<p dir="ltr">It's an interesting viewpoint, at least, and probably should stimulate some thought about what happens with very small BDPs. In this case we're talking about a BDP below 3KB per flow, including light times, permitted queuing delays, and link occupancy time of a single packet (which by itself guarantees that the total BDP is always at least one packet).</p>
<p dir="ltr">A point that I think gets missed in discussions involving delayed acks, is that it's always possible to force an immediate ack from the receiver, simply by setting the Push flag. A TCP sender could use that if its cwnd is forced down to 2 segments or less, without more invasive changes, in order to maintain traditional ack clocking.</p>
<p dir="ltr">However, with only one packet in flight, loss of that packet would result in an RTO, which I think would be much more severe a penalty than AQMs generally assume they are giving. This is a related problem to having too small a receive window.</p>
<p dir="ltr">I happened to be doing some thinking about TCP Pacing yesterday, and how it might compare to or be convertible into a truly rate based TCP congestion control. It might be relevant to summarise my thoughts here:</p>
<p dir="ltr">Pacing is generally thought of as spreading the transmission times of individual packets throughout the RTT interval corresponding to each congestion window. This is straightforward to implement in theory - calculate the earliest permitted transmission time of packet N+1 as the transmission time of packet N plus the length of packet N multiplied by the RTT estimate divided by the congestion window length (in bytes).</p>
<p dir="ltr">This construct assumes the availability of a high resolution timer for scheduling packets, but so does Bob's proposal.</p>
<p dir="ltr">The equation above does not include a term for where in the window the packet lies. This is intentional - that information is not needed. If pacing is thus applied even to packets transmitted out of order (ie. retransmissions), and the test against the end of the cwnd in existing TCP is removed (but not, of course, the rwnd test), then we easily get a rate based TCP congestion control which, as it turns out, can scale down to a single segment cwnd without incurring the risk of a single packet drop causing an RTO.</p>
<p dir="ltr">It is then relatively straightforward to extend this behaviour to cope with sub-segment cwnd, either by measuring cwnd in bytes rather than segments, or by introducing a scale factor for RTTe which is incremented in lieu of attempting to halve a cwnd of 1.</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>