Re: [tsvwg] UDP Options: on forcing the use of UDP CS=0 in connection with FRAG+LITE

Joe Touch <touch@strayalpha.com> Tue, 02 July 2019 02:05 UTC

Return-Path: <touch@strayalpha.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 E9F5312018F for <tsvwg@ietfa.amsl.com>; Mon, 1 Jul 2019 19:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level:
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HerPggk7orCg for <tsvwg@ietfa.amsl.com>; Mon, 1 Jul 2019 19:05:24 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA3612018B for <tsvwg@ietf.org>; Mon, 1 Jul 2019 19:05:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ODTqdShWnI51JS5Ob5nukaHzyucBiPWd/NC8LfdPAfc=; b=qBkARgwFFsT67aohyIsbQYlpd G0R7mTpYJUWXqCze9r2LMcrhjk/KSi3iJztrW3gI4EKLiCM4rTMzsPgTqxobrbuP8re59hKkbXkXe DfI4poXb5lgxTRx0TDiXbya2T1Qy53sr9MnzSjGVldOaiBNRyIutYdW+OvuPGFrWxfrkPdIa3+6K/ GYY9snyOAq7RYfVzSd202Dlh+Qcx+G+X4rT93IKI1VAh3VJy9Ct+LYMvKM1RvYxkNXWYD22SAZht/ 44ntA6Xy2rjbQgaX8dYLp/SJBVWX7LsxW/CMjPao9FqevBognaM1d0YKGV1s2iqN6ttuXVLXB8I3Z PT7XIGHwQ==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:60520 helo=[192.168.1.16]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1hi8AP-0007cS-M7; Mon, 01 Jul 2019 22:05:20 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@strayalpha.com>
X-Mailer: iPad Mail (16F203)
In-Reply-To: <CACL_3VF4XiRyS7Nc=eSE-ec+qGo6Xkc3syE+iGXxXPPN=eOpWw@mail.gmail.com>
Date: Mon, 01 Jul 2019 19:05:02 -0700
Cc: TSVWG <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <92422739-016A-4499-959B-D05955B5B7EF@strayalpha.com>
References: <CACL_3VHGtMz3htgfFLRGhjXm=qC7kOXQs+cchtamhh-giBnpLA@mail.gmail.com> <CALx6S35T9ApzMaoSVgHSJPpcpfXsbHHogoBbEjMPj6vH-kxYeA@mail.gmail.com> <CACL_3VE6kr33Vk5si5AxSZNmhqysZZGoy6HK37COUgwbvcRkdA@mail.gmail.com> <24692A9B-4AF1-4E32-A760-7D4908A61262@strayalpha.com> <CACL_3VExhAdFCu-kFLLO5DeRYUOFyJztUgJg-vQmnPoecvzeJg@mail.gmail.com> <6DB954BC-8D40-4347-A172-C00FED1AE4AF@strayalpha.com> <CACL_3VF38oR7emB0K6yrL7Npj4eb-Q-KFVu3=7L66syGaTrJtA@mail.gmail.com> <3E9DF9F3-EEBF-4C74-9633-A8E4ED1B5C01@strayalpha.com> <2977F9B1-73F3-4718-B65D-074EFED848AF@strayalpha.com> <CACL_3VHnVkSNXZoNzYBXX4jSGQuv1NL9UMf=j9YTXLmVb4Oq8Q@mail.gmail.com> <2720454F-8C4E-4C34-B326-C208ECD348A4@strayalpha.com> <CACL_3VF4XiRyS7Nc=eSE-ec+qGo6Xkc3syE+iGXxXPPN=eOpWw@mail.gmail.com>
To: "C. M. Heard" <heard@pobox.com>
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Eq02it66RKKgI-UkDB4fynMPfdQ>
Subject: Re: [tsvwg] UDP Options: on forcing the use of UDP CS=0 in connection with FRAG+LITE
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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, 02 Jul 2019 02:05:26 -0000


> On Jul 1, 2019, at 5:42 PM, C. M. Heard <heard@pobox.com> wrote:
> 
> The complaint now is that (under some implementation strategies, at least)
> FRAG+LITE and CS=0 may have a modest performance advantage ("matters a bit")

That bit can be significant, depending on how maids are laid out.

> compared to the new proposal with a fully compensated checksum. Is the
> purported performance advantage enough to outweigh the fact that CS=0
> suffers a significantly higher drop rate than a fully compensated checksum?

Again, wer also talking about per frag checksums vs. reassembled packet checksum. The latter is safer, due to potential reassembly errors.

The issue is what kind of errors should we catch? What should we be robust to?

IMO,  detecting address or port errors is very unlikely, given how NATS overwrite CSs.
Detecting reasssemblu errrors is very important, esp. at high data rates.
Tolerating implementation errors that are already a problem for others is very low on the list - those paths should be debugged and fixed, especially when tolerating them means either disabling reassembly checks or doing double the work.

IMO, we should design for the long term, not the transient.

But it’d be useful to hear from as many others as possible on these issues to determine where consensus is.

Joe