Hi Eddie, Well, when I opened this can of worms, I had no idea of how big it was :-). It might be worthwhile to restate the original problem I was trying to solve. That is, it will be common that the initial PMTU estimate made by DCCP (based on the first-hop MTU) will be wrong, and therefore an application that wants to use large packets, and relies on that initial estimate will lose its first few packets.
So, how big a problem is this? A few points: 1) A DCCP app must be able to deal with lost packets at any time, so a DCCP app must build the necessary recovery mechanisms anyway. 2) Recovering from packet loss requires some extra effort when it happens, and recovering from the loss of the initial packets is often higher effort than recovering from the loss of later packets. 3) No one wants to gratuitously lose packets. 4) Many DCCP apps will not use large packets. Large packets often imply some delay while the data is accumulated, and many DCCP apps will want to avoid that delay. A simple solution, for apps that are bothered by this problem, is to use something smaller than the initial PMTU DCCP gives. Maybe the IPv6 min MTU of 1280 (minus IP and DCCP headers), or maybe say 64 bytes less than the initial DCCP PMTU (enough to hold an IPv4 IPsec tunnel header and a little more). This guideline might cover enough cases to be worthwhile, and the resulting inefficiency doesn't seem to me to be terrible. 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). Since DCCP is an unreliable packet service rather than a reliable stream service, the PLPMTUD proposal requires some extensive translation. Eddie's idea of an initial probe with padded Acks fits better, and gets around some of the further issues involved in relying on ICMP messages. However, it doesn't seem to me that we can completely abandon IMCP messages. Since DCCP is unreliable, that would require some kind of continuous probing to detect mid-connection changes. So, my question for the DCCP people, is it worth changing DCCP PMTUD? Tom P. > -----Original Message----- > From: Eddie Kohler [mailto:[EMAIL PROTECTED] > Sent: Monday, November 17, 2003 8:39 PM > To: Fred Templin > 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 > > * 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 > trust it, but use it to optimize performance. > * So ICMP should not be "needed", but it might, and probably > would, be quite > helpful in some cases. > * For instance, not all packetization layers have as easy a > time as TCP > with packet size changes. The smooth ramp-up suggested in > PLPMTUD may > require intervention from the application for example. For good > performance, these applications may apply PMTUD in > unexpected ways -- > they might start large, for example. ICMP feedback would > really help > them. > * ICMP is not a significant cause of Internet congestion and > need not ever > become one (mark it less-than-best-effort). > > I still think your overloading of ECN capable as "PLPMTUD > capable, don't > send ICMP" is not necessary, a bad idea, and will not fly. > > Eddie > > _______________________________________________ > dccp IETF mailing list: [EMAIL PROTECTED] > list info: https://www1.ietf.org/mailman/listinfo/dccp > wg charter: http://www.ietf.org/html.charters/dccp-charter.html > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
