Re: [tsvwg] CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04

[<[e-mail]>]

Hi Toerless

Some more points marked [RG].

Regards, Ruediger

-----Ursprüngliche Nachricht-----
Von: Toerless Eckert [mailto:[e-mail]] 

> There is no end-to-end DSCP indicating the same PHB unless all 
> providers, departments, platform owners (and so on) along the 
> end-to-end Transport chain agreed on the value.

Sure. 
a) thats why we write these drafts/RFC to establish such DSCP standards.
b) If there is no end-to-end DSCP, there is also no other way to
   indicate end-to-end PHB.

[RG] The DSCP may change if RFC 8100 or the like isn't applied. The idea is to 
get an end-to-end PHB.

> My take of your LE discussion was that the sending party doesn't care, 
> whether there's a Diffserv agreement in place with a receiving domain. 
> In that case, it is a no go to link any service or transport specification to the DSCP value.

No, its not about parties "not caring" about DiffServ agreement. Its just that any new diffserv semantic we want to bring into "the Internet" needs to have a good story-line how it can be be backward compatible with BE in case there is no end-to-end agreement, and with LE we can IMHO easily do this. I don't think "good fallback" is the same as "don't care".

E.g.: for me the logic is quite simple: Applications indicate the end-to-end desired PHB/DB via a DSCP, the path/domains try to figure out if/how that desire can be met. If such an app is deployed on the Internet, it also needs to have some fallback to BE - Circuit breakers or BE compatible CC.

[RG] Compatibility with default transport and Best Effort service is useful and alright in that case. To me no agreement on a Diffserv transport service means default transport (& bleaching) of traffic received at interconnection and I think this interpretation is backed by Diffserv standardization.