[36966] in North American Network Operators' Group
RE: jumbo frames
daemon@ATHENA.MIT.EDU (Rowland, Alan D)
Fri Apr 27 11:57:32 2001
Message-ID: <1BEE67ADF602D3119F9A0008C79174C70EC86C84@PETRIFIED>
From: "Rowland, Alan D" <alan_r1@corp.earthlink.net>
To: 'Kurt Kayser' <kurt@noris.de>, Tony Hain <alh-ietf@tndh.net>
Cc: Roeland Meyer <rmeyer@mhsc.com>,
John Fraizer <nanog@Overkill.EnterZone.Net>,
Paul Lantinga <prl@q9.com>, nanog@merit.edu
Date: Fri, 27 Apr 2001 08:44:30 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: owner-nanog-outgoing@merit.edu
I am not an EE but maybe if you rephrased the question as
Which is greater, the cpu cycles to assemble/dissemble jumbo frames or =
the
additional cycles/bandwidth of more numerous ACK packets?
Then again, I may be way out of my depth here.
-Al
-----Original Message-----
From: Kurt Kayser [mailto:kurt@noris.de]
Sent: Friday, April 27, 2001 8:07 AM
To: Tony Hain
Cc: Roeland Meyer; John Fraizer; Paul Lantinga; nanog@merit.edu
Subject: Re: jumbo frames
Hi,
Isn't it a lot more cpu-intensive to 'collect' some 1500-byte frames
into some larger bucket, reassemble it into a jumbo-frame when the next
box has to chop it in order to send it out on a Sonet/PPP/etc interface
which=20
might have a smaller MTU again?
Doesn't make too much sense to me. I guess that was Tony's aim as =
well..
Kurt
=20
> Roeland you are talking about jumbo frames from the end system lan, =
while
> John is talking about only using the jumbo frames between the =
routers. My
> point was that in John's environment the packets will all be 1500 =
since
the
> packets are restricted to that size just to get to the router with =
the GE
> interface. I understand that there are perf gains as long as the =
entire
path
> supports the larger packets, but I don't understand the claim that =
having
a
> bigger pipe in the middle helps.
>=20
> Tony
>=20
--=20
noris network AG * tel +49 911 93 52-0 * internet
Kilianstra=DFe 142 * fax +49 911 93 52-100 * solution
90425 N=FCrnberg * http://www.noris.net * provider
