Coupled Congestion Control for Multipath Transport Protocols
RFC 6356

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

(Wesley Eddy; former steering group member) Yes

the authors should consider the comments sent by David Black in his TSVDIR review; a minor revision may be necessary in order to answer the main question raised.

(David Harrington; former steering group member) No Objection

(Gonzalo Camarillo; former steering group member) No Objection

(Pete Resnick; former steering group member) No Objection

(Peter Saint-Andre; former steering group member) No Objection

(Robert Sparks; former steering group member) No Objection

(Ron Bonica; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

(Sean Turner; former steering group member) No Objection

For the Security Considerations, I think maybe you meant to say something like:

This coupled congestion control algorithm defined in this draft adds no new security considerations to those found in [I-D.ford-mptcp-multiaddressed] and [RFC6181].  Detailed security analysis for the Multipath TCP protocol itself is included in [I-D.ford-mptcp-multiaddressed] and [RFC6181].

Instead of None followed by where the security considerations are found.

(Stephen Farrell; former steering group member) No Objection

I agree with Sean's comment.

I didn't have time to check the references but do they cover the case
where someone manipulates one link (e.g. dropping packets) to cause
more traffic on another link they can monitor or want to DoS? 

(Stewart Bryant; former steering group member) (was Discuss) No Objection

I know that the ASCII text that we use makes it very difficult to publish maths, but I found that the method of presenting the math chosen by the authors, particularly the math embedded in the paragraphs, and the absence of equation numbers made it extremely difficult to understand what they were saying.

I have the three worst examples below, but I would request that the authors work on the rest of the math to find a clearer way to present it.

=========

This is worse in my browser than in the text itself, but even so it is difficult to understand the equation

The formula to compute alpha is:

                                      cwnd_i
                                 max --------
                                  i         2
                                      rtt_i
             alpha = tot_cwnd * ----------------
                               /      cwnd_i \ 2
                               | sum ---------|
                               \  i   rtt_i  /

Please can a clearer specification of the equation be provided

=====

Hence, it is possible to compute alpha only once per drop according
   to the formula above, by replacing rtt_i with rtt_avg_i.

There were lots of formulii above

======

The following is just about readable.

For each ack received on subflow i, increase cwnd_i by min (
      (alpha*bytes_acked*mss_i/tot_cwnd)/alpha_scale ,
      bytes_acked*mss_i/cwnd_i )