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

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Jun 2014 14:49:12 +0200

This message contains running notes made during my initial review of 
draft-york-dart-dscp-rtp-00.
Apologies for lack of organization; it seems better to get them out soon 
than to polish them.

2 Background

"any one or more modalities" -> "one or more modalities" would read better.

"RTP defines the mechanism by which real-time data is transmitted" seems 
like an overreach. "RTP defines a common encapsulation format and 
handling rules for real-time data transmitted over the Internet" would 
be more appropriate.

"With most applications, a single..." - this is true for legacy. It 
seems likely not to remain true.

The definition of "media flow" needs to be in a "definitions" section. 
It's too important to be hiding in the "background" section - see much 
other mail.

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

The mention of MediaStream should be removed from bullet 1. It just 
confuses.

In bullet 2, only one RTP session can be multiplexed with another 
transport protocol (again).

The last paragraph is where distinguishing between <some kind of media 
related name> and <RTP packet flow> is very desirable. As it stands now, 
it seems simple, but when you start asking what all these flows "are", 
more precisely, it gets very confusing.

2.1 DiffServ

bullet 1, first list: grammar nit - "classify traffic and setting bits" 
-> "classify traffic and set bits"

"In this context, "forwarding behavior" is a general - for example" .... 
is a general what, exactly?

"to allocates resources" -> "to allocate resources"

Nit: the all-zero DSCP seems to have only five zeroes.

2.2 Diffserv PHBs

do you want to mention what the difference between the 4 AF classes is? 
Is it just isolation, or is there a ranking between them (in theory or 
in practice)?

2.3 Diffserv and transport protocols

The last paragraph is true but irrelevant - we're not using UDP here, 
we're using other protocols carried inside UDP. And the stuff that's 
carried inside UDP may be sensitive to reordering or may be insensitive 
to reordering - we just can't tell purely from the fact that it's UDP.

Suggest deleting the paragraph.

IMPORTANT: There is a huge missing section here - which is about 
sensitivity of real time communications to packet reordering.

I'm not sure how much can be said here, but I think this is quite complex:

- Packet reordering may lead to spurious NACK generation and unneeded 
retransmission, just as for the data flow case. How sensitive it is to 
that depends on timers.

- Packet reordering that can be accomodated within an existing jitter 
buffer will not lead to any quality issues.

- Packet reordering that causes jitter buffers to extend is bad news for 
delay sensitive communication, such as interactive conversations. 
Interactive implementations may choose to discard late data - but this 
is a matter of meeting the deadline, not a matter of whether it's reordered.
For replay of recorded media, it doesn't matter much.

- Packet loss is dealt with differently on interactive media than on 
reliable data delivery: Instead of retransmissing all lost data, one 
finds a reference point that new data can be based on, and continues to 
transmit media relative to that. One does not attempt to recover lost 
frames that are history.
How that affects this discussion ... I'm not too sure.

2.4 DSCP remarking

The discussion of token-bucket-based remarkers leaves me a bit confused.
To me, it's obvious (?) that token-bucket-based remarkers would operate 
in color-blind mode on a network boundary, and in color-sensitive mode 
only when they had assurance that incoming markings were already 
indicating color. Thus, flows from an end-user system should only hit 
color-blind remarkers; the real question is: will a color-blind remarker 
use the incoming DSCP codepoint to decide which of a group of remarking 
treatments it chooses for the packets?

It seems to me that the section should tell me, and it doesn't.

3 RTP Multiplexing Background

Repeating the story about "only one RTP session per 5-tuple, please"....

4 Recommendations

As discussed above, the first SHOULD NOT (reordering within a media 
flow) is not sufficiently founded in discussion of media properties. 
Reordering may be a problem, or it may not be a problem.

I don't see any issues with the other recommendations (the second seems 
like an obvious thing to say, for well documented reasons; the three 
others seem like no-ops from a practical standpoint).

Thanks for getting this out the door!

---

From: Dan York <[email-masked]>
Date: Thu, 12 Jun 2014 13:37:28 +0000

Harald,

Thank you for all the editorial nits and other readability suggestions.  I'll incorporate those as I make a readability pass through the document.  I agree that a paragraph around the impact of packet re-ordering on RTCWEB would be useful and I can work on something using your bullets as a base.

I will leave responses to your other points to members of the author team who are more knowledgable in those areas than I.

Thanks,
Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

On Jun 12, 2014, at 8:49 AM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>>
 wrote:

This message contains running notes made during my initial review of draft-york-dart-dscp-rtp-00.
Apologies for lack of organization; it seems better to get them out soon than to polish them.

2 Background

"RTP defines the mechanism by which real-time data is transmitted" seems like an overreach. "RTP defines a common encapsulation format and handling rules for real-time data transmitted over the Internet" would be more appropriate.

