Re: [tsvwg] FQ & VPNs

[Sebastian Moeller <[e-mail]>]

Ingemar, List,

let me note that a tunneled connection as you seem to describe, will either yield and behave like a single flow at any AQM/bottleneck or will risk to look like a non- or  under-responsive flow that violates the internet's assumption of rough equitable sharing of capacity (TCP-friendlyness).

	Sure, the tunnel end-points might know that the tunnel carries X flows and hence might consider it desirable and "fair" to get roughly X/N throughput on a congested node with N true flows, but how is the intermittent node expected to figure this out and still assure rough sharing?

	Are you really proposing that all bottleneck nodes should give the least responsive flows most capacity? That seems like an ideal strategy to be 
exploited/gamed by all transport protocols, leading to a race to congestion collapse. 

	As before, I am happy to concede that approximate flow fair queueing is almost never optimal, but also rarely pessimal, and without additional information probably the most deterministic/predictable behavior an intermittent node can choose. 

	In theory we could use the IPv6 flow label to pass information about flow identities to the outside of tunneled packets, in which case FQ will work reasonably well (this is harder to game, unless the traffic is completely re-ordering tolerant, as an FQ system only maintains order inside each "flow", but is free to re-order between flows).

	None of that discussion seems novel or particularly pertinent at this point in L4S' evolution though; how did we end up in this side-discussion again? Ah, yes, L4S' lack of safety by design; the point is that the argument has been made multiple times that L4S' under responsiveness to CE marks could be ignored assuming most all rfc3168 AQM employ FQ and hence the fall out of L4S's wrong interpretation of CE marks would be restricted to the (stochastic) queue used mostly be the L4S flow itself and hence would not cause harm to other traffic. Which has two issues, one: due to the birthday paradox hash collisions are not that rare, that L4S will cause harm to non-L4S bystander flows that happen to hash into the same queue, and the whole thing goes pear shaped with tunneled traffic containing a mix of L4S and non L4S packets. 


Best Regards
	Sebastian




> On Feb 20, 2021, at 19:42, Ingemar Johansson S <ingemar.s.johansson=[e-mail]> wrote:
> 
> Dave, Jonathan
> 
> Getting back to the subject. 
> 
> Quoting Jonathan " However, I would remind you that neither SFQ nor fq_codel can distinguish between flows carried inside an encrypted tunnel, so this cannot be relied upon alone to make L4S safe.  Pete's data shows significant tunnelled traffic, much of which is probably due to people working from home and using VPNs to access a corporate network."
> 
> This line of reasoning makes me confused.
> Section 6.2 in RFC8290 ( https://tools.ietf.org/html/rfc8290#section-6.2) clearly says that fq-codel will not deliver its intended benefits for encrypted tunnels. If ISP's still rely on fq-codel to do it´s job well even though a substantial share of the traffic is VPN, then that is of course a problem. But I see that only as an fq-codel problem.
> 
> So what I cannot at all understand.. Why should a known problem (or read design feature) in fq-codel (or SFQ) be interpreted as something that makes L4S unsafe ?. 
> 
> /Ingemar
> 
> 
> 
>> -----Original Message-----
>> From: tsvwg <[e-mail]> On Behalf Of Dave Taht
>> Sent: den 20 februari 2021 02:22
>> To: Bob Briscoe <[e-mail]>
>> Cc: TSVWG <[e-mail]>
>> Subject: Re: [tsvwg] FQ & VPNs
>> 
>> It takes an awful lot here for me to bother to reply to a thread.
>> 
>>> Here is an algorithm to find the truth. Take one of your emails, and do a diff
>> with the previous email in the thread. Then the other person's text that you
>> silently deleted (as above) will invariably be the truth.
>> 
>> Here is a better algorithm to find the truth. Purchase any of dozens of
>> commercial routers today running cake or fq_codel, or the thousands
>> available via reflash to openwrt/dd-wrt/tomato construct a repeatable
>> experiment, and publish the code and results. The results from running,
>> repeatable, code trumps theoretical objections every time.
>> 
>> The evenroute v3 and edgerouter X series are pretty good bases for
>> experimentation.
>> 
>> Wilful ignorance, and the lack of a willingness to construct repeatable
>> experiments is not science. If you have a point to make, make it with a
>> repeatable experiment against running code, please.
>> 
>> Tuning out again.
>> 
>>> 
>>> 
>>> Bob
>>> 
>>> --
>>> 
>> __________________________________________________________
>> ______
>>> Bob Briscoe
>> https://protect2.fireeye.com/v1/url?k=e8b458ab-b72f6049-e8b41830-
>> 86073b36ea28-0086813e29ae2dfb&q=1&e=e1b27d62-c59c-43ba-b512-
>> e8cf13c35f2c&u=http%3A%2F%2Fbobbriscoe.net%2F
>> 
>> 
>> 
>> --
>> "For a successful technology, reality must take precedence over public
>> relations, for Mother Nature cannot be fooled" - Richard Feynman
>> 
>> [e-mail] <Dave Täht> CTO, TekLibre, LLC Tel: [phone]