(Action Item) : it is necessary to track "implementations" on wiki (Dave Oran?) Minutes of ICNRG interim meeting Hong Kong, Sunday August 11th, 2013 ---------------------------------------------------------------------------------------------------------- First morning session - notes taker: Bengt Ahlgren 09:00 Welcome - Chairs Agenda bashing - Dirk Kutscher Welcome by the host - Jianping 09:15 Intro to ICNRG, Status of the baseline documents - Chairs ICN research challenges - Dirk K ICN baseline scenarios - Bšrje (slides by Kostas) * would like feedback from implementers on the relevance of the document for evaluation and comparison of different approaches * section 2 is near completion * section 3 will need more work in the coming months * two draft update releases planned till Vancouver * looking for volunteers to implement in a simulator some/all of the proposed topologies/traffic load/etc and contribute them to the community * in Berlin we agreed to split the scenario description (sec 2) and the evaluation methodology, including metrics (sec 3) into two separate drafts ICN survey document - ??? 10:00 SAR: Coupling Service Location with (Inter-domain) Routing, Decoupling Them From Forwarding - Hongbin LUO Beijing Jiaotong University (slightly different title of the talk) Using four namespaces - Service Identifiers (SIDs) - flat self-certifying - Node identifiers (NIDs) - flat self-certifying - Intra-domain routing locators - can be different in different domains - Path identifiers (PIDs) - negotiated bi-laterally between two domains Dave: discussing the relation to TRIAD - seems to be similar ideas Nacho: do the domains sharing path identifiers need to be next to each other? Nacho (slide 14): Are P5 etc the path identifiers? Hongbin: yes Nacho, Dave and Ashok asks about the routing (slide 17) Hongbin: tier-1 providers need to know all service names Dirk: requests and responses seem to be forwarded up and down in the hierarchy? Nacho: does this happen for every request? Hongbing: yes, but terminates at cached copies Nacho: when a node caches something it has to be registered with the local RM? Hongbing: that's right! Nacho: is there only one RM per domain? Hongbin: logically, yes Slide 24: questions about what traffic a certain node can estimate Dirk: you seem to have the concept of naming all the nodes? Hongbing: that is correct Second morning session - notes taker: Byoung-Joon (BJ) Lee Samsung Electronics, Advanced Institute of Technology (Action Item) : it is necessary to track "implementations" on wiki (Dave Oran?) 11:00~12:00: Software-Defined ICN (Wen Qi from City University of Hong Kong) - proposing generic ICN function module with unified pkt format for forwarding, to provide interoperability between different ICN networks via SDN - future work will include migration to OVS prototyping - followed by a lab demo in the afternoon, where the NDN and PURSUIT protocols were proprietary versions Additional notes by Dave Oran: - Two Usage models: (a) is interconnecting ICN islands using different ICN architectures, (b) migrating content or clients from one ICN protocol to another. - Approach: common/universal API, make no change at ICN clients. Then use SDN to decouple control and data plane. Q: (Dirk) can see SDN as implementation method, but for unification, is it enough to invent protocol headers - don;t you have to have compatible protocol semantics - NDN and Pursuit are totally different A: (didnÕt understand the question - response was about how to do the routing mappings) - There is a protocol analyzer (i.e. gateway) in the Label mapping module of the design. Q: where is the unified packet changed into a unified packet A: in the edge switch using a matching policy Q: controller does it manage the edgoe or the core also A: it does both - in the middle ther is no translation - they move the NDN routing into the content index and topology management modules Q: (DaveO) how do you handle large pursuit objets that break up into multiple NDN objects A: Cache whole Puesuit object in edge where NDN translation is done. Future work to be able to cut through. Q: (Dirk) what about the SDN controller - need extensions to OpenFlow? A: Yes. - How do we take this work forward - Dirk: possibilities are numerous - this approach envisions extending OpenFlow in various ways. 14:00~: Discussion on the ICN survey draft (Cedric Wesphal) - also describes "service model of ICN" (Dirk K) - history/plan : version -00 July 2013 version -01 January 2014 - Question: how to fit "trust management" using ICN in the survey document : ICN helps solve this problem or not? : or, to discuss trust management issues in ICN? - Question: scope of ICN? for the whole Future Internet? or just for "secure content" delivery? - Need clarification on "persistent storage" (Action Item) : it is necessary to track "implementations" on wiki (Dave Oran) 15:00 (?) ~ lost track of time here: Split into 4 small groups for separate discussion - traffic loads/scenarios, packet format, routing, etc 16:00~ : NDN workload (Ashok from Cisco) „ Started from IRC traces „ Reformatting URLs to names making them hierarchical „ Components of names - test data set with realistic component count and name length - from IRCache trace (13.5 million traces in 2007, over 8 site, etc) : every URI beyond 28 components is junk ...and many interesting results - presentation slide and Cisco data sets will be available on wiki (?) - How to deal with flat names like YouTube videos? - What about multihoming? - What about mobility and mobile content? - 17:00 ish~: a lab demo from City University of Hong Kong's work on Software-Defined ICN ...end of the first ICNRG meeting in Asia Thanks Byoung-Joon (BJ) Lee Samsung Electronics, Advanced Institute of Technology