The issue about packet-train drop and fairness seems like a complicated
one. What is the scenario in which its better to drop all of one flows
packets rather than nick everyone? Well... if one flow had several
packets in the queue and a big window and all the other flows had small
windows and/or long RTT's then it might make sense. In this case
dropping the packets from the small flows might affect them
disproportionately. Ultimately though this shouldn't affect network
goodput at all, only some kind of fairness. If you were doing something
like FRED at the router then this shouldn't matter. Is there another
scenario?
Ultimately, I agree the we should separate between buffer management and
signaling issues. To this end I suggest that we identify reasons for
dropping a packet. I'll suggest the following three questions as a
start:
1) is this buffer going to be useful?
(e.g. if window is less than 4 then additional packets
in train don't help)
2) will the network be better off if someone else uses this
buffer?
(e.g. letting this buffer through will make sender ramp
up)
3) is it more fair is someone else uses this buffer?
(e.g. your flow will be hurt less by dropping buffer
than another flow)
- Stefan
> -----Original Message-----
> From: tom@emigrant [SMTP:tom@emigrant]
> Sent: Thursday, May 21, 1998 4:23 PM
> To: cardwell@cs.washington.edu; syn@cs
> Subject: RE: early packet train discard?
>
> Where I was going was this: sack requires endpoint changes.
> So is this the right way to handle congestion drops? If we can change
> endpoints and routers, we could deploy "drop rest of stream" and a
> NAK/ECN,
> and completely remove dupacks and fast retransmit.
>
> 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, 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. Clearly if you want fairness, you want to shoot
> every flow equally, but maybe there's a swapping analogy --
> if there are too many little flows, maybe it would be better
> to shoot a fraction of them completely, rather than nick everyone.
>
> 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?
>
> tom