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)
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@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
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
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@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
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
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,
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
going to point. The presumably 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
-- Ravi K Madduri The Globus Alliance | Argonne National Laboratory http://www-unix.mcs.anl.gov/~madduri
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@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
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
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,
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
going to point. The presumably 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
-- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834
Folks, here're my thoughts and proposals concerning the current DMI architecture (actually, this is a result of a consultation of David Snelling). Following some sort of requirements list: 1) DMI needs to offer reliability to users 2) DMI needs to enable data movements across Grid middlewares 3) DMI needs to support more than one protocol 4) However, DMI does NOT need to offer protocol translation (i.e. source talks GridFTP, sink talks HTTP) 5) Instead, DMI does protocol negotiation between soource and sink. 6) Users need not know which protocol is employed to get the data movement job done. 7) DMI need not technically understand striping or replicas or what. 8) DMI need to understand the semantics of striping, replicas, etc. instead. 9) Once a protocol between source and sink is negotiated, DMI acts as the controller instance to that protocol. There are certainly more requirements necessary, but that's all I can think of for the moment. Having said that I support Allens concern how the factory solves the problem we describe as "protocol negotiation", and his example nicely illustrates that. So, DMI needs to find a solution. But how? One option would be to implement the interface at the source and sink as proposed in the Data Architecture document. My take on that option is that it would put too much burden on existing deployments to enforce this solution. The result would be that DMI would not be implemented/accepted. An alternative approach to that is as follows. As per current draft, the user of DMI obtains two EPRs out-of-bands that describe the data to be moved, from the source and sink, respectively. We also know, that the DMI Factory needs to sort out which data transport protocol shall be employed between source and sink location. The question is how. Most protocols do not have a mechanism built-in that allows for its automatic detection (that's how I understood Allen's concern). As a consequence, DMI should define at least information elements and identifiers thatdescribe supported protocols. For this proposal I assume DMI defines the following information elements in DMI namespace: [source protocol] The [source protocol] information element identifies a data transport protocol a node in a Data Grid supports when it acts as a source node in a DMI governed data movement. Its type is defined as xsd:QName. When conveyed in a SOAP message this information element is serialised into XML as follows (Pseudo XML code): <dmi:SourceProtocol>xsd:QName</dmi:SourceProtocol> [sink protocol] The [sink protocol] information element identifies a data transport protocol a node in a Data Grid supports when it acts as a sink node in a DMI governed data movement. Its type is defined as xsd:QName. When conveyed in a SOAP message this information element is serialised into XML as follows (Pseudo XML code): <dmi:SinkProtocol>xsd:QName</dmi:SinkProtocol> We need to define those two different information elements because some data transport protocols are asymmetric. For example, a node may support/implement HTTP, but only when acting as a sink (i.e. accepting only HTTP GET requests). For now I defined their types as xsd:QName but they can arguably be changed to any other suitable type (e.g. xsd:anyURI as in OGSA-ByteIO). To identify different data transport protocols, I define identifiers for now as follows: xmlns:dmi-prot="http://www.ogf.org/ogsa-dmi/2007/02/transport-protocols" 1) GridFTP v2.0 shall be identified by the QName "dmi-prot:gridftp-v20" 2) HTTP/1.1 shall be identified by the QName "dmi-prot:http-v11" 3) FTP shall be identified by the QName "dmi-prot:ftp" 4) Passive FTP, when supported as sink only shall be identified by the QName "dmi-prot:ftp-passive" However, we still have not solved the problem how source and sink should make available this kind of information, and how a DMII Factory would query this information. From here on, I can think of at least two different opptions how to solve this, thanks to the definition of the information elements as outlined above. The basic assumption is that, in a Data Grid, source, sinks and even DMI (once implemented) may or even may *not* be tightly coupled. So our approach should support both scenarios (or eeven more if identified). DMI needs that information from the source and sink, so DMI must normatively define that source and sink MUST provide a list of [source protocol]s and [sink protocol]s. Keeping in mind that the DMI functional specification must not make any assumptions on the message format being used when acquiring that information, we punt that into the rendering specifications that we will write in the future: a) OGSA WSRF Base Provile 1.0 The WSRF binding specification defines that the source and sink nodes MUST publish their [source protocol]s and [sink protocol]s as Resource Properties. A source node MAY also publish [sink protocol]s when it is also capable serving as a sink node. Respective for sink nodes. For example, the DMI Factory could invoke the rp:GetResourceProperty operation using the QName "dmi:SourceProtocol" when quizzing the source, and using the QName "dmi:SinkProtocol" when quizzing the sink, respectively. b) WS-I 1.1 Base Profile The WS-I binding specification defines that the source and sink nodes MUST publish their [source protocol]s and [sink protocol]s as a.1) respective lists of protocols in the wsa:MetaData section in the wsa:EPR describing the data source or data sink, respectively. For example, a non-normative wsa:EPR for the source may look like follows: <wsa:EndpointReference> <wsa:address>http://foo.example.org/bar/baz</wsa:address> <wsa:ReferenceParameters> [thinks like striping, replica, information etc] </wsa:ReferenceParameters> <wsa:MetaData> <dmi:SourceProtocol> dmi-prot:gridftp-v20 </dmi:SourceProtocol> <dmi:SourceProtocol> dmi-prot:ftp </dmi:SourceProtocol> </wsa:MetaData> </wsa:EndpointReference> c) WS-ResourceTransfer (??) No clue how this could/should be rendered here - WS-RT is evil. ;-) I think that this leaves enough freedom to the implementors of DMI to choose which rendering they want to use while specifying enough information eelements and formats so that DMI can accomplish its designated work effectively. Of course, all this information must be reflected in the specification, which of course it isn't at present... :-/ Cheers, Michel -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834
participants (3)
-
Allen Luniewski -
Michel Drescher -
Ravi Madduri