A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP
RFC 6675

Note: This ballot was opened for revision 02 and is now closed.

(Ron Bonica) Yes

Comment (2012-04-09)
No email
send info
Please run this document through the NIT checker before publication.

(Wesley Eddy) Yes

Barry Leiba Yes

Comment (2012-04-02)
No email
send info
This seems a good, clear document.  Thanks for a thought-out Security Considerations section, as well.

I have one question, as a non-expert on this topic:
All four functions in section 4 are "SHOULD implement."  Can a meaningful implementation really be done if NONE of them are included?  If so, fine.  If not, maybe a few more words in the first paragraph would be useful, explaining under what conditions it's important to include them or makes sense to leave them out.

(Stewart Bryant) No Objection

Comment (2012-04-10)
No email
send info
It would be helpful to those searching for information if the abstract noted that this document revised RFC 3517

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2012-04-12)
No email
send info
I have no objection to the publication of this document.

One comment from Chris LILJENSTOLPE, part of the OPS-Directorate review.
I wish the authors had selected some other state variable name other than DupAck for the multiple SACK counter.  While it is well described in the draft, on first read it is really not a Duplicate ACK counter, but a multiple SACK counter (number of SACKs between covering ACKs).  While useful, it would have been more intuitive to call it MultSack or some such.  I do not propose editing the draft just for this purpose, but if another version of the draft is required, it may make the digestion of the material a little easier.

I leave up to you to act on his feedback.

Regards, Benoit.

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

Comment (2012-04-06)
No email
send info
I have no objection to the publication of this document.Just a couple of nits.

---

Isn't [PF01] rather old to be cited as "evidence that hosts are not
using the SACK information when making retransmission and congestion
control decisions"?

I guess this was good evidence when 3517 was first written, but maybe a
different form of words is called for now? Perhapswe don't even need
the evidence to motivte this work since it is now established.

---

Section 1

   A
   summary of the changes between this document and [RFC3517] can be
   found in Section 9.

Pardon my pedantry, but the changes are between 3517 and this document.

(Stephen Farrell) No Objection

Comment (2012-04-10)
No email
send info
"Pipe" definition says "The algorithm" is often 
referred to as the pipe alg. That's a little unclear, maybe
better to say "The algorithm defined here...." and if
that is the case, to also put that in the abstract
and intro just to make it easier for someone who does
call it that to find the RFC.

(Brian Haberman) No Objection

Comment (2012-04-03)
No email
send info
Section 7 talks about the effectiveness of this approach when paired with TCP Reno, but I do not see any discussion of possible interactions with other TCP congestion control algorithms.  Has this re-transmission algorithm been tested with other congestion control algorithms?

(Russ Housley) No Objection

Comment (2012-04-09)
No email
send info
  The Gen-ART Review by Ben Campbell on 4-Apr-2012 suggests some
  improvements.  Please consider them.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07319.html

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

Comment (2012-04-02)
No email
send info
An editorial:
It it is relative short document, but recents RFCs seems all to have a table of contents, which is missing in this draft.

(Sean Turner) No Objection