Proportional Rate Reduction for TCP
draft-ietf-tcpm-proportional-rate-reduction-04

I appreciate this work and the open presentations of the results of
experimentation.  However, the document left me feeling that this was an
Informational report on an experiment rather than an Experimental
document where you wanted the IETF to participate in the Experiment.

The former is very useful, but would need the status to be changed to
Informational.  The latter, would, IMHO be a far better thing.  To get
there you need to describe the experiment you want to be undertaken,
the limits and risks (can it be done on the Open Internet? do both ends
need to know that the experiment is happening? are there interactions
with other algorithms in use through congested areas?), what feedback
you are looking for, and how/when the experiment will be judged.  While
this sort of explanation has not been conventionally present in
Experimental RFCs, I believe including it makes life simpler and clearer
for everyone.

See Nevil's Brownlee's feedback (OPS Directorate)

- - - -

1. Is the specification complete?  Can multiple interoperable
     implementations be built based on the specification?

The Proportional Rate algorithm and two reduction bound algorithms
are described in some detail, with C source code and explanations
of what the variables represent.  I believe there's enough detail
to implement PRR-SSRB (PRR with Slow Start Reduction Bound) from
this draft.

2. Is the proposed specification deployable?  If not, how could it be
     improved?

The draft doesn't consider this, however I see no reason why a TCP
sender using PRR would not interwork properly with other TCP
implementations, e.g. TCP Reno.  It would be good to see some comment
in the draft to say that, or - better - reporting on such an
interoperability test.

3. Does the proposed approach have any scaling issues that could
     affect usability for large scale operation?

No.

4. Are there any backward compatibility issues?

No, but see (2) above.

5. Do you anticipate any manageability issues with the specification?

Since this draft proposes an update to TCP, it will be implemented
in Operating Systems.  Site managers will need to be aware of which OS
versions that use it, as one more thing to check on should any
TCP interoperation problems manifest themselves.

6. Does the specification introduce new potential security risks or
     avenues for fraud?

No.

A few typos:

- Early in the draft PPR is often used when it should be PRR
- last para page 4:
    missing comma, s/of RFC 3517 we are/of RFC 3517, we are/
    s/General discussions algorithms/General discussions of algorithms/
- section 4 last para:
    s/Bound in very appealing/Bound is very appealing/

The protocol itself seems buried in the definition of DeliveredData in section 2, and the pseudo-code in section 3. I really think you should separate out the description of the protocol. Getting independent interoperable implementations from the current document is likely to be difficult.

I agree with Adrian that this needs a bit more to be Experimental. The information in the document is helpful, but probably overkill for a specification of this sort.

  The Abstract is quite long.  I propose a shorter version:

   This document describes an experimental Proportional Rate Reduction
   (PPR) algorithm as an alternative to the traditional Fast Recovery
   and Rate Halving algorithms.  These algorithms determine the amount
   of data sent by TCP during loss recovery.  PRP minimizes excess
   window adjustments and the actual window size will be as close as
   possible to the window size determined by the congestion control
   algorithm.

- "   RFC 793: snd.una":  too terse 

- Is it PRR+SSRB or PRR-SSRB? Using only one consistently
is better.

other typos:
p3, s/slight difference/slight differences/
p3, s/discussions algorithms/discussions of algorithms/

I agree with Adrian this has more of an "Informational" feel about it.