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-
ay, March 24, 2022 3:08 PM
> To: Joel M. Halpern
> Cc: Templin (US), Fred L ; int-area
>
> Subject: Re: [Int-area] IP Parcels improves performance for end systems
>
> Right, moving the problem does not fix the problem and changes the
> cost/benefit ratio as well.
>
&g
loyed base.
>> Fred
>>> -Original Message-
>>> From: Haoyu Song [mailto:haoyu.s...@futurewei.com]
>>> Sent: Thursday, March 24, 2022 1:42 PM
>>> To: Templin (US), Fred L ; Joel M. Halpern
>>>
>>> Cc: int-area
>>> Subject
, March 24, 2022 1:42 PM
To: Templin (US), Fred L ; Joel M. Halpern
Cc: int-area
Subject: RE: [Int-area] IP Parcels improves performance for end systems
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
> -Original Message-
> From: Haoyu Song [mailto:haoyu.s...@futurewei.com]
> Sent: Thursday, March 24, 2022 1:42 PM
> To: Templin (US), Fred L ; Joel M. Halpern
>
> Cc: int-area
> Subject: RE: [Int-area] IP Parcels improves performance for end systems
>
> Understood.
:j...@joelhalpern.com]
> Sent: Thursday, March 24, 2022 1:38 PM
> To: Templin (US), Fred L
> Cc: int-area
> Subject: Re: [Int-area] IP Parcels improves performance for end systems
>
> I understood that. I just don't see the benefit.
>
> We have a host. It is assembl
: Templin (US), Fred L
Sent: Thursday, March 24, 2022 1:12 PM
To: Haoyu Song ; Joel M. Halpern
Cc: int-area
Subject: RE: [Int-area] IP Parcels improves performance for end systems
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
ay, March 24, 2022 12:27 PM
> To: Joel M. Halpern ; Templin (US), Fred L
>
> Cc: int-area
> Subject: [EXTERNAL] RE: [Int-area] IP Parcels improves performance for end
> systems
>
> EXT email: be mindful of links/attachments.
>
>
>
> I have the similar concern
iding enough benefit to justify the work.
>
>
> Yours,
> Joel
>
> On 3/24/2022 3:05 PM, Templin (US), Fred L wrote:
> > Hi Joel,
> >
> >> -Original Message-
> >> From: Joel M. Halpern [mailto:j...@joelhalpern.com]
> >> Sent: Thursday, Marc
lpern [mailto:j...@joelhalpern.com]
Sent: Thursday, March 24, 2022 12:11 PM
To: Templin (US), Fred L
Cc: int-area
Subject: [EXTERNAL] Re: [Int-area] IP Parcels improves performance for end
systems
EXT email: be mindful of links/attachments.
I do remember token ring. (I was working from 1983 for folk
functions. Do we really want to
optimize the host and complicate the network?
Best regards,
Haoyu
-Original Message-
From: Int-area On Behalf Of Joel M. Halpern
Sent: Thursday, March 24, 2022 11:41 AM
To: Templin (US), Fred L
Cc: int-area
Subject: Re: [Int-area] IP Parcels improves
til 1986.
Fred
> -Original Message-
> From: Joel M. Halpern [mailto:j...@joelhalpern.com]
> Sent: Thursday, March 24, 2022 12:11 PM
> To: Templin (US), Fred L
> Cc: int-area
> Subject: [EXTERNAL] Re: [Int-area] IP Parcels improves performance for end
> systems
>
>
: Thursday, March 24, 2022 9:45 AM
To: Tom Herbert
Cc: int-area ; Eggert, Lars ;
l...@eggert.org
Subject: Re: [Int-area] IP Parcels improves performance for end systems
Hi Tom - responses below:
-Original Message-
From: Tom Herbert [mailto:t...@herbertland.com]
Sent: Thursday, March 24,
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 s
-area-boun...@ietf.org] On Behalf Of Templin (US),
Fred L
Sent: Thursday, March 24, 2022 9:45 AM
To: Tom Herbert
Cc: int-area ; Eggert, Lars ;
l...@eggert.org
Subject: Re: [Int-area] IP Parcels improves performance for end systems
Hi Tom - responses below:
-Original Message-
From: T
-Original Message-
> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Templin (US),
> Fred L
> Sent: Thursday, March 24, 2022 9:45 AM
> To: Tom Herbert
> Cc: int-area ; Eggert, Lars ;
> l...@eggert.org
> Subject: Re: [Int-area] IP Parcels improves performance fo
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 improve
es
>
> all of these points, and can be made into a standard.
Huh? GRO/GSO works perfectly fine with IPV6.
Tom
>
>
> Fred
>
>
>
> From: Tom Herbert [mailto:t...@herbertland.com]
> Sent: Wednesday, March 23, 2022 9:37 AM
> To: Templin (US), Fred L
> Cc: Egge
AM
To: Templin (US), Fred L
Cc: Eggert, Lars ; int-area ;
l...@eggert.org
Subject: Re: [EXTERNAL] Re: [Int-area] IP Parcels improves performance for end
systems
EXT email: be mindful of links/attachments.
On Wed, Mar 23, 2022, 9:54 AM Templin (US), Fred L
mailto:fred.l.temp...@boeing.c
ars ; int-area@ietf.org
> > Subject: Re: [Int-area] IP Parcels improves performance for end systems
> >
> > On Tue, Mar 22, 2022 at 7:42 AM Templin (US), Fred L
> > wrote:
> > >
> > > Lars, I did a poor job of answering your question. One of the most
> &g
Thanks for these thoughts, Herbie, and see below for follow-up:
Fred
> -Original Message-
> From: Robinson, Herbie [mailto:herbie.robin...@stratus.com]
> Sent: Tuesday, March 22, 2022 12:58 PM
> To: Templin (US), Fred L ; int-area@ietf.org
> Subject: RE: IP Parcels improves performance fo
I think this is a really good idea; although, it could be a bridge too far. It
certainly won’t get implemented quickly. I still remember implementing path
MTU discovery thinking about the big performance win I was going to get in IPv6
from 9K packets (vs 1500 byte packets) only to discover tha
Tom, see below:
> -Original Message-
> From: Tom Herbert [mailto:t...@herbertland.com]
> Sent: Tuesday, March 22, 2022 10:00 AM
> To: Templin (US), Fred L
> Cc: Eggert, Lars ; int-area@ietf.org
> Subject: Re: [Int-area] IP Parcels improves performance for end systems
&
On Tue, Mar 22, 2022 at 7:42 AM Templin (US), Fred L
wrote:
>
> Lars, I did a poor job of answering your question. One of the most important
> aspects of
>
> IP Parcels in relation to TSO and GSO/GRO is that transports get to use a
> full 4MB buffer
>
> instead of the 64KB limit in current pract
For those who have been tracking the IP Parcels discussion, please have another
look
at the document. There is now a section on "Parcel Path Qualification" that I
think
satisfies the incremental deployment issue - but, I am interested in your
comments.
Fred
nk?
>
> Fred
>
> > -Original Message-
> > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Templin
> > (US), Fred L
> > Sent: Wednesday, February 02, 2022 9:58 AM
> > To: Toerless Eckert
> > Cc: int-area@ietf.org
> > Subject
On Wed, Feb 02, 2022 at 05:58:04PM +, Templin (US), Fred L wrote:
> There are benefits for all three of the source host, network path and
> destination
> host if a parcel can be sent - even if the network path includes other links
> besides
> just an OMNI link. But, I don't think the source h
ent: Wednesday, February 02, 2022 9:58 AM
> To: Toerless Eckert
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] IP parcels
>
> Toerless, if we want the IP parcel concept to apply only for OMNI links then I
> agree that we should take it up only in that document. But, if we wan
Toerless, if we want the IP parcel concept to apply only for OMNI links then I
agree that we should take it up only in that document. But, if we want it to
apply
for all links then we also need a standalone document that updates RFC2675
since we are changing some rules associated with the Jumbo Pa
Fred,
Section 5 of draft-templin-intarea-parcels-06 reads as if there is a mandatory
dependency against draft-templin-6man-omni.
Q1: Is that true ? If not, then i must be overlooking a description how parcels
would work
in the absence of OMNI.
Q2: If there is this dependency, how do you think
On Thu, Jan 27, 2022 at 3:43 PM to...@strayalpha.com
wrote:
>
> Hi, Tom,
>
> > On Jan 27, 2022, at 2:46 PM, Tom Herbert wrote:
> >
> > On Thu, Jan 27, 2022 at 2:17 PM to...@strayalpha.com
> > wrote:
> >>
> >> FWIW, GRO/GSO give no end of headaches to the idea of new TCP options,
> >> esp. the c
Ease up, Joe - just ease up.
> -Original Message-
> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of
> to...@strayalpha.com
> Sent: Thursday, January 27, 2022 3:44 PM
> To: Tom Herbert
> Cc: int-area@ietf.org
> Subject: [EXTERNAL] Re: [Int-area] IP p
Hi, Tom,
> On Jan 27, 2022, at 2:46 PM, Tom Herbert wrote:
>
> On Thu, Jan 27, 2022 at 2:17 PM to...@strayalpha.com
> wrote:
>>
>> FWIW, GRO/GSO give no end of headaches to the idea of new TCP options, esp.
>> the current ones to extend option space after the SYN
>> (draft-ietf-tcpm-tcp-edo)
You know, this all stems back to the "qe reset" bug - do you all remember that?
Tom might, as a former Sun guy - Bob Hinden maybe too. Or maybe that was even
before your time? I think a guy named Rusty Young helped us diagnose it. Anyone
remember him?
___
On Thu, Jan 27, 2022 at 2:17 PM to...@strayalpha.com
wrote:
>
> FWIW, GRO/GSO give no end of headaches to the idea of new TCP options, esp.
> the current ones to extend option space after the SYN
> (draft-ietf-tcpm-tcp-edo).
GRO and GSO are software implementations and in most deployments
>
> A
FWIW, GRO/GSO give no end of headaches to the idea of new TCP options, esp. the
current ones to extend option space after the SYN (draft-ietf-tcpm-tcp-edo).
Although I appreciate their zeal for optimization, implementers of GRO/GSO
still need to play by the rules of TCP and UDP. It’s not clear t
Hi Folks,
Thanks Christian for explaining how GSO/GRO are used by Quic
implementations. So the use is not mandated in Quic RFCs but rather used in
implementations.
I found this presentation by Intel:
https://www.dpdk.org/wp-content/uploads/sites/35/2018/06/GRO-GSO-Libraries-Bring-Significant-Perf
On 12/20/2021 10:03 AM, Templin (US), Fred L wrote:
Tom, sorry I will try to use my words more carefully; I am using GSO/GRO also
for
a UDP-based transport protocol – not QUIC but something similar. I like GSO/GRO
very much; I am glad the service is available and I want to see it continue.
But
> >
> > > >
> > > >
> > > > - You still haven’t shown any evidence that end systems need to do all
> > > > this extra work so they can somehow run faster, nor that this
> will
> > > be noticeably faster than large (i.e., 20-60KB) IPv4
2021 9:20 AM
> > > To: Templin (US), Fred L
> > > Cc: to...@strayalpha.com; int-area@ietf.org
> > > Subject: Re: [Int-area] [EXTERNAL] Re: IP parcels
> > >
> > >
> > >
> > > The world is not just TCP anymore. QUIC and other UDP-bas
effect. These are widely deployed with TCP, TSO works well to
> offload transmit, LRO is defined and is in much better shape to
> offload RX now that programmable devices are emerging. For TCP it's hard to
> see how IP parcels would help significantly, but even for UDP
> we now ha
le bunch of implications like middleboxes are no
> longer work conserving and seems to have the implicit requirement that it has
> to be in the path of every packet in a parcel (i.e. even in the case of the
> last hop performing reassembly. Also, as simply a matter of resources and
> c
This idea has been used in ethernet backplanes (as well as cell based) in
switches/routers. The term is frequenty referred to as "super framing" and has
been for at least 20 years.
Maybe a suggestion of "super-packet" would be more appropriate.
The idea works well in short/higher-reliability p
Thank you, Alex - have a great holiday!
Fred
> -Original Message-
> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Alexandre
> Petrescu
> Sent: Tuesday, December 21, 2021 7:03 AM
> To: int-area@ietf.org
> Subject: Re: [Int-area] IP parcels
>
> Th
The title and abstract are great.
About the title, just one little note. This word 'parcel' is very well
adapted and suggestive for an English speaker. I think I heard it very
well in US English, even though not sure about UK English - to they also
use 'parcel' to mean a package sent in mail?
> Tom, reading your message makes me think you have not read my drafts. The
> answers to the perceived issues you are raising are all there. I do not see
> anything
> new in what you are saying to make me believe otherwise.
So there is a lot of email on this list where folks reference documents (
trayalpha.com<mailto:to...@strayalpha.com>
[mailto:to...@strayalpha.com<mailto:to...@strayalpha.com>]
Sent: Sunday, December 19, 2021 11:53 AM
To: Templin (US), Fred L
mailto:fred.l.temp...@boeing.com>>
Cc: int-area@ietf.org<mailto:int-area@ietf.org>; Wes Eddy
s
> get to use
>
> smaller addresses and smaller headers, and they can talk to remote
> correspondents using
>
> IPv4 as if they were all on the same IPv4 network. So yes, I think we
> might still want to
>
> consider IPv4 for edge networks like that.
>
>
>
&g
emp...@boeing.com>>
Cc: int-area@ietf.org<mailto:int-area@ietf.org>; Wes Eddy
mailto:w...@mti-systems.com>>
Subject: Re: [Int-area] IP parcels
Hi, Fred (et al.),
On Dec 19, 2021, at 10:21 AM, Templin (US), Fred L
mailto:fred.l.temp...@boeing.com>> wrote:
Joe, your insistence
aturday, December 18, 2021
8:13 PM *To:*Templin (US), Fred L <mailto:fred.l.temp...@boeing.com>> *Cc:*int-area@ietf.org
<mailto:int-area@ietf.org>; Wes Eddy <mailto:w...@mti-systems.com>> *Subject:*Re: [Int-area] IP parcels
HI, Fred, If you have one segment that’s less than
I don't readily see that having intermediate devices perform
> reassembly would be a win for hosts, and even if it were, host
> implementations still would need the capability to perform reassembly
> themselves since they will never rely on the network to always do it for
> them.
>
&
om>>
Cc: int-area@ietf.org<mailto:int-area@ietf.org>; Wes Eddy
mailto:w...@mti-systems.com>>
Subject: Re: [Int-area] IP parcels
Hi, Fred (et al.),
On Dec 19, 2021, at 10:21 AM, Templin (US), Fred L
mailto:fred.l.temp...@boeing.com>> wrote:
Joe, your insistence on using
e reduced interrupts and system call overhead they provide. That is what
> makes it
> worthwhile.
>
> Fred
>
> From: to...@strayalpha.com <mailto:to...@strayalpha.com>
> [mailto:to...@strayalpha.com <mailto:to...@strayalpha.com>]
> Sent: Saturday, December 18,
, December 18, 2021 8:13 PM
To: Templin (US), Fred L
Cc: int-area@ietf.org; Wes Eddy
Subject: Re: [Int-area] IP parcels
HI, Fred,
If you have one segment that’s less than 64K, you don’t need the parcel option
at all.
If you have something longer than 64K, either as a single segment or multiple
a@ietf.org <mailto:int-area@ietf.org>; Wes Eddy
> mailto:w...@mti-systems.com>>
> Subject: [EXTERNAL] Re: [Int-area] IP parcels
>
> EXT email: be mindful of links/attachments.
>
>
> Hi, Fred,
>
> Regarding 793bis, new ideas are out of scope. It’s suppo
(US), Fred L
Cc: int-area@ietf.org; Wes Eddy
Subject: [EXTERNAL] Re: [Int-area] IP parcels
EXT email: be mindful of links/attachments.
Hi, Fred,
Regarding 793bis, new ideas are out of scope. It’s supposed to be a roll-in of
existing items only.
Nevermind the problems below, which “TCP will
t; [mailto:to...@strayalpha.com <mailto:to...@strayalpha.com>]
> Sent: Friday, December 17, 2021 6:01 PM
> To: Templin (US), Fred L <mailto:fred.l.temp...@boeing.com>>
> Cc: int-area@ietf.org <mailto:int-area@ietf.org>
> Subject: Re: [Int-area] IP parcels
>
...@strayalpha.com [mailto:to...@strayalpha.com]
Sent: Friday, December 17, 2021 6:01 PM
To: Templin (US), Fred L
Cc: int-area@ietf.org
Subject: Re: [Int-area] IP parcels
Hi, Fred,
I’m first concerned at the use of an IP option at all, due to the problems with
*any* options forcing processing to slow-path
rday, 18 December 2021 at 03:01
To: "Templin (US), Fred L"
Cc: "int-area@ietf.org"
Subject: Re: [Int-area] IP parcels
Hi, Fred,
I’m first concerned at the use of an IP option at all, due to the problems with
*any* options forcing processing to slow-path.
From TCP’s v
Hi, Fred,
I’m first concerned at the use of an IP option at all, due to the problems with
*any* options forcing processing to slow-path.
From TCP’s viewpoint, it seems like you’ve just created a nightmare for SACK
and ECN, basically because you will encourage drops of large bursts of packets.
60 matches
Mail list logo
