[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
