Subject: Re: [dccp] PMTU issues

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

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

> 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 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

On Wed, 19 Nov 2003, Eddie Kohler wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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