Re: [tsvwg] RDMA Support by UDP FRAG Option

Joseph Touch <touch@strayalpha.com> Mon, 14 June 2021 00:01 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 B24DA3A15CD for <tsvwg@ietfa.amsl.com>; Sun, 13 Jun 2021 17:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 1xHnkEzX9ArA for <tsvwg@ietfa.amsl.com>; Sun, 13 Jun 2021 17:01:31 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 AF0493A15C6 for <tsvwg@ietf.org>; Sun, 13 Jun 2021 17:01:31 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding: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=JpgbHBDpBkJsx5EaLCzNacwJFbFxRNt4Mk8im+uUkiM=; b=ZogLkmEtbxeCM+4jI/r7ZtYpym fEOj3jopcT7mIUVC6jf3/amhNDIY5IoJuJqrEwD0rz1CxC4kh69yCA8a+afsMJggyFPe0l0JlSu6q 3eXn9I5GA9m+balG9nMLJaSzAk785HBkdQ9PGdgN0HP9hXGlHVJNewdOSBlA+G/6Z1rTLbQ7bOqUa DmN25Z3dmnbNmkQzW9qgqfIdk2dg0Qzck7gM9ALvHcerwiOFwbZqcLLZat2woKbNvqDSy/Gs1CxRG 3lmJmC7xWwneewjqfkBQ6YxEVj6FRK7qBUa7aMwPQfMDumJ83yEJ7ZXZNhK1/7MdYP84qNL5ODK5X N4E6Ac4Q==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:54044 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1lsa2g-000aQI-D0; Sun, 13 Jun 2021 20:01:30 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_E88B0501-74F6-4254-AE9B-5DB3C88F4A38"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <CACL_3VHTfxWaBj7TFEmBXBqovrrAj7XuFEZFUag_iBHr3Hx09g@mail.gmail.com>
Date: Sun, 13 Jun 2021 17:01:24 -0700
Cc: TSVWG <tsvwg@ietf.org>
Message-Id: <0EBFC9B0-591A-4860-B327-6E617B83F4D1@strayalpha.com>
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>
To: "C. M. Heard" <heard@pobox.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
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/lK5OYeUV-pygKOT39objxZiWMV8>
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: Mon, 14 Jun 2021 00:01:37 -0000

> On Jun 13, 2021, at 4:37 PM, C. M. Heard <heard@pobox.com> wrote:
> 
> On Thu, Jun 10, 2021 at 9:43 PM Joseph Touch wrote:
> - do we want/need RDMA support?
>         if not, we ditch the frag length in non-terminal frags
> 
> 
> I am going to reveal my ignorance by asking what is meant by RDMA (Remote Direct Memory Access). But I'm fine with that as long as we end up with an unambiguous problem statement.

I may have conflated two issues.

1. Whether UDP supports zero-copy in the presence of reassembly.
2. Whether FRAG needs a frag length per se

I think #2 might strictly depend only on whether non-terminal fragments can have post-fragment options. There doesn’t appear to be reason for doing this; options that apply to the whole reassembled payload would occur after the last fragment and any options that apply to individual fragments appear before FRAG in each non-terminal fragment.

#1 determines whether the data occurs in normal order or whether data in each fragment (including the final one) are moved around. Here’s what that looks like:

- in normal order, each fragment’s data just occurs in-order in each fragment, e.g.,:

	abcde	fghijkl	mnopqrst

- to support zero-copy, we previously had a technique that swapped bytes. Showing this for a full option is a bit complex; a simple version here would assume that each fragment had 3 bytes of options from the beginning of the option space to the start of the FRAG data (it’s always longer, but let’s make it 3 just to show it more simply). In that case we do the following:

	123deabc	123ijklfgh	123parstmno

The idea is that the data can be placed directly in memory, with the last 3 bytes overwriting the first three. By moving only the space covered by the options, direct data placement can be used:

	123de	- write up to the last 3 bytes
	a23de	- overwrite the last 3 bytes starting at the beginning (next 2 lines too)
	ab3de
	abcde

So this doesn’t affect the option format, but does affect whether FRAG data is in-place or wraps-around to support zero-copy.

Joe