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

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

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

Section 2.4 in draft-york starts with:

   DSCP markings are not end-to-end in general.

Given that we're having this discussion, it sounds like section
2.4 should be blunter in discussing how differentiation may
be lost via remarking.

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

That looks like some blunter text to start from ...

Thanks,
--David

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Wednesday, June 11, 2014 9:39 PM
> To: Dan Wing
> Cc: Black, David; [e-mail]
> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple
> 
> 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.
> 
>     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
> >
> >