Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps.

From: Mark Allman <[email-masked]>
Date: Thu, 10 Jan 2002 10:52:48 -0500

> >If you (a) don't want to incur the overhead of timestamps and (b)
> >want to detect spurious retransmits, you *do* have another
> >option.  You can use DSACK to detect spurious retransmits.
> 
> If you want to detect a spurious retransmit caused by a spurious
> timeout, you typically want to do that so that you can avoid that
> the entire outstanding flight of segments is (often unnecessarily)
> retransmitted. This "go-back-N misbehavior" inevitably follows a
> spurious timeout.
> 
> However, you *cannot* use DSACK to avoid those go-back-N
> retransmits since the DSACK only arrives after the "go-back-N
> misbehavior" has already taken place.

Yes.  But, if you can detect a spurious retransmit (and go-back-n
misbehavior) you can avoid it in the future.  So, there is still
value in detection no matter when you do so.  I am not saying that
use of the DSACK method is *preferred*.  I am simply noting that if
someone does not want to incur the cost of using timestamps and
eifel there is still *something* that can be done.

allman

---
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 10 Jan 2002 17:26:29 -0800 (PST)

> eifel there is still *something* that can be done.

But how does one spurious timeout correlate to the next timeout?
I don't know how TCP can say the next timeout must be spurious
given that the previous one is...

							K. Poon.
							[email-masked]