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

[Magnus Westerlund <[e-mail]>]

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. 

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. 


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


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




> 
> Fully editorial minor comments:

Will address these in next rev or AUTH48. 

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