Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple

[Dan Wing <[e-mail]>]

On Jun 11, 2014, at 6:39 PM, Brian E Carpenter <[e-mail]> wrote:

> On 12/06/2014 12:32, Dan Wing wrote:
>> On Jun 11, 2014, at 1:42 PM, Brian E Carpenter <[e-mail]> wrote:
>> 
>>> On 11/06/2014 07:59, Black, David wrote:
>>>> In another message, Ruediger Geib asked (>), and I responded:
>>>> 
>>>> --------------------
>>>> 
>>>>> Is the following correct:
>>>>> 
>>>>> UDP_5-tuple-+--transport protocol 1-----
>>>>>           |
>>>>>           +--RTP session 1-----
>>>>>           |
>>>>>           +--RTP session 2-----+---RTP_stream_2.1
>>>>>                                |
>>>>>                                +---RTP_stream_2.2
>>>>>                                |...
>>>> Yes, that matches my understanding, although the author team would like to
>>>> see discussion of whether it's a good idea to mix RTP and non-RTP protocols
>>>> on the same 5-tuple - I'll copy your useful diagram into a separate message
>>>> to start that discussion.
>>>> 
>>>> --------------------
>>>> 
>>>> This is that message, and I want to thank Ruediger for drawing that useful
>>>> diagram.
>>>> 
>>>> The author team for draft-york would like input on whether the draft should
>>>> discuss mixing of RTP and non-RTP traffic on the same UDP 5-tuple, vs. using
>>>> separate 5-tuples (probably separate UDP ports) for RTP and non-RTP traffic.
>>> One observation is that we should be thinking about a 6-tuple these
>>> days (see RFC 6437). I don't think it makes much difference to the argument.
>>> 
>>> Another observation is when load balancing is in play, things get a bit
>>> more complicated, but to a first approximation using the same 5-tuple
>>> or 6-tuple will usually ensure that all the packets reach the same
>>> load-balanced destination, which is probably a good thing.
>>> 
>>> Third, reverting to the diffserv discussion, the same 5-tuple
>>> should ensure that all the packets would be classified the same
>>> (if they cross a diffserv domain boundary and get reclassified).
>> 
>> What do you mean by 'all the packets would be classified the same'?  If you mean all the packets in a 5-tuple would get the same differentiated treatment, that is not desirable, because there are lots of folks wanting to send video i-frames or packets with FEC or other stuff with lower drop precedence than other packets.
> 
> Dan, if a packet crosses a diffserv domain boundary,
> the assumption is that (absent a specific SLA) its
> DSCP *will* be rewritten in whatever way the classifier
> of the receiving domain desires. DSCPs don't have end to
> end semantics, unless there is a string of SLAs along
> the path that all provide the same DSCP semantics.
> 
> Not everybody likes this, but it was what the operators
> in the diffserv WG wanted at the time.
> 
> If all operators agree to implement a common subset of
> the DSCPs suggested in various TSVWG documents, there would
> be a de facto end to end SLA for those DSCPs. But today,
> that's a bit of a dream world. So, for two arbitrary
> RTCweb users, there's certainly no assurance that the
> DSCP set at the source will be preserved until the
> destination. On the contrary, it's quite likely to
> be set to zero (at the boundary of an operator that
> distrusts the DSCP field) or to a value deemed suitable
> by an ingress classifier for whatever 5-tuple it carries.
> It seems unlikely that a classifier will look further
> into the payload than the port numbers.

So, by "all packets will be classified the same", you mean reset to zero.

-d


> 
>    Brian
> 
>> -d
>> 
>> 
>>>   Brian
>>> 
>>>> RTCWEB clearly intends to mix SCTP (via DTLS) and RTP traffic on the same
>>>> 5-tuple see the last paragraph of Section 3.5 of draft-ietf-rtcweb-transports-04:
>>>> 
>>>>  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.
>>>> 
>>>> OTOH, concerns have been expressed about whether the not-exactly-elegant
>>>> demux processing specified in the reference (RFC 5764, Section 5.1.2) ought
>>>> to be recommended as a good way of doing this multiplexing.
>>>> 
>>>> Please comment, including whether mixing SCTP and RTP on the same UDP
>>>> 5-tuple is a good idea (some rationale for doing this sort of multiplexing
>>>> onto a single 5-tuple can be found in Section 3 of draft-york-dart-dscp-rtp-00).
>>>> 
>>>> Thanks,
>>>> --David
>>>> ----------------------------------------------------
>>>> David L. Black, Distinguished Engineer
>>>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>>>> [phone]             FAX: [phone]
>>>> [e-mail]        Mobile: [phone]
>>>> ----------------------------------------------------
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Dart mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dart
>>>> 
>>> _______________________________________________
>>> Dart mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dart
>> 
>> 
> 
> _______________________________________________
> Dart mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dart