Re: Traffic shaping

On Sun, Jul 23, 2006 at 09:16:29PM -0600, Dylan Griffiths wrote:
> Steven Kurylo wrote:
> >The problem is exactly what I've already stated. I have a symmetrical
> >connection. For example, I can get 2Mb in either direction. So I
> >could have two downloads at 1Mb each. Or two uploads at 1Mb each. Or
> >one upload and one download at 1MBps each. It doesn't matter which
> >direction, but my total throughput isn't going over 2Mb.
>
> Ahh. In that case, you should let TCP do its thing (since it'll
> automatically reach an equilibrium state between outgoing and incoming
> traffic), and otherwise throttle UDP traffic (which does not have
> built-in flow control). You might want to throttle the max out both in
> and out going to be 1.9Mbps if this symmetrical connection is some piece
> of equipment like a cable modem or DSL device which, instead of dropping
> packets at the max, simply queues them up.

Dylan is correct, TCP takes care of itself and UDP (and other connectionless
protocols riding on IP) don't have flow control.

I think you guys are both working on the assumption that the link is duplex
like DSL or cable modem.

Given the description (Steven, correct me if I'm wrong), this is a shared
media link of some sort (probably wireless) and the probelem is one host
choking the whole network by gobbling all the available bandwidth for a
download. Unlike what all y'all are discussing, tunnelling or
channelization is not an option as there is no peer capable of terminating
the other end of a tunnel/VC. Bandwidth management must therefore be done
on a single gateway.

If I'm correct in assuming that this is a wireless link, then the problem
makes more sense. Since for example on WiFi or 10base2/5 Ethernet, everyone
shares the available bandwidth. Ethernet and WiFi will try their best to
use the bandwidth so there is no control mechanism at the link layer. On
the flipside, the old token based techmologies such as token ring and FDDI
did a good job of dealing with this kind of problem at the link layer. Too
bad CSMA technologies took over the market.
Received on Sun Jul 23 21:38:12 2006