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

Anna Brunstrom <anna.brunstrom@kau.se> Tue, 06 February 2018 15:30 UTC

Return-Path: <prvs=057550a7a4=anna.brunstrom@kau.se>
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 452A612D830; Tue, 6 Feb 2018 07:30:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut2U0hS04dTH; Tue, 6 Feb 2018 07:30:42 -0800 (PST)
Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (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 1CFA212706D; Tue, 6 Feb 2018 07:30:42 -0800 (PST)
To: Michael Welzl <michawe@ifi.uio.no>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
CC: "rmcat WG (rmcat@ietf.org)" <rmcat@ietf.org>, <draft-ietf-rmcat-sbd.all@ietf.org>
References: <227D2FC6-A331-4311-A8BF-E783B9F0B8EB@kuehlewind.net> <1b78e928-3fb3-7959-552a-e4c9bbcd7af6@kau.se> <1E245578-0EC9-4496-A683-9FBFBA1FC5C2@kuehlewind.net> <5E43ED74-2BBF-4E1E-8C4B-21D2D718E2F2@ifi.uio.no>
From: Anna Brunstrom <anna.brunstrom@kau.se>
Message-ID: <fcdafb8d-d3ff-5bd0-f502-9baea1dac615@kau.se>
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: <5E43ED74-2BBF-4E1E-8C4B-21D2D718E2F2@ifi.uio.no>
Content-Type: multipart/alternative; boundary="------------F244758E9836F1462305A790"
Content-Language: en-US
X-ClientProxiedBy: Exch-A2.personal.kau (130.243.19.83) To Exch-A2.personal.kau (130.243.19.83)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/_fbv-437ZICV-FdzRCV5Zg6xJl4>
Subject: Re: [rmcat] AD review of draft-ietf-rmcat-sbd-09
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: Tue, 06 Feb 2018 15:30:47 -0000

Hi,

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) 
>> <ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote:
>>
>>
>>
>>> Am 06.02.2018 um 02:18 schrieb Anna Brunstrom <anna.brunstrom@kau.se 
>>> <mailto:anna.brunstrom@kau.se>>:
>>>
>>> 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.
> http://heim.ifi.uio.no/michawe/research/publications/infocom2016.pdf
>
>
>>>> 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:
> https://www.ietf.org/standards/process/informational-vs-experimental

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

Best Regards,
Anna

>
> Cheers,
> Michael
>