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

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 2 Mar 2011 14:37:23 +0000

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]<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.
>> > some discussion see inline:D marked by red.
>> >
>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <[email-masked]<mailto:[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<http://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]<mailto:[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]<mailto:[email-masked]>
>> >> > mobile:+86 134-8881-9004
>> >> >
>> >> > _______________________________________________
>> >> > decade mailing list
>> >> > [email-masked]<mailto:[email-masked]>
>> >> > https://www.ietf.org/mailman/listinfo/decade
>> >> >
>> >> >
>> >
>> >
>> >
>> > --
>> > 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
>

--
Best wishes,

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

---

From: Richard Alimi <[email-masked]>
Date: Wed, 2 Mar 2011 17:13:37 -0800

Hi Xiao,

Sorry for the delay. Finally coming back to this.

2011/1/16 朱潇 <[email-masked]>:
> 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:
>> >> >
>> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <[email-masked]>
>> >> > wrote:
>> >> >>
>> >> >> Hi Xiao,
>> >> >>

> yes, and include data delivery proceeding.

I still don't think I understand what you are suggesting as new
requirements here.  Why can't the client retry any failed requests?

> 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?

The IAP in the problem statement is intended to describe data transfer
between DECADE servers.  I think the discussion above relates to
storing state about the progress of delivering data to DECADE clients.
Is that an accurate summary?  If so, then the point of DECADE is that
this is managed and controlled by the clients.  I don't think it makes
sense to add additional state in to DECADE servers for this.

> 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?

Historical information is not specified, but I can't think of another
storage protocol off the top of my head that provides this.

Quota/resource usage is in Section 5.1.6. Permissions, if applicable,
should be there too (we will update the doc to state this).

For data delivery, I see value in getting status about other client
that may have open connections or active transfers (reads or writes)
to one's storage. This could probably be added as a requirement.

However, if the expectation is for DECADE servers to somehow
coordinate (e.g., picking a data path, resuming/retrying failed
transfers, etc), then this is going towards delay-tolerant networking
or CDNs. DECADE is not intended for that.

> 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?

No I don't think this is necessary.  The client can retry the request
at a later time (e.g., exponential backoff).  Note that asking a
heavily-loaded DECADE server to also keep track of clients that need
to be notified, and keep them updated of the current status, is
probably counter-productive.

> 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?

That's the implementation's decision. I suspect most would drop it on the floor.

>> >> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of
>> >> >> this
>> >> >> approach for NFS.
>> >> >>
> 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?

That's fine. Explicit and more-specific hints are a different way to
accomplish the same thing, and seem to be a much better design to me.
They are simpler from an extensibility and implementation point of
view.

> just discussion together:D and also thanks for your points to help me

Thanks,
Rich

>> >> >> On Mon, Dec 27, 2010 at 12:57 AM, 朱潇 <[email-masked]> wrote:
>> >> >> > Dear all,
>> >> >> >
>> >> >> > A new version of I-D,
>> >> >> > draft-zhu-decade-additional-requirements-00.txt
>> >> >> > E-mail: [email-masked]
>> >> >> > mobile:+86 134-8881-9004
>> >> >> >
>> >> >> > [email-masked]
>> >> > E-mail: [email-masked]
>> >> > mobile:+86 134-8881-9004
>> >
>> >
>> >
>> > --
>> > Best wishes,
>> >
>> > E-mail: [email-masked]
>> > mobile:+86 134-8881-9004
>> >
>
>
>
> --
> Best wishes,
>
> E-mail: [email-masked]
> mobile:+86 134-8881-9004
>

---

From: Richard Alimi <[email-masked]>
Date: Wed, 2 Mar 2011 17:15:48 -0800

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
>
>
>
> 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?
> 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:
>>> >>
> And the requirement draft currently seems describe the overload condition as
> the event triggering. do you think if it is necessary to periodically
> 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:
>>> >>
>>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of this
>>> >> approach for NFS.
>>> >>

---

From: 朱潇 <[email-masked]>
Date: Mon, 7 Mar 2011 10:11:50 +0800

Hi, Richard:

sorry for reply so late, because i should remember what we
are dissuasion and the key of the problem[?]

so many quoted texts, let me make a summarize.

1 multi connection, i have the arguments as followings:

@me:

   - need it to process new authentication and authorization after the user
   moves in the wireless environment and access a new DECADE server

@you:

   - 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,

--> okay, agree with you, but we should specify in the requirements draft.

@me:

   - considering the service continuity, the next serving  DECADE server
    should know the progress of the service, how does they know?or different
   servers need to coordinate and schedule each other to fulfill the user
   request?

@you:

   - that does not mean that there can't be additional protocol(s) (not
   specified here) that are used between DECADE servers as well. and The IAP
   in the problem statement is intended to describe data transfer between
   DECADE servers.

