[rmcat] Spencer Dawkins' Yes on draft-ietf-rmcat-coupled-cc-06: (with COMMENT)
Spencer Dawkins <firstname.lastname@example.org> Tue, 12 September 2017 14:31 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BC6132332; Tue, 12 Sep 2017 07:31:03 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Spencer Dawkins <email@example.com>
To: "The IESG" <firstname.lastname@example.org>
Cc: email@example.com, Colin Perkins <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com
Date: Tue, 12 Sep 2017 07:31:03 -0700
Subject: [rmcat] Spencer Dawkins' Yes on draft-ietf-rmcat-coupled-cc-06: (with COMMENT)
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 14:31:03 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-rmcat-coupled-cc-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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.
- [rmcat] Spencer Dawkins' Yes on draft-ietf-rmca... Spencer Dawkins