Comments below.

Allen Luniewski
IBM Cross Brand Services
IBM Silicon Valley Laboratory
555 Bailey Ave.
San Jose, CA 95141

408-463-2255
408-930-1844 (mobile)

Ravi Madduri <madduri@mcs.anl.gov> wrote on 02/22/2007 05:04:46 PM: > 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

If the DMI factory is not determining the proper protocol to use then I question what value it is providing to its customers. This protocol negotiation is one of the primary benefits that DMI provides. And it is inherent that such protocol determination take into account QoS goals.
> am at it, I think protocol translation is also out of scope for DMI

Agreed. DMI should not be in the protocol translation game.
> 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

As I said above, if the caller of the DMI factory has predetermined the protocol to use, what value has DMI provided? Why not just go to the source and sink and create the transfer using the desired protocol?
> 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

I certainly agree that the DMI factory should advertise the set of protocols that it supports.
> 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

Although I agree that there are some QoS goals that are transport specific, it seems to me that there are a crucial set that are independent of the protocol being used. For instance, cost, bandwidth, amount of CPU to be used, security/encryption. One could easily argue that a "complete by" date is also a QoS parameter.
> 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.

I think that we have a basic disconnect here. If a DMI factory is not doing protocol negotiation, what value is DMI providing to its users? Why would a user get DMI involved? Why would the user just not use the desired protocol directly? There may be some but I don't see it right now.
> > 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@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