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

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

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

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

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