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 |
minutes-interim-2016-icnrg-08-201609290900-00
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]