Smoother bandwidth limiting

[Paul Slootman]

On Tue 04 Feb 2003, jw schultz wrote:

> > I've usually used bwlimits of
> > 4-12 depending on the time of day (expected available bandwidth in the
> > neighbourhood) and my other traffic. MTU is 1500, but I'm not certain if
> > the cable modem splits packages into smaller pieces than that for
> > forwarding. I suspect not, though.
> > 
> > > You do bring up an interesting point.  I could see
> > > restricting the write to bwlimit/100.  Sleeping much longer
> > > than 100ms is a bit crude.
> > 
> > Tying the maximum amount to write to bwlimit sounds like a workable, a
> > bit more general idea.
> 
> Yes but i'd like to hear from some people who know network
> performance programming.

Concerning ATM (used on DSL), from
http://www22.verizon.com/about/community/learningcenter/articles/displayarticle1/0,4065,1135z1,00.html

    ATM uses a 53 byte packet, with 5 bytes for the header - including
    bits to check the integrity of the header - and a 48 byte payload,
    with no integrity checking.
    [...]
    The choice of packet size was a tradeoff. A shorter packet size was
    desirable to minimize latency (delays in transmission) for voice
    traffic, but a longer one was desirable for computer traffic, which
    very often involved packets of 1500 bytes or so.

I believe that an MTU of 1500 is quite normal, however I've seen cases
where PPP is encapsulated over IP and the MTU becomes 1492 or less
(which gives problems where the (web)server at the other end doesn't
receive ICMP fragmentation-needed packets; usually due to
badly-configured firewalls). Of course, plain PPP often has an MTU of
576...

There's also the minimum 40 bytes of IP and TCP header data to consider
(IP and TCP header each are a multiple of 4 bytes, depending on the
amount of options set, with a minimum of 20 bytes and a max of 60
bytes). I believe that in most cases, the 40 bytes is a correct
assumption.

I can't really see that doing smaller writes will lead to packets being
padded, unless you're doing really small writes (ref. the ATM 48-byte
packets); the TCP and IP headers will always be added, which means that
the extra overhead of those will have a larger impact than any padding.

So, I'd suggest that 1024 isn't that bad a number for all cases; it'll
fit comfortably into most MTU sizes, and for dialup PPP it'll be split
into two packets without that much overhead. If not concerned with the
dialup PPP case, I'd go for something like 1400.


All IMHO of course :-)

Paul Slootman