Minutes for ICNRG at IETF-91
minutes-91-icnrg-1

Meeting Minutes Information-Centric Networking (icnrg) RG
Title Minutes for ICNRG at IETF-91
State Active
Other versions plain text
Last updated 2014-11-21

Meeting Minutes
minutes-91-icnrg

   ICNRG Meeting @ IETF-91
=======================

Monday, November 10, 2014
15:20 -- 18:30

ICNRG web page: http://irtf.org/icnrg
ICNRG Wiki: http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg

Dirk Kutscher, Chairing

[admnistrivia]
[review of agenda]

Documents Update - Dirk
ICN Baseline Scenarios - passed ISRG review, now IESG review
ICN Research Challenges - mostly complete, will consider outcome of
current QoE discussion, call for final RG review soon.
Evaluation Methodology - Editorial work required, mostly on sect 2.1 on
simulators/testbeds; aim for RG review early '15.

First ACM ICN Conference was in Paris in September - nice event.
Next one next year in SF.  Followed by full day meeting at
LIP6/SystemX in Paris. Discussed video distribution, ICN and IoT,
CCN/NDN packet format discussions, Scalable mobile backhaul via ICN,
Distributed latency-aware caching, named function networking
(championed by Christian Tschudin) - likely we will come back to that
in the future.

See wiki for all materials and minutes.

================================================================
Video Update - Cedric Westphal

- https://tools.ietf.org/html/draft-irtf-icnrg-videostreaming
- http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-7.pdf

Focus: most traffic in today's net is video; no reason to assume that
will be differnet, so it needs to be supported efficiently.  Can
current Internet mechanisms be adapted to an ICN?  [Other question,
not considered here: should new mechanisms be designed for ICN?]
No recent major changes, some reorg and two new sections.
Draft focus on current use-cases, to capture requirements.
Expanded list of research items: potentially the structure of an
"ICN-specific video mechanisms" document.
Real-time issues, requirements of flash crowd, local video
distribution (no infrastruct), heterogeneous environments, network
coding? Packet formats for Video?

[Nacho Solis]: hard to understand some of the documents in the group (not just
this one) - we at PARC are driven by what we are doing, but some
general documents ... it's not quite clear what the conserations are.
I'm happy to work on this document.

[Dirk]: what would be the contribution of these documents?

[Nacho]: would be good to have docs to point newcomers to, so that they
can learn about areas or contexts (e.g., video, IoT) that they are
not familiar with, so they can design the protocols correctly.  Don't
see that in the current documents, including this and IoT
[implication: docs are too high level]. 

[Cedric]: Fair point - document (and WG, to some extent) tries to be
agnostic about what ICN is going to be. At some point you have to be
specific, not sure when that will be.  We can start that discussion,
but it's not what's in this document right now.

Caching discussed mostly to reduce BW usage in the network by avoiding
repeating dup requests.  But can be used to increase capacity for a
single network xmission.  May allow you to find "niches" or reservoirs
of capacity.  E2E adaptation (a la DASH) uses minimum of server-cache
and cache-client rates.

What to do with this doc?  Next document? Native ICN video streaming,
what would that look like?  Agree with Nacho that if you are going to
design for a specific architecture you should at least say what that
looks like.

Q [name unknown]: Are you trying to solve everything listed in this
doc?  You list many tough tasks - are they potential work items?
A: this could be an outline for potential new drafts.  Or look at what
issues might come up, e.g., what happens if you wnat to run DASH over
ICN?
Q: Hard to figure goal of THIS document itself.
A: Outline scenarios/use cases, which have different requirements.

[Dirk]: What to do with the document? We should be confident that this
will be something that people would be interested to read... We got
some feedback.  Proposal: keep this draft mostly as-is, but clarify
assumptions about what "ICN"  means, without going into packet format
details.

[Nacho]: for these documents the incentives are mis-aligned = to finish
this and go onto something else.  It's informational anyway.
You are asking "Are we done with this discussion doc?" I say stop
before adding a lot of protocol-specific stuff.

