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

[Harald Alvestrand <[e-mail]>]

On 06/12/2014 05:57 PM, Black, David wrote:
> 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?

I'd ask the chairs of avtext / avtcore for guidance on that.

If they don't see any more action on this front in the near future, I
would prefer to say as little as possible about the possibility - it
might happen in the future, it might not happen at all, or it might
happen in a fashion which makes whatever we say about it now be wrong.

If they don't see any action happening in the near future, the reference
should be removed from -taxonomy- too, of course.

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


-- 
Surveillance is pervasive. Go Dark.