Minutes interim-2016-icnrg-08: Thu 09:00
minutes-interim-2016-icnrg-08-201609290900-00

Meeting Minutes Information-Centric Networking (icnrg) RG
Title Minutes interim-2016-icnrg-08: Thu 09:00
State Active
Other versions plain text
Last updated 2016-10-04

Meeting Minutes
minutes-interim-2016-icnrg-08-201609290900

   9:00-10:30 Session 1

Note taker: Dirk

Intro by KenKen

The Futility of Data Privacy in CCN - Gene Tsudik (45 min)
   * Q, Asami-san: meta info privacy in CCN?
     * A: yes, need to say what you encrypt and what not
   * Q, Asami-san: DPI in SDN/NFV in IP world, but in CCN it may be different
     * A: at network layer, IP just gives you addresses that map to location.
     In CCN, you could potentially see the full application name -- you get
     more "for free"
   * Q, Asami-san: two types of people: those who care about privacy and those
   who don't
     * DaveO: people may not care about privacy from google, but maybe from NSA
     or ISP * Asami: privacy-by-default? * N.N.: In CCN, we increase the scope
     to everything in the network. In Gmail, it's just about one application.
   * Q, George: what if we include some randomness and multiple copies of
   packets (confusing adversaries)
     * A: that would be a hand-waiving approach...
   * Q:, Marc Mosko: would IP & TLS be weak privacy according to your
   definition?
     * A: no -- you generate new keys for each session -- cannot correlate
     between two users
   * Q: Marc Mosko: but you can correlate requests to responses
     * A, DaveO: not if server changes order of responses
   * Q: Asami-san: according to CCN spec, users can specify whether data should
   be cached or not
     * DaveO: adversary can always intercept and cache, so cache control would
     not provide privacy * Asami-san: turning on encryption would also reveal
     information about privacy concerns
   * Q: Börje: in media distribution, not everything needs to be encrypted for
   privacy
     * A: yes, not every application needs privacy
   * Gene: may have to do equivalent to IP+TLS
     * DaveO: CCN-KE draft specifies this is
   * Marc Mosko: can still do symmetric encryption for some content. Some
   content providers do not want operators to see who is seeing what (so
   individual encryption)
     * Gene: so problem is worse?
     * Marc: yes
     * Dave: would not characterize as better/worse. Question is: where to
     provide caches that are trusted by one or multiple players. Need to be
     more nuanced and put caches into a trust framework
   * Jay: need to qualify what we mean by privacy
   * Marc: today everything is bundled in TLS
   * Gene: TLS only mitigates some privacy issues -- CCN does not -- goal is to
   make people aware * Jay: proportion of traffic that needs privacy makes up
   no more than 10%. For caching, need to understand what we need to cache *
   Gene: state actors etc. can mount strong adversary attacks * Börje: then we
   need stronger regulation. can also have attacks on devices (to get viewer
   statistics the TV industry is including hardware in TVs that do image
   recognition of what is on the screen, so it does not help if you get your
   content via an encrypted link or just play from your old VCR, they will
   still know what you are watching.) * Gene: all security will be broken
   eventually (no longevity) * Marc: problem of self-identification if
   encryption is not ubiquitous

Survey on ICN Security, Privacy, and Access Control - Satyajayant “Jay” Misra´
(45 min)

   * Q: DaveO: re content poisoning: are you mixing that with cache pollution?
   What does it have to do with interest hashes?
     * work by Gasti et al -- to be discussed offline
   * Q, DaveO: Google Bombing attack. Large groups of users collude to
   manipulate popularity, rankings etc. * DaveO, different ways for delaying
   responses from caches, e.g., adding delay when delivering cached objects *
   DaveO: for adaptive media-streaming, delaying could also be useful * DaveO:
   "don't cache" is like the "evil bit" * Jay: With ICN multi-path and network
   coding parts of the content can be requested over different interfaces,
   especially useful against censorship

10:30-11:00 Coffee Break

11:00-12:30 Session 2
Note taker: Bastiaan

