Subject: [rmcat] RMCAT WGLC: draft-ietf-rmcat-coupled-cc-03 - ends Sep 21

From: Anna Brunstrom <[email-masked]>
Date: Wed, 7 Sep 2016 01:03:28 +0200

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 [email-masked] 
list, although purely editorial comments may be sent directly to the 
authors at [email-masked] - if doing so, please 
cc: the WG chairs at [email-masked].

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

Thanks,
Anna & Martin

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 23 Sep 2016 11:53:33 +0200

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:
> Wednesday, September 21.  Comments should be sent to the 
> [email-masked] list, although purely editorial comments may be sent 
> directly to the authors at [email-masked] - if 
> doing so, please cc: the WG chairs at [email-masked].
>

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Mon, 26 Sep 2016 08:02:56 +0000

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 <[email-masked]> on behalf of Anna Brunstrom <[email-masked]>
Sent: Friday, September 23, 2016 4:53 AM
To: [email-masked]
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.

BR,
Anna

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 [email-masked]<mailto:[email-masked]> list, although purely editorial comments may be sent directly to the authors at [email-masked]<mailto:[email-masked]> - if doing so, please cc: the WG chairs at [email-masked]<mailto:[email-masked]>.

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

Thanks,
Anna & Martin

---

From: Safiqul Islam <[email-masked]>
Date: Mon, 26 Sep 2016 12:28:14 +0000

Hi Xiaoqing,

Thanks for reading our draft. We’ll incorporate your suggestions; it should be easy as they are all editorial. Please find our answers inline.

On 26. sep. 2016, at 10.02, Xiaoqing Zhu (xiaoqzhu) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Agree.

We’ll fix it as well. Thanks for the pointer.

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

Agree.

We agree that labeling is a good idea. We’ll extend the diagram to enhance clarity.

* 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?

Yes

 If so it may make sense to state that assumption even earlier in the text, maybe in Introduction?

yes, agree.

We’ll extend the text about configuration as well.

Thanks again.

Cheers,
Safiqul, Michael and Stein

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

Hi all,

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Tue, 27 Sep 2016 05:04:21 +0000

​Thanks for considering my review comments.  Looking forward to seeing the final version.

Best,

Xiaoqing

________________________________
From: Safiqul Islam <[email-masked]>
Sent: Monday, September 26, 2016 7:28 AM
To: Xiaoqing Zhu (xiaoqzhu)
Cc: [email-masked] WG; [email-masked]; Michael Welzl; Stein Gjessing
Subject: Re: [rmcat] Review of draft-ietf-rmcat-coupled-cc-03

Hi Xiaoqing,

Hi,

Agree.

Agree.

Yes

yes, agree.

Thanks again.

Cheers,

Hi all,