Home page logo
/

nanog logo nanog mailing list archives

RE: jumbo frames
From: Lane Patterson <lpatterson () equinix com>
Date: Thu, 31 May 2001 13:47:22 -0700


Has anybody been running PMTU-D scans across networks from a 
4470-connected host?  I would love to see some data.

I have been tracking jumbo frame support trends for a while, and
am reasonably disappointed by lack of standards and vendor willingness
to support jumbos (yes there are very REAL h/w design considerations, 
so until operators demand jumbo support and folks test it in realistic
environments, it's not going to happen).  

Unfortunately, many of the folks most adamant about maintaining 4470
in their core are therefore sticking with POS everywhere, so their 
requirement is not making it to the ether vendors.

There are different reasons to use several different sizing parameters:

        "Mini-jumbo": say 1518, 1540, etc.  the idea here is that you
                can handle stacked tunnels and LAN encapsulations, such
                as stacked headers of 802.1Q, MPLS, IP/GRE tunnels, etc.
                while still preserving "1500 for the edge"

                Applicability:  802.1Q, VPN, MPLS, and other encap-based 
                        or tunnel-based applications

        "Mid-jumbo": say 4470: the idea is to make sure a backbone can
                preserve its MTU across both ethernet, ATM, and POS links
                within its diameter, and conceivably between networks via
                IX's that support jumbos.  This in fact may be critical
                for folks running large ISIS implementations that need 
                to ration # of LSPs:

        
http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-02.txt

                Applicability:
                        -internal:  maintain 4470 for router-router control
                                traffic such as ISIS
                        -external:  allow for customers that use larger MTU,
                                preserve MTU across IX peering points

        "Real jumbo": not standardized, but somewhere between 8100-9100B,
                this is for servers that want to pack GigE links with 
                optimized I/O based on 8K memory chunks, ala the original 
                reasons for Alteon jumbo support.  Of course, need for these

                jumbos is probably still within LAN/MAN scope for the next 
                generation of operational deployment.

                Applicability:
                        -optimizing server thruput by reducing per-packet
                                overhead, and directly mapping data payload
                                to a memory chunk with no "SAR" buffering 
                                function.
                        -scope is LAN/MAN

Cheers,
-Lane

-----Original Message-----
From: Richard A. Steenbergen [mailto:ras () e-gerbil net]
Sent: Wednesday, May 30, 2001 3:05 PM
To: Wayne Bouchard
Cc: Dave Siegel; Tony Hain; nanog () merit edu
Subject: Re: jumbo frames



On Wed, 30 May 2001, Wayne Bouchard wrote:

Well, the way it oughta work is that the backbone uses the 
same MTU as
that of the largest MTU of your endpoints. So, for example, 
you have a
buncha hosts on a fddi ring running at 4470, you want to make sure
those frames don't have to get fragmented inside your 
network. Idealy,
all hosts have the same MTU and no one has to worry about 
that, but in
practice, it seems to be better to push the fragmentation 
as close to
the end user as possible. (That is, if a user on a 1500MTU 
link makes
a request to a host on a 4470 link, the response is 4470 up 
until the
user's end network.) Of course, path MTU discovery makes this a moot
point. The conversation will be held in 1500 byte fragments.

Fortunantly hosts on FDDI rings are rare these days, but I'd 
love to see a
modern analysis of the packet sizes going through the 
internet (everything
I've seen comes from the days when FDDI roamed the earth).

From everything I've seen out of IEEE, they continue to view 
Ethernet as a
"LAN Standard" and don't really want to consider its use in 
the core, even
for 10GigE. As long as the creation of 99.999% of packets is <= 1500
bytes, and the links which pass packets are equal or greater, noting
really nasty happens. The argument is that "most people won't really
benefit from it, and it will introduce incompatibilities in 
MTU size, so
why should it be a standard", which misses the potential use 
in WAN links.

I don't expect to see many hosts w/10GigE cards for a while, 
but it would
be nice if Path MTU Discovery was a bit better.

-- 
Richard A Steenbergen <ras () e-gerbil net>       
http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 
14 36 FE B6)



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]