[tsvwg] draft diffserv-intercon: Handling of a scavenger class / CS1

<Ruediger.Geib@telekom.de> Fri, 29 May 2015 10:27 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AB41B2A9C for <tsvwg@ietfa.amsl.com>; Fri, 29 May 2015 03:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.459
X-Spam-Level:
X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 uIFVbbqYsHA2 for <tsvwg@ietfa.amsl.com>; Fri, 29 May 2015 03:27:02 -0700 (PDT)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915881A026F for <tsvwg@ietf.org>; Fri, 29 May 2015 03:26:58 -0700 (PDT)
Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail91.telekom.de with ESMTP; 29 May 2015 12:20:32 +0200
X-IronPort-AV: E=Sophos;i="5.13,516,1427752800"; d="scan'208,217";a="680312677"
Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 29 May 2015 12:20:31 +0200
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 29 May 2015 12:20:31 +0200
From: Ruediger.Geib@telekom.de
To: gorry@erg.abdn.ac.uk
Date: Fri, 29 May 2015 12:20:29 +0200
Thread-Topic: draft diffserv-intercon: Handling of a scavenger class / CS1
Thread-Index: AdCZ+RaNtSi8mJFTQn+UwuqogDAGaA==
Message-ID: <CA7A7C64CC4ADB458B74477EA99DF6F50513613DD9@HE111643.EMEA1.CDS.T-INTERNAL.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: multipart/alternative; boundary="_000_CA7A7C64CC4ADB458B74477EA99DF6F50513613DD9HE111643EMEA1_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tsvwg/xuNTcnIv4dplh6ILFSAF1P9_TXU>
Cc: jmpolk@cisco.com, tsvwg@ietf.org, mattmathis@google.com
Subject: [tsvwg] draft diffserv-intercon: Handling of a scavenger class / CS1
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2015 10:27:05 -0000

Gorry,

the notes taken in Dallas (and thanks to the note taker!) showed a scavenger-class-at-interconnection related discussion.

Summary of Dallas discussion:
-       Scavenger is not supported at Interconnection, as CS1 is not a widely deployed standard DSCP for scavenger.
-       Taking this into account, there was a request for CS1 not to be re-marked to any other DSCP.

Basic questions:
-       Is the issue to get Scavenger support in a general DiffServ sense at Interconnection, i.e. the PHB is supported by the receiving domain but the DSCP may be remarked? To me, this would make Scavenger relevant for diffserv-intercon
-       Is the issue to avoid remarking of the DSCP, no matter whether the receiving domain supports Scavenger? As I agree to remove the remarking discussion from diffserv-intrcon, I'd regard this to be out of its scope (in both cases, if the receiving domain supports Scavenger by CS1 and also if it transports CS1 unchanged if it isn't aware of the DiffServ PHB indicated by it).

Those interested in scavenger class marked packets passing interconnection points are asked to respond.

My take:
-       The uniform model assumes the DSCP and PHB to remain unchanged when passing a tunnel (may also be an MPLS tunnel). The uniform model is out of scope of diffserv-intercon.
-       The pipe model assumes the DSCP to remain unchanged when passing a tunnel. The pipe model is out of scope of diffserv-intercon.
-       The short pipe model tolerates or requires a DSCP rewrite at interconnection points. Diffserv-intercon proposes to indicate a desired PHB by a defined DSCP at an interconnection point. Any DSCP may be re-written by the receiving domain.

This is not to say, that uniform model or pipe model should not be supported. It just to indicate what's within and what's out of scope of diffserv-intercon. The draft doesn't define the uniform and pipe model to be out of scope yet, the next version will (unless there's disagreement on this aspect).

Regards,

Ruediger