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

[Brian E Carpenter <[e-mail]>]

On 10/04/2018 21:00, Toerless Eckert wrote:
> On Tue, Apr 10, 2018 at 08:52:10AM +1200, Brian E Carpenter wrote:
>> On 09/04/2018 19:13, [e-mail] wrote:
>> ...
>>> My general view is: don't link determined end to end transport behavior to DSCP values bearing no 
>>> end to end significance.
>>
>> +many. The fact that DSCP meanings are domain-specific is so fundamental
>> that coupling them to e2e transport behaviour is condemned to failure.
> 
> I don't  know how to read Ruediger and your statements. How is an LE
> sender meant to indicate that the traffic is LE if not via an end-to-end DSCP
> indicating LE ? 

DSCPs are by definition source-to-edge, so the strict answer to your
question is "they can't". All DSCPs are in principle rewritten at each
admin boundary. 
(Why? Because the ISPs active in the diffserv WG insisted on this.)
(Don't like this? Step 1, invent a time machine and set it to 1998.)
If and only if there is an SLA between adjacent networks, then
DSCPs mentioned in the SLA could be copied over.

If there was a BCP about diffserv mapping across domain boundaries,
that might amount to a sort of universal voluntary SLA. But RFC8100
is Informational. Maybe it will prevail.
 
>> (Which we spent a lot of time explaining to the WebRTC folk.)
> 
> draft-ietf-tsvwg-rtcweb-qos ? 

No, RFC7657 (from the DART WG).

> Too bad it doesn't have changelogs. WOuld love
> to know what was changed in it because of that feedback. No mentioning
> of interdomain so not sure how this draft is relevant here...

The real question is whether rtcweb deployment encourages deployment
of RFC8100 style mappings. I'm pessimistic.

Yes, this strictly irrelevant to LE, but the underlying question is
the same I think - whatever we put in our RFCs, what is the incentive
for carriers to deploy LE support, or RFC8100 support in general?

    Brian