ICNRG ===== Agenda Bash ----------- Dirk: Welcome RG Please consider Note Well All: No questions on the agenda. Data-Name Integrity ------------------- James: why did you dismiss signatures? Steve: Group signatures could be interesting - but many of these things are flaky. Dave: less conventional approaches to data integrity - do you know of actual work? Do you want to get involved and bring it to the RG? Kevin: Private keys - what will be named and where will private keys be held? Steve: Publisher, owner,... private key management Kevin: will devices carry the private key Steve: needs to be on some server. Dave: Can't say anything on whether you be believe data. You can say data has changed. May be a higher layer problem. Or try to build a provenance system into the layer. Will impact your design. Steve: Also consider experience of the object, who looked at it. Steve: Try start some traffic on the mailing list on this topic. ???: [could not hear.] Kevin: we don't have to do use cases as in the IETF... useful considerations? Van: how do you ddos an ICN network? Fundamental exploit. If you have provenance the network can protect itself. Steve: interesting question to investigate draft-narayanan-icnrg-bgp-uri ----------------------------- Van: core problem with BGP for ICN is the assumption that you are distribution on a spanning tree. You only propagate a single origin. ICN has data in many places. Works in OSPF and IS-IS. But it has to pick one origin in BGP Ashok: Need some way to remove routes. Increases with factor of 80. You won't be able to keep all sources in the world. Van: You don't have a map - the same information might be on every possible path. The protocol can't give you any useful information. You have no choice in BGP and BGP hides the information you need to choose. Must be a better protocol. Ashok: Yes. Robert: There are attributes that allow you to carry information. But not trying to defend BGP Steve: How to distribute HTTP URL? URI is a locator not a name. Ashok: Locator [...] Threats in Content-Centric Routing --------------------------------- Borje: keep discussions short - provide an overview today. Questions need to be within presentation time. Van: Interesting work. You can limit number of outstanding interests. Relationships in CCN are pair wise. Entity can limit the number of outstanding interests. Static routes set this number to infinity - but that is not a fundamental limitation. [pointer???] simulated all of these attacks and talked about solutions of them. Thread 1 and 2 rest on sending unlimited interests. Matthias: Threat 1 and 2 are based not primarily on an unlimited number of interests. On the other hand, limiting the interest rate introduces new threats. Van: you can bound interests since you know link you are servicing them over. ICN Scalability and Deployability --------------------------------- Van: Problem with aggregation is false positives. You need to compute a route that gets you towards the destination. With false positives, you route towards someone who does not have the data. Akbar: Yes, right on false positives. You need to scale the aggregation, using less aggregation in various scenarios (e.g. for local routers or popular content). I.e., this is done by filtering. Potential Based Routing for ICN ------------------------------- Thomas: global information is needed to create this field? Do you need global state? Suyong: No. Uses information available locally, e.g., load and distance information. Any node who got the advertisements can make this decision. Dirk: Can we get an analysis how well this can handle dynamic information? Update in network. Suyong: Yes. Dirk: Last two papers will be discussed at Sigcomm. Congestion control and in-network caching ----------------------------------------- Ashok: Problem is not AIMD - it is end-to-end AIMD. Hop by hop is fine. Person who is using the least popular content will be choked. Network is not treating individual people the same but is trying to maximize resource use. Damien: overall there is a small unfairness. Ashok: even for skewed distribution? Damien: yes slightly Dave: optimality and fairness is not the same. We have to think about a fairness metric Van: this is now looking at topological effects of caching. In an aggregation network with high bandwidth feeder line and large fan out to subscribers we currently have a problem with saturating the feeder line. If subscribers take bandwidth out of the cache others will benefit. Here you see all competing for the same cache. But if people served by the cache are removing themselves from the bandwidth everyone will benefit. Mirja: There are solutions that are RTT fair. Damien: we have to define the fairness we want. Dirk: need to define this metric. REBOOK: a Network Resource Booking Algorithm -------------------------------------------- [missed name]: What is a resource? Pier: In experiments it is bandwidth. But it is an open framework - anything you can measure and control can be used to make reservations. You can specify minimal and optimal resource requirements. E.g., for a video distribution. Thomas: If you introduce flow state you are threatened by flow-based attacks. Assumption in ICN is everyone cooperates and trusts. This is a question of perspective. Right for single operator. But if we are looking at the Internet the assumption doesn't hold. Pier: Yes I agree. In general we are moving toward a system that provides receiver with software coming from server or provider. In future will be more control between sender and receiver and interaction with intermediary nodes. Dave: need to be efficient on time use. Information-Centric Network in an ISP ------------------------------------- [missed name]: centralized solution will be good. Will your work introduce a new bottleneck in the network? Lichun: ISP can deploy several controllers. You may not have another choice. ???: What is the range of a controller - city, region? Lichun: we just started this and don't have too much data. Need to work on this later. RG Chairs Discussion and Announcements -------------------------------------- ITU-T Liason ------------ Lars: IRTF is a research task force and we don't exchange liaisons. IRTF has no concept of a liaison. The RG is open for all contributions and is inviting input. Is the document publicly available? Suyong: If you have account in ITU-T Lars: Make it publicly available so people can comment Lars: IRTF IPR policy is that we expect people disclose. If you send us documents we expect that IPR is disclosed. ???: How many members do you have Suyong: 20-50 people ???: normally ITU-T does not work on protocols. Suyong: there is another WG in ITU-T who gets involved. Not sure. Suyong: Regarding document - need to find out if it can be made publicly available Dirk: if you are interested in feedback you can ask for comments. We cannot commit to your timeline. Lars: individuals can review the document. The RG cannot commit to a review Dave: you can use this as input just as a paper or discussion at conference. Next Steps ---------- Lars [hats off]: often useful to have an interim meeting. Will give more time to talk about this stuff. Might be good to have this soonish. Ashok: ICN schemes don't converge. Is it worth going down this path right now. Are we ready to document a structure today? Dirk: there have been attempts in doing this. I don't think we need to get conversion but it would be useful to understand the differences. Kostas Pentikousis: Mobility, network management and energy efficiency should be added to the table. There are a few initiatives in the IETF that work on network storage. This is work is ongoing and should be looked at. E.g., DECADE, MultiMOB, ... Dave: Want to push back on mobility as category. Mobility becomes ubiquitous in requirements. Think about mobility for anything. Kostas Pentikousis: almost same as security. People are taking mobile IP and are adding an ICN coating to it. There's more interesting stuff you can do on mobility in ICN. Borje: this is not the final categorization. Would like to seem more discussion on the mailing list on the categories. Dave: follow up on Lars comments on value of interim meeting. Like on the list for people to comment on whether that is possible between now and Atlanta. What venues can be combine with to be more efficient. Maybe we can meet next to CoNext, HotNets? What is happening in next 6 month that is good for cross fertilization? Kostas Pentikousis: Clarification Dave: May meet in Atlanta if there is no better idea. Have a robust discussion on the list and reach a plan by end of August Dirk: propose two work items to get work started. Problem statement and survey document. If you are interested in helping please talk to us or send mail to mailing list.