This is a great idea! If someone -is- going to do this, I think they would have a few basic questions.
-does the client/server store the MTU on a per connection basis already? (how hard is this to implement?) or should the server keep dropping to the lowest common denominator? Should all servers be using the same MTU, or should the connection to each say fileserver be negotiated individually? -Is there a mechanism for this communication already? ie if I set maxMTU on the server, does the client set itself to the same maxMTU also? if so, what is the priority does the client win over the server, or the server win over the client? Autodetection shouldn't win and you should be able to manually override/disable it. -icmp shouldn't be used. Some BOFH block/drop icmp. -should there be a renegotiation or autodetect after the initial connection? ie maybe the failover link doesn't have the same MTU as the primary link? -is there a standard way to do UDP mtu link detection on any platform already? Anything else? Sean On Wed, 8 Jul 2009, Simon Wilkinson wrote: > One interesting project, for someone who's looking to write something > really useful for OpenAFS, would be to implement path MTU discovery. > This was original an idea for this year's Summer of Code, and it's > description there read ... > > OpenAFS uses a UDP based RPC transport called Rx. RX uses the endpoint > maximum transfer units (MTUs) to determine how large a packet may be > transmitted without requiring the packet to be broken into fragments > on its journey. The prevalence of IP tunnelling, typically with > reduced MTUs, on modern internet topographies, means this is often not > an accurate way to determine true maximum packet size. This project > would develop and integrate into Rx a mechanism to discover the MTU of > the path rather than merely the endpoints, resultingly tuning packet > sizes accordingly. > > Cheers, > > Simon. > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info > -------------------------------------- Sean O'Malley, Information Technologist Michigan State University ------------------------------------- _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
