Just to clarify: A single bandwidth request can only serve a single TCP packet? That is, the modem cannot make a request for slots for multiple packets simultaneously during the use of a single contention slot?

*Bandwidth requests can be piggy-backed on data packets, but that only works when there are multiple data packets queued in the modem, and even in that case is dependent on the presence of optimization in the modem’s firmware.

“The bottleneck on the
upstream side isn’t bandwidth per se, it’s the packet rate. So a
number of connection requests use up the cable modem’s contention
slots before raw bandwidth is maxed out. It’s not about bandwidth,
it’s about duty cycle.”

Is your argument, in sum, the following?

In contrast to
other forms of traffic, Bittorrent produces a large number of small
synchronization (SYN/ACK) packets which substantially increases
contention at the DOCSIS MAC level (through collisions on the
“contention slot”? Or contention for mini-slots?). Packet drop has no
appreciable effect on the number of these packets and so such
“throttling” is ineffective.

I would expect the rate of contention to be a function of the amount
of data to be transmitted and not the number of packets: if you are
constantly sending data you need to vie for the same transmit slots
regardless of the size or type of the individual packets. That is, the
same data rate HTTP transfer should create the same degree of
contention as a Bittorrent transfer.

Second, the amount of contention is limited in some way (it is not
unbounded). How?

Finally, in the paper you cited, “Assessing the Impact of
BitTorrent on DOCSIS Networks” I see no comparison to performance
degradation caused by other forms of traffic (e.g. HTTP). That there
is contention when links are highly utilized is not under
question. There is no evidence in that paper that Bittorrent, as a
protocol, causes more contention that other forms of traffic.

Please do not shy away from precise, technical explanations.