Re: [tsvwg] RDMA Support by UDP FRAG Option

Joseph Touch <touch@strayalpha.com> Mon, 21 June 2021 22:43 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 590123A1CDC for <tsvwg@ietfa.amsl.com>; Mon, 21 Jun 2021 15:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.455
X-Spam-Level:
X-Spam-Status: No, score=0.455 tagged_above=-999 required=5 tests=[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.652, 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 n-p1Fq9qToy7 for <tsvwg@ietfa.amsl.com>; Mon, 21 Jun 2021 15:43:34 -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 CED983A1CD9 for <tsvwg@ietf.org>; Mon, 21 Jun 2021 15:43:34 -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=WHSQeEZrMjHMGcxXHrW4wl2WIt3foxaPpmiw7LNCCP4=; b=35hx/7AgbmjxNsYfuFIMKsfBAq SSHrL+6tkBcSEfrRL6ChF9+k56gth2a3fp/vHuDrE4Tnf4uaSkKmdz0u29OZzalY1lN2OkV5DtMf1 VEFS14otMmG8LMv3z58SWecsDAUV2TsCTxQ651yCw8rwYDQjkCVaB8v1CPz/IyBaJOBBLnv+0UMq1 M17z2clsB+v6a6D/mTCZnde+UbQwx5QBjSD7ZEgwjtHtDCwUTesXacsMrL1K8lYsMRRfZ88VKYmRt lynYRoP8etFA99sORFeUHwse9oCVGsxk1VH0bZ4YRYEIq3iqgWThmmruyC/7TL0KueVWZfE9g1JOY xmyyBvDQ==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:62139 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 1lvSdc-0031Hg-My; Mon, 21 Jun 2021 18:43:33 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_E9912DEF-0AA4-4B39-B26D-45B3FC6EEB04"
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_3VEMEGQo0zym59NQi7uejuoWaYOV0SSXyucUM6SZ4BPpvQ@mail.gmail.com>
Date: Mon, 21 Jun 2021 15:43:27 -0700
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, TSVWG <tsvwg@ietf.org>
Message-Id: <52B9E81C-8089-4951-9951-C1E45D4DB0C3@strayalpha.com>
References: <CACL_3VFQR_G5zgjbNiBH3Xu7Dvp+rOXUhNnJ2s4eDwZgq+e-=w@mail.gmail.com> <86D81D07-5CE6-4B89-BF7A-0907AD0AB525@strayalpha.com> <CACL_3VFUFr+bw8wV6zhZhEfj150=AFxgCjKY2mGeRPZcL1NK2w@mail.gmail.com> <20738006-963E-45D6-95DF-3ED842279731@strayalpha.com> <CACL_3VEMEGQo0zym59NQi7uejuoWaYOV0SSXyucUM6SZ4BPpvQ@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/ojBPV6uyDFL1cHbFMou5FDVohGg>
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, 21 Jun 2021 22:43:39 -0000


> On Jun 21, 2021, at 3:29 PM, C. M. Heard <heard@pobox.com> wrote:
> 
> On Mon, Jun 21, 2021 at 3:20 PM Joseph Touch wrote:
>> It's true that OCS is optional when UDP CS==0, but my understanding is that per the current spec, if it is present, the receiver is required to check it and drop the options if it does not follow the rule specified for OCS.
> 
> Yes, and that makes sense - if you’ve added OCS, regardless of whether the UDP CS==0 or not, then you want the options checked. All we currently have been saying is that “OCS can be omitted when CS==0”, not that it MUST be.
> 
>> And that rule is not that the surplus area sums to zero, but that the surplus area plus the pseudo-header consisting of the surplus are length sums to zero.
> 
> It was originally (through draft-ietf-tsvwg-udp-options-05)  to cover the surplus area only; it was in the additional CCO-like behavior that it changed to add the pseudo header  (the surplus length). So are we going back to the pre-CCO definition?
> 
> I'm certainly not advocating for that! Tom Hernert seems to want that, but I sure don't, and as I indicated in my reply to him, I think that going back to the pre-CCO definition would undermine the chances of successful deployment.

OK. I thought I saw something in your response that indicated either that we needed to adjust the calculation or that we need to force it being ignored when UDP CS==0.

Joe