[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
On 2007-12-22 18:48, Tony Li wrote:
On Dec 21, 2007, at 8:08 PM, Brian E Carpenter wrote:
PMTUD has been broken and unreliable for years, and that
hasn't stopped the Internet from working. The reason is
that hosts and applications have found methods of working
successfully that don't depend on PMTUD. Let's not even
debate what those methods are; it doesn't matter for
this discussion.
In fact, it very much does. The way that folks have worked around it
for years is to go around and manually turn down MTUs on end hosts,
leaving the Internet in a continual state of debugging and manual
reconfiguration.
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.
I don't see why the (virtual) links that are created by
a map-and-encap solution should be held to a higher standard
than any other link-layer technology.
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.
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.
Also - isn't this issue applicable to all the VPNish things being
developed these days, i.e. signiicantly broader than RRG?
Brian
--
to unsubscribe send a message to rrg-request@psg.com 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