1. Mass Storage System Forum HEPiX Vancouver, 24/10/2003 Don Petravick (FNAL) Olof Bärring (CERN)

2. technical areas of concern? interoperability data movement user application interfaces wrap on top of local MSS APIs identify necessary extensions beyond existing standards interfaces, e.g. pre-staging, access hints monitoring security obstacles roadmap inter-site storage resource management scheduling of large transfers with respect to local load cooperate on best use of WAN resources seamless extension to the local resources managed by the local MSS collaborate with WAN experimentalists on management interfaces for routing and circuit switching what else...?

3. data movement have gridftp and bbftp for the data movements do we need more? is file movement sufficient or are there some good arguments for working on WAN file access? do we need being informed about layer- 5 (and above) protocols

4. user application interfaces with user applications being transparently scheduled to run on any site a common layer for file access is needed two approaches it’s the headache for higher level components closer to the applications, e.g. ROOT, POOL it’s our headache we should at least agree on common denominator API that can be wrapped on top of our existing APIs (e.g. RFIO, dCap) commit to implement and support the API for our MSS GFAL has been developed for LCG

5. extensions beyond POSIX Pre-staging of files before submitting a CPU job is another popular concept however, resource reservation is a mixed blessing massive use implies locking up resources and lead to data starvation for running jobs competing reservations may lead to over- allocation/deadlocks there are more clever ways to pre-stage but no standard interface (à la POSIX) to express them

6. inter-site storage resource mgmt SRM implements some level of negotiation it allows client to provide precise resource estimation the server can basically just answer yes or no client often needs to negotiate with at least two SRMs and maybe also request WAN bandwidth is SRM too generic? do we need extensions for tighter service negotiation between large MSS installations?

7. WAN resources can we leverage some of the work going on for optimizing WAN transfers? do we want to do that? is MSS just a matter of managing storage or is it about managing data flows? seamless extension of local resources “WAN mover” problem: no means for optimal sharing. Lack management APIs for WAN routing

8. Large Systems and Wide Area Networks Large storage systems at several labs are developing “grid side” interfaces. Advanced Networking is being explored generally and under the banner of LHC in particular. Large storage systems have immense bandwidth and can present a realistic mix of traffic to research networks. Network researchers are interested in end-to- end performance, which includes interaction with “disk.”

9. Some Salient Network Research: Layer 1-3 Layer 1-3: Lambda Networking – light path circuits for substantial all of the paths. Requesting circuits and dealing with unavailability, faults Network details of getting to such circuits

10. Layer 4: Example: TCP stacks with good properties in the WAN. AIMD “additive increase, multiplicative decrease.” Issues of fairness, when conventional TCP is present.

11. Layer 5+: Layer 5 example:-. Current generation of // FTP’s. Next generation of FTP (or more general protocols). Layer 5+ :-. Ability to take high level applications and steer them on to a research WAN, (possibly by making small changes to storage system).