Re: [tsvwg] Disable ECN on VPNs, really?

[Sebastian Moeller <[e-mail]>]

Hi Koen,



> On Nov 18, 2020, at 11:39, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> Hi Sebastian,
> 
> Indeed, a better solution would be to support L4S in those deployments. Are there any constraints in doing so?

	[SM] Well, once it is settled that L4S is a) safe for the rest if the internet, and b) actually delivers on its promises in more than the Eye-Ball to CDN drag-race course there might be a rationalt to do so. At the current time with all the papered over mis designs n L4S I can not in good conscience recommend anybody to use L4S at all. The decrease of average queueing delay from 5ms to 1ms is going to be less of a bonus point until all the rate fairness kinks are ironed out first.
	But the one thing L4S has going for it, establishing of some kind of AQM at the ISP side of customer's access links, works just as well with bleached ECT(1). Sure single queue PIE is not my preferred AQM, but it certainly beats the ~100ms delay-under-load-increase, my ISP's current traffic shaper induces. That will certainly help with ingress shaping, as now the back-stop is leaps and bounds better than a FIFO.


> It seems to be installable/upgradable packages, not?

	[SM] Who, do you think is going to create and maintain such packages? Team L4S certainly not, your intent is clear in the context of long-term support, or rather lack thereof (like sending of TCP Prague for interested parties to fix/further develop). 

Best Regards
	Sebastian


> 
> Koen.
> 
> 
> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Sebastian Moeller
> Sent: Wednesday, November 18, 2020 10:38 AM
> To: tsvwg IETF list <[e-mail]>
> Subject: [tsvwg] Disable ECN on VPNs, really?
> 
> Dear list,
> 
> in today's tsvwg session chat, Mirja proposed that home-users could simply disable ECN negotiation for VPN tunnels to accommodate rfc3168 AQMs on the path and L4s flows in the tunnel.
> That is certainly an option, as would be to try to disable L4S for all home nodes or trying tp bleach ECT(1) on egress and ingress).
> 	Currently e.g. SQM (distributed as an OpenWrt installable package) employs an ECN fq_AQM at the ingress of home links to great success. The rationale to use ECN here is, that all packets entering the ingress AQM have already traversed the true bottleneck, so dropping them would simply just waste the "transmit slot" on the bottleneck that they already used-up and it would even delay the initiation of the please-slow-down signaling, as we need a few dupACKs to detect congestion from drop, while CE is more immediate (this is a simplification, sure).
> 	In short even classic ECN on a home link's ingress has immense value, and that is true for all packets, including packets in a tunnel, as these also consumed transmit slots when the AQM needs to decide whether to drop/mark. And more, that is an already deployed solution out in the field that works pretty well, you might want to try it ;) before declaring it obsolete and exchange it with the yet unproven promises of L4S.
> 
> Best Regards
> 	Sebastian