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

[Sebastian Moeller <[e-mail]>]

Hi Gory,



> On May 15, 2020, at 14:20, Gorry Fairhurst <[e-mail]> wrote:
> 
> 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.

	[SM] That was not my claim, I understand that the RFCs and reality diverged, but it is an argument that Tom Herbert made in the encrypted transport header discussion that seems appropriate here. Both endpoints, and network elements will fiddle with ECT(1) if that conveys an advantage, independent of whether it is recommended or not.


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

	[SM] Well, that equipment, according to the cited paper, will also (with low probability) bleach the ECN field (interpreting it as TOS) so that issue already exists for L4S with ECT(1), no?


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

	[SM] Yes theoretically true, but as reality seems to demonstrate not a strong enough driver for bleachers/remappers to change their way. A L4S DSCP/PHB that directly implies desirable traffic properties to each network node (less burstyness or more re-ordering tolerance) might change that value equation.


>> and treat it like BE for the operator in question.
> Perhaps - because mapping to a PHB is different to changing the DSCP.

	[SM] I am not fully understanding this argument. Sure these are different things, but the recommendation, remap locally unused DSCPs to the BE PHB, seems not to have gotten too much traction according to the data. Unless we assume that each network only ever re-mapps those input DSCPs that it uses for its own internal purposes, and that by pure chance DSCPs in the decimal ~8-48 range (see Figure 2) all get remapped, because networks either use a lot of dscps internally or different networks use mostly not overlapping sets of DSCPs. Honestly, I would bet on networks simply re-mapping everthing to zero and then upmark those paket with their internal DSCPs. It is always safer to re-map to zero and only elevate packets with known properties...

Best Regards
	Sebastian

P.S.: I am really not seeing how your paper does support the case for ECT(1) for L4S at all. For the one critical segment, mobile, I see quite enough involvement of @mobile-corp email addresses here, that getting the mobile segment honor a L4S-DSCP seems in no way insurmountable, IFF they are actually as interested in HFCC.



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