Re: [AVTCORE] Mirja Kühlewind's No Objection on draft-ietf-avtcore-multiplex-guidelines-11: (with COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Magnus,

See comments inline.

> On 4. Mar 2020, at 15:33, Magnus Westerlund <[e-mail]> wrote:
> 
> Hi Mirja
> 
> Responding as one of the authors. 
> 
> On Mon, 2020-03-02 at 10:41 -0800, Mirja Kühlewind via Datatracker wrote:
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-avtcore-multiplex-guidelines-11: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multiplex-guidelines/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> One processing question: Should this document update RFC3550 given the last
>> paragraph each in section 3.4.1 and 3.4.3?
> 
> No, this is an informational document and not an BCP. In addition the actual
> changes to RFC 3550 has already been executed by the approval of other
> documents. For Section 3.4.1 
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-media-rtp-session/already updates RFC 3550 regarding multiple media types. 

Then maybe provide a reference to draft-ietf-avtcore-multi-media-rtp-session ?
> 
> Regarding 3.4.3 yes, that paragraph in RFC 3550 should be updated as it give bad
> advice. However, this is not the document to affect that cahange. 

Hm… it sounds like this document is trying to change it… as you know putting an update tag might still not be wrong so people have a pointer… however, this is a comment and I think you know better than I what’s the right thing to do here. I was mainly saying that section 3.4.3 already reads as if it would update RFC3550...

> 
> 
>> 
>> And one comment on section 4.2.1:
>> "Different Differentiated
>>   Services Code Points (DSCP) can be assigned to different packets
>>   within a flow as well as within an RTP stream. "
>> not sure what you mean by flow here but at least RFC7657 says
>> "Should use a single DSCP for all packets within a reliable
>>      transport protocol session"
>> Maybe you can say a bit more here to ensure the guidance provided in RFC7657
>> is
>> reflected accurately.
> 
> With Flow we mean a transport flow, i.e. packet sharing 5-tuple. That transport
> flow can then it is term contain multiple RTP Streams, i.e. different SSRC. 
> 
> So the guidance from RFC 7657 that is primarily apply here is this part of
> section 6:
> 
>   o  Should limit use of DSCPs within a single RTP stream to those
>      whose corresponding PHBs do not enable packet reordering.  If this
>      is not done, significant network reordering may overwhelm
>      implementation assumptions about reordering limits, e.g., jitter
>      buffer size, causing poor user experiences (see Section 5.2).
>      This guideline applies to all of the RTP streams that are within
>      the scope of a common (coupled) congestion controller when that
>      controller does not use per-RTP-stream measurements for bottleneck
>      detection.
> 
> The bullet you quote for reliable transport does not apply to the most common
> usages for RTP i.e. when UDP is used. 
> 
> We could actually reflect the recommendation from RFC 7657, rather than just
> pointing out that here are issues and that you should go read it.

Yes that would be really good. I still not sure if the use of the term flow is correct then in that sentence. You could just drop it. Or if you add more text it might become clearer anyway.
> 
> 
>> 
>> Even though I didn't see any discussion of the TSV-ART review (Thanks
>> Bernard!)
>> I believe all comments have been addressed. Thanks for that!
> 
> These where adressed in -10 and -11 updates. It was discussed on AVTCORE mailing
> list. TSVART list was probably dropped. 
> 
> 
Okay. Thanks for the info!

> 
> 
>> 
>> Fully editorial minor comments:
> 
> Will address these in next rev or AUTH48. 

Thanks!

Mirja


> 
>> 1) In the intro maybe:
>> OLD
>> The authors hope that clarification on the usefulness
>>   of some functionalities in RTP will result in more complete
>>   implementations in the future.
>> NEW
>> This document aims to clarify the usefulness
>>   of some functionalities in RTP which will hopefully result in more complete
>>   implementations in the future.
>> 
>> 2) sec 3.2
>> s/one or transport flows/one or more transport flows/
>> And maybe also
>> s/transport flows, e.g. an UDP destination port./transport flows, e.g. based
>> on
>> the UDP destination port./?
>> 
>> 3) sec 3.2.1:
>> "   RTP does not contain a session identifier, yet different RTP sessions
>>   must be possible to identify both across different endpoints and
>>   within a single endpoint."
>> Not sure I can parse this sentence correctly...
>> 
>> 4) sec 4.1.3:
>> s/Signalling, choosing and policing/Signalling, choosing, and policing/ ->
>> missing comma
>> 
>> 5) sec 6 maybe:
>> s/specification writers/specification designers/
>> 
>> 
>> 
> -- 
> Cheers
> 
> Magnus Westerlund 
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>