Re: [TERNLI] Forwarding corrupt packets
Michael Welzl <michael.welzl@uibk.ac.at> Fri, 01 September 2006 14:30 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJA2s-0007lW-8z; Fri, 01 Sep 2006 10:30:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJA2r-0007lJ-3M for ternli@ietf.org; Fri, 01 Sep 2006 10:30:57 -0400
Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJA2p-0008CN-Eh for ternli@ietf.org; Fri, 01 Sep 2006 10:30:56 -0400
Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id 74D192DD292; Fri, 1 Sep 2006 16:30:54 +0200 (CEST)
Subject: Re: [TERNLI] Forwarding corrupt packets
From: Michael Welzl <michael.welzl@uibk.ac.at>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <44F83E74.1080603@isi.edu>
References: <1157097623.3192.34.camel@lap10-c703.uibk.ac.at> <44F83E74.1080603@isi.edu>
Content-Type: text/plain
Organization: University of Innsbruck
Message-Id: <1157121036.3192.148.camel@lap10-c703.uibk.ac.at>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4)
Date: Fri, 01 Sep 2006 16:30:36 +0200
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: ternli@ietf.org
X-BeenThere: ternli@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <ternli.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ternli>
List-Post: <mailto:ternli@ietf.org>
List-Help: <mailto:ternli-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=subscribe>
Errors-To: ternli-bounces@ietf.org
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. Cheers, Michael
- [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets alessandro salvatori
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Joe Touch
- Re: [TERNLI] Forwarding corrupt packets Michael Tuexen
- Re: [TERNLI] Forwarding corrupt packets Michael Welzl
- Re: [TERNLI] Forwarding corrupt packets Randall Stewart
- Re: [TERNLI] Forwarding corrupt packets Randall Stewart
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst
- Re: [TERNLI] Forwarding corrupt packets Gorry Fairhurst