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

"Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu@cisco.com> Tue, 27 September 2016 05:04 UTC

Return-Path: <xiaoqzhu@cisco.com>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AEA12B337 for <rmcat@ietfa.amsl.com>; Mon, 26 Sep 2016 22:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.836
X-Spam-Level:
X-Spam-Status: No, score=-16.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuE3PLIS6Sqb for <rmcat@ietfa.amsl.com>; Mon, 26 Sep 2016 22:04:23 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63FF812B3E6 for <rmcat@ietf.org>; Mon, 26 Sep 2016 22:04:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30749; q=dns/txt; s=iport; t=1474952663; x=1476162263; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sqmAKMUHlP+axrkB2O6SOE8G7feo1DfDql07A39GX+4=; b=JiOCJzb19rwe7NAI9VAl0XMaSfJ2YVqFW7xkU/SqO0cM6XOuSnQw9zR1 8jpS1hIveUBDqrSTBQbv/y3EKz1zAviRXLEnBzbPQP5KMMAwz6gk6rXXt 78Q4wXo94CQuwgIz4xYXcL8f8fvk7OIjjNbkRunkWfEFtOAx2QprNa5nB Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0COBQDs/OlX/5FdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgwk0AQEBAQEeV3wHhg2HH5sUAQQBkDWCBCSFegIcgUY4FAECAQEBAQEBAV4nhGEBAQEEI1YQAgEIEQEDAQEKFwcDAgICDSMUAwYIAgQOBYhLDrMSjG0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYY3hFSEFhEBJA8ICA+CToJaBYwxh22FWAGGJolDgW6EZIM3hWKMa4N7AR42GoJ/HIFQcoVAgSB/AQEB
X-IronPort-AV: E=Sophos;i="5.30,403,1470700800"; d="scan'208,217";a="155571703"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2016 05:04:22 +0000
Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u8R54MQu000902 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Sep 2016 05:04:22 GMT
Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Sep 2016 00:04:21 -0500
Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1210.000; Tue, 27 Sep 2016 00:04:21 -0500
From: "Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu@cisco.com>
To: Safiqul Islam <safiquli@ifi.uio.no>
Thread-Topic: [rmcat] Review of draft-ietf-rmcat-coupled-cc-03
Thread-Index: AQHSF8d3H8ZGmp5PT0+qTZf8ESW8VKCMBykAgADCWv0=
Date: Tue, 27 Sep 2016 05:04:21 +0000
Message-ID: <1474952661825.64052@cisco.com>
References: <61fd6536-366b-e3c9-0d76-162059d74a54@kau.se> <42edeb66-6bd9-cba8-9bd9-dc8c1980ba1d@kau.se> <1474876976118.84485@cisco.com>, <D7786F9E-A4CE-429C-AB21-B523FA7D2136@ifi.uio.no>
In-Reply-To: <D7786F9E-A4CE-429C-AB21-B523FA7D2136@ifi.uio.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.25.142]
Content-Type: multipart/alternative; boundary="_000_147495266182564052ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/50PBItE-hewxfrzLucIlGuzMkjc>
Cc: "rmcat@ietf.org WG" <rmcat@ietf.org>, Michael Welzl <michawe@ifi.uio.no>, "anna.brunstrom@kau.se" <anna.brunstrom@kau.se>, Stein Gjessing <steing@ifi.uio.no>
Subject: Re: [rmcat] Review of draft-ietf-rmcat-coupled-cc-03
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2016 05:04:26 -0000

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


Best,

Xiaoqing


________________________________
From: Safiqul Islam <safiquli@ifi.uio.no>
Sent: Monday, September 26, 2016 7:28 AM
To: Xiaoqing Zhu (xiaoqzhu)
Cc: rmcat@ietf.org WG; anna.brunstrom@kau.se; Michael Welzl; Stein Gjessing
Subject: Re: [rmcat] Review of draft-ietf-rmcat-coupled-cc-03

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) <xiaoqzhu@cisco.com<mailto:xiaoqzhu@cisco.com>> wrote:

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.


Agree.


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

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.


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


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.


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


We’ll extend the text about configuration as well.


Thanks again.

Cheers,
Safiqul, Michael and Stein





________________________________
From: rmcat <rmcat-bounces@ietf.org<mailto:rmcat-bounces@ietf.org>> on behalf of Anna Brunstrom <anna.brunstrom@kau.se<mailto:anna.brunstrom@kau.se>>
Sent: Friday, September 23, 2016 4:53 AM
To: rmcat@ietf.org<mailto:rmcat@ietf.org>
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 rmcat@ietf.org<mailto:rmcat@ietf.org> list, although purely editorial comments may be sent directly to the authors at draft-ietf-rmcat-coupled-cc@ietf.org<mailto:draft-ietf-rmcat-coupled-cc@ietf.org> - if doing so, please cc: the WG chairs at rmcat-chairs@tools.ietf.org<mailto:rmcat-chairs@tools.ietf.org>.
We are looking for at least a couple of reviews during WGLC, so please help review the document.
Thanks,
Anna & Martin