[ogsa-dmi-wg] DMI Factory Concern

Fri Feb 23 04:59:37 CST 2007

Folks,

firstly, thanks for the discussion - finally, DMI picks up in activity.

Secondly, I think Allan has a valid point in having concerns. I had them
too but was fond that we would solve them eventually. However, I strongly
believe that DMI needs to perform/specify protocol negotiation.

That'll be a quick answer; more technical elaboration and a possible
solution later today.

Cheers,
Michel

Ravi Madduri wrote:
> The value add DMI provides would be to make sure the QoS promise (SLA) 
> is met within the protocol specified for the task with management of 
> state of the transfers, asynchronous execution of transfers, reliability 
>   , finishBy semantics etc. I wonder how practical would it be to add 
> this functionality to DMI when there are'nt many (if any) existing 
> transport protocols that provide/support an interface that supports this 
> kind of interaction. I also wonder if any of our usecases actually do 
> protocol negotiation right now.
> 
> Allen Luniewski wrote:
>> 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 at 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 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
> 

-- 
Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com
Fujitsu Laboratories of Europe
+44 20 8606 4834

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20070223/4e125be5/attachment.pgp 