Everyone,
Please discontinue this discussion at [EMAIL PROTECTED] list.
Thanks,
Pekka
writing as v6-ops co-chair
On Wed, 19 Nov 2003, Eddie Kohler wrote:
> > It's also possible for DCCP to get a better initial estimate of the PMTU,
> > and apparently there are other problems with the current
Eddie,
Yes, I agree with the idea of initially "plumbing" the path MTU
when a connection starts up. If the application has lots of data to
send, it might initially try to plumb out to the largest possible
MTU; if only a little, it might be less aggressive during startup.
It might also be desireabl
> It's also possible for DCCP to get a better initial estimate of the PMTU,
> and apparently there are other problems with the current DCCP PMTUD
> mechanism (using ICMP "can't fragment" messages).
Yes -- The current draft tries to make clear (but fails to) that a new,
PLPMTUD-style MTU discover
> Since then, we have seen the boom and subsequent bust of the
> Internet revolution. It would be a far stretch to say that this all
> came as result of the path MTU discovery decisions, but I do
> believe it fair to say that a harmful precedent was set: ...
> So, where does this leave us today?
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 ICM
Eddie,
Your opinion is from the perspective of a modern-day expert
technologist with specific insight into the problem space, and
I have a great deal of respect for that. My opinion brings an
historical perspective that I believe also bears consideration:
I was very close to "ground-zero" when the
; Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [pmtud] Re: [dccp] PMTU issues
>
>
> Hi Fred,
>
> * PLPMTUD is useful.
> * Designing PMTUD so that it works in the absence of ICMP
> feedback seems
> necessary.
>
> BUT
... I agree 100% with Eddie on these two (1. "we should
get rid of ICMP feedback in the long run", 2. "combine PMTUD
with ECN") issues.
Cheers,
Michael
On Tue, 2003-11-18 at 02:39, Eddie Kohler wrote:
> Hi Fred,
>
> * PLPMTUD is useful.
> * Designing PMTUD so that it works in the absence of ICM
Hi Fred,
* PLPMTUD is useful.
* Designing PMTUD so that it works in the absence of ICMP feedback seems
necessary.
BUT
* Suitable ICMP feedback hints might significantly improve the performance
of a transport protocol.
* We can program our transports to react to ICMP as a hint -- i.e., not
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*
> 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.
Why overload the ECN bit this
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
I'm cross-posting this from another list, since it relates to the
recent discussions on Path MTU discovery:
Fred
[EMAIL PROTECTED]
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 la
13 matches
Mail list logo
