[clug] Emitting Source Quench When Queues Are Full?

Sam Couter sam at couter.dropbear.id.au
Wed Oct 1 23:38:41 EST 2003


Alex Satrapa <grail at goldweb.com.au> wrote:
> 
> The QoS stuff ultimately ends up dropping packets in order to force the 
> remote end to slow down.

That's the way it's supposed to work, and it does.

> I'm hoping that enough stuff out there will honour source quench, so 
> that I don't end up having to drop packets. My windows boxen will be 

Why would dropping outgoing packets on your side matter? They're free,
unless you pay a data charge on your local ethernet.

> I'd really like to be able to delay ACK packets "enough" to force the 
> remote end to slow down too (ie: run out of xmit window) without 
> retransmitting packets.

Delay/drop the ACK or the packet itself, it will have exactly the same
effect on the connection.

> Absolutely not!  The goal is to not drop packets *or* have packets 
> retransmitted.  Either way around will end up in wasted bandwidth.

Dude, people way smarter and more experienced than either of us have
already thought about this. They've got it covered.

Drop a TCP packet, the sender will retransmit after a while. If it still
doesn't get through, it'll back off exponentially. Pretty soon you've
got a TCP connection that's running about as fast as the network path
can carry it, with no dropped packets (barring occasional attempts to
step up the transmission rate again). You won't get (m)any dropped
packets after that, so you'll have achieved your goal.

You know all this already.

> I'd prefer to waste 10Mb of RAM in queues and buffers than drop a single 
> packet.

If you hold onto the packet (without sending an ACK back, which you
really don't want to do unless you're the final destination host), the
sender doesn't know that. It only cares about the ACKs. It won't slow
down until it loses a few packets, and a lost ACK looks the same as a
lost outgoing packet.

Big queues will only help when you're sending stuff anyway, in which
case you want to use QoS stuff and drop locally sourced packets. They're
free, since they haven't traversed the low-bandwidth link yet.

> Ideally, any packet-dropping would be done by my upstream, 
> before they try to shove packets down the skinny pipe downstream to my 
> network.

Packets that can't be shoved down your pipe before the TTL expires
*will* be dropped by your ISP. Sender then retransmits, backs off, etc.
See above.

> I don't see the sense in shaping traffic over my link by 
> dropping packets once they've already been sent to this network.  

So the sender's TCP stack can slow down!

> Dropping packets at my end seems an awful waste of bandwidth for the 
> whole intermediary network.

Only a few packets are dropped. TCP stacks know to slow down when that
happens. See "exponential TCP backoff", above.
-- 
Sam "Eddie" Couter  |  mailto:sam at couter.dropbear.id.au
Debian Developer    |  mailto:eddie at debian.org
                    |  jabber:sam at teknohaus.dyndns.org
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.samba.org/archive/linux/attachments/20031001/2bccd540/attachment.bin


More information about the linux mailing list