Subject: [tcpm] Some feedback on draft-ietf-tcpm-rfc2581bis-01.txt

From: Fernando Gont <[email-masked]>
Date: Sat, 05 Aug 2006 08:33:15 -0300

Mark,

A couple of comments on draft-ietf-tcpm-ietf-rfc2581bis-01.

Page 8. The draft says:
"    6.  When the next ACK arrives that acknowledges new data, a TCP
         MUST set cwnd to ssthresh (the value set in step 1).  This is
         termed "deflating" the window.

         This ACK should be the acknowledgment elicited by the
         retransmission from step 1, one RTT after the retransmission
         (though it may arrive sooner in the presence of significant out-
         of-order delivery of data segments at the
         receiver). "

Can the ACK really arrive sooner than one RTT? Unless the RTT for the 
connection decreases, I cannot see why this would happen.

The draft goes on with:

"       Additionally, this ACK should acknowledge all the
         intermediate segments sent between the lost segment and the
         receipt of the third duplicate ACK, if none of these were lost."

What if it doesn't? Should we stay in loss-recovery until this 
happens, or should we end loss recovery, anyway? (The former, right?)

Just my 2 cents,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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

---

From: Mark Allman <[email-masked]>
Date: Sat, 05 Aug 2006 09:51:12 -0400

> Can the ACK really arrive sooner than one RTT? Unless the RTT for
> the connection decreases, I cannot see why this would happen.

As noted, out-of-order delivery can make this happen ... i.e., the ACK
*should* be trigged by the retransmission.  But, if there was just
reordering and no loss then it might not be.  So, the ACK covering the
retransmit could be triggered by the original transmission (and, so
could arrive earlier than one RTT after the rexmt was sent).

> happens, or should we end loss recovery, anyway? (The former, right?)

Loss recovery ends with the receipt of the first new ACK as the document
says.  Right after the above quoted text is this:

    Note: This algorithm is known to generally not recover efficiently
    from multiple losses in a single flight of packets [FF96].  Section
    4.3 below addresses such cases.

RFC 2581 does not try to specify NewReno or SACK-based loss recovery
schemes - even though it recommends implementing such schemes (which are
specified elsewhere).

allman

---

From: Fernando Gont <[email-masked]>
Date: Tue, 08 Aug 2006 07:56:58 -0300

>could arrive earlier than one RTT after the rexmt was sent).

This makes perfect sense, of course. However, it wasn't clear to me 
from the draft.

I'd probably change the corresponding paragraph to:

"This ACK should be the acknowledgement elicited by the 
retransmission from step 1, one RTT after the retransmission (though 
it may arrive sooner in case Fast Retransmit has been triggered by 
network packet reordering, rather than by a loss event)"

Kindest regards,