DECADE WG, Tuesday, 13:00-15:00 =============================== (version 1 - August 5 2010) DECADE WG Minutes Meeting: IETF 78, Tuesday, July 27, 2010 Location: Maastricht Exhibition & Congress Centre (MECC), 0.2 Berlin, 1300-1500 Chairs: Rich Woundy, Haibin Song Minutes: Enrico Marocco, edited by Rich Woundy According to the blue sheets, there were 67 attendees. [These minutes represent a condensed summary of the meeting. Fully detailed discussions can be heard on the audio recording of the meeting, to be found at http://nagasaki.bogus.com/ietf78/ietf78-ch2-tue-noon.mp3, starting at offset 00:43:52.] Agenda ------ 1. Administrivia 2. Problem statement, draft-song-decade-problem-statement-02 3. Requirements, draft-gu-decade-reqs-05 4. Additional use cases and requirements, draft-ohlman-decade-add-use-cases-reqs-01 5. Survey a. A Survey of In-network Storage Systems, draft-song-decade-survey-04 b. An Additional Survey of In-Network Storage Systems, draft-rahman-decade-survey-00 6. Conclusion and next steps Rich Woundy presented the agenda, the history of the WG, a high-level overview and milestones. He would like the WG to make decisions about adopting drafts for upcoming milestones. There were no comments nor questions. [audio offset 00:50:30] Problem statement ----------------- Haibin Song presented the problem statement slides. Haibin indicated that the problem statement needed a security review; this will be followed up on the mailing list. Dave McDysan: I read it on the plane and support adoption. Rich W: Should we get a hum for adoption? David Bryan: First, are there any reasons why it should not be adopted? There was no response. Hum: Should we adopt the problem statement as a WG item? Outcome: There were several in favour, and none against. [audio offset 01:02:00] Requirements ------------ David Bryan presented the DECADE requirements slides. Dave McDysan: This draft is not as clear as the problem statement. One comment out of many I have is, the latency classes need further discussion. I Will send them to the list. David B: Please do. Rich Woundy: Let's stick to clarifying questions during the presentation, and save substantive comments until the end. Roni Even: About resource control, why not just list per-peer and per-data resource control as nice-to-have? David B: It's still not clear why. The document is not a mature document, and the authors are looking for feedback. Dirk Kutschaer: Have you considered what authentication mechanisms are needed? David B: One way is allowing clients to use its own authentication mechanism, and another way is allowing authentication mechanism specific for DECADE. We have thought about authentication for write permissions, but have not thought about the authentication that the content originates from the one who signed it. Richard Alimi: This is not about copyright, right? Dirk K: Maybe. Richard A: Copyright is out-of-scope per the charter. Lars Eggert: It seems we are designing a NFS, but we are not, right? David B: Where do you see that? I think we are on the same page. Lars E: I see a shopping list of nice-to-have things; it is not as narrow as I'd like it to be. David B: We are making assumptions and do not want to define a new NFS, but slides are broad and we want to check with the group about whether we missed something. Lars E: I'm not happy with "Data Availability" slide, that's something you should not consider. David B, Lars E and Rich W discussed the nature of P2P caching and storage. P2P applications need to know what the storage system does with cached data with intermittent connectivity, both for the local client and the remote peer's client; without such guidance, applications may not have enough information as to whether they need to restart a write operation or not. (The tradeoff is wasting bandwidth for an unnecessary operation, versus leaving an incomplete/corrupt data object in storage.) Different P2P applications have different expectations about the longevity of cached data; real-time streaming P2P applications might discard cached data in less than one minute, but P2P file sharing might keep cached data for hours. Roni E: The documents does not distinguish between DECADE and NFS requirements. Richard A: The draft tries to identify requirements from the P2P application point of view. Lars E: The applications seem to be diverse, so maybe focusing on them is an exercise that may not be useful. Dave M: Designing a solution that handles more general cases than P2P-only may be a good thing. Richard A: Would a section in the draft saying that we are not (re-)designing NFS help? Lars E: You may want to say that DECADE does things in one precise way, and applications will adapt. David Harrington: The draft makes no clear distinction between application requirements and storage system requirements. For example, a peer authorizing another peer is about P2P, it is not about storage. The draft needs to clarify what applies to applications and what applies to storage. David B: That's good advice. Bhumip Khasnabish: What do the slides mean about platform agnostic encoding? Richard A: Encoding refers to the metadata; see the last bullet on slide 12. [audio offset 01:38:15] Additional use cases and requirements ------------------------------------- Borje Ohlman presenting additional requirements from 4ward project (European community founded project). David B: We need to keep the requirements narrow. The applications are more diverse than what we initially realized, so we need to focus on one particular class of applications (P2P). And we should avoid requirements that are harmful for other applications. If support for other applications comes for free from our requirements, that's fine; otherwise forget about it. Richard A: Some of the confusion lies in the term "application agnostic". DECADE is not chartered to be application agnostic, but it might support non-P2P applications. It would be useful at least to identify what are the characteristic of such additional applications. Borje O: Should we start a WG for similar applications? Lars E: The charter is clearly about P2P; let's not revisit the charter! Borje O: The intention is not to support just any application. Lars E: Multicast may be similar to P2P, and may be declared in scope. Don't be over-broad. David B: It would be useful to list the other applications. Dave M: This is a terminology issue. If we are talking about multicast IPTV, probably that's close enough to P2P applications. Lars: On the "Data Reuse" requirement, this is again a feature of the storage system, not the resource control protocol. Rich W: A clarification question on the roaming scenario: Is it expected that content be prepositioned to where the user roams? David H: Side question to David B: Is this the same thing you presented? David B: I don't think so, but I am not sure I understand this requirement. Rich W: Do you expect the cache to replicate existing content to the new storage service as the user roams? Borje O: The requirement is quite simple. When you move to another network that also has storage service, you are allowed to use that service. Rich W: Are you talking about moving data, or simply accessing the storage in the visited network? Borje O: Only access. Richard A: Can we say that this is a discovery problem, that has to take into account locality? Finding the best storage is out-of-scope per the charter. David H: The charter does not allow anything but P2P. Lars E: The charter is not about designing in-network storage. Francois Le Faucheur: Application agnostic is a funny requirement. The working group should identify specific applications, or do not say anything. Also, data de-duplication is a non-requiremnt, as it is related to the storage. Lastly, about roaming, what happens when I move to the Netherlands? Are my buddies in United States now downloading from a server in Europe? Borje O: Roaming support does not imply that your home server goes away. David H: Redundancy is an implementation level issue. Roaming is basically about inter-provider agreements and discovery, both of which are out of scope. Lars E (relaying a Jabber question from Hannu): The first presentation on Requirements said that DECADE is not limited to a single data transport protocol. How is to be taken in the context of non-P2P applications? Where is the demarcation? Rich W: The charter indicates support for multiple transport protocols such as NFS or WebDAV. David H: It would be hard to build a generic API to meet the needs of all applications. David H: Data reuse does not belong here, because as a P2P application you do not want to know if the data is replicated. It is a non-requirement. Borje O: Maybe not. David H: Support for roaming users is either a requirement on the storage system, or a feature of the application protocol that supports efficient content location. The storage system should worry about the storage location, not the application. Richard A: Low latency transport to the remote peer might be an application-level concern. Yunfei Zhang: About the data reuse requirement - P2P applications store multiple copies of content on purpose. Therefore, keeping only one copy of content may cause another problem with P2P distribution. David H: The data reuse discussion includes knowing that when you put data into storage, you need to know nobody can muck around with your data - that's a requirement, not that each application's storage must be a separate physical instance. If a provider does data deduplication, the requirement is that if anybody changes the data a separate copy is spun off that contains the changes only in that copy. [audio offset 2:17:20] Survey ------ A Survey of In-network Storage Systems -------------------------------------- Richard Alimi presented a survey on in-network storage systems. Dirk K: The survey should also mention RFC 4838 on Delay-Tolerant Networking. [audio offset 02:27:15] An Additional Survey of In-Network Storage Systems -------------------------------------------------- Akbar Rahman presented an additional survey. David H: Webmail is client-server (not P2P), as well as photo sharing and all the applications in this survey. Rich W: This discussion isn't about use cases, just a survey of technologies that may apply. Rich W: What do the authors and others think about combining the two survey docs? Richard A: Photo sharing access authorization is similar to some P2P applications. Email is less related to P2P. Akbar R: Yes, photo sharing is definitely the closer technology to P2P. Richard A: Let's have the requirements say the solution must provide access control and let applications decide the logic (eg public versus private access). [audio offset 02:38:12] Conclusion and next steps ------------------------- Hum: Should we adopt the two survey drafts combined as a WG item? Outcome: There was strong consensus, albeit one (anonymous) hum against. Rich W: Let's go back to the topic of whether to accept the requirements draft as a WG item. Richard A: The WG draft will distinguish application requirements vs. storage requirements. David H: The draft also must distinguish nice-to-have vs. must-have requirements. Hum: Given those caveats, should the WG adopt the requirements document (draft-gu-decade-reqs-05)? Outcome: There was weak consensus, but none against. At this point, the DECADE session was adjourned.