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

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Jul 2009 10:34:38 +0200

[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

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Jul 2009 10:59:12 +0200

> The question is, what do we want to tell home gateway builders?

We should tell them that forwarding IP flows from higher bandwidth  
links into much lower bandwidth links generally produces better  
results when queues are only large enough to handle common burst sizes  
without loss and no larger.  Unnecessarily large transmission queues  
may introduce persistently and perversely high path latency on fully  
loaded low-bandwidth links, producing severe negative effects on  
application throughput.

Beyond that, I don't know what else we should say.  Maybe it would  
help to give some guidance for various common sub-IP links.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: David R Oran <[email-masked]>
Date: Wed, 29 Jul 2009 10:49:35 +0200

On Jul 29, 2009, at 10:34 AM, Iljitsch van Beijnum wrote:

> 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.)
>
It isn't actually home gateways that appear to be the problem, but  
either independent (or combined) L2 devices like cable modems or DSL  
modems that are the big offenders. In my case as a user I tend to  
ameliorate the problem by rate limiting the output of my home gateway  
to avoid building up a queue on the cable modem. At least the open- 
source firmware loads allow you to do this on some devices.

This does bring up a potential work area in the IETF, which is to  
develop or re-purpose some protocol for coordinating L3 and L2 devices  
so that the L3 box can learn the link characteristics of the L2 device  
and not act as if the ethernet between them is actually the capacity  
of the (probably bottleneck) next hop.

I don't think is this is an appropriate topic for the homegate group,  
as it jumps way over the line into protocol development.

> 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.
>
> 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?
Extensive is in the mind of the beholder. If you simply let the hosts  
do the marking, then all the home gateway has to do is police/shape.  
Right now we're in a chicken/egg situation where most hosts don't  
bother to mark because the home gateways either don't obey the  
markings, or worse, remark or drop the traffic.

HGI and others (e.g. DLNA) do in fact have specs for this kind of  
stuff. I'll refrain from commenting on what I think of their quality.  
I think the group might consider taking some of this on, however I  
urge caution for a number of reasons including:
- focus for the group
- bleed-over into net neutrality issues
- service definition and provisioning of device queues by the service  
provider versus the consumer.

> We also wouldn't want applications to game the system by sending  
> more small packets that get better service than fewer large packets.
>
All the reasonable QoS implementations I know of count bytes and  
account for headers. Do have a counter example?

> 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?
>
> 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?
>
RED doesn't help in the split-box configuration since the big queues  
aren't in the home gateway, as I noted above.

> 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.
>
Interesting, but orthogonal in my view.

> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Jul 2009 11:05:56 +0200

Hi,

> The question is, what do we want to tell home gateway builders?

one half-baked idea is to tell them to provision buffering for some  
number of milliseconds of traffic (I'm using ms here instead of bytes,  
because that factors out link speeds) *and* use something better than  
FIFO (e.g., some AQM scheme) that you configure so that the target  
queue is a small fraction of that buffer.

> somewhat out of favor, but is it worse than a simple tail drop queue?

I believe we want a queueing scheme that results in a short standing  
queue independent of how much buffer there is. Many AQM schemes (like  
RED) have that property, FIFO doesn't.

We also do want ECN, so that whatever AQM scheme we recommend doesn't  
need to induce unnecessary losses in order to drive the queue size down.

> the case where we specifically prioritize the real-time traffic.

I don't think basic WFQ has the property that it builds short standing  
queues (but my queue fu is ten years old).

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

Actually, I think recommending support for less-than-best-effort  
(e.g., RFC 3662) would be good.

Lars

---

From: Richard Bennett <[email-masked]>
Date: Wed, 29 Jul 2009 14:21:36 -0700

> provider versus the consumer.
I'm not sure what Homegate has to do with "net neutrality issues." If 
net neutrality means anything at all, it's the demand by certain private 
network operators, most notably Google, to have unfettered access to 
first/last mile residential broadband networks. Google wants to bypass 
the public Internet and install edge caches directly on the L2 network, 
in other words. Aren't private network-to-private network issues are 
outside the scope of IETF?

Under other definitions of net neutrality, ISP behavior is circumscribed 
in various ways, but end-user behavior isn't. Given that home gateways 
are (at least to some extent) end-user controlled devices, NN also 
wouldn't apply to them under this more fuzzy definition.

NN is in any case a US issues, so I don't see why the international 
community should care about it. What am I missing?

RB

-- 
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC