Hi, Fred, I’m first concerned at the use of an IP option at all, due to the problems with *any* options forcing processing to slow-path.
From TCP’s viewpoint, it seems like you’ve just created a nightmare for SACK and ECN, basically because you will encourage drops of large bursts of packets. This will also increase the bustiness of TCP, i.e., rather than letting the ACKs support pacing. Any part of the system that currently coalesces TCP packets is likely to generate errors here, because they might see only the first TCP segment. However, AFAICT the most significant consideration is that the issue with per-packet performance is at the TCP and UDP layers, not as much at the IP layer. So what problem is this trying to solve? Joe — Joe Touch, temporal epistemologist www.strayalpha.com > On Dec 17, 2021, at 5:06 PM, Templin (US), Fred L <fred.l.temp...@boeing.com> > wrote: > > Here's one that should help with shipping, just in time for Christmas. Thanks > to everyone for the past and future list exchanges. > > Fred > > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of > internet-dra...@ietf.org > Sent: Friday, December 17, 2021 5:00 PM > To: i-d-annou...@ietf.org > Subject: I-D Action: draft-templin-intarea-parcels-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IP Parcels > Author : Fred L. Templin > Filename : draft-templin-intarea-parcels-00.txt > Pages : 8 > Date : 2021-12-17 > > 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-templin-intarea-parcels-00 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > _______________________________________________ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
