Re: [tsvwg] RDMA Support by UDP FRAG Option

Tom Herbert <tom@herbertland.com> Fri, 18 June 2021 17:21 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 3A45C3A1B1C for <tsvwg@ietfa.amsl.com>; Fri, 18 Jun 2021 10:21:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BpVzeBdgma9j for <tsvwg@ietfa.amsl.com>; Fri, 18 Jun 2021 10:21:34 -0700 (PDT)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 32B803A1B19 for <tsvwg@ietf.org>; Fri, 18 Jun 2021 10:21:34 -0700 (PDT)
Received: by mail-ej1-x630.google.com with SMTP id my49so16943716ejc.7 for <tsvwg@ietf.org>; Fri, 18 Jun 2021 10:21:33 -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=beM4yVAd44ZsHbunCfozOjGltbhoHyVvM/0dvRd7flk=; b=J9Tj4Hnjc3XAZGelzelE5jRgVvQodHErfqyCJwn2ow2VBRScMjjbJ8ChsUIjmwSsqU 3avpQjm6lVpRQBKBfLf1Q+Ilz05B5hx//R2th+e3WK2kEj4s/4tSjRqpKHB7HN9K3zoD CvNhMwrzVcrcDaSSHczF9yc9bPWJfni3vHvjQAe0i2tuTV0J2c98F+p/CjmBtSrpli25 dJom4kO6bQRZrw8LEN6r+fOkW1DkdFxf6SK9yI9XYF7PYkAwwTmeeuDd4KiQL2g99h6D f+Z3+2wh4Br7DNTJvJvLkliZfVegdlTF57LrkrM86OYmimfRhGK+VaEqsXOI8lv8OoS2 IJ0A==
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=beM4yVAd44ZsHbunCfozOjGltbhoHyVvM/0dvRd7flk=; b=fDv1AfaauxwfoUCmUks+igEmFczBoisKtehi5NBnTnXX5ELLjm86Q85zq1zlMdZgQY UohwjOg1ZLq44PQL37KTvj+FdCprUPRSTPFNZrOAeWRt6UR3DwIT/ZzfC+e0pu+Sn/Xc XyEpGv2qJVumE3y9emJeC2QCBr8lCEMGnX/2eyAMx1aUywChC/70b2J6VbUi4vgDPzUZ r17sPf7xnLdciIUpPkGkjPhTgOJilud7gfd9LOkgYt41ejchqWdsarbvPxPZrn7AD9XO qI3dIcTKS/QGlyCas7v3T6NtWHLpACBq6szcRDjPfD8tHom9QnpqsxQidltAhOPUbGJt 4LYw==
X-Gm-Message-State: AOAM530ITgDNqPt0eBmkt4Yh2dIHVVKVlUK67z9g1ZcDyUHWpIt+1/zc u9SeBfMBm514wFYRDp8SSxcvHLg6mYcJQr0P0+SkNg==
X-Google-Smtp-Source: ABdhPJz6QSaTbZgxGRhdo3toW738msSMNU/Tm4cjUF8al9D0Ww42UhG9oV82jWeUN6U2XfUYfJQaBMpcovH2MWZ2ihg=
X-Received: by 2002:a17:907:3ea1:: with SMTP id hs33mr11939517ejc.259.1624036891755; Fri, 18 Jun 2021 10:21:31 -0700 (PDT)
MIME-Version: 1.0
References: <CACL_3VEyLdQZ-3hvzXxyA8ehtWs2hXESZ2OqyAx+BeSg85+-cA@mail.gmail.com> <CACL_3VFE4TjKvmkfZjvNpWo6vVfKjz5w85=Q+yqnYZKcwbYLmQ@mail.gmail.com> <63FFC34B-2179-47F1-B325-21CAC3D1543A@strayalpha.com> <CACL_3VHTfxWaBj7TFEmBXBqovrrAj7XuFEZFUag_iBHr3Hx09g@mail.gmail.com> <0EBFC9B0-591A-4860-B327-6E617B83F4D1@strayalpha.com> <CALx6S34pT81TbfQDk2vKF8wBrXL312As79K=rEzUQ3Lmg7UvpA@mail.gmail.com> <7C51D926-9DBB-41F5-93B2-10F716F672B1@strayalpha.com> <CALx6S37uN8TsXQZ3cv5jmxwxSyBRjK=-GQ_MsWxPWSs21XoGHw@mail.gmail.com> <CACL_3VEx7+VnLz7OLdXyhZU41e+-oBz3dc8JdMV_7pLMfic6=w@mail.gmail.com> <fcc8762f-c042-7999-d2e4-f28384950a19@erg.abdn.ac.uk> <CALx6S36sWGcZmFpAhF4DfOMyf6Z0w5F9bemNfeM1yWV-r0M+BA@mail.gmail.com> <8af3abf9-943f-13c1-e239-5efca27cf68c@erg.abdn.ac.uk> <5D0A926D-AB95-48F7-9D7B-8862FE290761@strayalpha.com>
In-Reply-To: <5D0A926D-AB95-48F7-9D7B-8862FE290761@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 18 Jun 2021 10:21:20 -0700
Message-ID: <CALx6S364dzBYRxWYTVHOHwdTzmHRN_jeZx=_ASk9EYsqrcK_2A@mail.gmail.com>
To: Joseph Touch <touch@strayalpha.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, 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/ei4V02_A_EflabBEVH0H6WzMTxE>
Subject: Re: [tsvwg] RDMA Support by UDP FRAG Option
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: Fri, 18 Jun 2021 17:21:39 -0000

On Fri, Jun 18, 2021 at 8:11 AM Joseph Touch <touch@strayalpha.com> wrote:
>
>
>
> On Jun 18, 2021, at 2:36 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>
> Please look at draft-herbert-udp-space-hdr-01 for my proposal as to
> how the UDP surplus space should be formatted. If there is interest, I
> could update draft to include considerations for UDP options
> fragmentation and reassembly offload as well as header/data split
> which is needed for zero-copy receive (i.e. packet headers are DMA'ed
> into one set of buffers to be processed by the stack, payload is
> DMA'ed to another set of buffers to be processed by the application).
>
> Tom
>
> ...
> I think it would be good for the WG to focus on how to finish draft-ietf-tsvwg-udp-options, but I do seem some opportunities to use some of these ideas for making the fragment header - because that also places all data in the "option”.
>
>
> The difference between this draft and where we are (and have been before that draft):
> 1. it adds an option area length field
> 2. it requires length on all packets with options
> 3. It requires OCS on all packets with options
>
> (1) repeats TCP's mistake of limiting the options space (see draft-ietf-tcpm-tcp-edo)

Allowing an unlimited size and number of options repeats the same
mistake in RFC8200, the only use case for unlimited options is Denial
of Service attack.

> (1) undermines the use of FRAGs where fragments are larger than 1K (not to mention being smaller for per-frag options)

I don't know what that means.

> (2) adds a field that is not needed in packets that are not FRAGs

Not sure to which fields you are referring.

> (3) requires checks that are redundant on packets already protected, undermining the flexibility that continues to be available via UDP CS=0
>
UDP checksum is required to be non-zero for IPv6, which means this
point is being rendered moot as IPv6 deployment continues. Besides
that, as I've mentioned several times now, if the checksum is in a TLV
then the checksum cannot protect against it's type field being
corrupted and also the checksum serves to validate that the surplus
space is indeed UDP options and not some random bits some hosts
decided to put in there.

> I don’t understand “places all the data in the ‘option’”. It doesn’t appear to do that unless used with FRAG, which we already do in the WG doc.
>
> Joe