At this point, I don't see IP parcels as being a significant benefit to host performance which, as I understand it, is the primary motivation. While it's an interesting idea, I don't support adoption.
A recent patch to the Linux kernel allows for GSO/GRO segments greater than 64K, using RFC2675 Jumbograms to reassemble so those limitations which were discussed on the list have been addressed in implementation. There is a nice writeup in https://lwn.net/Articles/884104/. As Joel mentions moving any sort of reassembly into network devices is complex and problematic. For instance, if a middebox is trying to perform reassembly of packets for a flow not addressed to it, it's implicitly requiring that all packets of the flow that go through the device perform reassembly which is contrary to the end-to-end model. Also, if reassembly requires buffering of messages then that creates a memory requirement on middleboxes; hosts are in a better position to do reassembly since they are only providing the service for themselves as opposed to some number of devices behind a middlebox. Tom On Wed, Jun 22, 2022 at 12:25 PM Juan Carlos Zuniga (juzuniga) <juzuniga= 40cisco....@dmarc.ietf.org> wrote: > Dear IntArea WG, > > > > We are starting a 2-week call for adoption of the IP-Parcels draft: > > https://www.ietf.org/archive/id/draft-templin-intarea-parcels-10.html > > > > The document has been discussed for some time and it has received multiple > comments. > > > > If you have an opinion on whether this document should be adopted by the > IntArea WG please indicate it on the list by the end of Wednesday July 6th > . > > > > Thanks, > > > > Juan-Carlos & Wassim > > (IntArea WG chairs) > > > _______________________________________________ > 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
