[rbridge] TTL only - was RE: New fields in shim header?

[Gray, Eric]

Silvano,

	Any tunneling technology introduces overhead, resulting in
reduced forwarding efficiency - in terms of content verses packet
(or frame) size.

	If you can put less content in a frame, then you may have
to send more frames to transfer the same content.

	It's theoretically true that - in developing a new approach
- you might assume that you could enlarge frame sizes to eliminate
the "cost" of the additional over-head.  Practically, this is not
true.

	In the RBridge case, it is possible to have 802-1D devices
between RBridges.  Consequently, it is an error to assume that we
can define any frame size we want.  In addition, changing anything
arbitrarily has the additional complication of potentially making
it necessary to re-spin hardware components that might otherwise
be used off-the-shelf.

--
Eric  

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
--> Sent: Thursday, October 12, 2006 4:17 PM
--> To: Caitlin Bestler; Joe Touch
--> Cc: rbridge at postel.org; Radia Perlman
--> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
--> 
--> 
--> Caitlin,
--> 
--> See below
--> 
--> ...
--> 
--> > 
--> > And as we all know the probability of MsgSize having been
--> > crafted so the MsgSize % n is zero is all too high. So the
--> > more we add to the header, the more IP datagrams will be
--> > required to send the same traffic. 
--> 
--> I had the impression that TRILL was increasing the frame size on the
--> encapsulated size, not MTU reduction at the IP level. The 
--> fact that we
--> add few bytes more or less impacts performance, but not number of IP
--> datagram.
--> 
--> -- Silvano