Re: [tsvwg] residential broadband BCP PHB and CP treatment Re: CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04

Mikael Abrahamsson <swmike@swm.pp.se> Sat, 21 April 2018 05:29 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5395412D775 for <tsvwg@ietfa.amsl.com>; Fri, 20 Apr 2018 22:29:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 DXQQF-tU9b1u for <tsvwg@ietfa.amsl.com>; Fri, 20 Apr 2018 22:29:45 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D631A1271DF for <tsvwg@ietf.org>; Fri, 20 Apr 2018 22:29:44 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0A1FDB0; Sat, 21 Apr 2018 07:29:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1524288582; bh=sOzs2Rge0zH32lLFaO9CJdqzYcFJ+wZeFSl0nbRIlYc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=n0k69DHTTsF+XTcK7+hhygyTHMocGVSDkcRXdNbNWaXIGdi2xiYzVDbJakGPrPuMT boRzHJYAHc2IO7BcjDeEdxDCQ5UAVLPVf/vRjvn51rQqW35js2H3ZO5ffscVRBBim+ LnLmn0/fTM7X5EkLeOjBJH7x/nWWW4mcF/OdBSLA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 062E6AF; Sat, 21 Apr 2018 07:29:42 +0200 (CEST)
Date: Sat, 21 Apr 2018 07:29:42 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: tsvwg@ietf.org
In-Reply-To: <943a0db3-5aa6-0f09-c13b-e69a3f62ef5f@gmail.com>
Message-ID: <alpine.DEB.2.20.1804210725390.18650@uplift.swm.pp.se>
References: <20180406160344.xwfqgzhzfto56jhq@faui48f.informatik.uni-erlangen.de> <LEJPR01MB1033F43509F08701B2B5EA1D9CBF0@LEJPR01MB1033.DEUPRD01.PROD.OUTLOOK.DE> <82d646b7-d475-64d6-9f0b-f75e3daeeaca@gmail.com> <20180410090033.xkwsyfbfardg4pwx@faui48f.informatik.uni-erlangen.de> <ddac784e-3a88-c82d-0ed5-3816bffa2d72@gmail.com> <20180412023305.6nwyoway2m2exy2c@faui48f.informatik.uni-erlangen.de> <LEJPR01MB10334C794BDA7E125917576E9CBC0@LEJPR01MB1033.DEUPRD01.PROD.OUTLOOK.DE> <alpine.DEB.2.20.1804190826550.18650@uplift.swm.pp.se> <adf6493b-45fd-9d0c-70f5-5d343cad22dd@gmail.com> <alpine.DEB.2.20.1804200635060.18650@uplift.swm.pp.se> <fbc0e011-6e37-c0ee-c90e-191349f75cac@gmail.com> <alpine.DEB.2.20.1804200823330.18650@uplift.swm.pp.se> <943a0db3-5aa6-0f09-c13b-e69a3f62ef5f@gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/-P3r6NKocdk-ljoWItwadLW9hOU>
Subject: Re: [tsvwg] residential broadband BCP PHB and CP treatment Re: CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 21 Apr 2018 05:29:46 -0000

On Sat, 21 Apr 2018, Brian E Carpenter wrote:

> Because RFC2474 clearly states that CS1 gets precedence over DF (=CS0).
> (Which in fact goes back to RFC791 and RFC1349.)
>
> "PHBs selected by a Class Selector Codepoint
> SHOULD give packets a probability of timely forwarding that is not
> lower than that given to packets marked with a Class Selector
> codepoint of lower relative order..." (RFC2474 section 4.2.2.2)
>
> None of the other RFCs that use the CS1 codepoint for LE have formally
> updated RFC2474; in other words they all violate the SHOULD above.
> Specifically, RFC4594 did not formally update RFC2474.
>
> A user who sets CS1 because they want better treatment than default
> is doing exactly what an IETF standard says. So if you see CS1 on
> incoming traffic, you have no idea whether the user wanted Precedence 1
> or LE, unless you have a specific understanding with that user.
>
> To me that means that the correct default behaviour is to map CS1 to
> DF, as a compromise. Of course, if you *know* whether the user is
> relying on RFC2474 or on RFC4594, you can configure the correct
> mapping. But that's always true of diffserv.

Thanks for the explanation. Would it influence your opinion if there were 
data that showed that more applications use CS1 in the LE sense compared 
to using CS1 as higher preference over DF?

Basically my question is that if setting formal references/updates etc 
aside, what have people actually been doing in the past 20 years, should 
that affect our decision?

Discovering that for instance ssh uses IPTOS by default was a revelation 
to me.

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