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

From: Fred Templin <[email-masked]>
Date: Fri, 14 Nov 2003 17:56:45 -0800

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
[email-masked]

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
> [email-masked]

---

From: Eddie Kohler <[email-masked]>
Date: Fri, 14 Nov 2003 19:04:56 -0800

>   response to too-large packets being dropped.

Why overload the ECN bit this way?  ECN should be used to indicate
end-to-end congestion control compliance.  In fact RFC 3168 requires that:
"... the transport protocol must be capable of reacting appropriately to
the receipt of CE packets." THat's independent of MTU discovery, or at
least should be pointed out.

Eddie

---

From: Fred Templin <[email-masked]>
Date: Mon, 17 Nov 2003 12:12:10 -0800

Eddie,

A transport protocol that is smart enough to react to the receipt of
CE packets should also be smart enough to figure out the size of the
largest piece of data that can traverse the network without incurring
fragmentation. Such a "smart transport" should be able to figure this
out with *no* feedback from unreliable and untrustworthy ICMP
messages from the network if the example from Packetization
Layer Path MTU Discovery (PLPMTUD) is taken.

So, if the ICMP's are unneeded, I believe it is desireable to have
a way to turn them off. This would serve the beneficial purpose
of reducing the overall congestion in the Internet as deployment
of transports that don't need the ICMPs ramps up

Thanks - Fred
[email-masked]