[clug] Emitting Source Quench When Queues Are Full?

[Alex Satrapa]

On Wednesday, October 1, 2003, at 11:38 , Sam Couter wrote:
> Delay/drop the ACK or the packet itself, it will have exactly the same
> effect on the connection.

Delay an ACK too long, or drop the wrong one, and suddenly you've got 
retransmitted packets ;)

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

Yeah, it's called ATM. :)  FastTCP is almost what I want - establish the 
bounds of the network at connection time, then start making minor 
adjustments through the life of the connection. ATM is great (as far as 
voice communications protocols go) - establish the available bandwidth 
at the time that the power is turned on, and never exceed it!

> ... You won't get (m)any dropped packets after that, so you'll have 
> achieved your goal.
>
> You know all this already.

I think what I'm really trying to say is that TCP/IP is not the right 
protocol for what I want to do.

> 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.

Yup.  That's about the size of it.  Rely on the upstream to drop packets 
at their expense, rely on downstream to drop packets at their expense, 
and me in the middle... I'll just queue stuff till the ACKs come home.

> So the sender's TCP stack can slow down!

But I've already paid for the packet!  I don't want to drop it or lose 
it again!  :)

In the meantime, I'll go look at ECN munging!

Alex