[BBLISA] November meeting: Jim Gettys on Internet buffer bloat

[Edward Ned Harvey]

> From: bblisa-bounces at bblisa.org [mailto:bblisa-bounces at bblisa.org] On
> Behalf Of Adam Moskowitz
> 
>        The mistaken quest to never drop packets has destroyed
interactivity
>        under load,

For what it's worth, I completely disagree with this, and as an IT
consultant, have been called in several times to companies having problems,
only to discover the problem was caused by somebody thinking it was ok to
drop packets under load.  

I don't want to argue about it, because I know it's religion, but I'll just
say this much:  

Let's assume a fast LAN getting congested through a WAN link.  There exists
a router, which is buffering the traffic it receives from the LAN.  There
exists such a thing as flow control.  At the mac layer, when the receiver
buffer is getting sufficiently full, the receiver (router) sends the PAUSE
frame (or newer more powerful alternatives) to the sender, on the LAN.  So
the sender, in hardware, knows to back off a little bit.  The application,
and even IP layer don't need to know about it.  No dropped packets.  Perfect
efficiency and optimization.  The only thing that can go wrong is a router
that is not sufficiently aggressive in applying back pressure on the LAN
might lead to so-called buffer bloat.  The fix is to tweak the router to
apply more back pressure on the LAN, or to give higher priority to certain
types of traffic, so they may jump the queue.  And the other possible
problem occurs if you have a WAN that is faster than your LAN.  Which I'm
not going to comment on, lest my comments be too caustic for public
disclosure.   ;-)

The so-called "congestion notification via packet drop," is a poorly
executed form of flow control.  It is fatal to DNS and many other stateless
protocols, like XMPP, SMS, etc.  It's fatal to stateless protocols that
don't want to waste the overhead of positive acknowledgement (because they
use small message datagrams and assume the network usually works).  The DNS
failure is the reason why clients call me to fix their network.  They don't
know what's wrong, all they tell me is "The internet is broken....  But only
sometimes, and we can't reproduce the problem consistently; it happens
randomly."  It is perfectly ok to do "congestion notification via packet
drop" for streaming video and audio.  It is also ok to do for TCP (at least
so I think, at least sometimes) because Positive Acknowledgement and
Retransmission (PAR) means TCP will automatically retransmit packets that
didn't receive an explicit ACK.

The main problem is dropping DNS packets.  Because DNS sends small stateless
datagrams, without explicit ACK, and DNS needs to rely on the network
reliably delivering the packets.  Dropping other packets such as XMPP and
SMS is also fatal to these other services, but the reason DNS is more
important is because DNS is so darn important.