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

<Ruediger.Geib@telekom.de> Fri, 15 August 2014 05:08 UTC

Return-Path: <Ruediger.Geib@telekom.de>
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 8C4DA1A89F5 for <dart@ietfa.amsl.com>; Thu, 14 Aug 2014 22:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.518
X-Spam-Level:
X-Spam-Status: No, score=-4.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 zY-FF7C6eGGO for <dart@ietfa.amsl.com>; Thu, 14 Aug 2014 22:08:36 -0700 (PDT)
Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98841A00C5 for <dart@ietf.org>; Thu, 14 Aug 2014 22:08:34 -0700 (PDT)
Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 15 Aug 2014 07:08:32 +0200
X-IronPort-AV: E=Sophos;i="5.01,867,1400018400"; d="scan'208";a="515090698"
Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 15 Aug 2014 07:08:32 +0200
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Fri, 15 Aug 2014 07:08:32 +0200
From: <Ruediger.Geib@telekom.de>
To: <brian.e.carpenter@gmail.com>
Date: Fri, 15 Aug 2014 07:08:31 +0200
Thread-Topic: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02
Thread-Index: Ac+3+hUjwVARCRWoSjKWP4eFVivXEgAS3JsA
Message-ID: <CA7A7C64CC4ADB458B74477EA99DF6F502DE559975@HE111643.EMEA1.CDS.T-INTERNAL.COM>
References: <53EBCB82.9010901@erg.abdn.ac.uk> <CA7A7C64CC4ADB458B74477EA99DF6F502DE559734@HE111643.EMEA1.CDS.T-INTERNAL.COM> <53ED14D0.7000206@gmail.com>
In-Reply-To: <53ED14D0.7000206@gmail.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/4BgUspC3FJmKyf5ne1pavl9u0qo
Cc: dart@ietf.org
Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02
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: Fri, 15 Aug 2014 05:08:40 -0000

Hi Brian,

standards agree on the PHB which unrecognised DSCPs should receive, which is 
default forwarding. RFC2474 however proposes to transport the DSCP without 
remarking: 

   Packets received with an unrecognized codepoint SHOULD be forwarded
   as if they were marked for the Default behavior (see Sec. 4), and
   their codepoints should not be changed.  Such packets MUST NOT cause
   the network node to malfunction.

The MUST NOT cause malfunction clause leaves a way out and I personally 
favor rewrite to default DSCP.

There has been a discussion whether a rewrite of several incoming DSCP 
to a single outgoing DSCP is DiffServ compatible or not. Here we have 
such a rewrite. It seems to be alright for not supported DSCPs and PHBs.

As you mention, a TCA/SLA stating treatment of all DSCPs is important 
at network domain boundaries.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Dart [mailto:dart-bounces@ietf.org] Im Auftrag von Brian E Carpenter
Gesendet: Donnerstag, 14. August 2014 21:58
An: Geib, Rüdiger
Cc: gorry@erg.abdn.ac.uk; dart@ietf.org
Betreff: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02

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

    Brian

_______________________________________________
Dart mailing list
Dart@ietf.org
https://www.ietf.org/mailman/listinfo/dart