Re: [tcpm] draft-anumita-tcpm-stronger-checksum

"Scheffenegger, Richard" <> Wed, 09 June 2010 23:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A5B63A695A for <>; Wed, 9 Jun 2010 16:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jqgttMms4YUN for <>; Wed, 9 Jun 2010 16:53:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 707E53A691D for <>; Wed, 9 Jun 2010 16:53:55 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,395,1272870000"; d="scan'208";a="171039230"
Received: from ([]) by with ESMTP; 09 Jun 2010 16:53:55 -0700
Received: from ( []) by (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o59Nr48p010310; Wed, 9 Jun 2010 16:53:19 -0700 (PDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 00:53:04 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Jun 2010 00:53:03 +0100
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] draft-anumita-tcpm-stronger-checksum
Thread-Index: AcsICfwuTcvIlT2/R4Weh1kzJLrm2wAGuFaw
References: <><> <20100609173556.GA5338@nuttenaction> <><> <>
From: "Scheffenegger, Richard" <>
To: Joe Touch <>, Lars Eggert <>
X-OriginalArrivalTime: 09 Jun 2010 23:53:04.0086 (UTC) FILETIME=[E69E8F60:01CB082E]
Cc:, "Anantha Ramaiah (ananth)" <>
Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Jun 2010 23:53:57 -0000

To further this discussion:

I believe the suggestion using Alternate Checksum Option has the highest

O) no new tcp option number would be needed
O) only an additional checksum option type would need to be defined (and
there are still plenty left; I found no evidence so far, that any other
value than 0 and 1 were ever used - scanning though the I-D archives).

To make this proposal compatible with existing middleboxes, which might
not understand the option, but choose to simply forward it, my
suggestion would be to *NOT* include the TCP pseudo-header in that
alternate checksum, but *only* cover the data section. This would make
it also possible to traverse NAT/PAT gateways, which are agnostic to
this option.

Furthermore, as Koopman has demonstrated, the Hamming distance is a
function of data bits covered - the fewer bits covered, the higher the
HD. Also, As TCP CRC-32 can detect *every* corruption affecting an
uneven number of bits, yet another CRC-32 could be choosen that works
especially well only for even bit corruptions...

The combination of CRC-32 + "CRC-32E" might have even better compound
properties than CRC-32C.

However, the drawback would be to do two calculations (one for the
standard TCP CRC-32, and one for CRC-32C covering only the data

Also, to stay with Alternate Checksum semantics, if that option is
negotiated once, it should be kept for the remainder of the session -
even if PMTUD / BH decide to start sending only small (MTU<=1500)
packets at some point.

Further, I have spent some time looking for research on the
effectiveness of SACK - as this option would reduce the typical number
of SACK fields from a maximum of 3 down to 2. But from what I learned,
it seems that the number of SACK fields in an ACK have the property of
diminishing returns. You gain a lot from the 1st field; somewhat from
the 2nd, a bit from the 3rd, and having a 4th is surplus :). Besides, if
that option would only be valid for data-carrying segments, it could be
omitted if no data is to be carried - but still kept in "enabled" mode
instead of disabling.

Other than that, only a few nit-picks in wording and definitions (can be
addressed in a later version).

Richard Scheffenegger

> -----Original Message-----
> From: Joe Touch [] 
> Sent: Mittwoch, 9. Juni 2010 21:27
> To: Lars Eggert
> Cc:; Anantha Ramaiah (ananth)
> Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum
> Lars Eggert wrote:
> > Hi,
> > 
> > On 2010-6-9, at 21:07, Anantha Ramaiah (ananth) wrote:
> >> FWIW, there is a recent proposal which talks about enhancing TCP 
> >> checksums as well :-
> >>
> >> 
> >>
> >> The above proposal tries to leverage on the TCP alternate checksum 
> >> option.
> > 
> > I've skimmed through this draft when it first came out. I may be 
> > missing something, but why isn't TLS the right solution 
> here? Sure, it 
> > may be overkill, but it's readily available.
> Hi, Lars,
> I don't know if they say it in detail, but:
> TLS doesn't protect TCP against errors which result in bad 
> segments not being retransmitted at the TCP layer; TLS 
> secures, but does not retransmit lost info (it's not a 
> 'reliability' layer). Further, TLS would interpret a bad MAC 
> as an attack and would drop the connection, AFAICT (RFC 5246, 
> see "bad_record_mac").
> With large frames, TCP's checksum would allow false positives 
> (bad segments would get sent to TLS), and TLS would fail.
> Joe