Question : Traffing Shaping and the TCP Window Field

I've been trying to find a way to do sophisticated traffic shaping on a box (rather than on a router), but I've been having no success. There's plenty of info about shaping outgoing traffic, but not for incoming traffic. I understand why this is...the sending computer can simply keep sending and there's not really a high-level way to control it, whereas to shape outgoing traffic you simply send the data in different manners. However: What about the TCP window field? Couldn't this field be used to control the bandwidth, and if the sending node were to consistently violate the window, that node could simply be blocked until they fixed the problem. (Maliciousness is a different issue; this is for those who do not intend to violate the server's policy.) I'm interested both in implementing this in the Linux 2.4.* kernel and in direct network manipulation (i.e., for an arbitrary operating system).

Answer : Traffing Shaping and the TCP Window Field

TCP window size can be used to speed up or slow down data transfer in that the sender can never send more data that the advertised window size. So if I indicate that my TCP window size is 4096 bytes, you could send four 1024-byte segments. I would then ACK the receipt of that data and assuming the data was still in my receive buffer the ACK would show a window size of 0. Once the receive buffer was cleared I would send another ACK with the window size of 4096.

4096 bytes is inefficient for ethernet and most of the machines on my ethernet network have TCP send/recv buffers of anywhere between 16k and 64k. I suppose I could limit a user's bandwidth by setting his TCP send/recv buffers to 2-4k and make data transfers slow to a crawl.

I'd recommend TCP/IP Illustrated, Vol 1 (W. Richard Stevens) which has 8 chapters devoted to TCP operation. What I have said only touches on the subject. You can alter TCP maximum segment size, ACK delay, and all sorts of other parameters that will affect the rate of bulk data transfer.

Good luck.
Steve
Random Solutions  
 
programming4us programming4us