Subject: [pmtud] MTU IP Option (reviving RFC 1063)

From: Michael Welzl <[email-masked]>
Date: 21 Aug 2003 09:53:37 +0200

Hi all,

I have a proposal for PMTUD which could be integrated
in the "new" as well as the "old" approach. The idea
is to revive RFC 1063 (the MTU Discovery Option, which
requires a router to update the MTU value in the option
if its MTU is smaller than the value already in there).
Back when this option was conceived, there was no
PMTUD - so PMTUD was clearly a better idea because the
option would require all routers to participate.

My idea is to combine the two. Routers MAY participate,
hosts SHOULD initially use the option when doing PTMUD.
If you receive something in the option, the Path MTU is
certainly not larger than the received value. If applied
properly, you have a method of PMTUD where a packet is
delayed (slow path processing), but, with some luck, you
lose no packets:
* With regular PMTUD, you use it before actually doing
  PMTUD and use the value as a starting point.
* With the new PMTUD, if you receive something, you
  should not increase the MTU beyond this point.

Is it a good idea?

Router perspective:
===================
Normally, routers send ICMP error messages back if
the MTU is exceeded. Router X which has a very small
MTU must generate a large number of such packets. Once
this new option is deployed, participating in the
mechanism can help router X to reduce its processing
overhead because option processing is certainly less
costly than generating an ICMP packet.

Source perspective:
===================
Is this worth having a packet delayed via slow path
processing? I think so, because it's a delayed vs. a
lost packet (well ... delayed in any case, vs. a chance
of not losing a packet). A precise answer requires
finding out the impact of slow path processing on
TCP performance. The first part of this sentence
(finding out the impact of slow path processing)
has already been done at our site; we are now
beginning a statistical analysis of our measured data.

What do you think?

Cheers,
Michael

_______________________________________________
pmtud mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmtud

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 21 Aug 2003 10:35:36 +0100

>   should not increase the MTU beyond this point.

Never?  What about route changes during a connection?
-Jeremy

---

From: Michael Welzl <[email-masked]>
Date: 21 Aug 2003 11:49:14 +0200

Hi,

Route Changes make no difference. The whole idea is to use
the IP Option when doing Path MTU Discovery, which implicitly
assumes that the path remains the same during the process.

Since a path may change indeed, the MTU should be increased
every once in a while (this is specified in RFC 1191).
So, if you generally use the MTU option for PMTUD, you
use it once again - simply each time you probe for the
Path MTU. The option must be seen in the context of a
single PMTUD process, no matter if it is by means of
increasing or decreasing the packet size until the right
one is found.

Cheers,
Michael

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Aug 2003 12:11:07 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Michael" == Michael Welzl <[email-masked]> writes:
    Michael> Is it a good idea?

    Michael> Router perspective: =================== Normally, routers send
    Michael> ICMP error messages back if the MTU is exceeded. Router X which
    Michael> has a very small MTU must generate a large number of such
    Michael> packets. Once this new option is deployed, participating in the

  The routers who are causing the MTU constraint clearly have some
obligation, and as an IPsec implementor, I'm happy to update my code like
this.
  So, this is a good idea. It may not be sufficient to deal with the problem.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: "Michael Welzl" <[email-masked]>
Date: Thu, 21 Aug 2003 18:28:27 +0200

>   So, this is a good idea. It may not be sufficient to deal with the
problem.

Let me make it clear to everybody that this is by no means intended
to be a sufficient solution to the problem, or to replace the original idea
of Matt (which I think is a very good one). It is an additional extension
which might give us an extra bonus (less loss, if lucky).

Cheers,
Michael

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Aug 2003 21:21:40 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Kevin" == Kevin Lahey <[email-masked]> writes:
    >> I have a proposal for PMTUD which could be integrated in the "new" as
    >> well as the "old" approach. The idea is to revive RFC 1063 (the MTU
    >> Discovery Option, which requires a router to update the MTU value in
    >> the option if its MTU is smaller than the value already in there).
    >> Back when this option was conceived, there was no PMTUD - so PMTUD was
    >> clearly a better idea because the option would require all routers to
    >> participate.

    Kevin> Whenever this is proposed, a wail seems to go up from the routing
    Kevin> folks.  The oft-repeated claim is that processing options on some
    Kevin> reasonable percentage of the packets would be incredably slow.

  Is there some way that we can put in a option that is not a hop-by-hop
option, but that things that have MTU-constraints might be willing to process?

---

From: Michael Welzl <[email-masked]>
Date: 27 Aug 2003 11:02:58 +0200

