Subject: Re: [dccp] PMTU issues

From: "Phelan, Tom" <[email-masked]>
Date: Tue, 18 Nov 2003 12:15:21 -0500

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-masked]]
> Sent: Monday, November 17, 2003 8:39 PM
> To: Fred Templin
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> 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-masked]
> 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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Eddie Kohler <[email-masked]>
Date: Wed, 19 Nov 2003 06:21:33 -0800

> mechanism (using ICMP "can't fragment" messages).  

Yes -- The current draft tries to make clear (but fails to) that a new,
PLPMTUD-style MTU discovery mechanism is acceptable. There are API problems
with such a scheme, but we absolutely allow it.

If you can accept an extra RTT or two at connection initiation time, I
think you can do pretty well:

    Request -->
            <-- Response
    then, all in 1 RTT:
    Padded Sync(512 bytes) -->     /* actual #s would need to fit CC
    Padded Sync(1280 bytes) -->	       mechanism */
    Padded Sync(4000 bytes) -->
            <-- SyncReply(1)	   /* SyncReplies sent only for those
	    <-- SyncReply(2)	      packets that got through */
	    <-- SyncReply(3)
            
> So, my question for the DCCP people, is it worth changing DCCP PMTUD?

It's certainly worth describing it better, and perhaps mentioning a set of
acceptable procedures.  Have you any suggestions for useful procedures
here?

Eddie

---

From: Fred Templin <[email-masked]>
Date: Wed, 19 Nov 2003 10:28:40 -0800

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 desireable to piggyback the plumbing process onto
other messages that require a RTT before the connection can be
tried. For example, IPv6 neighbor discovery messages (e.g., Router
Solicitations) can be null-padded to any length out to 64KB when
they are sent over an IPv6-in-IPv4 tunnel interface. See the next
to last paragraph in section 3.6 of:

  http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt

Thanks - Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Nov 2003 20:29:41 +0200 (EET)

Everyone,

Please discontinue this discussion at [email-masked] list.

Thanks,
 Pekka
  writing as v6-ops co-chair

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings