Re: [tsvwg] operational feedback regarding draft-ietf-tsvwg-le-phb-04

"Brian Trammell (IETF)" <ietf@trammell.ch> Mon, 09 April 2018 08:21 UTC

Return-Path: <ietf@trammell.ch>
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 02FC31242F7 for <tsvwg@ietfa.amsl.com>; Mon, 9 Apr 2018 01:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 ntJWWVbZ85db for <tsvwg@ietfa.amsl.com>; Mon, 9 Apr 2018 01:21:03 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C887126B7E for <tsvwg@ietf.org>; Mon, 9 Apr 2018 01:21:03 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C8A8A340E84; Mon, 9 Apr 2018 10:21:01 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.11645); Mon, 9 Apr 2018 10:21:01 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Mon, 9 Apr 2018 10:21:01 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 51046526; Mon, 09 Apr 2018 10:21:01 +0200
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <856CA02B-A360-47FF-AC4C-9D9A6D50EF51@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_CFC6A2B7-A9B8-4970-B6F9-8DBC97554277"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Mon, 09 Apr 2018 10:21:00 +0200
In-Reply-To: <6fb9733e-6a3e-e5af-09cc-ba57c96cdb73@kit.edu>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, tsvwg <tsvwg@ietf.org>
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
References: <alpine.DEB.2.20.1804060854370.18650@uplift.swm.pp.se> <6fb9733e-6a3e-e5af-09cc-ba57c96cdb73@kit.edu>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/SqU-nw_4hGlkc9AYETB7nVXVPRw>
Subject: Re: [tsvwg] operational feedback regarding 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: Mon, 09 Apr 2018 08:21:07 -0000

Hi, all,

Some additional results from another active measurement study, currently under submission, which looks at hop-by-hop DSCP manipulation on active traffic using a tracebox-like methodology for TCP SYNs with DSCP EF (46) set.

Of 418834 distinct IP-IP edges in the trace:

689  (0.16%)  change the DSCP value to CS1 (8)
1949 (0.46%)  change the DSCP value to 5 (undefined, also under consideration for LE)
246  (0.059%) change the DSCP value to 1

Source was a DigitalOcean node in Amsterdam, toward Alexa top hosting IPs.

We take a transition to a value to be an indication that that value is in use, but cannot assign semantics to that use. I've also looked at a separate, comparable dataset from a different VP toward similar targets that indicated that 1 saw less use than 5, though all these numbers are down in the underflow. Don't think that one was published.

In either case, overloading CS1 also doesn't seem right to me.

Cheers,

Brian

> On 9 Apr 2018, at 09:58, Bless, Roland (TM) <roland.bless@kit.edu> wrote:
> 
> Hi Mikael,
> 
> see inline.
> 
> Am 06.04.2018 um 09:06 schrieb Mikael Abrahamsson:
> 
>> I have asked people in the operational community what they think about
>> this proposal, and the little feedback I have received so far has been
>> that one person thought CS1 should be used instead, others have said
>> that 000001 seems fine. In the process of this there have been patches
>> proposed for ssh which historically has been using TOS:
>> 
>> https://marc.info/?l=openbsd-tech&m=152251266032032&w=2
> 
> Wow, this recommends CS1 for LE which isn't good. It should use the
> new LE codepoint then. I'm also not sure that scp always belongs to
> the LE class...
> 
>> So it seems to me that there are applications out there that are using
>> IPTOS_THROUGHPUT and IPTOS_LOWDELAY, in use today.
>> 
>> I found this in a header file:
>> 
>> /*
>>  * Definitions for IP type of service (ip_tos)
>>  */
>> #define    IPTOS_LOWDELAY        0x10
>> #define    IPTOS_THROUGHPUT    0x08
>> #define    IPTOS_RELIABILITY    0x04
>> 
>> So trying to figure out what bits go where, right-shifting two times and
>> trying to not get this wrong (I frequently have gotten it wrong, but
>> let's try again):
>> 
>> IPTOS_LOWDELAY      DSCP 000100
>> IPTOS_THROUGHPUT    DSCP 000010
>> IPTOS_RELIABILITY   DSCP 000001
>> 
>> So does this mean that the new LE DSCP CP maps to IPTOS_RELIABILITY?
> 
> I would put it the other way round: if only the
> IPTOS_RELIABILITY is set, it will be mapped to the LE DSCP.
> So you are right here. However, RFC2474 already obsoleted the IP ToS
> semantics:
>   A replacement header field, called the DS field, is defined, which is
>   intended to supersede the existing definitions of the IPv4 TOS octet
>   [RFC791] and the IPv6 Traffic Class octet [IPv6].
> ....
>   The structure of the DS field shown above is incompatible with the
>   existing definition of the IPv4 TOS octet in [RFC791].
> ....
>   No attempt is made to maintain backwards compatibility with the "DTR"
>   or TOS bits of the IPv4 TOS octet, as defined in [RFC791].
> 
> RFC2474 only preserved the IP precedence semantics by defining the
> class selector codepoints CSx. So, I don't see any problems here.
> 
>> Anyhow, I have also asked the RIPE Atlas team if they can do some
>> measurement about bleaching in todays networks, seeing if there is any
>> difference in bleaching for 000001 (LE) and 001000 (CS1).
> 
> I also asked them, but right now Atlas isn't supporting this type
> of measurement.
> 
>> I will also ask around and see if there is anyone with sFlow dumping
>> from a major IX that can tell me what DSCP code points they see in the
>> wild, and if I can get a summary. Or has this work already been done so
>> I don't need to?
> 
> More measurements are always good!
> I think that the neat project and Gorry's group did some work, see:
> https://www.ietf.org/proceedings/96/slides/slides-96-maprg-6.pdf
> https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-le-phb-00
> 
> Regards,
> Roland
>