Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12

Tom Herbert <tom@herbertland.com> Tue, 15 June 2021 16:59 UTC

Return-Path: <tom@herbertland.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 12FA43A369F for <tsvwg@ietfa.amsl.com>; Tue, 15 Jun 2021 09:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 oL3vQVG-F3zx for <tsvwg@ietfa.amsl.com>; Tue, 15 Jun 2021 09:59:10 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F433A369B for <tsvwg@ietf.org>; Tue, 15 Jun 2021 09:59:09 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id og14so23741262ejc.5 for <tsvwg@ietf.org>; Tue, 15 Jun 2021 09:59:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2fgZTk6rZcGESYldsfQ7FYwDM5o0Op6xH/SVxv56t9E=; b=cOcTTCI5sbSBkwZiUQys2tAiDxSHqbsSYFXqW3r0bKzslGCCUzlgA1fqIopcMUg+gj GybBMxmXkbNFPLUvNlcfop3CMc90ydma5BLKyzZU8YQH5ibXD+lCTkFpyUPXgWbDGMcg bn/NQIG49r4+1NW4L8ErPFeEVJTTJFYC43rdGoaxqliBT4HIt0IJpvd+ZKSHeBUuENjP f1UBNZvatOh7Y2IRv5VJmxcEJxqg0iGVujhMDsKQqxQ/wo+zlsBYaHttJ/5equlyak+3 u8M3TvLtZ9UOniJD4QL+xdKRXuaeAJC1sDFB/FE/5jq34jQmBe53S/HOqyi/VlsnMQq+ XEJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2fgZTk6rZcGESYldsfQ7FYwDM5o0Op6xH/SVxv56t9E=; b=OP4vEQTMtjLUIMXWzmv6Yxh7ZUlhZYQu6IJ0Q1AQgJe9+EGRgrE4S7hDWn4VAt+KEy d3XQiQga+iFkUFtVEgBGvdl1UAs09vUUmEOFpkK0tVKdTbp2jtYD3fbnoz6m9f6F+87R ZfsNyiEtiBFVXJ8AsnTHwqPEO4xJvdMC9NjI4AF0wJ7PPuPWiDo2kUJNI0l5LJMqWjMU zaPqtfEaB6WqC3UjvpA8BcF0wwi0xV8gKIixvwYuDgRRNn3LrDQ3RPjStK3Z1Cu78pTe RSj9fuS8TwcnQ9Qgzw4amKCYESRsXmWahJCaBOqNdZ08SE/OQk6jCaERaAlsEZTWSg4I a5ew==
X-Gm-Message-State: AOAM5320ghhHqjs12ycvWtMwXHEKprFAFGCPt12JdGzTEdAt19/G4eNU CyG8MnjMKAwSsFjb175bJx89ue6vOViICHlm8HcvjA==
X-Google-Smtp-Source: ABdhPJytCRwnYhslbyLwAOCFdAECDUGtV1aBiWzc2Ui6E3oGhCrD7F0YXnFghyDshl5z/QSDS7ORHMtBW8XX/COFEC4=
X-Received: by 2002:a17:906:8056:: with SMTP id x22mr552150ejw.298.1623776347227; Tue, 15 Jun 2021 09:59:07 -0700 (PDT)
MIME-Version: 1.0
References: <CACL_3VGb_9P5SfPGRJtf1ZBvEhgywc2ZEGr-qbgNOMXV20rFeA@mail.gmail.com> <CACL_3VHyoRr5ju8203DiLTUo-658DCj7ud+1dQE2o0hUPVhF0A@mail.gmail.com> <7D766992-AEEB-434F-BB1D-3817EE07DE61@strayalpha.com> <1BBDBD80-3A53-4700-A79F-9A3AE4876F2B@strayalpha.com> <CACL_3VEXCT-sSNhtncVK26DPQefDLJhqEijgDke4Q7DmhRrpTQ@mail.gmail.com> <67E79ED1-14DE-4127-83AF-D17E8C72F362@strayalpha.com> <CACL_3VGOVTjzOBBCS4b+4X_cTFX6T=gYO4_htvr2idzQGUP+oQ@mail.gmail.com> <C67EE01E-A41F-4BF5-BE1E-33E9F01D0B72@strayalpha.com> <CALx6S360gGWGicLAj1QJheHRyqvbkWx3KE7VrTyUSJ83cqkffA@mail.gmail.com> <B355DEDE-561E-4910-87D5-5C5F0D984BE6@strayalpha.com>
In-Reply-To: <B355DEDE-561E-4910-87D5-5C5F0D984BE6@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 15 Jun 2021 09:58:55 -0700
Message-ID: <CALx6S345AtooNGPiV4-TxZPURVcsJ27pMMQ9dYL09V7aHcVCNg@mail.gmail.com>
To: Joseph 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
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bSMAIM1uKTgFHFfHGU6NU36qEn8>
Subject: Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12
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, 15 Jun 2021 16:59:16 -0000

On Tue, Jun 15, 2021 at 9:32 AM Joseph Touch <touch@strayalpha.com> wrote:
>
> Hi, Tom,
>
> There’s no debating that zero-copy networking is challenging - moreso when dealing with an OS that is “different for the sake of being different” (Linux, largely for copyright reasons).
>
> To your points:
> >
> > IMO, if you want to make UDP options seamlessly integrate and get
> > ubiquitous support of UDP options in the OS and hardware (leverage
> > checksum offload, zero copy, hardware fragmentation/reassembly,
> > offload authentication/crypto, header/data split, etc.),
>
> Seamlessness is not a goal; we want only to not get in the way.
>
> > the best
> > direction would be to make UDP with options look like TCP as much as
> > possible at least with regards to packet format.
>
> QUIC doesn’t and UDP can’t.
>
> > i.e. use the same
> > option format, have a header length field, use headers instead of
> > trailers, etc.
>
> We do use the same basic format (TLV). We do have a length field where it would help zero-copy (FRAG), but not elsewhere.
>
> And we do use headers for FRAG but not elsewhere.
>
> Again, this is UDP. We can’t redefine it in a way that lets incorrect data be received at legacy endpoints.
>
> And - this is key - we also do not want to make the mistakes TCP made, even if that makes UDP options require its own code. E.g., we don’t want to limit UDP header length to 40 bytes.
>
> So the best we can do (and are doing) is *enable* new code for UDP zero-copy. For FRAG, that means putting the length where it can be found without TLV-chain parsing. But a true UDP zero-copy stack that supports non-frag messages would need to know how to deal with trailers rather than headers.
>
> And, FWIW, trailers are just as easy if not *EASIER* for zero-copy to handle; they just DMA the user data first then the UDP options.

Joe,

I am dubious of that statement. You'll have to show running code and
performance results. Software stacks and hardware have long been
designed around the fact that networking protocols are in headers; UDP
options is an outlier in that regard. While it is certainly possible
to make a functional stack to handle trailers, it is going to be hard
if not impossible to leverage many implementation optimizations and
techniques we've done over the years.

Tom

>
> Joe
>
>