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

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

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

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.

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