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

From: Mark Allman <[email-masked]>
Date: Thu, 21 Dec 2000 10:34:16 -0500

Jamshid-

Thanks for the comments!

> > 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).
> 
> 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?

I understand the desire to be robust in the face of reordering.
However, I want to push back a little here -- or, at least get a
clarification.  Say we're using timestamps so we can send at most 3
SACK blocks in each ACK.  Now consider the following situation:

    rcv seg 40                     [everything before 40 has been received]
     snd ACK seg 40

    rcv seg 42
     snd ACK seg 40, SACK 42

    rcv seg 44
     snd ACK seg 40, SACK 44,42

    rcv seg 46
     snd ACK seg 40, SACK 46,44,42

    rcv seg 48
     snd ACK seg 40, SACK 48,46,44

So, assume that all the ACKs arrive.  It would seem to me that ACKs
2, 3 and 4 explicitly indicate that segment 41 is missing -- meeting
the criteria to retransmit.  

However, if ACK 2 is lost we will not see 3 SACKs explicitly
pointing out that 41 is missing.  However, we can note that ACKs 3
and 4 do not contain 42 in the first SACK block, so we can conclude
that we missed an ACK and therefore we could trigger a retransmit.

What if we lose ACK 4?  We don't get 3 specific indications that
segment 41 is missing.  And, unlike the last example, it is not
necessarily simple to *know* we missed a SACK (although you can
likely untangle this all later by noting that we never received a
SACK with 46 in the first SACK block -- but, I think this ugly
quick).  So, we likely can't hit the threshold for retransmission.

Or, is is good enough to get 3 SACKs for segment 42 *or a higher
segment* before retransmitting segment 41?  If this is OK, I think
I'm OK with the algorithm.  If you need three specific indications
then I don't think I am a fan given that I think the algorithm is
fragile in the face of ACK loss.

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: Jamshid Mahdavi <[email-masked]>
Date: 29 Dec 2000 11:16:33 -0800

To follow up on two notes from before the holiday:

1.  As Ethan wrote, you would still send new data if there are holes
    in the scoreboard which have not been SACKed 3 times, and your
    window permits you to send something.

2.  As Mark wrote, you would accept any SACK higher than the hole in
    question as an indication that the hole is in fact a hole.  (As
    opposed to just a SACK containing N+1 specificly).

Happy New Year everyone!

--Jamshid

Ethan Blanton writes:

...
> 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?

Mark Allman writes:

...

---

From: Ethan Blanton <[email-masked]>
Date: Fri, 29 Dec 2000 15:46:36 -0500

>     window permits you to send something.

...  AND if there is no new data to be sent but there are holes, you 
retransmit a hole regardless of whether or not it has been SACKed as a hole
three times.

>     opposed to just a SACK containing N+1 specificly).

With that caveat, I like these.
Ethan

-- 
I was young and foolish then, I feel old and foolish now.
		-- They Might Be Giants, "Ball & Chain"