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