---------- 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.t...@gmail.com> Cc: ro...@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 _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm