Shared Bottleneck Detection for Coupled Congestion Control for RTP Media
draft-ietf-rmcat-sbd-11
Yes
(Mirja Kühlewind)
No Objection
(Alissa Cooper)
(Ben Campbell)
(Deborah Brungard)
(Eric Rescorla)
(Martin Vigoureux)
(Suresh Krishnan)
Note: This ballot was opened for revision 10 and is now closed.
Mirja Kühlewind Former IESG member
Yes
Yes
(for -10)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2018-04-02)
Unknown
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.
Adam Roach Former IESG member
No Objection
No Objection
(2018-04-04)
Unknown
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. --------------------------------------------------------------------------- §2: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "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.
Alissa Cooper Former IESG member
No Objection
No Objection
()
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
()
Unknown
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2018-04-04)
Unknown
Is there an end condition for the experiment, to determine whether it is successful or not?
Deborah Brungard Former IESG member
No Objection
No Objection
()
Unknown
Eric Rescorla Former IESG member
No Objection
No Objection
()
Unknown
Martin Vigoureux Former IESG member
No Objection
No Objection
()
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
()
Unknown