Sean O'Malley wrote:
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?
For a start try:
rxdebug host.name.client -port 7001 -peers.
This shows the mtu the client is trying to use for each connection.
(how hard is this to implement?) or should the server keep dropping to the
lowest common denominator?
Client should try and figure this out, as each client may be different.
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,
Don't change the server, only the clients that are having problems.
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
--
Douglas E. Engert <[email protected]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
