[R-C] Packet loss response - but how?

[Jim Gettys]

On 05/04/2012 03:02 AM, Harald Alvestrand wrote:
> Now that the LEDBAT discussion has died down....
>
> it's clear to me that we've got two scenarios where we HAVE to
> consider packet loss as an indicator that a congestion control
> algorithm based on delay will "have to do something":
>
> - Packet loss because of queues filled by TCP (high delay, but no way
> to reduce it)
> - Packet loss because of AQM-handled congestion (low delay, but
> packets go AWOL anyway)
>
> We also have a third category of loss that we should NOT consider, if
> we can avoid it:
>
> - Packet loss due to stochastic events like wireless drops.

These may be less frequent than you might expect: in fact, we have had
experience recently with the opposite problem, finding device drivers
which would attempt to retransmit infinitely (inserting unbounded delay)
in the face of problems in the wireless channel.  At least we've now got
an upper bound on retransmission attempts in the Linux Atheros 9k
driver...  There are bugs everywhere....

What is "normal" will be needing multiple attempts to transmit a packet
in WiFi (and therefore additional jitter as those attempts take place).
It turns out that it is often/usually a better strategy to *not* drop
the transmission rate in the face of transmission errors, but to make
multiple transmission attempts (remember, dropping the rate increases
the time in which a packet may get damaged by noise).  The Minstrel
algorithm in Linux is quite sophisticated in this way.  But such
operation will generate jitter rather than loss.
                    - Jim

For amusement, see:
http://www.rossolson.com/dwelling/2003/11/every-packet-is-sacred/

Unfortunately, some of the world takes this humour seriously, and the
result has been bufferbloat...