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

Brian E Carpenter <> Thu, 12 June 2014 01:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6C8E81B294B for <>; Wed, 11 Jun 2014 18:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WguMfIuMafeV for <>; Wed, 11 Jun 2014 18:38:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 764121B2946 for <>; Wed, 11 Jun 2014 18:38:58 -0700 (PDT)
Received: by with SMTP id kq14so423804pab.0 for <>; Wed, 11 Jun 2014 18:38:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kmuV+hrOPQUbMp4+o/mV2sNAJ6+F9Ob+TbhDZAt/jHw=; b=ng4n8JuJuhOeMt97GprMdaQ2AtxD2NUwUKkb6TlwTVS0QAzR+fVjx3nZu+r7L2aYAF f9c/MAPKMj/9qq0Ut1BiB0VJ8746vqZJ+osQ822ncBIbqjpB8vpQxtTE7orQahmdD2ou /xZwckf5T1kqK7C0Dv1KysORRZJ5Biz2DqNFKpNAxCYOTDvMKdqpA/FM+ALIrgJDk+Kd iWbvdg/tVsFNE/hbldMlV+sPrdPyZ555lHvbAEDysIOqXBDz94Ne9T/KyzSxg8XjxpHL yir5jA47iAvZUoui5sOJM09Tp4VjZLontxvYVpT0QEEPA5GGSk/HtuiaawS1T95JYdFr M9cg==
X-Received: by with SMTP id gi9mr9214969pbc.79.1402537138013; Wed, 11 Jun 2014 18:38:58 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id it4sm77298463pbc.39.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 18:38:57 -0700 (PDT)
Message-ID: <>
Date: Thu, 12 Jun 2014 13:39:02 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Dan Wing <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "Black, David" <>, "" <>
Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Jun 2014 01:39:00 -0000

On 12/06/2014 12:32, Dan Wing wrote:
> On Jun 11, 2014, at 1:42 PM, Brian E Carpenter <> 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.


> -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
>>> +1 (508) 293-7953             FAX: +1 (508) 293-7786
>>>        Mobile: +1 (978) 394-7754
>>> ----------------------------------------------------
>>> _______________________________________________
>>> Dart mailing list
>> _______________________________________________
>> Dart mailing list