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

["Black, David" <[e-mail]>]

<WG Chair Hat=OFF>

I'm not Ruediger, but ...

> How do you expect Internet Tier1:s to know the expected PHBs of traffic of
> their customers customers customers customer?

I don't - if the adjacent network is sending other-than-BE traffic to my network that is not supposed to be bleached, then there is some agreement/understanding in place between the two networks about what the DSCPs mean and the resulting PHBs.   Absence of such agreements/understandings is a major cause of current bleaching behavior.

> As per my earlier email, I am trying to write BCP PHB/CP treatment for the
> Internet. This will by definition be very simple, and an alternative to
> "set CP=0 ;send to large FIFO" or "sent to large FIFO" (just ignore CP and
> don't touch it, treat everything as BE regardless of DSCP set) which is
> typically the two ways generally done today.
> 
> RFC8325 states lots of things, which I guess is actually implemented in
> products today, or we aim that to be the default. We have lots of history.

For this exercise, RFC8325 has too many traffic classes, as does RFC4594, upon which RFC8325 draws heavily.  The intent was always that actual networks would support a subset of the RFC4594 traffic classes, as stated in the introduction section of RFC4594:

   However, we expect that
   network administrators will implement a subset of these classes
   relevant to their customers and their service offerings.

As Ruediger has already mentioned, RFC 8100 is likely to be a better starting point for this exercise, to which one could add a few things like LE, as opposed to starting from RFC4594/RFC8325 and figuring out what large collection of things to remove.

> Remember, there are applications out there which actually sets DSCP and
> seems to expect PHB treatment, that are in wide use. These application
> developers did this because they thought it was the right thing to do.

IMHO, it's very important to distinguish this endpoint-marking use case from the network interconnect use case.  For an example of endpoint marking guidance, see (IESG-approved, but not yet published as an RFC) 	
draft-ietf-tsvwg-rtcweb-qos (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/).   For a network interconnect example, see RFC 8100.

> Can we come up with something that is marginally better than we have
> today? My 3 PHB queues was an attempt to do this.

Please consider RFC8100 as a plausible starting point.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Mikael
> Abrahamsson
> Sent: Friday, April 20, 2018 9:15 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [tsvwg] residential broadband BCP PHB and CP treatment Re:
> CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04
> 
> On Fri, 20 Apr 2018, [e-mail] wrote:
> 
> > At an interconnection interface, I side with Brian. To me, a provider
> > sending DSCP marked packets to my domain without exchanging
> information
> > about the PHBs linked to the DSCPs is not interested in ensuring end to
> > end Diffserv support. General remarking to a codepoint resulting in
> > default transport is viable interconnection router option in that case
> > (if a domain supports Diffserv). I don't however object to other domains
> > behaving differently.
> 
> I don't understand what this means in practical terms.
> 
> How do you expect Internet Tier1:s to know the expected PHBs of traffic of
> their customers customers customers customer?
> 
> As per my earlier email, I am trying to write BCP PHB/CP treatment for the
> Internet. This will by definition be very simple, and an alternative to
> "set CP=0 ;send to large FIFO" or "sent to large FIFO" (just ignore CP and
> don't touch it, treat everything as BE regardless of DSCP set) which is
> typically the two ways generally done today.
> 
> RFC8325 states lots of things, which I guess is actually implemented in
> products today, or we aim that to be the default. We have lots of history.
> 
> Remember, there are applications out there which actually sets DSCP and
> seems to expect PHB treatment, that are in wide use. These application
> developers did this because they thought it was the right thing to do. For
> instance openssh sets IPTOS_LOWLATENCY (as per earlier discussions). Now
> people are trying to change the defaults of ssh and looked at
> IPTOS_LOWLATENCY and said "hm, this looks like it should be AF21 instead".
> Is this sensible default? Should we just ignore these kinds of
> initiatives?
> 
> Can we come up with something that is marginally better than we have
> today? My 3 PHB queues was an attempt to do this.
> 
> We have an historic mess. Can we say what we think should be the future
> and come up with a recommendation for PHB that is not very harmful but
> still brings us away from "single large FIFO for everything"? It doesn't
> have to be perfect, it just has to be better than we have today and not
> provide too many downsides. This is what I aimed my 3 PHB queues proposal
> to be.
> 
> --
> Mikael Abrahamsson    email: [e-mail]