"With most applications, a single..." - this is true for legacy. It seems likely not to remain true.

The definition of "media flow" needs to be in a "definitions" section. It's too important to be hiding in the "background" section - see much other mail.

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

The mention of MediaStream should be removed from bullet 1. It just confuses.

In bullet 2, only one RTP session can be multiplexed with another transport protocol (again).

The last paragraph is where distinguishing between <some kind of media related name> and <RTP packet flow> is very desirable. As it stands now, it seems simple, but when you start asking what all these flows "are", more precisely, it gets very confusing.

2.1 DiffServ

bullet 1, first list: grammar nit - "classify traffic and setting bits" -> "classify traffic and set bits"

"In this context, "forwarding behavior" is a general - for example" .... is a general what, exactly?

2.2 Diffserv PHBs

do you want to mention what the difference between the 4 AF classes is? Is it just isolation, or is there a ranking between them (in theory or in practice)?

The last paragraph is true but irrelevant - we're not using UDP here, we're using other protocols carried inside UDP. And the stuff that's carried inside UDP may be sensitive to reordering or may be insensitive to reordering - we just can't tell purely from the fact that it's UDP.

IMPORTANT: There is a huge missing section here - which is about sensitivity of real time communications to packet reordering.

- Packet reordering may lead to spurious NACK generation and unneeded retransmission, just as for the data flow case. How sensitive it is to that depends on timers.

- Packet reordering that can be accomodated within an existing jitter buffer will not lead to any quality issues.

- Packet reordering that causes jitter buffers to extend is bad news for delay sensitive communication, such as interactive conversations. Interactive implementations may choose to discard late data - but this is a matter of meeting the deadline, not a matter of whether it's reordered.
For replay of recorded media, it doesn't matter much.

- Packet loss is dealt with differently on interactive media than on reliable data delivery: Instead of retransmissing all lost data, one finds a reference point that new data can be based on, and continues to transmit media relative to that. One does not attempt to recover lost frames that are history.
How that affects this discussion ... I'm not too sure.

2.4 DSCP remarking

The discussion of token-bucket-based remarkers leaves me a bit confused.
To me, it's obvious (?) that token-bucket-based remarkers would operate in color-blind mode on a network boundary, and in color-sensitive mode only when they had assurance that incoming markings were already indicating color. Thus, flows from an end-user system should only hit color-blind remarkers; the real question is: will a color-blind remarker use the incoming DSCP codepoint to decide which of a group of remarking treatments it chooses for the packets?

4 Recommendations

As discussed above, the first SHOULD NOT (reordering within a media flow) is not sufficiently founded in discussion of media properties. Reordering may be a problem, or it may not be a problem.

I don't see any issues with the other recommendations (the second seems like an obvious thing to say, for well documented reasons; the three others seem like no-ops from a practical standpoint).

_______________________________________________
Dart mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dart

---

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Jun 2014 09:25:53 -0500

Thanks Harald! I want to hit one particular comment:

On Jun 12, 2014, at 7:49 AM, Harald Alvestrand <[email-masked]> 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 s…

[...]

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Jun 2014 16:38:49 +0200

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

---

From: "Black, David" <[email-masked]>
Date: Thu, 12 Jun 2014 11:57:16 -0400

Harald,

This explanation helps (thank you):

>     underlying Media Transport.

