[tsvwg] A counterproposal to Section 5.5 of draft-ietf-tsvwg-udp-options-12
"C. M. Heard" <heard@pobox.com> Fri, 04 June 2021 02:22 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 635F33A2439 for <tsvwg@ietfa.amsl.com>; Thu, 3 Jun 2021 19:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 5NFwv55TRggI for <tsvwg@ietfa.amsl.com>; Thu, 3 Jun 2021 19:22:41 -0700 (PDT)
Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA143A2447 for <tsvwg@ietf.org>; Thu, 3 Jun 2021 19:22:41 -0700 (PDT)
Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 43E4C14765B for <tsvwg@ietf.org>; Thu, 3 Jun 2021 22:22:38 -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:content-type; s=sasl; bh=ownFlEwuZkYzzDB60YyqFlz6D1gf/FxJ/nd 2SHBJTTM=; b=noAbndBSPmSy2RmVdWUnbt1L4D0OvlnEkzNEMBdYCGsBw/O3B/U jyFDBwxJrsb5L9pZUzvxhEsNSkAbTL797L9MWcq1u1nxj6biQyiaj38gL+tIz4LE eZS1HTQerGYgr+wLSDIFL9TKVvYqYNQ/zK+SGBOi9nUIuF7+ASLFoVZI=
Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 3E3C614765A for <tsvwg@ietf.org>; Thu, 3 Jun 2021 22:22:38 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-io1-f50.google.com (unknown [209.85.166.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id CC333147657 for <tsvwg@ietf.org>; Thu, 3 Jun 2021 22:22:35 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-io1-f50.google.com with SMTP id p66so6598069iod.8 for <tsvwg@ietf.org>; Thu, 03 Jun 2021 19:22:35 -0700 (PDT)
X-Gm-Message-State: AOAM533WSlhLPavgwGZf/yZctIVRuZjHNFWUlPLem22I0And57gSZsSm FiJAWtYXUwGsyIqz5xGep+P4bqe5kxm7UaaALys=
X-Google-Smtp-Source: ABdhPJzXdFhpe6wVVJA0NH6dRsoJGGPb5EdNhquQl1sZACaWJdzbISERvR6Dn9q3B1No+Dt1FeKuWO1q9EuJbObh4hg=
X-Received: by 2002:a6b:5112:: with SMTP id f18mr1802936iob.142.1622773354480; Thu, 03 Jun 2021 19:22:34 -0700 (PDT)
MIME-Version: 1.0
References: <CACL_3VEyLdQZ-3hvzXxyA8ehtWs2hXESZ2OqyAx+BeSg85+-cA@mail.gmail.com>
In-Reply-To: <CACL_3VEyLdQZ-3hvzXxyA8ehtWs2hXESZ2OqyAx+BeSg85+-cA@mail.gmail.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Thu, 03 Jun 2021 19:22:22 -0700
X-Gmail-Original-Message-ID: <CACL_3VFE4TjKvmkfZjvNpWo6vVfKjz5w85=Q+yqnYZKcwbYLmQ@mail.gmail.com>
Message-ID: <CACL_3VFE4TjKvmkfZjvNpWo6vVfKjz5w85=Q+yqnYZKcwbYLmQ@mail.gmail.com>
To: TSVWG <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000584d4905c3e75dce"
X-Pobox-Relay-ID: B9C4EA86-C4DB-11EB-94F5-D5C30F5B5667-06080547!pb-smtp20.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/N1fmoBxQ5iOL5X7o34oVSA8Ayvw>
Subject: [tsvwg] A counterproposal to Section 5.5 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: Fri, 04 Jun 2021 02:22:54 -0000
TSVWG, In a previous message, I made some rather unkind comments about he FRAG option as proposed in Section 5.5 of draft-ietf-tsvwg-udp-options-12. In this missive I wish to present proposed relacement text for the entire section. If some of the packet diagrams end up a bit garbled, please accept my apologies; I am working within the limits of the gmail client, and I can't always tell what will look good to list recipents or those who browse the TSWG archive. This proposal first appeared in https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg/. The central idea is to make the FRAG option the very last option in the packet and to have it consume all following octets. I want to acknowledge freeley borrowing/stealing the best of some of Joe Touch's excellent text in draft-ietf-tsvwg-udp-options-12. --cut here-- 5.5. Fragmentation (FRAG) The Fragmentation (FRAG) option supports UDP fragmentation and reassembly, which can be used to transfer UDP messages larger than limited by the IP receive MTU (EMTU_R [RFC1122]). It is typically used with the UDP MSS option to enable more efficient use of large messages, both at the UDP and IP layers. FRAG is designed similar to the IPv6 Fragmentation Header [RFC8200], except that the UDP variant uses a 16-bit Offset measured in bytes, rather than IPv6's 13-bit Fragment Offset measured in 8-byte units. FRAG provides transport-layer fragmentation and reassembly in which each fragment includes a copy of the same UDP transport ports, enabling the fragments to traverse Network Address (and port) Translation (NAT) devices, in contrast to the behavior of IP fragments. >> When FRAG is present, the UDP payload MUST be empty. If the payload is not empty, all UDP options MUST be silently ignored and the UDP payload received MUST be sent to the user. Legacy receivers interpret FRAG messages as zero-length payload packets (i.e., UDP Length field is 8, the length of just the UDP header), which would not affect the receiver unless the presence of the packet itself were a signal. >> When FRAG is present, it MUST come LAST in the UDP options list. All remaining octets in the packet are interpreted as fragment data. The FRAG option has two formats; non-terminal fragments set the More Fragments (MF) field to 1 and terminal fragments set the MF field to 0. The latter includes stand-alone fragments, i.e., when data is contained in the FRAG option but reassembly is not required. In both cases the option length is implicitly eight octets. +--------+--------+--------+--------+ | Kind=5 | MF=1 | Frag. Offset | +--------+--------+--------+--------+ | Identification | +--------+--------+--------+--------+ | ... Fragment Data ... | +--------+--------+--------+--------+ UDP non-terminal FRAG option format +--------+--------+--------+--------+ | Kind=5 | MF=0 | Frag. Offset | +--------+--------+--------+--------+ | Identification | +--------+--------+--------+--------+ | ... Fragment Data ... | +--------+--------+--------+--------+ UDP terminal FRAG option format >> The Fragment Offset is 16 bits and indicates the location of the UDP payload fragment in bytes from the beginning of the original unfragmented payload. The MF field indicates whether there are more fragments (MF=1) or no more fragments (MF=0). >> The Identification field is a 32-bit value that MUST be unique over the expected fragment reassembly timeout. >> The Identification field SHOULD be generated in a manner similar to that of the IPv6 Fragment ID [RFC8200]. >> UDP fragments MUST NOT overlap. Note that exact duplicates may occur when packets are duplicated in the network. UDP fragmentation relies on a fragment expiration timer, which can be preset or could use a value computed using the UDP Timestamp option. >> The default UDP reassembly SHOULD be no more than 2 minutes. Implementers are advised to limit the space available for UDP reassembly. >> UDP reassembly space SHOULD be limited to reduce the impact of DOS attacks on resource use. >> UDP reassembly space limits SHOULD NOT be implemented as an aggregate, to avoid cross-socketpair DOS attacks. >> Individual UDP fragments MUST NOT be forwarded to the user. The reassembled datagram is received only after complete reassembly, and continued processing of the remaining UDP options. >> Only per-fragment UDP options may accompany the FRAG header in non-terminal fragments. These include NOP, OCS, and AE. All options that apply to a reassembled UDP datagram MUST accompany the FRAG header in the terminal fragment. These include ACS, MSS, MRSS, TIME, REQ, and RES. UNSAFE may appear in either place, depending. on the nature of the UNSAFE Ukind. In general, UDP packets are fragmented as follows: 1. Create a datagram with data and any UDP options that apply to the complete UDP datagram, which we will call "D". Note that these options must accompany the terminal fragment. They are prepared before the rest of the fragmentation steps below. 2. Identify the desired fragment size, which we will call "S". This value should take into account the path MTU (if known) and allow space for per-fragment options (e.g., OCS). 3. Fragment "D" into chunks of size no larger than "S"-8 each. Note that all of the per-datagram options in step #1 MUST appear in the terminal fragment. 4. For each chunk of "D" in step #3, create a zero-data UDP packet followed by the per-fragment options, with the final option being the FRAG option followed by the FRAG data chunk. The last chunk includes the non-FRAG options noted in step #1. These UDP options apply to the reassembled data as a whole. 5. Process the UDP options of each fragment, e.g., computing its OCS. Receivers reverse the above sequence. They process all received options in each fragment. When the FRAG option is encountered, the FRAG data is used in reassembly. After all fragments are received, the entire packet is processed with any per-datagram UDP options accompanying the terminal fragment applying to the reassembled data. --cut here-- This is what typical UDP datagrams containing UDP fragments would look like: +--------+--------+--------+--------+ | Source Port | Dest. Port | +--------+--------+--------+--------+ | UDP Len=8 | UDP Checksum | +--------+--------+--------+--------+ | NOP=1 | OCS=2 | Option Checksum | +--------+--------+--------+--------+ | FRAG=5 | MF=1 | Frag. Offset | +--------+--------+--------+--------+ | Identification | +--------+--------+--------+--------+ | ... Fragment Data ... | +--------+--------+--------+--------+ UDP non-terminal FRAG packet +--------+--------+--------+--------+ | Source Port | Dest. Port | +--------+--------+--------+--------+ | UDP Len=8 | UDP Checksum | +--------+--------+--------+--------+ | NOP=1 | OCS=2 | Option Checksum | +--------+--------+--------+--------+ | ... Other Options ... | +--------+--------+--------+--------+ | FRAG=5 | MF=0 | Frag. Offset | +--------+--------+--------+--------+ | Identification | +--------+--------+--------+--------+ | ... Fragment Data ... | +--------+--------+--------+--------+ UDP terminal FRAG packet Kindly review and send send constructive comments to the WG list Thanks and regards, Mike Heard
- [tsvwg] A counterproposal to Section 5.5 of draft… C. M. Heard
- Re: [tsvwg] A counterproposal to Section 5.5 of d… Joseph Touch
- Re: [tsvwg] A counterproposal to Section 5.5 of d… C. M. Heard
- [tsvwg] RDMA Support by UDP FRAG Option C. M. Heard
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option C. M. Heard
- Re: [tsvwg] RDMA Support by UDP FRAG Option Gorry Fairhurst
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option Gorry Fairhurst
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joe Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option C. M. Heard
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joe Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option C. M. Heard
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option C. M. Heard
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- [tsvwg] incorrectly coalesce packets [was: Re: RD… Rodney W. Grimes
- Re: [tsvwg] RDMA Support by UDP FRAG Option Rodney W. Grimes
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option C. M. Heard
- Re: [tsvwg] incorrectly coalesce packets [was: Re… Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option C. M. Heard
- Re: [tsvwg] RDMA Support by UDP FRAG Option C. M. Heard
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option C. M. Heard
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joe Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joe Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Tom Herbert
- Re: [tsvwg] RDMA Support by UDP FRAG Option C. M. Heard
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joe Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch
- Re: [tsvwg] RDMA Support by UDP FRAG Option C. M. Heard
- Re: [tsvwg] RDMA Support by UDP FRAG Option Joseph Touch