On Jul 29, 2009, at 10:34 AM, Iljitsch van Beijnum wrote:
[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.)
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.
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?
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?
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?
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.
I'm guessing that we don't want to specify any default diffserv
behavior...
Iljitsch
_______________________________________________
homegate mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homegate
