Re: [tsvwg] Fwd: New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt

[Jonathan Morton <[e-mail]>]

> On 22 Mar, 2021, at 6:53 pm, Bob Briscoe <[e-mail]> wrote:
> 
> The results for the 38 IPs backhauled via the FQ-CoDel nodes (known to support ECN) are even more unexpected (again taking only the TCP results, because they show both directions):
> * In the direction from the LAN, 10 of these 38 IPs saw no ECN marking from the LAN side (including none from those FQ-CoDel nodes), but they did see the feedback of ECN marking from somewhere deeper into the network.
> * The results in the direction from the WAN are more what I would expect: 30 of the 38 IPs saw no ECN marking from the WAN side, but they did see the feedback of ECN marking that must have occurred on the LAN side (where the FQ-CoDel nodes are).

Some members of this ISP run servers.  This might be surprising from a UK or US perspective, as the incumbent telcos have tended to prevent people from doing that on a "domestic grade" service contract.  But since this is a cooperative ISP, the rules are different.

These servers are "found" by the background of port scanners that has been a feature of the Internet for many years now.  These port scanners often perform a "fingerprint" analysis of servers they find, which includes a probe of their ECN behaviour.  Each port scan is thus associated with an equal number of "artificial" CE marks and ECE flags.  As described, we filtered patterns like that out of our results post-hoc.

This leaves open the possibility of servers at "our" end which see port-scanning activity, also see little congestion within the ISP, but see a small amount of congestion, occasionally, at the client end of their connections, some small fraction of which are ECN Capable.  This is what we think those cases you refer to probably represent.

One possible explanation for this is clients connecting over wifi, through an AP that supports the Airtime Fairness feature introduced for several popular wifi chipset drivers in Linux some years ago.  This includes ath9k, ath10k, and mt76, which together account for a large fraction of deployed wifi APs.  It would not be strange for a wifi link to sometimes be a lot narrower than some of the ISP members' links.

 - Jonathan Morton