[... snip ...]

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

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:[email-masked]] On Behalf Of Harald Alvestrand
> Sent: Thursday, June 12, 2014 10:39 AM
> To: Ben Campbell
> Cc: [email-masked]
> Subject: Re: [Dart] Commentary on draft-york-00
> 
> 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.
> >>
> >>
> > [...]
> >
> > 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.
> [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Jun 2014 20:19:53 +0200

> of that expired draft's proposal, possibly via a reference to the

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.

-- 
Surveillance is pervasive. Go Dark.

---

From: "Black, David" <[email-masked]>
Date: Fri, 13 Jun 2014 01:43:12 -0400

Harald,

Many thanks for the review and commentary, especially for the discussion
of real time traffic sensitivity to reordering.  This note is an attempt
to pick up non-editorial items that haven't been dealt with in other
messages on the list. I see four of them:

[1]
> Is it just isolation, or is there a ranking between them (in theory or

Sure, there is a ranking between them.  In general, higher numbered
AF classes are expected to receive better forwarding behavior roughly akin
to higher numbered class selector codepoints being expected to receive
better forwarding behavior.

[2]
> Suggest deleting the paragraph.

I agree with the point, but rather than deleting the paragraph, I'd
suggest expanding it to include discussion of the use of UDP to
encapsulate protocols that are sensitive to reordering.  One of
the reasons for the existence of this paragraph is that it sets up
the allowance for use of multiple PHBs that may cause reordering
within a single UDP 5-tuple.

[3]
> sensitivity of real time communications to packet reordering.

I agree, and thank you for the more detailed explanation that can be
used as a starting point to write this section.

[4]
> treatments it chooses for the packets?

I'm not sure about the "obvious" point - anyone care to comment on what's
actually deployed/configured in practice?

The answer to the final question about choice of remarking treatment is
"yes" although the PHBs in an AF class should receive the same treatment.
The fact that the question was asked suggests that the discussion of
traffic classifiers needs some additional clarity and explanation.

Thanks,
--David

> Sent: Thursday, June 12, 2014 8:49 AM
> To: [email-masked]
> Subject: [Dart] Commentary on draft-york-00
>

---

From: <[email-masked]>
Date: Fri, 13 Jun 2014 10:04:35 +0200

Hi David,

to answer the question related to implementations and configurations at least from the viewpoint of one network provider

- you can support a multi-vendor strategy. This makes sense 
  from an economical point of view, but limits 
  deployments to the minimum common denominator.

- to configure a PHB, there are classifiers, policers, 
  schedulers, AQM and re-markers.   
  Implementations differ to some aspects (e.g. on 
  supported number of classes and ingress/egress remarking).
  Limits like less than 20 PHBs may apply today.
  I'd be interested, whether there are offers of any 
  complete AF class as part of a single product. 
  
- there used to be a possibility to ignore the lower DSCP 
  bits 3-6, but there's no standard to that. Some vendors 
  removed this option and with IPv6, each PHB must be 
  classified and completely configured individually by DSCP.
  Please be aware, if it comes to a re-write, a single DSCP 
  is set for all incoming DSCPs matching this PHB. Keep in 
  mind the possible restrictions on the number of PHBs. 

- many IP/MPLS backbone networks and also many Ethernet 
  based access networks support 3-4 PHBs for retail services.
  I'm not aware of any two providers using exactly the 
  same DSCPs. I'm also not aware of any two standards using fully 
  matching DSCPs for their PHBs (IETF, GSMA, MEF).

- There's something I'd call enterprise philosophy, that is 
  making use of a large set of internal PHBs. I never saw 
  any of these philosophies remotely resembling the other. 
  PHBs or classes are used to identify products, 
  access types, stream types and so on. These usually just 
  consume PHBs with sometimes at best loose relation to 
  standards.

If end-to-end DiffServ PHBs are what you look for, standardise what is really required and be clear on how to use it. If a network provider is expected to support these PHBs, there must be a convincing reason to do so. Take EF as an example for a well specified DiffServ standard. 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Dart [mailto:[email-masked]] Im Auftrag von Black, David
Gesendet: Freitag, 13. Juni 2014 07:43
An: Harald Alvestrand; [email-masked]
Betreff: Re: [Dart] Commentary on draft-york-00

   Harald,

RG: [snip]

   [4]
   > To me, it's obvious (?) that token-bucket-based remarkers would 
   > operate in color-blind mode on a network boundary, and in 
   > color-sensitive mode only when they had assurance that incoming 
   > markings were already indicating color. Thus, flows from an end-user 
   > system should only hit color-blind remarkers; the real question is: 
   > will a color-blind remarker use the incoming DSCP codepoint to decide 
   > which of a group of remarking treatments it chooses for the packets?

   Thanks,
   --David

---

From: "Black, David" <[email-masked]>
Date: Fri, 13 Jun 2014 09:24:16 -0400

Hi Ruediger

>   classified and completely configured individually by DSCP.

That's a good thing, since that behavior (per DSCP traffic
handling) is a core element of the DiffServ architecture,
and is required by RFC 2474 (Section 3).

>   mind the possible restrictions on the number of PHBs.

Full AF support should classify all 3 PHBs that make up an AF
class into a single aggregate on the node, with remarking applied
to that aggregate, not DSCP by DSCP.

> If end-to-end DiffServ PHBs are what you look for, standardize
> what is really required and be clear on how to use it.

As noted earlier, that's not the goal of the dart WG, as I
understand it.  I believe the goal of this short term WG is
to describe what exists and provide guidance on how to use
it, particularly for RTCWEB.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 13, 2014 4:05 AM
> To: Black, David
> Cc: [email-masked]
> Subject: AW: [Dart] Commentary on draft-york-00
> 
> Hi David,
> 
> to answer the question related to implementations and configurations at least
> from the viewpoint of one network provider
> 
> If end-to-end DiffServ PHBs are what you look for, standardise what is really
> required and be clear on how to use it. If a network provider is expected to
> support these PHBs, there must be a convincing reason to do so. Take EF as an
> example for a well specified DiffServ standard.
> 
> Regards,
> 
> Ruediger
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 15 Jun 2014 04:52:38 +0000

Harald,

>"SCTP ... can be multiplexed with one or more RTP sessions". Actually 
>we can only multiplex SCTP with a single RTP session. There have been 

Your draft (draft-ietf-rtcweb-transports) says:

     RTCWEB implementations MUST support multiplexing of DTLS and RTP 
over
     the same port pair, as described in the DTLS_SRTP specification
     [RFC5764], section 5.1.2. All application layer protocol payloads
     over this DTLS connection are SCTP packets.

I had a question about this as we discussed the DART draft.  I assumed 
the only DTLS connection would be one used for key negotiation for SRTP. 
  Is that not the case? Would there be multiple DTLS connections 
multiplexed?  If so, how would one be differentiated from another?

As for RTP Session multiplexing, it's interesting to hear that proposals 
are dead.  Is there a proposal for multiplexing different media types 
(e.g., audio and video) within the same RTP Session, then?  RFC 3550 
discourages that, but it was my understanding that browser makers wanted 
to multiplex the different media types somehow.  What's the plan?

Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 15 Jun 2014 09:18:09 +0200

(Adding EKR to thread to get a definitive DTLS answer)

On 06/15/2014 06:52 AM, Paul E. Jones wrote:
>> proposals that would allow multiplexing of multiple RTP sessions
>> (each containing multiple media flows) over a single 5-tuple, but
>> these were not accepted.
>
>     RTCWEB implementations MUST support multiplexing of DTLS and RTP over
> the only DTLS connection would be one used for key negotiation for
> SRTP.  Is that not the case? Would there be multiple DTLS connections

EKR is the expert here.

As I understand it, the key material for DTLS-SRTP is derived from the
session keys from the DTLS session. This does not in any way affect the
usage of the same DTLS session for passing DTLS data.

>
> As for RTP Session multiplexing, it's interesting to hear that
> proposals are dead.  Is there a proposal for multiplexing different
> media types (e.g., audio and video) within the same RTP Session,
> then?  RFC 3550 discourages that, but it was my understanding that
> browser makers wanted to multiplex the different media types somehow. 
> What's the plan?

draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects.
draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP.

The only thing in RTP itself that prevents such multiplexing is the
words in RFC 3550; technically there is no barrier at the RTP level.

At the SDP level things are a bit more complex, which is why -bundle-
isn't an RFC yet.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 15 Jun 2014 10:24:23 -0400

Harald,

Thanks for the clarification. If you'll indulge, allow me to ask one more basic question...

In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to explain that multiplexing is on the SSRC. It also says no two media sources shall use the same PT value. Thus, a payload type could be used when demultiplexing, though the text says otherwise. Perhaps this language exists to support multipoint?  Thus, a receiver first looks at the SSRC to identify the source, then the PT to determine what the packet contains? Is SSRC demuxing there only for multipoint?

Why not allow the PT number space to be distinct per SSRC?

Paul

-------- Original Message --------
From: Harald Alvestrand <[email-masked]>
Sent: June 15, 2014 3:18:09 AM EDT
To: "Paul E. Jones" <[email-masked]>, [email-masked], Eric Rescorla <[email-masked]>
Subject: Re: multiplexing different media types

EKR is the expert here.

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 15 Jun 2014 16:35:45 +0200

On 06/15/2014 04:24 PM, Paul E. Jones wrote:
> In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to 
> explain that multiplexing is on the SSRC. It also says no two media 
> sources shall use the same PT value.
>

No, it does not say that - in fact, it says exactly the opposite.

It says that it cannot use the same SSRC for two different media streams 
and depend on PT to distinguish between them. PT is not a multiplexing 
point.

The PT value is a single byte, and is sometimes used for other purposes 
(with RTP/RTCP multiplexing, for example, some numbers are unusable 
because RTCP uses the same field for operation codes). Trying to use it 
to distinguish between streams would reduce the max number of possible 
streams to a seriously ridiculously low number.

Can you point me at the language you interpreted that way? If it can be 
read that way, it *must* be changed.

> Thus, a payload type could be used when demultiplexing, though the 
> text says otherwise. Perhaps this language exists to support 
> multipoint?  Thus, a receiver first looks at the SSRC to identify the 
> source, then the PT to determine what the packet contains? Is SSRC 
> demuxing there only for multipoint?
>

No. The PT tells the receiver what format the packet contains. The SSRC 
tells you which RTP packet flow it belongs to. In some cases one RTP 
packet flow will switch between different payload types (audio, DTMF and 
comfort noise being the most common examples), while still representing 
only one media flow.

> Why not allow the PT number space to be distinct per SSRC?

I have problems parsing this question into the context above. What are 
you asking?

> Paul
>
>
>
> ------------------------------------------------------------------------
> *From:* Harald Alvestrand <[email-masked]>
> *Sent:* June 15, 2014 3:18:09 AM EDT
> *To:* "Paul E. Jones" <[email-masked]>, [email-masked], Eric 
> Rescorla <[email-masked]>
> *Subject:* Re: multiplexing different media types
>
>         "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. 
>
>     Your draft (draft-ietf-rtcweb-transports) says: RTCWEB
>     implementations MUST support multiplexing of DTLS and RTP over the
>     same port pair, as described in the DTLS_SRTP specification
>     [RFC5764], section 5.1.2. A! ll application layer protocol
>     payloads over this DTLS connection are SCTP packets. I had a
>     question about this as we discussed the DART draft. I assumed the
>     only DTLS connection would be one used for key negotiation for
>     SRTP. Is that not the case? Would there be multiple DTLS
>     connections multiplexed? If so, how would one be differentiated
>     from another? 
>
>
> EKR is the expert here.
>
>     media types (e.g., audio and video) within the sa! me RTP Session,
>     browser makers wanted to multiplex the different media types
>     somehow. What's the plan? 
>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 15 Jun 2014 11:30:57 -0400

Harald,

I think we're saying the same thing. The multiplexing point is the SSRC, correct?

I said two media sources cannot use the same PT. Effectively, all PT values used by an endpoint sending media are distinct. Is that correct?

My last question below is trying to understand why its not allowed for SSRC1 and SSRC2, perhaps one being an audio source and one being a video source, to use PT 97, for example. I think that's presently not allowed, but not sure why since demux occurs on the SSRC.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 15 Jun 2014 12:18:13 -0400

Eric,

Sorry, I should have been clearer in preparing the question. When I was referring to media sources, I had completely different types in mind (e.g., audio and video).

What I am trying to understand is why there is this statement in the guidelines draft:

"The payload type is scoped by sending endpoint within an RTP Session. All synchronisation sources sent from an single endpoint share the same payload types definitions."

Clearly, that is legal. But, I'm curious why we maintain this restriction.  Since a receiver will demux incoming packets via the SSRC, it seems the PT values associated with a given SSRC could be distinct from another SSRC.

Presently for a given sender, there is a "global" definition of PT values (96 for some specific audio format, 97 for some specific video format, ...) and those can be used by multiple SSRCs.  So I'm asking why we don't allow {SSRC1: (96, 97), SSRC2: (96, 97), ...}, where each 96 could be different formats.

Paul

-------- Original Message --------
From: Eric Rescorla <[email-masked]>
Sent: June 15, 2014 11:41:09 AM EDT
To: "Paul E. Jones" <[email-masked]>
Cc: Harald Alvestrand <[email-masked]>, [email-masked]
Subject: Re: multiplexing different media types

On Sun, Jun 15, 2014 at 8:30 AM, Paul E. Jones <[email-masked]>
wrote:

> I said two media sources cannot use the same PT. Effectively, all PT
> values used by an endpoint sending media are distinct. Is that correct?
>

No. Two media sources that are sending the same type of media
(e.g., two streams of VP8) from the same endpoint can use the same
PT as long as the SSRCs are different. See:

http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.2.1.2

-Ekr

My last question below is trying to understand why its not allowed for
> SSRC1 and SSRC2, perhaps one being an audio source and one being a video
> source, to use PT 97, for example. I think that's presently not allowed,
> but not sure why since demux occurs on the SSRC.
>
> Paul
>
>
> ------------------------------
> *Sent:* June 15, 2014 10:35:45 AM EDT
>
> explain that multiplexing is on the SSRC. It also says no two media sources
> shall use the same PT value.
>
>
> (with RTP/RTCP multiplexing, for example, some numbers are unusable because
> RTCP uses the same field for operation codes). Trying to use it to
> distinguish between streams would reduce the max number of possible streams
> to a seriously ridiculously low number.
>
>  Thus, a payload type could be used when demultiplexing, though the text
> says otherwise. Perhaps this language exists to support multipoint?  Thus,
> a receiver first looks at the SSRC to identify the source, then the PT to
> determine what the packet contains? Is SSRC demuxing there only for
> multipoint?
>
>
> tells you which RTP packet flow it belongs to. In some cases one RTP packet
> flow will switch between different payload types (audio, DTMF and comfort
> noise being the most common examples), while still representing only one
> media flow.
>
>
> I have problems parsing this question into the context above. What are you
> asking?
>
>  Paul
>
>
>  ------------------------------
> *From:* Harald Alvestrand <[email-masked]> <[email-masked]>
> *To:* "Paul E. Jones" <[email-masked]> <[email-masked]>,
> [email-masked], Eric Rescorla <[email-masked]> <[email-masked]>
>>      [RFC5764], section 5.1.2. A!
>>  ll
>> application layer protocol payloads
>>  media types (e.g., audio and video) within the sa!
>>  me RTP
>> Session,

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 15 Jun 2014 18:26:01 +0000

Eric,

The reason is to free the endpoint from what I think might be an 
unnecessary constraints.

>From the multiplexing guidelines draft, we have this:

| | packets +-- v | +------------+ | | Socket | | +------------+ | || || 
RTP | RTP/ || |+-----> SCTP ( ...and any other protocols) Session | RTCP 
|| +------> STUN (multiplexed using same port) +-- || +-- || | (split by 
SSRC) | || || || | || || || Media | +--+ +--+ +--+ Streams | |PB| |PB| 
|PB| Jitter buffer, process RTCP, FEC, etc. | +--+ +--+ +--+ +-- | | | 
(pick rending context based on PT) +-- | / | | +---+ | | / | | Payload | 
+--+ +--+ +--+ Formats | |CR| |CR| |CR| Codecs and rendering | +--+ +--+ 
+--+ +--

So the PT value only has practical significance within the context of a 
given SSRC (which maps directly to a specific media source), as it's 
that point in the code where some application component (e.g., the audio 
component) will look at the packets.  Given the fact that the PT number 
space is fairly limited, having PT associated only with a given SSRC 
makes it possible for any media source to have a fairly extensive number 
of values.

If there is a complex system sending a lots of different media formats, 
sending FEC information (which I assume would still use the same SSRC), 
perhaps RFC 2198 redundancy PT, etc., it's possible that the number of 
different payload types might go beyond the number currently allocated 
as dynamic PT values.  This has not been an issue until now, since 
systems would usually use separate RTP sessions for different media 
sources, which means the endpoint is less constrained by the numbering 
space for PT values.

Now that the plan is to multiplex media over the same port and using the 
SSRC to differentiate one media source from the other, each media source 
potentially using a multiplicity of payload type values, I think there 
might be benefit in not imposing the restriction of "all synchronisation 
sources sent from an single endpoint share the same payload types 
definitions."

So lifting this restriction,
* a video source could define PT 96, 97, 98, and 99 for it's purpose
* an audio source could define PT 96, 97, 98, 99, 100, 101 for its 
purpose
* a file transfer component could use PT 96 (this might go over the data 
channel, but indulge me)
* etc.

In terms of writing code, this could allow for further separation of 
application components.  There is no need for the audio component to 
coordinate with the whiteboarding component or video component or 
whatever when deciding what payload type values to use.  I can imagine 
how these different components might be developed by different teams, 
with all of the independent components easily plugging in together to 
share an RTP session.  Forcing the use of a "global" set of PT 
definition forces additional coordination between these application 
component teams and more complexity in the internal application 
interfaces.  If each component can be developed and maintained in 
isolation as much as possible, the easier it will be to mix/match 
components in the browser and to share the single RTP session.  It also 
make orchestration between those components a bit easier.  At least 
that's my opinion. :-)

I'm not suggesting the current text is wrong, but I am curious why we 
might not want to lift that global payload type definition restriction.

Paul

------ Original Message ------
From: "Eric Rescorla" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: "Harald Alvestrand" <[email-masked]>; [email-masked]
Sent: 6/15/2014 1:01:29 PM
Subject: Re: multiplexing different media types

>
>
>
>On Sun, Jun 15, 2014 at 9:18 AM, Paul E. Jones <[email-masked]> 
>wrote:
>>Eric,
>>
>>Sorry, I should have been clearer in preparing the question. When I 
>>was referring to media sources, I had completely different types in 
>>mind (e.g., audio and video).
>>
>>"The payload type is scoped by sending endpoint within an RTP Session. 
>>All synchronisation sources sent from an single endpoint share the 
>>same payload types definitions."
>>
>>Clearly, that is legal. But, I'm curious why we maintain this 
>>restriction.  Since a receiver will demux incoming packets via the 
>>SSRC, it seems the PT values associated with a given SSRC could be 
>>distinct from another SSRC.
>>
>>Presently for a given sender, there is a "global" definition of PT 
>>values (96 for some specific audio format, 97 for some specific video 
>>format, ...) and those can be used by multiple SSRCs.  So I'm asking 
>>why we don't allow {SSRC1: (96, 97), SSRC2: (96, 97), ...}, where each 
>>96 could be different formats.
>>
>What would be the virtue of doing that?
>
>-Ekr
>
[snip]

---

From: <[email-masked]>
Date: Mon, 16 Jun 2014 08:54:04 +0200

Hi David,

to make sure we mean the same thing on AF, re-marking and PHB consumption:

If a network provider just supports aggregated classes and that provider must use DSCP based classification then

Incoming AF4n -> outgoing AF4 with a cost of 1 local PHB is (for example):

Incoming DSCP 100 010 -> outgoing DSCP 100 010    PHB AF41
Incoming DSCP 100 100 -> outgoing DSCP 100 010    PHB AF41
Incoming DSCP 100 110 -> outgoing DSCP 100 010    PHB AF41

The other option, with a cost of 3 local PHBs is

Incoming DSCP 100 010 -> outgoing DSCP 100 010    PHB AF41
Incoming DSCP 100 100 -> outgoing DSCP 100 100    PHB AF42
Incoming DSCP 100 110 -> outgoing DSCP 100 110    PHB AF43

If there was an additional possibility to classify based on 
DSCP bits 0-2, the second option can be configured with a cost 
of 1 local PHB (results in an aggregate / single local PHB for 
the provider and 3 DSCPs for an application or a device closer 
to the network edge). 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Black, David [mailto:[email-masked]] 
Gesendet: Freitag, 13. Juni 2014 15:24
An: Geib, Rüdiger
Cc: [email-masked]
Betreff: RE: [Dart] Commentary on draft-york-00

Hi Ruediger

That's a good thing, since that behavior (per DSCP traffic
handling) is a core element of the DiffServ architecture, and is required by RFC 2474 (Section 3).

