Shared Bottleneck Detection for Coupled Congestion Control for RTP Media

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

(Spencer Dawkins) Yes

Comment (2018-04-02)
No email
send info
I'm somewhat confused about whether the intended scope for this mechanism is to detect bottleneck links shared by all flows, or only what's shared by RTP media flows. The Abstract seems clear about that, but I'm not seeing a similar statement about scope in the Introduction, unless I'm missing it. Perhaps it's worth repeating the statement from the Abstract in the Introduction? 

I agree with the last sentence in this paragraph, 

  The current Internet is unable to explicitly inform endpoints as to
   which flows share bottlenecks, so endpoints need to infer this from
   whatever information is available to them.  The mechanism described
   here currently utilizes packet loss and packet delay, but is not
   restricted to these.  As ECN becomes more prevalent it too will
   become a valuable base signal.

and I'd believe that ECN helps identify path bottlenecks, but I'm not understanding how ECN helps identify shared bottlenecks, and I think that's the point being made here.

(Mirja Kühlewind) Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Alissa Cooper No Objection

Benjamin Kaduk No Objection

Comment (2018-04-04)
No email
send info
Is there an end condition for the experiment, to determine whether it is successful or not?

(Suresh Krishnan) No Objection

(Eric Rescorla) No Objection

(Adam Roach) No Objection

Comment (2018-04-04)
No email
send info
Thanks for everyone's work on this document, and especially to those who ran the
preliminary experiments. This sounds like an interesting technique. I have two
minor comments.



>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "OPTIONAL" in this document are to be interpreted as described in BCP
>  14 [RFC2119] RFC2119 [RFC2119] RFC8174 [RFC8174] when, and only when,
>  they appear in all capitals, as shown here.

This is almost, but not quite, the boilerplate defined in RFC 8174. Please
consider fixing it.


§2.1 says "Usually M=N", while §2.2 recommends N=50 and M=30. These statements
seem in conflict.

Martin Vigoureux No Objection