-> basically agree with you,  a question reminds me that "IAP means in the
media layer？ and signalling or controlling layer protocol may be needed to
solve the problem? and we can reuse the other protocol to fulfill the
storing status transfer. and we should consider to update the draft to add
the permission requirement and retrieve the client status about getting and
writing storage.

2 Service Assurance

-> basically agree with you, keep tracking the status of the DCADE server
may also bring the additional burden to the overloaded DECADE server.

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

> >> >> > be ok, or DECADE server list with some parameters will be return
> for
> >> >> > user to
> >> >> > 2. you mean "the resource sharing policies are still being
> considered
> >> >> > in
> >> >> > architecture and protocol will be badly impacted if the
> requirements
> >> >> > change.
> >> >> > draft as "soft handover in wireless environment and delete
> operation
> >> >> > in
> >> >> > authorization need to be taken each time when setup connection with
> a
> >> >> > new
> >> >> >> 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
> >> >> >> > wireless network environment and CDN application. We present
> these
> >> >> >> > in

-- 
Best wishes,

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 9 Mar 2011 14:04:41 -0500

A few comments inline:

> - We can add a requirement mentioning that DECADE may support redirection.

+1

> supports hints, a DECADE client or server can use it.

Exactly. My preference is to keep the protocol as simple as possible,
for a few reasons. First, it is very critical for getting an IETF
protocol finished to keep things simple. Otherwise, it takes years to
get a protocol finished. Even more critically, I just don't think we
need this from a protocol perspective. We should avoid trying to
classify the application/access pattern.

David

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 9 Mar 2011 14:13:11 -0500

Comments inline:

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

>    - need it to process new authentication and authorization after the
>    user moves in the wireless environment and access a new DECADE server
>
> @you:
>
>     should know the progress of the service, how does they know?or
>    different servers need to coordinate and schedule each other to fulfill the
>    user request?
>
> @you:
>
>
>    specified here) that are used between DECADE servers as well. and The
>    IAP in the problem statement is intended to describe data transfer between
>    DECADE servers.
>

I'm not sure I quite understand this, but it sounds like a proposal to add
some sort of shared state explicitly to the protocol. In other words, to
allow a request to be received by one server and processed by another or
something similar.

I have no problem with someone implementing this, but explicitly adding it
to the protocol will complicate this incredibly. If someone wants to be a
distributed version of a DECADE server (service?) that is great, but, it is
up to the application developer to handle that in the background,
transparently to the user. I also don't really like the idea of different
servers being involved in one transaction, from a security perspective. I
want to send a request and get a response from that same "server". Now if
you want to use signed certificates and some fancy process in the back where
it appears the response came from a different server, I'm ok with that, but
I firmly think to be able to finish on time we should treat the server as a
single, client-server entity from a protocol perspective.

BTW and on a slight tangent, there are lots of protocols that seem to be
considering distributed backends (PPSP ruled it out of scope to make the
problem simple enough to be solved as well, but there was a similar
discussion). Perhaps some folks (in another mailing list of course) should
look at the generic aspects required by these and other distributed servers
and figure out if there is a need for a protocol framework to help enable
that it...

