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:t...@herbertland.com] > Sent: Tuesday, December 21, 2021 1:52 PM > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > Cc: to...@strayalpha.com; int-area@ietf.org > 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 > <fred.l.temp...@boeing.com> 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:t...@herbertland.com] > > > Sent: Tuesday, December 21, 2021 10:01 AM > > > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > > > Cc: to...@strayalpha.com; int-area@ietf.org > > > Subject: Re: IP parcels > > > > > > On Tue, Dec 21, 2021 at 6:24 AM Templin (US), Fred L > > > <fred.l.temp...@boeing.com> 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:t...@herbertland.com] > > > > Sent: Monday, December 20, 2021 4:14 PM > > > > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > > > > Cc: to...@strayalpha.com; int-area@ietf.org > > > > Subject: Re: IP parcels > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Dec 20, 2021 at 3:11 PM Templin (US), Fred L > > > > <fred.l.temp...@boeing.com> 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:t...@herbertland.com] > > > > Sent: Monday, December 20, 2021 1:06 PM > > > > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > > > > Cc: to...@strayalpha.com; int-area@ietf.org > > > > Subject: Re: IP parcels > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Dec 20, 2021 at 12:03 PM Templin (US), Fred L > > > > <fred.l.temp...@boeing.com> 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:t...@herbertland.com] > > > > Sent: Monday, December 20, 2021 9:20 AM > > > > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > > > > Cc: to...@strayalpha.com; int-area@ietf.org > > > > 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: to...@strayalpha.com [mailto:to...@strayalpha.com] > > > > Sent: Sunday, December 19, 2021 11:53 AM > > > > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > > > > Cc: int-area@ietf.org; Wes Eddy <w...@mti-systems.com> > > > > Subject: Re: [Int-area] IP parcels > > > > > > > > > > > > > > > > Hi, Fred (et al.), > > > > > > > > > > > > > > > > On Dec 19, 2021, at 10:21 AM, Templin (US), Fred L > > > > <fred.l.temp...@boeing.com> 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: to...@strayalpha.com [mailto:to...@strayalpha.com] > > > > Sent: Saturday, December 18, 2021 8:13 PM > > > > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > > > > Cc: int-area@ietf.org; Wes Eddy <w...@mti-systems.com> > > > > 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 > > > > <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] > > > > Sent: Saturday, December 18, 2021 4:57 PM > > > > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > > > > Cc: int-area@ietf.org; Wes Eddy <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 > > > > > > > > > > > > > > > > On Dec 18, 2021, at 4:42 PM, Templin (US), Fred L > > > > <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/ > > > > > > > > > > > > > > > > Fred > > > > > > > > > > > > > > > > From: 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> > > > > Cc: 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 > > > > > > > > > > > > > > > > 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 > > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
