Subject: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Sun, 3 Jun 2012 23:07:51 +0000

http://www.ietf.org/id/draft-ejzak-avtcore-rtp-subsessions-00.txt

In response to the chairs' request for additional input on the multi session issue, I have submitted this draft for your consideration.  There are superficial similarities with an expired draft from last year in http://tools.ietf.org/id/draft-rosenberg-rtcweb-rtpmux-00.txt, but my draft has a different take on the use of SSRC as the basis for multi session multiplexing that I think is superior and worthy of consideration as a potential replacement for BUNDLE and/or SHIM.  Please comment.

Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, June 03, 2012 5:16 PM
To: Ejzak, Richard P (Richard)
Subject: New Version Notification for draft-ejzak-avtcore-rtp-subsessions-00.txt

A new version of I-D, draft-ejzak-avtcore-rtp-subsessions-00.txt has been successfully submitted by Richard Ejzak and posted to the IETF repository.

Filename:	 draft-ejzak-avtcore-rtp-subsessions
Revision:	 00
Title:		 Media multiplexing with Real-time Transport Protocol (RTP) subsessions
Creation date:	 2012-06-04
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
   This document describes a means of multiplexing RTP streams having
   different media types within a single transport connection and how to
   represent this multiplexing option in SDP.  This mechanism is an
   alternative to the BUNDLE and SHIM proposals currently under active
   consideration in AVTCORE.  Instead of adding an extra multiplexing
   header as in SHIM to allow multiple RTP sessions within a single
   transport connection, or using the payload type field to separate
   different media streams within a single RTP session, this document
   describes how to partition the existing SSRC space to create RTP
   subsessions from a single RTP session.  A filter can be used to
   identify each RTP subsession for different QoS handling as necessary.
   RTP subsessions can be treated like RTP sessions with a few
   restrictions.  In particular, SSRC mapping may be needed when
   forwarding RTP streams into an RTP subsession to avoid SSRC
   conflicts, but there are few use cases in which this limitation is a
   concern and RTP subsessions can be disabled if necessary.

The IETF Secretariat

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 05 Jun 2012 08:52:11 +0200

> In response to the chairs' request for additional input on the multi session issue, I have submitted this draft for your consideration.  There are superficial similarities with an expired draft fro…
Since this draft is destined for AVTCORE, I'll repeat my comments from 
the RTCWEB discussion here, and encourage people to keep the discussion 
on AVTCORE:

Richard,
having scanned your draft:

- I still fundamentally think that the partition of media types into 
separate RTP sessions was a design mistake that we should seek to 
rectify, not promulgate, and additional complexity like what you propose 
for perpetuating the use of "separated" sessions is not helpful. See 
draft-alvestrand-rtp-sess-neutral for details.

- When we have parts of the ecosystem that have code that is written on 
the assumption that the SSRC space is a 32-bit flat space, I think the 
partitioning of that space into subspaces as you propose is likely to 
lead to "interesting" bugs. We should reinforce the randomness and 
flatness of the SSRC space, not partition it.

- You say "The biggest problem with BUNDLE is that it is
    difficult to partition the RTP streams associated with different
    media lines since this requires filtering on sets of payload type
    values.  RTP subsessions is superior for this purpose since it is
    only necessary to screen for a single value in the first 16 bits".
This assumes that the partitioning associated with different media lines 
is a good thing.
I claim that it is not.

If there are no bigger problems than that with BUNDLE, I would prefer to 
stick with that approach.

> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 Jun 2012 10:05:15 +0200

Hi,

Just to clarify also to the AVTCORE community.

BUNDLE is not an RTP multiplexing mechanism. BUNDLE is an SDP extension which allows to signal the re-usage of the same IP address:port for multiple SDP media descriptions (m- lines).

BUNDLE currently does define a "default", which is a single RTP session, but BUNDLE can be extended to also be used with subsessions, SHIM, etc.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 5. kesäkuuta 2012 9:52
To: [email-masked]
Subject: Re: [AVTCORE] multi session draft-ejzak-avtcore-rtp-subsessions-00.txt

> In response to the chairs' request for additional input on the multi session issue, I have submitted this draft for your consideration.  There are superficial similarities with an expired draft fro…
Since this draft is destined for AVTCORE, I'll repeat my comments from the RTCWEB discussion here, and encourage people to keep the discussion on AVTCORE:

Richard,

- I still fundamentally think that the partition of media types into separate RTP sessions was a design mistake that we should seek to rectify, not promulgate, and additional complexity like what you propose for perpetuating the use of "separated" sessions is not helpful. See draft-alvestrand-rtp-sess-neutral for details.

