IP Parcels
draft-templin-intarea-parcels-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Fred Templin | ||
| Last updated | 2021-12-17 | ||
| 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-00
Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology
Updates: RFC2675 (if approved) 17 December 2021
Intended status: Standards Track
Expires: 20 June 2022
IP Parcels
draft-templin-intarea-parcels-00
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. 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 20 June 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Templin Expires 20 June 2022 [Page 1]
Internet-Draft IP Parcels December 2021
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. Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 6
7. RFC2675 Updates . . . . . . . . . . . . . . . . . . . . . . . 6
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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] 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.
Templin Expires 20 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. 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 smaller than 576 and no larger than 65535 minus the length
of the IP header plus extensions. The upper layer protocol entity
then delivers the buffer and non-final segment size to the IP layer,
which appends the necessary 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
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.
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 application and data link design.
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.
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 IP header sizes,
while parcels that carry the segments may themselves be significantly
Templin Expires 20 June 2022 [Page 3]
Internet-Draft IP Parcels December 2021
larger. Then, even if a middlebox needs to open the parcels to
deliver individual segments further toward final hops, 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 in one or a few larger boxes (or parcels) then puts the
parcels on a semi-truck or airplane. The parcels arrive at a
regional distribution center where they may be further broken down
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 smaller than 576 and
no larger than 65535 minus the length the IP header plus extensions.
The application then presents the buffer and non-final segment size
to the IP layer which appends an 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 TBD)
formed as follows:
+--------+--------+--------+--------+--------+--------+
|000(TBD)|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.
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
Templin Expires 20 June 2022 [Page 4]
Internet-Draft IP Parcels December 2021
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.
4. Transmission of IP Parcels
The IP layer next presents the parcel to the next lower layer. If
the lower layer is the OMNI Adaptation Layer (OAL)
[I-D.templin-6man-omni], the OAL source opens the parcel and forwards
each segment as an individual IP packet. These individual packets
eventually arrive at the OAL destination which re-combines them into
a new parcel or parcels then forwards them to the final destination.
Details for OAL parcel forwarding are discussed in
[I-D.templin-6man-omni].
If the lower layer is a true data link layer interface, however, the
IP layer instead forwards the parcel according to the path MTU to
either the first middlebox that configures an OAL layer or the final
destination itself, whichever comes first. If the parcel is no
larger than the 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 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 then 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.
Templin Expires 20 June 2022 [Page 5]
Internet-Draft IP Parcels December 2021
5. Integrity
Parcels can range in length from the size of the smallest single
segment to as large as (64 * (2**16)) octets. Although link layer
integrity checks provide sufficient protection for sizes 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 in relation to how they were sent.
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 must then be
verified at the receiver on a per-segment basis, with any corrupted
segments discarded and considered as a loss event.
6. Compatibility
Legacy networking gear that forwards parcels over ordinary data links
may not recognize this new coding of the Jumbo Payload extension
header and may act only on what is observed in the IPv4 Total Length
or IPv6 Payload Length field. In that case, the legacy gear would
likely forward the first segment of the parcel only while truncating
the remainder since only the length of the first segment is included
in the 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.
7. 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 20 June 2022 [Page 6]
Internet-Draft IP Parcels December 2021
8. Implementation Status
TBD.
9. IANA Considerations
The IANA is instructed to allocate a new IP option code in the 'ip
option numbers' registry for the IPv4 Jumbo Payload option. The Copy
and Class fields must both be set to 0, and the Number field must be
set to 'TBD'.
10. Security Considerations
Communications networking security is necessary to preserve
confidentiality, integrity and availability.
11. 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.
.
12. References
12.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>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[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>.
Templin Expires 20 June 2022 [Page 7]
Internet-Draft IP Parcels December 2021
12.2. Informative References
[I-D.templin-6man-aero]
Templin, F. L., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin-
6man-aero-37, 15 November 2021,
<https://www.ietf.org/archive/id/draft-templin-6man-aero-
37.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>.
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 20 June 2022 [Page 8]