[TERNLI] Forwarding corrupt packets

Michael Welzl <michael.welzl@uibk.ac.at> Fri, 01 September 2006 08:00 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ3xF-0004Hp-7s; Fri, 01 Sep 2006 04:00:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ3xD-0004Hk-Mf for ternli@ietf.org; Fri, 01 Sep 2006 04:00:43 -0400
Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ3xC-0003Vq-D0 for ternli@ietf.org; Fri, 01 Sep 2006 04:00:43 -0400
Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id 961022DD292 for <ternli@ietf.org>; Fri, 1 Sep 2006 10:00:40 +0200 (CEST)
From: Michael Welzl <michael.welzl@uibk.ac.at>
To: ternli@ietf.org
Content-Type: text/plain
Organization: University of Innsbruck
Message-Id: <1157097623.3192.34.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 10:00:23 +0200
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Subject: [TERNLI] Forwarding corrupt packets
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

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.

These functions don't yield a benefit if a network
element drops all corrupt packets anyway. A CF
message could indicate that they would yield a
benefit. A CA message could increase the chance
of seeing a benefit.

What do you say?

Cheers,
Michael