>   mind the possible restrictions on the number of PHBs.

Full AF support should classify all 3 PHBs that make up an AF class into a single aggregate on the node, with remarking applied to that aggregate, not DSCP by DSCP.

> If end-to-end DiffServ PHBs are what you look for, standardize what is 
> really required and be clear on how to use it.

As noted earlier, that's not the goal of the dart WG, as I understand it.  I believe the goal of this short term WG is to describe what exists and provide guidance on how to use it, particularly for RTCWEB.

Thanks,
--David

> to answer the question related to implementations and configurations 
> at least from the viewpoint of one network provider
> 
> If end-to-end DiffServ PHBs are what you look for, standardise what is 
> really required and be clear on how to use it. If a network provider 
> is expected to support these PHBs, there must be a convincing reason 
> to do so. Take EF as an example for a well specified DiffServ standard.
> 
> Regards,
> 
> Ruediger
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 16 Jun 2014 14:39:42 +0200

Paul,

this is one of the (many) things that seem extremely simple when we look
at the RTP level, but devolves into dastardly complexity when we
consider SDP as a description protocol, and the claim is made that the
restriction is also embedded into many RTP/SDP/SIP implementations.

SDP uses a per m-line field to describe a payload type, without
indicating which SSRC these payload types are intended to belong to.
Traditionally, one m-line described one RTP session. So colliding PTs
inside one RTP session simply couldn't work.

