From nobody Mon Apr 2 07:49:05 2018 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 E42201241FC; Mon, 2 Apr 2018 07:49: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-sbd@ietf.org, Anna Brunstrom , rmcat-chairs@ietf.org, anna.brunstrom@kau.se, rmcat@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152268054392.30863.14736928981691873030.idtracker@ietfa.amsl.com> Date: Mon, 02 Apr 2018 07:49:03 -0700 Archived-At: Subject: [rmcat] Spencer Dawkins' Yes on draft-ietf-rmcat-sbd-11: (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: Mon, 02 Apr 2018 14:49:04 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-rmcat-sbd-11: 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-sbd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm somewhat confused about whether the intended scope for this mechanism is to detect bottleneck links shared by all flows, or only what's shared by RTP media flows. The Abstract seems clear about that, but I'm not seeing a similar statement about scope in the Introduction, unless I'm missing it. Perhaps it's worth repeating the statement from the Abstract in the Introduction? I agree with the last sentence in this paragraph, The current Internet is unable to explicitly inform endpoints as to which flows share bottlenecks, so endpoints need to infer this from whatever information is available to them. The mechanism described here currently utilizes packet loss and packet delay, but is not restricted to these. As ECN becomes more prevalent it too will become a valuable base signal. and I'd believe that ECN helps identify path bottlenecks, but I'm not understanding how ECN helps identify shared bottlenecks, and I think that's the point being made here. From nobody Wed Apr 4 23:28:06 2018 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 26CA4126C26; Wed, 4 Apr 2018 23:28:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-rmcat-sbd@ietf.org, Anna Brunstrom , rmcat-chairs@ietf.org, anna.brunstrom@kau.se, rmcat@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152290968414.26031.16395339801847446844.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2018 23:28:04 -0700 Archived-At: Subject: [rmcat] Adam Roach's No Objection on draft-ietf-rmcat-sbd-11: (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, 05 Apr 2018 06:28:04 -0000 Adam Roach has entered the following ballot position for draft-ietf-rmcat-sbd-11: 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-sbd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for everyone's work on this document, and especially to those who ran the preliminary experiments. This sounds like an interesting technique. I have two minor comments. --------------------------------------------------------------------------- §2: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14 [RFC2119] RFC2119 [RFC2119] RFC8174 [RFC8174] when, and only when, > they appear in all capitals, as shown here. This is almost, but not quite, the boilerplate defined in RFC 8174. Please consider fixing it. --------------------------------------------------------------------------- §2.1 says "Usually M=N", while §2.2 recommends N=50 and M=30. These statements seem in conflict. From nobody Mon Apr 9 16:45:53 2018 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 769F11200C1; Mon, 9 Apr 2018 16:45:45 -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.77.1 Auto-Submitted: auto-generated Precedence: bulk Cc: rmcat-chairs@ietf.org, The IESG , rmcat@ietf.org, draft-ietf-rmcat-sbd@ietf.org, ietf@kuehlewind.net, anna.brunstrom@kau.se, Anna Brunstrom , rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <152331754543.13388.10200539969299988152.idtracker@ietfa.amsl.com> Date: Mon, 09 Apr 2018 16:45:45 -0700 Archived-At: Subject: [rmcat] Document Action: 'Shared Bottleneck Detection for Coupled Congestion Control for RTP Media.' to Experimental RFC (draft-ietf-rmcat-sbd-11.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, 09 Apr 2018 23:45:46 -0000 The IESG has approved the following document: - 'Shared Bottleneck Detection for Coupled Congestion Control for RTP Media.' (draft-ietf-rmcat-sbd-11.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-sbd/ Technical Summary This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. It relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed. This mechanism complements the coupled congestion control mechanism in draft-ietf-rmcat-coupled-cc. Working Group Summary The draft has been under development in the RMCAT WG for some years, receiving several rounds of reviews. There seems general, but not overwhelming, consensus from the working group that the mechanism is useful and suitable for use together with coupled congestion control. There has been no controversial points. Document Quality This document is experimental, as a number of algorithm parameters have to be tested under real network conditions.The current set of parameters have been mainly evaluated through simulation. The WG will collect the feedback from first experiments using SBD and use them to discuss further steps. Personnel The document shepherd is Anna Brunstrom (anna.brunstrom@kau.se) The responsible Area Director is Mirja Kuehlewind (ietf@kuehlewind.net) RFC Editor note 1) I assume this would happen anyway but just to be sure: Please expand the acronym ECN to Explicit Congestion Notification on first occurrence. 2) Also please replace the following sentence: OLD "As ECN becomes more prevalent it too will become a valuable base signal.“ NEW "As ECN becomes more prevalent it too will become a valuable base signal that can be correlated to detected shared bottlenecks.“ 3) Please also update the following sentence in section 2.1: OLD "Usually M=N, though having M