Re: [tsvwg] David Black (individual) on safety of L4S for the Internet

[Gorry Fairhurst <[e-mail]>]

Hi,

On 15/05/2020 12:26, Sebastian Moeller wrote:
> Hi Gorry,
>
>
>> On May 15, 2020, at 11:59, Gorry Fairhurst <[e-mail]> wrote:
>>
>> See in-line
>>
>> On 15/05/2020 01:03, Black, David wrote:
>>> Bob,
>>> [still posting as an individual, not as WG chair]
>>>
>>>
>>>> Firstly an appeal to everyone to stop talking about wiping the ECN field
>>>> as if it is acceptable. Bleaching ECN is not a safety mechanism, except
>>>> as a last resort. Treating ECT(1)
>>>> /as if/
>>>>   it is Not-ECT is far
>>>> preferable to wiping it so it
>>>> /is/
>>>>   Not-ECT.
>>>>
>>> I concur with that appeal ... but ...
>>>
>>> .... We've been through an analogous adventure with DSCP bleaching, as RFC 2474 recommends that behavior for DSCPs (treat unknown DSCPs as best effort without changing the DSCP) but the network operators went ahead and bleached DSCPs at network boundaries, as described in Section 1 of RFC 8100 (
>>> https://www.rfc-editor.org/rfc/rfc8100.html#section-1
>>> ).  I strongly suggest reviewing that history towards understanding why things turned out that way.
>>>
>>>
>> Well, some operators have chosen a model that does that, I can't resist self-citing some research that shows this might not be the full story ... "Exploring DSCP modification pathologies in the Internet" (2018).
>>
>> https://www.sciencedirect.com/science/article/pii/S0140366417312835
> 	[SM] Well, my take on that is that there is a 80% or higher chance (transparent plus Reset ToS prec. plus Reset ToS prec. CS6/CS7)  for DSCPs with 3 leading zero bits to survive internet traversal. That seems like a viable starting position for a LL classifier IMHO. In reality L4S will only work well over short paths anyway (mostly CDN -> end-user) and there the number of Diffserve domain crossings should be on the lower side and SLAs might be an option to make an L4S-dscp actually survive well.

> 	As the bleaching ECT(1) argument demonstrates any marker on a packet will be considered fair game to manipulation if that still allows delivery of the packets
Not really the IETF recommendation.
>   and fiddling it gives advantages to either senders or to intermediate hops, so the superiority of ECT(1) in internet traversal really is just a snapshot due to the circumstances that nobody got sufficiently annoyed by ECT(1) yet. IMHO if L4S works and is really worth its salt (meets its promises), it should be able to pull its own weight, by making networks operators take care to not bleach its reference DSCP, instead of forcing ECT(1) on everybody.
Equipment still configured for ToS Semantics is hard to change. 
Although, useful to do so.
>> The reasons for field bleaching seem to vary, (and, alas, a significant proportion still seems to be due to configured ToS semantics).
> 	[SM] Clearly one of the reasons is that so far there is absolutely zero value to conserve an unhandled DSCP
DSCPs might be utilised by other network segments and hence could add 
value to the traffic.
> and treat it like BE for the operator in question.
Perhaps - because mapping to a PHB is different to changing the DSCP.
> According to the L4S RFCs however, everybody is going to profit from L4S everywhere, so surely those operator straggling today to leave DSCPs alone will now do so for the L4S-dscp since that will give them better network performance (even if not participating in the L4S experiment, they could optimistically expect less bursty traffic patterns, allowing to drive the gear at higher average load). Either that or that "everybody is going to profit" claim is being falsified, either way an interesting result.
>
> Best Results
> 	Sebastian
>
>
>> Gorry

-- 
G. Fairhurst, School of Engineering

I'm not sure how a transport would ensure that the bottleneck links are using a DSCP in their classifier, and how you would operators would police such a scheme
- excepet perhaps to confine L4S as an ISP experiment for their own customer base (which they can already do using a private DSCP).
This just involves more components in the deployment. I thought the WG has gone
beyond the idea of doing an experiment within an ISP to proposing a new architecture, so I really don't understand how
the use of a DSCP would help deploy that experiment.

Gorry.