ICNRG meeting @ IETF 94, Yokohama, Japan, November 1-6, 2015 ¶ * Date: Thursday, November 5 (confirmed) * Time: 9:00-11:30 * Location: Room 302 * Etherpad for notes: TBD Agenda ¶ * Welcome, Agenda Bashing, Minutes taker, Bluesheets, Status - Chairs -- 10 min * Reports from interim meetings in S.F. and Yokohama -- 15 min * Forwarding-Label support in CCN Protocol (draft-ravi-ccn-forwarding-label-01) - Ravi Ravindran -- 15 min * Proposed Design Choices for IoT over Information Centric Networking (draft-lindgren-icnrg-designchoices-00) - Olov Schelén -- 15 min * Discussion on merging ICN-IoT documents - Ravi Ravindran -- 15 min * 1-to-n Matching of Interest and Content Objects for Reduction of Router Workload - Jun Kurihara -- 15 min * B-NRS updates - Jungha Hong -- 10 min * Name based web browser - Jungha Hong -- 15 min * Key exchange - Chris Wood -- 10 min * TLV compression - Marc Mosko -- 10 min * Manifests - Chris Wood -- 10 min * Wrap up, Next meetings -- 10 min Note: Please see our Wiki for the most up to date version of the agenda: http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg Forwarding-Label support for the CCN Protocol- Ravi Ravindran - slides at https://www.ietf.org/proceedings/94/slides/slides-94-icnrg-2.pdf Kireeti - Has a problem with not taking questions during the talk. Metaphysical point: point is that name=locator and you route based on names. Seems anti- the philosophy. Ravi: didn't say locator not a name - it is a name Lixia: as research group questions should be taken during the talk Dirk: we generally allow questions during the talk Ravi: I already shared the draft 4 weeks ago MarkM: Has comments already on the list - many aspects are not implementatble. At each step a bunch of options and doesn't see how to tell if it's correct. Needs correctness and liveness proofs. Ravi: wanted to cover all the cases inclusing ones where application does the mapping DeanB: how do names simplify the routing in the networks today? Do you have public to private translation. MarkM: "the validation depends on the trust context" - how does the network know the applicaiton is managed by the same authority? Ravi: might be aplications inside the provider where the two are the same. KevinF: reacting to saying that there are "non-routable names" There is technology that can route on flat names - don't need hierarchy. Ravi: yes, but most people use a name resolution service for that Lixia: whether a name shows up in the routing protocol is not the same as whether it is "special" type like a locator. No need to have special locators. Ravi: draft has point of view that the difference is that "locator" names are managed by the infrastructure provider. Lixia: how can you know a prefix like cnn.com won't show up in a routing protocol? Also the namespace cnn.com is not managed by network provider. Ravi: provider has control...big concern on routing plane stability and scalability. Proposed Design Choices for IoT over Information Centric Networking (draft-lindgren-icnrg-designchoices-00) - Olov Schelén Slides at https://www.ietf.org/proceedings/94/slides/slides-94-icnrg-5.pdf DeanB: without advanced lookups how to know what to ask for - some semantic differences between versions and sequences. Olov: eitehr can be used HannesT: what is the ocmmunciation paradigm? Is this publishing to the cloud, or mesh/peer-to-peer Olov: haven't fully thought out - but want any IoT device to be a publisher HannesT: what about commands Olov: on later slide MarkM: what is it about publishing with a sequence number that makes data immutable. Does it mean that the publisher NEVER reuses and name. Olov: yes, challenge that needs to be addressed. KireetiK: how old the data you keep - oldest you keep depends on the avaialbility of storage Olov: what you cache is under control of the publisher. Publisher may keep things forever KireetiK: what about limited devices Olov: can have multiple publisher instances. KireeetiK: how can I ask for "the latest data"? If you can't do this, can't solve certain important problems. Olov: as consumer you have to figure out what to ask for. Including ask for next version that does not yet exist. Exploring tradeoffs. MarkM: comment that it works for real-time data. Anything after the first you need another round trip In CCN/NDN interests are unacknowledge subscriptions, so if you need long-term subscriptions you either need something heavy on network or an end-to-end protocol Olov: yes, agrees. KevinF: haven't we plowed this area before with HTTP/SPDY? Olov: yes, of course. We look at these JörgO: not every service needs the extra round trips. Since this isn't tied to a specific architecture, could look into Push style. ManuelV: work very intersting - wants you start to have time could be a can of worms - need time sync etc. Olov: haven't elaborated on this yet, but address how to map time to the namespace of objects RaviR: use of authenticators? Olov: no particular assumptions Lixia: have done some prototyping on this kind of application, to map objects with time, put timestamp in the name. Two other challenges we saw from our prototyping: 1) data builds up very quickly, how to handle that; 2) security aspects, including what keys are used for what data. Olov: yes - have 50 temperatire sensors, each with a different clock. Need consensus on what you advertise. HannesT: would be interested in seeing performance comparisons between this and alternative approaches - how big are the packets, energy consumption, code size - do we have any results. DirkK: RIOT guys had some data at ICN 2014 Discussion on merging ICN-IoT documents - Ravi Ravindran Slides at https://www.ietf.org/proceedings/94/slides/slides-94-icnrg-2.pdf DirkK: Thanks for doing all the work. Regarding adoption, we normally first have discussion on mailing list before asking for adoption. 1-to-n Matching of Interest and Content Objects for Reduction of Router Workload - Jun Kurihara Slides at: https://www.ietf.org/proceedings/94/slides/slides-94-icnrg-6.pdf AlexA: comment - the work not properly motivated - FIB optimization is not really a problem, the real problem is in the PIT. Can be engineered. NachoS: the congestion control may allow better multi-path splitting LixiaZ: agree with Alex - really an engineering issue - better not to complicate the architecture. B-NRS updates - Jungha Hong Slides at: https://www.ietf.org/proceedings/94/slides/slides-94-icnrg-7.pdf Jungha: what about the B-NRS as a RG work item DirkK: is threre broader interest in the group for an NRS work item. If no immediate reactions now, can ask on the mailing list Name-based Web Browser for ICN - Jungha Hong Slides at: https://www.ietf.org/proceedings/94/slides/slides-94-icnrg-7.pdf (combined with Bloom filter slides) Yusuke Doi:: quite new for this field - how do you combine the ICN with the traditional Internet on one infrastructure. Jungha: did not combine them Yusuke Doi: that means the briwser does or does ot have both ICN and HTTP data on the screen? DirkK: for future work need to describe the atual software architecture of the browser - that was unclear Manifests - Chris Wood Slides at: https://www.ietf.org/proceedings/94/slides/slides-94-icnrg-4.pdf NachoS: has propsed answers to the oopen questions - (did not catch them all) RaviR: from consumer's point of view does the conumer know what to expect? On dynamic manafiest, how do we deal with some of these issues MarkM: reason for separate packet type needs to be explained - don't want to carry both in one message for a variety of reasons AlexA: Are these requirements architectural or engineering DaveO: thinks it is architectural since it is defining fundamental data structures that have to understood by everybody DaveO: some advantages to allowing parent pointers NachoS: some problems if poitners are all hash-based MarkM: could have multiple pointer types to deal with this Dave O: This is architecture because it is fundamental data structures that everyone needs to understand. I want to make the case for parent pointer on the questions that Nacho said No to. Key exchange - Chris Wood Slides at: https://www.ietf.org/proceedings/94/slides/slides-94-icnrg-3.pdf DeanB: on config data - how do you know the accuracy ChrisW: It's signed like any other content object, including validity time RaviR: is this to support private communication between producer/consumer ChrisW: establish secure session with your bank, etc. MarkM: should be be vinvolving CFRG or other securuty people DirkK: yes - started looking to engage them, also present work in other format Skipping talk on TLV compression Wrapup: Chairs Meeting at IETF95 in Buenos Aires Proposal for Interim in Paris in mid-January