[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

BTW, one last parting thought on this subject (and then I'll
shut up) is that we have perhaps an opportunity to specify
the following good thing:

 A packetization layer should set an ECN codepoint in
 the packets it sends IFF it is also doing Packetization
 Layer Path MTU Discovery (PLPMTUD) and is not
 expecting to get ICMP's back from the network in
 response to too-large packets being dropped.

I have already implied this in my document, which should
hit the I-D repository soon. See:

www.geocities.com/osprey67/tunnelmtu-06.txt

But, perhaps this needs to be spelled out in a more general-use
type of document, e.g., a per-hop behavoir (PHB) document for
RFC 3168?

Thanks - Fred
ftemplin@iprg.nokia.com

Fred Templin wrote:

I hate to say it, but frankly I think this whole PMTU business is
a bunch of hooey. We have RFCs 1191 and 1981 as the service for
packetization layers that require network level feedback, and those
packetization layers can happily continue doing what they've been
doing for the past decade or so.

But, new packetization layers that take the example of PLPMTUD
require no feedback from the network and so they should have a
means by which to turn the network layer feedback off. This should
eventually dampen the noise from the unnecessary ICMP's as the
new packetization layers supplant the old.

Anyway, that's my story and I'm sticking to it.

Fred
ftemplin@iprg.nokia.com