Re: [Int-area] [EXTERNAL] Re: About draft-templin-intarea-parcels

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

Hi Haoyu - I appreciate your qualifying your message as coming from a researcher's
perspective, but the IETF is about engineering and IP parcels is about engineering.
It is here and now and ready to go - it is not to be put on some research back-burner
that maybe we come back to 20 years from now.

Fred

> -----Original Message-----
> From: Haoyu Song <[e-mail]>
> Sent: Thursday, November 10, 2022 9:04 AM
> To: Templin (US), Fred L <[e-mail]>; Tom Herbert <[e-mail]>
> Cc: [e-mail]
> Subject: RE: [Int-area] [EXTERNAL] Re: About draft-templin-intarea-parcels
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> As a researcher, I'd like to provide  a suggestion. Given its potentially profound impact to the Internet, I think the blind peer reviews for its
> design and evaluation are needed in some top tier research conferences such as SIGCOMM. If it is accepted by the research community, it'll
> also help people here gain confidence on it. The PoC code is a good start, more comprehensive tests using both a simulator and a real
> network setup would be necessary, and the cost/benefit should also be evaluated. A real promising scheme should be able to sustain such
> review (the research community tends to focus more on novelty and feasibility but less on the pragmatic side of a scheme). I believe such
> effort can help clear many doubts here  and then the standardization can be considered as the next step.
> 
> Best regards,
> Haoyu
> 
> -----Original Message-----
> From: Int-area <[e-mail]> On Behalf Of Templin (US), Fred L
> Sent: Thursday, November 10, 2022 4:35 PM
> To: Tom Herbert <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Int-area] [EXTERNAL] Re: About draft-templin-intarea-parcels
> 
> Tom, IP parcels have a very significant difference from the GSO/GRO and others you mentioned in that IP parcels allow a *single* packet to
> contain *multiple* upper layer protocol segments; in all of the other schemes you cited, it is always a single ULP segment per packet. This
> alone demonstrates that IP parcels at the very least provides a significant savings in terms of reduced packet headers, since only a single
> copy of the {TCP,UDP}/IP headers appears and not multiple.
> 
> The maximum IP parcel size is also not constrained by the underlying network path MTU the same way that the maximum GSO/GRO packet
> size is. So, even if the path MTU is only 1500 IP parcels up to 64KB and even larger can be sent over an OMNI interface configured over the
> path. If you did that with GSO, then the packets would arrive at the destination fragmented and as you know in linux GRO cannot apply
> UDP/IP reassembly to packets that have already undergone fragmentation at the sub-IP layer. Yes, you can linearize the packets but the
> second you do that any GRO performance gains are lost.
> 
> You mentioned data centers going to 9KB, and while that is good it is still way smaller than what we should be aiming for. IP parcels will
> encourage links with much larger MTUs - 64KB is just a starting point, and going much larger into multiple MBs can be a near-term goal.
> Yes, IP parcels can take full advantage of 9KB MTUs right away and still be better than the other schemes because larger MTUs at the sub-IP
> layer result in less IPv6 fragmentation and associated savings in sub-IP layer encapsulation overhead.
> 
> IP parcels can be thought of as a gateway to larger MTUs in the Internet without having to compromise integrity and/or without having to
> retransmit lots of big blocks of data if only just one or a couple of bits were damaged in transit. The IP parcels philosophy is to accept as
> much good data as possible while asking for retransmission only of errored data that cannot be locally repaired. This will be good for a vast
> array of bulk-transfer Internetworking applications, not only within the local data center but also across the wide area using OMNI.
> 
> I could go on, but I won't for now. I have done the work, and I have shown the work. The community now needs to apply a check-mark to
> acknowledge.
> 
> Fred
> 
> > -----Original Message-----
> > From: Tom Herbert <[e-mail]>
> > Sent: Wednesday, November 09, 2022 9:22 AM
> > To: Templin (US), Fred L <[e-mail]>
> > Cc: Richard Li <[e-mail]>; [e-mail]
> > Subject: [EXTERNAL] Re: [Int-area] About draft-templin-intarea-parcels
> >
> > EXT email: be mindful of links/attachments.
> >
> >
> >
> > On Wed, Nov 9, 2022 at 7:47 AM Templin (US), Fred L
> > <[e-mail]> wrote:
> > >
> > > Richard, thank you for your message. The intarea community must
> > > understand that
> > >
> > > the live IP Parcels presentation given today was only a "roadmap" to
> > > a proper
> > >
> > > presentation which could not be given due to time constraints. The
> > > charts shown
> > >
> > > during the live presentation were skipped over quickly, but they
> > > provide full
> > >
> > > detail and are permanently available here:
> > >
> > >
> > >
> > >
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> > > tatracker.ietf.org%2Fmeeting%2F115%2Fmaterials%2Fslides-115-intarea-
> > > ip-parcels&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7Cf3d70ea49
> > > 53d4a476cb808dac339892c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> > > C638036949165322831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> > > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
> > > =pEndNpnEOWuQctTp54syiw7zL8%2F%2FFM0ib6P6JTY%2Bri0%3D&amp;reserved=0
> > >
> > >
> > >
> > > Running code is also now permanently available here:
> > >
> > >
> > >
> > >
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > thub.com%2Ffltemplin%2Fip-parcels&amp;data=05%7C01%7Chaoyu.song%40fu
> > > turewei.com%7Cf3d70ea4953d4a476cb808dac339892c%7C0fee8ff2a3b240189c7
> > > 53a1d5591fedc%7C1%7C0%7C638036949165322831%7CUnknown%7CTWFpbGZsb3d8e
> > > yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> > > 3000%7C%7C%7C&amp;sdata=8%2FUkWd1FnslqWOiMO%2FTeOykcI7HoPLYr3eUY9NIJ
> > > zEQ%3D&amp;reserved=0
> > >
> > >
> > >
> > > and provides clear evidence that IP parcels provide an appreciable
> > > performance
> > >
> > > gain which cannot be ignored any longer.
> > >
> > >
> > >
> > > IP parcels are good for the Internet, and the presentation charts
> > > and running code
> > >
> > > provide clear evidence. It is time to adopt IP parcels.
> >
> > Fred,
> >
> > Thanks for the data and implementation, but I'm still not convinced
> > that IP parcels should be adopted. Your data seems to show that when
> > the networking stack processes large segments performance increases
> > (fewer packets to process in the data path is a win). We've known this
> > for a long time and that's why stacks commonly implement various
> > segmentation techniques like GSO/TSO, GRO/LRO, UFO, USO, and more
> > recently BigTCP. Also, within the data center, 9K MTUs are becoming
> > common place which is even better than segmentation with 1500 byte
> > MTU. The major difference between these techniques and IP parcels is
> > that the segmentation techniques don't require any new protocol or
> > changes to an existing protocol, whereas IP parcels requires protocol
> > changes. So in order to justify IP parcels adoption, not just in IETF
> > but also upstreaming into Linux, I think you'll want to show that it
> > has significant benefits over the existing segmentation techniques to
> > justify the complexities and cost of a new protocol.
> >
> > Tom
> >
> > >
> > >
> > >
> > > Fred
> > >
> > >
> > >
> > > From: Int-area <[e-mail]> On Behalf Of Richard Li
> > > Sent: Wednesday, November 09, 2022 6:12 AM
> > > To: [e-mail]
> > > Subject: [Int-area] About draft-templin-intarea-parcels
> > >
> > >
> > >
> > > Hi Chairs and All,
> > >
> > >
> > >
> > > At today's intarea meeting, the chair asked the participants if
> > > anybody has an interest in this draft or not. If nobody is
> > > interested, this draft
> > will be closed, and if anyone is interested, he/she is asked to voice it on the mailing list.
> > >
> > >
> > >
> > > As a follow up, I am expressing my interest in this draft, and would
> > > like to see this draft open and let it go on. A few months ago, I
> > > asked
> > its authors several questions, and the authors answered and clarified
> > them. I do see good values for some use cases, especially for those in
> > broadband access and jumbo frames being used on the links. It seems to me that this draft points to a useful direction, some rooms are
> remaining for expansion though.
> > >
> > >
> > >
> > > Thanks,
> > >
> > >
> > >
> > > Richard
> > >
> > >
> > >
> > > _______________________________________________
> > > Int-area mailing list
> > > [e-mail]
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > > w.ietf.org%2Fmailman%2Flistinfo%2Fint-area&amp;data=05%7C01%7Chaoyu.
> > > song%40futurewei.com%7Cf3d70ea4953d4a476cb808dac339892c%7C0fee8ff2a3
> > > b240189c753a1d5591fedc%7C1%7C0%7C638036949165322831%7CUnknown%7CTWFp
> > > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > > Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ZjlouJMjtalnJWJwi%2Bw0QvEId%2FjYGPw
> > > 21HYupE34M04%3D&amp;reserved=0
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-
> area&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7Cf3d70ea4953d4a476cb808dac339892c%7C0fee8ff2a3b240189c753a1d55
> 91fedc%7C1%7C0%7C638036949165322831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ZjlouJMjtalnJWJwi%2Bw0QvEId%2FjYGPw21HYupE34M04%3D&amp;reserved=0