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

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 6 Apr 2018 09:06:46 +0200 (CEST)

Hi,

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

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?

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 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?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 6 Apr 2018 09:52:56 +0200 (CEST)

On Fri, 6 Apr 2018, Mikael Abrahamsson wrote:

> 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?

One network provided me this output from 24 hours in their network (which 
does not bleach DSCP). These are the 6 DSCP bits in decimal notation.

DSCP 	percent
0 	95.4928
2  	1.7633
12 	0.6397
6  	0.4266
8  	0.2435
18 	0.1888
16 	0.1846
10 	0.1463
4  	0.1425
46 	0.1102
...
1	0.0150

So at least in this network, it seems 1 is not in wide use.

As additional information, they also said they see at least one packet per 
24 hour period with every value out of the possible 64 DSCP values.

---

From: <[email-masked]>
Date: Fri, 6 Apr 2018 07:52:47 +0000

Hi Mikael,

>measurement about bleaching in todays networks, seeing if there 
>is any difference in bleaching for 000001 (LE) and 001000 (CS1).

[RG] I'd expect differences. Without checking the list mail archive:
I think to recall that Michael Weltzel 
has executed some tests and distributed his results on the list (and 
Gorry I think did that too).

Regards,

Ruediger

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Mon, 9 Apr 2018 09:58:01 +0200

Hi Mikael,

see inline.

Am 06.04.2018 um 09:06 schrieb Mikael Abrahamsson:

> 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:
> 

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

> trying to not get this wrong (I frequently have gotten it wrong, but
> let's try again):
> 

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.

> difference in bleaching for 000001 (LE) and 001000 (CS1).

I also asked them, but right now Atlas isn't supporting this type
of measurement.

> wild, and if I can get a summary. Or has this work already been done so

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Apr 2018 10:12:56 +0200 (CEST)

> new LE codepoint then. I'm also not sure that scp always belongs to

We've had very animated discussions with this, and my opinion is that 
there is no correct answer, only tough trade-offs. CS1 and anything AF2x 
maps by default to a 802.1p queueing class that is lower priority compared 
to BE. So installed L2 network and default behaviour is clashing with all 
the diffserv CPs as currently specified.

So I'm arguing "we should do the right thing going forward" and get all 
systems to implement the new diffserv->802.1p and 802.11 mappings as 
recently specified, whereas others are claiming we should use whatever 
works right now. I believe both view points have merit, but I prefer to 
look forward since current situation doesn't work well anyway. Having 
PREC1 and 2 map into background for basically all IEEE networks doesn't 
match well to current DSCP CPs and default behaviour of putting PREC bits 
straight into L2 802.1p and equivalents.

> class selector codepoints CSx. So, I don't see any problems here.

Well, it's fascinating that we're using code today that still implements 
IPTOS even though it was obsoleted 20 years ago. Otoh it's good that there 
are now initiatives to change this. The bad part is that the proposal for 
change is to go to CS1 which I don't agree with, but is the correct choice 
as per current standards because LE hasn't been standardised yet.

> I also asked them, but right now Atlas isn't supporting this type

Right, but I got a response which seemed to indicate that they'll look 
into this.

> https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-le-phb-00

Thanks, I had missed that one.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 9 Apr 2018 10:21:00 +0200

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) <[email-masked]> wrote:
> 
> Hi Mikael,
> 
> see inline.
> 
> ....
> ....

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Apr 2018 08:47:21 +1200

On 09/04/2018 20:12, Mikael Abrahamsson wrote:
...
> The bad part is that the proposal for 

So, can we stop talking and get the new recommended LE codepoint into
a standards track RFC, please? The longer we delay, the harder it is
to get rid of misuse of the CS1 codepoint.

(There is a completely separate issue of why ancient crud like 
IPTOS_RELIABILITY is still apparently defined at all, but
overhauling the socket API is not quite in scope here. But,
good grief, look at this from 2012:
https://stackoverflow.com/questions/12024335/java-tcp-traffic-classes )

    Brian