Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02

Brian E Carpenter <> Thu, 14 August 2014 19:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8ABB31A872A for <>; Thu, 14 Aug 2014 12:58:09 -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 pIT5RnYhRtbb for <>; Thu, 14 Aug 2014 12:58:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31FDD1A871D for <>; Thu, 14 Aug 2014 12:58:08 -0700 (PDT)
Received: by with SMTP id kx10so2208010pab.20 for <>; Thu, 14 Aug 2014 12:58:07 -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=yn8UjWE0RJs1lNRpYuBwrjwBZ0a+MQKCMzIhq18wkJ8=; b=PcDB5ttYXBpqbPyNlYYL1TXWx9y3iwtkD/tetDgSvPb6odat/fdzhBTcVnjbl0GAkj JUf/UhaEdTGnjTurcNJlgDHoHvib7k0m7Wqyovj6tZ7CDg5gliK7mi6/9dQ/NGJYr0FS 0TGqbBYYpoG4NBggMr885nrsSWOSsMwC0jZlSl4dVXbGwjG4Vy9trASUWP5FBb868lNZ TXb8ZuOAR9vTV/Yqvwnu2KfDAbSj3dBM0xb9P+GhA3neqEEZZlrGZgSfoP5LSLzcpvZ9 2rBuVDl8bCKwBGqAHPbR4P7VC4DTVE7tvoDwuTA7uqN4Ju1MhrTI7S/VXPlo14l58fR6 UFDg==
X-Received: by with SMTP id tg10mr6536552pbc.72.1408046287728; Thu, 14 Aug 2014 12:58:07 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id dw8sm20396626pab.35.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Aug 2014 12:58:07 -0700 (PDT)
Message-ID: <>
Date: Fri, 15 Aug 2014 07:58:08 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
References: <> <CA7A7C64CC4ADB458B74477EA99DF6F502DE559734@HE111643.EMEA1.CDS.T-INTERNAL.COM>
In-Reply-To: <CA7A7C64CC4ADB458B74477EA99DF6F502DE559734@HE111643.EMEA1.CDS.T-INTERNAL.COM>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02
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, 14 Aug 2014 19:58:09 -0000

> Another question to be answered then is how a network provider will treat unrecognized or unexpected DSCPs received at network boundaries.

Quoting RFC 2475:

  "A DS domain has a well-defined boundary consisting of
   DS boundary nodes which classify and possibly condition ingress
   traffic to ensure that packets which transit the domain are
   appropriately marked to select a PHB from one of the PHB groups
   supported within the domain."

In other words the assumption is that (unless there's an SLA
that allows the receiving domain to trust the incoming DSCP),
a classifier is needed. My assumption has always been that
the default classifier will simply re-mark packets with the
default DSCP.

We also have
  "A DS ingress node is responsible for ensuring that the traffic entering
   the DS domain conforms to any TCA between it and the other domain to
   which the ingress node is connected."

and the definition of a TCA:

"  Traffic Conditioning      an agreement specifying classifier rules
   Agreement (TCA)           and any corresponding traffic profiles and
                             metering, marking, discarding and/or
                             shaping rules which are to apply to the
                             traffic streams selected by the classifier.
                             A TCA encompasses all of the traffic
                             conditioning rules explicitly specified
                             within a SLA along with all of the rules
                             implicit from the relevant service
                             requirements and/or from a DS domain's
                             service provisioning policy."

In other words: the treatment of unrecognized DSCPs needs to
be stated in the TCA part of the SLA.

Of course you could suggest a default approach in diffserv-intercon.