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

[Michael Welzl <[e-mail]>]

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]> wrote:
> 
> 
> 
>> Am 06.02.2018 um 02:18 schrieb Anna Brunstrom <[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’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 <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!
> 
>> 
>>> 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 <https://www.ietf.org/standards/process/informational-vs-experimental>

Cheers,
Michael