Subject: Re: Path MTU for Tunnels (was: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt)

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

I have one more update to share on this document. It is found at:
 
  www.geocities.com/osprey67/tunnelmtu-05.txt
 
Changelog is below:
 
Fred Templin
[email-masked]
 
Appendix A. Changelog

   o  Removed support for IPv4 fragmentation to save state; eliminated
      control message overhead.

Fred Templin <[email-masked]> wrote:
Folks,
 
I uncovered a few bugs and made some changes since yesterday.
(I was using the wrong mechanism for L2 fragmentation! :^/ ) The
new document version can be found at:
 
  www.geocities.com/osprey67/tunnelmtu-04.txt
 
The changelog appears below:
 
Fred
[email-masked]
 
Appendix A. Changelog

   o  Specified use of IPv4 fragmentation (instead of IPv6) as the L2
      fragmentation mechanism.

   o  Added CongestMTU for use during periods of congestion.

   o  Added support for sending congestion indications not associated
      with probes.

   o  Clarified DF bit settings.

Fred Templin <[email-masked]> wrote:
I would like to add some qualifying remarks to my previous message.
Many of my earlier messages on this subject were preliminary, but this
message and my current document are not. See:
 
www.geocities.com/osprey67/tunnelmtu-03.txt
 
This document offers the following important conclusion:
 
  "It is impossible for the network to anticipate the
   packet transmission strategy of the application."
 
This result is perhaps not surprising and certainly not new, as
it is accurately predicted by the End-to-End Principle.
 
Some additional notes:
 
- For the past several months, I have worked under the premise that a
  robust, secure, efficient, and generalized Path MTU discovery mechanism
  for IPv6-in-IPv4 tunnels was needed that operated autonomously and without
  direction from the application. I struggled for many months to come up
  with a solution that satisfied this design point and failed -  as have many
  others over the past 15 years.
 
- After finally accepting the above conclusion and recognizing the means
  by which the application could provide guidance to the network, the solution
  was immediately obvious and I was able to write the entire document on
  the 4.5 hr flight into Minneapolis.
 
All those interested in path MTU discovery (and the more general
subject of application<->network interactions) should read this
document along with the normative references it cites (even reading
just the Introduction should be sufficient if time is short). The document
probably has a few bugs, and I would appreciate comments. But,
the conclusions will not go away and are indeed inescapable.
 
Thanks - Fred
[email-masked]
 
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version. 

Fred Templin <[email-masked]> wrote:
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
 
A copy of the document can be viewed at:
 
  www.geocities.com/osprey67/tunnelmtu-03.txt
 
I am copying this to both lists, but suggest we continue
the discussion on 'v6ops'. Finally, I would like to welcome
comments and offer this document as topic for discussion
during the MECH timeslot in Tuesday's v6ops session.
 
Fred Templin
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Wed, 12 Nov 2003 11:08:45 -0800 (PST)

Yes, it's me again - hopefully one last time. I took out a bit too much in
my last iteration on the document. I have added the following new text
under "Sending Packets:"

      "If the packet is 1280 bytes in length and it contains an IPv6
      fragment header, the tunnel interface encapsluates the packet
      in IPv4 then fragments the encapsulated packet to a fragment
      size of 256 bytes. Each of the five resulting fragments will
      add a 20 byte IPv4 fragment header making each fragment 276
      bytes. Thus, each fragment will fit within the ~200msec human
      perceptible delay budget for the lowest-common denominator
      link that may occur over the tunnel, which is 296 bytes for
      a 9.6kbps link ([RFC3150], section 2.3)."
 
See:
 
  www.geocities.com/osprey67/tunnelmtu-06.txt
 
Thanks - Fred
[email-masked]

 
Changelog is below:
 
Fred Templin
[email-masked]
 
Appendix A. Changelog

 

 
Fred
[email-masked]
 
Appendix A. Changelog

 

 
 
Some additional notes:

 
 
Thanks - Fred
[email-masked]

 

 
Fred Templin
[email-masked]