Question [Cedric]: who has read 01-version? (about half a dozen hands)
So: go ahead with 02 version, get more input from group.

================================================================
IoT Update - GQ Wang

- http://tools.ietf.org/html/draft-zhang-iot-icn-challenges
- http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-1.pdf

Quick review of doc after comments from Paris meeting.  Updated
portions only.
Draft was split to encourage participation: Architecture and
Use cases, then ICN CHallenges.  Only latter was changed.

Naming and Name resolution: smart homes, smart grids, ...

Caching and Storage: where to cache - unconstrained vs. constrained
envs.  What to cache - pub/sub info in routers?  Caching in context of
actuation - little meaning for authenticated requests, e.g. Building
Mgt Systems.

Scenaro-specific challenges for caching - similar.

Routing & Forwarding: requirements (direct & indirect)
Direct Name-based Routing - flat names, producer mobility introduce
challenges.
Indirect routing: name resolution system; static vs dynamic binding,
later requires router to handle (?)  Scenarios: some for each.

Req Most Specific to IoT: contextual communication - constraints
related to timing, power, trust, ...
Info-gathering for self-config - Contexts processed in network layer
Again, challenges across all contexts.

In-net computing: security requirements, filtering noisy data, context
reasoning, services for networks...

Security & Privacy - "crucial to all IoT applications".  Most concern
about privacy.  Also BW limitations - when you get only 100 bits, how
are you going to do, e.g., authentication?

Contributions are welcome.

Q: [Al ? ] are you looking at what's been established last few years?
E.g., refrigerators - they don't have TCP/IP. How will you convert
them?  How will you accommodate the security?
A. Some of these folks have said their intent is to replace
TCP/IP. Our view: TCP/IP is overkill for tiny things.  Just need a
very simple packet format, just room for the name.  You use TCP/IP,
you need a babysitter - not workable for IoT.
Q: But how you going to get it across the globe?
A: Agree with you.  Talking about in a certain domain.
Q: Then you gotta build a gateway, and that's costly. Who's gonna pay
that cost?
A: People build gateways today.  Look at Nest.
We do have an implementation, if you do another protocol stack, then
we pay the penalty of gateway.

[Nacho]: we work on many different networks.  Not connecting fridges
across the country.  We can run as overlay or native.  Power co uses
in an island.  Goal is to build a complete stack...

[Dirk]: whole thesis of IoT work is that there is value in having an
abstraction poerful enough to connect IoT with big-I internet, without
having to have application-specific gateways all over the place.

Q: [Dirk]: When you explain challenges (e.g., routing), do you think
this document should make recommendations?
A: Not in the architecture.  We don't impose any solution in this
document.
================================================================
BF-based Flat Name Resolution Update - Jungha Hong

- https://tools.ietf.org/html/draft-hong-icnrg-bloomfilterbased-name-resolution
- http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-6.pdf


This is version 02. Presented twice before, but will go over basics
for those who haven't seen it..
"Location indepedent flat name assumed in ICN"

NRS maintains and resolves bindings.

Proposed B-NRS imposes hierarchical structure - network of B-NRS
servers, a forest of disjoint trees. No constraint on peering.
Use BFs to aggregate name.  Announce BF instead of full name.
2 components: BF and lookup table.  Lookup table stores loc(s) of
already-resolved names.  BFs store names for children and peers.

No constraints on name registration - BF updates via insert-through.
BF cannot handle deletion.

Locator information is inserted/deleted into name lookup table.
"Inherently supports mobility" because info of locator can be
changed.

Forward to all children/peers with positive output from BF.  If fail -
send up to parent.

BF can't handle deletion, this is a problem.  How to handle?
- ignore
- update all BFs on every deregistration
- counting BFs.  Expands BFs; size is already a challenge
- have two copies, refresh periodically.

