From nobody Mon Sep 11 08:43:39 2017 Return-Path: X-Original-To: rmcat@ietf.org Delivered-To: rmcat@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6901326FE; Mon, 11 Sep 2017 08:43:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: rmcat@ietf.org, ietf@ietf.org, draft-ietf-rmcat-coupled-cc.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150514460458.9791.14186175950174051912@ietfa.amsl.com> Date: Mon, 11 Sep 2017 08:43:24 -0700 Archived-At: Subject: [rmcat] Genart last call review of draft-ietf-rmcat-coupled-cc-06 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 15:43:25 -0000 Reviewer: Matthew Miller Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-rmcat-coupled-cc-06 Reviewer: Matthew A. Miller Review Date: 2017-09-11 IETF LC End Date: 2017-08-28 IESG Telechat date: 2017-09-14 Summary: This document is ready to be published as Experimental; I have some nits below that addressing them would help with the readability. Major issues: NONE Minor issues: NONE Nits/editorial comments: * In Section 2. "Definitions", the second sentence detailing the term "Flow" is awkward. I think "or" can be added between "connection," and "an RTP stream" to correct it? """ It could, for example, be a transport layer connection, or an RTP stream [RFC7656], whether or not this RTP stream is multiplexed onto an RTP session with other RTP streams. """ * In Section 4. "Architectural overview", the last paragraph has an awkwardly-phrased sentence. I suggest the following sentence be changed from: """ It does, for instance, not define how many bits must be used to represent FSIs, or in which way the entities communicate. """ to the following: """ It does not, for instance, define how many bits must be used to represent FSIs, or in which way the entities communicate. """ From nobody Mon Sep 11 08:57:04 2017 Return-Path: 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 E039313292D for ; Mon, 11 Sep 2017 08:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 RmAKTx7pQJyE for ; Mon, 11 Sep 2017 08:56:56 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B555132D8F for ; Mon, 11 Sep 2017 08:56:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=IXSWwSN1dssxxh8sIetGo32DLm44ZEeN+5JnqiuJDl8dA3t4cp0DYgkvF9ZeLl3jV93sLdHhPUqL1KDkQzeRWWN1yb4JXPKKUWOeFib8erdkJMvXdZllEvFL/a38hCX8cHR41h03JM/0z0AjTBtEyhLszAVvjNqYs6rweQhWVfs=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 17479 invoked from network); 11 Sep 2017 17:50:12 +0200 Received: from pd9e11f83.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.31.131) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 Sep 2017 17:50:11 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <150514460458.9791.14186175950174051912@ietfa.amsl.com> Date: Mon, 11 Sep 2017 17:50:10 +0200 Cc: gen-art@ietf.org, rmcat@ietf.org, ietf@ietf.org, draft-ietf-rmcat-coupled-cc.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150514460458.9791.14186175950174051912@ietfa.amsl.com> To: Matthew Miller X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170911155012.17471.98598@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [rmcat] Genart last call review of draft-ietf-rmcat-coupled-cc-06 X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 15:56:58 -0000 Thanks for the review and the nit. We will address these in the next = version or as editor comments! Mirja > Am 11.09.2017 um 17:43 schrieb Matthew Miller = : >=20 > Reviewer: Matthew Miller > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-rmcat-coupled-cc-06 > Reviewer: Matthew A. Miller > Review Date: 2017-09-11 > IETF LC End Date: 2017-08-28 > IESG Telechat date: 2017-09-14 >=20 > Summary: >=20 > This document is ready to be published as Experimental; I have some = nits > below that addressing them would help with the readability. >=20 > Major issues: NONE >=20 > Minor issues: NONE >=20 > Nits/editorial comments: >=20 > * In Section 2. "Definitions", the second sentence detailing the term > "Flow" is awkward. I think "or" can be added between "connection," = and > "an RTP stream" to correct it? >=20 > """ > It could, for example, be a transport layer connection, or an RTP > stream [RFC7656], whether or not this RTP stream is multiplexed > onto an RTP session with other RTP streams. > """ >=20 > * In Section 4. "Architectural overview", the last paragraph has an > awkwardly-phrased sentence. I suggest the following sentence be = changed from: > """ > It does, for instance, not define how many bits must be used to = represent > FSIs, or in which way the entities communicate. > """ >=20 > to the following: > """ > It does not, for instance, define how many bits must be used to = represent > FSIs, or in which way the entities communicate. > """ >=20 >=20 From nobody Tue Sep 12 07:31:04 2017 Return-Path: X-Original-To: rmcat@ietf.org Delivered-To: rmcat@ietfa.amsl.com 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) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-rmcat-coupled-cc@ietf.org, Colin Perkins , rmcat-chairs@ietf.org, csp@csperkins.org, rmcat@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150522666321.4656.13121533235476408007.idtracker@ietfa.amsl.com> Date: Tue, 12 Sep 2017 07:31:03 -0700 Archived-At: Subject: [rmcat] Spencer Dawkins' Yes on draft-ietf-rmcat-coupled-cc-06: (with COMMENT) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. From nobody Wed Sep 13 13:09:47 2017 Return-Path: X-Original-To: rmcat@ietf.org Delivered-To: rmcat@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B0A132D45; Wed, 13 Sep 2017 13:09:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-rmcat-coupled-cc@ietf.org, Colin Perkins , rmcat-chairs@ietf.org, csp@csperkins.org, rmcat@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150533338075.30471.13189956755147482737.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 13:09:40 -0700 Archived-At: Subject: [rmcat] Ben Campbell's No Objection on draft-ietf-rmcat-coupled-cc-06: (with COMMENT) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 20:09:41 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rmcat-coupled-cc-06: No Objection 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: ---------------------------------------------------------------------- Please expand "NADA" in the abstract. From nobody Wed Sep 13 22:59:51 2017 Return-Path: X-Original-To: rmcat@ietf.org Delivered-To: rmcat@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3190F1321DE; Wed, 13 Sep 2017 22:59:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-rmcat-coupled-cc@ietf.org, Colin Perkins , rmcat-chairs@ietf.org, csp@csperkins.org, rmcat@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150536878919.12683.14759725309211505734.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 22:59:49 -0700 Archived-At: Subject: [rmcat] Adam Roach's No Objection on draft-ietf-rmcat-coupled-cc-06: (with COMMENT) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 05:59:49 -0000 Adam Roach has entered the following ballot position for draft-ietf-rmcat-coupled-cc-06: No Objection 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: ---------------------------------------------------------------------- The first line of Appendix B uses the word "connections" -- did you mean "flows"? From nobody Thu Sep 14 02:30:00 2017 Return-Path: X-Original-To: rmcat@ietf.org Delivered-To: rmcat@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED58E1329C8; Thu, 14 Sep 2017 02:29:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-rmcat-coupled-cc@ietf.org, Colin Perkins , rmcat-chairs@ietf.org, csp@csperkins.org, rmcat@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150538139894.12621.17177152345859451451.idtracker@ietfa.amsl.com> Date: Thu, 14 Sep 2017 02:29:58 -0700 Archived-At: Subject: [rmcat] Benoit Claise's No Objection on draft-ietf-rmcat-coupled-cc-06: (with COMMENT) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 09:29:59 -0000 Benoit Claise has entered the following ballot position for draft-ietf-rmcat-coupled-cc-06: No Objection 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: ---------------------------------------------------------------------- Editorial: age 1: The first sentence: “When multiple congestion controlled RTP sessions...”. I suggest expanding the “RTP”, like Real-time Transport Protocol (RTP), since it first appear in the document. Page 1: The last sentence: “It specifies how to apply the method for the NADA congestion control...”. I suggest expanding the “NADA”, like Network-Assisted Dynamic Adaptation (NADA). The reason same to above item. Page 3: The first paragraph: “sometimes the rate is increased further, until packets are ECN-marked or dropped.” I suggest adding a reference to help the readers understanding “ECN-marked”. Page 3: Suggest adding a term definition: “Flow State Identifiers (FSIs)” which be used in section 4 but not be introduced in the section 2 Definitions. Page 11: 6.1 NADA -- " Network-Assisted Dynamic Adapation (NADA) [I-D.ietf-rmcat-nada] is a congestion control scheme for rtcweb." I suggest adding a reference or some sentence to help the readers understand the “rtcweb”. A run of idnits revealed there were 0 error, 3 warning and 2 comments: Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (March 28, 2017) is 140 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-rmcat-nada-03 == Outdated reference: A later version (-05) exists of draft-ietf-rmcat-eval-test-04 == Outdated reference: A later version (-08) exists of draft-ietf-rmcat-sbd-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. From nobody Fri Sep 15 07:23:10 2017 Return-Path: X-Original-To: rmcat@ietf.org Delivered-To: rmcat@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD0C12421A; Fri, 15 Sep 2017 07:23:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rmcat@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150548538918.2933.9081846375430408288@ietfa.amsl.com> Date: Fri, 15 Sep 2017 07:23:09 -0700 Archived-At: Subject: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-07.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 14:23:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques WG of the IETF. Title : Coupled congestion control for RTP media Authors : Safiqul Islam Michael Welzl Stein Gjessing Filename : draft-ietf-rmcat-coupled-cc-07.txt Pages : 26 Date : 2017-09-15 Abstract: When multiple congestion controlled Real-time Transport Protocol (RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications. It specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm, and provides suggestions on how to apply it to other congestion control algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rmcat-coupled-cc-07 https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-coupled-cc-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-coupled-cc-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 18 09:57:05 2017 Return-Path: X-Original-To: rmcat@ietf.org Delivered-To: rmcat@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE93F1342AF; Mon, 18 Sep 2017 09:56:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rmcat-chairs@ietf.org, The IESG , Colin Perkins , rmcat@ietf.org, draft-ietf-rmcat-coupled-cc@ietf.org, ietf@kuehlewind.net, csp@csperkins.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <150575379470.15563.10480933132991639869.idtracker@ietfa.amsl.com> Date: Mon, 18 Sep 2017 09:56:34 -0700 Archived-At: Subject: [rmcat] Document Action: 'Coupled congestion control for RTP media' to Experimental RFC (draft-ietf-rmcat-coupled-cc-07.txt) X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 16:56:38 -0000 The IESG has approved the following document: - 'Coupled congestion control for RTP media' (draft-ietf-rmcat-coupled-cc-07.txt) as Experimental RFC This document is the product of the RTP Media Congestion Avoidance Techniques Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-coupled-cc/ Technical Summary The RMCAT working group is developing congestion control schemes for use with RTP. When multiple such congestion controlled RTP flows traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications. It specifies how to apply the method for the NADA congestion control algorithm, and provides suggestions on how to apply it to other congestion control algorithms. Working Group Summary The draft has been under development in the working group for some years. Much of the time was taken waiting for the candidate congestion control algorithms to stabilise, mapping the algorithms to the mechanisms given in this draft, and deciding which congestion control algorithms should be supported. The coupled congestion control algorithm itself has proved reasonably stable. The draft discusses how to apply coupled congestion control to NADA and Google Congestion Control. The mapping to NADA is in the main body of the draft, since NADA is nearing working group last call and believed stable. The mapping for Google Congestion Control is in an appendix, since Google Congestion Control is not yet finalised. There is no mapping for SCReAM at this time, but one could be added later if there was interest in doing so (nothing in SCReAM should prevent this). Overall, the working group process has been relatively smooth, although not rapid. The main issue of contention was the choice of congestion control algorithm to which the mechanism should be applied - based on the maturity of the candidate congestion control algorithms, and the relative importance the authors of the candidates placed on coupled congestion control. Document Quality The algorithm has been implemented in simulations and emulated testbeds. This is appropriate for an experimental protocol of this type, and meets the usual community evaluation standards for transport protocol research. The draft has been reviewed by some authors of each candidate congestion control algorithm, with Xiaoqing Zhu and Stefan Holmer providing detailed reviews and advice on integration with the congestion control proposals. The draft is well written, and the mechanism is clearly specified. There is no need for MIB Doctor, Media Type, or other expert review, since the proposed mechanism relies only on common RTP features and parameters that can be directly measured by the end-point using the mechanism. Personnel The document shepherd is Colin Perkins. The responsible AS is Mirja Kühlewind. From nobody Thu Sep 28 14:36:12 2017 Return-Path: X-Original-To: rmcat@ietf.org Delivered-To: rmcat@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 098DA1349C9; Thu, 28 Sep 2017 14:36:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rmcat@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150663456501.27767.1526687431255447082@ietfa.amsl.com> Date: Thu, 28 Sep 2017 14:36:05 -0700 Archived-At: Subject: [rmcat] I-D Action: draft-ietf-rmcat-nada-05.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 21:36:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques WG of the IETF. Title : NADA: A Unified Congestion Control Scheme for Real-Time Media Authors : Xiaoqing Zhu Rong Pan Michael A. Ramalho Sergio Mena de la Cruz Paul E. Jones Jiantao Fu Stefano D'Aronco Filename : draft-ietf-rmcat-nada-05.txt Pages : 25 Date : 2017-09-28 Abstract: This document describes NADA (network-assisted dynamic adaptation), a novel congestion control scheme for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from explicit congestion notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays and packet losses instead. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rmcat-nada-05 https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-nada-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-nada-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 28 14:50:27 2017 Return-Path: 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 C735B134466 for ; Thu, 28 Sep 2017 14:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 VCzeDUqJcO4D for ; Thu, 28 Sep 2017 14:50:24 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE30A132F2C for ; Thu, 28 Sep 2017 14:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3936; q=dns/txt; s=iport; t=1506635423; x=1507845023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j7UJ2aj+Q7eKcko4AmBhJub4MDK31QfH04d+0BPMHGA=; b=MkLw6dVqwGG4UeEPa42dsPy21fhRMX5pQTIgKGoAeiEPsguznZxtaMh/ OuOPqrwXmvvxQSE83RoUXOhdKy4PBJLmMbaoB91COvEaJnZwF9LD+ogd4 tNDkoGZN8fFSgSD8qwQ9FmYs0rKwCAwz0CWds2H6l6y2Le0rgyQiZnBWs o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAQBXbc1Z/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1xkbicHhj2XM4F2hCABApQaCiOFGAKEJVcBAgEBAQEBAmsdC4U?= =?us-ascii?q?YAQEBAQN5EAIBCBEEAQEKJQ8jHQgCBA4FijEQqS+LRAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2DK4ICgVGBaoMogzKBUoVzBZIIjyACh1yNAoITW4UTiwWVIAIRGQG?= =?us-ascii?q?BOAFXgQ54FR+HR3aHdIEQAQEB?= X-IronPort-AV: E=Sophos;i="5.42,451,1500940800"; d="scan'208";a="10156580" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 21:50:23 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8SLoMkP022837 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Sep 2017 21:50:23 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 28 Sep 2017 16:50:22 -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.1320.000; Thu, 28 Sep 2017 16:50:22 -0500 From: "Xiaoqing Zhu (xiaoqzhu)" To: "rmcat@ietf.org" CC: "Flohr, Julius" Thread-Topic: [rmcat] I-D Action: draft-ietf-rmcat-nada-05.txt Thread-Index: AQHTOKKFInfrUOMBjkCYyD3VUVv3ug== Date: Thu, 28 Sep 2017 21:50:22 +0000 Message-ID: <1506635454282.84079@cisco.com> References: <150663456501.27767.1526687431255447082@ietfa.amsl.com> In-Reply-To: <150663456501.27767.1526687431255447082@ietfa.amsl.com> 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.152.245.120] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-nada-05.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 21:50:26 -0000 Hi Everyone, =0A= =0A= We have just updated the NADA draft with some minor algorithmic changes bas= ed on the input from Julius Flohr. The changes are concentrated on Sec.4.2= (regarding how NADA behaves in the presence of loss), and can be summarize= d as follows: =0A= =0A= * Revised the criteria for determining when to perform non-linear warping: = instead of abiding by a fixed expiration time (TEXP) as in the previous ver= sion, we now self-adapt this expiration time as multiples of the average pa= cket loss intervals; =0A= =0A= * Recommended linear transition between warped and non-warped values of que= uing delay during the transitional period switching from loss-based back to= delay-based; =0A= =0A= * Revised the loss penalty function from linear to quadratic with respect t= o observed packet loss ratio. Also, for ease of understanding, revised the = formula to anchor around a reference packet loss ratio so the scaling facto= r can be kept dimensionless. =0A= =0A= Basically, those changes are introduced to make the behavior of NADA more r= obust in the presence of loss-based flows (e.g., conventional TCP, as in RM= CAT test case 5.6). We have implemented them in our ns3 reference code and = verified their performance for all existing test cases. Still pending effo= rts on testing this out in Julius' independent implementation on omnet (we = are working together on this). =0A= =0A= Best regards,=0A= Xiaoqing=0A= =0A= =0A= ________________________________________=0A= From: rmcat on behalf of internet-drafts@ietf.org = =0A= Sent: Thursday, September 28, 2017 4:36 PM=0A= To: i-d-announce@ietf.org=0A= Cc: rmcat@ietf.org=0A= Subject: [rmcat] I-D Action: draft-ietf-rmcat-nada-05.txt=0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=0A= This draft is a work item of the RTP Media Congestion Avoidance Techniques = WG of the IETF.=0A= =0A= Title : NADA: A Unified Congestion Control Scheme for Rea= l-Time Media=0A= Authors : Xiaoqing Zhu=0A= Rong Pan=0A= Michael A. Ramalho=0A= Sergio Mena de la Cruz=0A= Paul E. Jones=0A= Jiantao Fu=0A= Stefano D'Aronco=0A= Filename : draft-ietf-rmcat-nada-05.txt=0A= Pages : 25=0A= Date : 2017-09-28=0A= =0A= Abstract:=0A= This document describes NADA (network-assisted dynamic adaptation), a=0A= novel congestion control scheme for interactive real-time media=0A= applications, such as video conferencing. In the proposed scheme,=0A= the sender regulates its sending rate based on either implicit or=0A= explicit congestion signaling, in a unified approach. The scheme can=0A= benefit from explicit congestion notification (ECN) markings from=0A= network nodes. It also maintains consistent sender behavior in the=0A= absence of such markings, by reacting to queuing delays and packet=0A= losses instead.=0A= =0A= =0A= The IETF datatracker status page for this draft is:=0A= https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada/=0A= =0A= There are also htmlized versions available at:=0A= https://tools.ietf.org/html/draft-ietf-rmcat-nada-05=0A= https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-nada-05=0A= =0A= A diff from the previous version is available at:=0A= https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-nada-05=0A= =0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n=0A= until the htmlized version and diff are available at tools.ietf.org.=0A= =0A= Internet-Drafts are also available by anonymous FTP at:=0A= ftp://ftp.ietf.org/internet-drafts/=0A= =0A=