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

[Anna Brunstrom <[e-mail]>]

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) 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>
>>
>>> Am 06.02.2018 um 02:18 schrieb Anna Brunstrom <[e-mail] 
>>> <mailto:[e-mail]>>:
>>>
>>> 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
>