[36962] in North American Network Operators' Group
Re: jumbo frames
daemon@ATHENA.MIT.EDU (Kurt Kayser)
Fri Apr 27 11:18:13 2001
Date: Fri, 27 Apr 2001 17:06:58 +0200
From: Kurt Kayser <kurt@noris.de>
To: "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>
Message-ID: <20010427170658.X11588@noris.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <IEEOIFENFHDKFJFILDAHMEMMCGAA.alh-ietf@tndh.net>; from alh-ietf@tndh.net on Thu, Apr 26, 2001 at 12:54:48PM -0700
Errors-To: owner-nanog-outgoing@merit.edu
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
might have a smaller MTU again?
Doesn't make too much sense to me. I guess that was Tony's aim as well..
Kurt
> 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.
>
> Tony
>
--
noris network AG * tel +49 911 93 52-0 * internet
Kilianstraße 142 * fax +49 911 93 52-100 * solution
90425 Nürnberg * http://www.noris.net * provider
