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

Mikael Abrahamsson <swmike@swm.pp.se> Fri, 26 June 2015 08:33 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 076ED1A0115 for <tsvwg@ietfa.amsl.com>; Fri, 26 Jun 2015 01:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.361
X-Spam-Level:
X-Spam-Status: No, score=-3.361 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, J_CHICKENPOX_21=0.6, 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 9JWyOkqCATXy for <tsvwg@ietfa.amsl.com>; Fri, 26 Jun 2015 01:33:52 -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 6A17B1A010F for <tsvwg@ietf.org>; Fri, 26 Jun 2015 01:33:52 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7386BA2; Fri, 26 Jun 2015 10:33:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1435307630; bh=B/xd4vTdCn9ykjXjUcYlB+7WGlKiil+bm5iLhOC8Mso=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vgc0+3GZVtc/OWqn4KHymsVK9vYOZ02sUdbzNrcc90tKYshjJ8YUguCIEMO/b6VyV S05EZuaM/pJL6FIexoPCCnLoKKMq/h2Rgae2JL0bDTNRQ6LSO24uovv8aXRYhVWGni SivP9eNccl/FmPlOED7HQyM6AqU6e+ujhu5fCHK0=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5E2BAA1; Fri, 26 Jun 2015 10:33:50 +0200 (CEST)
Date: Fri, 26 Jun 2015 10:33:50 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ruediger.Geib@telekom.de
In-Reply-To: <CA7A7C64CC4ADB458B74477EA99DF6F505290F292B@HE111643.EMEA1.CDS.T-INTERNAL.COM>
Message-ID: <alpine.DEB.2.02.1506261011340.9487@uplift.swm.pp.se>
References: <CA7A7C64CC4ADB458B74477EA99DF6F50513613DD9@HE111643.EMEA1.CDS.T-INTERNAL.COM> <alpine.DEB.2.02.1505291422130.9487@uplift.swm.pp.se> <5568CF68.9020406@gmail.com> <alpine.DEB.2.02.1505292256170.9487@uplift.swm.pp.se> <CA7A7C64CC4ADB458B74477EA99DF6F505136148FE@HE111643.EMEA1.CDS.T-INTERNAL.COM> <CE03DB3D7B45C245BCA0D243277949360B3798B8@MX104CL02.corp.emc.com> <5580C588.9070008@gmail.com> <538a059f43eb8a2c2bd42453de21d6f2.squirrel@erg.abdn.ac.uk> <alpine.DEB.2.02.1506260829330.9487@uplift.swm.pp.se> <CA7A7C64CC4ADB458B74477EA99DF6F505290F292B@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/VnGrGB2mWTCD3HTQq-xfN1zstvw>
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: <https://mailarchive.ietf.org/arch/browse/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, 26 Jun 2015 08:33:55 -0000

On Fri, 26 Jun 2015, Ruediger.Geib@telekom.de wrote:

> I've asked my colleagues visiting RIPE and NANOG meetings for Diffserv 
> Interconnection related contacts, but feedback was limited. I guess 
> there's some truth in what you say - developers and more so operational 
> staff hardly participates in IETF work.

I don't understand what "Diffserv Interconnection related contacts" would 
be. This would most likely be handled by peering managers and IP 
network architects that do the rest of the network design.

> If you are aware of DiffServ Interconnection related agreements of NANOG 
> please let me know. I think there's nothing discussed by RIPE.

In the operational community things are done largely by interpersonal 
connections and discussions on mailing lists that then create de-facto 
ways of doing things.

> Bleaching of "Ip precedence bits" is not within scope of Diffserv 
> Intercon and it will stay out of scope (it is an informational draft and 
> it cannot and is not supposed to change standards).

Right now most ISPs will bleach all 6 bits for Internet traffic. My 
proposal was to come up with a solution that allowed them to bleach the CS 
bits.

> Carrier representatives interested in a standard allowing to remark, 
> say, ranges of DSCPs (bleaching by precedence is bad wording) should 
> collectively draft a suitable document. I guess, if at all, this is only 
> picked up by standardization if a significant number of provider 
> representatives express interest. If you know some more provider 
> representatives willing to co-author such a draft, please let me know.

I have already suggested what I think would be achievable in real life. I 
am willing to bring this to nanog and ask for opinions from the 
operational community.

> I've had some text related to the issue in very early versions of the draft.

I propose that what I want to do isn't applicable to your draft, I just 
realised I had jumped into the discussion without reading it. I now have 
quickly scanned through it, and your text isn't applicable to Internet 
peering at all.

So what I want to achieve would need a new document. I have no idea how it 
applies to all the other documents out there because there are just too 
many for someone not focusing on this area, to overlook. I have been 
architecting Internet backbones for 15 years.

I would like to see a document that applies to Internet traffic only, 
scavenger class and BE only, that basically proposes to bleach CS bits and 
leave the rest of the bits intact, and then suggests how to configure 
queuing behavior for Internet access to take this into account. It should 
be an operational document which includes deployment cases and how to 
configure this using commonly used equipment.

I think the disconnect here is that in the IETF DSCP and the rest is 
considered transport, but by most operators, DSCP and queuing behaviour is 
done by IP engineers and IP architects. These people go to v6ops, 
potentially to 6man, routing protocol WG:s and similar IP control and 
forwarding groups, they don't really attend what IETF calls transport. I 
also get the feeling that people in here don't really attend NANOG or 
other places where the people who actually forward packets and configure 
queues attend. So we have two groups who never interact.

So there is really a need for TSV-OPS or something, that actually talks 
about how to implement what's in the DSCP related documents, and the IETF 
needs to somehow try to attract operational people in there. I have non 
idea how to achieve this.

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