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%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638036949165322831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%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