Traceroute & Ping - Jim Gibson (30 min)
   * MarcM: Forwarders need an identity, not specifically a name.
   * N.N: What would be the difference between an Identifier and a Name?
   * Jay: adding signing to ping will more accurately estimate rtt
     * DaveO: applicable to dynamic generated data packets? How do you tell the
     difference?
   * MarcM: Do you allow client to ask for specific payload size?
     * Jim: Currently not in draft, only minimal size based on TLV
   * DaveO: because of the cost of signing, more concerned with signing when
   consumer is trying to get info on your forwarder * Asami-San: According to
   discussion, network management of ICN seems more complicated. So is ping for
   ICN quite complicated?
     * MarcM: Example, Verizon names all routers they want pingable. Summarize
     in exchange to external world. You don't always have path symmetry. ->
     One namespace for router, different namespace for application connected to
     router * DaveO: pinging router versus pinging application connected to
     router, might give different paths. * MarcM: are you pinging a piece of
     infrastructure? * DaveO: no, you are pinging a FIB entry. * N.N: as soon
     as you hit a FIB entry,  would then that forwarder name be the box? *
     DaveO: that's why we return the corresponding forwarder name then * MarcM:
     does that name need to be globally routable? * DaveO: you can never force
     that * Jim: assumption, if we are doing the case of pinging a router name,
     it would be close to the application.

Flow classification - Dave Oran (30 min)
   * Asami-San: Could you define security envelope?
     * DaveO: The thing that is hashed and signed by producer, is within data
     packet. Immutable for lifetime of packet.
   * Jay: Could you give a example of regrouping?
     * DaveO: Not part of the name. One day, classify
   * ??: Any scheme for different producers that define same classes (EC3
   scheme)?
     * Jay: For example, one producer chooses 5 equivalence classes, another
     producer 1000? How does forwarder decide? * DaveO: Depends on how much the
     forwarder decides to remember, e.g. due to memory, cpu limitations.
   * N.N: when you include class in security envelope and is cached. Do you
   also cache security envelope?
     * DaveO: yes
     * N.N: three different classes, will they be considered as different
     objects? * DaveO: yes
   * Jay: (ECNCT scheme) several subflows with own class, subscribe to super
   flow. What would you recommend, longest, shortest prefix matching?
     * DaveO: Not sure
     * MarcM: Should flow class be part of name?
     * DaveO: That's one of the questions
     * DaveO: Consumers can ask for certain treatment, but this just says what
     should we do with the different classes.
   * DaveO: two questions on last slide, any feedback?
     * Jay: I like the second solution (ECNCT scheme), but some aspects seem
     "scary". We should think/experiment * Dirk: are you in position to present
     some experiments? * DaveO: unfortunately not
   * George: Isn't it clear that second mechanism is more globally explicit?
   Interesting that it doesn't mean any thing about the treatment of classes.
   Isn't it useful to have explanation about ordering of treatment of classes?
     * Borje: we need to think in parallel what these treatments mean, e.g. do
     we cache something longer or less. * Dirk: people have been doing
     experiments on this topic (in general). See in experiments * MarcM: doing
     it in the name has some interesting things to it, but also some drawbacks.
     * DaveO: observation, this seems like the service equivalent of whether or
     not to have hierarchical names versus flat or attribute-based names * Jay:
     we are trying to design and ICN architecture for smart grids, where flow
     classification is also very important.

12:30-14:00 Lunch

14:00-15:00 Session 3
Note taker: Adeel

Discussion on the three congestion control papers at ICN2016 (30 min)
   * Börje puts forward some questions in a slide
   * Jim: Identify a bunch of mechanisms that could help and use them together.
   * Bengt: If you don't have a window, it is hard to do a fast retransmit.
   * Bengt: NACKs can be sent for losses if the losses can be detected.
   * Jim: Don't have any intuitions of the coexistence of the ICN congestion
   control approaches and TCP because MIRC/PCON are multipath. * Dave: We
   didn't look at how it would be if TCP runs over ICN than if it runs over IP.
   * Dave: We were not running any sophisticated congestion control on ICN in
   our TCP over ICN work * Marc: Combining multiple control loops that don't
   know about each other is asking for trouble. TCP operates on byte level when
   it comes to congestion control. * Jim: The SAID paper was an interesting
   idea but I don't see how that quite fits in. * Marc: I did not understand
   about the SAID approach how the publisher knows which byte was asked for. *
   Bengt: I am interested in the stability properties of the congestion
   control. Two things, per-hop and multipath. I am not up to date how MIRCC
   has designed the per hop regulator. * Dave: For the unreliable proxy every
   arriving TCP packet is treated separately. * Dave: Congestion control for
   ICN is potentially a career for people and not merely a project :-) * Dave:
   Van Jacobson has recently published some new work on congestion control. *
   Bengt: In MIRCC did you figure out a way for the routers to split Interests
   over outgoing interfaces for a certain prefix? * Jim: We did not figure out
   a good way. So we chose to go with a client scheme. * Börje: Contributions
   and discussion on the mailing list are most welcome.

