[dmis-bof] Vote for submission of Charter

[Arie Shoshani]

Michel,

I think we are converging now in terms of the scope of MDIS and its 
relationship
to GSM ( and the SRM functionality in particular).

I think that understanding could be (in time) articulated for GGF, so 
the boundaries between this DMIS-WG (I assume it will be approved) and 
GSM-WG are clear.

Thanks, Arie


Michel Drescher wrote:

> Hi Arie,
>
> see comments inline below:
>
> On 21 Mar 2006, at 23:35, Arie Shoshani wrote:
>
>> [...]
>>
>> You say:
>> "When requesting a data movement, I have certain expectations that  I 
>> would like to be met. It is simply not always true that a service  
>> can meet these expectations; for example if I request a data  
>> transfer to be carried out using GridFTP but the service supports  
>> only MTOM, then the request would fail."
>>
>> Now, suppose that the expectation is that the data will be moved to  
>> some storage system and that the entire volume is 1 TB.  Which  
>> component will take care of making sure that the user is allowed to  
>> move a TB, and that there is enough space allocated?  I don't think  
>> the DMIS should do that.
>
>
> Ack, that would not be the DMIS.
>
>> It seems from what you suggested below (the "hierarchical model"),  
>> that in this case the data movement call could be made to an SRM  
>> (which will allocate the space) and it will call the DMIS for the  
>> actual transfer.  Is this how you envision this working?
>
>
> Again, ack.
>
>> Another expectation could be that the TB movement should happen in  
>> 24 hours.  Would the DMIS try to estimate whether this can be  achieved?
>
>
> In case you mean that the movement should *start* in 24 hours, the  
> DMIS can estimate if this is feasible by assessing its current  
> movement queue and schedule, and available resources. In case you  
> meant that the movement has to be finished within the next 24 hours,  
> yes, the algorithm to assess whether this is feasible or not won't be  
> much different.
>
>> It seems that in order to provide DMIS with "the parameters that  
>> directly affect the data movement itself sorted out before the data  
>> movement will actually take place" (to quote what you said below),  
>> another fairly complex service would be needed to set it up.  Maybe  
>> in simple use cases, one can assume certain parameters, so they do  
>> not have to be setup.
>
>
> I must admit, I am lacking rhetoric skills here. I really didn't know  
> how to express myself better. So let's just see in practical work how  
> and where we will end up with this.
>
>> Finally, I agree with your comment on what resources the DMIS could  
>> report on (resources it has consumed to fulfil a data movement  
>> request, e.g. bandwidth usage, CPU cycles(?), total bytes moved,  
>> etc.).  While this may not be easy to implement, it will be of  great 
>> value to the component that invokes it, especially if that  was an SRM.
>
>
> Yes I agree here, though some I expect to be easy to implement, some  
> rather difficult or impossible (e.g. CPU cycles in Java based WS). So  
> I expect that we will end up so that a DMIS MUST report resource  
> usage, but some resources mandatory and others not.
>
>
> Cheers,
> Michel