Subject: RE: Reopening jumbo frames in IS-IS

From: "Crouch, Alan" <[email-masked]>
Date: Sun, 24 Jul 2005 11:37:18 -0700

There are multiple protocols where jumbo frames are considered a
potential benefit (iSCSI, RDMA come to mind as well as NFS per below).
A quick Internet search of "jumbo frame"+2005 generates over 20,000
hits, shows that most major switch vendors support them, and provides
plenty of information on the pros/cons of using them.   Gigabit Ethernet
is gaining wide adoption, and 10G Ethernet will eventually gain wide
deployment as costs come down.   End system HW/SW implementations are
continuing to improve, and become more efficient at moving TCP/IP data
between the wire and the applications.  

The IETF and IEEE are the best organizations to ensure jumbo frames are
dealt with in a sensible and interoperable fashion throughout the
protocol suites.   Let's do the work to handle jumbo frames
appropriately in the Internet architecture.

Alan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tony Li
Sent: Sunday, July 24, 2005 7:56 AM
To: [email-masked]
Cc: [email-masked]; Brian E Carpenter; [email-masked];
[email-masked]; Scott Bradner
Subject: Re: Reopening jumbo frames in IS-IS

Curtis,

> Excluding NFS and a few other less used protocols there is little
> reason for end system jumbo frames.  It is widely understood that NFS
> 8K UDP packets are a bad design.
> 
> IMHO endorsing jumbo frames in end systems goes to much against what
> IEEE would like to see and does so for the benefit of protocols that
> should have a new revision that eliminates the need by being more MTU
> aware.  This also can improve their performance radically when used
> over a WAN or VPN.

I would agree that using UDP for NFS in the first place was a
questionable call, exacerbated when UDP checksums were not enabled by
default on the implementations in question.

However, the real issue here is the end system efficiency, not MTU
awareness.  With a larger LAN MTU, the end system can be more efficient
by transfering an entire page at a time, rather than fragmenting it at
the UDP level or at the TCP level.  For some systems, this is a
non-trivial consideration.  When you couple this with ever increasing
link speeds (e.g., 10GigE), there seems little reason to preclude using
larger MTU sizes.  You'll note that the supercomputer folks have been
pushing us in this direction for years and we also had this discussion
relative to IPv6.

As to what the IEEE would like to see, that would seem to be a lesser
consideration than delivering the technology that our customers (i.e.,
end users) would like to see.  Those votes have already been cast and
are clearly in favor of jumbo frames.

The IETF's larger job, besides pushing this work forward, should be to
consider the role and scope of the MTU in the Internet in general.  It
is a fine point of the Internet architecture, and we have been remiss in
  not attending to this issue.  Right now, much of the Internet supports
a 4096 byte MTU, thanks primarily to some predominant POS
implementations.  However, most access links are still constrained to
1500B.  It would be very helpful, operationally, if the IETF could come
up with a recommended set of MTUs and set some expectations for end
users on the predominant MTU sizes.

While many folks may feel that this is a trivial and pointless detail,
it has a decided economic impact.  A fine example is classical IP over
ATM.  There the IETF specified a large default MTU (9120B, if memory
serves).  This caused equipment prices to rise as packet buffering
memory needed to be sized accordingly.  However, due to the lack of
transit capability for this MTU size, this capability has been largely
wasted.  Admittedly, this is indeed trivial with respect to the overall
waste on ATM technology, but it would be best if we did not repeat this
particular experiment.

Tony

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion