[rmcat] Review of draft-ietf-rmcat-coupled-cc-03

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

Hi,

I have read through the draft, and consider it to be in good shape overall.  In particular, the descriptions in Sec. 6.1 regarding what information exchange is needed for making coupled congestion control work for NADA is clear.


Below are some further suggestions, mainly with the intention to further improve a reader's understand of merits of this work.


* In both abstract and introduction section, will be nice to explicitly point out what type of benefit one may expect from adopting coupled congestion control, instead of vaguely stating that "... behavior is improved". It became clearly later in the text that benefits may be in the form of reduced queuing delay and packet losses. Will be nice to call those out earlier in the draft as well.


* In Introduction, end of first paragraph, it is stated that the effect (of undesirable queuing delay) "is amplified when multiple congestion controlled connections traverse the same network bottleneck".  Why is the effect "amplified"?  It does not seem to be immediately clear to me (maybe only me?).


* Section 3, Limitations:  "... to eventually decide the transmission rate" => "... to eventually decide on the transmission rate"


* Section 4, Architecture Overview:  Can Figure 1 be a bit more specific in terms of what input/output each module takes?   The text provides some examples (e.g., that arrow from SBD to FSE denotes the Flow State Identifiers), but it was a bit hard to follow in conjunction with the figure.  Maybe it will be more clear by labeling the interfaces in the figure (e.g., a, b, c ...) and then describe each arrow explicitly?


* Still on Figure 1: As an architecture figure, this one omits how coupled congestion control interacts with congestion control all together.  My preference would be to also see in this figure a box representing the coupled-cc algorithm (e.g., those described in Sec. 5.3) and another set of boxes representing the individual cc algorithm (e.g., NADA/GCC), as well as arrows showing how information flows from one to the other.


* Again regarding Figure 1:  it is mentioned in the text right below that this assumes a single host. Does this entire document follow that assumption?  If so it may make sense to state that assumption even earlier in the text, maybe in Introduction?   Or, if the document potentially applies to multiple streams hosted by different physical senders (if I remember from previous discussions on this draft, that would be quite a tricky situation to handle), the authors can add a paragraph somewhere (maybe in Limitations?) to discuss implications of that extended scenario.


* Section 5.1 SBD: currently discussions of the tradeoff in various method of shared bottleneck detection only covers multiplexing-based and measurement-based.  Anything the authors want to mention regarding configuration-based approach?


Best,

Xiaoqing


________________________________
From: rmcat <[e-mail]> on behalf of Anna Brunstrom <[e-mail]>
Sent: Friday, September 23, 2016 4:53 AM
To: [e-mail]
Subject: [rmcat] RMCAT WGLC: draft-ietf-rmcat-coupled-cc-03: still accepting comments


Hi all,

As we did not get many reviews, we are extending the period for comments on this draft until Sunday. Please note that all types of feedback is useful.

The announcement for SCReAM will follow on Monday.

BR,
Anna

On 2016-09-07 01:03, Anna Brunstrom wrote:

This email announces a RMCAT Working Group Last Call (WGLC) on:

Coupled congestion control for RTP media
draft-ietf-rmcat-coupled-cc-03<https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/>

This WGLC will run for 2 weeks, ending at midnight US Eastern Time on Wednesday, September 21.  Comments should be sent to the [e-mail]<mailto:[e-mail]> list, although purely editorial comments may be sent directly to the authors at [e-mail]<mailto:[e-mail]> - if doing so, please cc: the WG chairs at [e-mail]<mailto:[e-mail]>.

We are looking for at least a couple of reviews during WGLC, so please help review the document.

Thanks,
Anna & Martin