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

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.

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.

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?

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.

  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

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

It would be helpful to those searching for information if the abstract noted that this document revised RFC 3517