Re: [TERNLI] Forwarding corrupt packets

Michael Welzl <> Fri, 01 September 2006 14:30 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GJA2s-0007lW-8z; Fri, 01 Sep 2006 10:30:58 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GJA2r-0007lJ-3M for; Fri, 01 Sep 2006 10:30:57 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GJA2p-0008CN-Eh for; Fri, 01 Sep 2006 10:30:56 -0400
Received: from ( []) by (Postfix) with ESMTP id 74D192DD292; Fri, 1 Sep 2006 16:30:54 +0200 (CEST)
Subject: Re: [TERNLI] Forwarding corrupt packets
From: Michael Welzl <>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <>
References: <> <>
Content-Type: text/plain
Organization: University of Innsbruck
Message-Id: <>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4)
Date: 01 Sep 2006 16:30:36 +0200
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Fri, 2006-09-01 at 16:06, Joe Touch wrote:
> Michael Welzl wrote:
> > Hi all,
> > 
> > Here's an idea for a potentially useful message that
> > could be exchanged between end systems and the inner
> > network:
> > 
> >>From transport end point to network:
> > "Corruption Acceptable (CA)" (meaning that it would be
> > preferrable to forward packets that are corrupt rather
> > than drop them)
> > 
> >>From network to transport end point: "Corruption
> > Forwarding supported (CF)"
> > 
> > Purpose: help the end system decide whether to use
> > UDP-Lite, or partial checksums in DCCP, or the
> > Data Checksum option in DCCP.
> Why does the _network_ need to know about these? The network doesn't
> check (or shouldn't check) transport checksums.
> The only reason the network would think a packet is corrupt:
> 1) bad net checksum (e.g., IPv4)

I agree that, if this checksum is known to be corrupt, the
packet should be dropped.

> 2) bad link checksum

which normally covers everything, e.g. in 802.11 nets AFAIK.
So that's the one that I'm concerned about.

> In both cases, the destination address is not trusted anymore, so you're
> potentially sending the corrupt packet to the wrong _place_. If you
> can't send it the right place, then why are you sending it?

i remember you saying some time ago that sending it to the
wrong destination isn't a big problem for the network, and
therefore the lack of a checksum in ipv6 isn't a big issue.

chances are that it would reach the right place, so where's
the problem?

> This isn't a new issue; it's one of the reasons for the partial checksum
> in lite/DCCP - but also why it should be only over the _data_ portion.

This is at least the only portion the end node is concerned
with, so yep - the precise message from the sender would have
to be "corrupt data portion is okay" (no matter how exactly
the element in the network would handle this message - e.g. by
looking at the data portion, which I consider ugly design,
or by always forwarding corrupt data when at least the IP
checksum is ok, which I'd prefer).

> In those conditions, you might end up with one e2e-pair causing a
> separate endpoint to throttle-back thinking its packets are corrupted.
> That cross-contamination seems like a sufficient reason not to do this.

I don't get this - could you go into more details?

> IMO, partial transport checksums are useful only where the header
> checksum is still valid; otherwise, there's no point in interpreting the
> header at all.

As I say above, that's an implementation detail in my opinion.
We can make recommendations in either direction - right now,
I'm just suggesting this explicit message between the transport
endpoints and the network.