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

From: Mark Allman <[email-masked]>
Date: Thu, 10 Jan 2002 07:33:02 -0500

Two points...

Repacketization seems like it will be a problem.  In other words,
adding 12 bytes to a retransmit turns a single packet retransmission
into two packets worth of data when sending full sized segments.
While this should not be a problem in principle, my guess is that it
would end up being quite an ugly situation (because hosts would be
sending too many segments, runt segments, etc. and because middle
boxes may puke).  If we want a signaling method for retransmits, I
say we revert to the bit approach.

> My argument is that, there should be allowance (and specification)
> for using timestamps only when it is necessary/useful to do so
> (just like SACK). The Eifel draft seems to me like a good place to
> address this (as well as the= suggestion about restarting the
> retransmit timer after fast-retransmit)?

I agree that there could well be cases for enabling timestamps on
the fly (e.g., enable them for all connections, but only use them
once we are sending fast enough to need PAWS).  However, I disagree
completely with the assertion that the eifel draft is the right
place to make that change.  Eifel is simply an algorithm to detect
spurious timeouts.  Let's not throw together everything in the one
draft.

OK, I lied... One more point...

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.  For instance,
there is an algorithm sketched in draft-blanton-dsack-use-01.txt
that could be used.  It is not nearly as robust as eifel, but my hit
is that it could work pretty well in lots of cases.

allman

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

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

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 10 Jan 2002 16:45:59 +0100

I haven't caught up in this discussion yet, but one comment ...

At 13:33 10.01.2002, Mark Allman wrote:
>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.

///Reiner