Subject: Re: [decade] draft-zhu-decade-additional-requirements

From: 朱潇 <[email-masked]>
Date: Mon, 27 Jun 2011 11:07:02 +0800

hi, Richard and everybody

The draft draft-zhu-decade-additional-requirements I submitted last year is
about to expire. do you have some suggestions to update the version? and do
the DECADE requirement draft has adopted some suggestions of my draft?

2011/3/14 Richard Alimi <[email-masked]>

> Hi All,
>
> We've made all of these updates to the requirements document, with the
> exception of:
>
> > - If an object is deleted as it is concurrently being read, then the
> > server MAY continue to read it (lazy deletion), or it MAY discontinue
> > reading the object and signal an error to the client reading the
> > object.
>
> Upon looking at this again, it looks more like an implementation
> detail. If anything, this would result in a "non-requirement" in the
> document. However, it seems like a fairly low-level non-requirement to
> state at this time. I'd propose to leave it out for now and revisit
> this if it comes up again in the future.  Thoughts?
>
> Thanks,
> Rich
>
> 2011/3/2 Richard Alimi <[email-masked]>:
> > Hi All,
> >
> > I'll offer a summary of this discussion. Let me know if I missed
> > anything, or if there are objections/other thoughts on these proposed
> > resolutions.
> >
> > Redirection:
> > - We can add a requirement mentioning that DECADE may support
> redirection.
> >
> > Data Classification:
> > - I (personally) strongly disagree with attempting to classify access
> > patterns or applications. We could add something saying that explicit
> > hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf) could be
> > provided in DECADE.  However, I don't think we need to do something
> > new here. In particular, if the underlying storage/data transport
> > supports hints, a DECADE client or server can use it.
> >
> > Storage Status:
> > - Update section 5.1.6 to indicate that status information should
> > include permissions of stored objects, if applicable.
> > - Update 5.1.6 to indicate that status information should include
> > other information about resource usage (the clients own resources, or
> > resources used by other clients that have been authorized to
> > read/write objects or open connections to one's storage).
> >
> > Requirements for object deletion/overwriting:
> > - DECADE MAY have an overwrite flag (note that this may or may not be
> > necessary depending on our naming, but the requirements document
> > probably is not the place to take a stand on this at the current
> > point.)
> > - If an object is deleted as it is concurrently being read, then the
> > server MAY continue to read it (lazy deletion), or it MAY discontinue
> > reading the object and signal an error to the client reading the
> > object.
> >
> > Would this be sufficient to merge in the points from
> > draft-zhu-decade-additional-requirements-00 and this ensuing
> > discussion?
> >
> > Thanks,
> > Rich
> >
> >
> > 2011/3/2 Woundy, Richard <[email-masked]>:
> >> Folks,
> >>
> >>
> >>
> >> Do we have consensus yet about how the WG could have a single DECADE
> >> requirements document going forward? I can't tell the state of our
> >> requirements consolidation from the email thread below.
> >>
> >>
> >>
> >> It would be preferable if we could resolve this fully on the WG mailing
> >> list, but this is important enough to allocate some time at our meeting
> in
> >> Prague.
> >>
> >>
> >>
> >> -- Rich
> >>
> >>
> >>
> >> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> >> ??
> >> Sent: Sunday, January 16, 2011 9:02 PM
> >> To: Richard Alimi
> >> Cc: [email-masked]
> >> Subject: Re: [decade] draft-zhu-decade-additional-requirements
> >>
> >>
> >>
> >> hi, Richard:
> >>
> >>
> >>
> >> thanks for your reply:D
> >>
> >> additional discussion see inline:D
> >>
> >>
> >>
> >> 2011/1/14 Richard Alimi <[email-masked]>
> >>
> >> HI Xiao,
> >>
> >> 2011/1/12 朱潇 <[email-masked]>:
> >>
> >>> hi, Richard
> >>> see inline:D
> >>>
> >>> 2011/1/11 Richard Alimi <[email-masked]>
> >>>>
> >>>> Hi Xiao,
> >>>>
> >>>> On Mon, Jan 10, 2011 at 6:45 PM, 朱潇 <[email-masked]> wrote:
> >>>> >
> >>>> > hi, Richard, sorry for so late response because of be busy with
> other
> >>>> > projects.
> >>>> > some discussion see inline:D marked by red.
> >>>> >
> >>>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <[email-masked]>
> >>>> > wrote:
> >>>> >>
> >>>> >> Hi Xiao,
> >>>> >>
> >>>> >> Thank you for the draft.  Some comments on the requirements:
> >>>> >>
> >>>> >> Request Redirects:
> >>>> >>
> >>>> >> This would provide some additional freedom for the storage
> provider.
> >>>> >> I think it is reasonable since it doesn't necessitate additional
> >>>> >> complexity for the DECADE server, but allows it if desired.
> However,
> >>>> >> note that it may complicate some of the other components of the
> >>>> >> design. In particular, if there is a per-user quota for storage, is
> >>>> >> the user made aware of the quota at each in-network storage (if
> there
> >>>> >> is no shared storage between them)?  Resource sharing policies may
> be
> >>>> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean
> something
> >>>> >> different at DECADE server A than it does at DECADE server B).  At
> >>>> >> this point it may be best to just note these so they are
> documented,
> >>>> >> but since the specification of the resource sharing policies are
> still
> >>>> >> being contemplated for the basic case of a single server it may be
> >>>> >> premature to even try and solve them for the case supporting
> >>>> >> redirection.
> >>>> >>
> >>>> > actually, you mean two points, right?
> >>>> > 1. whether or not to be ware of the content at each in-network
> storage
> >>>> > and of course resource sharing policies can be impact in the request
> >>>> > redirection. your suggestion"just to note these so they are
> documented"
> >>>> > will
> >>>> > be ok, or DECADE server list with some parameters will be return for
> >>>> > user to
> >>>> > select the appropriate DECADE server, which can avoid the different
> >>>> > weighted
> >>>> > of the same parameter in server decision. but the parameter used in
> >>>> > select
> >>>> > the best DECADE server will be known for DECADE servers, in which
> other
> >>>> > complexities will be added. anyway, all the solution are the
> >>>> > implementation
> >>>> > issue, which, i believe, does not impact the necessity of the
> >>>> > requirement.
> >>>>
> >>>> In general, I'd agree that the decision about where to redirect would
> >>>> be an implementation issue.
> >>>>
> >>>> >
> >>>> > 2. you mean "the resource sharing policies are still being
> considered
> >>>> > in
> >>>> > a single server", so it may be premature to support redirection.
>  the
> >>>> > architecture and protocol will be badly impacted if the requirements
> >>>> > change.
> >>>> > so the designing can be  taken  step by step, but the requirements
> >>>> > should be
> >>>> > overall considered.
> >>>>
> >>>> I said that it is probably premature to consider how resource sharing
> >>>> policies works across servers (or even if we need to say anything
> >>>> about it) since we have not determined how to specify them (or rather,
> >>>> how little we need to specify in protocol) for a single server. I did
> >>>> not mean to imply that redirection could not be introduced as a
> >>>> requirement.
> >>>>
> >>>
> >>>>
> >>>> >
> >>>> >
> >>>> >>
> >>>> >> Multi-connection:
> >>>> >>
> >>>> >> I'm not quite clear on the intention of the requirement.  My
> >>>> >> understanding is that you wish the client to be able to have
> multiple
> >>>> >> connections open spanning multiple DECADE servers. Is that correct?
> >>>> >>
> >>>> >> If so, do we need this stated as a requirement or the protocol? Or
> is
> >>>> >> this a policy that would be allowed/disallowed by the storage
> >>>> >> provider?
> >>>> >>
> >>>> > yep, your understanding is right, the scenarios were just described
> in
> >>>> > draft as "soft handover in wireless environment and delete operation
> in
> >>>> > multi-servers". under these consideration, the authentication and
> >>>> > authorization need to be taken each time when setup connection with
> a
> >>>> > new
> >>>> > DECADE server, or just be taken only once during  the service?
> >>>>
> >>>> The DECADE server should need to do some sort of check on each new
> >>>> connection, regardless of whether the user has or previously had a
> >>>> connection open to a different DECADE server, right?  Note that the
> >>>> requirements don't indicate how authentication or authorization is
> >>>> done, and allow a server to make optimizations if it is enforcing the
> >>>> same permissions.
> >>>>
> >>>> Can you indicate where the existing authorization-related requirements
> >>>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffice
> >>>> for the use case you are thinking of?
> >>
> >>> as considering the service continuity, the next serving  DECADE server
> >>> should know the progress of the service, how does they know?
> >>
> >> By progress of the service, do you mean current user state (e.g.,
> >> quota, recent resource usage history, permissions, etc)?
> >>
> >> yes, and include data delivery proceeding.
> >>> so if the
> >>> service proceeding information should be known by the next serving
> server,
> >>> or different servers need to coordinate and schedule each other to
> fulfill
> >>> the user request, i believe the the 4.1.6.3 of the
> >>> draft-ietf-decade-req-00
> >>> cannot satisfy the req. what do you think about?
> >>
> >> Note that the protocol that is covered here is the client-server
> >> protocol. Some of the same protocol may be useful between DECADE
> >> servers (especially in different administrative domains) for storing
> >> and retrieving data, but that does not mean that there can't be
> >> additional protocol(s) (not specified here) that are used between
> >> DECADE servers as well.  For example, if DECADE servers within an
> >> administrative domain can certainly have their own mechanism to share
> >> such information.  If such capabilities were included in the DECADE
> >> protocol (e.g., a need to do this between administrative domains),
> >> that sounds like lots more complexity that we need at this point.
> >> but the access between in-network storage also is included in IAP
> described
> >> in problem statement.  i mean why not put this kind of function in
> DECADE
> >> since the IAP is defined just like that?
> >> That said, it sounds to me like what is described in 4.1.6.3 would be
> >> sufficient (from the perspective of the client-server protocol,
> >> anyways) to implement what you're describing. If not, what
> >> specifically is missing and what use-case does it not meet?
> >>
> >> so you mean the information you mentioned above, just like current user
> >> state (e.g.,
> >> quota, recent resource usage history, permissions, etc) was already
> included
> >> in DECADE requirement? what about the data delivery proceeding
> information?
> >> can you specify the chapter for me ? thanks?
> >>>> >
> >>>> >
> >>>> >>
> >>>> >> Data Distribution:
> >>>> >>
> >>>> >> I'm also confused about the intent of this requirement.  This
> >>>> >> statement has me somewhat worried: "The distribution is transparent
> to
> >>>> >> the users as they interact with the in-network storage as a single
> >>>> >> logical system." Does this mean that you are proposing for DECADE
> >>>> >> servers to assume the responsibility for deciding how data is to be
> >>>> >> distributed throughout the network, including the path of the data,
> >>>> >> which servers act as intermediate caches, content expiration
> policies,
> >>>> >> etc?  If this is true, I think it is missing one of the major
> points
> >>>> >> of DECADE. In particular, these decisions are application-dependent
> >>>> >> and are not implemented within DECADE. Instead, DECADE provides the
> >>>> >> basic capabilities and the functionality described above are
> >>>> >> implemented by the applications using DECADE.
> >>>> >>
> >>>> >> Or, am I misinterpreting the intent of the requirement?
> >>>> >>
> >>>> > you mean DECADE provides the basic capabilities, so can you give
> some
> >>>> > specify explanations on DECADE capabilities in supporting data
> >>>> > distribution?
> >>>> >>
> >>>>
> >>>> The problem statement gives a couple of scenarios. The "Integration
> >>>> Examples" presentation from IETF 79 also has more details of an
> >>>> on-going effort at Yale.
> >>
> >>> okay, thx for your information, i will lookup and refer, actually, the
> >>> content publisher described in problem statement remind me of  the
> >>> protocol requirements which i did not find in draft-ietf-decade-reqs-00
> to
> >>> support content publish. or i miss some points?
> >>
> >> Which requirements do you think are missing?
> >>
> >>>> >> Service Assurance:
> >>>> >>
> >>>> >> It seems problematic to include "assurance" in a DECADE.  Shouldn't
> >>>> >> these instead be part of SLAs with a storage provider?  Why should
> >>>> >> they be DECADE's responsibility?
> >>>> >>
> >>>> >> Regarding "resource reservation", are you referring to an actual
> >>>> >> reservation (which might be problematic -- see above) or do you
> mean
> >>>> >> that the resource share should able to be specified at the time the
> >>>> >> connection opens and be assumed to be the same for the duration of
> the
> >>>> >> connection?
> >>>> >>
> >>>> >> Regarding Dynamic Feedback, is this orthogonal to the storage
> >>>> >> protocol?  It seems like what you want here is a generic "status"
> >>>> >> service saying how loaded a server is?
> >>>> >>
> >>>> > thats right, actually, the flow control mechanism was under
> discussion
> >>>> > in writing the draft at first. what about your opinion in this
> >>>> > requirements?
> >>>> >
> >>>>
> >>>> I'm not sure what the typical way of providing such "load status"
> >>>> information for IETF protocols, but my inclination is that it should
> >>>> not be in the DECADE protocol itself.  Maybe someone else with a
> >>>> longer history in IETF could jump in here :)
> >>> so can i understand that "load status" is kind of necessity
>  information
> >>> for DECADE Server, but where and who collects the information are
> >>> remain discussion?
> >>
> >> The storage provider is free to collect the information wherever and
> >> however they wish.  The DECADE server implementation could additional
> >> export whatever status information it wishes. I don't think the DECADE
> >> protocol needs to be concerned with that.
> >>
> >> Note that certain error conditions (e.g., overload, insufficient
> >> resources) may be signaled by a DECADE server (there are already have
> >> requirements for those).  If you are referring to status for a user's
> >> resources, there is already a requirement for that too.
> >>
> >> I'm just not convinced that the DECADE protocol needs to export its
> >> current load status to clients.
> >>
> >> actually i am not sure which elements in DECADE needs the load
> >> status,(DECADE client or network storage if the network storage needs to
> >> redirect the request or both?).
> >>
> >>
> >>
> >> And the requirement draft currently seems describe the overload
> condition as
> >> the event triggering. do you think if it is necessary to periodically
> >> reporting of the DECADE network status to client for its network storage
> >> selection?
> >>
> >>
> >>
> >> and the requirement draft just describe DECADE which is busy to serve
> other
> >> requests must be able to reject requests, not consider how to handle the
> >> user request after being rejected?
> >>
> >>>> >>
> >>>> >> Data classification:
> >>>> >>
> >>>> >> Would it be better to instead have the client specify properties of
> >>>> >> the content instead of place it into ? See
> >>>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of
> this
> >>>> >> approach for NFS.
> >>>> >>
> >>>> >> I think a problem with classifying applications is that it assumes
> >>>> >> that applications fit one of the supplied classifications. What if
> it
> >>>> >> may fit multiple classifications? or none?  Another problem is it
> >>>> >> assumes that servers assume based on indirect and assumed
> information
> >>>> >> that they know what to do with a particular piece of content. Why
> not
> >>>> >> have an application specify its desires directly?
> >>>> >>
> >>>> >
> >>>> >
> >>>> >>
> >>>> >> Small Objects:
> >>>> >>
> >>>> >> What is the new requirement here?  Why is the existing requirement
> in
> >>>> >> draft-ietf-decade-reqs-00 insufficient?
> >>>> >>
> >>>> >> This also has me a bit worried:
> >>>> >> "And the in-network storage has the limited storage capacity, with
> the
> >>>> >> arrival of user requests and data distribution requirements, the
> data
> >>>> >> stored in the in-network storage will be replaced if the storage
> >>>> >> reaches the limit and data arrivals continually."
> >>>> >>
> >>>> >> How does the server know what the proper replacement strategy is
> for
> >>>> >> an application? I think DECADE's philosophy is that applications
> >>>> >> should decide this. A simple way to do this is explicit deletion by
> an
> >>>> >> application, but perhaps a more efficient (yet more complex)
> solution
> >>>> >> is for an application to specify the replacement policy to the
> server.
> >>>> >>
> >>>> > actually, the key in "the data classification and small objects " is
> >>>> > whether does it or not in P2P application? i did not find data
> >>>> > classification was adopted in P2P application so far, let alone
> DECADE
> >>>> > need
> >>>> > to classify the data used in all kinds of application.
> >>>> >
> >>>>
> >>>> So, do you agree that it is problematic to try and classify each type
> >>>> of application and try to specify the typical workload for each class?
> >>>>
> >>>> My point was that I don't think its necessary to do the classification
> >>>> at all.  It is more extensible (and directly useful) for a server to
> >>>> just give it direct hints about what would be preferable.
> >>>
> >>> yep, i believe it may be a little difficult, but worthy doing.
> specially
> >>> for improving the resource utilization within a single server and
> reducing
> >>> the response time for client. what about others opinion?
> >>
> >> Can you justify why giving classifications (e.g., "I'm a live
> >> streaming application") would be better than giving specific hints
> >> (e.g., "please don't bother persistent these objects to disk")?
> >>
> >> i mean data in different kind of operation mode and attribute should
> have
> >> different user patterns and storage rules, which may be help to improve
> the
> >> resource utilization and reduce the response time for request, what are
> you
> >> understanding?
> >>> >>
> >>>> >> Removal of Expired Records:
> >>>> >>
> >>>> >> "However, the two scenarios did not mention how to handle the old
> >>>> >> resource if the user distributes the new resource which is an
> updated
> >>>> >> copy of the old resource."
> >>>> >>
> >>>> >> Why does this need to be handled in the requirements?  Are you
> trying
> >>>> >> to draw the distinction between immediate deletion of content and
> lazy
> >>>> >> deletion?
> >>>> >>
> >>>> > i mean the meaning of delete operation and how to handle the expired
> >>>> > records need to be clarify in requirements.
> >>>>
> >>>> My inclination is that "deleted" means that other requests the object
> >>>> of the same name should result an error, until another object with the
> >>>> same name is stored.
> >>>
> >>> okay, under the scenario "client uploads the new version, and did not
> >>> specify how to handle the old version", did DECADE server delete the
> older
> >>> version (or just label it unavailable, anyway, it is implementation
> issue
> >>> )
> >>> or not ? in another word, just replace the older version with the new
> >>> version with the same name?
> >>
> >> In this case, I would think the "write" of the new object should be
> >> rejected, or if desired, we could have an overwrite option.  This
> >> could be added to the requirements if it helps to clarify.
> >>
> >> yep, no matter which solution is chosen, let the understanding
> unanimously:D
> >>> how to handle the older version which is
> >>> transferring from server to client?
> >>
> >> I think it would be cleaner to ask the server to continue sending an
> >> object once it has been started, but ultimately this would be the
> >> decision of the server's implementation I think.  Maybe a "SHOULD"
> >> requirement.  This could be added if desired.
> >>
> >> Thank you for these questions.  It helps design the requirements more
> >> cleanly if there are specific scenarios in front of us :)
> >> just discussion together:D and also thanks for your points to help me
> >> understanding more!
> >> Rich
> >>
> >>>> I think that the time the data is removed from disk (or memory) should
> >>>> be up to the implementation. A storage provider might still have as
> >>>> part of some agreement that deleted data will be removed within X
> >>>> days/hours/minutes/whatever.
> >>>
> >>>    agree with you.
> >>>>
> >>>> If people in the WG think it is necessary, we could have a requirement
> >>>> that says the protocol should support an argument indicating immediate
> >>>> deletion, but it is not clear that we need this.
> >>>>
> >>>> Rich
> >>>>
> >>>> >>
> >>>> >> Thanks!
> >>>> >> Rich
> >>>> >>
> >>>> >>
> >>>> >> On Mon, Dec 27, 2010 at 12:57 AM, 朱潇 <[email-masked]>
> wrote:
> >>>> >> > Dear all,
> >>>> >> >
> >>>> >> > There is a slightly updated version of the decade additional
> >>>> >> > requirements
> >>>> >> > draft.
> >>>> >> >
> >>>> >> >
> >>>> >> >
> https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirements/
> >>>> >> >
> >>>> >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussion
> >>>> >> > with
> >>>> >> > all of
> >>>> >> > you.
> >>>> >> >
> >>>> >> > Any comments are appreciated!
> >>>> >> >
> >>>> >> > A new version of I-D,
> >>>> >> > draft-zhu-decade-additional-requirements-00.txt
> >>>> >> > has been successfully submitted by Xiao Zhu and posted to the
> IETF
> >>>> >> > repository.
> >>>> >> >
> >>>> >> > Filename:      draft-zhu-decade-additional-requirements
> >>>> >> > Revision:      00
> >>>> >> > Title:                 Additional protocol requirements on DECADE
> >>>> >> > Creation_date:         2010-12-27
> >>>> >> > WG ID:                 Independent Submission
> >>>> >> > Number_of_pages: 10
> >>>> >> >
> >>>> >> > Abstract:
> >>>> >> > The DECoupled Application Data Enroute(DECADE)working group is
> >>>> >> > specifying standardized interfaces for accessing in-network
> storage
> >>>> >> > from applications to store, retrieve and manage data. The main
> >>>> >> > object
> >>>> >> > is to provide a framework that is useful to the applications,
> >>>> >> > including P2P applications and other data-oriented applications,
> >>>> >> > possibly related applications that can benefit from accessing in-
> >>>> >> > network storage. This memo focuses on some requirements such as
> >>>> >> > request redirecting and so on which are on the central of
> mobility,
> >>>> >> > wireless network environment and CDN application. We present
> these
> >>>> >> > in
> >>>> >> > this memo as additional requirements that should be considered
> for
> >>>> >> > the DECADE architecture and protocol specifications.
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> > The IETF Secretariat.
> >>>> >> >
> >>>> >> > --
> >>>> >> > Best wishes,
> >>>> >> >
> >>>> >> > Beijing University of Posts & Telecommunications (BUPT)
> >>>> >> > Zhu Xiao  ( 朱潇 )
> >>>> >> > E-mail: [email-masked]
> >>>> >> > mobile:+86 134-8881-9004
> >>>> >> >
> >>>> >> > _______________________________________________
> >>>> >> > decade mailing list
> >>>> >> > [email-masked]
> >>>> >> > https://www.ietf.org/mailman/listinfo/decade
> >>>> >> >
> >>>> >> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > Best wishes,
> >>>> >
> >>>> > Beijing University of Posts & Telecommunications (BUPT)
> >>>> > Zhu Xiao  ( 朱潇 )
> >>>> > E-mail: [email-masked]
> >>>> > mobile:+86 134-8881-9004
> >>>
> >>>
> >>>
> >>> --
> >>> Best wishes,
> >>>
> >>> Beijing University of Posts & Telecommunications (BUPT)
> >>> Zhu Xiao  ( 朱潇 )
> >>> E-mail: [email-masked]
> >>> mobile:+86 134-8881-9004
> >>>
> >>
> >>
> >> --
> >> Best wishes,
> >>
> >> Beijing University of Posts & Telecommunications (BUPT)
> >> Zhu Xiao  ( 朱潇 )
> >> E-mail: [email-masked]
> >> mobile:+86 134-8881-9004
> >
>

