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

[Mirja Kühlewind <[e-mail]>]

Hi Anna,

see below.

On 06.02.2018 16:30, Anna Brunstrom wrote:
> 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:

So that document is an 10 year old expired draft and not an RFC but let 
me reply to these points below to avoid future confusion:

> 
> /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).//

This is simply not true. If a "high-order" doc references a 
"lower-order" doc normatively, this is called a down ref and needs to be 
call out in the IETF last call to explicitly make people aware of this 
but it can still be done if it is the right thing to do. The problem 
here is that informational as well as experimental documents do not need 
to have IETF consensus, however, we usually run the same process for all 
the docs so effectively they usually also have IETF consensus.

> //   2.  if the referencing statement is not a normative statement; 
> i.e., does not prescribes some degree of normative compliance with the 
> target document.//

I'm actually not sure what this means. However, if a documents repeats a 
normative statement that was made in a different document that does also 
not automatically mean that this doc has to be referenced normatively 
because if the statement on its own is understandable as such without 
reading the other doc that is fine as well. However, usually it is 
better practice to not repeat the statement normatively (because then 
you have to change two independent docs and keep the knowledge that you 
have to do that, if you ever would want to change that statement). So it 
is better explain the statement non-normatively and refer to the 
original doc normatively instead.

> //   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./

This is just not true. If you need to read that section to be able to 
understand the (normative) content of the current doc, which mainly 
means you need that information to implement the current spec correctly, 
it must be normative. This is the bit where we often have discussions 
about terminology. If the terminology that you use if defined in a 
different document and it is not possible to understand the spec in this 
doc without knowing the terminology that's a normative reference. If you 
want to avoid that reference for some reason, you have to copy the 
terminology into the current doc.

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

Okay. Just wanted to double-check!

> 
> 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.

Yes. I agree. They could also try and re-read and try to understand if 
the intro is understandable without knowing the architecture of 
draft-ietf-rmcat-coupled-cc and if not maybe add a bit more explanation. 
I actually also believe that the text as it is might be fine. I just 
wasn't sure, so I thought I might ask and see if you or the authors have 
further opinions.

> 
>> 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

So I would like to add something here. I don't know why you think from 
this text that experimental is the better fit, but I think both are 
suitable and therefore I'm also fine to move on with experimental but I 
wanted to make sure that this has been considered. So both informational 
and experimental do not need to have IETF consensus (but as I said they 
usually have); so no difference in this aspect. Experimental docs are 
usually specs that are not ready for proposed standard yet but 
experimentation in the Internet is needed to move forward. However, sbd 
is not really a spec, it's more a documentation of a mechansims. As such 
I think it could also be moved forward as informational. The difference 
for me at this point is, are there any plans to move it forward to 
proposed standard as any point in the future, or do we keep this 
document as a documentation of the proposed mechanism and probably will 
never touch it again?

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

Assuming, we have a decision on the indented status (going for exp as 
the current version said). Would you like to submit another update 
before IETF last call, or should I just start the IETF last right away?

Mirja



> 
> Best Regards,
> Anna
> 
>>
>> Cheers,
>> Michael
>>
>