- When we have parts of the ecosystem that have code that is written on the assumption that the SSRC space is a 32-bit flat space, I think the partitioning of that space into subspaces as you propose is likely to lead to "interesting" bugs. We should reinforce the randomness and flatness of the SSRC space, not partition it.

This assumes that the partitioning associated with different media lines is a good thing.
I claim that it is not.

If there are no bigger problems than that with BUNDLE, I would prefer to stick with that approach.

> Subject: New Version Notification for 
> draft-ejzak-avtcore-rtp-subsessions-00.txt
>
> Audio/Video Transport Core Maintenance [email-masked]

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 5 Jun 2012 23:34:19 +0000

> draft-alvestrand-rtp-sess-neutral for details.

There are two reasons why "separating" sessions can be helpful. Firstly, in more complex RTP session topologies with multiple systems, other systems will already consider each media line to identify a separate RTP session, so BUNDLE (in its current default mode) essentially merges these sessions together since they now have a common SSRC space. This has the potential to cause additional SSRC conflicts. I am not proposing to separate the sessions but instead suggesting a way to keep them separate as originally intended. I agree that there are many use cases in which this merging is not a problem.

The more important reason for separating sessions is so that it is possible for the network to easily identify the IP packets associated with different media types for different QoS treatment. Blending of different media types into a single RTP session means that the corresponding compound RTCP packets will mix RTCP information for different media types into single IP packets. It is important to assign the same QoS to the RTCP packets as to the corresponding RTP streams and this will not be possible with these compound RTCP packets.

You made the following comment on the related rtcweb thread when I mentioned the need to support QoS:
> Yes, some applications need that.
>  In that case, the simplest way (allowing per-flow prioritization) is to 
> use different RTP sessions on different transport addresses.
> The next simplest way (using DiffServ) is to apply different DSCP markings
> on a per-packet basis. Both techniques are well established.

If we use different transport connections then we lose the clear advantages of multiplexing. If we use DiffServ without "separating" the sessions in some way, we still have problems with compound RTCP packets.

DSCP has two other problems. There is no current mechanism defined for the application to direct the browser and/or OS to correctly mark the transmitted packets. (We could fix this.) And since there is no guarantee regarding the marking of packets from the remote endpoint and through intermediate networks towards the device, there still needs to be a way to identify each flow to correctly reassign the markings! That is the purpose of my proposal.

So I agree with you that DSCP is required, but it is not sufficient.

Richard

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Jun 2012 09:17:02 +0200

> The more important reason for separating sessions is so that it is possible for the network to easily identify the IP packets associated with different media types for different QoS treatment. Blen…
As I stated in draft-alvestrand-rtp-sess-neutral, I heartily agree that 
RTP session separation is a poweful tool for letting the network give 
differential treatment to packets. What I don't agree with is the idea 
that this need for differential treatment aligns with media types.

Sometimes we need to treat two different media types the same. Sometimes 
we need to treat two flows of the same media type differently. Forcing 
them to be always separated on media type is a bad idea.

I don't believe the compound-ness of RTCP packets is relevant to this 
argument; within a single RTP session (without muxing), all the RTCP 
packets will be treated the same, which is how it should be if one uses 
RTP sessions to indicate the need for differential treatment from the 
network.
> DSCP has two other problems. There is no current mechanism defined for the application to direct the browser and/or OS to correctly mark the transmitted packets. (We could fix this.)
That's actually a WEBRTC problem, not an AVTCORE problem.
>   And since there is no guarantee regarding the marking of packets from the remote endpoint and through intermediate networks towards the device, there still needs to be a way to identify each flow to correctly reassign the markings!
I believe that's not how diffserv is supposed to work; the diffserv 
marking from the endpoint is supposed to give enough information for 
intermediate hops to remark according to policy.
I think the most common current practice is that the source host is 
diffserv-ignorant, and the first router takes on the task of diffserv 
classification, based on flows - but if we want end-to-end diffserv, 
that has to change.
>   That is the purpose of my proposal.
>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 7 Jun 2012 01:57:19 +0000

> them to be always separated on media type is a bad idea.

My position is that differential treatment aligns with different media lines rather than different media types. It seems natural to assign the same treatment to the RTP streams associated with a media line based on the negotiated payload types. Are you suggesting that different RTP streams associated with a media line may be selected for further differentiation? An application may enable/disable individual streams, but on what basis could the network assign different treatment to individual streams associated with a single media line? Or are you suggesting that multiplexing of media lines on a single transport connection be disabled when differential treatment is needed? I would prefer to have a solution where we can assign differential treatment to flows within a transport connection.

> RTP sessions to indicate the need for differential treatment from the

