[dmis-bof] Updated Charter

Tue Mar 14 16:34:20 CST 2006

Bill,

By policy I simply mean the ability to specify things such as:
        1. When must the transfer complete by
        2. How much network bandwidth is it allowed to consume
        3. How much is it allowed to load the source (destination) points
        4. If we were in a charge back environment, how much am I willing 
to spend for the transfer
        5. Constraints on routing the in-flight data
There are probably others, and not all of these might be appropriate for a 
first transfer specification, but hopefully this gives you the idea of 
what I thought needed to be covered.

As for management, yes, I was thinking of things such as cancel, suspect, 
resume and status.  If these kinds of functions are in-scope, that is what 
I think is necessary.  It then becomes an item of discussion within the WG 
as to how to provide those functions.

Allen

"William E. Allcock" <allcock at mcs.anl.gov> 
03/14/2006 02:21 PM
Please respond to
<allcock at mcs.anl.gov>

To
"'Allen Luniewski'" <luniew at almaden.ibm.com>
cc
<dmis-bof at ggf.org>, "'Michel Drescher'" <Michel.Drescher at uk.fujitsu.com>, 
<owner-dmis-bof at ggf.org>, "'Robert B. Wood'" <Robert.B.Wood at Sun.COM>
Subject
RE: [dmis-bof] Updated Charter

From: Allen Luniewski [mailto:luniew at almaden.ibm.com] 
Sent: Tuesday, March 14, 2006 3:39 PM
To: allcock at mcs.anl.gov
Cc: dmis-bof at ggf.org; 'Michel Drescher'; owner-dmis-bof at ggf.org; 'Robert 
B. Wood'
Subject: RE: [dmis-bof] Updated Charter

I find the proposed charter fundamentally sound.  I do have two small 
issues to raise. 

I am surprised that it does not address policy control of data movement. 
The charter is mute on the subject of Policy so it does not seem to 
consider that out of scope.  Policy based data movement seems to be an 
essential aspect of a data transport mechanism in the evolving grid space. 

Ummm.... I certainly would not agree that anything not explicitly 
mentioned is not considered out of scope.  I personally hate the word 
policy because every body means something different by it.  Right now, my 
default answer would be that we didn't explicitly specify it as in scope, 
so it is out of scope.  If you give me a better idea of what you had in 
mind, I can try and comment further. 

I expected (hoped?) to find words asserting that management of an 
in-progress data transfer was in scope but did not.  Is the belief that 
existing management mechanisms (e.g., WSDM) are sufficient?  Is it 
something that will fall out of the work described?  Or is it out of 
scope?  Management of an in flight data movement by the interested parties 
seems so essential to me that I am surprised by the silence in the 
charter.  At the least, I would like to see the charter state whether or 
not management issues are in scope or out of scope.  (I can not decide if 
the "User Management" item in section 2 is about this issue.)  

Again, it depends on what exactly you mean by management, but if you mean 
things like suspend, cancel, status, etc., I know that RFT has such 
functionality, and I suspect the others do as well.  I believe such 
capabilities are required, as to whether we are WSDM compliant, I have no 
idea.

Bill 

Allen

"William E. Allcock" <allcock at mcs.anl.gov> 
Sent by: owner-dmis-bof at ggf.org 
03/14/2006 12:29 PM 

Please respond to
<allcock at mcs.anl.gov>

To
"'Robert B. Wood'" <Robert.B.Wood at Sun.COM>, "'Michel Drescher'" 
<Michel.Drescher at uk.fujitsu.com> 
cc
<dmis-bof at ggf.org> 
Subject
RE: [dmis-bof] Updated Charter

Ok, next iteration is attached.  We tried to address the comments we had
received so far.

Bill 

