Odd TCP ECN related bahavior

[Rodney W. Grimes]

> 
> Hi all,
> 
> I am not on this mailing list. So, all responses should be sent
> to my personal address.
> 
> I just noticed somewhat confusing network behavior when I was
> using wireshark to understand why certain connections have been
> unexpectedly slow.
> 
> My 11.3 stable (latest update 2019-06-23) seems to do this
> according to wireshark...
> 
> .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)

You only show 1 packet, and without the type of that packet
I can not tell if this is an error in the code or simply
that you captured one of the packets that does not marked
with ECN bits even in an ECN flow

Note also that ECN is negotiated on a per TCP connection,
not on every single packet.  

> 
> My system has this set, though...
> 
> net.inet.tcp.ecn.enable: 1

So ecn should be negotiated in both directions.

> 
> At the same time the peer system was reporting ECN capability...
> 
> .... ..10 = Explicit Congestion Notification: ECN-Capable Transport 
> codepoint '10' (2)
> 
> Apparently increasing the value in...
> 
> net.inet.tcp.ecn.maxretries
> 
> doesn't help.
> 
> What should I make of this? Is the ECN implementation in 11.3 somehow
> faulty or is this something more down to earth?

If it is I would certainly like to now asap,

> --jau
-- 
Rod Grimes                                                 rgrimes at freebsd.org