ICNRG@IETF88 Vancouver Chair: Borje Ohlman (other chairs: Dirk Kutscher, Dave Oran could not make it) - Dirk and Dave were not available for this meeting. - IPR policy - Mailing list info: icnrg@irtf.org; web: http://irtf.org/icnrg; wiki... - Agenda: review of agenda. Packet format proposals, ICN & IoT, discussion on current work item. Anything else? No. - Report from Sunday meeting (all material from Sunday meeting is available on the wiki) 1- ICN and video distribution. Presentation from PPSP (peer-to-peer streaming protocol); most of the discussion on the topic postponed to London as contributors were missing. Contributions for London invited. 2- ICN API and naming. Ideas for common ICN API and naming presented as well; unified ICN framework; new label-segmented URI format proposal 3- CCN updates: new version of CCN protocol specs to be published as drafts; CCN network stack software architecture. 4- Working documents: input presentations: usage scenario for IM; evaluation of Fairness in ICN; scenario document split: ICN baseline scenarios and evaluation methodology; ICN challenge documents: unchanged, plans for a new revision before Christmas. 5- ICN demos: firefox extension for NetInf using NI names in browser; Network experiment programming interface (NEPI); demo of NetInf video streaming and dynamic HTTP streaming. Anything missing from presentation of Sunday meeting? No Upcoming meetings: ICNRG meeting on Sunday before the IETF89; volunteers for hosting the meeting? Regular ICNRG meeting @ IETF89 ----------------------------------------------------- ICN Management Considerations. draft-corujo-icn-mgmt-02 Presented by Kostas Pentikousis Quick draft update. Draft is contribution-driven. Reflects the interest of the people on the author list. Those not in the previous meetings, it started from previous paper from Daniel in Communication Magazine on ICN management focused on NDN. Added section on NetInf, and then added interest in two directions: management of video adaptation; content management. Draft reflects contribution of Spiros and Stefan. For video adaptation, you have the possibility to do interesting things in an ICN. MPEG-DASH seems a way to go. They have done work for a version on top of ICN. You can do more interesting things if you have information about different connectivity opportunity or link event, or altering the video delivery. Text in very early phase, but contribution driven. So if you work in this area and share this interest, Daniel will be happy to work with you. For content management: interesting to control where things are stored (or not) in the network. Content distribution based upon ICN, should take content management into account. How can you integrate different ecosystems? We may be able to do different things in content management. Towards -03: for -02, the emphasis on bringing more people on board, to accommodate new content. Now, rewriting of previous section s(NSN management, NetInf Management) to bring more uniformity and extend new sections. We are also open to contributions in other areas impacted/impacting management. Contributions welcome: management can interface with secondary and tertiary systems (network, content, users); evaluate different inputs and act for optimization. SECURITY important. Slides written before today's plenary. We welcome contribution on security to the draft. Q: Hitoshi Asaeda. Video steaming part seems to be QoS control or rate control. So term of management is not fit for this quality control. A: not an expert in video adaptation. Not sure I would frame it in terms of QoS. The demo Borje showed (two phones downloading a video stream, the first one from the server, the second one from the other phones; what if low quality is stored, and you have consumed the high quality content) required an adaptation that would work with the content management of Spiros. Q (follow): does not really on adaptive streaming or MPEG-DASH, it's just ICN architecture. A: technology means protocol; I don't think the discussion in the draft is on a specific technology. It's more (and I'm speaking for StefanÉ) to see if adaptive video fits well with ICN, perhaps better than host-centric paradigm. You can think of mechanisms you allow to get better return for your value. Q: Hannu Flinck (NSN): aren't you mixing services applications and management altogether, unless you have redefined management for your context? A: Slide Towards-03 states: further editing. There are blocks and pieces here, needs more editing. A: Hannu offered to contribute. Borje: we need to sort this out Kostas: a playground right now Q: optimization processes. It is used to mention ICN specific optimization. What I would expect form such document Borje: please bring this discussion to the mailing list. Kostas: Key to remember working item on challenges. Something challenging should be directed to challenges document. ------------------------------------------------------------ GlobeTraff: a traffic workload generator for the performance evaluation of ICN architectures Presented by Kostas on behalf of the authors (Katsaros, Xylomenos, Polyzos) Presented at NTMS'12 (a conference on management) a year ago. Motivation for this work: some test traffic to make an experiment is required. As you see in evaluation document, we don't have a good handle. No traffic traces, we don't know if these distributions would materialize in the future assuming a full scale ICN deployment. But a lot of work on traffic analysis and developing models on how traffic looks like in an IP network. Tool: synthetic workload generator, based upon current traffic model. But maybe can be extended to other traffic models. Chose parameters for popularity characteristics and for object sizes, based upon existing traces. Models implemented: web, P2P, youtube, other. GlobeTraff tool based upon ProWGen tool, command line written in C++, Java GUI to drive the tool. Output stored in two files which can then be imported into simulation. We (i.e. Kostas) will have two paragraphs in the Evaluation document to describe GlobeTraff Q: Jan Seedorf. What's in the file? A: You get two things, table 1: objects in workload; table 2: workload in time. Better than Poisson traffic or CBR. Borje: anyone in the audience used this tool? A: no raised hand. ------------------------------------------------------------------ Using ICN in disaster scenarios (draft-seedorf-icn-disaster-01) presented by Jan Seedorf Presented this last time, and updated the draft. Who saw it last time? About half. Part of GreenICN project, focusing in disaster scenarios. We're convinced that ICN approach is good for this approach. New section: concrete use cases and requirements. We want feedback from the WG on this. GreenICN: Euro-Japan joint project. Focus on naming, routing, also looking into pub/sub scenarios. And energy efficiency is one of the main themes. Two main use scenarios: disaster recovery and video delivery (more no this in the next presentation) Scenarios driven by the Great Earthquake of 2011 in Japan. In such scenario, energy and communication are very important. High level research challenges: enable usage of functional parts of the architecture when backhaul connectivity is lost; decentralized authentication; delivering/obtaining information in congested networks. How can ICN be beneficial: routing-by-name, authentication of named data objects; content-based access control; caching are all very useful for this scenario Q: Kostas Pentikousis EICT. Clarification question: you are talking about specific things in ICN, which approach do you consider? A: Eventually we'll have to. Answer is generic. We have these problems, but we want to advance the state of the art. We're at the stage of filtering what is most suitable for our problem. The truth,there's no perfect match. Maybe we'll have to enhance one with properties of the other. We like self-certifying names a lot. CCN on the other hand has running code. We won't reinvent the wheel. Q: Kostas: do you have a matrix that says, for our particular use case, this approach has this benefits? A: we're working on this. My understanding is that none of the existing architectures are a perfect match. We'll probably have to pick one and enhance. This is not specific to this scenario. We want to have scalable routing and self-certified naming. One of the contribution of the project would be to build something specific upon one of the existing proposals. Use cases and requirements: new section in draft-seedorf-icn-disaster-01. Use cases: delivering messages to relatives/friends; spreading crucial information to citizens; verifying and spreading information from citizens to citizens. All with associated requirements. Would like feedback and comments. One good comment already to have an evaluation matrix. Others? Q: Hitoshi. What is the goal of the draft? A: Currently to make the research community aware of what we're doing and get feedback. In the long term, maybe this can be a document for this specific use case. Q: GQ Wang (Huawei): Is this using lightweight CCNx? A: lightweight CCNx is very interesting to us, low energy you can achieve something, we are looking at it right now. Q: Kostas. Are you planning to do simulation? A: we will develop something and try it out. We will do simulation and some prototype implementation. Q: most people do not have the capacity to build a testbed. It would have more impact if you had a simulation tool. It's critical we have more simulator. A: I don't want to go in project details, we have industry partners. University want simulation, industry want prototype, we'll do both. Q: Kostas: case of where you take a problem and you show how it's done better in ICN. Demonstrate that it's done better in ICN. Q: Emmanuel Baccelli (INRIA). We have a CCN lite port on RIOT, which is an IoT platform, and we plan on making some real tests on testbed. Q: Elwin Davies. If you were to do a simulator, do you have access to traces you can use? A: we have huge data sets from our Japanese partners from earthquake: where people were, where infra failed, what people wanted to do. This is one of things that I like about this project, we have this real problem that happened in Japan. Q: Elwin. EnergyÉyou are interested in the total number of messages that go through. A: You are all right. There are many aspects to it. -------------------------------------------------------- CCN Application domains. Jan presenting Authors: Andrea Detti, Nicola Blefari-Melazzi. CCN issues: ICN has critical issues for large scale deployment. CCN: stageful forwarding; Universal caching: is it a solution? Such issues are congenital to ICN: issues are a deep part of CCN. People are trying to patch/alleviate these issues when they are part of the core paradigm. Idea: CCN on the edge, application-domain. They don't want an universal deployment of CCN, but a domain where there is an overlay which serves a specific application. CCN client in end-user device, but don't need a CCN architecture. You can tunnel over IP. Connection with user and application domain uses legacy Internet. Proposal: CCNx running on edge devices. "having a CDN per application using CCN". Why using CCN in this framework? used it for P2P video streaming; pub/sub topic based service in MANET. It works, but not in a global environment. Devil's advocate: CCN vs CDN. More questions than answers. Some technical advantages, authors looking for answers. Q: Kostas. Go back to slide 6. I'm more confused, what are they thinking about? I have no clue why a particular domain would do this? A: general idea is to have a CCNx client on the device. Not all routers on the Internet would have CCNx. The first edge router would have it. You would tunnel over IP into your domain where you run the application. Definitely there are questions, on-going research. The question is for CCNx expert: are you considering this? Q: Emmanuel Baccelli. This comparison was done by Akamai. With CDN, you have someone to talk to and it's easier control, you can remove content, you can do accounting, you can do measurements. A: the proposal is not talking about who is operating this CCN domain or CDN replacement. It could be Akamai. The reason they have control it's because they have control of their servers. Question they're asking: can you convince someone to use CCNx Q: Borje: you might have answered my question. The idea of doing some ICN approach in the edge network and then tunnel, I believe it's an excellent idea to get started. What I don't understand is why you would want to do it in a per-application basis. A: control is one answer; maybe it's a necessity. If you have universal deployment, you can cache on the same node; but if it's not universal Q: Nacho Solis (PARC): The answer to Jan's question is YES: we are thinking of sensors talking to only sensors, or to a single app, or to a subset of nodes speaking CCN. If we can provide something that provides a single app for security and communication. We however think that in the future, some years, there's going to be more than one app. Our current stack runs from small processors to big servers, and we plan to keep it this way. -------------------------------------------------------------------- CCNx 1.0 Wire Format Marc Mosko (PARC) TLV format with 2 byte T, 2 byte L. Issues with other length, in particular how to normalize aliases. 2+2 solves these problems and is not wasteful in bytes. Overall packet format has a fixed header (protocol version, type of message, payload length, then header length of optional TLVs). Optional TLVs are not part of security signing (for instance, nonce for loop prevention or a hop limit). They are not signed by the creator of a content object. In the payload, there is a message. and then the message specific TLVs. Name has grown up quite a bit: specific name components have types. By putting the type as a distinct field in the name component, remove aliasing problem. Interest format: one mandatory field, the name. Can add optional TLV (content hash, scope, etc) Content object has 3 mandatory fields: the name, the name authenticator (key ID, key locator, crypto); and a mandatory signature block. Fragmentation protocol uses per hop headers. The interest is the probe, and record the minimum MTU along its path, like IPv6. Q: Kostas: doesn't that assume one path hop and done. A: Nacho: yes, that's how CCN works A: Mark: that reverse path has to remember the MTU along that reverse path. If I receive two interests with a 9k and the 1500 path for the same data, the PIT has to remember the path MTU from the interest. One issue with fragmentation: you can't route until you know the name. You have to match the content object to the interest. Q: Mark Stap. If an interest can be fragmented, does the name have to fit in one fragment? A: this is practical thing to do, or you have to do hop-by-hop reassembly of fragments. We're not trying to do a secure hash chain. Fragment streams id are random, so difficult for an attacker. Also new: hash-based forwarding scheme. Systems who want to remove the LPM can pre-process a hash, and insert this in the header. CCNx 1.0 protocol roadmap: Core protocol + bunch of functions: discovery protocol, wire format, hash forwarding, fragmentation, etc. ---------------------------------------------------------------------- Packet Format. Mark Stapp (Cisco) Terminology: object, messages, packets. Multiple layers and areas on how to encode the objects. We think it's important to be able to experiment. Q: Kostas: clarification. Symmetric is only with the path the packets take, not the property of the links A: correct Working with 3 NDN messages types: Interest, Content, Nack. Recent work on congestion control: network can do forwarding decision, and congestion management, important to get info flowing. So a different kind of flow of messages is important. TLV format: 1+1 and 2+2. Value in shorter representations when data carried is small. So two schemes, more compact representation for places that care if the message is 60 bytes long as opposed to 80. Message header: we don't see the value in arbitrarily large application layer protocols. Protocol that it's valuable to have a MB thing is not (to me) realistic. Speculative forwarding and multi-path forwarding might need nonce, so we just stuck a byte in there. Header option TLVs for loop detection and cross marking. Not signed by producer so it can be modified in flight. Name is always the first TLV for us. CCN inserted another four octet there, we are not doing this. Fixed part of message is that you can find it fast. Offers the opportunity for exploration from the layer on up. But with some rules that allow wire speed forwarding. Q: Kostas. Demo at SIGCOMM, with this the format you used? A: yes, very like this. Some slight differences, but more or less this. We were not exactly using the same software. Q: Elwin: when you say hops, there's a lot of pushback against hop-by-hop header A: I don't think so. Necessary to experiment. Before putting 16 octets of nonce, we have to see where it's required. ---------------------------------------------------------------- Update on NDN spec. Beichuan Zhang, University of Arizona Approach: re-examine design decisions. Current packet format: CCNx and Cisco. TLV-based, number of simplification to packet format. Are considering the NAck, but want to do more study. Writing some technical documents, currently in progress. Borje: goal to make people aware of this discussion. NDN people are continuing this discussion next week. CCN building real things, and we need to refine the proposals. We're not going to solve the issues today. But if people from the rest of the community have questions? Q: Emmanuel Baccelli. There are a lot of different things, which in a different sense belong to different places in the network stack. For instance, fragmentation, where will this be used? Is this IETF the place to discuss this? What's the actual architecture that we are aiming for? How do we separate the different mechanisms? A: Mark (CISCO): we just are trying to share things with the community. No standardization, this is IRTF. There are convergence in some areas, no agreement on other. People say: you don't fragment; other say: it's transport problem, it's not part of the problem; we are thinking about these problems, we have a few minutes to cover this. Q: it's at a stage where we as a research group can challenge this. A: Mark (PARC), there are different concerns that you would have in ICN (NDN/CCN provides reverse data path forwarding) Q: GQ Wang. For the assembler, is the operation optional, or no assembler at all? A: Mark (PARC) assembling in the middle depends on how you want to handle interest. Either you need to re-assemble and handle time-out and dropping, or you have to wait until you get the name. In the hash forwarding, A: Mark (CISCO): that's the all spectrum, hop-by-hop and we don't worry about it, or end-to-end and do path MTU discovery. Q: Emmanuel Baccelli. Other thing to mention, we need to start talking about small MTU. I come from 6lowpan background. Whenever you design these packet formats, do you have in mind these efforts they put into header compression? A: Mark (PARC) for very constrained, where 5 bytes make a difference, you will need to do your own customized protocol. there is a trade-off between desiging for the common case and the specialized case. Q: Elwin. Security? Given the hassle in DTN regarding security and fragmentation, watch it! A: Borje, we can bring in DTN people into Sunday meeting in London if you think it's valuable conversation. ---------------------------------------------------------- ICN-Based architecture for IoT Presenter: GQ Wang (Huawei) In 2020, 50 Billion to 75 Billion connected nodes in the Internet. $1.5Trillion market value according to John Chambers. IoT scenarios have variety of scenarios: smart home, smart grid, etc. All share large scale. List 11 architecture requirements. Some features common to ICN applications, some specific to IoT. For instance, scalability crucial when 75B devices. Late binding to support mobility. Proposes ICN-centric unified IoT platform. IoT middleware on top of ICN network connecting things (sensors, tags, feeds, actuator, DBs) to services (apps, services) Scenario: location context service in RDF, for cab/taxi services. Users: cab driver interested in joining the service, registering name, car, etc; other users: cab customers, with location and car requirements. In this scenario, all is stored in a service router at the edge. Vision for requirement document: try to define generic requirements for ICN IoT. Conversation with Kostas to merge this into baseline document. Maybe this can be merged with challenge document. We suggest to organize a work item similar to video streaming specifically on IoT applications and technology study in ICN. Huawei is willing to lead such a work item. The more people, the better. Expectation: one of the most successful standard in IEEE was ethernet. Some people say IEEE defined only 1 standard. If you have ask the inventor of Ethernet (Bob Metcalfe at PARC) what was the critical factor, and the answer was: 1) simple, ethernet was simple; 2) open; 3) installation base. We propose to use the IoT to validate the usefulness of ICN solution, no matter what this solution is. We hope to install ICN to 75B devices, that would be the largest installation base! If ICN works for IoT, it will work for the all Internet. Borje: I believe this is a good benchmark. Q: Will Liu, Huawei. I support this, however, for IoT, machines only have limited bw and caches. How to take advantage of in-network cache? A: This is one of the study topic. From the protocol design perspective, I would expect to design protocol that could be used for both IoT and infrastructure worlds. If you look at packet format, you have 1+1, or 2+2, you have to think of IoT. Q: Lixia Zhang (UCLA) GQ's talk is great. In Beichuan's talk, there was a factor. The NDN team drives the design, but application and testbed drive the deployment. One of the application of NDN is IoT. Efficiency is one of the top design consideration. Would like to talk more if people interested. Q: Kostas: with editor hat on, we have an IoT section. Definitely, we cannot have 15 pages in the scenarios. I would support having an item in IoT as a work item, that would be a good thing. Question on slide 8: control data path separation, but you have management in small characters. Talk to Daniel. Q: Emmanuel. Very interesting work item, interested in contributing. There was a work item in identifying challenges in ICN in non-IoT item. What this WG can add at this point is communication in IoT with ICN paradigm. Not sure we need to spend so much time on IoT scenarios, but rather jumpstart the effort on identifying the challenges and the specific differences with the already identified challenges. This "diff" would save time and it's a very interesting item. It would leverage work already done in this WG. A: Borje: good point, continue discussion in the mailing list. We can make a decision in London if there's activity. Q: Elwin. Big thing that does not come up from this pictures is the time element. CCN is mentioned. Sensors are not going to be able to talk all the time. ICN aspect and caching are critical due to the fact they won't be able to talk all the time. Need to know if protocol can take this time dimension into account. Pictures look like permanent communication everywhere, and we don't. A: good point. Publisher could determine TTLs. --------------------------------------------------------------------------- ICN: Baseline Scenarios. draft-irtf-icnrg-scenarios-01 Presented by the editor, Kostas Pentikousis Draft presented again and again, just doing draft updates. Extensive decision in IETF87: adopt by ICNRG and finalize by Vancouver. Put on RFC path by end of the year. Difficult to modify, would like to freeze the document. Enough scrutiny by now. Call for 3 critical reviews: Mark Stapp, GQ Wang, Juan Carlos. Reviews will be posted to the mailing list. Met the goals that were set at the beginning: Community viewpoint, technology agnostic, etc. Q: Dimitri Papadimitriou. Section on summary may be elaborated on two perspectives: common dimensions. A: Borje: please email to the list, talk to Kostas. ICN: Evaluation Methodology Presented by Kostas. Cut short by time. Editorial changes. PLEASE CONTRIBUTE. ------------------------------------- Borje: meeting adjourned.