Hi all,

This mail from last week was the last response to my
proposal ... so what? Should I put it in writing?
Matt?

Cheers,
Michael

On Thu, 2003-08-21 at 18:11, Michael Richardson wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> Comment: Finger me for keys - custom hacks make this fully PGP2 compat
> 
> iQCVAwUBP0TvGoqHRg3pndX9AQHPzAP+M82eZ9WOz6CmnGdwG2gQ2rWru+X8o2q4
> MYtTBAt/wUmnVmv6kxB/rGfwpeOI03nWfaCr0hatQS/sbrZGDTAWq0iSH5XPezFh
> rmXPk7kbElw1CNONwUUQVrL1vBt9GzydjneZt0ZN3awhlragbZ0fIFZpINdUjYy2
> 23vN6/LO+eA=
> =8rTo
> -----END PGP SIGNATURE-----
> ----------------------------------------------------------------------
> This message was sent to [email-masked].
> Send questions about this list to: [email-masked].
> For help using this service, send a blank message to: [email-masked]
-- 
Michael Welzl <[email-masked]>
University of Innsbruck

---

From: Fred Templin <[email-masked]>
Date: Wed, 27 Aug 2003 14:28:20 -0700

Earlier this year I prepared two interrelated drafts on Path MTU
support for IPv6-in-IPv4 tunnels, but their domain of applicability
may also extend to other use cases. The drafts can be found at:

  http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-00.txt
  http://www.ietf.org/internet-drafts/draft-templin-ndiscmtu-00.txt

Is there any interest in pursuing this work further in this group?

Fred
[email-masked]

---

From: "Kevin Lahey" <[email-masked]>
Date: Wed, 27 Aug 2003 17:34:28 -0700

In message <1061452416.1733.104.camel@lap10-c703>Michael Welzl writes
>option would require all routers to participate.

Whenever this is proposed, a wail seems to go up from the 
routing folks.  The oft-repeated claim is that processing
options on some reasonable percentage of the packets would
be incredably slow.

Similar suggestions were floated in the IPng just a few years
ago, and shot down in flames.  OTOH, I thought I just read
something on e2e suggesting that current routers were 
up to the task, so maybe now is the time to revive the idea.

Good luck,

Kevin
[email-masked]

---

From: Michael Welzl <[email-masked]>
Date: 28 Aug 2003 08:39:33 +0200

>     Kevin> reasonable percentage of the packets would be incredably slow.

As I said earlier, I have some data from measurements using
NOP options, so "incredibly" could be put in numbers. However,
a statistical analysis is missing - a student is currently
going through the data, so I can't tell how long it's going
to take. Then, it would be possible to calculate / estimate
whether it's worth the disadvantage of slow path processing
or not. I would have proposed this idea a little later if
Matt hadn't started the working group...

I decided to give you an idea of the results by putting
two preliminary diagrams online; please look at:
http://www.welzl.at/tmp/option.html
for more. As you can see, the impact of option processing
is considerable, but clearly an order of magnitude smaller
than the RTT itself.

> option, but that things that have MTU-constraints might be willing to process?

This would be great, but the only way I can think of (given that
ANY kind of option processing puts your packets in the slow path,
and there are no additional bits available in the IP header) is
by introducing an extra protocol (new protocol number in IP) that
would reside in between IP and the transport layer. And I have a
bad feeling about this.

Any better ideas?

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: 28 Aug 2003 09:41:41 +0200

> would reside in between IP and the transport layer. And I have a

... come to think of it, once the receiver gets some valuable
information from the option, we ought to find a way to transmit
the information back to the sender. RFC1063 has a reply option;
there should be a better way to do it (slow path processing
once again, just for the feedback? nay ...)

We could perhaps put the feedback directly in the transport
layer - attach it to TCP ACKs...

Cheers,
Michael

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Aug 2003 11:14:44 -0400

>>>>> "Michael" == Michael Welzl <[email-masked]> writes:
    Michael> ... come to think of it, once the receiver gets some valuable
    Michael> information from the option, we ought to find a way to transmit
    Michael> the information back to the sender. RFC1063 has a reply option;
    Michael> there should be a better way to do it (slow path processing
    Michael> once again, just for the feedback? nay ...)

    Michael> We could perhaps put the feedback directly in the transport
    Michael> layer - attach it to TCP ACKs...

  Yes, that's what I proposed in another message.

  Perhaps we can agree that the receiver has some knowledge of the MTU
and can provide it to the sender.