Steven M. Bellovin wrote:
> In message <m1CxYca-0024g3C@building.weird.com>, "Greg A. Woods" writes:
>>Well with any bandwidth management tool in any IP network it is only
>>possible to control what one sends, but not what one receives.
>>
>>(You could control what you receive, but there's no point since it has
>>to cross the narrower wire to get to your control point anyway.)
> 
> Actually, at least for TCP and well-behaved UDP applications, that's 
> not so.  Dropped packets are interpreted by the sender as an indication 
> of congestion, which will cause it to slow down.  Another strategy (I 
> suspect, though I haven't tried it) is to delay ACKs, since the sending 
> TCP will use the ACk arrival rate to clock the sending rate.

For TCP, one can set the window size [(struct tcphdr *)->th_win ] to a small 
value, which will indicate the amount of network traffic the other size ought 
to send before receving ACKs.

Using a window size of 0 tells the other side it ought to delay sending data 
for an interval and can be used for extreme congestion.

-- 
-Chuck