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

Mikael Abrahamsson <swmike@swm.pp.se> Fri, 29 May 2015 12:53 UTC

Return-Path: <swmike@swm.pp.se>
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 4BA8D1A8899 for <tsvwg@ietfa.amsl.com>; Fri, 29 May 2015 05:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Level:
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 e5Qp9WScLNdG for <tsvwg@ietfa.amsl.com>; Fri, 29 May 2015 05:53:15 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22801A88AB for <tsvwg@ietf.org>; Fri, 29 May 2015 05:53:14 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 44132A1; Fri, 29 May 2015 14:53:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1432903991; bh=YG/JD0A2PM+2/AbusQUnZzVBnywRN+ph7twzZULN204=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=2S7vaZvGWeg5h5vqQM0hasvpZ9x11vCb0h1zo8WJ4g/5xBEEgc2OLOFSHLt/rk8Am xQcsW8s+qiagq0shWcGaOqfF0B8CU/hrwe5Zpub7qLsht57s4PuOcqBfRVtK44CDl/ w/Q4M9Ck4gElj0dxxiuvvWrNZzAtlzxLFt2NaCdA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3A6C59F; Fri, 29 May 2015 14:53:11 +0200 (CEST)
Date: Fri, 29 May 2015 14:53:11 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ruediger.Geib@telekom.de
In-Reply-To: <CA7A7C64CC4ADB458B74477EA99DF6F50513613DD9@HE111643.EMEA1.CDS.T-INTERNAL.COM>
Message-ID: <alpine.DEB.2.02.1505291422130.9487@uplift.swm.pp.se>
References: <CA7A7C64CC4ADB458B74477EA99DF6F50513613DD9@HE111643.EMEA1.CDS.T-INTERNAL.COM>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tsvwg/hyNlEzkeHrR9OZOQxFxAGoF69Ko>
Cc: tsvwg@ietf.org
Subject: Re: [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 12:53:17 -0000

On Fri, 29 May 2015, Ruediger.Geib@telekom.de wrote:

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

>From an operational point of view, for me, the only way to get scavenger 
class incrementally implemented is to create a new DSCP bit pattern for 
this with the first 3 bits set to 0. CS1 is not well suited for scavanger 
for incremental deployment in todays networks because it means different 
things in different places.

I posted about this in another discussion here on AQM:

http://www.ietf.org/mail-archive/web/aqm/current/msg01240.html

The proposal is to create a scavanger class which would map to CS0 but 
have DSCP-style drop probability bits set.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se