Re: [tsvwg] Reasons for WGLC/RFC asap

[Jonathan Morton <[e-mail]>]

> On 19 Nov, 2020, at 4:24 pm, Ingemar Johansson S <ingemar.s.johansson=[e-mail]> wrote:
> 
> Recall from the discussion yesterday that Stuart Cheshire and
> his team has not need evidence of ECN marking AQMs. So I fear that we spend
> a lot of time discussing problems that are very rare.

Okay, I'm going to interject on this.  I don't know precisely how Apple is collecting their data, but you can see the data collected by a MacOS X machine by entering the following in Terminal:

	sudo netstat -sp tcp

About two-thirds of the way down the output, you should find a group of statistics related to ECN.  Here's mine:

	917 client connections attempted to negotiate ECN
		789 client connections successfully negotiated ECN
		97 times graceful fallback to Non-ECN connection
		1 time lost ECN negotiating SYN, followed by retransmission
		0 server connection attempted to negotiate ECN
		0 server connection successfully negotiated ECN
		0 time lost ECN negotiating SYN-ACK, followed by retransmission
		162 times received congestion experienced (CE) notification
		0 time CWR was sent in response to ECE
		1986 times sent ECE notification
		32 connections received CE atleast once
		0 connection received ECE atleast once
		298 connections using ECN have seen packet loss but no CE
		17 connections using ECN have seen packet loss and CE
		15 connections using ECN received CE but no packet loss
		0 connection fell back to non-ECN due to SYN-loss
		14 connections fell back to non-ECN due to reordering
		0 connection fell back to non-ECN due to excessive CE-markings

Of the connections where ECN negotiation was attempted, most (almost 90%) succeeded, and of these some did show ECN activity in practice - noting that many connections probably did not reach the shaper limit set by my ECN-enabled router, or reached the capacity of my rural LTE connection at a time when it was less than the shaper limit.

But to put this into context, further up is:

	117038 connection requests

This is a machine with ECN support forced on by appropriate entries in /etc/sysctl.conf.  Even so, less than 1% of TCP connections initiated even *attempted* to negotiate ECN.  This led me to discover that MacOS X had unexpectedly and erroneously designated my network as an ECN blackhole, a condition that was temporarily resolved by turning wifi off and on again, but soon recurred for unknown reasons.  (This effect does not occur with my Linux-based machines.)

If this erroneous ECN blackholing phenomenon is common in Apple devices - not only desktops and laptops but also iPhones and iPads - then that would certainly explain why Stuart Cheshire sees so little ECN activity in the data available to him.  I would encourage him to double-check that with appropriate technical employees at Apple.

I note also that Jake Holland's data from Akamai depends on client endpoints initiating ECN negotiation, which is by no means universal thus far, and may therefore understate the deployment of RFC-3168 compliant AQMs (which exert congestion signalling via packet drops for Not-ECT traffic) by a large factor, especially in the small number of ASNs that already show significant ECN activity in that data.

In short, I believe there's a lot more ECN deployment in practice than most people realise.

 - Jonathan Morton