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 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 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
