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

[Bob Briscoe <[e-mail]>]

Sebastian,

On 15/05/2020 12:26, Sebastian Moeller wrote:
> Hi Gory,
>
>
>> 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.

[BB]
I don't think you've read the paper closely enough. The measurements you 
quote did not cross any access network. They were  from a couple of 
dozen vantage points in Digital Ocean data centres to large numbers of 
popular web server destinations. That doesn't measure what typical 
access networks do to the DSCP.

The paper does include measurements from 107 vantage points connected to 
Internet access networks, but solely mobile. Here, for any DSCP except 
best efforts, the % unchanged is never better than 38%.

For how fixed access networks mangle Diffserv, you'd need to measure 
from vantage points on something like PlanetLab. Reference [31] measured 
from both MONROE and PlanetLab vantage points to characterize mobile and 
fixed access, but that was looking more at the effect on ECN than 
Diffserv. We did take some Diffserv measurements to look for correlation 
with ECN wiping. But from memory I think we only added the Diffserv test 
over mobile, 'cos that's where nearly all the ECN wiping was. I'll take 
a look at the data when I have some time (ha ha!)

> In reality L4S will only work well over short paths anyway (mostly CDN -> end-user)

[BB] Is this a fact, or an alternative fact?

> 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 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.
>

[BB] The bleaching ECT(1) argument doesn't /demonstrate/ anything. It's 
your conjecture.

Currently, for fixed networks:
* according to our measurements (ref [31] in Gorry's study), from 54 
PlanetLab vantage points on 25 networks in 22 countries to the Alexa top 
500k web servers, consistent with previous studies, the ECN codepoint is 
wiped on 0.23% of paths.
* in contrast, according to Gorry's study measured at a similar time, 
from a couple of dozen vantage points in data centres, there is some 
form of DSCP pathology on 70% of paths.
* Gorry's study also found a high correlation between clearing the DSCP 
and clearing the ECN field, which supports the hypothesis that a 
well-documented bug reported on more than one brand of equipment is 
still prevalent, where the ECN field is cleared as an unintentional 
side-effect of clearing the DSCP.

For mobile:
* Our study from vantage points in 18 mobile networks found 10.5 always 
wiped the ECN codepoint, and the others never did.
* Gorry's study from 107 vantage points, in an unstated number of mobile 
networks, found only between about 5% and 25% of paths preserved the DSCP.

When we put a huge amount of effort into measurement studies, it's 
because data is important. When the data contradicts what you want to 
believe, you are welcome to say that the data might change in the 
future. And you can make up reasons why this might happen. But I'm not 
going to make the same points against your arguments again because, when 
you've said the same made-up things once, and twice and three times and 
four times, it achieves nothing other than demonstrating that you like 
the sound of your own keyboard.

> 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.

[BB] There is no reference DSCP for L4S. ECT(1) already inherently 
identifies L4S packets. If a DSCP were used as well, networks supporting 
L4S would ignore it, given it's redundant anyway, and it might sometimes 
be bleached.

It is poor practice to use 2 identifiers for one feature, because both 
then have to be checked and cases where they are inconsistent have to be 
handled, potentially opening security vulnerabilities.


Bob

>> 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 and treat it like BE for the operator in question. 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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/