As I've heard the arguments in the context of the BUNDLE draft, there
are implementations that expected this state of things to last forever,
and do not do any SSRC signalling - so when they see a new SSRC, they
look at its payload type to decide what kind of flow it is.

In a context where something different than SDP is used, and SSRCs are
always described explicitly, what you suggest is easy.

When using SDP, with either non-explicit SSRC signaling or multiple
media flows per m-line, it is hard.

I'll return later to why I think the problem is not so great as you
describe below, but that's enough of a topic to deserve another message.

On 06/15/2014 08:26 PM, Paul E. Jones wrote:
> Eric,
>  
> The reason is to free the endpoint from what I think might be
> an unnecessary constraints.
>  
>                            |
>                            | packets
>            +--             v
>            |        +------------+
>            |        |   Socket   |
>            |        +------------+
>            |            ||  ||
>       RTP  |       RTP/ ||  |+-----> SCTP ( ...and any other protocols)
>    Session |       RTCP ||  +------> STUN (multiplexed using same port)
>            +--          ||
>            +--          ||
>            |      (split by SSRC)
>            |       ||   ||   ||
>            |       ||   ||   ||
>      Media |      +--+ +--+ +--+
>    Streams |      |PB| |PB| |PB| Jitter buffer, process RTCP, FEC, etc.
>            |      +--+ +--+ +--+
>            +--      |   |     |
>            (pick rending context based on PT)
>            +--      |  /      |
>            |        +---+     |
>            |         /  |     |
>    Payload |      +--+ +--+ +--+
>    Formats |      |CR| |CR| |CR| Codecs and rendering
>            |      +--+ +--+ +--+
>            +--
>  
> So the PT value only has practical significance within the context of
> a given SSRC (which maps directly to a specific media source), as it's
> that point in the code where some application component (e.g., the
> audio component) will look at the packets.  Given the fact that the PT
> number space is fairly limited, having PT associated only with a given
> SSRC makes it possible for any media source to have a fairly extensive
> number of values.
>  
> If there is a complex system sending a lots of different media
> formats, sending FEC information (which I assume would still use the
> same SSRC), perhaps RFC 2198 redundancy PT, etc., it's possible that
> the number of different payload types might go beyond the number
> currently allocated as dynamic PT values.  This has not been an issue
> until now, since systems would usually use separate RTP sessions for
> different media sources, which means the endpoint is less constrained
> by the numbering space for PT values.
>  
> Now that the plan is to multiplex media over the same port and using
> the SSRC to differentiate one media source from the other, each media
> source potentially using a multiplicity of payload type values, I
> think there might be benefit in not imposing the restriction of "all
> synchronisation sources sent from an single endpoint share the same
> payload types definitions."
>  
> * an audio source could define PT 96, 97, 98, 99, 100, 101 for its purpose
> * a file transfer component could use PT 96 (this might go over the
> data channel, but indulge me)
> * etc.
>  
> components in the browser and to share the single RTP session.  It
> also make orchestration between those components a bit easier.  At
> least that's my opinion. :-)
>  
> From: "Eric Rescorla" <[email-masked] <mailto:[email-masked]>>
> To: "Paul E. Jones" <[email-masked] <mailto:[email-masked]>>
> Cc: "Harald Alvestrand" <[email-masked]
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> On Sun, Jun 15, 2014 at 9:18 AM, Paul E. Jones <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     Eric,
>>
>>     Sorry, I should have been clearer in preparing the question. When
>>     I was referring to media sources, I had completely different
>>     types in mind (e.g., audio and video).
>>
>>     "The payload type is scoped by sending endpoint within an RTP
>>     Session. All synchronisation sources sent from an single endpoint
>>     share the same payload types definitions."
>>
>>     restriction.  Since a receiver will demux incoming packets via
>>     the SSRC, it seems the PT values associated with a given SSRC
>>     could be distinct from another SSRC.
>>
>>     Presently for a given sender, there is a "global" definition of
>>     PT values (96 for some specific audio format, 97 for some
>>     specific video format, ...) and those can be used by multiple
>>     SSRCs.  So I'm asking why we don't allow {SSRC1: (96, 97), SSRC2:
>>     (96, 97), ...}, where each 96 could be different formats.
>>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Jun 2014 07:20:24 -0700

