DECoupled Application Data Enroute (DECADE) Problem Statement
draft-ietf-decade-problem-statement-06

The authors have edited the required changes in the draft instead of summarizing everything in an RFC editor's note. All remaining comments have been addressed in the -06 version of the draft.

[Ballot comment]
I have no objection to the publication of this document.

I wondered whether Section 5 should discuss the problem that in-network
storage may result in false data being supplied either through the
data on a legitimate store being modified, or through a bogus store
being introduced into the network. The material in Section 5 seems to
cover the security of the protocol itself (and that may be enough)
without describing these risks. Sis I miss something?

[Ballot comment]
I agree with Peter's thought about para 1 of s3 sounding a lot like marketing.

I was surprised by the references to RFC 3414 in s5.4-5.7.  Is that where the solution is expected to come from or where the definition came from?  If it's the later wouldn't RFC 4949 be a better reference - it's the Internet Security Glossary, Version 2.  Also are there any privacy considerations to be worried about?

I also found myself thinking along the same lines as Ron and Robert.

[Ballot discuss]
The document may be conflating the following issues:

- Problems that P2P applications present
- How those problems can be solved by in-network caching
- Deficiencies in currently deployed in-network caching solution.

Deficiencies in currently deployed in-network caching solution might include:
- lack of standardized singling protocols
- lack of access control mechanisms
- etc

While the first first two issues are interesting, I think that the WG wants:
- for the reader of this document to focus on deficiencies in currently deployed caching strategies
- to address  deficiencies in currently deployed caching strategies

Would it be possible to make that more clear? One thing that you could do to focus the reader's attention is to remove text that isn't relevant to the point that you are making.

[Ballot comment]
Here are some suggestions that might make this document more useful to the working group:

Much of this document states the problem is that there's no standardized network storage solution. That's the solution you want to pursue, not the problem. A reader can get that the problem is some peer-to-peer protocols put stress on access networks. A potential solution that might treat the network as a whole more nicely would be to make it possible for peers that were on bandwidth constrained access to put things in a place that is both not bandwidth constrained and accessible by other peers. A secondary problem is that if existing protocols each tried to make this possible in their own way, it's harder for middleboxes that aren't explicitly part of that protocol to inject themselves to "help", and that could be avoided by giving all of the existing (and potentially any new) p2p protocols a common way to minimize moving content across the constrained barrier. A reader can get this message, but they have to read deeply and infer some of it. Please consider making the problem the main point of the text, and clearly identifying that network storage is the proposed solution path.

The document speaks of a service "inside a network". It would help to be more precise. Do you mean "in the relatively bandwidth-unconstrained part of the network" or "in an access-regulated single administrative domain" or something else?

The document asserts several times that using in-network resources will help, but doesn't support the assertion. Are
there studies you can point to that show it's likely to help?

The second paragraph quotes some reports on p2p traffic on access networks, using it to motivate reducing access traffic, but then claims it also motivates reducing "cross-domain and backbone traffic". While reducing traffic in general is probably a good idea the argument presented doesn't support the conclusion.

The document says a P2P cache is likely to be much better connected to end hosts than to remote peers. The remote
peers _are_ end hosts. What are you actually trying to distinguish here?

Section 5.2 (Copyright and Legal Issues) puts filtering and DRM out of scope for this document. It would be better to say something like "is not in scope for the problem this document proposes solving".

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (DECoupled Application Data Enroute (DECADE) Problem Statement) to Informational RFC


The IESG has received a request from the Decoupled Application Data
Enroute WG (decade) to consider the following document:
- 'DECoupled Application Data Enroute (DECADE) Problem Statement'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-03-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Peer-to-peer (P2P) applications have become widely used on the
  Internet today and make up a large portion of the traffic in many
  networks.  In P2P applications, one technique for reducing the
  transit and uplink P2P traffic is to introduce storage capabilities
  within the network.  Traditional caches (e.g., P2P and Web caches)
  provide such storage, but they are complex (due to explicitly
  supporting individual P2P application protocols and cache refresh
  mechanisms) and they do not allow users to manage access to content
  in the cache.  For example, content providers wishing to use in-
  network storage cannot easily control cache access and resource usage
  policies to satisfy their own requirements.  This document discusses
  the introduction of in-network storage for P2P applications, and
  shows the need for a standard protocol for accessing this storage.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/