> -----Original Message-----
> From: owner-dmis-bof at ggf.org [mailto:owner-dmis-bof at ggf.org] 
> On Behalf Of Robert B. Wood
> Sent: Tuesday, March 14, 2006 10:07 AM
> To: Michel Drescher
> Cc: allcock at mcs.anl.gov; dmis-bof at ggf.org
> Subject: Re: [dmis-bof] Updated Charter
> 
> In my opinion, "4th party data transfer" as a term such as described 
> below offers more debate than value.  To my understanding, a 
> 3rd party 
> copy operation is a data transfer between two data stores that is 
> initiated by [at least] one of the data stores or devices themselves, 
> without the aid or instruction of the user or their 
> server/application 
> code.  It was originally coined in the realm of data backup.
> 
> When an agent of the user (including the user him or herself) 
> initiates 
> a data transfer and the data transfer path includes the 
> user's system, 
> that is a first party operation.  When an agent initiates a data 
> transfer directly between two data stores or devices, without placing 
> their server in the data stream, this is an extended data movement 
> operation; what is referred to as extended copy or serverless 
> backup in 
> the data backup realm.
> 
> The usage of these terms is pretty well codified in the SCSI-3 
> specification and implemented in storage products. 
> 
> I'm not suggesting that management of agents, like the "truly 
> independent service" that Michel describes is trivial, in 
> fact the data 
> security aspects can be quite challenging.  Also the line 
> between direct 
> control and independent operations is pretty fuzzy, as data movements 
> rarely occur without some user involvement, be it simply an 
> exersize of 
> a service level agreement with the data storage service provider[s].
> 
> Just a couple of comments to the comments to the comments ... Bob
> 
> Michel Drescher wrote:
> 
> > Bill,
> >
> > some comments, related to the comments you put in the 
> charter document:
> >
> > 4th party data transfer:
> > I see 3 different scenarios for data movement. Let's assume 
> we have a 
> > (data) source and a (data) destination. We also have a user that 
> > wants data moved. If the user is the source, we have a direct pull 
> > case, if the user is the destination, then we have a direct push 
> > case. If the user tells the source to move some data to the 
> > destination, then this is 3rd party push, if the user tells the 
> > destination to get some data, then this is 3rd party pull.
> > Well, if the user tells a truly independent service to initiate a 
> > data transfer from source to target, then this is very 
> similar to 3rd 
> > party data transfer, but different enough as there is a 4th 
> instance 
> > participating in the data movement.
> >
> > Transport protocols:
> > Yes I meant application level protocols from a network 
> point of view, 
> > such as GridFTP, HTTP, FTP, etc.
> >
> >
> > Regarding the timeline:
> > The short term planning is ambitious, but manageable, I think, 
> > especially if we can appreciate broad contribution support.
> >
> > Cheers,
> > Michel
> >
> > On 13 Mar 2006, at 22:41, William E. Allcock wrote:
> >
> >> All,
> >>
> >> Michel and I have updated the charter based on discussions 
> that  took 
> >> place
> >> at GGF16.  They are already scheduling slots for next GGF, so we 
> >> need to
> >> ratify this charter ASAP and become a full fledged working 
> group.  The
> >> charter is short, only a couple of pages of text and a table with 
> >> goals and
> >> timelines.  This shouldn't take long, so please take a few 
> minutes 
> >> now and
> >> review this.
> >>
> >> In particular we would like comments on:
> >>
> >>  - Do you agree with the focus and scope
> >>  - Do you think the Goals and timeline are reasonable? 
> Are we missing
> >> anything?
> >>  - Which documents / implementations would you be willing 
> to work on?
> >>
> >> Thanks, and I hope to see you in Tokyo.
> >>
> >> Bill
> >>
> >> ---------------------------------------------------------------
> >> William E. Allcock
> >> Argonne National Laboratory
> >> Bldg 221, Office B-139
> >> 9700 South Cass Ave
> >> Argonne, IL 60439-4844
> >> Email:           allcock at mcs.anl.gov
> >> Office Phone:    +1-630-252-7573
> >> Office Fax:      +1-630-252-1997
> >> Cell Phone:      +1-630-854-2842
> >>
> >> <charter-v3.doc>
> >
> >
> 
> -- 
> Bob Wood
> Network Storage Architecture Office
> Sun Microsystems Inc.
> 
> 303.395.3801 (x43011)
> Robert.B.Wood at Sun.com
> 
> 
[attachment "charter-v4.doc" deleted by Allen Luniewski/Almaden/IBM] 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dmis-bof/attachments/20060314/1dd29575/attachment.html 