On Wed, Mar 23, 2022 at 10:47 AM Templin (US), Fred L
wrote:
>
> Tom, looks like you have switched over to HTML which can be a real
> conversation-killer.
>
> But, to some points you raised that require a response:
>
> >You can't turn it off UDP checksums for IPv6 (except for narrow case of
> >e
Tom - see below:
> -Original Message-
> From: Tom Herbert [mailto:t...@herbertland.com]
> Sent: Thursday, March 24, 2022 6:22 AM
> To: Templin (US), Fred L
> Cc: Eggert, Lars ; int-area ;
> l...@eggert.org
> Subject: Re: [Int-area] IP Parcels improves performance for end systems
>
> On
Luigi, I did an equally poor job addressing your question. The deployment model
for
IP Parcel-capable links begins at the extreme network edges; not in the network
core.
The core network can continue to function as it always has with whatever link
MTUs
are already in place, and the OMNI link ove
Hi All,
There has been a lot of discussion about potential changes to Internet
addressing schemes on this list recently. We have organised a SIGCOMM 2022
workshop covering several topics related to these discussions. The workshop
CFP may be found here:
1st ACM SIGCOMM Workshop on Future of Int
On Thu, Mar 24, 2022 at 7:27 AM Templin (US), Fred L
wrote:
>
> Tom - see below:
>
> > -Original Message-
> > From: Tom Herbert [mailto:t...@herbertland.com]
> > Sent: Thursday, March 24, 2022 6:22 AM
> > To: Templin (US), Fred L
> > Cc: Eggert, Lars ; int-area ;
> > l...@eggert.org
> >
Hi Tom - responses below:
> -Original Message-
> From: Tom Herbert [mailto:t...@herbertland.com]
> Sent: Thursday, March 24, 2022 9:09 AM
> To: Templin (US), Fred L
> Cc: Eggert, Lars ; int-area ;
> l...@eggert.org
> Subject: Re: [Int-area] IP Parcels improves performance for end systems
Tom, I missed this from your previous message:
> > Actually, my assertion wasn't good to begin with because for IPv6 even if
> > UDP
> > checksums are turned off the OMNI encapsulation layer includes a checksum
> > that ensures the integrity of the IPv6 header. UDP checksums off for IPv6
> > whe
> The category 1) links are not yet in existence, but once parcels start to
> enter the mainstream innovation will drive the creation of new kinds of
> data links (1TB Ethernet?) that will be rolled out as new hardware.
I want to put a gold star next to the above. AFAICT, pushing the MTU and
imple
This exchange seems to assume facts not in evidence.
And the whole premise is spending resources in other parts of the
network for a marginal diminishing return in the hosts.
It simply does not add up.
Yours,
Joel
On 3/24/2022 2:19 PM, Templin (US), Fred L wrote:
The category 1) links are n
Hi Joel,
> -Original Message-
> From: Joel M. Halpern [mailto:j...@joelhalpern.com]
> Sent: Thursday, March 24, 2022 11:41 AM
> To: Templin (US), Fred L
> Cc: int-area
> Subject: Re: [Int-area] IP Parcels improves performance for end systems
>
> This exchange seems to assume facts not i
I do remember token ring. (I was working from 1983 for folks who
delivered 50 megabits starting in 1976, and built some of the best FDDI
around at the time.)
I am not claiming that increasing the MTU from 1500 to 9K did nothing.
I am claiming that diminishing returns has distinctly set in.
If
Joel, I can demonstrate today (and have documented) that some ULPs see dramatic
increases in performance proportional to the ULP segment sizes they use. This
is true
when the ULP segments are encapsulated and fragmented, and so must also be true
when they can be sent over the wire in once piece ov
I have the similar concern. The IP parcels make me worried about the buffer and
scheduling for those huge parcels in network routers (the buffer size over
bandwidth ratio is becoming smaller and smaller, the packet loss/reorder could
happen after parcel break in the network, the parcel assembly
I will observe that if one is sending a very large set of data, one
needs to assemble that very large set of data. I have trouble
constructing a situation in which is better to spend all the time
assembling it, and then start sending data once it is all assembled.
Send it in pieces. I suppose
On Thu, Mar 24, 2022, 3:11 PM Joel M. Halpern wrote:
> I do remember token ring. (I was working from 1983 for folks who
> delivered 50 megabits starting in 1976, and built some of the best FDDI
> around at the time.)
>
> I am not claiming that increasing the MTU from 1500 to 9K did nothing.
> I
Hi, no it is not the case that routers deep within the network will be asked to
forward jumbos - that is not what we are after. Routers in the core will
continue
to forward common-sized IP packets the way they have always done - nothing
within that realm needs to change.
Where parcels will have a
Joel, what you may be missing is that we are introducing a new layer in
the Internet architecture known as the Adaptation Layer - that layer that
logically resides between L3 and L2. Remember AAL5? it is kind of like that,
except over heterogeneous Internetworks instead of over a switched fabric
wi
I understood that. I just don't see the benefit.
We have a host. It is assembling data to send. It is doing so
progressively.
It can either send in nice sized pieces (9K? 64K) as it has the data and
everything flows so that the receiver can process the data in pieces.
Or it can wait until
Understood. But some router or whatever will need to do the parcel break and
assembly anyway. In high speed network, this is much more challenging than at
the host, due to the buffer, scheduling, packet loss, out-of-order issues
mentioned earlier.
Haoyu
-Original Message-
From: Templi
Joel, to continue to argue only the MTU aspects of having an Adaptation Layer
loses sight of the fact that it is about much more than just that. The
Adaptation
Layer gives the "6M's of Modern Internetworking" including Multilink, Multinet,
Mobility, Multicast, Multihop and MTU determination. How a
Again, expect the breaking/reassembling to happen mostly near the edges of the
network.
And, not necessarily on dedicated router platforms (in fact, probably not on
dedicated
router platforms). Implications of loss at the IP fragment level are discussed
in my
recent APNIC article:
https://blog.
Fundamentally Fred, by not having the host send things in timely pieces
you have created work. Having some other platform do that work does not
mean it does not need to get done. It still does. And since getting
such big pieces costs latency, I can not see how the savings in I/O
operations a
Right, moving the problem does not fix the problem and changes the cost/benefit
ratio as well.
Dino
> On Mar 24, 2022, at 2:30 PM, Joel M. Halpern wrote:
>
> Fundamentally Fred, by not having the host send things in timely pieces you
> have created work. Having some other platform do that wo
In addition to what has been said on the list here (which is substantial) folks
should
watch for my article series on the APNIC blog. The first article is here, and
there will
be several more to follow:
https://blog.apnic.net/2022/02/18/omni-an-adaptation-layer-for-the-internet/
This is Interne
I have general sympathy for things that would improve the ability of end
nodes to send larger packet sizes. As LAN and WAN speeds rise, latency
goes down since each packet takes less time on the medium, but packet
processing overhead goes up, since you must be able to receive 10x as
many existing-
25 matches
Mail list logo
