Re: [Int-area] IP parcels

["Templin (US), Fred L" <[e-mail]>]

Tom, sorry getting ready to shut down for the evening but a new draft version is out.
Please see if this answers questions, or if not we can continue to discuss.

Thanks - Fred

> -----Original Message-----
> From: Tom Herbert [mailto:[e-mail]]
> Sent: Tuesday, December 21, 2021 1:52 PM
> To: Templin (US), Fred L <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: [EXTERNAL] Re: IP parcels
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> On Tue, Dec 21, 2021 at 1:17 PM Templin (US), Fred L
> <[e-mail]> wrote:
> >
> > Tom, thanks for these questions. A simple picture might help understanding:
> >
> > A <- net #1 -> X <- Internet -> Y <- net #2 - > B
> >
> Fred,
> 
> Thanks. The picture is helpful.
> 
> Presumably, in this picture the typical scenario would be that the MTU
> of net #1 and net #2 are greater than the MTU on the Internet, and
> could in fact be much greater. So a large MTU packet to B and over its
> local network it gets the benefits of a larger MTU. And then such
> packets could be fragmented at X to send over the Internet. Y
> reassembles the packet to enjoy the benefits of a larger MTU on
> network #2.
> 
> If my understanding is correct, X is basically fragmenting packets
> whose length exceeds the MTU of the Internet. That seems to have the
> same functionality as IP fragmentation, but I suppose the point of IP
> parcels is that the packet may be larger than 64K or it allows
> intermediate nodes to do fragmentation with IPv6.
> 
> But what is happening at Y is interesting to me. Y is trying to
> opportunistically reassemble packets in the network. As I mentioned
> the problem with doing that is that Y may or may not see all the
> packets of a parcel, or an attacker could purposely send one-off
> fragments to try to exhaust memory, or there might just be too many
> user flows going through the device that are candidates for
> reassembly-- for any of these cases it seems pretty easy to move to a
> state that substantially reduces the benefits of in-network
> reassembly. And if a device does get into this mode where it's only
> able to reassemble some small fraction of the traffic, then it seems
> like the effect would be to introduce delay on parcel fragments that
> never actually get reassembled (which would seem to violate the
> principle that if an opportunistic optimization becomes in effective,
> the effects should be no worse than had the optimization no existed at
> all). Do you have any data on the cost/benefits of reassembling at Y?
> 
> Tom
> 
> > Here, when A sends a parcel to B, it travels first over net #1 to a "first hop
> > middlebox" X. If the path MTU from A to X is smaller than the size of the
> > parcel, then A has to split the parcel into subparcels no larger than 64KB
> > and transmit each of the sub-parcels to X using IP fragmentation if necessary.
> > If the path MTU from A to X is at least as large as the parcel, then A can send
> > the whole parcel to X, i.e., even if the path MTU and parcel size exceed 64KB.
> >
> > Once X gets the subparcels, X should perform "sticky reassembly" by concatenating
> > subparcels of the same parcel opportunistically; but it does not need to strictly
> > reassemble the full parcel because the sub-parcels can go forward independently
> > if necessary. X then needs to somehow convey the parcel (or sub-parcels) over the
> > Internet to Y and the same considerations as above apply. Then, the same thing
> > happens for Y conveying finally on to B.
> >
> > So, in terms of fragmentation and reassembly at the IP layer, all that is required
> > is that all of A, X, Y and B are capable of reassembling up to 64KB since that is the
> > largest size IP packet that can be reassembled. If any or all of the hops support a
> > larger packet size (jumbo) then great and the parcel can be forwarded in one piece.
> >
> > But, at the parcel layer it is somewhat different. Breaking a parcel into sub-parcels
> > means that a single parcel can be broken down to a maximum of 64 sub-parcels.
> > Each of these sub-parcels should be marked with a common short Parcel ID plus
> > a monotonically incrementing 32-bit packet Identifier so the next hop can know
> > that they were all originally part of the same parcel. Then, the next hop applies
> > "opportunistic reassembly" as you called it and tries to paste the parcel back together.
> > If the whole parcel gets reassembled to its original form, then that is great; otherwise,
> > it can continue forward as sub parcels to the next hop.
> >
> > And it continues in this fashion from source to destination. If the "sticky" parcel
> > reassembly works well then the whole original parcel might be delivered to the
> > final destination in one piece. But, in the worst case, the final destination might
> > get up to 64 singleton parcels - and then, it can do "sticky reassembly" on these
> > since it is the final destination!
> >
> > In fact, the whole reason for doing "sticky reassembly" at middleboxes it to make
> > the largest possible parcels to send to next hops where the path MTU is greater
> > than 64K. We don't have many paths like that yet, but parcels might provide
> > motivation for trending in that direction.
> >
> > I was originally thinking I would capture all this in the OMNI spec instead of the
> > IP parcels spec, but I see that a lot of this should probably also go in IP parcels.
> > What do you think?
> >
> > Thanks - Fred
> >
> > > -----Original Message-----
> > > From: Tom Herbert [mailto:[e-mail]]
> > > Sent: Tuesday, December 21, 2021 10:01 AM
> > > To: Templin (US), Fred L <[e-mail]>
> > > Cc: [e-mail]; [e-mail]
> > > Subject: Re: IP parcels
> > >
> > > On Tue, Dec 21, 2021 at 6:24 AM Templin (US), Fred L
> > > <[e-mail]> wrote:
> > > >
> > > > Tom, reading your message makes me think you have not read my drafts. The
> > > >
> > > > answers to the perceived issues you are raising are all there. I do not see anything
> > > >
> > > > new in what you are saying to make me believe otherwise.
> > > >
> > > >
> > >
> > > Fred,
> > >
> > > I did read your draft. I might be misunderstanding it. Here are points
> > > I don't think I understand, f these are in the draft plead reference
> > > the precise section:
> > >
> > > - A clear explanation why GSO/GRO are not sufficient to solve the
> > > problem. The draft highlights these to show the advantages of
> > > sending/receiving large data units, but it's not clear to me why a
> > > change to the protocol is required to get the same or somehow better
> > > effect. As a side note, it should be pointed out that GSO/GRO and
> > > similar mechanisms are opportunistic optimizations. For instance, the
> > > TCP congestion window and receive window have to be large enough for
> > > GSO to be effective for sending on a connection. As an anecdote, there
> > > was an incident early on at YouTube where they extensively used GSO
> > > for serving video which under normal circumstances is a great savings
> > > in CPU utilization. But one day there was a hiccup on the Internet
> > > that caused all the connections to go to slow start. So now instead of
> > > sending 64K at a time the servers were sending two segments at a time
> > > for all the connections (this was before the work to raise initcwnd);
> > > so now instead of servers running at 50% CPU, they needed 150% CPU and
> > > so were dropping a lot of packets, and recovering took quite a bit of
> > > time making unhappy customers (moral of this story: always provision
> > > your servers to handle the worst case scenario where opportunistic
> > > optimizations become ineffective!)
> > >
> > > - What is the exact algorithm for reassembly of parcels? Searching the
> > > document for reassemble only comes up with "when the OAL source or
> > > final destination receives the fragments or whole parcels, it
> > > reassembles if necessary"
> > >
> > > - What are the ramifications of middleboxes performing reassembly on
> > > behalf of a host. The document says "then rejoined into one or more
> > > parcels at a last-hop middlebox to be forwarded to the final
> > > destination". I'm not sure what a "last-hop middlebox" means in a
> > > normative context, but this does appear to be an intermediate network
> > > node which would seem to be susceptible to the issues of stateful
> > > intermediate network nodes that I previously raised.
> > >
> > > - Is in order delivery of segments within a parcel maintained. The
> > > draft states "While not desirable, reordering of segments within
> > > parcels and individual segment loss are possible.  But, 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".
> > > Why is it so critical to keep the number of parcels delivered to the
> > > final destination to be kept at minimum? As I mentioned, hosts are
> > > already used to dealing with reassembly, it seems like the best method
> > > is still to send packets at path MTU which is what TCP is doing with
> > > PMTUD.
> > >
> > > - How are IP parcels substantially different from fragmentation?  Is
> > > the idea that individual segments in an IP parcel can be lost without
> > > losing the whole parcel? Is the idea that parcels can make up a >64K
> > > super packet? What if a segment in a parcel is greater than an MTU in
> > > the path, is an intermediate node breaking up a parcel expected to
> > > fragment the segment, or send a PTB?
> > >
> > > Tom
> > >
> > >
> > >
> > > >
> > > > Thanks - Fred
> > > >
> > > >
> > > >
> > > > From: Tom Herbert [mailto:[e-mail]]
> > > > Sent: Monday, December 20, 2021 4:14 PM
> > > > To: Templin (US), Fred L <[e-mail]>
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: Re: IP parcels
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Dec 20, 2021 at 3:11 PM Templin (US), Fred L <[e-mail]> wrote:
> > > >
> > > > Tom, in modern reassembly it is not going to wait for the MSL for all fragments
> > > >
> > > > to arrive anymore; either they all get there after a very small inter-fragment
> > > >
> > > > delay, or you send an immediate FRAGREP and possibly also a PTB soft error
> > > >
> > > > then quickly declare the reassembly dead if that doesn’t help. And, you make
> > > >
> > > > sure to inspect IDs of received fragments before admitting them into the
> > > >
> > > > reassembly cache so you don’t end up caching garbage that will just have to
> > > >
> > > > be discarded later.
> > > >
> > > >
> > > >
> > > > Fred,
> > > >
> > > >
> > > >
> > > > It doesn't matter in the sense that reassembly is a non-working conserving mechanism. In order to perform reassembly packet
> fragments
> > > need to be held which means memory will be consumed and since memory is a finite resource it needs to be managed.  Managing
> memory
> > > means that some policy is needed when to time out a reassembly or which fragment train to discard under memory pressure. A network
> > > that implements some arbitrary policy can cause problems on unsuspecting hosts. For instance, there's mechanisms for hosts to try to
> guess
> > > what the timeout is in a NAT box and send a keepalive packet before an idle NAT state is evicted. So this is just a guess that may or may
> not
> > > be right, and in fact there might not even be a NAT in the path in which case the host is just wasting energy sending keepalives. Also, the
> > > second we introduce a new exhaustible resource in the path that becomes yet another denial of service vector (consider the case that
> an
> > > attacker spoofs a whole bunch of IP parcels).
> > > >
> > > >
> > > >
> > > > Unless the network can coordinate very specifically with the host about what it's doing on behalf of the host stack, I think it's much
> better
> > > for the network to just focus or forward packets without delay and let the host handle the details of receive processing, reassembly,
> > > security, etc.
> > > >
> > > >
> > > >
> > > > Tom
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Fred
> > > >
> > > >
> > > >
> > > > From: Tom Herbert [mailto:[e-mail]]
> > > > Sent: Monday, December 20, 2021 1:06 PM
> > > > To: Templin (US), Fred L <[e-mail]>
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: Re: IP parcels
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Dec 20, 2021 at 12:03 PM Templin (US), Fred L <[e-mail]> wrote:
> > > >
> > > > Tom, sorry I will try to use my words more carefully; I am using GSO/GRO also for
> > > >
> > > > a UDP-based transport protocol – not QUIC but something similar. I like GSO/GRO
> > > >
> > > > very much; I am glad the service is available and I want to see it continue. But, my
> > > >
> > > > understanding of the services is that they leverage the IP ID field in whole IPv4
> > > >
> > > > packets that are not eligible for fragmentation and those are limitations I am
> > > >
> > > > seeking to improve on.
> > > >
> > > >
> > > >
> > > > I want to enable a facility similar to GSO/GRO that works for both IPv4 and IPv6
> > > >
> > > > packets and allows for lower layers to fragment if necessary. And, I want to use
> > > >
> > > > a well-behaved 32-bit IPv6 ID instead of the 16-bit IPv4 one where the use is not
> > > >
> > > > well defined when DF=1.
> > > >
> > > >
> > > >
> > > > There has been a lot of work in this area. For instance, you might want to take a look at
> > > https://www.youtube.com/watch?v=ccUeG1dAhbw
> > > >
> > > >
> > > >
> > > > About reassembly, that would only happen on the end systems themselves or on
> > > >
> > > > a very capable device that is very close to the end systems; I would not want for
> > > >
> > > > a high-speed core router to have to reassemble.
> > > >
> > > >
> > > >
> > > > Even so, an intermediate device close to the end system still has to provide service to more than one host. Reassembly requires
> memory
> > > to store fragments. A host would need enough memory to service all of its own flows, but an intermediate node would need number of
> > > hosts it serves times that amount of memory to perform reassembly.  This is a fundamental scaling problem of stateful services in the
> > > network, inevitably the network nodes cannot scale to the number of users or flows that require service. In the best case scenario, when
> > > resources are not available the network won't attempt the stateful operation and will just forward the packet unimpeded (which is fine
> > > because host will never rely on this class of optimization). In the worse case scenario, the network will take a detrimental action such as
> > > forcibly breaking a connection (e.g. this is what can happen when a NAT evicts a TCP connection because it has run out of memory).
> IMO,
> > > maintaining state in the network is a bad, albeit unfortunately prevalent, idea.
> > > >
> > > >
> > > >
> > > > Tom
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Again, GSO/GRO is nice work and much respect is due to those who made it possible.
> > > >
> > > >
> > > >
> > > > Fred
> > > >
> > > >
> > > >
> > > > From: Tom Herbert [mailto:[e-mail]]
> > > > Sent: Monday, December 20, 2021 9:20 AM
> > > > To: Templin (US), Fred L <[e-mail]>
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: Re: [Int-area] [EXTERNAL] Re: IP parcels
> > > >
> > > >
> > > >
> > > > The world is not just TCP anymore. QUIC and other UDP-based transports have already
> > > >
> > > > shown performance increases using facilities like GSO/GRO which are essentially a short
> > > >
> > > > term and non-standard implementation of what parcels promise to do in the long term.
> > > >
> > > >
> > > >
> > > > Fred,
> > > >
> > > >
> > > >
> > > > Can you explain why GSO/GRO aren't sufficient and are only short term solutions? We've been using these for almost twenty years
> now
> > > with good effect. These are widely deployed with TCP, TSO works well to offload transmit, LRO is defined and is in much better shape to
> > > offload RX now that programmable devices are emerging. For TCP it's hard to see how IP parcels would help significantly, but even for
> UDP
> > > we now have UDP GSO, sendmmsg, and recvmmsg that mitigate the cost of system calls and interrupts to which the draft refers. The
> > > reason these aren't standards in IETF is because they're implementation techniques and not protocol (although I will point out that
> > > GSO/GRO/sendmmsg/recvmmsg are in all Linux devices so that effectively makes it a de facto implementation standard).
> > > >
> > > >
> > > >
> > > > I am also concerned about the idea that intermediate devices would perform reassembly. This has a whole bunch of implications like
> > > middleboxes are no longer work conserving and seems to have the implicit requirement that it has to be in the path of every packet in a
> > > parcel (i.e. even in the case of the last hop performing reassembly. Also, as simply a matter of resources and capabilities, hosts are in a
> > > much better position to perform tasks like reassembly. I don't readily see that having intermediate devices perform reassembly would be
> a
> > > win for hosts, and even if it were, host implementations still would need the capability to perform reassembly themselves since they will
> > > never rely on the network to always do it for them.
> > > >
> > > >
> > > >
> > > > Tom
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Thanks - Fred
> > > >
> > > >
> > > >
> > > > From: [e-mail] [mailto:[e-mail]]
> > > > Sent: Sunday, December 19, 2021 11:53 AM
> > > > To: Templin (US), Fred L <[e-mail]>
> > > > Cc: [e-mail]; Wes Eddy <[e-mail]>
> > > > Subject: Re: [Int-area] IP parcels
> > > >
> > > >
> > > >
> > > > Hi, Fred (et al.),
> > > >
> > > >
> > > >
> > > > On Dec 19, 2021, at 10:21 AM, Templin (US), Fred L <[e-mail]> wrote:
> > > >
> > > >
> > > >
> > > > Joe, your insistence on using html makes it impossible to respond to all of your points inline
> > > >
> > > > which is the reason for my top-posts.
> > > >
> > > >
> > > >
> > > > I use MacOS mail, IOS mail, and Thunderbird on Windows, all using default configurations, FWIW. I appear to be able to post inside
> > > everyone else’s responses. I don’t know if the IETF’s mailers are munging formats, though.
> > > >
> > > >
> > > >
> > > > I’ve made my position clear. However:
> > > >
> > > >
> > > >
> > > > - You still haven’t shown any evidence that end systems need to do all this extra work so they can somehow run faster, nor that this
> will
> > > be noticeably faster than large (i.e., 20-60KB) IPv4 packets.
> > > >
> > > >
> > > >
> > > > - You still haven’t shown any reason why this is feasible; in fact, below you add the idea of on-path fragmentation, which is largely
> > > deprecated because fragments won’t traverse tunnels (in your case, notably for single chunks larger than 64KB). Nevermind that the
> > > fragmentation is both expensive and slow-path at routers.
> > > >
> > > >
> > > >
> > > > - You have claimed that both routers and transports will somehow adopt this when we can’t even get reasonably large MTUs that
> already
> > > fit within IPv4 across heterogeneous enterprises.
> > > >
> > > >
> > > >
> > > > IPv4 is over; even if you don’t think so, any way forward with larger packets starts with:
> > > >
> > > >                a) getting ~64KB IP packets across the net
> > > >
> > > >                b) after (a), prove that >64KB are needed based on the IPv6 jumbo approach
> > > >
> > > >
> > > >
> > > > Any way forward with a lot of small packets inside one large one (where both chunks and total length are less than 64K) starts by
> proving
> > > there’s a need and it fixing how TCP interacts with its inherent burstiness and loss correlation.
> > > >
> > > >
> > > >
> > > > Only THEN will this issue be worth more discussion.
> > > >
> > > >
> > > >
> > > > Joe
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Parcels that contain a single segment whether 64K or considerably less are still sent as
> > > >
> > > > (singleton) parcels and not ordinary packets. That way, nodes in the network can know
> > > >
> > > > that it is OK to encapsulate and fragment since by asserting its interest in receiving parcels
> > > >
> > > > the destination has also subscribed to being able to reassemble up to a full 64K.
> > > >
> > > >
> > > >
> > > > Parcels do not set (Payload Length / Total Length) to 0; they set it to the length of the
> > > >
> > > > first element of the parcel (which is also the same length of each non-final element of
> > > >
> > > > the parcel). What happens then is that network equipment will see a unit with an L3
> > > >
> > > > length that may be considerably shorter than the L2 length. You are right that legacy
> > > >
> > > > routers might not like this (or, they might truncate the packet according to L3 length),
> > > >
> > > > and so for paths that might traverse legacy routers the first-hop node that recognizes
> > > >
> > > > parcels instead encapsulates the parcel in an IPv4 or IPv6 header then performs (source)
> > > >
> > > > fragmentation if necessary. These IP fragments will then travel through legacy routers
> > > >
> > > > just fine.
> > > >
> > > >
> > > >
> > > > About RFC793bis, you and Wes Eddy know far more about its status than I do; I only
> > > >
> > > > noted that this is something with TCP implications and so made mention of it in case
> > > >
> > > > there is still room for a few more engine tweaks while the hood is still open.
> > > >
> > > >
> > > >
> > > > About IPv4, I am currently running IPv4 edge networks with IPv4-in-IPv6 tunnel endpoints
> > > >
> > > > connected to an IPv6 transit network and it works really good. End systems get to use
> > > >
> > > > smaller addresses and smaller headers, and they can talk to remote correspondents using
> > > >
> > > > IPv4 as if they were all on the same IPv4 network. So yes, I think we might still want to
> > > >
> > > > consider IPv4 for edge networks like that.
> > > >
> > > >
> > > >
> > > > About getting 64K packets across, only the edge networks or end systems see them as
> > > >
> > > > large packets; in the core thy are typically broken up into something much smaller by
> > > >
> > > > ingress nodes that apply segmentation/fragmentation. We don’t need the core to move
> > > >
> > > > to jumbo links; we only need that at the edges. ATM taught us that.
> > > >
> > > >
> > > >
> > > > About our “nail”, end systems get to see larger packets/parcels and get to take advantage
> > > >
> > > > of the reduced interrupts and system call overhead they provide. That is what makes it
> > > >
> > > > worthwhile.
> > > >
> > > >
> > > >
> > > > Fred
> > > >
> > > >
> > > >
> > > > From: [e-mail] [mailto:[e-mail]]
> > > > Sent: Saturday, December 18, 2021 8:13 PM
> > > > To: Templin (US), Fred L <[e-mail]>
> > > > Cc: [e-mail]; Wes Eddy <[e-mail]>
> > > > Subject: Re: [Int-area] IP parcels
> > > >
> > > >
> > > >
> > > > 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 <[e-mail]> 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: [e-mail] [mailto:[e-mail]]
> > > > Sent: Saturday, December 18, 2021 4:57 PM
> > > > To: Templin (US), Fred L <[e-mail]>
> > > > Cc: [e-mail]; Wes Eddy <[e-mail]>
> > > > 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
> > > >
> > > >
> > > >
> > > > On Dec 18, 2021, at 4:42 PM, Templin (US), Fred L <[e-mail]> 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/
> > > >
> > > >
> > > >
> > > > Fred
> > > >
> > > >
> > > >
> > > > From: [e-mail] [mailto:[e-mail]]
> > > > Sent: Friday, December 17, 2021 6:01 PM
> > > > To: Templin (US), Fred L <[e-mail]>
> > > > Cc: [e-mail]
> > > > 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
> > > >
> > > >
> > > >
> > > > On Dec 17, 2021, at 5:06 PM, Templin (US), Fred L <[e-mail]> 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:[e-mail]] On Behalf Of [e-mail]
> > > > Sent: Friday, December 17, 2021 5:00 PM
> > > > To: [e-mail]
> > > > 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
> > > > [e-mail]
> > > > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/int-area
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Int-area mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/int-area
> >