-- 
Best wishes,

Beijing University of Posts & Telecommunications (BUPT)
Zhu Xiao  ( 朱潇 )
E-mail: [email-masked]
mobile:+86 134-8881-9004

---

From: 朱潇 <[email-masked]>
Date: Tue, 28 Jun 2011 10:22:56 +0800

2011/6/27 朱潇 <[email-masked]>

>> >>>> > draft as "soft handover in wireless environment and delete
>> operation in
>> >>>> >> statement has me somewhat worried: "The distribution is
>> transparent to
>> >>> protocol requirements which i did not find in
>> draft-ietf-decade-reqs-00 to
>> >>>> >> should decide this. A simple way to do this is explicit deletion
>> by an

-- 
Best wishes,

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 28 Jun 2011 16:19:56 +0000

Xiao,

My personal preference would be to let draft-zhu-decade-additional-requirements expire, and ensure that the key requirements from your draft are reflected in draft-ietf-decade-reqs which is the official WG draft.

Do you have objections about how your requirements were reflected in draft-ietf-decade-reqs?

-- Rich

From: 朱潇 [mailto:[email-masked]]
Sent: Monday, June 27, 2011 10:23 PM
To: Richard Alimi
Cc: Woundy, Richard; [email-masked]
Subject: Re: [decade] draft-zhu-decade-additional-requirements

