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

[John Leslie]

Eddy, Wesley M. (GRC-MS00)[Verizon] <wesley.m.eddy at nasa.gov> wrote:
>>-----Original Message-----
>>From: tsv-area-bounces at ietf.org [mailto:tsv-area-bounces at ietf.org] On
>>Behalf Of Iljitsch van Beijnum
>>
>> 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.)

   (I've added Iljitsch as a Cc; I don't think cross-posting would help.)

>> 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.

   I think we can define a lower bound: the buffer must hold at least
enough bytes to form the maximum-size outgoing message.

   An upper bound is harder.

   Let me suggest that the additional amount of buffering should cover
the time required to input enough bytes for another maximum-size
message _plus_ some "response time" -- the size in bytes being computed
based upon the outgoing byte rate.

   On the question of what that "response time" should be, I'll punt.

   ;^)

>> 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?

   I wouldn't agree that packet count is the right metric.

   I also wouldn't agree that a single number is appropriate without
regard to the input rate.

   10 maximum-sized packets strikes me as a bit high for a 128 kbps
uplink. (1500 * 8 / 128000 = 94 msec, not even considering jumbograms.)

>> But do we want to recommend RED?

   Random Early Discard makes sense only when you can't rate-limit at
the input (in other words, when you have to accept a packet not knowing
whether it might go out on an uncongested interface). Otherwise, you're
better off letting the sender(s) know you're congested by not accepting
their packet.

>> 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.

   This doesn't feel like a congestion-control question to me.

>> I'm guessing that we don't want to specify any default diffserv
>> behavior...

   I certainly don't want to do so here and now...

--
John Leslie <john at jlc.net>