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

Ben Campbell <> Thu, 12 June 2014 14:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D9E21B2A6B for <>; Thu, 12 Jun 2014 07:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id klwVP3olyRea for <>; Thu, 12 Jun 2014 07:41:35 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0AE11B2A6A for <>; Thu, 12 Jun 2014 07:41:35 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.9/8.14.7) with ESMTP id s5CEfLt4045881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Jun 2014 09:41:22 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ben Campbell <>
In-Reply-To: <>
Date: Thu, 12 Jun 2014 09:41:21 -0500
X-Mao-Original-Outgoing-Id: 424276881.504328-9c38469682cec4988bb1254e8f164469
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Brian E Carpenter <>
X-Mailer: Apple Mail (2.1878.2)
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 14:41:37 -0000

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