[OpenAFS] Network becomes terribly slow when cache manager flushes updates over xDSL

[Sean O'Malley]

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
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>

--------------------------------------
  Sean O'Malley, Information Technologist
  Michigan State University
-------------------------------------