Coupled congestion control for RTP media
Note: This ballot was opened for revision 06 and is now closed.
Spencer Dawkins Yes
Comment (2017-09-12 for -06)
I'm really glad to see this draft going forward. I do have comments, but they're mostly about clarity. It would be good to expand NADA as "Network-Assisted Dynamic Adapation (NADA)" in the Abstract. In the first paragraph of the Introduction, When there is enough data to send, a congestion controller must increase its sending rate until the path's capacity has been reached; depending on the controller, sometimes the rate is increased further, until packets are ECN-marked or dropped. This process inevitably creates undesirable queuing delay when multiple congestion controlled connections traverse the same network bottleneck. I'm not sure about "must increase its sending rate", but ignoring that, I think this paragraph is really saying When there is enough data to send, a congestion controller attempts to increase its sending rate until the path's capacity has been reached. Some controllers detect path capacity by increasing the sending rate further, until packets are ECN-marked or dropped, and then decreasing its sending rate until that stops happening. This process inevitably creates undesirable queuing delay when multiple congestion-controlled connections traverse the same network bottleneck, and each connection overshoots the path capacity as it determines its sending rate. Do the right thing, of course. I'm wondering if https://tools.ietf.org/html/rfc7478 is the right reference for rtcweb in the Introduction, since even the Abstract of that RFC says (paraphrasing) "this is what we thought about RTCWeb early in the process, and the document hasn't been updated as we worked on RTCWeb". I know that https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ has been in "Revised I-D Needed" substate for some time, but that might be more appropriate. Do the right thing, of course. I understand why "Shared bottlenecks do not change quickly:" is a limitation, but I'm not sure I understand why "Sender-side only:" is listed as a limitation in Section 3 - I've seen "sender-side only" as a strength for most of the time I've worked in TSV. It's worth pointing out as an attribute, and maybe even as a design goal, but that's not the way it's presented here. I'm a little bit confused by This document describes both active and passive versions, however the passive version is put into the appendix as it is extremely experimental. in an Experimental RFC. Perhaps the point is that the passive version is less mature, or has received less analysis, or something? But I'm not sure from reading this whether you want people to experiment with the passive version, which would be the point of including it in an Experimental RFC. And ... when I make it all the way to Appendix C, I find While the passive algorithm works better for congestion controls with RTT-independent convergence, it can still produce oscillations on short time scales. The algorithm described below is therefore considered as highly experimental and not safe to deploy outside of testbed environments. which would have been good information to include in Section 4! At a minimum, s/the appendix/Appendix C/, because there are multiple appendices ... I'm struggling a bit with this text: Implementations can take various forms: for instance, all the elements in the figure could be implemented within a single application, thereby operating on flows generated by that application only. Another alternative could be to implement both the FSE and SBD together in a separate process which different applications communicate with via some form of Inter-Process Communication (IPC). Such an implementation would extend the scope to flows generated by multiple applications. The FSE and SBD could also be included in the Operating System kernel. because I'm reading ahead to Section 5.3, which says Below, two example algorithms are described. While other algorithms could be used instead, the same algorithm must be applied to all flows. so, I'm wondering if there's a similar restriction that applies to how many implementations can co-exist with good results - if some of my flows are using an implementation that is specific to an application, others are using an implementation that's in a separate process, and still others are using an implementation within the OS kernel, is that supposed to work well? If not, that's worth mentioning in Section 4. I'm not sure what "the latter method" is in this text: 1. From multiplexing: it can be based on the simple assumption that packets sharing the same five-tuple (IP source and destination address, protocol, and transport layer port number pair) and having the same values for the Differentiated Services Code Point (DSCP) and the ECN field in the IP header are typically treated in the same way along the path. The latter method is the only one specified in this document: SBD MAY consider all flows that use the same five-tuple, DSCP and ECN field value to belong to the same FG. Did I miss other methods being previously mentioned? It looks like this is referring to "2. Via configuration" and "3. From measurements", but they haven't been mentioned at this point - so, "the latter method" probably isn't what you want to say. "This method" might be clearer.
Mirja Kühlewind Yes
(Alia Atlas) No Objection
Deborah Brungard No Objection
Ben Campbell No Objection
Comment (2017-09-13 for -06)
Please expand "NADA" in the abstract.
(Benoit Claise) No Objection
Comment (2017-09-14 for -06)
Editorial: age 1: The first sentence: “When multiple congestion controlled RTP sessions...”. I suggest expanding the “RTP”, like Real-time Transport Protocol (RTP), since it first appear in the document. Page 1: The last sentence: “It specifies how to apply the method for the NADA congestion control...”. I suggest expanding the “NADA”, like Network-Assisted Dynamic Adaptation (NADA). The reason same to above item. Page 3: The first paragraph: “sometimes the rate is increased further, until packets are ECN-marked or dropped.” I suggest adding a reference to help the readers understanding “ECN-marked”. Page 3: Suggest adding a term definition: “Flow State Identifiers (FSIs)” which be used in section 4 but not be introduced in the section 2 Definitions. Page 11: 6.1 NADA -- " Network-Assisted Dynamic Adapation (NADA) [I-D.ietf-rmcat-nada] is a congestion control scheme for rtcweb." I suggest adding a reference or some sentence to help the readers understand the “rtcweb”. A run of idnits revealed there were 0 error, 3 warning and 2 comments: Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (March 28, 2017) is 140 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '<CODE BEGINS>' and '<CODE ENDS>' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-rmcat-nada-03 == Outdated reference: A later version (-05) exists of draft-ietf-rmcat-eval-test-04 == Outdated reference: A later version (-08) exists of draft-ietf-rmcat-sbd-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above.
Suresh Krishnan No Objection
Terry Manderson No Objection
(Kathleen Moriarty) No Objection
Alvaro Retana No Objection
Adam Roach No Objection
Comment (2017-09-13 for -06)
The first line of Appendix B uses the word "connections" -- did you mean "flows"?