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

[<[e-mail]>]

My comments are marked [RG], regards, Ruediger

-----Ursprüngliche Nachricht-----
Von: Mikael Abrahamsson [mailto:[e-mail]] 
Gesendet: Freitag, 20. April 2018 15:15
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]
Betreff: 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.

[RG] RFC8100 should explain that. If RFC8100 requires clarifications, please 
point out the relevant issues.

      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.

[RG] I'm fine with optimisations related to scheduling of wired/wireless traffic within home networks or at hot spots. This may also include BNG behavior. The case of a provider not supporting a PHB must be expected. Please don't read that as a recommendation not to support the PHB. I want a clear specification, covering all cases which are reasonable to expect.

      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?

[RG] BCP is based on widespread support. Didn't hear of that in the example you mention. I'm not aware of any discussion of the openssh community within IETF, when they went to pick a codepoint. I can add standards of other SDOs which determine DSCPs and PHBs, but never were liaised with IETF. 

     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.

[RG] My experience is that those interested in Diffserv first determine their own architecture and deploy and operate that locally.  Then they figure out, that there's world outside of their LAN and Diffserv might be useful end-to-end. The usual conclusion is, the others may adapt to their local scheme, as they made up their mind before deploying and why should they adapt their deployment, rather than the others? I've settled a couple of these discussions, and sometimes partial agreement was the best I could reach.
To me, the Diffserv AF classes offer to much flexibility in terms of DSCPs and PHBs and too little guidance of when to deploy a specific DSCP and the PHB linked to it. We could try to clean up that, but I expect that we have to cope with multiple operational deployments all differing in some detail.