[Iccrg] FW: [tsv-area] Amount of packet buffering in home gateways

[Eddy, Wesley M. (GRC-MS00)[Verizon]]

>-----Original Message-----
>From: tsv-area-bounces at ietf.org [mailto:tsv-area-bounces at ietf.org] On
>Behalf Of Iljitsch van Beijnum
>Sent: Wednesday, July 29, 2009 4:35 AM
>To: homegate at ietf.org; TSV Area
>Subject: [tsv-area] Amount of packet buffering in home gateways
>
>[posted to homegate and tsv area, prune as necessary]
>
>I'm currently in the congestion control research group session and the
>issue of excessive buffering in home gateways came up. (I'm posting to
>tsv area rather than iccrg or ledbat to avoid subscribing to a bunch
>of new lists for a single discussion, I would prefer to discuss this
>on homegate but I'm open to redirects if necessary.)
>
>So what is the right thing to do? As I mentioned in the homegate bar
>bof, last year I was in a place where there was a 128 kbps uplink with
>10 seconds (160 kbyte) of buffering. This made the connection almost
>unusable until I manually set my send/receive buffers to 8k.
>
>The question is, what do we want to tell home gateway builders?
>Obviously it would be nice to give priority to VoIP and gaming traffic
>and so on, but how do you easily do this without an extensive packet
>classification system? We also wouldn't want applications to game the
>system by sending more small packets that get better service than
>fewer large packets.
>
>What I'm thinking is that at 64 kbps or slower, you probably want to
>buffer 4 packets and no more, but also no less. At higher speeds, I'm
>thinking 10 packets is really all you need, assuming a single fifo /
>tail drop queue. Does anyone have data or arguments that conflict with
>this?
>
>But do we want to recommend RED? I seem to remember it has fallen
>somewhat out of favor, but is it worse than a simple tail drop queue?
>With RED it's necessary to have more buffering in order to let it work
>without tail drops happening anyway. So how much buffering would that
>require? 20 packets? 40?
>
>Bob Briscoe just made the argument that weighted fair queuing isolates
>flows from each other so they can't interact in useful ways. So
>recommend against it? On the other hand, WFQ would make VoIP etc work
>much better in the presence of some heavy flows. But not as well as in
>the case where we specifically prioritize the real-time traffic.
>
>I'm guessing that we don't want to specify any default diffserv
>behavior...
>
>Iljitsch