A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP
draft-ietf-tcpm-3517bis-02

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

(Barry Leiba; former steering group member) Yes

Yes (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.

(Ron Bonica; former steering group member) Yes

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

(Wesley Eddy; former steering group member) Yes

Yes ()
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (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.

(Benoît Claise; former steering group member) No Objection

No Objection (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.

(Brian Haberman; former steering group member) No Objection

No Objection (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?

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection (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.

(Pete Resnick; former steering group member) No Objection

No Objection ()
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ()
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (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

(Sean Turner; former steering group member) No Objection

No Objection ()
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (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.

(Stewart Bryant; former steering group member) No Objection

No Objection (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