HI, Fred, If you have one segment that’s less than 64K, you don’t need the parcel option at all.
If you have something longer than 64K, either as a single segment or multiple smaller segments, by setting total length to 0, you end up being dropped by legacy routers, which either ignore options they don’t understand or drop packets with options they don’t support. RFC793bis does talk about IPv6 jumbos, but this new work is out of scope for RFC793bis - furthermore, it’s too late. It has passed WGLC, IETF LC, and is currently in IESG review for publication. You also haven’t addressed why the IETF should be taking up this *new* work for IPv4, which I thought also had been considered ineligible. But overall, again, what’s the point? We can’t even get 64K IP packets through the Internet; making them larger doesn’t make that easier or more likely. Such large sizes are of diminishing benefit; routers already forward at 40Gbps per link for minimal packets and end systems have other problems that this exacerbates. This seems a lot like a huge hammer in search of a nail. Where’s the nail? Joe — Joe Touch, temporal epistemologist www.strayalpha.com > On Dec 18, 2021, at 7:18 PM, Templin (US), Fred L <fred.l.temp...@boeing.com> > wrote: > > Joe, I never said that I wanted to restrict this to small transport segments; > in fact, I want > just the opposite – I want large segments. A perfectly legal parcel is one > which includes 1 > ~64KB segment - another legal parcel is one which includes 64 of them! If you > want bigger > segments than that, then true jumbos are necessary and this spec does not > preclude that. > > About RFC793(bis), I see there is a section on Jumbos and IP parcels is (sort > of) an application > of Jumbos. > > Fred > > From: to...@strayalpha.com <mailto:to...@strayalpha.com> > [mailto:to...@strayalpha.com <mailto:to...@strayalpha.com>] > Sent: Saturday, December 18, 2021 4:57 PM > To: Templin (US), Fred L <fred.l.temp...@boeing.com > <mailto:fred.l.temp...@boeing.com>> > Cc: int-area@ietf.org <mailto:int-area@ietf.org>; Wes Eddy > <w...@mti-systems.com <mailto:w...@mti-systems.com>> > Subject: [EXTERNAL] Re: [Int-area] IP parcels > > EXT email: be mindful of links/attachments. > > > Hi, Fred, > > Regarding 793bis, new ideas are out of scope. It’s supposed to be a roll-in > of existing items only. > > Nevermind the problems below, which “TCP will find a way” doesn’t magically > fix. > > The problem is this: > - end systems need to send larger transport segments (not just IP segments) > - if they can do that, they should, filling up to the largest IP payload > > Having an IP packet have the opportunity to include lots of small transport > packets assumes transport packets either work better or faster when they’re > small. It’s the opposite. > > Joe > > — > Joe Touch, temporal epistemologist > www.strayalpha.com <http://www.strayalpha.com/> > > > On Dec 18, 2021, at 4:42 PM, Templin (US), Fred L <fred.l.temp...@boeing.com > <mailto:fred.l.temp...@boeing.com>> wrote: > > Joe, TCP will find a way to adapt – it always has. I also see that TCP is > currently undergoing > a second edition revision so the timing seems right to consider IP parcels in > the analysis. > I am Cc’ing the second edition editor for his information – Wesley, please > consider this > new concept called “IP Parcels” as it relates to your document. > > Here is the latest draft version – it expands on the “Motivation” section and > adds a number > of important feature such as a new “Parcels Permitted” TCP option: > > https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/ > <https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/> > > Fred > > From: to...@strayalpha.com <mailto:to...@strayalpha.com> > [mailto:to...@strayalpha.com <mailto:to...@strayalpha.com>] > Sent: Friday, December 17, 2021 6:01 PM > To: Templin (US), Fred L <fred.l.temp...@boeing.com > <mailto:fred.l.temp...@boeing.com>> > Cc: int-area@ietf.org <mailto:int-area@ietf.org> > Subject: Re: [Int-area] IP parcels > > 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 <http://www.strayalpha.com/> > > > > On Dec 17, 2021, at 5:06 PM, Templin (US), Fred L <fred.l.temp...@boeing.com > <mailto: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 > <mailto:i-d-announce-boun...@ietf.org>] On Behalf Of internet-dra...@ietf.org > <mailto:internet-dra...@ietf.org> > Sent: Friday, December 17, 2021 5:00 PM > To: i-d-annou...@ietf.org <mailto: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/ > <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 > <https://datatracker.ietf.org/doc/html/draft-templin-intarea-parcels-00> > > > Internet-Drafts are also available by rsync at rsync.ietf.org > <http://rsync.ietf.org/>::internet-drafts > > > _______________________________________________ > I-D-Announce mailing list > i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> > https://www.ietf.org/mailman/listinfo/i-d-announce > <https://www.ietf.org/mailman/listinfo/i-d-announce> > Internet-Draft directories: http://www.ietf.org/shadow.html > <http://www.ietf.org/shadow.html> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > <ftp://ftp.ietf.org/ietf/1shadow-sites.txt> > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org <mailto:Int-area@ietf.org> > https://www.ietf.org/mailman/listinfo/int-area > <https://www.ietf.org/mailman/listinfo/int-area>
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