No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup.
Updated AD Review for draft-ietf-decade-problem-statement-04

My job as Responsible AD is to bring documents that one of my WGs has requested
be published to the IESG. Part of my responsibility is to make sure the document
is ready for IESG Evaluation. I still have concerns with this document.

PPSP WG submitted a problem statement, and it drew four DISCUSSes because it talkss about things not appropriate to a problem statement document.  I don't want to see the same thing happen with this document. Please rewrite this document to be a statement of the problem, and eliminate those parts that do not belong in a problem statement. This is NOT marketing literature for the wonderful things that DECADE will do.

Below are concerns I feel need to be addressed before I can bring this document
to the IESG.
1) There are references to current IETF WGs, such as in 3.1. WGs go away,
and this RFC will outlast them. Please eliminate them from the text.
The discussion in appendix A, which discusses related work in IETF is acceptable. The IESG may prefer that this be removed upon publication, but it is useful for the IESG to understand how decade fits with the other efforts. Puitting all references to working groups in one place would make this easy to remove them.
Please move the discussion of ALTO and LEDBAT from 3.1 into Appendix A.  ALTO or LEDBAT WGs may be working on related technologies, but THIS document is concerned with the PROBLEMS that in-network storage addresses. So, for example, you are NOT chartered to "complement the ALTO effort", but you are chartered to describe the need to reduce upload access traffic.
/it becomes increasingly important to complement the ALTO effort and reduce upload access traffic/it becomes increasingly important to reduce upload access traffic/
If it is really important to discuss work going on in the IETF, please use "The IETF is working on ..." rather than "The XXX WG is working on ...". If the work has been published as an RFC then you can refer to the IETF technology.

