IETF Logo Mail Archive

Re: [tsvwg] draft-tuexen-tsvwg-sctp-zero-checksum-02 adoption

Nils Ohlmeier <nils.ohlmeier@8x8.com> Thu, 13 April 2023 21:10 UTC

Return-Path: <nils.ohlmeier@8x8.com>
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 53C24C152A16 for <tsvwg@ietfa.amsl.com>; Thu, 13 Apr 2023 14:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=8x8.com
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 yks2bHgJ6_hK for <tsvwg@ietfa.amsl.com>; Thu, 13 Apr 2023 14:10:17 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E801BC152A13 for <tsvwg@ietf.org>; Thu, 13 Apr 2023 14:10:17 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-329326b4f10so1741935ab.2 for <tsvwg@ietf.org>; Thu, 13 Apr 2023 14:10:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8x8.com; s=googlemail; t=1681420217; x=1684012217; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=eVFub2+erSC7TkWFvFhnwRz7438NGGbuitHylI1cOMY=; b=b2yITCaBmaveOWwKBbsCRP3LhOgrhCC/dk0xTGAYLGpH3PhQPSpSWtG5F3uoZgG3eg hyxpWRl/Mh81U4azReEvnQa2WVGFRIhbBEZkMUHpVCCW2vt4LXLbpN6BjHvP4cFQaBWn DxYDlBx9TXgyj53X4B1DXQD2admSxkvVnqOt4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681420217; x=1684012217; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eVFub2+erSC7TkWFvFhnwRz7438NGGbuitHylI1cOMY=; b=Aj/RRsorAL1DLg5snowGMVN009GttHaaxrldke5Ipy9rt7H2q5j0nVOCIpFcVNEtCT GGss3N4VD0HlgxtuZavP2FMVn7hxZhURqcuGsQ50+g5jCZwBtpCo53QEz0hz9RFYPbCN oYFLQuJAIFXI7cq0xEPd1gk4d5oyEHdAthbUI18NiXv/0IIE6yRbIJNOwjHO5U5Evsvl Cnt4lzjTziewmeXY1/jdAcvNQX3EE1OnEHV8d6ZuRN4uDR1IBsn9A35wDSh1BYjgGF6k 6KqtubWVQdf4Zkio7bQdTS+1HZJ2kL25v1Vjewr8P9KpI2yaYQGkuDo/I20hgmwLdRTc 1VHg==
X-Gm-Message-State: AAQBX9dfo6LO/8kd4y5dNr5HwDHISKCA40T5l6AyS4hsiAq4ohX/ajmc on4isHdGkITyx93pAqEy8yYy4mg3aisTQUmB9gQ=
X-Google-Smtp-Source: AKy350ZtUbAapfeWSbZ1gTJkOawVn+rAvdk1JhshmEsp6LafoZvRJNwy5m60VCvYSbckRJDc+bMZVw==
X-Received: by 2002:a92:d987:0:b0:325:fe9f:b89e with SMTP id r7-20020a92d987000000b00325fe9fb89emr2426580iln.30.1681420216828; Thu, 13 Apr 2023 14:10:16 -0700 (PDT)
Received: from smtpclient.apple (75-166-40-160.hlrn.qwest.net. [75.166.40.160]) by smtp.gmail.com with ESMTPSA id q8-20020a02b048000000b0040bb7c83da4sm714200jah.136.2023.04.13.14.10.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Apr 2023 14:10:16 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Nils Ohlmeier <nils.ohlmeier@8x8.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 13 Apr 2023 15:10:04 -0600
Message-Id: <011B379C-D6A4-458C-AB6F-668659CB1D6E@8x8.com>
References: <E521C310-4D4D-4851-A668-BDAE119D6C37@fh-muenster.de>
Cc: tsvwg@ietf.org
In-Reply-To: <E521C310-4D4D-4851-A668-BDAE119D6C37@fh-muenster.de>
To: tuexen@fh-muenster.de
X-Mailer: iPhone Mail (20E252)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/xDo5tK74K0o8CkDlZRPmGjhTsTw>
Subject: Re: [tsvwg] draft-tuexen-tsvwg-sctp-zero-checksum-02 adoption
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: Thu, 13 Apr 2023 21:10:23 -0000


> Am 4/13/23 um 14:38 schrieb tuexen@fh-muenster.de:
> 
> 
>> 
>>> On 13. Apr 2023, at 21:30, Nils Ohlmeier <nils.ohlmeier@8x8.com> wrote:
>>> 
>>> 
>>> 
>>>> On Apr 12, 2023, at 06:20, tuexen@fh-muenster.de wrote:
>>> 
>>>> On 11. Apr 2023, at 19:15, Nils Ohlmeier <nils.ohlmeier@8x8.com> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> I’m supporting adoption of draft draft-tuexen-tsvwg-sctp-zero-checksum-02, because it is going to be useful for all WebRTC endpoints out there to have the option to skip the checksum step.
>>>> 
>>>> I also reviewed the draft. The only concern I found is this sentence:
>>>> 
>>>> "Since the lower layer of SCTP can not be IPv4 or IPv6 as specified in [RFC9260] or UDP as specified in [RFC6951], no problems with middle boxes expecting correct CRC32c checksums in the SCTP packets are expected.”
>>>> 
>>>> Which confuses me, because it sounds to me like this is trying to say that SCTP over IPv4 or IPv6 can not be done. Which obviously doesn’t make any sense. But I honestly fail to parse what this sentence is suppose to tell me (besides no problems with middle boxes is expected).
>>> Would using
>>> 
>>> One example of such a lower layer is the use of SCTP over DTLS as
>>> described in [RFC8261] (as used in the WebRTC context). Counter
>>> examples include:
>>> 
>>> * SCTP over IPv4 or IPv6 as specified in [RFC9260].
>>> 
>>> * SCTP over UDP as specified in [RFC6951].
>>> 
>>> * The use of SCTP Authentication as specified in [RFC4895].
>>> 
>>> Therefore using an incorrect zero checksum will not result in
>>> problems with middle boxes expecting correct CRC32c checksums in SCTP
>>> packets.
>>> 
>>> be clearer?
>> 
>> Yes I think that helps.
>> I think if you expand the last sentence in our proposal to something like:
>> 
>> Therefore using an incorrect zero checksum when using SCTP over DTLS will not result in
>> problems with the middle boxes expecting correct CRC32c checksums in SCTP packets.
>> 
>> Should remove any remaining ambiguity.
> But we list DTLS over SCTP as an example. Some what about:
> 
> Therefore using an incorrect zero checksum, in particular when using SCTP over DTLS,
> will not result in problems with the middle boxes expecting correct CRC32c checksums
> in SCTP packets.
> 
> OK?

Yes that sounds a lot clear to me, compared to current wording in the draft. 

Thanks
  Nils

v2.31.3 | Report a Bug | By Email | System Status