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