Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)

[Martin Stiemerling <[e-mail]>]

Hi Richard,

On 09/21/2012 04:19 PM, Y. Richard Yang wrote:
[...]
>
>> though there are a number of issues that should have been discussed.
>>
>> The WG chairs were explicitly notified in mid of June that there are
>> severe issues and the WG had time to address those issues. However, it
>> must have been obvious even before mid of June that there are severe
>> issues, i.e., there has been sufficient time to fix it.
>>
>> Furthermore, the requirements and architecture draft were submitted to
>> the IESG for publication and both drafts have been returned to the WG,
>> as both are not ready to be published as RFC.
>> You can find the AD review in the datatracker:
>> - https://datatracker.ietf.org/doc/draft-ietf-decade-reqs/history/
>> - https://datatracker.ietf.org/doc/draft-ietf-decade-arch/history/
>>
> Your preceding AD reviews are extensive. But I think the main criticism
> is writing/English/organization problems, not technical problems.

No, it isn't!
The criticisms are about technical issues in the sense that it is not 
clear what DECADE is exactly looking like in many parts and also many 
requirements are not correct or incomplete.
This is not about language or organizational issues, but it is about 
technical issues, though that there are organizational issues, e.g., 
listing new requirements in the architecture.

>
>> Both drafts do leave any number of key questions unanswered, i.e.,
>> they are far away from being technically useful to be the base for the
>> next steps in the protocol development.
>>
>> To give 2 examples:
>> 1)
>> It is completely unclear how the resources on a DECADE server are
>> supposed to be managed
> The basic design principles are stated in Sec. 4.4 and 4.5 of -arch:
> Explicit Control and Delegation, with sentences such as
>
> "Storage Providers will have the ability to explicitly manage the
>     entities allowed to utilize the resources at a DECADE-compatible
>     server.  This capability is needed for reasons such as capacity-
>     planning and legal considerations in certain deployment scenarios."

This is a high-level description that does not add anything to question 
on how it will be managed.

>
> "Content Providers are able to explicitly and independently manage their
> own shares of resources on a server."

Nice, but how? The 'how' is about how on the conceptual level and not 
yet on the protocol detail level.

>
> "The client can in turn share the
>     granted resources amongst its multiple applications.  The share of
>     resources granted by a server is called a User Delegation."

Sure, that seems to be a glimpse of a concept, but how does the DECADE 
server distinguish the applications? Or this is handled solely by the 
client?
Each of these paragraphs opens up many questions, which are never answered.

>
> "As a simple example, a DECADE-compatible server operated by an ISP
>     might be configured to grant each ISP Subscriber 1.5 Mbit/s of
>     bandwidth.  The ISP Subscriber might in turn divide this share of
>     resources amongst a video streaming application and file-sharing
>     application which are running concurrently."

Again nice, but how is this done on a conceptual level? What the 
measures in the requirements to ensure this?
For instance, how would expect that an ISP subscriber is identified?

>
> In -req:
> - Multiple Applications Sharing Resources
>
>
> "REQUIREMENT(S):  A client MUST be able to indicate to a DECADE-
>         compatible server about resource sharing policies among multiple
>         Target Applications being run/managed by the same client."

But how exactly does the client indicate this and where? How are the 
target applications announced to the server and distinguished during 
operations?
It is clear that the requirements do not specify all the bits and bytes 
of the protocol, but writing a high-level requirement is not sufficient 
at all.

>
> - Per-Client Resource Policy
>
> "REQUIREMENT(S):  A Provider MUST be able to specify resource policies
>         (bandwidth share, storage quota, and network connection quota) to
>         individual Consumers for reading from and writing data to its in-
>         network storage within a particular range of time."

This is underspecified: What is the policy for bandwidth share that is 
expected to be implemented by a protocol? Is it 10 % of my outgoing link 
capacity or is it a maximum throughput in x bits per second? What is 
expected here?

And does this related to multiple customers? How is such a customer 
identified?


>
>
> - Distributed Resource Sharing Specification
> REQUIREMENT(S):  A Provider MUST be able to indicate to its DECADE-
>         compatible server, without itself contacting the server, resource
>         control policies for a Consumer.  The DECADE-compatible server
>         MUST be able to authenticate the resource control policies.
>
>
> - Resource Set
> REQUIREMENT(S):  A DECADE-compatible server MUST allow specification
>         on the following resources: storage, bandwidth, and number of
>         connections, and MAY allow additional types of resources to be
>         specified.
>
>
> ...
>
>> and how this management is mapped to the protocol split of SDT, DRP,
>> and other management protocols.
>> Parts of it, such as setting the permissions of data objects clearly
>> belongs to the DRP, and it is sort of stated in a vague way in the
>> architecture, but it is not documented in a comprehensive way.

You say it correctly: 'vague way' and 'not documented in a comprehensive 
way.'
This is one of the main points that it is all to vague.

>
> The documents intentionally stayed vague as the understanding was that
> they are not solution-specifying protocol documents. Some authors have a
> lot more details on resource management, e.g., the recent SIGCOMM ICN'12
> paper (http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p25.pdf)
> discusses using a hierarchical weighted sharing scheme for resource
> sharing and how to encode them in tokens. But the authors discussed the
> issues intensively, considered this to be too solution specific, and
> intentionally left them over to allow a larger design space to allow
> better participation.

The requirements and the architecture can get specific without detailing 
what the bits and bytes of the protocol are. This is what it is actually 
needed to design a proper protocol later on!


>
>> Other parts, such as the accounting is probably not part of the the
>> DRP nor SDT, but there is supposedly another interface that is needed
>> for this.
>>
>> 2)
>> What is the model how data objects are handled on the server in the
>> sense about who is allowed to do what?
>> The drafts solely talk about tokens to be used to do access control.
>> But there other aspects, for instance, who is controlling what on a
>> DECADE server: The DECADE server can be operated by an ISP, but the
>> content is provided by a content provider and it is access by an
>> unlimited set of clients or limited set of clients.
> Limited set of clients. See -req: "
>
> REQUIREMENT(S):  A Provider MUST be able to control which individual
>         clients are authorized to read/write which particular data
>         objects from/to its in-network storage.
>
>     RATIONALE:  A Target Application should able to conduct access
>         control on the granularity of individual clients, individual data
>         objects."

Those are really high-level requirements that do not saying too much 
about how the protocol should look like in the end. For instance, a main 
use case for this is bittorrent. There are no clients that can be easily 
identified and authorized. How is this handled?

One way would be that the management protocol, which is not specified in 
the requirements or architecture, is used to limited the IP addresses 
that are allowed to access such a DECADE server. This would be a 
requirement!

>
>
>
>> How is the access control divided between those parties?
> Mostly by clients, but with the exception that ISP has a say when:
> -req Sec. 9:
> 9.1.  Illegal Data Object
>
>     REQUIREMENT(S):  A DECADE-compatible server SHOULD provide an error
>         indicating that (1) data was rejected from being written, (2)
>         deleted, or (3) marked unavailable.
>
>     RATIONALE:  DECADE Storage Providers may require the ability to (1)
>         avoid storing, (2) delete, or (3) quarantine certain data that
>         has been identified as illegal (or otherwise prohibited).  It is
>         not specified how such data is identified, but applications
>         employing DECADE-compatible servers should not break if a Storage
>         Provider is obligated to enforce such policies.  Appropriate
>         error conditions should be indicated to applications.
>
>     EXCEPTION:  A DECADE-compatible server should be able to be
>         configured to suppress Illegal Data Object responses for security
>         reasons.

Those requirements do not answer my question about access control is 
divided between the parties.


   Martin

-- 
[e-mail]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283