4) There are many instances of marketing-like promises of what "DECADE" will
provide. This is a problem statement, not a marketing document. DECADE is not a
product, or a standard.
Please stop talking about DECADE and talk about the problem.
in 1, "This document introduces DECADE, a standard interface ..."; That is NOT what this document is for. There is no DECADE standard interface, so you cannot introduce it. You should be talking about the problem(s) that in-network storage will address, and what problems decoupling will address.
OLD:
This document introduces DECADE, a standard interface for various P2P applications to access storage and data transport services in the network to improve their efficiency and reduce load on the network infrastructure.
With DECADE, P2P applications can still use their native protocols for signaling and data transport. However, they may use a standard protocol for data access incorporating in-network storage, and fall back to their native data transport protocols if in-network storage is not available or not used.
NEW:
P2P applications suffer decreased efficiency, and the network infrastructure suffers increased load because there is no standardized interface for accessing storage and data transport services in the Internet.
OLD: "With DECADE, P2P applications can still use their native protocols for signaling and data transport. However, they may use a standard protocol for data access incorporating in-network storage, and fall back to their native data transport protocols if in-network storage is not available or not used.";  This is not a problem description; it seems to be a solution description. Maybe fallback is a requirement (which means it belongs in the requirements document, not here).
OLD: "In essence, an open, standard protocol to access in-network storage provides an alternative mechanism for P2P application data access that is decoupled from P2P application control and signaling. This decoupling leads to many advantages, which is explained further in Section 4. " This sound slike a description of a design decision in developing a protocol. Maybe it's a requirement. It is NOT a problem as far as I can see.
If coupling is a problem. then describe what coupling is and why it is problematic.
OLD: "And further, either the existing P2P cache or any new type of in- network storage should be deployed near the edge of the ISP's network so as to gain better performance." sounds like part of a proposed soltuion rather than a description of the PROBLEM.
in 4,
OLD: "DECADE aims to ..." sounds like a proposed solution, not a description of the PROBLEM. You might try rewriting this to disucss how existing P2P caching works, and why it is insufficient to meet the needs of operators today. But please resist the urge to explain how DECADE fixes it.
in 5, these use cases should be discussing the PROBLEMS that occur in thise use cases, not how to integrate with DECADE.
Everyplace you mention DECADE in the text as a solution, it doesn't belong in this document. Please change DECADE server to "in-network storage server"
in 5.2, "If it desires, a content publisher may still apply DRM to the payload. This is independent of any authentication or authorization provided by DECADE." Since DECADE doesn't exist, you shouldn't be discussing the authentication, authorization, or payload of DECADE. The PROBLEMs  of authentication, authorization, and DRM can be discussed (although you probably don't want to get into a deep discussion o fthese until you get into develooping a protocol. I suggest mentioning these in Security Considerations.
9) Security Considerations should discuss the security threats/vulnerabilities
that apply to in-network storage. These ARE part of the PROBLEM space, and these things DO belong in this document.
Saying "they are too numerous to mention" will not get your docuent approved. You need to consider what the thteats to in-network storage are, and document the problem they present.
I suggest looking at RFC3414's description of some standard threats in section 1.1.  I recommend describing the threats, and stating whether they are primary, secondary, or of lesser importance to in-network storage.
You can also look at RFC3553, BCP 72, on writing security considerations. It is important to recognize that your document is a PROBLEM STATEMENT, so all you need to do is document the security problems of in-network storage, not document how DECADE will mitigate those problems. When we get to requirements, we can document what a decade protocol must be able to mitigate, and when we develop a protocol, we can document how the threats are mitigated.
You might want to break the security considerations down into data-at-rest issues versus data-in-motion issues.
new:
10) in 5.3, there is no such things as a decade server because there is no such thing as a decade protocol !!!!!!!! please call it an in-network storage server.
11) it is generally not useful to capitalize terms like Content Publisher unless the term is very specifically defined in the document as part of a protocol. You are not defining a protocol, so I think using lower case (just plain old English) is adequate.
12) in 5.1, it says can copy to storage and then upload from its network storage, "again avoiding usage of the last-mile uplink", but this only avoids using B's last-mile uplink, right? It does however use A's last-mile uplink, doesn't it? I think the wording could be a bit clearer.

AD Review draft-ietf-decade-problem-statement

My job as Responsible AD is to bring documents that one of my WGs has requested be published to the IESG. Part of my responsibility is to make sure the document is ready for IESG Evaluation. I have concerns with this document.

I don't have technical concerns with the document, so much as editorial and process concerns.

As Responsible AD, I request that the WG rewrite this document to be what it is supposed to be, and eliminate those parts that do not belong in a problem statement.
I believe this will not take very long, since in many cases, it just requires some rewording. In other places it will require removing portions of the document, but they might be saved for other documents where the text would be more appropriate.

Here are some of the IESG DISCUSS criteria that I think could be triggered on this document.
- IETF process related to document advancement was not carried out; e.g., the document is outside the scope of the charter of the WG which requested its publication, and so on.
- The specification would create serious security holes, or the described protocol has self-defeating security vulnerabilities (e.g. a protocol that cannot fulfill its purpose without security properties it does not provide).

Below are concerns I feel need to be addressed before I can bring this document to the IESG.

1) There are Informative references that I think don't really need to be there. Some are to Internet-drafts. What happens if that ID never gets published? Having references to work in progress can delay publication of this document. Please make sure these references are REALLY needed in the text.

2) There are references to current IETF WGs, such as in 3.1. But WGs go away, and the RFC will outlast them. Please make sure these references are REALLY needed in the text.

3) This document has a title that says it is the problem statement for Decoupled Application Data Enroute. But throughout the document I find instances of proposed solutions.

4) There are many instances of marketing-like promises of what "DECADE" will provide. This is a problem statement, not a marketing document. DECADE is not a product, and despite what section4 says, the goal of the WG is NOT to design DECADE; it is to identify applications, describe the requirements, and develop an architecture. The WG is explicitly prevented from developing the protocol without going through a recharter. Here are some claims:

