[ogsa-dmi-wg] Potential problem

Michel Drescher Michel.Drescher at uk.fujitsu.com
Mon Nov 5 11:50:08 CST 2007 

Good explanation, thanks.

I was probably too imprecise by simply declaring it as an  
implementation detail. In fact, in hindsight I realise that I came to  
the conclusion that, after thinking along the lines Allen laid out as  
option 2, the only solution in the current situation is to make it an  
implementation (issue | detail).

But Allen's definitely right in that we should describe this in a non- 
normative section somewhere.

And I agree that a dynamic negotiation would have elegantly solved  
this solution. But we should stick now with with what e agreed on,  
and move on.

Cheers,
Michel

On 5 Nov 2007, at 17:17, Allen Luniewski wrote:

> 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)
>
> <graycol.gif>
> Michel Drescher <Michel.Drescher at uk.fujitsu.com>
>
>
> Michel Drescher <Michel.Drescher at uk.fujitsu.com>
> Sent by: ogsa-dmi-wg-bounces at ogf.org
> 11/05/2007 08:35 AM
>
> <ecblank.gif>
>
> To
> <ecblank.gif>
>
> Mario Antonioletti <mario at epcc.ed.ac.uk>
> <ecblank.gif>
>
> cc
> <ecblank.gif>
>
> OGSA-DMI <ogsa-dmi-wg at ogf.org>
> <ecblank.gif>
>
> Subject
> <ecblank.gif>
>
> Re: [ogsa-dmi-wg] Potential problem
> <ecblank.gif>
> <ecblank.gif>
>
> 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
> <graycol.gif>
> <pic23039.gif>
> <ecblank.gif>
> <PGP.sig>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20071105/863d7660/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20071105/863d7660/attachment-0001.bin

More information about the ogsa-dmi-wg mailing list