Re: Reopening jumbo frames in IS-IS

[sob at harvard.edu (Scott Bradner)]

also - there is no layer-2 way to say "packet too big"
so that big packets sent through paths that do not support big packets
go into a black hole and the software never knows what happened

Scott

----
>From fred at cisco.com  Fri Jul 15 13:27:20 2005
X-Original-To: sob at newdev.harvard.edu
Delivered-To: sob at newdev.harvard.edu
In-Reply-To: <42D7ECF3.3010406 at sun.com>
References: <200507151359.j6FDxVsQ009521 at workhorse.faster-light.net> <42D7ECF3.3010406 at sun.com>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Cc: curtis at faster-light.net, rtg-dir at ietf.org, iesg at ietf.org,
	routing-discussion at ietf.org, Brian E Carpenter <brc at zurich.ibm.com>,
	Scott Bradner <sob at harvard.edu>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred at cisco.com>
Subject: Re: Reopening jumbo frames in IS-IS
Date: Fri, 15 Jul 2005 10:27:16 -0700
To: Radia Perlman <Radia.Perlman at sun.com>
X-Mailer: Apple Mail (2.733)
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs";
	t:"1121448351.73505"; x:"432200"; a:"rsa-sha1"; b:"nofws:421";
	e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p"
	"XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC"
	"50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc=";
	s:"PRq9DVgsHUgdLZP6sRxe94EDYyx7rXYtgeFGzLriIX75ui9ef1uLnh7XQ1nYkEgZgUbgUrce"
	"j9ixfAHCKzd2oKC2SPQxG2Vnw1cm9o0mM/fNAmN9DIstyE5Px0hi+06+oVrzgFpZxxJnerl1okq"
	"hNk5G8/GFnmG/344JKdaVCXE=";
	c:"From: Fred Baker <fred at cisco.com>";
	c:"Subject: Re: Reopening jumbo frames in IS-IS";
	c:"Date: Fri, 15 Jul 2005 10:27:16 -0700"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com";
	c:"message from imail.cisco.com verified; "


On Jul 15, 2005, at 10:05 AM, Radia Perlman wrote:

> What are the technical reasons that IEEE does not like large packets?

I can't speak for IEEE, but the reasons usually brought up include  
implementation costs in terms of buffer depths, and mutual jitter  
between competing traffic streams. If you have a session that sends a  
packet every 20 ms and depends on that being mostly maintained,  
having another session send packets that are 30 ms long and can get  
several into the queue ahead of you can be a real pain.