There's some of that, but there are also apps that tune down their
application PDU size until things work. I guess my instinct is that
this problem can only be generically solved at transport level
and above, as RFC 4821 begins to recognize.
Agreed. If we knew that 4821 was going to make it into a
predominance of hosts, this wouldn't be nearly the issue that it is...
Other link-layer technologies are not creating this problem.
Tunneling is.
But it wouldn't, if we simply placed a (recursive) requirement on
tunnels
to deliver adequate MTU at the innermost level. Which is of course
an operational, not a protocol, solution.
True, but it's not a reasonable operational requirement due to the
large deployed base of 1500B MTU media.
And as long as we're going to make significant architectural
changes, we should be making things cleaner than when we got here.
I can't disagree with the principle. But to my taste, we're headed
towards
complexity instead of simplicity.
Agreed. I hope that we can do better.
Also - isn't this issue applicable to all the VPNish things being
developed these days, i.e. signiicantly broader than RRG?
In some ways, yes. It has been an issue since we started tunneling
over IP and it's not going to go away soon. The big difference, the
reason why RRG has to solve this if we want to tunnel, is that we're
making tunneling a first class part of the architecture. If LISP
were to be deployed ubiquitously, for example, we'd end up with
something like 99.99% of all Internet core traffic being tunneled and
being susceptible to the PMTUD problems that we've discussed. This
would include tunneling a large percentage of the folks without their
knowledge and consent. This is very different than inflicting pain
on a small subset of sophisticated folks who are using a specialized
application.
Tony
--
to unsubscribe send a message to [EMAIL PROTECTED] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
