But since TCP doesn't do go-back-N (it only fills in the holes usually),
it seems to me to be better for the flow and the network (with or without
SACK) to get the remaining packets in the train thru to the destination,
if you are able. If we drop them, then all the work - bandwidth and
buffers - expended in getting the packets that far (on average, half way
across the internet) will have been wasted. In addition, you lose any
dupack or SACK info you might get by letting the packets thru, and force a
timeout and slow start, as Stefan alludes to. So it seems we'd just
increase latency and wasted bandwidth and buffers by retransmitting later.
Is that right?
It seems SACK (and Vegas and RED) would be good things here.
neal
> > An interesting study would be whether this would be better than sack.
>
> 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
>