Re: [Int-area] About draft-templin-intarea-parcels
Tom, let me say another word about "research" continuing on from the previous
post.
Large packet research really began in the 1980's with FDDI, which is where we
got the
artificial 9KB limit we are experiencing with modern Ethernet. The FDDI
research proved
that ~9KB was the safety limit above which CRC-32 could not be depended upon to
adequately catch all bit error combinations, and we still see that affecting
our selection
in interface MTUs today. After FDDI, ATM and HiPPI research in the 1990's took
large
packet investigations a further step. Then, beginning in the late 1990's and
continuing
to the present day is when my investigation into large MTUs began to take
shape. I have
compiled a large body of publications over the years which can be easily found
by
googling my name, and I have also compiled a large body of RFCs and expired
Internet
Drafts that shaped what has now become AERO/OMNI and IP parcels. Countless ideas
have been tried and discarded, and what has remained in the end is IP parcels.
IP
parcels is therefore not the *beginning* of a decades-long research initiative;
rather,
it is the *end result* of a decades-long research initiative. It is what is
left over after
everything else imaginable has been tried.
Let me say a word further about the 9KB limit - the technique of applying a
CRC-32
check at the receiver and discarding the packet if the CRC is incorrect is a
20th-century
limitation that we need to move beyond in order to grow the Internet into the
21st
century. We need to equip receivers with materials they can use to *repair*
large
packets with errors instead of discarding them. For this, decades worth of
research
and engineering in Forward Error Correction have produced results that we can
now
begin applying to large-MTU links. And, this fits perfectly with IP parcels
which can
apply much more fine-grained integrity assurance than is possible for singleton
large
packets. With IP parcels, isolated bit errors do not invalidate the entire
packet; rather
the vast majority of good materials in the packet can be salvaged and only the
errored
portions need be retransmitted if they cannot be repaired locally. It is the
only sane
way to move the Internet forward into the next millennium.
So again, IP parcels is more about a massive amount of work that has already
been
done much moreso than a massive amount of work still left to do. We have been at
this for decades and it is time to put all of that work into operational
practice.
Fred
> -Original Message-
> From: Tom Herbert
> Sent: Thursday, November 10, 2022 10:22 AM
> To: Templin (US), Fred L
> Cc: Richard Li ; int-area@ietf.org
> Subject: Re: [EXTERNAL] Re: [Int-area] About draft-templin-intarea-parcels
>
> EXT email: be mindful of links/attachments.
>
>
>
> On Thu, Nov 10, 2022 at 8:34 AM Templin (US), Fred L
> wrote:
> >
> > 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 t
Re: [Int-area] About draft-templin-intarea-parcels
On Wed, Nov 9, 2022 at 7:47 AM Templin (US), Fred L 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://datatracker.ietf.org/meeting/115/materials/slides-115-intarea-ip-parcels > > > > Running code is also now permanently available here: > > > > https://github.com/fltemplin/ip-parcels > > > > 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 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://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] About draft-templin-intarea-parcels
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://datatracker.ietf.org/meeting/115/materials/slides-115-intarea-ip-parcels Running code is also now permanently available here: https://github.com/fltemplin/ip-parcels 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 From: Int-area 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://www.ietf.org/mailman/listinfo/int-area
[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://www.ietf.org/mailman/listinfo/int-area
