Re: [dccp] PMTU issues

[Fred Templin <ftemplin@iprg.nokia.com>]

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
ftemplin@iprg.nokia.com

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