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

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 2 Feb 2018 17:04:14 +0100

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.

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

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.

It would be great if you could reply (or update) by early next week as I would like to start the IETF LC latest by Wednesday (or I need to move the draft to the telechat two weeks later on March 8).

Find further below other comments that came to my mind while reading the doc. None of these are critical to proceed the document and may or may not be address at any point in the process.

Thanks!
Mirja

————————
Other review comments:

1) As normative language is very sparsely use in this document and when used not really that much necessary, I would recommend to instead not used normative language at all, which mean use only lower case words and removed the respective preamble text in sec 2.

2) Question on the 2. scenario in section 3 (receiver-side). This says that the receiver H3 can calculate stats for SBD for H1 and H2, however H1 and H2 cannot implement coupled congestion control, thus congestion control would also need to be implemented at the receiver H3, right? Maybe worth mentioning...

3) In section 3.2.1, I’d say that the following part could be removed as it goes a bit beyond the scope of the document, and also seems actually unnecessary to me: if you have a way to request a set of metrics and the other end tells you with metrics it can send, you have to chose your SBD algorithm based on that information anyway without actually being at all restricted to one specific scheme.

"* A protocol identifier (SBD=01). This is to future proof the message exchange so that potential advances in SBD technology can be easily deployed. All following initialization elements relate to the mechanism outlined in this document which will have the identifier SBD=01.“

4) RMCAT is mentioned 3 times on the doc but never really introduced. Maybe make the following change: 
sec 3.1.3: s/SBD in RMCAT/the SBD algorithm described in this document./
sec 3.3.1: s/SBD in the RMCAT context/use of SBD with Coupled congestion control for RTP media [draft-ietf-rmcat-coupled-cc]/
sec 6: s/RMCAT congestion control algorithms/RTP Media Congestion Avoidance Techniques (RMCAT) algorithms/ 
   or: s/RMCAT congestion control algorithms/congestion control algorithm as developed in the RTP Media Congestion Avoidance Techniques (RMCAT) working group/

5) Use of the terms one way delay, OWD, or e.g way delay samples (OWD) is inconsistent in section 3.2.1 and 3.2.2

6) Just to double-check: sec 3.2.1, 3.2.2, and 3.2.3 use M while 3.2.4 and 3.2.5 use N. Is that correct? To be honest I actually still did not fully understand yet why and N and M are needed.

7) Sec 5.1:
OLD:
"Timing information described by
   [I-D.ietf-avtcore-cc-feedback-message] should be sufficient for the
   sender to calculate relative OWD."
MAYBE
"Timing information described by
   [I-D.ietf-avtcore-cc-feedback-message] should be sufficient for the
   sender to calculate relative OWD of an Internet path.“
Or would those information be also sufficient for e.g. a data center scenario?

8) Probably the security consideration section should also point to the security considerations of draft-ietf-rmcat-coupled-cc.

---

From: Anna Brunstrom <[email-masked]>
Date: Tue, 6 Feb 2018 02:18:31 +0100

Hi Mirja, all,

Comments inline.

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

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.

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

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

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.

> Find further below other comments that came to my mind while reading the doc. None of these are critical to proceed the document and may or may not be address at any point in the process.

Great, thanks! Authors please take them into account in you next update.

Best Regards,
Anna

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 6 Feb 2018 09:21:48 +0100

> Am 06.02.2018 um 02:18 schrieb Anna Brunstrom <[email-masked]>:
> 
> Hi Mirja, all,
> 
> Comments inline.
> 
> 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).

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

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

Mirja

---

From: Michael Welzl <[email-masked]>
Date: Tue, 6 Feb 2018 13:34:57 +0100

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) <[email-masked]> wrote:
> 
> 
> 

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>

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

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

---

From: Anna Brunstrom <[email-masked]>
Date: Tue, 6 Feb 2018 16:30:36 +0100

Hi,

On 2018-02-06 13:34, Michael Welzl wrote:
>> On Feb 6, 2018, at 9:21 AM, Mirja Kuehlewind (IETF) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>
>>> Am 06.02.2018 um 02:18 schrieb Anna Brunstrom <[email-masked] 
>>> <mailto:[email-masked]>>:
>>>
>>> Hi Mirja, all,
>>>
>>> Comments inline.
>>>
>>>> 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.
>>>
>>> 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).
>
> 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
>
>
>>>> 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.
>>> 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.
>>
>> 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

---

From: Michael Welzl <[email-masked]>
Date: Tue, 6 Feb 2018 16:33:12 +0100

Hi,

(..)

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

ACK; I agree.

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

and ACK.

Thanks!

Cheers,
Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 6 Feb 2018 16:59:11 +0100

Hi Anna,

see below.

> language were the same. I was referring to these guidelines from the 

So that document is an 10 year old expired draft and not an RFC but let 

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

> i.e., does not prescribes some degree of normative compliance with the 

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.

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

> read to understand the SBD document.

Okay. Just wanted to double-check!

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

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

---

From: Michael Welzl <[email-masked]>
Date: Tue, 6 Feb 2018 18:07:33 +0100

Hi,

I’m cutting away some things and only answering on the part that speaks to me as one of the authors:

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

1. If it can't be practiced, it's Informational.  => this is an algorithm, it can be practiced.
2. If it's not going to be changed no matter what the result is, it's Informational  => that’s not the case, see my answer below regarding “will never touch it again”.
3. (..)work that could be practiced, was developed in the IETF, has been dropped for some reason, but is being published for the record(..) Informational or Historic  => that’s also not the case.
4. If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental  => again the point below, I do think this can go to standards track after more experience.
5. If the document contains implicit or explicit success/failure criteria, and it's clear that the outcome can be used as the basis for a recommendation to the IETF community, it's Experimental  => well there’s a section on expected feedback from experiments.

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

I don’t see what makes you say that this isn’t really a spec? It should be, it’s meant to be a spec.

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

Well, it’s certainly my plan as one of the authors to move this forward to proposed standard at some point in the future. We’re actively working on this.

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

We’d like to do another update - there were some recommendations here: removing the reference to coupled-cc from the abstract, different boilerplate and your editorial comments. This may take a little bit (I’m not the only author).

Cheers,
Michael

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 7 Feb 2018 10:25:25 +0100

Hi Michael,

that’s okay. Please go ahead and make the updates. I moved the draft to the later telechat.

Mirja

P.S.: By spec I actually meant protocol spec…

> Am 06.02.2018 um 18:07 schrieb Michael Welzl <[email-masked]>:
> 
> Hi,
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 12 Feb 2018 22:11:13 +0100

Hi,

when will you likely submit an update?

Mirja

> Am 07.02.2018 um 10:25 schrieb Mirja Kuehlewind (IETF) <[email-masked]>:
> 
> Hi Michael,
>