Date: Mon, 24 Jun 2019 08:00:49 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: "Jukka A. Ukkonen" <jau789@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Odd TCP ECN related bahavior Message-ID: <201906241500.x5OF0nRT044101@gndrsh.dnsmgr.net> In-Reply-To: <777f12f5-3c58-a6ef-5a92-df6be9372ec6@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201906241500.x5OF0nRT044101>