Status update on the CCN/NDN harmonization efforts - Alex/Lixia (30 min)
   * Dirk presents ICN Harmonization Activity Update slides that Paul Polakos
   put together. Paul was one of the drivers of this activity. * Alex presents
   his and Lixia's slides on Identifying NDN/CCNx1.x Commonalties and
   Differences, a high-level summary of the discussions so far. Described  the
   common starting point of CCN and NDN, different goals drove the branching
   out of the two. * Lixia asks Marc if PARC's protocol changes mentioned in
   the slide look fine. We want to get it right, hoping to produce a summary
   draft by Seoul IETF. * Marc: Loosely synchronized clocks are needed among
   all caches and not all routers. * Marc: Before CCNx 1.0 the definition is
   about whether  a cache entry is stale or fresh.  CCNx 1.0 changed to whether
   cache entries are alive or dead. * Lixia: Any other major changes since CCNx
   0.8 missing in the "Parc Protocol Changes" slide? * Dave and Marc: Typed
   name components * Dave: There are a number of other things that have changed
   which are not in the slide e.g. key and hash restrictions, etc. but they are
   secondary level, not architecture * Marc: the selector (including
   exclusions) draft is technically not part of the ICNRG drafts but an
   individual contribution. * Alex: One thing not mentioned is scope which was
   in CCNx 0.8. * Marc: Yes * Dave: Nonces have been removed from CCNx 1.0. *
   Lixia presents the changes in NDN after the branch out: Our fundamental goal
   is to experiment with the architecture. That is why we have tried a number
   of diverse apps, fill in missing holes, identified new issues.  In
   particular we noticed security was a weak point in early app development, so
   we put in effort and fixed it (schematized trust).  Our focus differs. PARC
   focused more on performance.  We could not change the code even before the
   split. We made the NDN software package modular. * Dave: cisco code pushed
   for understanding "big O" aspects of performance, but believe PARC's
   forwarder is also quite modular and flexible. * Lixia: PARC's focus has been
   mostly the forwarding plane and not trying out a number of different
   applications to really test out the architecture design.  Still so far the
   discussion shows that the NDN team and the CCN team had pretty different
   focus. * Dave: A lot of the work that has been done on performance was not
   to do optimization but to check the inherent performance characteristics of
   the different elements of the architecture. These characteristics are
   equally important for testing the architecture. * Lixia: as we discussed
   during ICN16, ICN can effectively solve IoT, V2V, ad hoc, DTN problems --
   these are low hanging fruits of ICN at the edges. ICN can make a fundamental
   impact at the edges where TCP/IP does not offer good solutions. * Lixia: We
   are pretty far from the point where we need optimized performance inside
   infrastructure. If we really want to make a big stride to move ICN forward
   we should really look at the low hanging fruits. * Marc: We need to be
   careful about protocol scaling problems. * Lixia: I agree, here are a group
   of protocol veterans with scars in protocol designs. we learned. * Dave: Jon
   Turner who worked with ATM figured out how to forward IP packets fast using
   hardware designed for ATM * Börje: I agree with both Lixia and Dave. We have
   to look at both sides, keeping the architecture open and performance
   characteristics. It is a difficult balance. * Dirk: Industry is waiting. *
   Lixia: down the road the Infrastructure will change.

Proactive Content Caching Utilizing Transportation Systems and its Evaluation
by Field Experiment - Yo Kakuhei (30 min)
   * Dirk: Can you say anything about the LTE utilization and load?
   * Yo: Yes it is in the slides.
   * Börje: How do you get data into the cache before any user requests it?
   What protocol do you use to put data in the cache? * Yo's colleague: We used
   MPEG-DASH and some scripts. And we use CCN. * Dirk: How CCN has actually
   helped you in this? Pre-fetching is their in current technologies too. It
   was not apparent what CCN brings to this. * Yo's colleague: With IP you need
   to build an application and a proxy, with our solution we use inherent
   caching of ICN.

15:00-15:30 Coffee Break

15:30-17:00 Session 4
Note taker: Jim

Information Centric Networking for Disaster Information Sharing Service - Wen
Zheng (20 min)
   * DaveO: Did you use ICN to do reverse geo-coordinate mapping?
   * Wen: No, it's a standard db with interface not ICN
   * DaveO: Seems it might have some interesting issues
   * Dirk: Any interest in participating in ICNRG disaster group, have you see
   the doc? * Wen: Yes, I've read that document * MarkM: With respect to using
   LatLong: LatLong is a point, not an area. There are other coordinate systems
   that represent areas and that could be encoded in the name, e.g. to scope to
   different granularity areas. * Wen: Yes, started with a system based on a
   single point, have some ideas about how to progress that.

