[saga-rg] Fwd (hupfeld at zib.de): Re: SAGA Strawman API Version 1.0

[Andre Merzky]

Ha, finally someone really critical :-D

Thanks Felix, comments are invited.

Cheers, Andre.


----- Forwarded message from Felix Hupfeld <hupfeld at zib.de> -----

> I think there is a problem in the foundation of the SAGA approach. The 
> underlying assumptions seem to be that:
> (a) prospective designers of Grid applications are unaware of distr. system 
> issues
> (b) distr. system issues are not fundamental, but can be solved by 
> technical means
> 
> on (a): Designers of Grid applications are presumably already writing
> parallel applications on clusters or large HPC machines. They are well
> aware that remote memory is not local memory and that they can't use DSM
> just like local memory without serious performance issues. To name one
> of the fundamental problems of writing distr. systems...
> 
> on (b): There are fundamental tradeoffs to be considered when building
> distributed systems (DS), like availability vs. consistency,
> scalabillity vs. consistency, ... State of the art of CS is that they
> can't be solved by technical means but are laws of the nature of DS. In
> practice that means: if you design an API for a DS, where you _must_
> state which consistency guarentees you give, you assume certain
> requirements of the user and force him into your choice of the tradeoff
> spectrum.
> 
> With assumptions (a) and (b), the designers of SAGA seem to persue an
> approach, where the user has a very-POSIX like API. Although the spec.
> ignores all DS issues, it seems to imply that the API gives the user a
> single-copy view of the overall Grid, which makes the strongest choice
> on consistency, but results in the worst possible scalability and
> availability.
> 
> To illustrate, I will elaborate on the File API, but the same arguments
> can be made for namespaces and logical files, replicas, ...
> 
> The spec. does not make any statements about the consistency guarantees
> of the read and write operations. I assume that should imply that it
> gives POSIX like read and write guarantees, resulting in bad scalability
> and availability. The authors must explicitly state that. If the
> consistency guarantees are left open and governed by the API
> implementation, no applications can be written towards that API. You
> can't write applications if you don't known when you will be able to
> read the data you have written on local or remote instances.
> 
> A solution to this problem would be the specification of required
> consistency guarantees by the applications at open() time. This,
> however, would require thorough research on conistency models and
> application requirements, so I can't propose a few of hand.
> 
> If SAGA choses to give single-system like guarantees, this must be
> explicititely stated. All interfaces that deal with data are unusable 
> without a
> specification of consistency guarantees.
> 
> However, if you chose to be as POSIX like as possible and have
> single-system semantics, why not directly use parts of the POSIX spec.
> and strip it down where needed?

----- End forwarded message -----

-- 
+-----------------------------------------------------------------+
| Andre Merzky                      | phon: +31 - 20 - 598 - 7759 |
| Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 |
| Dept. of Computer Science         | mail: merzky at cs.vu.nl       |
| De Boelelaan 1083a                | www:  http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands    |                             |
+-----------------------------------------------------------------+