IETF Logo Mail Archive

Re: [tsvwg] RDMA Support by UDP FRAG Option

"C. M. Heard" <heard@pobox.com> Mon, 21 June 2021 19:48 UTC

Return-Path: <heard@pobox.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 326ED3A18B8 for <tsvwg@ietfa.amsl.com>; Mon, 21 Jun 2021 12:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.898
X-Spam-Level:
X-Spam-Status: No, score=-0.898 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.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 nHvjXhXDsehf for <tsvwg@ietfa.amsl.com>; Mon, 21 Jun 2021 12:48:18 -0700 (PDT)
Received: from pb-smtp21.pobox.com (pb-smtp21.pobox.com [173.228.157.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383813A18B3 for <tsvwg@ietf.org>; Mon, 21 Jun 2021 12:48:17 -0700 (PDT)
Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 46DC7129A67 for <tsvwg@ietf.org>; Mon, 21 Jun 2021 15:48:16 -0400 (EDT) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:cc:content-type; s=sasl; bh=XLCke53+yrr6TKrVJTqMpJNiRR8MjREw p5pOZp1jTeg=; b=d7YBlYn6KUre86ShOqZ+gN5MHiq72muDGRwfSQ8BISknUQNZ 06iWnWJqDPvTDyPY11yQsTXRC5P1h7KvtTmuskqL0Yt1BKfscV5+nuymSB48JvWP UjJCgEnbfUdDyaNpk2LuC+ESP/EHKtF0iUcdqIt3oDv+6X4FnYSZUm4KCHQ=
Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 40065129A66 for <tsvwg@ietf.org>; Mon, 21 Jun 2021 15:48:16 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-io1-f53.google.com (unknown [209.85.166.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 2AAFE129A61 for <tsvwg@ietf.org>; Mon, 21 Jun 2021 15:48:13 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-io1-f53.google.com with SMTP id s19so10713101ioc.3 for <tsvwg@ietf.org>; Mon, 21 Jun 2021 12:48:13 -0700 (PDT)
X-Gm-Message-State: AOAM5326CPr4NUdEf1TiXWJIQG3NscPWKoFjHgWqeAbteIKXS58TIw4Y 6qqo/qdbcflF3V5qrKXlRd8gD4Pi4TxdrjMjtCI=
X-Google-Smtp-Source: ABdhPJzDDFSkVL6c+xBRscfxbxmXjzFRDt8szfCd3J6pEF5DJjWmvLayKPxUTdi2qiyzdEvvX5qP07XZnKPC+UOM0Fg=
X-Received: by 2002:a6b:f717:: with SMTP id k23mr21050503iog.17.1624304891807; Mon, 21 Jun 2021 12:48:11 -0700 (PDT)
MIME-Version: 1.0
References: <CACL_3VFQR_G5zgjbNiBH3Xu7Dvp+rOXUhNnJ2s4eDwZgq+e-=w@mail.gmail.com> <86D81D07-5CE6-4B89-BF7A-0907AD0AB525@strayalpha.com>
In-Reply-To: <86D81D07-5CE6-4B89-BF7A-0907AD0AB525@strayalpha.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Mon, 21 Jun 2021 12:48:00 -0700
X-Gmail-Original-Message-ID: <CACL_3VFUFr+bw8wV6zhZhEfj150=AFxgCjKY2mGeRPZcL1NK2w@mail.gmail.com>
Message-ID: <CACL_3VFUFr+bw8wV6zhZhEfj150=AFxgCjKY2mGeRPZcL1NK2w@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, TSVWG <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001551ea05c54bf4af"
X-Pobox-Relay-ID: 9D286F3C-D2C9-11EB-AEB2-FA9E2DDBB1FC-06080547!pb-smtp21.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Q9DMZ16Bmhr-B_6uUfrF42_BZL0>
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 19:48:23 -0000

On Mon, Jun 21, 2021 at 11:19 AM Joe Touch <touch@strayalpha.com> wrote:

> On Jun 21, 2021, at 9:37 AM, C. M. Heard <heard@pobox.com> wrote:
>
> On Mon, Jun 21, 2021 at 8:48 AM Joseph Touch wrote:
>
>> …
>> > In my opinion, the best chance for UDP options to be deployable and
>> > successful is to require that the surplus area always sums to zero.
>>
>> When UDP CS==0, OCS provides that capability.
>
>
> It would, if the requirement for a receiver to check OCS when it is
> present were dropped when UCP CS==0.
>
>
> Why / how does this help?
>

You said (or at least I thought you said) that when UDP CS==0, OCS provides
the capability to force the surplus area to sum to zero.

If I understand the current spec correctly, then that is not really true.

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.
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.

Mike

v2.23.0 | Report a Bug | By Email