CCN aggregation scheme - Marc Mosko (20 min)
   * Borje/Dirk: What's the definition of "similar Interests"?
     * MarkM: depends on which protocol version. Currently is name,hash
     restriction,key restriction
   * DaveO: What about HopLimit: If the newer Interest's HopLimit is higher,
   naively you should forward it. * DaveO: What does "pass a ContentObject in
   flight" refer to?
     * MarkM: There's a weird race where Interest2 is sent up while ContentMsg
     is going down, and in that case the ContentMsg can get sent on a link
     twice. * DaveO: Maybe I'm quibbling with the words, but your description
     doesn't seem quite right. I'd say "You'll never get more Content than sent
     Interests. In the worst case, due to passing in transmission, can get as
     many Content objects back as Interests sent. * MarkM: Also, duplicate
     ContentObject will get killed off after traversing one link, since no PIT
     entry. * DaveO/MarkM: discussion of difference between cycles and spirals.
     MarkM asserts that can't have same cycle, but can have successively
     smaller cycles because TTL has been decremented.
   * JimG: what's a route with a 0 hop count.
     * MarkM: cost is 0.
   * DaveO: Cool feature but sounds like premature optimization. Adds
   requirements to routing protocol, special cases to traceroute, etc.
     * MarkM: concept is to be able to reduce Msg.HopCount by more than 1 at a
     hop to terminate cycles faster, especially given that we do not choke off
     looping Interests that arrive on same Interface -- we categorize them as
     retransmissions that should be forwarded. * DaveO: example routing
     protocol issue -- with a dv protocol, can't "find largest distance of all
     downstream routes" to make sure that the routing entry hop limit field is
     correct. * Lixia: Can this issue be solved by putting the Nonce back in? *
     MarkM: Nonce needs to be stored even if PIT entry got wiped out. * Lixia:
     Sure, but this will work most of the time. I had planned to finish a
     writeup talking the importance of nonce. As we want to forward Interests
     more liberally utilizing wireless channels, more chance of small loops,
     need nonce to break loops.  TTL is ineffective in killing small loops as
     it counts into infinity. * MarkM: agreed that nonces are useful with
     "Information foraging environment" (lower-performance exploratory
     forwarding systems), but CCNx1.0 has HopLimit as the mandatory approach,
     Nonce is optional. * DaveO: MarkM and I have a deterministic loop
     suppression algorithm if we can store 2 64-bit values (128 bits total). *
     Lixia: not great for IoT * MarkM: sounds like the feedback is that
     HopLimit decrement is too complicated. * DaveO: off-the-cuff, seems it
     won't work * MarkM: Then need another mechanism if worried about the
     count-to-infinity problem.

Highlights from Research (e.g., topics from conference or other activities) (30
min)
   * Borje: Any topics that ICNRG should add?
     * Dirk: Retransmissions :)
   * Borje: ICN-over-broadcast-media?
     * MarkM: Needs to consider Nack (or Success) storms. Either need to be
     prepared for many responses or a GOSSIP-type approach. * Lixia: work has
     already been done on these problems in other domains * MarkM: yes, but
     need to do that in ICN or else do OSPF-style approach, can't casually talk
     about broadcast and not think about this. * DaveO: IS-IS mechanism is much
     better than OSPF, which requires configuring for leader and backup *
     DaveO: Doesn't work well in 802.11, since multicast is unusable.
   * DaveO: Differentiation of services

RG maintenance/admin (20 min)
   * Planning for future Interop / Hackathon
   * Terminology
   * IoT document
   * Planning for Seoul
     * Interim meeting on Sunday?
       * Joint meeting with T2TRG in Seoul?
       * Borje: Makes sense to me to talk to other RG, to avoid pointlessly
       diverging * Lixia: How about "slow start" :) 1/2 day joint work with
       T2TRG, 1/2 day work on own. * Borje: Should we meet on our own first or
       meeting with T2TRG first? * MarkM: Should we shoot for a
       draft-of-a-draft on harmonization? * Dirk: Doesn't need to be complete *
       MarkM: We could write up what we have now, which is a lot. * Borje:
       Sounds like there is interest from NDN/Lixia and CCNx/MarkM? [Yes --
       make final decision on mailing list] * Lixia: need to confirm Sunday
       meeting, so we can make travel reservations * Borje: Okay, _yes_ to
       Sunday meeting, agreed here on the spot.

[End]