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

[Douglas E. Engert]

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
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>>
> 
> --------------------------------------
>   Sean O'Malley, Information Technologist
>   Michigan State University
> -------------------------------------
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444