Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-05.txt

Michael Welzl <michawe@ifi.uio.no> Sat, 25 March 2017 05:52 UTC

Return-Path: <michawe@ifi.uio.no>
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 2EC4C1299DC for <rmcat@ietfa.amsl.com>; Fri, 24 Mar 2017 22:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Ut_46mJGcJTG for <rmcat@ietfa.amsl.com>; Fri, 24 Mar 2017 22:52:49 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF1B12942F for <rmcat@ietf.org>; Fri, 24 Mar 2017 22:52:49 -0700 (PDT)
Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <michawe@ifi.uio.no>) id 1cred5-0003tG-Rg; Sat, 25 Mar 2017 06:52:47 +0100
Received: from [81.92.27.192] (helo=[10.26.63.177]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from <michawe@ifi.uio.no>) id 1cred4-0006Ff-R5; Sat, 25 Mar 2017 06:52:47 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <111EB839-EC1B-4DCA-AC85-5AE63C21E812@csperkins.org>
Date: Sat, 25 Mar 2017 06:53:33 +0100
Cc: rmcat WG <rmcat@ietf.org>, draft-ietf-rmcat-coupled-cc@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5CD82FB1-C38E-475B-9C3A-C7C61EAEEE04@ifi.uio.no>
References: <148111854325.13729.9946710085994858033.idtracker@ietfa.amsl.com> <66C087EE-823A-43C9-8E8B-A2364FD6511B@csperkins.org> <79DC47FB-2032-444C-9654-A0A87F93CC18@csperkins.org> <0A54D20B-45D0-41F6-AAAD-923A60F6C285@csperkins.org> <9DCBD472-DFFF-43CF-BBDC-6241BEA2C67A@ifi.uio.no> <111EB839-EC1B-4DCA-AC85-5AE63C21E812@csperkins.org>
To: Colin Perkins <csp@csperkins.org>
X-Mailer: Apple Mail (2.3259)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 81.92.27.192 is neither permitted nor denied by domain of ifi.uio.no) client-ip=81.92.27.192; envelope-from=michawe@ifi.uio.no; helo=[10.26.63.177];
X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 5 sum msgs/h 2 total rcpts 53165 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: C9FB8DDAB98A1F1E885F961CC51DBC2A2F242C4C
X-UiO-SPAM-Test: remote_host: 81.92.27.192 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 18 max/h 4 blacklist 0 greylist 0 ratelimit 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/2wBfpS8KPoxQsPYdAo5WpyDmWd4>
Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-coupled-cc-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." <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: Sat, 25 Mar 2017 05:52:53 -0000

Thanks!

This is actually there but too weakly qualified:

***
a priority P(f), which here is assumed to be represented as a
      positive number within a fixed range.
***

Suggest to change to:

***
a priority P(f), which is a positive number within a fixed range.
***

Cheers,
Michael


