OGSA-DMI Telcon - 07/11/07
==========================

Attendees:

 	   Steve Newhouse, Microsoft
 	   Mario Antonioletti, EPCC
 	   Allen Luniewski, IBM
	   Michel Drescher, Fujitsu

	   
Agenda:

1.       IPR Notice
2.       Previous Minutes and Action Review
3.       Agenda Bashing
4.       Issues Arising
5.       Spec Progress
6.       AOB

Actions:

[Ravi] Resolve minor comments on the spec.
[Ravi] Come up with a proposal on how to represent data aggregates
        (e.g. multiple files) with Data EPRs to the mailing list.
[Ravi] Come up with a proposal for a multiple retries property to the
        mailing list.
[Steve/Michel] Come up with a proposal for Data ERPs that can deal with
        the three scenarios proposed below.

http://www.ogf.org/pipermail/ogsa-dmi-wg/2007-October/000293.html

+---

Discussion on the Data EPRs and scenarios was postponed until Ravi
becomes available or comments on the suggestions proposed by Michel:

http://www.ogf.org/pipermail/ogsa-dmi-wg/2007-October/000293.html

and Steven:

http://www.ogf.org/pipermail/ogsa-dmi-wg/2007-October/000294.html

Discussion thus proceeded on how to address transfer failures by the
DMI architecture.

DTF transport negotiation is done by protocol matching but, at run
time, other factors may come into play that prevent the transfer from
succeeding, e.g. firewalls. At the moment this means that the DTI will
report the failure to the client but the client has no current way to
communiccate this information back to the DTF - the client can talk to
the DTF again to effect the transfer but this will probably lead to
the same protocols being chosen and thus reproduce the same
failure. Allen suggested three possible solutions.

http://www.ogf.org/pipermail/ogsa-dmi-wg/2007-November/000301.html

Neither 1 and 2 are preferred, 3 requires active negotiation which is
not in scope for this version of the spec. Not clear that it would not
be able to do the transfer unless it performed a small test.

The following solutions were discussed all starting from the point
where the data transfer has began with the DTI but then failed:

1. The DTI returns the failure to the client with modified DEPRs to
   the client - effectively new ones with the failed protocol removed
   from the list of supported protocols. The client can then use these
   DEPRs to retry the transfer through the DTF.

2. The DTI returns the failed protocol to the client, the client modifies
   the data EPRs (as in 1 by removing the failed transport protocol)
   and resubmits these to the DEPRs.

3. The client passes on the DEPRs to the DTF as well as any failure
   messages returned by the DTI to the DTF which is then informed of
   the protocols that do not work (this might mean aggregating
   multiple failure messages which does not seem desirable).

4. The DTI is able to communicate an outcome of a transfer to the DTF
   which is then informed of what protocols do not work and it may be
   able to act on this.

5. There is auser agent between the DTF and DTI that maintains state
   and is able to apply some re-try policy on behalf of the client.
   This would maintain the clean interfaces and state models already
   in the spec.

Michel is not at all keen on 1 as the minting of the DEPRs should be
done by third parties. Allen not keen on 2 as this is making clients
do stuff that should not really be in their scope. Idea now is that
interested parties will flesh out the use case above (or some other)
that most appeals to them noting the pros and cons. It was felt that
we should not produce a first version of this spec that does not 
address this problem.
 
Other factor addressed in the call was when the DTF can match more
than one protocol - how does it chose what protocol to use? The
fastest? The cheapest? etc? It was thought that for version 1 of the
scope this woul dnot be addressed - i.e. the client does not provide
hints or QoS parameters BUT the DTF should publish what algorithm it
will use to choose a transport protocol when there is more than one
valid choice.

There will be no DMI call next week in part to SC07 and other
committments.

The next call on the 20th of November at the same time (this is so as
to not clash with the night before thanks giving).