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

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Nov 2002 12:52:44 +0200 (EET)

On Fri, 8 Nov 2002 [email-masked] 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

---

From: Fred Templin <[email-masked]>
Date: Thu, 14 Nov 2002 06:58:51 -0800 (PST)

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
[email-masked]

> interesting compromise, I believe.)

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

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 17 Nov 2002 18:38:34 +0100 (CET)

> (probably the latter, but it's a bit unclear.)

For manual I assume the encapsulator and decapsualtor should be able to
pick whatever values they want, since this is manual. For instance,
if they have IP over AAL5/ATM in the path they might want to configure a 9k
number.

I take it I need to make this more clear in the draft on this point.

> interesting compromise, I believe.)

As I pointed out in emails (but not in the draft) we can debate the actual
numbers - possibly forever. 4400 was something I pulled from a hat.

I don't know what *process* to use to determine the numbers.
(There is also the 1280 default number when the tunnel MTU is not dynamic
which perhaps we need to debate.)

In terms of the 4400 number, it effects a bit the IPv4 reassembly buffer
in decapsulators. This is because the encapsulator might be using 
the dynamic scheme. Thus if a decapsulator have an interface which can receive
packets of size X, it needs a reassembly buffer size for MIN(X, 4400).
Does this mean we can make the 4400 number larger (e.g. 8k, 9k?)

The 1280 number (the MTU used when there is the tunnel MTU is not dynamic)
directly effects the IPv4 reassembly buffer in decapsulators so we
presumably don't want this number to be much larger (but one could argue that
2k would not be a big deal I think).

   Erik

---

From: Stig Venaas <[email-masked]>
Date: Wed, 20 Nov 2002 17:19:00 +0100

As Dave said at the meeting, I believe MTU of 1280 might be a problem
for MIP. It might also be a problem when doing multicast and sending
PIM register messages.

Stig

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 20 Nov 2002 17:52:11 -0800

Erik,

I liked the suggestion of 1380 bytes for the MTU when dynamic tunnel 
configuration
is not used. I believe this also requires an MRU of at least 1400 bytes 
in the receiver,
however. Does this require any sync-up with the IPv6 node requirements 
draft? The
text there says:

  "If Path MTU Discovery is not implemented then the sending packet size is
    limited to 1280 octets ..."

We would like to be able to cite [MECH](bis) out of the next version of the
ISATAP draft. Do you have any timeframe for making the changes?

Fred Templin
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Wed, 20 Nov 2002 18:20:07 -0800 (PST)

Harald,

You made some comment during the v6ops meeting this AM regarding an
"interesting" draft. Could you be referring to this one:

  http://www.ietf.org/internet-drafts/draft-templin-v6v4-ndisc-01.txt

The main idea is to have an after-market deployable mechanism that
can allow automatic tunnel encapsulators/decapsulators to participate
in path MTU discovery. The mechanism detects whether both ends are
participating in the protocol and only runs if the handshake is
completed. The penalty is extra state for neighbor cache entries,
which presents a scaling issue for routers - but one that I think
can be quantified.

I'd be happy to have some comments on the draft,

Fred Templin
[email-masked]

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Nov 2002 03:36:30 +0100 (CET)

>     limited to 1280 octets ..."

That is an orthogonal issue.
An IPv6 sender that doesn't perform path MTU discovery will only send <=1280
bytes as you point out, but the IPv4 reassembly buffer size of
the receiver on a tunnel decapsulator is merely a function of how
the IPv6-in-IPv4 tunneling is done.
 
> ISATAP draft. Do you have any timeframe for making the changes?

I'd like to get it done in a month.

  Erik

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 20 Nov 2002 19:10:18 -0800

>the IPv6-in-IPv4 tunneling is done.
Yes - unless a dynamic mechanism is used.

>I'd like to get it done in a month.

This might be too late for us to get ISATAP ready for last call. We may 
decide to
continue to work the issue out of our document for now. But, I believe 
we have
sufficient flexibility around the minimum sizing to acommodate extra 
layers of
encapsulation, e.g., VPN.

Thanks,

Fred Templin
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Nov 2002 13:51:48 +0100 (CET)

> >bytes as you point out, but the IPv4 reassembly buffer size of >the
> receiver on a tunnel decapsulator is merely a function of how >the
> IPv6-in-IPv4 tunneling is done. >

My point about orthogonality holds even if a dynamic tunnel MTU is in use.

  Erik