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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Mon, 02 Mar 2020 10:41:08 -0800

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?

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.

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!

Fully editorial minor comments:
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/

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 4 Mar 2020 14:33:22 +0000

Hi Mirja

Responding as one of the authors. 

> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multiplex-guidelines/

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. 

> Maybe you can say a bit more here to ensure the guidance provided in RFC7657

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.

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

-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 4 Mar 2020 16:27:34 +0100

Hi Magnus,

See comments inline.

> On 4. Mar 2020, at 15:33, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi Mirja
> 

Then maybe provide a reference to draft-ietf-avtcore-multi-media-rtp-session ?
> 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...

> 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.
> list. TSVART list was probably dropped. 
Okay. Thanks for the info!

> Will address these in next rev or AUTH48. 

Thanks!

Mirja

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 4 Mar 2020 15:49:02 +0000

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

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.

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

> > > Maybe you can say a bit more here to ensure the guidance provided in
> > > RFC7657
> > > is
> > > reflected accurately.
> > 
> 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

> > > s/transport flows, e.g. an UDP destination port./transport flows, e.g.
> > > based
> > > on
-- 
Cheers

Magnus Westerlund