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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EB5921A02E5 for <>; Thu, 12 Jun 2014 16:12:01 -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 pkFELfg0oo2T for <>; Thu, 12 Jun 2014 16:11:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8158F1A02C4 for <>; Thu, 12 Jun 2014 16:11:59 -0700 (PDT)
Received: by with SMTP id kx10so1430521pab.26 for <>; Thu, 12 Jun 2014 16:11:59 -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=3YW+inSbwhEwfPoI7YZOErUamonTyw0dvSBahr/q9q8=; b=oNfImLa+0EjPJ0c1YISGGLR1PBhMjJLfMms55kfNAavoUyqj9sXM2WNq0MbRiy7e4R FuYR/reZlryxCVOiRM525cMCJsbpkAmwCCmgY0GheCYZe8XmSrcA5nNntqat/DeM1Pzo 3JRa4A3jVGs/cePqj7XEeB7NAdOEE/SxvusmAizpoL2dMx3/LDHhV0MLiWTlCqIMA6Et csKEZobvFG7h8BFR/6g+Ri5ejeh9D5HS+kty++swDahp6FVMds72kOl0NYzrudCP42jD 4kNxrgcO56ERcnCxrdX7pws9oE0srcbWxkdeNYOOWjnc32Kba1/ccE9nGzuMYvOJWfZ+ z/2w==
X-Received: by with SMTP id nr1mr15935432pbc.52.1402614719094; Thu, 12 Jun 2014 16:11:59 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id kn1sm66820pbd.13.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 16:11:58 -0700 (PDT)
Message-ID: <>
Date: Fri, 13 Jun 2014 11:12:06 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Ben Campbell <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "Black, David" <>, "" <>, Dan Wing <>
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 23:12:02 -0000

On 13/06/2014 02:41, Ben Campbell wrote:
> On Jun 11, 2014, at 8:39 PM, Brian E Carpenter <> 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.
>> 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.
> 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)

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.