"DECADE provides basic access mechanisms"
"DECADE will provide access to storage and data transport services in the network to improve their efficiency and reduce the stress on the network infrastructure."
"It also improves the availability of P2P contents because the in-network storage is always-on."

So how does an architecture without a protocol do all these things?

5) in section 4, it says "(IAP), which is a standard, P2P-application-agnostic protocol ..."

IAP is NOT a standard protocol. A document that is a work in progress that has not yet been approved should never claim it is a standard. And the WG is not even working on designing a protocol yet, just a problem statement, requirements, and an architecture, right?

6) Section 4 claims, IAP includes the following functionality (and then lists a number of things). But the WG is not authorized to work on protocols yet; how can you know what that protocol includes? and why is this description of a proposed solution in the "problem statement" document? You should be describing the problem, not the solution.

7) in section 5, there are lots of "A instructs its in-network storage to downlaod a block from B's in-network storage, and finally A itself retreives the block." How is this a problem statement?

8) in section 5.1, paragraph 5 discusses how B can attach its storage address in the message to its tracker. The WG is NOT designing a protocol. How can you possibly know what can be passed in the message? This problem statement can certainly tak about the problem to be solved, but should NOT be talking about the details of how a proposed protocol works.

9) Security Considerations should discuss the security threats/vulnerabilities that apply to in-network storage. You don't need to describe how to mitigate them here; that can be done in the requirments, architecture, and protocol documents. But you should include the problem description here. The chairs can ask me if they want a security advisor to help develop an appropriate threat analysis.

David Harrington
Director, IETF Transport Area
ietfdbh@comcast.net (preferred for ietf)
dbharrington@huaweisymantec.com
+1 603 828 1401 (cell)

(1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

Richard Woundy (richard_woundy@cable.comcast.com)

He has reviewed this document personally and believes this draft version is ready to move forward.

(1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

At IETF 79 in Beijing, the WG chairs selected three key WG members as reviewers for this document before the WGLC: David Bryan, Akbar Rahman, and Ning Zong. All three plus Roni Even, Börje Ohlmann and Tao Ma provide substantial review comments on the draft, resulting in draft revisions on 20 December 2010 and 22 January 2011.

WGLC started 28 January 2011 and completed on 14 February 2011, drawing further reviews from Rich Woundy, Wes Eddy, and Lars Eggert. Comments from the WGLC are reflected in the draft submitted on 14 March 2011. From this experience, this document appears to have received sufficient review.

Akbar Rahman


David Bryan


Roni Even


Ning Zong


Tao Ma


Richard Woundy


Wesley Eddy


Lars Eggert


(1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No. This is a problem statement document, and provides the motivations for the DECADE effort and its scope. Optimizing peer-to-peer applications are the primary motivation for DECADE, and the document authors and reviewers are well-versed in P2P technology. There does not seem to be a need to review the document from another perspective.

(1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

There are no such concerns nor IPR disclosures.

(1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG strongly supports this document for publication. Many WG members have read and agreed with it.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Yes.

(1.h) Has the document split its references into normative and informative?

Yes. But only informative references are used in this document.

Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

No normative references.

(1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

This document does not have any IANA considerations. No Expert Review process is needed.

(1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

This problem statement document does not include any such formal language.

(1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

This document provides an introduction of DECADE in-network storage for peer-to-peer (P2P) applications, and for other applications with similar requirements. This document shows the motivations for a standard protocol for accessing this storage, identifies the scope of this protocol, and enumerates potential usage scenarios.

Working Group Summary

This document is a product of the DECADE WG, and was reviewed in working group meetings and via the decade@ietf.org list.

Document Quality

The document was reviewed by DECADE WG members, the WG Chairs, and key non-WG contributors, particularly by Akbar Rahman, Roni Even, David Bryan, Ning Zong, Börje Ohlmann and Tao Ma.