> On Mar 25, 2017, at 12:29 AM, Colin Perkins <csp@csperkins.org>; wrote:
> 
> Looks good, thanks! (although maybe call out explicitly that the priority has to be greater than zero?)
> 
> Cheers,
> Colin
> 
> 
> 
> 
>> On 23 Mar 2017, at 13:47, Michael Welzl <michawe@ifi.uio.no>; wrote:
>> 
>> Dear Colin,
>> 
>> Thanks a lot, this was very helpful !    We incorporated your comments and attach the updated draft to this email, as right now submission is closed.
>> Some answers in line:
>> 
>> 
>>> On 23 Mar 2017, at 00:33, Colin Perkins <csp@csperkins.org>; wrote:
>>> 
>>> Authors,
>>> 
>>> I’ve reviewed this draft while preparing the IESG write-up and request for publication. I have a number of minor questions and comments:
>>> 
>>> - Section 2 defines a Flow and gives an example as “an RTP session, or a sub-session that is multiplexed onto a single RTP session”. I believe this example is incorrect, and what is intended is “an RTP Stream [RFC7656], or a group of RTP Streams multiplexed onto a single RTP session” (Section 2.1.10 of RFC 7656 defines the term RTP Stream carefully, so I think a reference is useful; it also defines the term RTP Session in Section 2.2.2). Can you please check and update are necessary.
>> 
>> Thanks a lot - of course you're right! We changed the definition of a flow as follows:
>> "A flow is the entity that congestion control is operating on. It could, for example, be a transport layer connection, or an RTP  stream <xref target="RFC7656"/>, whether or not this RTP stream is multiplexed onto an RTP session with other RTP streams."
>> 
>> 
>>> - Section 3 discusses limitations of the proposed algorithms. Would it be appropriate to add a brief applicability statement either here, or in the Introduction, stating that the described mechanisms are believed safe to use, but are experimental and are presented for wider review and operational evaluation?
>> 
>> OK, done, at the end of the introduction.
>> 
>> 
>>> - Section 5.1, bullet 1, notes that flows share a bottleneck if they’re sent on the same 5-tuple and have the same DSCP value. Should this also note that they need the same ECT mark? With the proposed L4S ECN experiments, we’re likely to see quite different behaviour between flows with NotECT/ECT(0) and those with ECT(1) marking. 
>> 
>> Good catch! Done
>> 
>> 
>>> - Section 5.2 defines the priority in the range 0.1 to 1. Assuming 0.1 is correct, it might be worth adding a brief note to explain this choice, since readers might think it a typo for the more typical range of 0 to 1. 
>>> 
>>> - Section 5.2, in the paragraph following the bullet points, the draft suggests mapping priority levels from RTCWEB using the values 1, 2, 4, and 8 – how do these relate to the 0.1 to 1 range?
>> 
>> Another good catch! The value range really doesn't matter for our algorithm, but 0 is not allowed (it might lead to a division by 0).
>> 
>> To clarify all of this, we have removed the "0.1 to 1" example in the priority definition, and changed the text talking about 1, 2, 4 and 8 levels to the following:
>> 
>> ***
>>  Note that the absolute range of priorities does not matter: the
>>  algorithm works with a flow's priority portion of the sum of all
>>  priority values.  For example, if there are two flows, flow 1 with
>>  priority 1 and flow 2 with priority 2, the sum of the priorities is
>>  3.  Then, flow 1 will be assigned 1/3 of the aggregate sending rate
>>  and flow 2 will be assigned 2/3 of the aggregate sending rate.
>>  Priorities can be mapped to the "very-low", "low", "medium" or "high"
>>  priority levels described in [I-D.ietf-rtcweb-transports] by simply
>>  using the values 1, 2, 4 and 8, respectively.
>> ***
>> 
>> 
>>> - Section 5.3 defines terminology and describes the two algorithms. The terminology used is inconsistent, sometimes using FSE_R and sometimes FSE_R(f). If the intent is that these are the same variable, the terminology should be aligned (I assume to FSE_R(f) since they’re per-flow values, but the important point is that it’s consistent). If there’s intended to be a difference between the overall and per-flow values, can you please check that they’re used consistently, and add a sentence to clarify the meanings of the terms. 
>>> 
>>> - Section 5.3 also uses P and P(i) in a manner that suggests they’re referring to the same parameter. Similarly for CC_R – should it be CC_R(i)?
>> 
>> Fixed everywhere.
>> 
>> 
>>> - Appendix C: similar terminology comments apply.
>> 
>> Fixed everywhere (here it also applies to the variables DR, new_DR and Rate).
>> 
>> 
>>> - Appendix C: “highly experimental” – It might be useful to add a brief applicability statement for implementors so they know whether this is safe to deploy outside of testbed environments.
>> 
>> done  (we added "and not safe to deploy outside of testbed environments" after "highly experimental").
>> 
>> Cheers,
>> Michael
>> 
>> <draft-ietf-rmcat-coupled-cc-06.txt>
>> 
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
>