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 > >
- [tsvwg] A review of draft-ietf-tsvwg-udp-options-… C. M. Heard
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… mohamed.boucadair
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Gorry Fairhurst
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Paul Vixie
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Gorry Fairhurst
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Gorry Fairhurst
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Gorry Fairhurst
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joe Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joe Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joe Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Gorry Fairhurst
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Paul Vixie
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Joseph Touch
- Re: [tsvwg] A review of draft-ietf-tsvwg-udp-opti… Paul Vixie
- [tsvwg] UDP Options - per segment or per datagram C. M. Heard
- Re: [tsvwg] UDP Options - per segment or per data… Joseph Touch
- Re: [tsvwg] UDP TIME Option - per segment or per … C. M. Heard
- Re: [tsvwg] UDP REQ/RES Options - per segment or … C. M. Heard
- Re: [tsvwg] UDP TIME Option - per segment or per … Joseph Touch
- Re: [tsvwg] UDP REQ/RES Options - per segment or … Joseph Touch