The draft draft-zhu-decade-additional-requirements I submitted last year is about to expire. do you have some suggestions to update the version? and do the DECADE requirement draft has adopted some suggestions of my draft?

2011/6/27 朱潇 <[email-masked]<mailto:[email-masked]>>
hi, Richard and everybody

The draft draft-zhu-decade-additional-requirements I submitted last year is about to expire. do you have some suggestions to update the version? and do the DECADE requirement draft has adopted some suggestions of my draft?

2011/3/14 Richard Alimi <[email-masked]<mailto:[email-masked]>>
Hi All,

Thanks,
Rich

2011/3/2 Richard Alimi <[email-masked]<mailto:[email-masked]>>:
> - We can add a requirement mentioning that DECADE may support redirection.
>
> Data Classification:
> hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf<http://www.ietf.org/proceedings/78/slides/nfsv4-0.pdf>) could be
> 2011/3/2 Woundy, Richard <[email-masked]<mailto:[email-masked]>>:
>> Folks,
>>
>>
>>
>> list, but this is important enough to allocate some time at our meeting in
>> Prague.
>>
>>
>>
>> -- Rich
>>
>>
>>
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>> ??
>> Cc: [email-masked]<mailto:[email-masked]>
>> 2011/1/14 Richard Alimi <[email-masked]<mailto:[email-masked]>>
>>
>> HI Xiao,
>>
>> 2011/1/12 朱潇 <[email-masked]<mailto:[email-masked]>>:
>>
>>> hi, Richard
>>> see inline:D
>>>
>>> 2011/1/11 Richard Alimi <[email-masked]<mailto:[email-masked]>>
>>>>
>>>> Hi Xiao,
>>>>
>>>> On Mon, Jan 10, 2011 at 6:45 PM, 朱潇 <[email-masked]<mailto:[email-masked]>> wrote:
>>>> >
>>>> > hi, Richard, sorry for so late response because of be busy with other
>>>> > projects.
>>>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <[email-masked]<mailto:[email-masked]>>
>>>> > wrote:
>>>> >>
>>>> >> Hi Xiao,
>>>> >>
>>>> >> This would provide some additional freedom for the storage provider.
>>>> >> complexity for the DECADE server, but allows it if desired. However,
>>>> >> the user made aware of the quota at each in-network storage (if there
>>>> >> is no shared storage between them)?  Resource sharing policies may be
>>>> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean something
>>>> >> this point it may be best to just note these so they are documented,
>>>> >> but since the specification of the resource sharing policies are still
>>>> > 1. whether or not to be ware of the content at each in-network storage
>>>> > redirection. your suggestion"just to note these so they are documented"
>>>> > will
>>>> > the best DECADE server will be known for DECADE servers, in which other
>>>> > 2. you mean "the resource sharing policies are still being considered
>>>> > in
>>>> > a single server", so it may be premature to support redirection.  the
>>>> >> understanding is that you wish the client to be able to have multiple
>>>> >> If so, do we need this stated as a requirement or the protocol? Or is
>>>> > yep, your understanding is right, the scenarios were just described in
>>>> > draft as "soft handover in wireless environment and delete operation in
>>>> > authorization need to be taken each time when setup connection with a
>>>> > new
>>> service proceeding information should be known by the next serving server,
>>> or different servers need to coordinate and schedule each other to fulfill
>> but the access between in-network storage also is included in IAP described
>> in problem statement.  i mean why not put this kind of function in DECADE
>> quota, recent resource usage history, permissions, etc) was already included
>> in DECADE requirement? what about the data delivery proceeding information?
>>>> >> statement has me somewhat worried: "The distribution is transparent to
>>>> >> which servers act as intermediate caches, content expiration policies,
>>>> >> etc?  If this is true, I think it is missing one of the major points
>>>> > you mean DECADE provides the basic capabilities, so can you give some
>>> protocol requirements which i did not find in draft-ietf-decade-reqs-00 to
>>>> >> reservation (which might be problematic -- see above) or do you mean
>>>> >> connection opens and be assumed to be the same for the duration of the
>>>> >> connection?
>>>> >>
>>>> > thats right, actually, the flow control mechanism was under discussion
>>> so can i understand that "load status" is kind of necessity  information
>> And the requirement draft currently seems describe the overload condition as
>> and the requirement draft just describe DECADE which is busy to serve other
>>>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf<http://www.ietf.org/proceedings/78/slides/nfsv4-0.pdf> for an example of this
>>>> >> approach for NFS.
>>>> >>
>>>> >> that applications fit one of the supplied classifications. What if it
>>>> >> assumes that servers assume based on indirect and assumed information
>>>> >> that they know what to do with a particular piece of content. Why not
>>>> >> What is the new requirement here?  Why is the existing requirement in
>>>> >> "And the in-network storage has the limited storage capacity, with the
>>>> >> arrival of user requests and data distribution requirements, the data
>>>> >> How does the server know what the proper replacement strategy is for
>>>> >> should decide this. A simple way to do this is explicit deletion by an
>>>> >> application, but perhaps a more efficient (yet more complex) solution
>>>> >> is for an application to specify the replacement policy to the server.
>>>> >>
>>>> > classification was adopted in P2P application so far, let alone DECADE
>>>> > need
>>> yep, i believe it may be a little difficult, but worthy doing. specially
>>> for improving the resource utilization within a single server and reducing
>> i mean data in different kind of operation mode and attribute should have
>> different user patterns and storage rules, which may be help to improve the
>> resource utilization and reduce the response time for request, what are you
>> understanding?
>>> >>
>>>> >> resource if the user distributes the new resource which is an updated
>>>> >> Why does this need to be handled in the requirements?  Are you trying
>>>> >> to draw the distinction between immediate deletion of content and lazy
>>>> >> deletion?
>>>> >>
>>> specify how to handle the old version", did DECADE server delete the older
>>> version (or just label it unavailable, anyway, it is implementation issue
>>> )
>> yep, no matter which solution is chosen, let the understanding unanimously:D
>>>> >> On Mon, Dec 27, 2010 at 12:57 AM, 朱潇 <[email-masked]<mailto:[email-masked]>> wrote:
>>>> >> > Dear all,
>>>> >> >
>>>> >> > has been successfully submitted by Xiao Zhu and posted to the IETF
>>>> >> > repository.
>>>> >> >
>>>> >> > specifying standardized interfaces for accessing in-network storage
>>>> >> > request redirecting and so on which are on the central of mobility,
>>>> >> > wireless network environment and CDN application. We present these
>>>> >> > in
>>>> >> > this memo as additional requirements that should be considered for
>>>> >> > E-mail: [email-masked]<mailto:[email-masked]>
>>>> >> > mobile:+86 134-8881-9004
>>>> >> >
>>>> >> > [email-masked]<mailto:[email-masked]>
>>>> > E-mail: [email-masked]<mailto:[email-masked]>
>>>> > mobile:+86 134-8881-9004
>>>
>>>
>>>
>>> --
>>> Best wishes,
>>>
>>> E-mail: [email-masked]<mailto:[email-masked]>
>>> mobile:+86 134-8881-9004
>>>
>>
>>
>> --
>> Best wishes,
>>
>> E-mail: [email-masked]<mailto:[email-masked]>
>> mobile:+86 134-8881-9004
>

