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

From: "Black, David" <[email-masked]>
Date: Tue, 10 Jun 2014 15:59:22 -0400

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.

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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jun 2014 08:42:56 +1200

> In another message, Ruediger Geib asked (>), and I responded:

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

    Brian

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

---

From: Dan Wing <[email-masked]>
Date: Wed, 11 Jun 2014 17:32:19 -0700

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

---

From: "Black, David" <[email-masked]>
Date: Wed, 11 Jun 2014 20:58:01 -0400

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

Thanks,
--David

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jun 2014 13:39:02 +1200

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jun 2014 13:46:44 +1200

> distinctions, but this cannot be relied upon.

Indeed not, and that's on the assumption that the receiving domain
even operates an AF service class. The worst case assumption is
that everything reverts to best effort somewhere along the path.

For some of the reasons behind this situation, I suggest reading
http://tools.ietf.org/html/rfc2475#section-6.1

   Brian

---

From: "Black, David" <[email-masked]>
Date: Wed, 11 Jun 2014 22:03:52 -0400

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

> into the payload than the port numbers.

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

Thanks,
--David

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, June 11, 2014 9:39 PM
> To: Dan Wing

---

From: Dan Wing <[email-masked]>
Date: Wed, 11 Jun 2014 18:59:51 -0700

> 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

---

From: Dan Wing <[email-masked]>
Date: Wed, 11 Jun 2014 19:31:50 -0700

> into the payload than the port numbers.

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

-d

---

From: "Black, David" <[email-masked]>
Date: Wed, 11 Jun 2014 22:37:34 -0400

> 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

> Sent: Wednesday, June 11, 2014 10:00 PM
> To: Black, David
> Cc: [email-masked]
> 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
> >
> >> On Jun 11, 2014, at 1:42 PM, Brian E Carpenter
> <[email-masked]>
> >> wrote:
> >>

---

From: Dan Wing <[email-masked]>
Date: Wed, 11 Jun 2014 21:54:37 -0700

>   rate and burst behavior, removing the drop precedence distinctions

So, from a DSCP perspective, there won't be a problem mixing traffic needing different DSCP in the same 5-tuple.

> the AF class involved on that ingress, DSCP remarking to zero (best effort)

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

---

From: <[email-masked]>
Date: Thu, 12 Jun 2014 12:08:05 +0200

Dan, David,

as David and Brian pointed out, there are hardly any reliable 
e2e PHBs/codepoints.

To me the DART discussion indicates that we may have to review how we 
use DiffServ or whether it is currently suitable to serve carrier, service 
provider and enterprise network requirements as well as application designer 
requirements simultaneously and deliver useful end to end service. I think 
if flexibility is king, then there will be no simple end to end solution 
(unless tunneling is regarded as simple - and outer header DSCPs still 
have to make sense then). If we desire e2e QoS and want to have simple 
solutions, then we need to standardize DiffServ along the full end to end 
chain to a higher degree than today - but of course respecting the existing 
deployments. That means accepting some constraints, but I'd be happy to 
try that.

Regards,

Ruediger

-----Original Message-----
From: Dart [mailto:[email-masked]] on behalf of Dan Wing
Sent: Thursday, 12. June 2014 06:55
To: Black, David
Cc: [email-masked]
Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 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.

-d

>>>> 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
>>>>>> Yes, that matches my understanding, although the author team 
>>>>>> would like
>> to
>>>>>> on the same 5-tuple - I'll copy your useful diagram into a 
>>>>>> separate
>> message
>>>>>> 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
>>>>>> 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.
>>>>> 
>>>> 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
>>>>>> 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

---

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

> that everything reverts to best effort somewhere along the path.

That's a fairly benign case, actually.
The worst case is that DSCP priorities get remapped in a way that 
inverts drop precedence (see the draft's discussion about 
less-than-best-effort).

I hope that's not a case that's so frequent that we have to worry 
over-much about it.

---

From: <[email-masked]>
Date: Thu, 12 Jun 2014 12:56:03 +0200

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:[email-masked]] on behalf of Dan Wing
Sent: Thursday, 12. June 2014 06:55
To: Black, David
Cc: [email-masked]
Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple

-d

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Jun 2014 13:40:33 +0200

Brian,

you mentioned 6-tuples - with the link you gave, I assume you're talking 
about IPv6 flow labels.

Apart from the issues with remapping, the use of flow labels should have 
many of the same aspects as the use of DSCP codepoints.

