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

Ben Campbell <ben@nostrum.com> Thu, 12 June 2014 14:41 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9E21B2A6B for <dart@ietfa.amsl.com>; Thu, 12 Jun 2014 07:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klwVP3olyRea for <dart@ietfa.amsl.com>; Thu, 12 Jun 2014 07:41:35 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0AE11B2A6A for <dart@ietf.org>; Thu, 12 Jun 2014 07:41:35 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (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 ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <539904B6.4050803@gmail.com>
Date: Thu, 12 Jun 2014 09:41:21 -0500
X-Mao-Original-Outgoing-Id: 424276881.504328-9c38469682cec4988bb1254e8f164469
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC45C7A8-2D7F-47D4-B4C8-8924930CF7B4@nostrum.com>
References: <8D3D17ACE214DC429325B2B98F3AE712076FD346C9@MX15A.corp.emc.com> <5398BF50.5040604@gmail.com> <657B1854-CC2F-4061-83BF-43447230ACC3@cisco.com> <539904B6.4050803@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/a5lJXnXECnk5R8ICGqsT8UcCfWw
Cc: "Black, David" <david.black@emc.com>, "dart@ietf.org" <dart@ietf.org>, Dan Wing <dwing@cisco.com>
Subject: Re: [Dart] RTP and non-RTP traffic on same UDP 5-tuple
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jun 2014 14:41:37 -0000

On Jun 11, 2014, at 8:39 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> 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.)

Thanks!

Ben.