Re: [tsvwg] FQ & VPNs

[Pete Heist <[e-mail]>]

Hi Greg, some comments below [PH].

On Sun, 2021-02-21 at 23:49 +0000, Greg White wrote:
> On 2/21/21, 4:25 PM, "tsvwg on behalf of Jonathan Morton" <
> [e-mail] on behalf of [e-mail]> wrote:
> 
>     L4S cannot safely be deployed on existing networks - that is
> axiomatic in its current form.  Therefore, you have to prepare the
> network as fully L4S-aware before you can safely deploy your first
> endpoints - on Internet scale, that is not really feasible within a
> decade.  It would be easier to start deployment if you had a good way
> of containing L4S traffic to a small portion of the network (eg. a
> CDN and an associated ISP) in which dealing with the network
> preparation is actually feasible in the short term.
> 
> [GW] This is blatantly false. In the vast majority of paths, L4S is
> considered safe for deployment today.  In a minority of paths there
> exists the rare possibility of L4S flows achieving more than their
> "fair" share of the bottleneck link bandwidth, and an extremely rare
> possibility that this unfairness results in a significant temporary
> degradation of classic traffic performance.  In these paths there is
> almost certainly only one network element that will need to be
> updated in order to prevent any possibility of such degradation, and
> as far as anyone can discern at the moment those network elements are
> largely prosumer grade home routers that are increasingly being
> actively patched already. 

[PH] In regards to the proportion of paths with RFC3168 AQMs deployed,
referring to section 3.2 in our recent draft, and cautioning that this
is not authoritative:
https://www.ietf.org/archive/id/draft-heist-tsvwg-ecn-deployment-observations-01.html#name-rfc3168-aqm-activity

If we remove the IP addresses that I had an influence on, leaving only
the unknown sources of AQM marking, then the proportion of IPs that
successfully negotiated ECN and saw CE or ECE, i.e. apparently had an
AQM on the path, is (90-38)/382 = 0.14.

I also noticed during a few script runs, as it was refined, that as we
let it run longer, more IP addresses appeared that saw CE or ECE. AQMs
are only visible to us when flows both negotiate ECN and experience
congestion at those AQMs. It takes time for detection when 1.44% of
SYNs had ECN capability, so we may have missed some.

The 1.44% ECN SYN proportion may also make it more difficult to detect
ECN traffic within tunnels, because now we have the product of ECN
capable traffic with traffic that's traversing a tunnel. However, that
product does not apply to the potential for induced harm, since that
occurs to both ECN and non-ECN capable flows.

[PH] As to the level of harm induced when traffic winds up in the same
queue, it appears that in the presence of a "long-running" L4S flow,
short flows as well as long flows, ECN capable or not, may be affected.
As flows start up, there can be "good" cases:

http://sce.dnsmgr.net/results/l4s-2021-02-19T194323-s8/l4s-s8-rfc3168-second/l4s-s8-rfc3168-second-ns-prague-vs-cubic-ecn-fq_codel_1q_-50Mbit-20ms_tcp_delivery_with_rtt.svg

and "not as good" cases:

http://sce.dnsmgr.net/results/l4s-2021-02-19T193357-s8/l4s-s8-rfc3168-second/l4s-s8-rfc3168-second-ns-prague-vs-cubic-ecn-fq_codel_1q_-50Mbit-80ms_tcp_delivery_with_rtt.svg

It might be useful to have a histogram of FCT vs flow length, to
project what the user experience might be like for web browsing or
other applications in the presence of long-running L4S flows.

Regards,
Pete

> [snip]
> 
>     Conversely, let's look at SCE from the same perspective. 
> Remember, SCE is capable of achieving the same performance as L4S,
> given similar marking and response algorithms.  The difference is in
> backwards compatibility.
> 
> [GW] The WG considered SCE and has decided against it.  You seem to
> be repeating the same arguments (with the same transparent hyperbole)
> that led to that conclusion in hopes that the outcome somehow
> changes. 
> 
> [snip]
> 
>