> usage of the same DTLS session for passing DTLS data.

Each transport pair is attached to one DTLS association.

If you mux media and data channels on the same transport pairs,
you have one DTLS association. You derive SRTP keys from the
DTLS keys and send SRTP over the same transport.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Jun 2014 07:30:54 -0700

On Sun, Jun 15, 2014 at 7:24 AM, Paul E. Jones <[email-masked]>
wrote:

> shall use the same PT value. Thus, a payload type could be used when
> demultiplexing, though the text says otherwise. Perhaps this language
> exists to support multipoint?  Thus, a receiver first looks at the SSRC to
> identify the source, then the PT to determine what the packet contains? Is
> SSRC demuxing there only for multipoint?
>
This is an inconsistency in the drafts. See:
http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00

for extensive documentation of the issues at hand and the
current plan of record.

-Ekr

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Jun 2014 08:41:09 -0700

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Jun 2014 10:01:29 -0700

On Sun, Jun 15, 2014 at 9:18 AM, Paul E. Jones <[email-masked]>
wrote:

> Eric,
>
> Sorry, I should have been clearer in preparing the question. When I was
> referring to media sources, I had completely different types in mind (e.g.,
> audio and video).
>
> "The payload type is scoped by sending endpoint within an RTP Session. All
> synchronisation sources sent from an single endpoint share the same payload
> types definitions."
>
> restriction.  Since a receiver will demux incoming packets via the SSRC, it
> seems the PT values associated with a given SSRC could be distinct from
> another SSRC.
>
> Presently for a given sender, there is a "global" definition of PT values
> (96 for some specific audio format, 97 for some specific video format, ...)
> and those can be used by multiple SSRCs.  So I'm asking why we don't allow
> {SSRC1: (96, 97), SSRC2: (96, 97), ...}, where each 96 could be different
> formats.
>

-Ekr

> *From:* Eric Rescorla <[email-masked]>
> *Sent:* June 15, 2014 11:41:09 AM EDT
>
> *To:* "Paul E. Jones" <[email-masked]>
> *Cc:* Harald Alvestrand <[email-masked]>, [email-masked]
>