Results on BF size vs. FPP  Assume 1M names in BF => 2MB BF size
k: (optimal # hash functions) = 11.09.

Example: assume server at top with 1M children, 1M names each (1T
names). Lookup in child BFs via hardware assist (GPU).

Q [Nacho]: you aggregate BFs from children and then send that to
peers. So are you XORing the million BFs?
A: This is only at the top.  This shows how to do it for 1T entries.
Q: so every query goes through the top node?
A: Just showing an extreme case.

Q: You assume flat names, not all architectures assume that.  Also,
flat names => flat traffic, so most queries will go throught the root?

Q: [unknown] What about false negatives?
A: No such thing in Bloom Filters.

Q: [Dirk]: what about maturity of this work?  Implementations?
A: work in progress, we are working on hardware implementation.

Q: [Nacho]: At the beginning, you queried the first server. Does it have
the BF of it's parent?  So if it misses, it queries the parent?
A: Yes.

================================================================
CCN/NDN Protocol Wire Format & Functionality Considerations - GQ Wang
(also Christian Tschudin)

- http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-0.pdf

Current TLV discussions focus on performance.  But other
considerations: flexibility, scalability, expressiveness - these also
need support @ wire format level.

"One TLV to rule them all" is bad.  Need support for multiplicity of
schemata.
 - one(few) for header, but more flavors for payload.
Examples: backward compatibility, NFN, service composition

Elastic TLV: Variable "length" - 2B for type, 2bits + 14 bits for
length, with 2bits defining units: 00 = B, 01 = KB, 10 = MB, 11 =
GB. Selection of per-unit resolution can be chosen by the
application, based on feedback from ICN fwding layer, based on
strategic path level feedback.

Q [Nacho]: now you have to have padding options, because units are too
big.  What is the big win in transmitting big things as one unit at
L2?  Don't agree with this, we can argue whether 64K is right thing...

Q [Kevin Fall]: DTN bundle protocol, FYI, many fields are
variable/extensible.  Use a bit in each byte so they can be as long
as you want (at expense of more processing).  Might be convenient if
they were the same format.

A: fragmentation is per-interface.  Optical is most reliable link
today.

Q [Nacho]: when you are transmitting your 2TB bundle, do you keep it in
memory or do cut-through?  If the latter, you can do that with little
ones.
A: but then there's lots more overhead.

Example: Vint Cerf gave a speech and said "I really regret that we decided 32
bits was big enough".  I don't want to make that mistake again.

Q: [Ken Calvert] There is also a multiplexing cost - you can't interleave with
anything else.  There may be scenarios where this makes sense -
suggest you describe the parameters and analysis where it really
matters, and see if it's really worth it.
A: OK.

[Nacho]: flexibility causes problems when you do exact matching - have
to go over every field to make sure it's encoded properly, or else
have multiple hashes.

[Kevin]: another place to do it IPv6-like: stuff it in an extension
header for the terribly large ones.

Q [Ralph Droms]: what is the intention of this work?  Is it to lay out diffs
between CCN/NDN, or are authors making recos?  Are you
recommending that this be adopted as the unifying approach?
How to understand the rest of the work being presented?
A: Want to make sure the protocol definition is flexible enough.

[Dirk]: at this stage different people are bringing reports on the
status of their implementations.  My understanding: this is their
perspective on the packet formats.

Forwarding Target Pointer (aka locator).
Allow Interest Forwarding to operate on something other than the
interest name proper, which remains in the packet.  Supports mobility
a la Kite, late-binding,. FT flag plus forwarding header.

Header compression - hooks for header compression - ask downstream
node to allow use of "name abbreviations".

[Nacho]: agree, it's a per-link thing.

Caching as a service: Introduce packet processing complexity where it
is more useful.
Q: Ralph: is there more to it than this?
A: no

Shareable vs. non-shareable.  non-share can be on fast path without
PIT/CS processing.  Optional Header TLV.  Don't have to use cache.

[Nacho]: cacheable/non is not the same as shareable/non.  Might want to
cache, e.g., upstream from a lossy link.

Selectors - optional feature. Implications for PIT design.
Should be a feature that can be optionally enabled.

Q [Nacho]: if traffic with the option goes through a node that doesn't
understand it, what happens?
A: like IP today, just ignore it.
[Nacho]: we proposed a selector protocol that runs on top of CCN that
works like this.

Context handling - 

Summary

Q [Nacho]: The only thing you discussed that wasn't optional was the TLV,
right?
A: right.
[Nacho]: we are in agreement with others that static format is the way
to go.

Q [GQ, to Nacho]: why is 64K the magic number?
[Nacho]: unlike the 32 bits in IP, it doesn't impose a fundamental
limit.  It imposes a unit size; the only question is whether the
overhead it imposes is too big.
================================================================
QoE in ICN - Damien Saucez

- http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-3.pdf

Just discussion now; to decide if it's an important topic.

Question: For a given infrastructure, woudl the QoE be better, equal
or worse with ICN than IP.
Def' (ITU): QoE = overall acceptability of application or service as
subjectively experienced by the user.
Objective part = QoS; Subjective part - nothing to do.
So: focus on objective measures.

3 Main factors:

i) Service factor = how to design caching and routing to preserve or
improve QoE?  (e.g., changing source from one chunk to another may
cause variability).  People may be more influenced by variation than
by quality itself.

