Re: [Dart] Commentary on draft-york-00

["Black, David" <[e-mail]>]

Harald,

This explanation helps (thank you):

> 3.4.  Multiple RTP Sessions over one Media Transport
> 
>     [I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism
>     that allow several RTP Sessions to be carried over a single
>     underlying Media Transport.

[... snip ...]

> The -westerlund- draft expired this April. I have not heard of anyone
> pursuing it.

I believe that the westerlund-avtcore draft was the indirect source of
draft-york's assertion that multiple RTP sessions could be mixed on a
single 5-tuple.  In correcting that statement to say that RTP sessions
cannot be mixed on a UDP 5-tuple, would it be reasonable to make note
of that expired draft's proposal, possibly via a reference to the
avtext-taxonomy draft?

Thanks,
--David


> -----Original Message-----
> From: Dart [mailto:[e-mail]] On Behalf Of Harald Alvestrand
> Sent: Thursday, June 12, 2014 10:39 AM
> To: Ben Campbell
> Cc: [e-mail]
> Subject: Re: [Dart] Commentary on draft-york-00
> 
> On 06/12/2014 04:25 PM, Ben Campbell wrote:
> > Thanks Harald! I want to hit one particular comment:
> >
> > On Jun 12, 2014, at 7:49 AM, Harald Alvestrand <[e-mail]> wrote:
> >
> > [...]
> >
> >> "SCTP ... can be multiplexed with one or more RTP sessions". Actually we
> can only multiplex SCTP with a single RTP session. There have been proposals
> that would allow multiplexing of multiple RTP sessions (each containing
> multiple media flows) over a single 5-tuple, but these were not accepted.
> >>
> >>
> > [...]
> >
> >> In bullet 2, only one RTP session can be multiplexed with another transport
> protocol (again).
> > [...]
> >
> > Is this a matter of proper definitions of "RTP Session" vs "Media Flow"?
> (i.e. properly naming the thing that can be multiplexed?) Or is there a
> technical misunderstanding?
> >
> > Ben.
> The word "session" is one of the most horrible words in the vocabulary.....
> 
> RTP packet streams that are in the same RTP session can be multiplexed
> over the same 5-tuple.
> RTP packet streams that are from different RTP sessions cannot.
> 
> A media flow as you've defined it here (="packet stream" from
> -taxonomy-) is identified by its SSRC.
> 
> About "RTP Session", -taxonomy- has this definition:
> 
>   2.2.2.  RTP Session
> 
>     An RTP session is an association among a group of participants
>     communicating with RTP.  It is a group communications channel which
>     can potentially carry a number of Packet Streams.  Within an RTP
>     session, every participant can find meta-data and control information
>     (over RTCP) about all the Packet Streams in the RTP session.  The
>     bandwidth of the RTCP control channel is shared between all
>     participants within an RTP Session.
> 
>     Alternate usages:
> 
>     o  Within the context of SDP, a singe m=line can map to a single RTP
>        Session or multiple m=lines can map to a single RTP Session. The
>        latter is enabled via multiplexing schemes such as BUNDLE
>        [I-D.ietf-mmusic-sdp-bundle-negotiation], for example, which
>        allows mapping of multiple m=lines to a single RTP Session.
> 
>     Characteristics:
> 
>     o  Typically, an RTP Session can carry one ore more Packet Streams.
> 
>     o  An RTP Session shares a single SSRC space as defined in RFC3550
>        [RFC3550].  That is, the End Points participating in an RTP
>        Session can see an SSRC identifier transmitted by any of the other
>        End Points.  An End Point can receive an SSRC either as SSRC or as
>        a Contributing source (CSRC) in RTP and RTCP packets, as defined
>        by the endpoints' network interconnection topology.
> 
>     o  An RTP Session uses at least two Media Transports
>        (Section 2.1.13), one for sending and one for receiving.
>        Commonly, the receiving one is the reverse direction of the same
>        one as used for sending.  An RTP Session may use many Media
>        Transports and these define the session's network interconnection
>        topology.  A single Media Transport can normally not transport
>        more than one RTP Session, unless a solution for multiplexing
>        multiple RTP sessions over a single Media Transport is used. One
>        example of such a scheme is Multiple RTP Sessions on a Single
>        Lower-Layer Transport
>        [I-D.westerlund-avtcore-transport-multiplexing].
> 
>     o  Multiple RTP Sessions can be related.
> 
> About the possibility of putting multiple sessions on a single media
> transport, -taxonomy- says:
> 
> 3.4.  Multiple RTP Sessions over one Media Transport
> 
>     [I-D.westerlund-avtcore-transport-multiplexing] describes a mechanism
>     that allow several RTP Sessions to be carried over a single
>     underlying Media Transport.  The main reasons for doing this are
>     related to the impact of using one or more Media Transports. Thus
>     using a common network path or potentially have different ones.
>     There is reduced need for NAT/FW traversal resources and no need for
>     flow based QoS.
> 
>     However, Multiple RTP Sessions over one Media Transport makes it
>     clear that a single Media Transport 5-tuple is not sufficient to
>     express which RTP Session context a particular Packet Stream exists
>     in.  Complexities in the relationship between Media Transports and
>     RTP Session already exist as one RTP Session contains multiple Media
>     Transports, e.g. even a Peer-to-Peer RTP Session with RTP/RTCP
>     Multiplexing requires two Media Transports, one in each direction.
>     The relationship between Media Transports and RTP Sessions as well as
>     additional levels of identifiers need to be considered in both
>     signaling design and when defining terminology.
> 
> This is, in my opinion, a very longwinded way of saying "this doesn't
> exist".
> 
> The -westerlund- draft expired this April. I have not heard of anyone
> pursuing it.
> 
> 
> 
> _______________________________________________
> Dart mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dart