I'm afraid I don't follow your argument here. Let me just ask a simple question. Should RTCP packets get the same QoS treatment in the network as their corresponding RTP streams, or is it ok for them to be treated with some arbitrary other QoS?

> >   And since there is no guarantee regarding the marking of packets from
> the remote endpoint and through intermediate networks towards the device,
> there still needs to be a way to identify each flow to correctly reassign
> the markings!

I did not intend to say anything different; I just said it less precisely than you did. For the near future, diffserv markings will not generally survive transport through the internet. Depending on policy they may be remarked in a meaningful way or they may simply be remarked for best effort handling.

The situation is not as bad as it sounds since differential treatment in the access network (be it cable, DSL, or wireless access, but particularly for wireless access), is generally more important than treatment in the backbone. The access network will need to ensure that packets (flowing in either direction) are marked correctly to get the right treatment (or the access network will need to assign the treatment directly based on filtering without remarking).

The only way to intelligently remark packets for correct treatment in the access network (or to just identify them) is to define a simple filter that can be used to separate them from other packets sharing the transport connection (and 5-tuple). The filter has to be based on some characteristic of the IP packet payload since the TOS can't be trusted to have the right value.

Even if we assume your "common current practice" scenario, where the first router performs the diffserv classification, and subsequent routers remark so as to retain the assigned treatment end-to-end, the first router still needs to be told how to identify the packets associated with each assigned treatment.

Richard

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 07 Jun 2012 08:15:46 +0200

On 06/07/2012 03:57 AM, Ejzak, Richard P (Richard) wrote:
> My position is that differential treatment aligns with different media lines rather than different media types. It seems natural to assign the same treatment to the RTP streams associated with a media line based on the negotiated payload types.
That ("based on the negotiated payload types") is the part that doesn't 
seem natural to me.
>   Are you suggesting that different RTP streams associated with a media line may be selected for further differentiation? An application may enable/disable individual streams, but on what basis could the network assign different treatment to individual streams associated with a single media line? Or are you suggesting that multiplexing of media lines on a single transport connection be disabled when differential treatment is needed?
I'm suggesting that media lines should be grouped into RTP sessions, 
each of which is carried on a single transport connection. That's the 
reason why the BUNDLE extension is explicit about which sessions are 
part of the bundle; it's simple to define as many bundles as are needed 
in order to achieve one's differential-treatment goals.
>   I would prefer to have a solution where we can assign differential treatment to flows within a transport connection.
That's a complexity I don't see the need for. YMMV.
> I'm afraid I don't follow your argument here. Let me just ask a simple question. Should RTCP packets get the same QoS treatment in the network as their corresponding RTP streams, or is it ok for th…
Quibbling somewhat about whether "the same treatment" can be achieved 
A->B as B->A, but yes; I think that RTCP packets need to get the same 
treatment as their corresponding RTP streams.
This is achieved in BUNDLE by the fact that all RTP and RTCP packets in 
a bundle are on the same transport flow.
> Even if we assume your "common current practice" scenario, where the first router performs the diffserv classification, and subsequent routers remark so as to retain the assigned treatment end-to-e…
Good that we're agreeing here!

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 7 Jun 2012 11:19:50 -0400

> I'm afraid I don't follow your argument here. Let me just ask a simple question. Should RTCP packets get the same QoS treatment in the network as their corresponding RTP streams, or is it ok for th…

Depends on your need for RTCP. If you don't need it, it doesn't
matter. If you do need it, it is dangerous to give it lower priority,
as you may not get enough of it to be useable. We just had this
discussion on the "RTCP traffic class" thread - see also RFC 4594. So,
the answer is no, it is not OK, if by arbitrary you mean possibly a
lower service level. (Clearly, there is no problem (at our level) if
the RTCP gets put in a higher QOS service level, so that possibility
is OK.)

Regards
Marshall

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 7 Jun 2012 19:20:17 +0000

> That ("based on the negotiated payload types") is the part that doesn't

I only mean by this that QoS treatment can take into account the characteristics of the expected payload.  I don't think we differ here.

> >   I would prefer to have a solution where we can assign differential
> treatment to flows within a transport connection.

This seems to be the real issue.  We have a difference in understanding of requirements.  I thought that the multi session work was intended to remove the major limitations of the single session BUNDLE technique.  To me, the most significant limitation of BUNDLE is the inability to assign differential treatment to different media lines within a BUNDLE.  If we don't fix this I don't see a need to progress work on multi session within AVTCORE.  I agree with you that single session BUNDLE is adequate for all reasonable use cases without this requirement.  And differential treatment based on filtering on a SHIM header at the end of the IP payload is problematic in some implementations. 

Richard