ii) Transport factor  = how to design the transport mechanisms (e.g.,
congestion control) in ICN context to preserve or improve QoE? (e.g.,
caching may have negative effect on completion time of least popular
contents. Consider big popular and small unpopular file requested at
same time.  Big file served from cache, takes more BW than small file.

iii) Application factor = how to design applications to preserve or
improve QoE?

QoS = characteristics of service that bear on its ability to satisfy
stated and implied needs of the user.

Q [GQ]: What is the "QoE Model"?  
A: ITU takes people, puts them in a room, measures their "happiness".

[Dirk]: fear we are re-inventing problems and labeling them "ICN
problems".
A: Don't think there is really anything new here, but we need to take
into account the user experience.  In some cases it may be better, on
some worse, but we need to take into account the user.  Need to be
able to say "if you do it this way, the result will be this".

Q [Ken]: Can you really say anything aboout QoE in isolation? Caching
example that hurts the less popular object has an assumption of
fairness.  There will always be a context... and the answer will
depend on it.

A: Yes, there is fairness question but it's not all about fairness.

[Dirk]: keep discussion going on the mailing list.
================================================================
Network API for ICN - Cinyoung Hur

- https://tools.ietf.org/html/draft-hur-icnrg-abstracted-network-api-01
- http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-4.pdf


API = language spoken by application.  Well-designed API is important
to adoption of ICN.

Network Independent Model on top, Network Specific Model below.
Intent modeling: separates concerns vertically.  E.g., voice call
requires security and QoS.  Mechanisms: IPSec + jitter control.

Loosely-coupled modeling - separates concerns horizontally. E.g.,
get(), retrieves data regardless of protocol.

Prototype of Abstracted Network API: IPlug and DSocket.
Upper layer: Bind - identification of application
Plug-in and Plug-out: dynamic association between application and
network (DSocket)?

Q [Nacho]: do you somehow in your API detect where the content is, to
go and get it?
A: Yes.  didn't show it.  Monitor or mgr who can provide...
[Nacho]: but application is trying to provide or consume.
For consuming, what is the info you give the API, and how does the
stack figure out how to get the content?  TCP/IP, etc.
A: [note-taker could not follow...]

[Nacho]: Side note: Stack Evolution will be discussed tonight in tech
plenary.  May be relevant to this.
================================================================
Demo: Web of trust in ICN - Jan Seedorf

- https://tools.ietf.org/html/draft-seedorf-icn-wot-selfcertifying-00
- http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-2.ppt

Part of GreenICN project.

Verifying key-ID binding based on WoT.
Uses a double-sided BFS algorithm to find cert chains between
initiator of the request and the publisher of the content.
Use "trust metrics" to assess the graph/chain.  E.g., how many paths
shorter than a given length.

Current PGP web only has about 50K users. (!)
Developed a methodology to synthesize large-scale WoT graphs,
maintaining several key graph-theoretic props.

Want to see how this scales, depending on trust metric, size of WoT,
etc.