In message <m1CxeMK-0024g4C@building.weird.com>, "Greg A. Woods" writes:
>[ On Saturday, February 5, 2005 at 17:53:59 (-0500), Steven M. Bellovin wrote:
> ]
>> Subject: Re: Up-stream bandwidth shaping without resorting to linux/iptables
>? 
>>
>> 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.
>
>Ah ha!  Yes, of course.  And dropping of packets is one of the things
>ALTQ can be good at!  ;-)
>
>I haven't always been very trusting of a random sender's TCP conjestion
>control implementation though.  Do you know off hand whether all the
>more common implementations out there actually do the right thing or not?

Yes, all common implementations do the right thing, and have for >15 
years.  There have been some third-party products that break the rules 
to get better performance; fortunately, those haven't caught on.
>
>Also, for multimedia applications using UDP, such as VoIP using IAX, the
>majority of senders are not ever going to be "well behaved" by that
>definition.  There's a specific amount of data for them to send in every
>time slot and dropped packets are only going to affect the quality of
>reception, not slow them down.  I suppose in a really sophisticated
>multimedia application the receiver might report that "congestion" of
>some sort is causing quality problems and perhaps the result might be
>re-negotiation to use more compression or to drop back to a
>lower-quality data stream (perhaps if the user chooses to permit it),
>but that's really not going to help much if the goal is to limit the
>total incoming traffic of a given kind on a given link.
>
Right.  VoIP needs flow-based guaranteed bandwidth, where ALTQ or 
equivalent (a) reserves the bandwidth for the flow, and (b0 polices the 
flow to make sure it's not misbehaving.

>
>
>>  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.
>
>What happens in TCP if ACKs are dropped?  IIRC that wouldn't work as
>well, for rate control, as simply delaying the ACKs.

The sender can't tell the difference between a dropped packet and a 
dropped ack, so it will slow down in either case, but the situation is 
more complex.  If A sends bytes 1-100 in one packet and 101-200 in 
another, and the ACK(101) is dropped but the ACK(201) gets through, the 
sender won't really be able to tell -- it might just have been the 
receiver delaying its ACK on the first packet in the hope that it could 
send out a single ACK for two packets.  And things like ECN complicate 
the picture even more.

The same effect could, of course, happen for delayed ACKs, if the 
router doesn't queue them properly.  

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb