Skip to main content

IP Parcels
draft-templin-intarea-parcels-02

The information below is for an old version of the document.
Document Type Active Internet-Draft (individual)
Author Fred Templin
Last updated 2021-12-18
Stream (None)
Formats plain text html xml htmlized pdfized bibtex
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-templin-intarea-parcels-02
Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Updates: RFC2675 (if approved)                          18 December 2021
Intended status: Standards Track                                        
Expires: 21 June 2022

                               IP Parcels
                    draft-templin-intarea-parcels-02

Abstract

   IP packets (both IPv4 and IPv6) are understood to contain a unit of
   data which becomes the retransmission unit in case of loss.  Upper
   layer protocols such as the Transmission Control Protocol (TCP)
   prepare data units known as "segments", with traditional arrangements
   including a single segment per packet.  This document presents a new
   construct known as the "IP Parcel" which permits a single packet to
   carry multiple segments, essentially creating a "packet-of-packets".
   The parcel can be opened at middleboxes on the path with the included
   segments broken out into individual packets, then rejoined into one
   or more repackaged parcels to be forwarded further toward the final
   destination.  Reordering of segments within parcels is unimportant;
   what matters is that the number of parcels delivered to the final
   destination should be kept to a minimum, and that loss or receipt of
   individual segments (and not parcel size) determines the
   retransmission unit.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 21 June 2022.

Templin                   Expires 21 June 2022                  [Page 1]
Internet-Draft                 IP Parcels                  December 2021

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  IP Parcel Formation . . . . . . . . . . . . . . . . . . . . .   4
   4.  Transmission of IP Parcels  . . . . . . . . . . . . . . . . .   5
   5.  TCP Parcel-Permitted Option . . . . . . . . . . . . . . . . .   6
   6.  Integrity . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  RFC2675 Updates . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  IPv4 Jumbograms . . . . . . . . . . . . . . . . . . . . . . .   8
   10. Implementation Status . . . . . . . . . . . . . . . . . . . .   8
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   12. Security Considerations . . . . . . . . . . . . . . . . . . .   8
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     14.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     14.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   IP packets (both IPv4 [RFC0791] and IPv6 [RFC8200]) are understood to
   contain a unit of data which becomes the retransmission unit in case
   of loss.  Upper layer protocols such as the Transmission Control
   Protocol (TCP) [RFC0793], QUIC [RFC9000], LTP [RFC5326] and others
   prepare data units known as "segments", with traditional arrangements
   including a single segment per packet.  This document presents a new
   construct known as the "IP Parcel" which permits a single packet to
   carry multiple segments.  This essentially creates a "packet-of-
   packets" with the IP layer headers appearing only once but with
   possibly multiple upper layer protocol segments.

Templin                   Expires 21 June 2022                  [Page 2]
Internet-Draft                 IP Parcels                  December 2021

   Parcels are formed when an upper layer protocol entity (identified by
   the "5-tuple" source IP address/port number, destination IP address/
   port number and protocol number) prepares a buffer of data with the
   concatenation of up to 64 properly-formed segments that could stand
   alone if broken out into individual packets using a copy of the IP
   header.  All segments except the final segment must be equal in size,
   while the final segment must not be larger than the others but may be
   smaller.  Each non-final segment must be no larger than 65535 (minus
   headers).  The upper layer protocol entity then delivers the buffer
   and non-final segment size to the IP layer, which appends the
   necessary IP headers to identify this as a parcel and not an ordinary
   packet.

   Each parcel can be opened at a first-hop middlebox on the path with
   the included segments broken out into individual packets, then
   rejoined into one or more parcels at a last-hop middlebox to be
   forwarded to the final destination.  Reordering of segments within a
   parcel or even repackaging of parcels entirely is unimportant; what
   matters is that the number of parcels delivered to the final
   destination should be kept to a minimum, and that loss or receipt of
   individual segments (and not parcel size) determines the
   retransmission unit.

   The following sections discuss rationale for creating and shipping
   parcels as well as the actual protocol constructs and procedures
   involved.  It is expected that the parcel concept may drive future
   innovation in applications, operating systems, network equipment and
   data links.

2.  Motivation

   Studies have shown that applications that send and receive large
   packets can realize greater performance due to reduced numbers of
   system calls and interrupts as well as larger atomic data copies
   between kernel and user space.  Within the network, large packets
   also result in reduced numbers of device interrupts and better
   network utilization in comparison with smaller packet sizes.

Templin                   Expires 21 June 2022                  [Page 3]
Internet-Draft                 IP Parcels                  December 2021

   A first study involved performance enhancement of the QUIC protocol
   [RFC9000] using the Generic Segment/Receive Offload (GSO/GRO)
   facility.  GSO/GRO provide a robust (but non-standard) service very
   similar in nature to the IP parcel service described here, and its
   application has shown significant performance increases due to the
   increased transfer unit size between the operating system kernel and
   QUIC application.  A second study showed that GSO/GRO also improved
   performance for the Licklider Transmission Protocol (LTP) [RFC5326]
   in a similar fashion.  Historically, the NFS protocol also saw
   dramatic performance increases when using larger UDP datagram sizes
   even when those sizes invoked IP fragmentation.

   The issue with sending large packets is that they are often lost at
   links with smaller Maximum Transmission Units (MTUs), and the
   resulting Packet Too Big (PTB) message may be lost somewhere in the
   path back to the original source.  This "Path MTU black hole"
   condition can cripple application performance unless also
   supplemented with robust path probing techniques, however the best
   case performance always occurs when no packets are lost due to size
   restrictions.

   These considerations therefore motivate a design where the maximum
   segment size should be no larger than 65535 (minus headers), while
   parcels that carry the segments may themselves be significantly
   larger.  Then, even if a middlebox needs to open the parcels to
   deliver individual segments further toward final hops as separate IP
   packets, an important performance optimization for both the original
   source and final destination can be realized.

   An analogy: when an end user orders 50 small items from a major
   online retailer, the retailer does not ship the order in 50 separate
   small boxes.  Instead, the retailer puts as many of the small boxes
   as possible into one or a few larger boxes (or parcels) then places
   the parcels on a semi-truck or airplane.  The parcels arrive at a
   regional distribution center where they may be further redistributed
   into slightly smaller parcels that get delivered to the end user.
   But most often, the end user will only find one or a few parcels at
   his doorstep and not 50 individual boxes.

3.  IP Parcel Formation

   IP parcel formation is invoked by an upper layer protocol (identified
   by the 5-tuple as above) when it produces a data buffer containing
   the concatenation of up to 64 segments.  All non-final segments MUST
   be equal in length while the final segment MUST NOT be larger but MAY
   be smaller.  Each non-final segment MUST be no larger than 65535
   minus the length of the IP header, IP extension headers, and the
   length of an additional IPv6 header in case encapsulation is

Templin                   Expires 21 June 2022                  [Page 4]
Internet-Draft                 IP Parcels                  December 2021

   necessary (see: Section 4).  The application then presents the buffer
   and non-final segment size to the IP layer which appends a single IP
   header (plus any extension headers) before presenting the parcel to
   lower layers.

   For IPv4, the IP layer prepares the parcel by appending an IPv4
   header with a Jumbo Payload option (identified by option code TBD1)
   formed as follows:

   +--------+--------+--------+--------+--------+--------+
   |000(TBD1)00000110|       Jumbo Payload Length        |
   +--------+--------+--------+--------+--------+--------+

   where "Jumbo Payload Length" is a 32-bit unsigned integer value (in
   network byte order) set to the lengths of the IPv4 header plus all
   concatenated segments.  The IP layer next sets the IPv4 header DF bit
   to 1, then sets the IPv4 header Total Length field to the length of
   the IPv4 header plus the length of the first segment only.  Note that
   the IP layer can form true IPv4 jumbograms (as opposed to parcels) by
   instead setting the IPv4 header Total Length field to 0 (see:
   Section 9).

   For IPv6, the IP layer forms a parcel by appending an IPv6 header
   with a Jumbo Payload option [RFC2675] the same as for IPv4 above
   where "Jumbo Payload Length" is set to the lengths of the IPv6 Hop-
   by-Hop Options header and any other extension headers present plus
   all concatenated segments.  The IP layer next sets the IPv6 header
   Payload Length field to the lengths of the IPv6 Hop-by-Hop Options
   header and any other extension headers present plus the length of the
   first segment only.  As with IPv4 the IP layer can form true IPv6
   jumbograms (as opposed to parcels) by instead setting the IPv6 header
   Payload Length field to 0 (see: [RFC2675]).

