From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <4bone@gndrsh.dnsmgr.net> Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 76B8F3CB36 for ; Mon, 12 Aug 2019 21:01:39 -0400 (EDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x7D11Z29014243; Mon, 12 Aug 2019 18:01:35 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net) Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x7D11Z77014242; Mon, 12 Aug 2019 18:01:35 -0700 (PDT) (envelope-from 4bone) From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Message-Id: <201908130101.x7D11Z77014242@gndrsh.dnsmgr.net> In-Reply-To: <1565657396.226529457@apps.rackspace.com> To: "David P. Reed" Date: Mon, 12 Aug 2019 18:01:35 -0700 (PDT) CC: Jonathan Morton , ECN-Sane X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Subject: Re: [Ecn-sane] cautionary tcp tale X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 01:01:39 -0000 > This is the stupidity of NAT, which encouraged modifying TCP checksums, which are supposed to be not modified in the network at all. Yes, I never liked that this had to be done. > > The whole point of an "end-to-end" checksum is that the middle shouldn't touch it! :-) > Now I get why NAT became popular, though at the time many of us pretty much vomited all over the idea as completely bogus. Still vomiting for some of us that have to deal with it on a continuous basis. > I do worry that now there is TCP checksum offloading in NICs, that middleboxes are feeling freer just to throw away and recalculate checksums as they pass through, and not bother to forward non-TCP, nonUDP, nonICMP IP packets at all. Scarry thought, do these nic cards have ECC on the buffers? Is the datapath through the chip protected by ECC? > This would be the kind of thing that Cisco, for example, might just do, since they have long thought that they owned the Internet design as a corporate entity. Well thankful a few competitors have shown up to level the game, a bit anyway. > On Monday, August 12, 2019 7:37pm, "Jonathan Morton" said: > > >> On 13 Aug, 2019, at 12:30 am, Dave Taht wrote: > >> > >> https://www.snellman.net/blog/archive/2017-07-20-s3-mystery/ > > > > TL;DR summary: > > > > Buggy checksum recalculation in a cable modem caused minor packet loss (through > > rejection at the receiver). In the absence of TCP Timestamps, the retransmissions > > of these lost packets were identical and triggered the same bug. Result, > > connections to certain particular servers which had the unusual property of > > disabling TCP Timestamps would quickly stall. > > > > I think a tool could be made to watch a sample of received traffic for this > > pattern: incorrect checksums where the correct checksum is the same each time > > (though different per deployment). How much network equipment exhibits this bug? > > > > - Jonathan Morton > > _______________________________________________ > > Ecn-sane mailing list > > Ecn-sane@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/ecn-sane > > > > > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane > > -- Rod Grimes rgrimes@freebsd.org