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