Re: [pmtud] Re: [dccp] PMTU issues

[Michael Welzl <michael.welzl@uibk.ac.at>]

Fred,

Let us reconsider the end-to-end arguments:
They are NOT about keeping anything and everything out
of the network, not placing any helpful additional mechanisms
inside the network, and not putting any complexity inside the
network.

Routing algorithms, for instance, can be arbitrarily complex,
and still, it is all very much in line with the end-to-end
arguments. There is also nothing wrong with network mechanisms
that help end systems (see "network transparency" in the
"e2e and active networks" paper: lower layers should provide
"...usable means for effective sharing of resources and
resolution of resource conflicts."); the idea is not to place
any kind of application level functionality inside the
network.

So, yes: since only the application knows the packet size it's
going to send, it's a good idea to leave it up to the application
to determine the MTU. I believe that you're right about this -
this became evident when I read the update of your tunnel draft,
which has become much shorter and simpler.

Not relying on ICMP packets is indeed a big step - but
utilizing ICMP packets as an optional enhancement is something
entirely different. In particular, the difference is that
ISPs can find out that it was a bad idea (too many ICMP's, too
much work for routers, ...) AFTERWARDS and simply turn it
off if they want to. So there's really not much harm done.

Cheers,
Michael




On Wed, 2003-11-19 at 02:29, Fred Templin wrote:
> Eddie Kohler wrote:
> 
> >Well, I wouldn't want to be responsible for any further destruction of the
> >Internet revolution, but most of this seems besides the point.  Old-style
> >PMTUD, which *depended* on the delivery of ICMPs, is a far cry from
> >new-style PMTUD, which *can benefit* from the delivery of ICMPs.  The
> >problem was the PMTU algorithm, not the idea of ICMPs.  And the network
> >isn't full of useless ICMPs.
> >
> 
> Nonetheless, I believe we should keep options open and investigate
> ways to support L2 devices that don't send ICMPs and don't support
> IP fragmentation without relegating them to second-class citizens.
> PLPMTUD gives us one such tool, but does it *really need* the ICMPs?
> 
> We got this wrong on the first iteration some 15 years ago, and if there
> is now an opportunity to set things right we should at least give it serious
> consideration and make the right informed decisions.
> 
> Thanks - Fred
> ftemplin@iprg.nokia.com



_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html