Re: RFC 1812, section

William Chops Westfield <> Sun, 17 September 1995 07:14 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa06004; 17 Sep 95 3:14 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06000; 17 Sep 95 3:14 EDT
Received: from by CNRI.Reston.VA.US id aa07465; 17 Sep 95 3:14 EDT
Received: from by (5.65c/5.61+local-22) id <AA05608>; Sat, 16 Sep 1995 23:45:47 -0700
Received: (billw@localhost) by (8.6.8+c/8.6.5) id XAA20146; Sat, 16 Sep 1995 23:45:14 -0700
Date: Sat, 16 Sep 95 23:45:14 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: William Chops Westfield <>
To: Craig Partridge <>
Subject: Re: RFC 1812, section
In-Reply-To: Your message of Thu, 14 Sep 95 17:25:26 -0700
Message-Id: <>

	2.  You can skip verifying the IP checksum if you use incremental
	checksum updating and the only field being changed is the ttl.

    I read various related documents and sections of 1812, and I think either
    interpretation is valid, though there are hints that interpretation (1)
    may have been intended.  I'm obviously very interested in doing (2),
    because on a processor I'm looking at, it represents a 25% performance hit
    to actually compute and check the checksum on the header.

I think what it amounts to is that most people agreed that (2) might be an
interesting approach, but no vendor was ever gutsy enough to do it and risk
the resultant semi-technical ridicule that might occur in the competitive
marketplace.  (You know salescritters - it'd be "Yeah, the cisco's almost as
fast as we are, but they don't even check if the packet's valid before they
forward it.")

I find it difficult to believe a 25% performance hit considering the other
sanity checks that probably have to be made, but then I've never counted
cycles through our fastest single-processor path...