Coupled Congestion Control for RTP Media
draft-ietf-rmcat-coupled-cc-09

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.