this is a good question.
> Yes, we lose the work we did in getting the stream packets to the
> congested router. But clearly the router is overwhelmed when
> we start dropping packets,
assuming drop-tail FIFO, yep.
>so is the better thing to do to drop
> (say) one packet randomly from all flows or to pick a single flow to shoot
> in the head? What I'm worried about is that we are conflating
> two problems -- how best to manage buffers and how best to signal
> congestion.
this is a good point. it's tough though, since if we discard a packet,
deployed TCP will always take this as a signal to cut its sending rate
drastically (by a factor of two or down to one packet/rtt).
> What if we specialized this to "drop-SYN" -- if the syn gets dropped,
> we drop the remainder of the flow and send a NAK/ECN? That gets
> us out of the fast retransmit question. Alternatively, perhaps
> we could propose a wart that did fast SYN retransmit -- if
> you get post-SYN packets before a SYN, ack them! --
> if you get three post-SYN dupacks, fast retransmit the SYN.
> Or maybe I've forgotten and someone mentioned that already?
We've tossed around the idea of retransmitting SYNs, since clients are
awfully slow about this (a 3 second timeout, i think). But i don't think
either the client or the server will typically send anything after the
SYN, since in typical (non-NT) sockets APIs, you have to wait to get an
ACK for your SYN before you send data. If the SYN gets dropped we won't
have to worry about anything else coming, 'cause the app probably isn't
going to send anything.
neal