[Gllug] traffic shapping

[Alistair Mann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thus spaketh Chris Ball on Friday 23 May 2003 1:39 pm:
> >> On 23 May 2003 10:19:58, Alistair Mann <alistair at lgeezer.net> said:
>    > Thus spaketh Jonathan Dye on Wednesday 21 May 2003 1:11 pm:
>    >> I'm trying to set up some traffic shaping on my dial up connection
>    >> to limit the speed of incoming packets
>    >
>    > Stop right there. There is no traffic-shaping solution anywhere
>    > that can help you to shape /incoming/ traffic. By definition,
>    > traffic cannot be shaped until it has already arrived, by which
>    > time, your dialup line has already been swamped.
>
> For complex traffic shaping, perhaps.  There are certainly shaping
> (limiting) solutions that *can* work from the same machine, though.
> Consider the following, taken from the GNU wget(1) source:
>
>    limit_data.dltime += delta;
>    expected = (long)(1000.0 * limit_data.bytes / opt.limit_rate);
>
>    if (expected > limit_data.dltime) {
>        long slp = expected - limit_data.dltime;
>        usleep (1000 * slp);
>    }
>
> By usleep(3)ing while we read(2), we delay the ACK that is sent back
> after a packet.  This in turn reduces the TCP window for the connection,
> which reduces the rate that the remote machine sends us data.  Not only
> is it possible to limit incoming traffic, it's possible to do it in
> userland, too.
>
> Generalising this approach, trickle[1] LD_PRELOADs its own read(2)
> implementation and takes config file arguments of per-site and service
> limits, usleeping as appropriate. :) It may well help for the situation
> described, and portably so.

Just before this thread goes beyond the bounds of my knowledge, I'll recognise 
there's at least two problems that inbound shaping can solve.

The first is enforced interhost connection speed, which was what Chris and OP 
are doing, by slowing down acks, and using slow outbound traffic to slow down 
inbounds traffic.

The second is enforced bandwidth allocation, which was what I was looking at. 
A remote host will not dutifully accept slow initial acks for the entirety of 
the connection, but will try to increase speed all the way through; this 
results in traffic on the wire that is being ignored. That ignored traffic 
serves to exclude other remote hosts from connecting to the extent that IF 
bandwidth per host is 25% of available bandwidth, then, the maximum number of 
hosts able to connect is not necessarily 4; it could well be just the 1.
- -- 
Alistair Mann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+zh3dEz+/jt85AfsRAgf3AJ97qpL1wYzXg+Hvc/1pAgRs3nfAQwCeNAt/
mU1LIVVK2JN0Jps2u9tvzlA=
=goaO
-----END PGP SIGNATURE-----



-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug