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 <haoyu.s...@futurewei.com>
> Sent: Thursday, November 10, 2022 9:04 AM
> To: Templin (US), Fred L <fred.l.temp...@boeing.com>; Tom Herbert
> <t...@herbertland.com>
> Cc: int-area@ietf.org
> 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 <int-area-boun...@ietf.org> On Behalf Of Templin (US), Fred L
> Sent: Thursday, November 10, 2022 4:35 PM
> To: Tom Herbert <t...@herbertland.com>
> Cc: int-area@ietf.org
> 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 <t...@herbertland.com>
> > Sent: Wednesday, November 09, 2022 9:22 AM
> > To: Templin (US), Fred L <fred.l.temp...@boeing.com>
> > Cc: Richard Li <richard...@futurewei.com>; int-area@ietf.org
> > 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
> > <fred.l.temp...@boeing.com> 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&data=05%7C01%7Chaoyu.song%40futurewei.com%7Cf3d70ea49
> > > 53d4a476cb808dac339892c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> > > C638036949165322831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> > > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
> > > =pEndNpnEOWuQctTp54syiw7zL8%2F%2FFM0ib6P6JTY%2Bri0%3D&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&data=05%7C01%7Chaoyu.song%40fu
> > > turewei.com%7Cf3d70ea4953d4a476cb808dac339892c%7C0fee8ff2a3b240189c7
> > > 53a1d5591fedc%7C1%7C0%7C638036949165322831%7CUnknown%7CTWFpbGZsb3d8e
> > > yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> > > 3000%7C%7C%7C&sdata=8%2FUkWd1FnslqWOiMO%2FTeOykcI7HoPLYr3eUY9NIJ
> > > zEQ%3D&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 <int-area-boun...@ietf.org> On Behalf Of Richard Li
> > > Sent: Wednesday, November 09, 2022 6:12 AM
> > > To: int-area@ietf.org
> > > 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
> > > Int-area@ietf.org
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > > w.ietf.org%2Fmailman%2Flistinfo%2Fint-area&data=05%7C01%7Chaoyu.
> > > song%40futurewei.com%7Cf3d70ea4953d4a476cb808dac339892c%7C0fee8ff2a3
> > > b240189c753a1d5591fedc%7C1%7C0%7C638036949165322831%7CUnknown%7CTWFp
> > > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > > Mn0%3D%7C3000%7C%7C%7C&sdata=ZjlouJMjtalnJWJwi%2Bw0QvEId%2FjYGPw
> > > 21HYupE34M04%3D&reserved=0
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-
> area&data=05%7C01%7Chaoyu.song%40futurewei.com%7Cf3d70ea4953d4a476cb808dac339892c%7C0fee8ff2a3b240189c753a1d55
> 91fedc%7C1%7C0%7C638036949165322831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZjlouJMjtalnJWJwi%2Bw0QvEId%2FjYGPw21HYupE34M04%3D&reserved=0
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
