Subject: Re: [Tsvwg] Re: new I-D for SACK-based recovery

From: Jamshid Mahdavi <[email-masked]>
Date: 20 Dec 2000 09:51:27 -0800

Mark,

This looks like a very nice draft.  We have also suggested the
possibility that NextSeg() could duplicate the 3 dupacks check for
each sequence number range it returns; this would fix the
(admittedly unlikely) case where a packet was reordered at just the
right point in time after the loss which started recovery.  (The
reordering would emit a SACK block which looks like a loss until the
next SACK block comes in which indicates the arrival of the
out-of-order segment).

It also occurs to me to ask whether you mean "segment" in this
definition of NextSeg() or whether you actually just mean a
byte-range.  (I.e. does NextSeg() decide how to segment the data or
does the caller of NextSeg()?)  Another minor point, but maybe worth
clarifying.

As far as justification for this I-D, Tan Gao did some work for me
this summer which provides some very compelling examples of problems
in numerous implementations.  I have put this work on line at the
following URL:

http://www.neticus.com/users/mahdavi/papers/tcp_behavior.ps

If anyone has any doubt for the need of drafts such as this one, they
should look at this paper (and perhaps be terrified...).

--Jamshid

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

---

From: Ethan Blanton <[email-masked]>
Date: Wed, 20 Dec 2000 20:08:15 -0500

> next SACK block comes in which indicates the arrival of the

Hmm, this seems reasonable to me as long as it does not prevent a packet
being sent altogether...  i.e. it seems like a good enough reason to send
*new* data, but not a good enough reason to send nothing at all.  If there
is no new data I think the first non-ACKed non-SACKed non-rexmtd packet
should go all the same.  Comments?

> does the caller of NextSeg()?)  Another minor point, but maybe worth

I feel it should return a byte range that is the precise size of the segment
to be sent.  This seems most reasonable to me...  This range would be 1 SMSS
for new data or large holes, and could conceivably be less if a small packet
was lost for some reason.

> should look at this paper (and perhaps be terrified...).

I have been reading it this afternoon, and I am indeed frightened...
Ethan

-- 
*Notice*:  My GPG key has changed.  Please retrieve the new key via:
            gpg --keyserver wwwkeys.us.pgp.net --recv-key 883C1C14
           Sorry for the inconvenience.  Please note that the new key
	   is signed with my old key for preliminary verification.