--
Best wishes,

Beijing University of Posts & Telecommunications (BUPT)
Zhu Xiao  ( 朱潇 )
E-mail: [email-masked]<mailto:[email-masked]>
mobile:+86 134-8881-9004

--
Best wishes,

Beijing University of Posts & Telecommunications (BUPT)
Zhu Xiao  ( 朱潇 )
E-mail: [email-masked]<mailto:[email-masked]>
mobile:+86 134-8881-9004

---

From: 朱潇 <[email-masked]>
Date: Wed, 29 Jun 2011 15:02:37 +0800

hi, Woundy

okay. that`s a good idea. I remember we have a discussion on the additional
requirements in the draft-zhu-decade-additional-requirement and we have
reached agreement on the first points with Richard Alimi.  I have no special
suggestion on how my requirements were reflected in draft-ietf-decade-reqs.
 But we, the writers of the draft could be added in the contributors of the
draft-ieft-decade-reqs. What do you think of ?

2011/6/29 Woundy, Richard <[email-masked]>

>  Xiao,****
>
> ** **
>
> My personal preference would be to let
> draft-zhu-decade-additional-requirements expire, and ensure that the key
> requirements from your draft are reflected in draft-ietf-decade-reqs which
> is the official WG draft.****
>
> ** **
>
> Do you have objections about how your requirements were reflected in
> draft-ietf-decade-reqs?****
>
> ** **
>
> -- Rich****
>
> ** **
>
> *From:* 朱潇 [mailto:[email-masked]]
> *Sent:* Monday, June 27, 2011 10:23 PM
> *To:* Richard Alimi
> *Cc:* Woundy, Richard; [email-masked]
>
> *Subject:* Re: [decade] draft-zhu-decade-additional-requirements****
>
>  ** **
>
> hi, Richard and everybody****
>
> ** **
>
> The draft draft-zhu-decade-additional-requirements I submitted last year
> is about to expire. do you have some suggestions to update the version? and
> do the DECADE requirement draft has adopted some suggestions of my draft?*
> ***
>
> ** **
>
> 2011/6/27 朱潇 <[email-masked]>****
>
> hi, Richard and everybody****
>
> ** **
>
> The draft draft-zhu-decade-additional-requirements I submitted last year
> is about to expire. do you have some suggestions to update the version? and
> do the DECADE requirement draft has adopted some suggestions of my draft?*
> ***
>
> ** **
>
> 2011/3/14 Richard Alimi <[email-masked]>****
>
> Hi All,
>
> >> Subject: Re: [decade] draft-zhu-decade-additional-requirements****
>
> >>
> >>
> >>
> >> hi, Richard:
> >>
> >>
> >>
> >> thanks for your reply:D
> >>
> >> yes, and include data delivery proceeding.****
>
> >>> so if the
> >> since the IAP is defined just like that?****
>
> >>>> >>****
> >>****
> >>>> >>****
> >>> >>****
> >> understanding more!****
> >****
> ****
> -- ****
> mobile:+86 134-8881-9004****
>
>
>
>
> --
> Best wishes,
>
> mobile:+86 134-8881-9004****
>

-- 
Best wishes,

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 29 Jun 2011 08:50:17 +0000

There is a limit of five authors on an Internet draft, but you could be mentioned in the Acknowledgments section.
________________________________________
From: 朱潇 [[email-masked]]
Sent: Wednesday, June 29, 2011 3:02 AM
To: Woundy, Richard
Cc: Richard Alimi; [email-masked]
Subject: Re: [decade] draft-zhu-decade-additional-requirements

hi, Woundy

okay. that`s a good idea. I remember we have a discussion on the additional requirements in the draft-zhu-decade-additional-requirement and we have reached agreement on the first points with Richard Alimi.  I have no special suggestion on how my requirements were reflected in draft-ietf-decade-reqs.  But we, the writers of the draft could be added in the contributors of the draft-ieft-decade-reqs. What do you think of ?

2011/6/29 Woundy, Richard <[email-masked]<mailto:[email-masked]>>
Xiao,

-- Rich

From: 朱潇 [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, June 27, 2011 10:23 PM
To: Richard Alimi
Cc: Woundy, Richard; [email-masked]<mailto:[email-masked]>

Thanks,
Rich

--
Best wishes,

--
Best wishes,

--
Best wishes,

---

From: Richard Alimi <[email-masked]>
Date: Wed, 29 Jun 2011 22:26:23 -0700

> There is a limit of five authors on an Internet draft, but you could be mentioned in the Acknowledgments section.

Adding the authors of draft-zhu-decade-additional-requirements in the
Acknowledgments would be very reasonable I think.

Thanks,
Rich