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

"Y. Richard Yang" <> Mon, 24 September 2012 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79D9D21F87CF for <>; Mon, 24 Sep 2012 08:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cMQ3RGLdLH1T for <>; Mon, 24 Sep 2012 08:16:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BBE4421F87C5 for <>; Mon, 24 Sep 2012 08:16:27 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id q8OFGOZR025534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Sep 2012 11:16:25 -0400
Message-ID: <>
Date: Mon, 24 Sep 2012 11:16:24 -0400
From: "Y. Richard Yang" <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Martin Stiemerling <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------050407030700070505060005"
X-Scanned-By: MIMEDefang 2.71 on
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Sep 2012 15:16:39 -0000

On 9/24/12 5:36 AM, Martin Stiemerling wrote:
> 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:
>>> -
>>> -
>> 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 
This could be a useful discussion on the mailing list, before the 
closure of the WG. From my personal point of view, requirements and 
architecture do not specify "exactly looking". My personal design 
approach is that if I can see two reasonable design approaches to 
satisfy one req, I will resist strongly to specify one.

> and also many requirements are not correct or incomplete.

It can helpful if you point out which part is "not correct".

> 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.
This is not an empty requirement--it rules out non-managed caches, and 
hence is a step in answering the management issue.

>> "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.
We list requirements, not how to satisfy the requirements. We resisted 
strongly to specify how. But even so, the documents suggested some 
'how'. A related 'how' for this:

      8.3 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.

RATIONALE:  One important consideration for a DECADE-compatible
        server is scalability, since a single storage element may be used
        to support many users.  Many Target Applications use small chunk
        sizes and frequent data exchanges.  If such an application
        employed resource control and contacted the DECADE-compatible
        server for each data exchange, this could present a scalability
        challenge for the server as well as additional latency for

        The preferred way is to let requesting clients obtain signed
        resource control policies (in the form of a token) from the
        owning client, and then requesting clients can present the policy
        to a DECADE-compatible server directly.  This can result in
        reduced messaging handled by the DECADE-compatible server.

As another example, see Figure 2 of -arch.

>> "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?
There are multiple design options: distinguish between the apps, or not 
(app is a higher level concept that needs to be managed by an App only). 
A first design distinguished (by explicitly introducing App ID), and a 
later did not. Either way can work. We do not rule out such design options.
> Each of these paragraphs opens up many questions, which are never 
> answered.
I look at it differently: they specify requirements/goals, now how. What 
is opened up is not questions, are design options. Like I said: My 
personal design approach is that if I can see two reasonable approaches 
to satisfy one req, I will resist strongly to specify one.

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

      2.4 DECADE Account

    An account of a DECADE-compatible server has associated cryptographic
    credentials for access control, and resource allocation attributes on
    the server.

>> 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?
There are multiple options: a control channel, or piggy backed on data 
requests.  See preceding text for Sec. 8.3. Regarding the need to 
distinguish apps or not, see preceding on the two design options.

> 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?
This is very intentionally left open. The authors tried hard to leave 
the design space open. A design option considered your quesions is:
co-authors by the doc authors. See Sec. 4 of the paper. The authors felt 
strongly that IETF should allow other design options, instead of their 
own designs. Hence, they publish a paper on there design, instead of 
putting them in -req so that only their design is OK.
> And does this related to multiple customers? How is such a customer 
> identified?
See preceding text on Sec. 2.4 DECADE account and the mention on crypto 
>> - 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.
Like I said. I have different opinions on how -req and -arch should be 
I am a minimalist and prefer a larger design space for protocol.

>> The documents intentionally stayed vague as the understanding was that
If I could, I would change:
s/stayed vague/leave as much design space as possible/

>> 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 (
>> 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. 

I share this point, and I think that the docs tried to get as specific 
as possible, and but leave as much design space possible as well. It is 
a tradeoff. If you have strong opinions, please discuss on the mailing 
list. Constructive opinions can be particularly valuable, e.g., you feel 
strongly that each client/app is assigned a unique clientID/AppID and 
then we can discuss.

> 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. 
It does say a lot and answered your question: by an unlimited set of 
clients or limited set. There are multiple design options, control 
channel setting ACL or token, etc. The doc suggested token, but did not 
make it a requirement.

> 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?
The bittorren software client needs to be changed (e.g., with a plugin) 
and the user needs to specify DECADE account(s) that the software client 
can use. A recent design option being evaluated is to use OAuth.

> 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!
Setting up allowed IP address is an approximate way to implement the 
specified client-level access-control requirement.  The existing 
requirement is checkable.

>>> 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.
I think it does. User Delegation means that users are the boss. Storage 
Provider can interject but need to provide error messages. This was 
discussed in the WG and agreed upon.


>   Martin