[ogsa-dmi-wg] DMI Factory Concern

[Ravi Madduri]

I am just thinking out loud here and I reserve the right to take back 
anything I said here later, if needed :)

I think the DMI factory should stay away from QoS goals of the transfer 
that involve protocol negotiation with sources and sinks. Also while I 
am at it, I think protocol translation is also out of scope for DMI 
factory. I think that the protocol to be used for the transfer is 
pre-determined by a higher-level service or user and is provided for the 
DMI factory. This request goes to the factory and a instance is created 
provided the factory knows how to talk the specified transfer protocol. 
Ideally, the user or the service invoking DMI factory should query the 
factory for the supported transfer protocols and then make a decision 
whether to send the transfer request to this DMI factory or not. Once 
the user/service sends the request to the DMI factory with a specific 
transfer protocol and QoS parameters(remember the QoS params are 
sometimes specific to the transfer protocol that is being used so there 
is no negotiation), the factory would then invoke the appropriate 
transfer mechanism with the said QoS parameters. I think QoS negotiation 
with respect to the transfer protocol should be done even before the 
request reaches the DMI factory.

Allen Luniewski wrote:
> 
> I have read through the current draft of the specification.  My big 
> concern after reading this is the way in which a DMI factory is going to 
> get its job done.
> 
> Consider what a factory has to do.  It is given a source, S0, and a 
> sink, S1, to move data between, as well as other important information. 
>  But let's concentrate on the source and sink aspects at this point. The 
> factory also support doing transfers using one or more transfer 
> mechanisms/protocols, call them P0...PN.  The fundamental problem facing 
> the factory is to find which of the Pi are supported by both S0 and S1 
> and which will meet the QoS goals of the transfer.  I am struggling to 
> understand how the factory can find which of the Pi are mutually 
> supported.  The current specification provides no architected mechanism 
> for making this determination.
> 
> With no architected mechanism, the factory must have a means, presumably 
> specific to each Pi, of asking S0 and S1 if they support Pi.  I suppose 
> that this is a solution but doesn't it then place a requirement on the 
> specification of each possible transfer mechanism to provide such an 
> interface?  Do all transfer mechanisms have this, especially those 
> already with approved specifications or, even, de facto specifications?
> 
> Another approach would be for the factory to run through the Pi trying 
> to create a transfer using that Pi.  Possible, does not add additional 
> requirements on the specifications of transfer protocols but it sure 
> seems inefficient to me.
> 
> Is there some other way of doing this without placing something in the 
> DMI spec?
> 
> In the Data Architecture document 
> (http://forge.ogf.org/sf/go/doc14053?nav=1) we explicitly attacked this 
> problem. We proposed a simple interface provided by each data service 
> that allows the DMI factory to get a list of the transfer protocols 
> supported by that service.  This seemed to us to be simple to specify, 
> effective in solving the problem and easy to implement in a data 
> service.  I suggest that DMI take this approach and architect such an 
> inquiry interface between DMI factories and sources/sinks.
> 
> Comments?  Suggestions?
> 
> Allen Luniewski
> IBM Cross Brand Services
> IBM Silicon Valley Laboratory
> 555 Bailey Ave.
> San Jose, CA 95141
> 
> 408-463-2255
> 408-930-1844 (mobile)
> 
> 
> ------------------------------------------------------------------------
> 
> --
>   ogsa-dmi-wg mailing list
>   ogsa-dmi-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-dmi-wg

-- 
Ravi K Madduri
The Globus Alliance | Argonne National Laboratory
http://www-unix.mcs.anl.gov/~madduri