Re: [tsvwg] Adoption call fordraft-tuexen-tsvwg-sctp-zero-checksum - to conclude 25th April 2023
Michael Tuexen <michael.tuexen@lurchi.franken.de> Tue, 11 April 2023 09:59 UTC
Return-Path: <michael.tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FF6C14CE40 for <tsvwg@ietfa.amsl.com>; Tue, 11 Apr 2023 02:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 072vqIgPfuFB for <tsvwg@ietfa.amsl.com>; Tue, 11 Apr 2023 02:59:09 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B452AC14CE42 for <tsvwg@ietf.org>; Tue, 11 Apr 2023 02:59:09 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:ed58:432e:c240:748]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 7010474C7607B; Tue, 11 Apr 2023 11:59:03 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <78604000-0F5E-4E09-8CC3-0BEB06ABC5CF@ifi.uio.no>
Date: Tue, 11 Apr 2023 11:59:02 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <31FA5928-3823-40DF-8116-69DF747AA4C4@lurchi.franken.de>
References: <e9c1cb50-64cb-3d13-2c57-ffb15a101059@erg.abdn.ac.uk> <78604000-0F5E-4E09-8CC3-0BEB06ABC5CF@ifi.uio.no>
To: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/DZgsWH6YU1zlyDXZS1Qd8rXy5RM>
Subject: Re: [tsvwg] Adoption call fordraft-tuexen-tsvwg-sctp-zero-checksum - to conclude 25th April 2023
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Apr 2023 09:59:11 -0000
> On 11. Apr 2023, at 11:28, Michael Welzl <michawe@ifi.uio.no> wrote: > > Hi, > > I have now read this document and support progressing it: it looks genuinely useful to me. > > I was just wondering if the receiver-side behavior should include a statement about the possibility of simply ignoring the checksum? The way section 4.3 is written, it doesn’t exclude this, but I guess that the SCTP base RFCs prescribe that the checksum *must* be calculated and checked. So, why not relax this? With or without negotiation of "Zero Checksum Acceptable”, a receiver could probably always locally decide: “I see that this is going over DTLS, so I will ignore the SCTP checksum." > > A nit - though, not being a native speaker, I don’t even know if this really is a mistake: "This is in particular important for computational limited end points using SCTP encapsulated in DTLS.” > I believe that “computationally” should be used here instead of “computational". Fixed. Thanks for notifying. Best regards Michael > > Cheers, > Michael > > >> On Apr 11, 2023, at 10:31 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote: >> >> This email now marks the start of a WG adoption call for: Zero Checksum for the Stream Control Transmission Protocol (draft-tuexen-tsvwg-sctp-zero-checksum-02). This draft was discussed at the recent TSVWG meeting. >> >> Abstract: >> >> The Stream Control Transmission Protocol (SCTP) uses a 32-bit >> checksum in the common header of each packet to provide some level of >> data integrity. When the lower layer used by SCTP provides already >> the same or a higher level of data integrity, computing this checksum >> does not provide any additional protection, but does require >> computing resources. This document provides a simple extension to >> SCTP allowing to save these computing resources by using the constant >> 0 as the checksum in a backwards compatible way. >> >> Please read this draft, and send any comments/concerns to either the TSVWG or to the chairs <tsvwg-chairs@ietf.org>. Notes of support to progress this work, and volunteers to review the drafts will also be very welcome at this stage. >> >> All participants, should disclose any relevant intellectual property rights (IPR) under [RFC8179]. >> >> >> Best wishes, >> Gorry and Marten >> (tsvwg co-chairs) >> >> >
- [tsvwg] Adoption call fordraft-tuexen-tsvwg-sctp-… Gorry Fairhurst
- Re: [tsvwg] Adoption call fordraft-tuexen-tsvwg-s… Michael Tuexen
- Re: [tsvwg] Adoption call fordraft-tuexen-tsvwg-s… Michael Welzl
- Re: [tsvwg] Adoption call fordraft-tuexen-tsvwg-s… Michael Tuexen
- Re: [tsvwg] Adoption call fordraft-tuexen-tsvwg-s… Michael Tuexen
- Re: [tsvwg] Adoption call fordraft-tuexen-tsvwg-s… Michael Welzl
- Re: [tsvwg] Adoption call fordraft-tuexen-tsvwg-s… Michael Tuexen
- Re: [tsvwg] Adoption call fordraft-tuexen-tsvwg-s… C. M. Heard