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

[Sebastian Moeller <[e-mail]>]

Hi Bob,

more below in-line, prefixed with [SM]. 


> On May 16, 2020, at 01:12, Bob Briscoe <[e-mail]> wrote:
> 
> 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.

	[SM] Oh, sure, But for L4S to go anywhere the edge ISPs need to be on-board anyway, so that final level of potential bleaching, is IMHO less of a hard obstacle and more of a test whether there is actually demand for L4S' promises and deliverables. That applies both to the fixed-line and the mobile edge. 


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

	[SM] Yes, but either the carriers are interested in L4S ad then passing a single DSCP will not be an unsurmountable problem, or the market will have spoken about L4S.


> 
> 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!)

	[SM] That would surely be interesting in itself, but I believe orthogonal to the question whether DSCPs are a viable way to signal intent end-2-end. IMHO that will work if the intermediate networks can also profit, and according to L4S promises they should. (I am less optimistic about these advantages offered by L4S, but I am happy if I should be proven wrong about this by reality).


> 
>> In reality L4S will only work well over short paths anyway (mostly CDN -> end-user)
> 
> [BB] Is this a fact, or an alternative fact?

	[SM] Future tense should have made clear that this is a prediction, sorry, but as a non-native speaker of english I sometimes miss subtle points and assumed no "In reality I predict, L4S will...". 
	I base this prediction on ancient and recent rounds of testing from both team L4S and team SCE. The amount of realistic scenarios where L4S falls way short of how reasonable minds will read its promises, and the lack of sufficiently adversarial testing from team L4S, together with the hopes and wishes that ECT(1) will not be abused (instead of hard requirements and/or analysis). 
	I still think that on reasonable short paths things might work reasonably well most of the time though, and hence conceded positive uitility for L4S for short paths. I note that when I asked about bi-directional saturating tests, you did not deliver data, but just accepted that L4S will do badly under those circumstances.

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

	[SM] Erm, sorry, I did not introduce ECT(1)-bleaching, it were other's supportive of L4S that brought up that in case of failure bleaching ECT(1) might be an option. All I note above is that if bleaching ECT(1) gives an intermediate node an advantage it will be done, no amount of words in the L4S RFCs to the opposite. I also predict L4S to fail at least of non-short paths and hence assume ECT(1) bleaching to become a reality. Call it conjecture, but your hypothesis that ECT(1) will not be bleached is based on the same incomplete information and hence also just a 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.

	[SM] Yes, but proper reading of that data indicates that by thoughtfully selecting a DSC with the 3 TOS precedence bits set to zero, significantly increases that percentage to above 80%. I did mention that explicitly, so let's stick to my numbers please.


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

	[SM] Sure, but that does not change the fact the ECT(1) is not qualitatively different in that regard.

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

	[SM] Yes that looks less attractive, but with mobile carriers interested in L4S' offerings, that should be relatively easy to change, given the size and range of the big mobile carriers action of a few players will "unlock" L4S for a considerable number of users, even if other ISPs struggle behind.


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

	[SM] I conceptually agree, except I offered a pretty close to the numbers reading of the paper. So let's stick to objective arguments, please. 


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

	@chairs: I wonder whether this is the level of discourse to aim for on this list?

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

	[SM] I apologize for being to terse here, I am talking about a hypothetical DSCP L4S could use as signal from the end-points to request 1/p-congestion signaling. I assumed that everybody participating in this discussion is sufficiently fluent about the L4S drafts to understand that. Your argument indicates that I was wrong, so thanks for giving me an opportunity to clarify this.

> ECT(1) already inherently identifies L4S packets.

	[SM] That is the plan, but we have gone though this ad nauseam, so please tell me L4S sees a CE marked packet, what kind of flow does this come from? I do not ask whether that is important to know, I ask how would an L4S node deduce this from a non-existent identifier.


> If a DSCP were used as well, networks supporting L4S would ignore it, given it's redundant anyway, and it might sometimes be bleached.

	[SM] Well, you probably missed my position, I am of the opinion that ECT(1) should not be used as input, and hence that situation would not really happen. I have given my rationale in the past, so will not repeat that here (but it is related to my prediction above).

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

	[SM] I am with you on this Bob, we just differ in which "identifier" we would jettison respectively.


Best Regards	


Sebastian

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