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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

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

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

Mirja


> 
>> 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.
> 
> Great, thanks! Authors please take them into account in you next update.
> 
> Best Regards,
> Anna
> 
>> 
>> 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.
>> 
>> 
>