I think the issue is what "better" means. In the absence of SACK,
clearly its "better for the network" if all the packets are dropped
until the dropped packet is retransmitted (note that this can be tricky
if you're not at an edge because the packets may take different paths).
On the other hand, if RTT + e < RTO, then its "better for the flow" for
you to transmit the packets so you can get the duplicate ACK congestion
signal before the coarse grain timeout. Note that SACK will help both
the flow and the network, unlike the scheme we've proposed.
Somewhat orthogonal to the proposed scheme is the notion of an eager
retransmit signal. This seems like it can't help but be better for the
flow because it minimally saves the difference between the RTT between
the router and the destination. The effect on the network is somewhat
less clear because it would cause the pause between retransmission to
shorten.
- Stefan
> -----Original Message-----
> From: tom@emigrant [SMTP:tom@emigrant]
> Sent: Thursday, May 21, 1998 2:11 PM
> To: cardwell@cs.washington.edu; savage@cs.washington.edu; syn@cs
> Subject: RE: early packet train discard?
>
> With strict go-back-N, once you drop a packet from a TCP flow,
> you could be better off dropping every future packet from that flow,
> until you see the next retransmit of the dropped packet.
> After all, with stream semantics, you can't use the later packets
> until the earlier packet gets delivered. If we assume this
> is the only congested switch in the flow, then you could argue
> that it would be better to drop aggressively now, if the congestion at
>
> the switch might be lower later. Akin to JZ's drop all or none.
>
> Of course, this mucks with fast retransmit. But it seems strange to
> transmit a packet simply so an dupack can be generated in the reverse
> direction -- why is this any different than ECN?
>
> An interesting study would be whether this would be better than sack.
>
> tom