Re: [RAM] Tunnelling & GigE jumbo frame size

Iljitsch van Beijnum <iljitsch@muada.com> Wed, 12 September 2007 18:14 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWjj-0007n7-NX; Wed, 12 Sep 2007 14:14:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWji-0007n0-J6 for ram@iab.org; Wed, 12 Sep 2007 14:14:50 -0400
Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVWjh-0006Cm-98 for ram@iab.org; Wed, 12 Sep 2007 14:14:50 -0400
Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l8CIAsTK038082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Sep 2007 20:10:54 +0200 (CEST) (envelope-from iljitsch@muada.com)
In-Reply-To: <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.com>
References: <896E7873-B5D5-442E-AB33-63910A6E78BE@extremenetworks.com> <B39B869F-1148-4DC6-A308-02A125F40031@muada.com> <1CD6EB92-9167-4EAE-B372-A517572FCA4D@extremenetworks.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <E4A2C41B-454D-49CD-852C-B95ACA007971@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: [RAM] Tunnelling & GigE jumbo frame size
Date: Wed, 12 Sep 2007 20:13:24 +0200
To: RJ Atkinson <rja@extremenetworks.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

On 12-sep-2007, at 19:42, RJ Atkinson wrote:

>>> 	Just as "4K" MTU really means 4470 bytes, Jumbo Ethernet
>>> 	sizes of "9K" really mean an IP MTU of 9180 bytes.  This
>>> 	means the link MTU for Jumbo Ethernet is really:
>>>            (9180 + sizeof(Ethernet header) + sizeof(VLAN tag))

>> I think most people take it to mean 9000 bytes.

> I strongly disagree [...]

>> This is the only real jumboframe IP MTU size I've seen implemented
>> in hosts.

> You should look around more broadly then.

(Oh wait: I once saw a 10 Gbit ethernet card in a couple of PowerMac  
G5s that did 16384 bytes.)

> I've seen the jumbo MTU that I outlined in multiple versions of UNIX
> and in other kinds of systems.  Moreover, the jumbo MTU is primarily
> deployed by service providers and super-computer centers, and is
> not often used by ordinary end systems (e.g. one's home computer).

Let me make several points at once. This is my computer at home, a  
Mac laptop:

$ sudo ifconfig en0 mtu 9180
Password:
$ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         supported media: autoselect 10baseT/UTP <half-duplex>  
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>  
10baseT/UTP <full-duplex,flow-control> 100baseTX <half-duplex>  
100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 100baseTX  
<full-duplex,flow-control> 1000baseT <full-duplex> 1000baseT <full- 
duplex,hw-loopback> 1000baseT <full-duplex,flow-control> none
$ sudo ifconfig en0 mtu 9000
$ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 9000
$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384

In other words: it can do 9000 bytes but not 9180 and the default MTU  
on the loopback interface is 16834 so obviously 9000 is not a maximum  
imposed by the OS. And apparantly, it can't do half duplex for  
gigabit ethernet.

>> However, routers and especially switches come with many different  
>> maximum frame sizes. I've looked over some product literature and  
>> compiled the following list: 1508, 1530, 1536, 1546, 1998, 2000,  
>> 2018, 4464, 4470, 8092, 8192, 9000, 9176, 9180, 9216, 17976, 64000  
>> and 65280.

> As there is no standard, the maximum for a particular device will  
> vary.
> Most networking devices make this parameter *configurable*, below
> some maximum value.  Varying maxima was not the question on the table,
> however.

> The question on the table is *narrowly* "what is meant by 9K MTU ?".
> I stand by the contents of my original note.

Well obviously we shouldn't be saying "9k MTU" because it is too  
imprecise. Also, it's irrelevant unless we're trying to come up with  
a unified MTU size, which is something I am very much against, as it  
doesn't solve the problem but only moves the goalposts. We need to  
move to a situation where the capability to use larger packets is  
used where it exists and to the degree that it exists.

If we can increase the average packet size used on the internet by  
transmitting the same amount of data in fewer packets and routers/ 
switches are built such that they mostly use power when they are  
actually doing work, this will help with the power/heat issue.

But for the purposes of a jack up solution we just need a few dozen  
extra bytes to accommodate the new headers without triggering the  
breakage that ensues when 1500-byte packets can't be forwarded  
without fragmentation.

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram