Re: [Cake] lower bounds for latency

[Jonathan Morton <chromatix99@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2485 bytes --]

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).

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.

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.

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:

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).

This construct assumes the availability of a high resolution timer for
scheduling packets, but so does Bob's proposal.

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.

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.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 2662 bytes --]