4.  Transmission of IP Parcels

   The IP layer next presents the parcel to the outgoing network
   interface.  For OMNI interfaces [I-D.templin-6man-omni], the OMNI
   Adaptation Layer (OAL) source can open the parcel if necessary and
   forward each segment as an individual IP packet.  These individual
   packets eventually arrive at the OAL destination which may re-combine
   them into a new parcel or parcels to forward to the final
   destination.  Details for OAL parcel forwarding are discussed in
   [I-D.templin-6man-omni].

   For ordinary network interfaces, however, the IP layer instead
   forwards the parcel according to the path MTU to either the first
   middlebox that configures an OAL layer or to the final destination
   itself, whichever comes first.  If the parcel is no larger than the

Templin                   Expires 21 June 2022                  [Page 5]
Internet-Draft                 IP Parcels                  December 2021

   path MTU, the IP layer simply forwards the parcel the same as it
   would an ordinary IP packet and processes any PTB messages that may
   be returned (but, see below for compatibility issues).  If the parcel
   is larger than 65535 (minus encapsulation headers) and also larger
   than the path MTU, the IP layer instead discards the parcel and
   returns a packet size error to the upper layer protocol.

   If the parcel is no larger than 65535 (minus encapsulation headers)
   but larger than the path MTU, the IP layer instead performs IP
   encapsulation with destination set to the IP address of the middlebox
   or final destination and (Payload Length / Total Length) set to the
   Jumbo Payload Length plus encapsulation header length then performs
   source-fragmentation on the encapsulated parcel the same as for an
   ordinary IP packet by generating IP fragments destined for the
   middlebox or final destination.

   When the middlebox or final destination receives the fragments or
   whole parcels, it reassembles, discards the encapsulation headers if
   necessary then presents the parcel to the OAL in the middlebox case
   or the upper layer protocol in the final destination case.

5.  TCP Parcel-Permitted Option

   TCP peers that wish to employ IP parcels must negotiate their use
   upon connection establishment by including the Parcel-Permitted
   option.  This two-byte option may be sent in a SYN by a TCP that has
   been extended to receive (and presumably process) IP parcels once the
   connection has opened.  It MUST NOT be sent on non-SYN segments.  The
   TCP option has the following format:

          TCP Parcel-Permitted Option:

          Kind: TBD2

          +---------+---------+
          |Kind=TBD2| Length=2|
          +---------+---------+

   A TCP that includes the Parcel-Permitted option MUST be capable of
   reassembling the maximum-length encapsulated IP parcel/packet that
   can undergo fragmentation (see: Section 3 and Section 4).

   Note: the TCP protocol is currently under revision for second edition
   RFC publication [I-D.ietf-tcpm-rfc793bis].  An investigation of the
   applicability of IP parcels for the second edition publication is
   recommended.

Templin                   Expires 21 June 2022                  [Page 6]
Internet-Draft                 IP Parcels                  December 2021

6.  Integrity

   Parcels can range in length from as small as only the IP header sizes
   to as large as the IP headers plus (64 * (2**16 minus headers))
   octets.  Although link layer integrity checks provide sufficient
   protection for contiguous data blocks up to approximately 9KB,
   reliance on the presence of link-layer integrity checks may not be
   possible over links such as tunnels.  Moreover, the segment contents
   of a received parcel may arrive in an incomplete and/or rearranged
   order with respect to their original packaging.

   For these reasons, upper layers must include individual integrity
   checks with each segment included in the parcel with a strength
   compatible with the segment length.  The integrity check must then be
   verified at the receiver on a per-segment basis, which discards any
   corrupted segments and considers them as a loss event.

