Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-multiplex-guidelines-12.txt

From: [email-masked]
Date: Tue, 16 Jun 2020 01:37:46 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF.

        Title           : Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams
        Authors         : Magnus Westerlund
                          Bo Burman
                          Colin Perkins
                          Harald Tveit Alvestrand
                          Roni Even
	Filename        : draft-ietf-avtcore-multiplex-guidelines-12.txt
	Pages           : 43
	Date            : 2020-06-16

Abstract:
   The Real-time Transport Protocol (RTP) is a flexible protocol that
   can be used in a wide range of applications, networks, and system
   topologies.  That flexibility makes for wide applicability, but can
   complicate the application design process.  One particular design
   question that has received much attention is how to support multiple
   media streams in RTP.  This memo discusses the available options and
   design trade-offs, and provides guidelines on how to use the
   multiplexing features of RTP to support multiple media streams.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multiplex-guidelines/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-avtcore-multiplex-guidelines-12
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-multiplex-guidelines-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multiplex-guidelines-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 16 Jun 2020 08:40:56 +0000

WG,

This version intendeds to address the issues raised during IESG review. 

Cheers

Magnus

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
-- 
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: Gunnar Hellström <[email-masked]>
Date: Sat, 20 Jun 2020 11:37:55 +0200

Hi,

Thanks for an inspiring draft.

I have two issues:

1.) In section 3.4.2 it is said:

"RTP Considerations for Endpoints Sending Multiple Media Streams" 
[RFC8108 <https://tools.ietf.org/html/rfc8108>].

I first got the impression that this would refer to a section in RFC 
8108, but there is none with that title.

And it is also not the title of RFC 8108. I suggest that you update the 
string to what it was intended to refer to.

2.) I see a contradiction between two statements:

--------------------------------------------------------------------------------

I.) In 3.4 you say:    "Using multiple RTP streams is a well-supported 
feature of RTP."

II.) In 5.2, 4.b you mention a disadvantage with using multiple streams 
for the same media type in one RTP session:

"b. There is some potential for concern with legacy implementations that 
don't support the RTP specification fully when it comes to handling 
multiple SSRC per endpoint."

-------------------------------------------------------------------------------------------

Can you in some way tell for which cases there is concern and for which 
it is a well-supported feature.

My interest is for the multi-party-rtt drafts, where we have so far 
avoided the solution with multiple media streams of one media type in a 
single RTP session saying that there may be lack of support for it in 
current RTP stacks. Our current choice to instead have a mixer combine 
all streams into one stream has some disadvantages and does not seem to 
be your recommendation.

Regards

Gunnar

-- 
Gunnar Hellström
GHAccess
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Jun 2020 14:05:35 +0000

Hi Gunnar, 

Thanks for the feedback. 

From: Gunnar Hellström <[email-masked]> 
Sent: den 20 juni 2020 11:38
To: Magnus Westerlund <[email-masked]>; [email-masked]
Subject: Re: [AVTCORE] I-D Action:
draft-ietf-avtcore-multiplex-guidelines-12.txt

Hi,

I have two issues:

"RTP Considerations for Endpoints Sending Multiple Media Streams" [RFC8108
<https://tools.ietf.org/html/rfc8108> ].

I first got the impression that this would refer to a section in RFC 8108,
but there is none with that title.

[MW] Yes, the title should really be changed. I am not certain I understand
the first part. This whole document do discuss and clarify how to handle the
aspects that are raised. So I tried to clarify that “These” really refer to
aspects and not anything else. Updated paragraph below. 

Using multiple SSRCs at one endpoint in an RTP session requires resolving
some unclear aspects of the RTP specification. These aspects could
potentially lead to some interoperability issues as well as some  potential
significant inefficiencies, as further discussed in “Sending Multiple RTP
Streams in a Single RTP Session" [RFC8108]. An RTP application designer
should consider these issues and the possible application impact from lack
of            appropriate RTP handling or optimization in the peer
endpoints.

----------------------------------------------------------------------------
----

II.) In 5.2, 4.b you mention a disadvantage with using multiple streams for
the same media type in one RTP session:

"b. There is some potential for concern with legacy implementations that
don't support the RTP specification fully when it comes to handling multiple
SSRC per endpoint."

----------------------------------------------------------------------------
---------------

Can you in some way tell for which cases there is concern and for which it
is a well-supported feature. 

My interest is for the multi-party-rtt drafts, where we have so far avoided
the solution with multiple media streams of one media type in a single RTP
session saying that there may be lack of support for it in current RTP
stacks. Our current choice to instead have a mixer combine all streams into
one stream has some disadvantages and does not seem to be your
recommendation.

[MW] So the 3.4 is related to the RTP protocols capabilities as
specification. The second aspect is related to system employing RTP and what
capabilities they have required and can be expected to support. 

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Jun 2020 12:42:10 +0000

Hi,

For your knowledge I didn't manage to get the edits into a draft that got
submitted prior to the IESG approval. I have sent the suggested edits to the
RFC-editor so they will be considered in the editing process. 

Cheers

Magnus

On Mon, 2020-06-22 at 14:05 +0000, Magnus Westerlund wrote:
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multiplex-guidelines-
> 12.txt
>  
> Hi,
> "RTP Considerations for Endpoints Sending Multiple Media Streams" [RFC8108].
> I first got the impression that this would refer to a section in RFC 8108, but
> there is none with that title.
> And it is also not the title of RFC 8108. I suggest that you update the string
> to what it was intended to refer to.
> Using multiple SSRCs at one endpoint in an RTP session requires resolving some
> unclear aspects of the RTP specification. These aspects could           
> Streams in a Single RTP Session" [RFC8108]. An RTP application designer should
> consider these issues and the possible application impact from lack
> of            appropriate RTP handling or optimization in the peer endpoints.
>  
>  
> I.) In 3.4 you say:    "Using multiple RTP streams is a well-supported feature
> of RTP."
> "b. There is some potential for concern with legacy implementations that don't
> support the RTP specification fully when it comes to handling multiple SSRC
> per endpoint."
> Can you in some way tell for which cases there is concern and for which it is
> a well-supported feature.
> session saying that there may be lack of support for it in current RTP stacks.
> Our current choice to instead have a mixer combine all streams into one stream
> has some disadvantages and does not seem to be your recommendation.
> [MW] So the 3.4 is related to the RTP protocols capabilities as specification.
> The second aspect is related to system employing RTP and what capabilities
> they have required and can be expected to support.
>  
> Cheers
> Magnus Westerlund
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
-- 
Cheers

Magnus Westerlund