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

[Mikael Abrahamsson <[e-mail]>]

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]