[Bloat] A bit of history on RFC970 and RFC896 from john nagle

[Dave Taht]

---------- Forwarded message ----------
From: John Nagle
Date: Thu, Apr 14, 2016 at 7:14 PM
Subject: Re: Bufferbloat and FQ and you
To: Dave Taht <dave.taht at gmail.com>
Cc: ropan at cisco.com


On 04/14/2016 03:33 PM, Dave Taht wrote:
>
> https://www.rfc-editor.org/rfc/rfc7806.txt was published today.


   "There is extensive history in the set of algorithms collectively
   referred to as "fair queuing".  The model was initially discussed in
   [RFC970], which proposed it hypothetically as a solution to the TCP
   Silly Window Syndrome issue in BSD 4.1."

That's somewhat wrong.

First, tinygram prevention (the "Nagle algorithm") is not about
"silly window syndrome".  Silly window syndrome occurs when the
window is full, and the reader does a small read, resulting in
the sender being allowed a small write, resulting in very short
messages.  The solution is clearly to not offer more window
until there's at least one full size datagram worth of window
available.

Tinygram prevention is a problem when the window is empty,
not full, and the writer is doing small writes.  The question
is how to consolidate those writes.  It's not obvious how
to do this without impacting interactive response.  The
classic solution, from X.25, was an accumulation timer with
a human response time sized delay. That's a bad idea, but
unfortunately the people who put in delayed ACKs didn't know that.
They were trying to fix TELNET responsiveness at Berkeley, which
was using a large number of dumb terminals connected to terminal
servers at the time. Delayed ACKs with a fixed timer are useful
in that situation, and in few others.

Actually, this didn't involve 4.1BSD's netowrking; we at Ford
Aerospace were running a heavily modified version of 3COM's UNET
TCP/IP stack on various UNIX systems.  That TCP/IP stack lost
out because it cost about $4000 per node for the software.

The tinygram stuff was in my RFC 896, and isn't really
relevant to fair queuing or congestion management in routers
and other middle boxes.

The important part of RFC970 is at the section headed
"Game Theoretic Aspects of Network Congestion".  This
discusses the relationship between endpoints and
middle boxes, and the need to create an ecosystem
which does not reward bad endpoint behavior.

The [NOFAIR]] reference is interesting.  Yes, fairness is
gameable.  But FIFO is so much worse, as the bufferbloat
people point out.

It's worth thinking about when a packet becomes useless and
should be dropped.  If the packet times out (this was originally
what TTL was for; it was a seconds count), it can be dropped
as obsolete.  A router which looks above the IP level could
also detect that the packet has been superseded by a later packet
in the same flow, that is, there's a retransmitted copy also
queued.  If enough resources are available, that's the only
packet dropping you have to do.  As an optimization, you
can also drop packets that are so far back in queues that
they'll time out before they're sent.

It's worth viewing that as a goal - don't drop any packets that
would be useful if they were delivered.  Just reorder based
on notions of fairness and quality of service.  This is the
opposite of Random Early Drop, but that's sort of a meat-axe
approach.

Bufferbloat is only bad if the queuing is FIFO-dumb. It's
fine to have lots of queue space if you manage it well.

(I'm retired from all this.  It's up to you guys now.)

                                John Nagle




-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org