Suggestions for dCache SRM improvements
Matt: Measure the time it took to execute a request and set the limits dynamically as a function of this time. Initiate the refusal of work gradually with increasing probability as the queues increase (similar to random early detection (RED)).

Ideas for upcoming meeting on Storage Management future in DESY. Move away from GSI. Motivation: Performance Improvements. Security implications from usage of unmaintained versions of PureTLS libraries. Alternatives would be to use standard TLS protocol, which would enable us to choose from a large variety of the implementations. Issue that needs to be addressed is how to perform delegation. GT4 Delegation service? Alex Sim: We experimented with using Delegation Service and it could be used with SRM interface. There exists a gLite delegation service that is incompatible with globus. Only one of delegation services should be adapted into the SRM Spec. Delegation service should be based on open specification and should not create dependancies on particular implementations or libraries. 

Gerd: SRM makes denial of service easy to implement intentionally or by mistake. Example is requests for get TULRs that are not released, performed by pilot jobs, causing production problems in FZK. Tigran :count number of the available transfers in doors when specifying the limits on TURLs. 
Gerd: Start limiting TURLs number given out as we approach the upper limit of the rate that doors can support. 

Feature negotiation and versions of protocol.
Patrick: Some new features could be added gradually. Matt: expanding WSDL would not harm anyone too. 
Paul: gSoap supports http headers. We could use this for implementation of the feature negotiation and for listing features that client understands. 
Patrick: this could be used in the short term to advertise the client support of async ls. Tigran: use ideas for protocol negations from NFS4.1.

Alex: Motivation for the DESY meeting is the complains by the user community. 
Patrick: FTS logs will be analyzed and statistics about the average time spent  by SRM requests in various states will be presented. 
Patrick: Could we analyze CMS T1 data and present our view on execution of SRM requests. 
Paul provided us with an idea on how to visualize the request executions. X axis is a relative or absolute time, Y axis is a state of request, request execution is visualized as the set of segments connecting points, each point is the (time,state) plotted at the time when state is first assumed. Plot would include a number of request execute over a certain period of time. 
Dmitry: It would take me at most several hours to implement this. 
Dmitry: Ping should have a return code. 

Tanya, Ted: Different SRM Servers use different SURL structures, would be nice to standardize this behavior. Authentication failures are hard to debug. Logging is excessive and not very useful. Error propagation to the client is broken. 
Patrick, Gerd: Provide more info in Status Code description string. 
Ted: Should SRM be integrated with information provider to enable system wide status query?
Timur: May be InfoProvider should be a separate standard interface to storage? GLue might already provide some info in a standard way.
Ted: Having a standard way to get info from storage into glue schema would help a lot. 
Paul: in dCache we can easily publish glue schema ldap via http. 
Ted requested to include this topic in DESY meeting agenda. Patrick agreed.


DesiredTotalRequestTime topic. We are interested in this. Requires pre-analysis of effort needed to implement in dCache.

Ted: Space Reservation can be extended? Only lifetime.  Dmitry: size can be extended using admin interface. 

PAtrick: Alex, are there complaints about srm functionality from clients?
Alex S.: clients use libraries and do not know much about srm level functionality.

Gerd: Is the issue of long term prospects of the SRM as management protocol is going to be brought up? Are the experiments planning to keep on using SRM at all in the future? 
Patrick: If we perform when LHC startup, then experiments will continue using SRM. 
Gerd: Some of the functionality is not implemented because dCache internally does not support certain concepts. We need to work on internal architecture improvements and anticipate future usage. We might not have effort to implement new features in SRM. 
Patrick: Since Ian Bird said "SRM might be dead soon" we need to be ready for the next interface.