Minutes for ICNRG at IETF-94
minutes-94-icnrg-2

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