Subject: Re: [decade] Updated DECADE Charter

From: Song Haibin <[email-masked]>
Date: Mon, 01 Feb 2010 17:17:17 +0800

Hi Börje,

Thanks for your interest. For the second comment on mobility, I don't think
you mean IP mobility protocols. The existing underlying protocol can already
support it. So there is no problem for the basic mobility issue.

As for i3, I know some about it and like it very much, and do think it works
well for mobility issues.  In DECADE, the DECADE server can already be an
anchor point. That said, the sender can send the data to its in-network
storage, and it does not need to be aware of the receiver's address. The
receiver can also get the data from this in-network storage and does not
need to be aware of the sender' address (although the receiver needs to get
the authorization to access the data, e.g. get a token from the sender) .
The DECADE server can maitain the connectivity when both the end-points
move. Just like what an i3 server does. But we don't need to describe it in
so detail in the charter. Are you satisfied with this or is there any new
function that you think should be basically supported by DECADE?

I also support to leave automatic data migration out of scope.

Xie Xie,
Haibin

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Richard Alimi
> Sent: Monday, February 01, 2010 12:56 PM
> To: Börje Ohlman
> Cc: [email-masked]
> Subject: Re: [decade] Updated DECADE Charter
> 
> Hi Börje,
> 
> On Friday 29 January 2010 9:43:38 am Börje Ohlman wrote:
> > Hi Richard,
> > 
> > I don't think support for mobility necessarily needs to make things 
> > complex, not if it is designed in from the beginning (e.g. see 
> > Internet Indirection Infrastructure (i3)), it is when it is 
> added as 
> > an afterthought things get complex. That is why I think 
> that support 
> > for basic node mobility should at least be considered.
> > 
> > I also think the two issues 'copies' and  'mobility' are 
> related to a 
> > certain extent. Being able to use locally available copies 
> rather than 
> > to have to access 'your own' remote or migrated copy can simplify 
> > mobility significantly.
> 
> Comments below...
> 
> > 
> > Please see further comments in line below.
> > 
> >     Börje
> > 
> > Richard Alimi wrote:
> > > Hi Börje,
> > >
> > > Thanks for taking the time to provide feedback. See below:
> > >
> > > On Wednesday 27 January 2010 4:01:19 am Börje Ohlman wrote:
> > >> Hi All,
> > >>
> > >> I think this charter starts to look quite good.
> > >> Though here are two issues I would like to see added to it.
> > >>
> > >> 1) How DECADE deals with copies in the in-network 
> storage I think 
> > >> it would be good to make clear if the network part of 
> DECADE can  
> > >> benefit when multiple users/application stores the same 
> information 
> > >> object (e.g. file). Is it then possible for DECADE to store only 
> > >> one copy of the information object or is it required to store 
> > >> multiple copies of the same object?
> > >
> > > While this is an optimization that could be worthwhile, 
> my feeling 
> > > is that it does not matter with respect to the protocol 
> between the 
> > > application and the storage.  If the storage system were to have 
> > > such a feature, it may be an implementation detail.  Are you 
> > > envisioning a case where this would surface in the protocol?
> > 
> > How you refer to an object, e.g. by relative or absolute 
> references, 
> > has an influence on how easy it is to identify a copy of an 
> object. If 
> > you use relative path names to refer to objects see that 
> two objects 
> > are the same.
> 
> I think I am beginning to see where you are coming from here. 
>  My response above was in the more general case, where the 
> storage system automatically detected objects that contained 
> exactly the same data, and then, as an optimization in the 
> implementation, deleted one and replaced it with a link (e.g, 
> a hardlink) to the other.  This would have the effect of 
> reducing redundancy across multiple users using storage at 
> the same server.  Note that it would *not* be safe to only do 
> this based on the naming of the object.
> 
> However, it sounds like you are referring to a user 
> explicitly creating links to objects within his or her own 
> storage - is this an accurate characterization?  If not, can 
> you provide an example?
> 
> When it comes to defining exactly which management operations 
> would be 
> supported by DECADE, this is already in the charter.   I 
> believe links between 
> objects would be considered a management operation and this 
> would be fair game.
> 
> You've also touched on the naming here.  This is something 
> that would have to be decided as well within the WG, but is 
> probably not important for the charter.
> 
> I'd be good to get opinions from others here as well.
> 
> > >> 2) Should DECADE support mobility of 
> terminals/users/applications?
> > >> A lot of today's terminals are mobile, e.g. laptops and 
> smartphones.
> > >> When they move should their in-network storage move with them or 
> > >> should access to their storage be made by tunneling back to some 
> > >> type of "home storage"?
> > >
> > > I think this is a good discussion to have and it would be 
> great to 
> > > get opinions from others. My personal feeling is to leave 
> automatic 
> > > data migration out of scope, since it may make the system 
> quite complicated.
> > > In particular, one of the things we explicitly mentioned as 
> > > out-of-scope was finding the "best" in-network storage element. I 
> > > think that what you mention here for mobility is somewhat 
> related to this.
> > 
> > If we don't want to get into data migration and trying to find 'the 
> > best' copy I would settle to for agreeing that it is ok to 
> use locally 
> > available copies if they happens to be around. As I indicated above 
> > this could simplify giving some basic support for nodes 
> that are not 
> > permanently stationary in the network.
> 
> Yes, I certainly agree that it should be possible for clients 
> to use a closer copy if it is available.  One way I can see 
> for providing such functionality without needing automatic 
> data migration is for a client to locally have a list of 
> DECADE servers (e.g., DNS names) available to it, and the 
> client locally picks the most-desired one with the data it needs.
> 
> Are there other possibilities (not using data migration) that 
> you were thinking about?
> 
> > > The idea is that we'd like to be able to use existing 
> storage access 
> > > protocols where possible.  The candidates that we mention in the 
> > > charter currently are NFS and WebDAV.  However, in 
> DECADE, we need 
> > > to pass some additional information between the user and 
> in-network 
> > > storage (e.g., resource control and access control).  Do you have 
> > > suggestions for an alternate wording here?
> > 
> > If the current thinking is that we want to try to find a suitable 
> > protocol to be reused I think it is a bit premature to state that 
> > developing a new protocol is out of scope before we have 
> even defined 
> > the requirements for the functionality of the new protocol.
> 
> We have an initial copy of the requirements draft and have 
> done some initial thinking about how it might be applied to 
> NFS or WebDAV.  We have also left the charter open to 
> providing extensions where necessary.
> 
> Is there certain functionality that you believe would just 
> fundamentally not align with such protocols (meaning 
> extensions would not be a good approach)?
> 
> --
> Richard Alimi
> Department of Computer Science
> Yale University
> _______________________________________________
> decade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade
>