Re: [rmcat] AD review of draft-ietf-rmcat-sbd-09

Anna Brunstrom <> Tue, 06 February 2018 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 452A612D830; Tue, 6 Feb 2018 07:30:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ut2U0hS04dTH; Tue, 6 Feb 2018 07:30:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CFA212706D; Tue, 6 Feb 2018 07:30:42 -0800 (PST)
To: Michael Welzl <>, "Mirja Kuehlewind (IETF)" <>
CC: "rmcat WG (" <>, <>
References: <> <> <> <>
From: Anna Brunstrom <>
Message-ID: <>
Date: Tue, 6 Feb 2018 16:30:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------F244758E9836F1462305A790"
Content-Language: en-US
X-ClientProxiedBy: Exch-A2.personal.kau ( To Exch-A2.personal.kau (
Archived-At: <>
Subject: Re: [rmcat] AD review of draft-ietf-rmcat-sbd-09
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: Tue, 06 Feb 2018 15:30:47 -0000


On 2018-02-06 13:34, Michael Welzl wrote:
> Hi,
> As an author, first of all, thanks for your feedback!
> I’m answering a point below:
>> On Feb 6, 2018, at 9:21 AM, Mirja Kuehlewind (IETF) 
>> < <>> wrote:
>>> Am 06.02.2018 um 02:18 schrieb Anna Brunstrom < 
>>> <>>:
>>> Hi Mirja, all,
>>> Comments inline.
>>> On 2018-02-02 17:04, Mirja Kuehlewind (IETF) wrote:
>>>> Hi authors, hi chairs,
>>>> many thanks for this very well written document as well as a good 
>>>> write-up from the shepherd!
>>>> Before I start the IETF LC call I have two small questions:
>>>> 1) Normative references:
>>>> I wonder if draft-ietf-rmcat-coupled-cc should be a normative 
>>>> reference, especially as it is mentioned in the abstract, but also 
>>>> because it probably helps to at least read section 4 (architecture) 
>>>> of draft-ietf-rmcat-coupled-cc.
>>> My understanding is that only normative statements create normative 
>>> references, so the fact that it is mentioned in the abstract or 
>>> useful to read does not make it normative? As I am not so 
>>> experienced with the process I looked for guidelines on this before 
>>> reviewing the draft and this is at least what 
>>> draft-peterson-informational-normativity-01 suggests.
>> Normative references and normative language are two different things. 
>> A reference should be normative if it is (or part of it) a required 
>> read to understand the content of the document. E.g. if you write an 
>> TCP extension the RFC defining the TCP base protocol must be a 
>> normative reference. So my question is here, do you think that couple 
>> congestion is a required read to understand this document (I’m asking 
>> this because there is this architecture section in 
>> draft-ietf-rmcat-coupled-cc).

I did not mean to suggest that normative references and normative 
language were the same. I was referring to these guidelines from the 
draft mentioned above:

/For the benefit of specification authors, the following is a list of 
conditions in which a reference to a document need not be normative://
//   1.  if the source document is itself Informational (not a 
standards-track document, BCP or an Experimental document).//
//   2.  if the referencing statement is not a normative statement; 
i.e., does not prescribes some degree of normative compliance with the 
target document.//
//   3.  if the target document, and in particular any subset scope 
designated by the referencing statement (a section, or what have you), 
contains no normative statements./

Either way, I do not think that coupled congestion control is a required 
read to understand the SBD document.

For the next update the authors may perhaps still consider removing the 
reference from the abstract, as it may in general look a bit odd.

> I’m not Anna, but at least I think that, despite there being an 
> architecture section in draft-ietf-rmcat-coupled-cc, it is not a 
> required read to understand draft-ietf-rmcat-sbd-09. It really 
> shouldn’t be: SBD is just a mechanism that provides information about 
> flows traversing common bottlenecks. Coupled-cc is a mechanism that 
> can use it (it doesn’t have to, but if you combine them, you can, 
> e.g., couple flows from one sender towards multiple receivers).
> Here is an example of how the SBD algorithm can be used independent 
> of draft-ietf-rmcat-coupled-cc:
> Simone Ferlin, Ozgu Alay, David Hayes, Thomas Dreibholz, Michael 
> Welzl: "Revisiting Congestion Control for Multipath TCP with Shared 
> Bottleneck Detection", IEEE Infocom 2016, San Francisco, USA, 10-15 
> April 2016.
>>>> Further this sentence seems to make avtcore-cc-feedback-message 
>>>> should also be a normative reference:
>>>> "Timing information described by
>>>>   [I-D.ietf-avtcore-cc-feedback-message] should be sufficient for the
>>>>   sender to calculate relative OWD.“
>>>> I don’t think we want to wait for avtcore-cc-feedback-message for 
>>>> publication, therefor I would recommend to say something about the 
>>>> resolution used in avtcore-cc-feedback-message, e.g.
>>>> „Frequent timing information in millisecond resolution as described by
>>>>   [I-D.ietf-avtcore-cc-feedback-message] should be sufficient for the
>>>>   sender to calculate relative OWD.“
>>> From the same reasoning as above, I am not sure that this is a 
>>> normative reference either? But I agree that your proposal to 
>>> mention the resolution is much better! Actually, reading the text 
>>> now we should probably also avoid the lower case should just to not 
>>> confuse it with SHOULD, Perhaps "will be" or "is believed to be" or 
>>> something similar instead of "should be“.
>> There is no need to avoid lower case should. Actually there is the 
>> update of RFC2119 which clarifies this. You should probably also use 
>> the new boilerplate of RFC8174. Forgot to mention that!

Ok, good I had missed this. Authors, please add updating the boilerplate 
to the list for the next draft update.

>>>> 2) I can't remember if this was discussed in the group but actually 
>>>> I believe it was not: this document could also be an informational 
>>>> document, as it is just one example algorithm but there are no 
>>>> dependencies on this scheme otherwise. I also don’t think is makes 
>>>> too much sense to think about this proposed algorithm as an 
>>>> experiment; if you want to change the algorithm or use a different 
>>>> one just do it; this is just a documentation of one proposal. I 
>>>> also assume that there is actually not much interest in the group 
>>>> to publish an updated version of this algorithm as proposed 
>>>> standard, as such why not informational from the beginning…?
>>>> If the authors and the group are uncertain about this point, I’m 
>>>> okay to start IETF LC as exp and see if we can get further feedback 
>>>> there or from the IESG; „downgrading“ to information can easily be 
>>>> done with any additional actions at any time.
>>> This is not something that has been discussed as far as I know, but 
>>> I am not sure what happened in the beginning of the process. Unless 
>>> the authors prefer to have it informational I would not like to 
>>> change the status at this point as this is not something that has 
>>> been discussed in the group. I also do not think it is fully correct 
>>> to say that SBD does not interact with other mechanisms in the 
>>> network as it can affect congestion control and the performance of 
>>> other flows. So the need to verify a sane and useful behavior still 
>>> seems to be applicable here.
>> I didn’t say it didn’t interact but it does not need to be 
>> standardized for interoperability.
>> If we would decide to change the status, in agreement with the 
>> authors of course, I think it would be okay to simply announce it on 
>> the mailing list. I would not expect to see a lot of discuss there. I 
>> will wait for feedback from the authors. However, I don’t have a 
>> strong opinion here.
> We believe that Experimental status is more fitting; we looked at the 
> checklist here, from which this seems a pretty clear decision to us:

Ok, thanks for the feedback Michael. Then we stay with experimental.

Best Regards,

> Cheers,
> Michael