- Stefan
> -----Original Message-----
> From: Neal Cardwell [SMTP:cardwell@cs.washington.edu]
> Sent: Thursday, May 21, 1998 2:47 PM
> To: syn@cs
> Subject: RE: early packet train discard?
>
>
> Hmm. If TCP were using strict go-back-N, i could see that it would
> make
> sense to do early packet train discard.
>
> 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
> >