> may also bring the additional burden to the overloaded DECADE server.

I also think that publicly sharing load could be a security threat, although
we might need to think about it. Redirection is great, and a busy server can
use it to shed load. Explicitly telling a client (with which the server may
have no other relationship than this transaction) the load might let me know
that I shouldn't waste any more bots on a DoS attack on this
server...already compromised and I can move on to DoS-ing a different one.
Just seems like a bad idea.

David

>> >> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <[email-masked]
>> >
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Hi Xiao,
>> >> >> >>
>> >> >> >> is no shared storage between them)?  Resource sharing policies
>> may
>> >> >> >> be
>> >> >> > select the appropriate DECADE server, which can avoid the
>> different
>> >> >> > weighted
>> >> >> > of the same parameter in server decision. but the parameter used
>> in
>> >> >> > select
>> >> >> >> 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
>> >> >> > authorization need to be taken each time when setup connection
>> with a
>> >> >> > new
>> >> >> >> connection opens and be assumed to be the same for the duration
>> of
>> >> >> >> the
>> >> >> >> connection?
>> >> >> >>
>> >> >> >> that applications fit one of the supplied classifications. What
>> if
>> >> >> >> it
>> >> >> >> What is the new requirement here?  Why is the existing
>> requirement
>> >> >> >> in
>> >> >> >> "And the in-network storage has the limited storage capacity,
>> with
>> >> >> >> the
>> >> >> >> > Jin Peng, Yunfei Zhang and me are expecting to have a
>> discussion
>> >> >> >> > with
>> >> >> >> > all of
>> >> >> >> > you.
>> >> >> >> >

---

From: Richard Alimi <[email-masked]>
Date: Sat, 12 Mar 2011 22:00:03 -0800

> --> okay, agree with you, but we should specify in the requirements draft.
Can you point out what, if anything, should be added to the existing
requirement?  The intent was to specify this, but note that the existing
text does this at the request level instead of connections.  The notion of
when to drop an connection seems like an implementation detail to me.

The existing text is here:
  http://tools.ietf.org/html/draft-ietf-decade-reqs-00#section-4.1.6.3

Thanks!
Rich

---

From: 朱潇 <[email-masked]>
Date: Sun, 13 Mar 2011 18:09:10 +0800

hi David:

thanks for joining our discussion.

i can understand your concerns, especially we should finish the protocol in
time. but i just wonder how decade support the user in mobile environment.
you know users may roam and need to handover when they access the decade
server and when the service continues, how the decade handle this
situation.

In Richard`s opinion, he gives explanations, basically  i agree with him. if
we just see the problem from the technical view, what about your opinion? do
your agree with Richard?

thanks!

2011/3/10 David A. Bryan <[email-masked]>

> I also think that publicly sharing load could be a security threat,
> although we might need to think about it. Redirection is great, and a busy
> server can use it to shed load. Explicitly telling a client (with which the
> server may have no other relationship than this transaction) the load might
> let me know that I shouldn't waste any more bots on a DoS attack on this
>>> >> >> > so the designing can be  taken  step by step, but the
>>> requirements
>>> >> >> > should be
>>> >> >> > overall considered.
>>> >> >>
>>> >> >> >> that they know what to do with a particular piece of content.
>>> Why
>>> >> >> >> not
>>> >> >> >> to draw the distinction between immediate deletion of content
>>> and
>>> >> >> >> lazy
>>> >> >> >> deletion?
>>> >> >> >>

-- 
Best wishes,

---

From: 朱潇 <[email-masked]>
Date: Sun, 13 Mar 2011 19:55:58 +0800

hi, Richard:

The in-network storage MAY use optimizations to avoid such authorization
checks
as long as the enforced permissions are the the same.

right? i see! many thx[?]!

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

-- 
Best wishes,

---

From: Richard Alimi <[email-masked]>
Date: Sun, 13 Mar 2011 10:15:04 -0700

Hi All,

We've made all of these updates to the requirements document, with the

> reading the object and signal an error to the client reading the

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