[ogsa-dmi-wg] DMI Factory Concern

Ravi Madduri madduri at mcs.anl.gov
Thu Feb 22 19:51:46 CST 2007 

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

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

More information about the ogsa-dmi-wg mailing list