[ogsa-dmi-wg] Potential problem

Mon Nov 5 11:17:58 CST 2007

I think that there is a problem here and it is not an implementation one.

In Mario's example, the sink might very well support ftp within the
firewall.  But for security reasons it is not allowed to cross the
firewall.  At the same time one might conjecture that some other protocol
was valid across the firewall.  Since the DTI is created to execute a
particular protocol, all it can do in this case is report failure when the
FTP fails.  The DTI has no means to negotiate another protocol that might
work - that is the job of the DTF.  So reporting failure is all that it can
do.

At this point the client is in a difficult position.  If it just reinvokes
the DTF, we will just go around this loop again since nothing has changed.
If the error reported by the DTF has enough information, the client could
edit the DEPRs to remove the protocol that does not work.  This will
eventually lead to a successful transfer (assuming that the transfer is
possible) but seems to obviate one of the key reasons that DMI exists -
ease of use/simplicity for the client.  So, I regard this as an
unacceptable solution.

So what might work and retain the desirable properties of DMI?

1. The DTF could test the protocol to see if it works.  I am nervous about
this as it raises questions about what data is transferred, where is it
stored, how is the test undone, are there security issues, etc.

2. One could take a tact that says that when the DTF does protocol
negotiation, it informs the source (sink) as to the identity of the other
party involved in the transfer.  This then puts the onus on the source
(sink) to declare a protocol as unworkable. Unfortunately, this
reintroduces protocol negation into DMI which is something that we have
gotten away from (as I understand things, right now we basically assume
that the DTF just does matches based upon what it finds in the DEPRs).
This becomes, I think, just an implementation issue (assuming that we were
to choose to not architect the negotiation process) but one that we would
need to comment on in the document.

3. We could have the DTI go back to the DTF to choose a different protocol.
The problem with this is that this will result in a new DTI (since DTIs are
protocol specific) and there is no way to communicate this new DTI back to
the client who requested the transfer.

I lean towards option #2.  It addresses the problem at DTF time which is
when it seems most appropriate to address.  It is a natural part of
protocol negotiation (which I have always felt was the proper way to
architect this and not via the current DEPR based approach).  It is also
something that is easy to explain to DMI clients.

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

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

             Michel Drescher                                               
             <Michel.Drescher@                                             
             uk.fujitsu.com>                                            To 
             Sent by:                  Mario Antonioletti                  
             ogsa-dmi-wg-bounc         <mario at epcc.ed.ac.uk>               
             es at ogf.org                                                 cc 
                                       OGSA-DMI <ogsa-dmi-wg at ogf.org>      
                                                                   Subject 
             11/05/2007 08:35          Re: [ogsa-dmi-wg] Potential problem 
             AM                                                            

Hi all,

quick shot at face value:

I don't see a problem - I see this as an implementation detail.

Primarily, I see this problem as a fault of the sink not DMI, as the
sink returns an available protocol that effectively is impossible to
use (setting temporal skews aside).

Naïve DMI implementations may simply go forward and trust the
information supplied by source and sink, while more advanced
implementation may be able to solicit that information with
heuristics, statistical/historical information and active probing as
you described.

Cheers,
Michel

On 5 Nov 2007, at 16:04, Mario Antonioletti wrote:

>
> Hi,
>     Last week we were discussing comments to the OGSA Data document
> and
> something came up that is pertinent to DMI (Alle pitch in).
>
> Basically, suppose that the source and sink publish a set of supported
> transport protocols. Then, if client wants to effect a transfer
> between the source and sink, they would talk to a DTF. The DTF would
> negotiate a protocol supported at both ends and create a DTI to manage
> the transfer for the user. The issue is that there may be other
> factors that preclude that transfer from taking place - for instance
> as a simple example, if active ftp was chosen as the protocol of
> choice a firewall could stop this transfer from successfully
> completing. The DTI would not be able to communicate this back to the
> DTF as the two are logically dissociated. Is there an expectation that
> the DTF, would not only protocol match but also test out that the
> transfer protocol actually works between source and sink before
> creating the DTI? I'm not sure if this is an implementation thing or
> whether there is a deeper potential problem here - thoughts?
>
> Mario
>
> +---------------------------------------------------------------------
> --+
> |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9
> 3JZ.   |
> |Tel:0131 650 5141|mario at epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/
> ~mario/ |
> +---------------------------------------------------------------------
> --+
> --
>   ogsa-dmi-wg mailing list
>   ogsa-dmi-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-dmi-wg

(See attached file: PGP.sig)--
  ogsa-dmi-wg mailing list
  ogsa-dmi-wg at ogf.org
  http://www.ogf.org/mailman/listinfo/ogsa-dmi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20071105/4ddcd74f/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20071105/4ddcd74f/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic23039.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20071105/4ddcd74f/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20071105/4ddcd74f/attachment-0002.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/octet-stream
Size: 193 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20071105/4ddcd74f/attachment.obj 