Can you give us some idea of how the use (or not) of multiple flow 
labels within a 5-tuple has been thought about in the IPv6 context?

        Harald

---

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

> into the payload than the port numbers.

I think I understand your meaning, but just to be sure:

Even if the packets with the same 5-tuple have different DSCPs, the are likely to get reset to the same DSCP (probably zero)  at a boundary, because the classifier either ignores or distrusts the original markings entirely? (As opposed to remapping any given DSCP to a different DSCP, but maintaining some distinction within the flow.)

Thanks!

Ben.

---

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

Ruediger,

> 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

> From: Dart [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, June 12, 2014 6:56 AM
> To: [email-masked]; Black, David
> Cc: [email-masked]
> 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
> >
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Jun 2014 08:12:54 +1200

Hi Harald,

> labels within a 5-tuple has been thought about in the IPv6 context?

It hasn't, because the model is that the label will be the same for all
packets in a given flow, and a flow is usually assumed to be identified
by its 5-tuple. But there are words at the very beginning of RFC 6437
that intentionally leave room for breaking that assumption:

> 1.  Introduction
> 
>    From the viewpoint of the network layer, a flow is a sequence of
>    packets sent from a particular source to a particular unicast,
>    anycast, or multicast destination that a node desires to label as a
>    flow.  From an upper-layer viewpoint, a flow could consist of all
>    packets in one direction of a specific transport connection or media
>    stream.  However, a flow is not necessarily 1:1 mapped to a transport
>    connection.

So the door is open for multiple labels for the same 5-tuple, but always
remembering that the label might be used as part of a load-balancing
mechanism (as discussed in RFC 6438 and RFC 7098).

Also, here's the bad news, remapping cannot be completely excluded
for the flow label. See http://tools.ietf.org/html/rfc6437#section-6
and in particular http://tools.ietf.org/html/rfc6437#section-6.1

   Brian
>>> over
>>> draft-york-dart-dscp-rtp-00).
>>>
>>> Thanks,
>>> --David

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Jun 2014 11:12:06 +1200

On 13/06/2014 02:41, Ben Campbell wrote:
> Even if the packets with the same 5-tuple have different DSCPs, the are likely to get reset to the same DSCP (probably zero)

I'm not sure about "probably" (unless someone has done large-scale
experiments, we don't really know) but it is the fail-safe default,
so we can definitely say "quite likely."

> at a boundary, because the classifier either ignores or distrusts the original markings entirely? (As opposed to remapping any given DSCP to a different DSCP, but maintaining some distinction within the flow.)

Subject to David's comment about AF "colour" possibly being preserved, yes.

There is another little point though. We've been discussing port numbers
as though they are transport-independent. Actually, a classifier needs to
look at the protocol number (TCP, UDP, SCTP, DCCP etc) before it knows
for sure where the port numbers are. So debating this point before
draft-ietf-rtcweb-transports-05 is rock solid may be a little academic.
I don't think generic classifiers are set up for "SCTP over DTLS over ICE"
for example.

   Brian

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 15 Jun 2014 10:33:23 +0200

> I don't think generic classifiers are set up for "SCTP over DTLS over ICE"

As far as anything at all in RTCWEB is rock solid, the decision to use
UDP is rock solid.
So we can take that as a given for RTCWEB.

(apart from the case where one uses TCP because the firewalls don't
allow UDP...)

Generic classifiers will detect the traffic as UDP, and may be able to
tell RTP from DTLS-encapsulated data in the same way as the DTLS/RTP
demultiplexing does it.

-- 
Surveillance is pervasive. Go Dark.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Jun 2014 08:06:36 +1200

Harald,

> (apart from the case where one uses TCP because the firewalls don't

Ah. Now I understand better. The following comment is out of scope
for DART, but I think that draft-ietf-rtcweb-transports desparately
needs an overview section with a diagram that shows the complete
set of transport nestings. I was very confused by
http://tools.ietf.org/html/draft-ietf-rtcweb-transports-05#section-3.5
and such a diagram would make it much clearer what a diffserv
classifier would see in the outermost header.

> tell RTP from DTLS-encapsulated data in the same way as the DTLS/RTP

I expect David will agree that RFC 2983 might be worth a read, because
some of the same issues arise. I guess that if RTCweb takes over
the universe, classifiers might be updated to understand RTCweb
transport nestings, but initially you certainly can't assume that.

   Brian