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

[Magnus Westerlund <[e-mail]>]

On Wed, 2020-03-04 at 16:27 +0100, Mirja Kuehlewind wrote:
> 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 ?

There already are a reference present in the pargraph but we could be more
explicit about that it updates RFC 3550:

OLD:
  A summary of RFC 3550's view on multiplexing is to use unique SSRCs
   for
anything that is its own media/packet stream, and to use
   different RTP
sessions for media streams that don't share a media
   type.  This document
supports the first point; it is very valid.  The
   latter needs further
discussion, as imposing a single solution on all
   usages of RTP is
inappropriate.  Multiple Media Types in an RTP
   Session specification [I-
D.ietf-avtcore-multi-media-rtp-session]
   provides a detailed analysis of the
potential issues in having
   multiple media types in the same RTP session.  This
document provides
   a wider scope for an RTP session and considers multiple
media types
   in one RTP session as a possible choice for the RTP application
   
designer.

NEW:
   A summary of RFC 3550's view on multiplexing is to use unique SSRCs
   for anything that is its own media/packet stream, and to use
   different RTP sessions for media streams that don't share a media
   type.  This document supports the first point; it is very valid.  The
   latter needs further discussion, as imposing a single solution on all
   usages of RTP is inappropriate.  Multiple Media Types in an RTP
   Session specification [I-D.ietf-avtcore-multi-media-rtp-session] 
   updates RFC 3550 to allow multiple media types in a RTP session. 
   It also provides a detailed analysis of the potential benefits 
   and issues in having
   multiple media types in the same RTP session.  Thus this document provides
   a wider scope for an RTP session and considers multiple media types
   in one RTP session as a possible choice for the RTP application
   designer.


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

So this is not the document to do that update. Also the paragraph has to be
taken in the light of the earlier paragraphs of this section that can be
summarized into; We have created new mechanisms for achieving binding between
SSRCs for other use cases. It is in this context that we propose designers
consider to use the same methods also for layered multicast despite what RFC
3550 says.

Layered multicast is a very niche use case and although it we know the
recommendation is wrong, finding enough energy to correct that statement is less
than easy. Although such an update is likely a 5-page document. 

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

Let us try to reformualte it. 

Cheers

Magnus

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

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------