7.  Compatibility

   Legacy networking gear that forwards parcels over ordinary data links
   may not recognize the new Jumbo Payload extension header coding and
   may act only on the IPv4 Total Length or IPv6 Payload Length field
   value.  In that case, the legacy gear would likely forward only the
   first segment of the parcel while truncating the remainder since only
   the length of the first segment is included in the IP header.

   In networks where compatibility is thought to be an issue, the
   original source can perform encapsulation on parcels uniformly
   whether or not fragmentation is required to ensure they are delivered
   to the OAL source or final destination (whichever comes first).  In
   the same way the OAL destination can uniformly perform encapsulation
   to ensure that parcels are delivered to the final destination.

8.  RFC2675 Updates

   Section 3 of [RFC2675] provides a list of certain conditions to be
   considered as errors.  In particular:

      error: IPv6 Payload Length != 0 and Jumbo Payload option present

      error: Jumbo Payload option present and Jumbo Payload Length <
      65,536

   Implementations that obey this specification ignore these conditions
   and do not consider them as errors.

Templin                   Expires 21 June 2022                  [Page 7]
Internet-Draft                 IP Parcels                  December 2021

9.  IPv4 Jumbograms

   By defining a new IPv4 Jumbo Payload option, this document also
   implicitly enables an IPv4 jumbogram service defined as an IPv4
   packet with Total Length set to 0 and with a Jumbo Payload option in
   the IPv4 extension headers.  All aspects of IPv4 jumbograms
   (including length determination for upper layer protocols) follow
   exactly the same as for IPv6 jumbograms as specified in [RFC2675].

10.  Implementation Status

   Common widely-deployed implementations include services such as TCP
   Segmentation Offload (TSO) and Generic Segmentation/Receive Offload
   (GSO/GRO).  These services support a robust (but not standardized)
   service that has been shown to improve performance in many instances.
   Implementation of the IP parcel service is a work in progress.

11.  IANA Considerations

   The IANA is instructed to allocate a new IP option code in the 'ip
   option numbers' registry for the "JUMBO - IPv4 Jumbo Payload" option.
   The Copy and Class fields must both be set to 0, and the Number and
   Value fields must both be set to 'TBD1 (to be assigned by IANA)'.
   The reference must be set to this document (RFCXXXX).

   The IANA is instructed to allocate a new TCP Option Kind Number in
   the 'tcp-parameters' registry for the "IP Parcel Permitted" option.
   The Kind must be set to 'TBD2' (to be assigned by IANA) and the
   Length must be set to 2.  The reference must be set to this document
   (RFCXXXX).

12.  Security Considerations

   Communications networking security is necessary to preserve
   confidentiality, integrity and availability.

13.  Acknowledgements

   This work was inspired by ongoing AERO/OMNI/DTN investigations.  The
   concepts were further motivated through discussions on the intarea
   list.

   A considerable body of work over recent years has produced useful
   "segmentation offload" facilities available in widely-deployed
   implementations.

   .

Templin                   Expires 21 June 2022                  [Page 8]
Internet-Draft                 IP Parcels                  December 2021

14.  References

14.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
              RFC 2675, DOI 10.17487/RFC2675, August 1999,
              <https://www.rfc-editor.org/info/rfc2675>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

14.2.  Informative References

   [I-D.ietf-tcpm-rfc793bis]
              Eddy, W. M., "Transmission Control Protocol (TCP)
              Specification", Work in Progress, Internet-Draft, draft-
              ietf-tcpm-rfc793bis-25, 7 September 2021,
              <https://www.ietf.org/archive/id/draft-ietf-tcpm-
              rfc793bis-25.txt>.

   [I-D.templin-6man-omni]
              Templin, F. L. and T. Whyman, "Transmission of IP Packets
              over Overlay Multilink Network (OMNI) Interfaces", Work in
              Progress, Internet-Draft, draft-templin-6man-omni-51, 15
              November 2021, <https://www.ietf.org/archive/id/draft-
              templin-6man-omni-51.txt>.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

   [RFC5326]  Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
              Transmission Protocol - Specification", RFC 5326,
              DOI 10.17487/RFC5326, September 2008,
              <https://www.rfc-editor.org/info/rfc5326>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

Templin                   Expires 21 June 2022                  [Page 9]
Internet-Draft                 IP Parcels                  December 2021

Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA 98124
   United States of America

   Email: fltemplin@acm.org

Templin                   Expires 21 June 2022                 [Page 10]