Subject: Re: alternative PMTU

From: Vernon Schryver <[email-masked]>
Date: Mon, 22 Mar 1999 08:34:02 -0700 (MST)

> From: "Eric A. Hall" <[email-masked]>

> ...
> Suppose that instead of doing this complex probe operation that we have
> today, we just send datagrams with fragmentation allowed. Then, if
> fragmentation does occur somewhere, the recipient responds with a TCP
> option that states "fragmentation occurred: fragment size is X"
> ...

Contrast the current path MTU discovery mechanism with that idea:

  current scheme:
    deals with UDP, ICMP, and other protocols

    works even when other host and all routers do not know the new
      PMTU ICMP option.  It works very with only some routers updated,
      and with the far larger number of hosts running the original TCP.

    Routers do not absolutely need to be updated, but if they are,
      the change is tiny.

    always discovers the MTU that the sender needs to use to avoid
      fragmentation.

    handles routing changes

  alternate scheme:
    handles only TCP.

    Does not work at all unless requires the remote host has new TCP and
      IP code.  There are far more hosts that would need to be updated
      with new TCP and IP code than routers in the current scheme.

    The new code needed in hosts is much larger than the change in routers,
      and again, the routers do not absolutely need to be changed at all
      in the current scheme.

    gets the fragment seen by the far host, which can be larger than the
      smallest MTU if any router does IP reassembly, and usually is
      smaller.  What if the bottleneck router fragments into even sizes
      instead of maximum and tiny sizes?   What about the effects of the
      8-byte granularity of IP fragments?  Also consider the IP fragments
      an Ethernet host (1500) can receives from an FDDI sender, 1500,
      1500, and 1412 (assuming no TCP or IP options).  Does the alternate
      scheme report 1500 or 1412?   Now consider the fragments received
      on the Ethernet when the the FDDI host prefers to use an MSS of 4096
      instead of 4332, because that is often much faster.  (There are many
      commercial systems that do that.)

    Say you handled those problems by looking for the largest fragment or
      datagram received, and ignored the fact that would not always give
      the right answer.  Then what about routing changes?

] From: "Eric A. Hall" <[email-masked]>

] > Am I missing something here. The ICMP reply optionally gives you the
] > mtu size
]
] Sometimes an intermediary will, but the end-point never does.

The endpoint never does any IP fragmenting, so why do you care what it
guesses is the smallest MTU in the path?

]                                                               Also, it
] can take multiple efforts to find the "true" end-to-end mtu.

Not in practice, unless the router doing the fragmenting does not know
about the new ICMP option.

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 22 Mar 1999 22:06:55 -0700 (MST)

> ...
> No, what I'm thinking is that instead of sending a series of recursive
> probes through the network (which don't get returned, or which get eaten
> by ICMP-hostile devices, or which don't provide any useful info), just
> have the end-node return an option that says "hey fragmentation has
> occurred and this is the biggest fragment that I got."

But once again, the biggest fragment that a host received has no useful
relationship to the path MTU.  Please consider the implications of the
8-byte granularity of IP fragments.  Because of the 8-byte granularity,
it can be impossible for a router to generate a fragment that is as
large as the MTU allows.

Consdier the possibility that the router with the smallest MTU in the path
might not do not fragment stupidly.  What if the MSS is 2048, the PMTU is
1500, and the largest fragment far host receives is 1024?  Your scheme
would incorrectly declare the PMTU to be 1024.  

Consider load sharing a TCP connection with MSS=4312 (FDDI) over two paths,
one with PMTU of 1500 (Ethernet) and the other with PMTU 4352 (FDDI).
Your scheme would falsely declare the PMTU is 4352.

Also as I said before, your notion does not support UDP.
In practice, UDP often needs PMTU discovery while TCP usually does not,
because of the TCP MSS option.

All of those casees are handled correctly by the current mechansim RFC 1191.

> It is a lot easier to deal with the one message that is explicit than
> trying to deal with many messages of many different flavors that don't
> necessarily tell you anything even when they do succeed (the current
> design of using DF and hoping for informative errors).

Please take time to read RFC 1063 and RFC 1191, and see that there
are not "many messages of many different flavors", but only two.
Please also notice that one of those two flavors contains the actual,
accurate value, unlike the hopelessly inaccurate value of your proposal.

Consider the 1988 date of RFC 1063, and consider the likelihood that
support for the second flavor that contains all of the accurate information
is practically universal today in reasonable routers.

> One downside to the one-shot model is that the remote end-point HAS to
> support the option if it is going to be relied upon. Otherwise you'd
> just keep sending fragmentable data and never get a response saying "got
> frags."

Yes, and that issue was one of the design constraints on RFC 1063
and RFC 1191.