Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt

[Fred Templin <osprey67@yahoo.com>]

Another thing to note about MTUs is that bigger is NOT always better.
Take wireless media for example, where bit error rates are high. The
larger the packet, the more exposure to the high bit error rate and
the greater the probability of loss or long delays due to link-level
retransmissions. 1500 bytes should be a plenty-large MTU for any
wireless media unless/until some laws of physics are bent to allow
a more efficient transmission media than RF.

Pretty much all routers these days can handle 1500 byte packets,
and it doesn't take *any* signalling between the encapsulator and
decapsulator to determine that. The problem comes if you err a bit
on the high side, incurring fragmentation in the network if additional
link-level encapsulations occur. "Beyond Folklore: Observations on
Fragmented Traffic" observes that tunneled traffic is the #2
contributer to fragmentation due to mis-configured MTUs. Packet
lengths of 1520 - 1636 bytes in fragmented series were observed, with
1520 (due to a 20-byte IPv4 encapsulation layer) and 1572 (due to 20
byte IPv4 and 52-byte L2TP/PPTP ecapsualtion for VPN) by far the most
common. This situation is to be avoided for transition mechanism
tunneling, since fragmentation at 1500 bytes usually results in a
maximum-sized packet followed by a "tinygram" of 20 - 72 data bytes
plus 20 additional bytes for the IPv4 fragment header, which is
terribly inefficient.    

Consider finally that if the network is going to fragment packets
on a smaller granularity than 1500 bytes, it will likely do so at
576 bytes (a common MTU for some serial line protocols), as observed
in "Beyond Folklore: Observations on Fragmented Traffic". But, both
1280 and 1500 byte packets will require 3 fragments in this case,
so it makes no sense to to err on the low side.  

Conclusion - the fixed interface MTU of 1280 bytes suggested in the
MECH text is too small. I suggest it be changed to 1428 (1500 minus
72 for IPv4/VPN encaps).

Fred Templin
osprey67@yahoo.com
   


--- Pekka Savola <pekkas@netcore.fi> wrote:
> On Fri, 8 Nov 2002 Internet-Drafts@ietf.org wrote:
> > 	Title		: Basic Transition Mechanisms for IPv6 Hosts and Routers
> > 	Author(s)	: E. Nordmark, R. Gilligan
> > 	Filename	: draft-ietf-ngtrans-mech-v2-01.txt
> > 	Pages		: 25
> > 	Date		: 2002-11-7
> 
> Just two comments on this:
> 
>    This dynamic MTU determination is OPTIONAL.  However, if it is
>    implemented it SHOULD have the behavior described in this document
>    and the tunnel MTU MUST be not exceed 4400 bytes.  If it is not
>    implemented instead the node MUST instead limit the size of the IPv6
>    packets it tunnels to 1280 bytes i.e., treat the tunnel interface as
>    having a fixed interface MTU of 1280 bytes.  An implementation MAY
>    have a configuration knob which can be used to set a larger value of
>    the tunnel MTU than 1280 bytes, but if so the default MUST be 1280
>    bytes.
> 
> ==>
> 1) does 'tunnel MTU MUST be not exceed 4400 bytes' only apply to the 
> dynamic MTU determination part or also to "manual configuration" part?
> (probably the latter, but it's a bit unclear.)
> 
> 2) Why just 4400, not e.g. 4500? (Note: ATM/POS links usually have a
> default MTU of 4470 bytes, so either 4470+20 or 4470-20 (depending on
> which kind of encapsulation you believe is more useful) would be one
> interesting compromise, I believe.)
> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 
> 


__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com