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

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

Ruediger,

> to be a bit more specific about the constraints: if certain PHBs
> and may be DSCPs are desired, then we will have to standardize
> them and pay attention to the way they are produced in different
> network sections along an end to end path.

I agree, but that's not going to happen as part of this dart work
- PHBs and DSCPs are not end-to-end as things stand, and the dart
WG goal as I understand it is to describe how things work today and
provide guidance on what to do and not do in using PHBs/DSCPs at
endpoints to minimize surprises.

In preliminary discussions in London that lead to forming the dart WG,
some of the RAI & RTCWEB folks were ok with the QoS differentiation
getting removed by the network (e.g., by a diffserv edge node that
remarks all of the traffic involved to best effort (DF)) - if the
original differentiation survives a hop or a few hops from a residential
subscriber, their view was that it probably provides some benefits. 

Thanks,
--David

> -----Original Message-----
> From: Dart [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Thursday, June 12, 2014 6:56 AM
> To: [e-mail]; Black, David
> Cc: [e-mail]
> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple
> 
> Dan, David,
> 
> to be a bit more specific about the constraints: if certain PHBs
> and may be DSCPs are desired, then we will have to standardize
> them and pay attention to the way they are produced in different
> network sections along an end to end path.
> 
> It came to my mind that your draft deals with some DiffServ related
> constraints and my other mail wasn't explicit.
> 
> Regards,
> 
> Ruediger
> 
> 
> -----Original Message-----
> From: Dart [mailto:[e-mail]] on behalf of Dan Wing
> Sent: Thursday, 12. June 2014 06:55
> To: Black, David
> Cc: [e-mail]
> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple
> 
> 
> On Jun 11, 2014, at 7:37 PM, Black, David <[e-mail]> wrote:
> 
> >> Is the problem lack of color awareness in the AF remarker, or that AF
> >> remarkers assume all packets in the 5-tuple have the same color?
> >
> > The former, quoting from Section 2.4 of the draft:
> >
> >   In addition, remarking may remove application-level distinctions in
> >   forwarding behavior - e.g., if multiple PHBs within an AF class are
> >   used to distinguish different types of frames within a video flow,
> >   token-bucket-based remarkers operating in Color-Blind mode (see
> >   [RFC2697] and [RFC2698] for examples) may remark solely based on flow
> >   rate and burst behavior, removing the drop precedence distinctions
> >   specified by the source.
> 
> So, from a DSCP perspective, there won't be a problem mixing traffic needing
> different DSCP in the same 5-tuple.
> 
> > Beyond that, if the network that the traffic is entering does not
> > support the AF class involved on that ingress, DSCP remarking to zero
> > (best effort) is a likely behavior.
> 
> Sure.  Only fix there is to restore the DSCP by some other sort of signaling.
> Which means separate 5-tuples (to make such signaling straight forward) or
> requiring network gear to peek deeper into the packets to restore the DSCP
> bits, such as distinguish STUN/DTLS/RTP packets from each other, and if RTP to
> use the solution-de-jour for how to identify more-important RTP packets from
> less-important RTP packets (such as RTP header extension which has been
> bantered about, or DPI).
> 
> Hoping DSCP is preserved or re-written without semantic loss seems a long-dead
> pipe dream.  I would like to work towards solutions that allow the receiver to
> indicate their desired behavior for treatment on the receiver's network,
> rather than the sender specifying.  But probably out of scope of DART, I
> suppose.
> 
> -d
> 
> 
> 
> >
> > Thanks,
> > --David
> >
> >
> >> -----Original Message-----
> >> From: Dan Wing [mailto:[e-mail]]
> >> Sent: Wednesday, June 11, 2014 10:00 PM
> >> To: Black, David
> >> Cc: [e-mail]
> >> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple
> >>
> >>
> >> On Jun 11, 2014, at 5:58 PM, Black, David <[e-mail]> wrote:
> >>
> >>>> 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.
> >>>
> >>> That would most likely be within an AF class; the entire set of
> >>> packets
> >> marked
> >>> w/different drop precedences within an AF class should be classified
> >>> the
> >> same.
> >>>
> >>> Beyond that, one can hope that any AF remarker (e.g., for traffic
> >>> shaping)
> >> is
> >>> running in Color-Aware mode and hence tries to preserve source drop
> >> precedence
> >>> distinctions, but this cannot be relied upon.
> >>
> >> Is the problem lack of color awareness in the AF remarker, or that AF
> >> remarkers assume all packets in the 5-tuple have the same color?
> >>
> >> -d
> >>
> >>
> >>> Thanks,
> >>> --David
> >>>
> >>>> -----Original Message-----
> >>>> From: Dan Wing [mailto:[e-mail]]
> >>>> Sent: Wednesday, June 11, 2014 8:32 PM
> >>>> To: Brian E Carpenter
> >>>> Cc: Black, David; [e-mail]
> >>>> Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple
> >>>>
> >>>>
> >>>> 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.
> >>>>
> >>>> -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
> 
> _______________________________________________
> Dart mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dart