IETF Logo Mail Archive

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

"C. M. Heard" <heard@pobox.com> Tue, 02 July 2019 00:42 UTC

Return-Path: <heard@pobox.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 D2ADF1201D9 for <tsvwg@ietfa.amsl.com>; Mon, 1 Jul 2019 17:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 n5jg2ALhr_Tn for <tsvwg@ietfa.amsl.com>; Mon, 1 Jul 2019 17:42:40 -0700 (PDT)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7FC1120370 for <tsvwg@ietf.org>; Mon, 1 Jul 2019 17:42:39 -0700 (PDT)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id DFBF1169E84 for <tsvwg@ietf.org>; Mon, 1 Jul 2019 20:42:38 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=sasl; bh=oCWMiN5tv8tG zigLzJ/f1J5bhrM=; b=akIwLopsft03nGM+GtLdL9D1Ya5ddB11mIKpQpXMPFRc PL3F+TqWoP4vBDQuAu42emyu1C7e76XZ9GPECrxJj+s9n0qdLKHHj8XaGL85uv9R EMqbU2HK/ZkgtxbnYu3e82UvWPOHCTQotWCqht4L+zAOJKIhLhrLyMSoNCHhWWM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; q=dns; s=sasl; b=pwcbED xnRAb4Je4CHhYSo3iPSG+2NVjHFCLUTFq/zcOmd3n/evBLMyafNJsgLJPGpF850L cnzcjKvL8luP0GchTPOL29gv0GH7jVcY6uiOJRBleGyfSjwYh/6782H2yeebV4Jf dt+J6PWsrjztvn3OkUUC8cDXA4dtA3//OsC5E=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id D7540169E83 for <tsvwg@ietf.org>; Mon, 1 Jul 2019 20:42:38 -0400 (EDT)
Received: from mail-io1-f44.google.com (unknown [209.85.166.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 5EACE169E80 for <tsvwg@ietf.org>; Mon, 1 Jul 2019 20:42:38 -0400 (EDT)
Received: by mail-io1-f44.google.com with SMTP id i10so19269844iol.13 for <tsvwg@ietf.org>; Mon, 01 Jul 2019 17:42:38 -0700 (PDT)
X-Gm-Message-State: APjAAAXr2j2Oz1YkuAneOb9IN1CqPsCsGyfAmuxYAxoLzIYpS/JAzpGY 6LHJE4TfCdBUtBnkMTKOa8RMc4OezmWO7KSb5C8=
X-Google-Smtp-Source: APXvYqy+tzzt9pBVknwb/rgUEml6JH5/eeVsrhgASQxQLIEQXpHaRgzZzcbSbS4goauMQAGG+qbcqJCNb5UJGyZTmlQ=
X-Received: by 2002:a6b:f910:: with SMTP id j16mr2395997iog.256.1562028157929; Mon, 01 Jul 2019 17:42:37 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <2720454F-8C4E-4C34-B326-C208ECD348A4@strayalpha.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Mon, 01 Jul 2019 17:42:26 -0700
X-Gmail-Original-Message-ID: <CACL_3VF4XiRyS7Nc=eSE-ec+qGo6Xkc3syE+iGXxXPPN=eOpWw@mail.gmail.com>
Message-ID: <CACL_3VF4XiRyS7Nc=eSE-ec+qGo6Xkc3syE+iGXxXPPN=eOpWw@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: "C. M. Heard" <heard@pobox.com>, TSVWG <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Pobox-Relay-ID: 4A9CDC2A-9C62-11E9-B1D6-72EEE64BB12D-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/RoskhhZt29kpyAZbrctbKgJRX9w>
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 00:42:54 -0000

On Mon, Jul 1, 2019 at 5:06 PM Joe Touch <touch@strayalpha.com> wrote:
> On Jul 1, 2019, at 3:42 PM, C. M. Heard <heard@pobox.com> wrote:
> > On Mon, Jul 1, 2019 at 12:27 PM Joe Touch  wrote:
...
> > > In the new proposal, there would be a potentially variable offset
> > > from the head of each mbuf in the chain.
> > >
> > > Those might have very different overheads…
> >
> > YMMV, but I find that argument to be unconvincing. Any not conspicuously
> > deficient mbuf design needs to be able to easily trim off variable length
> > headers from the start of a packet (e.g., by having a starting offset), or
> > else it would not be able to efficiently accommodate IP options/extension
> > headers, TCP options, tunnel encapsulation headers, and so on.
> >
> > Mike
>
> That correlates with what I’ve seen in performance exactly though.
>
> The common case is fast; other cases not so much. Even the mbuf start
> offset from malloc start matters a bit (per measurements I did with MD5
> in memory).

The original complaint was:

> The solution below doesn't appear to avoid copying/moving large amounts
> of data.
>
> At a minimum, can you address #2? If we can do this without moving
> around a lot of data, it might be viable.

I believe I've addressed that point. There are implementation strategies
that avoid copying/moving large amounts of data.

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")
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?

Mike

v2.23.0 | Report a Bug | By Email