ICNRG interim meeting minutes
Saturday, 27 September 2014, Paris, France
=================
First morning session
=================
All three Chairs present; ~50 people in the room
- NOTE-takers recruited
- Agenda bashing (no changes)
- Last item of the day will be open discussion about take-aways from the
conference. What insights valuable for ICNRG or any new items that
should be taken up.
- Also: Folks leaving early please give chairs their views on whether
to meet in Honolulu; needs to be decided in the next couple of days.
================================================================
ICN and Video Distribution - Eiichi Muramoto, Panasonic
"Consumer Driven Adaptive Rate Control for Real-time Video Streaming
in CCN/NDN"
Target is at the "live" (=buffering intolerant) end of the spectrum.
Goal: less than 200 msec delay.
Examples: security camera, real-time tracking, with multiple users
accessing sources. RTT fairness is important!
Interest-data RTT variation caused by (i) data coming from different
sources; (ii) congestion, queueing (as in current Internet).
Proposed method: measure RTT on each data packet; cache average RTT in
each short period, control interest rate based on AvgRTT.
[Q: Dave O - what's the increase exponent? 0.5=square root? yes.]
Basic idea: distinguish between source change and congestion by
suddenness of change.]
Single period increase/decrease -> assume source change.
Several consecutive increase/decrease -> infer congestion and adjust rate.
NDNSim evaluation. Comparison vs. AIMD: proposed method is more
stable in various RTT, with lower delay.
Note: method not TCP-friendly
Evaluation of fairness: consumers gain same t'put, vs. AIMD where gain
is inversely proportional to RTT.
Evaluation on multi-bottleneck topology: good fairness, adapts to
smallest bottleneck.
UCLA video implementation.
Many Q's about parameters, how "consecutive" is defined, relationship
between buffers and RTT. Where were caches? Did you use the RED
queue in the simulator? Are you aware of other work that shows
indicates that adapting according to RTT is hard?
Are you sure this is stable? (Answer to the
last seems to be no.)
================================================================
Adeel Malik, Ericsson
Applicability and Tradeoffs of ICN for Efficient IoT
draft-lindgren-icnrg-efficientiot-01
Goal: see how well ICN fits for IoT, what are challenges. Try to
avoid introducing iot-specific architectural challenges in ICN.
Good fits: data-orientation, caching, sender-receiver decoupling
Challenges: control/manage devices, names could be larger than data,
dynamic data, security of real-time data
Design choices w/ no changes to ICN
- device actuation and control: use ICN w/ existing protocols
- how to name aggregated information (e.g. aggregated sensor readings)
-- have known or deducible names
- Immutable atomic data units vs. dynamic data
-- model as a stream of immutable data units; "latest" name is deducible
(e.g., from timestamp)
- handling actuators - state as data object
-- actuator has to poll for desired state
- don't force constrained IoT devices to act as intermediate ICN nodes
-- but they may store their own content
Dave Oran: what if you have a mesh network? Yes, then you must have
nodes forward.
Ralph Droms: it's an important problem. It's more about
outing/fwding the interests, rather than data.
Börje: usually here we are talking about wireless; we should
remember that radios are naturally broadcast when we design ICN.
Dave O: Broadcast is seductive, but all nodes
have to be awake simultaneously for it to work.
Börje: yes, but we still need to take this back, e.g., to 5G
discussions - if we someday have very low-power radios that
are always on, things will look different.
George Polyzos: we should give proxies a more prominent role. Scatter
them throughout the network, use them for expensive operations.
Adeel: my statement might have been a bit aggressive. (:-)
George: but we should not accept the status quo either.
Dirk: instead of mandating proxies, we should discuss the options.
Should that be true only for ICN? Hybrid solution with Inet?
We shouldn't mandate a proxy-only soln.
Mark Stapp: it's not either/or. It's really a hybrid. Some nodes
are well-connected (or on). There will be some mix of managed and
low-powered devices.
Ralph: There are many different use cases. Example: sometimes nodes
are low-power but fixed. May need different strategy layers for
different contexts.
Jörg Ott: The IETF is building IoT extensions for the Internet protos. We
should see this presentation as a starting point, which doesn't
discount other options.
- Object security - should be handled above ICN layer.
Ralph: re security: you don't have to have all the smarts in the
node. Node can send the data and let somebody else worry about
access control, other policy aspects.
Mark: you didn't mention the possibility of sending sensor data in
interest messages. I want to keep making the pitch for being able
to do that. "Route it to the more powerful object" seems like a
viable model.
[Presentation resumes]
Design choices - where additions/changes to ICN would improve efficiency
- Importance of time - may need extensions (metadata) to represent
time.
- Pull and push - want push for real-time, triggers, alarms.
both should be supported. But who defines the trigger conditions?
Dave O: there are subtleties when you combine push and pull. It would
be good to have real use cases. If you decide you need push to get
things out quickly, you lose caching. If data is generated by the guy
sending the interest, the security model is cockeyed. May be necessary to
send the data you would have sent if it had been polled for.
There's a real opportunity for interesting work here.
Ralph: opportunistic caching may not be useful in this case, but
"architected caching" may be more useful, where it (cache) is explicitly
populated.
Felix : Suggest to look at what the Node.js guys did with their API
for stream processing. It may be useful.
Manolis: Isn't this pretty application-oriented? What's important to
the network is what is forwarded when...
Ralph: there is a question here: do you model this as one eternal
object that emits chunks periodically, or is each sensor reading a
different object? Time series - thermostat vs parking meters, they
are different things.
Paul Polakos[?]: when we talk about pushing and pulling, we may have different
ideas of "push" - I think it implies someone is listening, else it's
just not useful.
Mark Mosko: one way of getting real-time updates is to send an interest
with very long lifetime, sits in the PIT at the sensor for long
time, whenever there's new data it goes outs. (Not that he thinks
that's a good idea...)
- optional Meta Data - for efficiency reasons, delivering metadata
should be optional.
Dirk: the draft was really nice. Re: efficiency - does it make
sense to think about implementation efficiency, simplifying the
stack etc. a la RIOT?
Adeel: not sure, hadn't thought about being that specific.
Ralph: what about operational considerations, e.g. overhead,
configuration complexity? That is another form of efficiency.
Dave: Maybe people who have ideas should contribute to the draft.
My reading is that we should use this good discussion to move the
discussion forward.
================================================================
Ravi Ravindran, Huawei
ICN based Architecture for IoT - Requirements and Challenges
draft-zhang-iot-icn-challenges-00.txt
Looking at not just devices, but services and higher levels.
Multipoint to multipoint...
Draft was split to encourage participation, into challenges and
architecture.
[Going through the draft]
Motivation: ICN-IoT could be one binding layer for lots of systems...
[summarizing the draft, see the slides.]
Legacy IoT systems - are very fragmented and siloed. Small set of
pre-designated applications "Not something that fosters innovation"
State of the art is everything funnels to a server/gateway.
ICN allows to decouple service logic from data distribution logic.
Overlay approach - on IP is not really suitable.
Popular scenarios - smart grid, transportation, healthcare, education,
entertainment,...
ICN Challenges:
Naming - constructible names, on-demand publishing. Requesting data
not yet published.
Contributions to draft are welcome.
Dirk: meta-question. This is an extensive effort. What do we do with
it? Have you considered exporting this to the hard core IoT people? You
are preaching ICN benefits to the choir here. Any outside feedback?
Ravi: no.
Börje: Dirk has a point. If we want to reach out, if we think we have
a better way of doing it we should sell our stuff to these people.
George P: what's the relationship with the previous draft?
Ravi: no connection.
Ralph: Lots of time spent in draft describing different application
scenarios. Are there common threads?
Ravi: that's why we put the requirements up front - many common things
are provided by the basic ICN abstractions. There are still
area-specific challenges. Last section is suposed to give the ICN
perspective, but there are still things to be explored.
Dave O: this document tends to have a top-down approach to the area,
more breadth than depth, which is good because it shows the shape.
The other draft is more bottom-up: here are the real environments
and what we have to deal with. It may make sense to have both and
work both bottom-up and top-down.
Adeel: We had a section on design choices. Are you willing to
to suggest some choices?
Ravi: There is some work coming out that we think will cover that.
[Coffee Break]
===================
Second morning session
===================
CCN/NDN Packet Format, status update and discussion
Dave Oran intro:
—————————
Diego presenting "Update on experimental wire-speed packet format and comparison of different proposals”. Some key concepts/capabilities:
———————
Nacho presented CCN 1.0 packet format. Some key concepts/capabilities:
———————————
Cisco - Mark Stapp
NDN - Alex Afanasyev
Discussion:
[Lunch]
=================
First afternoon session
=================
/********** Industry-academic cooperation for the NDN project from NSF **********/
Dave talked a bit about the industry-academic cooperation for the NDN project.
/********** Scalable mobile backhauling via information-centric networking **********/
Presenter: Luca Muscariello
Luca: Packet forwarding is being done at 4000 packets per second
Dave: Is it graduate students doing that? :-)
Dave: So you are choking the links to achieve the same effect as a very high rate of packet forwarding?
Luca: Yes
Alex Afanasyev: What kind of CCN statistics?
Luca: Average hit miss etc. You can have per object statistics but that can slow down the system due to logging load.
Nacho: Is this the old CCN?
Luca: Yes
Mark: Did you try separating ICN with caching and ICN without caching. ICN without caching meaning multi-path.
Giovanna : Most of the gains come from multi-path actually.
Dave: Are you measuring all the way to the mobile?
Luca: Yes
Dave: Are you considering congestive losses here?
Luca: Yes
Börje: Are you doing ICN in the caches in eNodeB?
(Not able to capture the answer)
Dave: To get the same effect (multi-path) out of IP you would have to put a load-balancer in IP?
Giovanna : Dynamic load balancing would be impossible with IP in the mobile core.
Dave: Yes, because of the tunnels.
Ravi: Mobility is handled in L2 in mobile networks, right? You don't change your IP address.
Luca: It depends. (Not sure if that was really the answer)
Audience: Are you assuming that the budget of all caches is the same?
Luca: Yes
Audience: But in a few presentations in the conference earlier we saw that the benefits of edge caching can be more in certain cases.
Luca: (Not able to capture the answer)
Dirk: So when you say DPI you mean there is a transparent HTTP proxy?
Luca: Yes
Ravi: I dont see in the diagram that the UE talks ICN. Is it only HTTP that the UE talks?
Luca: Yes, ICN is transparent to the UE.
Ravi: How easy is that adaptation? Taking all HTTP traffic and putting it into ICN.
Luca: A number of adaptations are being done.
/********** Bloom Filter-based Flat Name Resolution System for ICN **********/
Presenter: Jungha Hong
Jeff Burke: What is the red line at the bottom in your diagram?
Jungha: That is a peering relationship.
Dave: Is adding or removing a locator equally expensive computationally as locator update?
Jungha: There is a difference. (Did not capture the rest)
Dave: Did you look at the scalability aspects of adding/removing/updating the locator?
Jungha: The scalability relates to the size of the bloom filter. Do you mean to talk about that?
Dave: Let's take is it offline.
No more questions or comments after the presentation.
/********** A distributed latency-aware caching mechanism for networks of caches **********/
Presenter: Leonce Mekinda
Audience: Have you tried to evaluate the signaling needed for your approach?
Leonce: There is no signaling. A node makes local decision based on the latency of the packet.
Dave: In your model it seemed like you had latencies in a restricted range. Not very high or very low latencies. Which means that this approach is not for high pressure points.
Leonce: (Did not capture the answer)
Dave: Since caching is being done based on latencies, that means that caches in Denver will be caching content from Japan rather than caching content from San Francisco
Leonce: It is probablistic. We take popularity into consideration. So that problem will not occur.
Dave: What about someone deliberately inflating latency so that their content is cached.
Leonce: That is a problem. But the problem is mitigated to some extent since popularity is taken into consideration.
Note: Orange has decided not to make the slides presented at this presentation public at this point in time.
[Coffee break]
====================
Second afternoon session
====================
Christian talk - Named functions
- Networking is full of name rewriting
- Network is full of term rewriting
- Modules rewrite
- Modules can be abstracted (higher level rewrite boxes, ping is composed of many rewrite boxes)
DaveO: Turing complete -> halting problem?
Christian: Not everything is solved. Just a view of networking.
KevinF: Timing problems?
Christian: Some things are not possible from a theory perspective. The arrogant formal theory viewpoint.
KevinF: It may not be a rich enough model
- CCN: rewrite box interests->content objects (I->CO)
- View the network as that type of box (interest->content object)
- Do all boxes look like the high level box (I->CO)?
DaveO: In costumer side, data does not arrive without an interest.
KevinF: Rewriting system that is not order preserving?
DaveO: If data can be produced before an interest arrives, that implies you know the name that will be used. How does this map to rewriting?
KevinF: Is this an arbitrary rewriting system?
Christian: It’s a framework
- How much work is done in the box? (or adjacent boxes)
- Interest with selectors could be rewritten for an environment without selectors
- Lambda calculus (expressions as inputs, results as outputs)
- NFN can emulate all ICNs
- NFN could translate from NDN to CCN.
KevinF: What’s the difference between NDlog and this?
NDlog was for configuration specification
NFN is for executing functions. More complex queries.
- Current approach, a name stays. We need to experiment changing that in the network.
- SQL does rewriting with builtin functions
- How much stuff can we bring into from Descriptor based systems?
- Named data has a constant name-to-object binding
- NFN has term rewriting
- Who can run on top of who?
DaveO: NDN only sees one hop in a computational chain. (for example, requesting a video of a certain bit-rate).
KevinF: Naming issues also exist in sender-based system. (Send this to green people within 3 meters of point X)
DirkK: We should talk about whether NFN is above the ICN layer.
KenC: This might only focus on one part of the network. But it seems suitable mostly to lambda calculus.
FelixR: Is NDN only a subset of NFN.
XXX: We should talk about explicitly exposing functions from the network. Not necessarily doing full lambda calculus.
XXX: Most of the packet formats expose the same information. We might need to expose a way to convert 1 to the other.
Leonce: RESTful system just RPCs like NFN
Christian: NFN has no side effects on the network. RPCs an interesting thing to look at.
KenC: Not a lot got done with pure lambda calculus / LISP
JeffT: If you move discovery out of routers the discovery can do something more fancy, like run other functions.
JeffT: In REMAP we define a namespace, once defined, you want to query things in a different manner than the hierarchal namespace.
MarkS: That’s SQL! - We need constraints.
DirkK: What’s the NFN concept over the ICN concept.
Christian: Does every router need to do the same thing?
MarkS: A router that’s designed for throughput needs to do the correct thing when it sees traffic of certain type
Christian: Name doesn’t need to be the name used for networking
DaveO: It seems there’s a strong desire to collapse layers. Route to places to compute stuff, return previous results without redoing computation, etc. Is there a strong benefit to collapsing?
DaveO: I know what the worse case for forwarding is. I don’t know what the arbitrary computation is if we collapse layers. What do you lose by layering on top?
Nacho: CCN is trying to define what every node must do.
KevinF: Nacho is too black and white. You need to define middle boxes and things that are needed in some boxes.
MarkS: Transport functions are more logical to implement in network, but arbitrary functions are hard.
MarkS: We can let the network expose some stuff.
<discussion discussion discussion> = what is black and white
Nacho: CCN defines a minimum set, yes, it sets a line in the sand. We decided not to do regular expressions for queries or attributed based naming.
DirkK: What are we defining on each layer?
KevinF: Is it a layer or is it optional.
Nacho: Caching is optional.
KevinF: You seem to be looking at programable networks, and this is just how programable networks apply to ICN.
DirkK: There is interest in this topic from the group.
KevinF: You might even be able to form an RG.
=====================
IETF Honolulu discussion
Dirk - We could get a slot, potentially 2 slots if needed.
Dave - If we’re going, we should exploit the meeting. Work on the packet format?
Börje - Send suggestions to the list of what we want to talk about in Honolulu
Dirk going to Honolulu.
Potentially an interim meeting before Dallas for packet format.
=================================================================
Attendance list
===========
# |
Name |
|
|
|
1 |
Börje Ohlman |
Borje.Ohlman a t ericsson.com |
|
|
2 |
Diarmuid Collins |
collindi a t tcd.ie |
|
|
3 |
Dimitri Papadimitriou |
dimitri.papadimitriou a t alcatel-lucent.com |
|
|
4 |
Jeff Thompson |
jefft0 a t remap.ucla.edu |
|
|
5 |
Ravi Ravindran |
ravi.ravindran a t huawei.com |
|
|
6 |
George C. Polyzos |
polyzos a t aueb.gr |
|
|
7 |
Mayutan Arumaithurai |
mayutan.arumaithurai a t gmail.com |
|
|
8 |
Paul Duggan |
dugganp4 a t tcd.ie |
|
|
9 |
Mark Stapp |
mjs a t cisco.com |
|
|
10 |
Yong-Jin Park |
yjp a t ieee.org |
|
|
11 |
Luca Muscariello |
luca.muscariello a t orange.com |
|
|
12 |
Salah El Ayoubi |
salaheddine.elayoubi a t orange.com |
|
|
13 |
Léonce Mekinda |
leonce.mekinda a t orange.com |
|
|
14 |
Nacho (Ignacio) Solis |
Ignacio.Solis a t parc.com |
|
|
15 |
Glenn Scott |
Glenn.Scott a t parc.com |
|
|
16 |
Glenn Edens |
Glenn.Edens a t parc.com |
|
|
17 |
Marc Mosko |
Marc.Mosko a t parc.com |
|
|
18 |
Ersin Uzun |
Ersin.Uzun a t parc.com |
|
|
19 |
Andriana Ioannou |
ioannoa a t scss.tcd.ie |
|
|
20 |
Michele Tortelli |
tortellimichele a t jp.panasonic.com |
|
|
21 |
Eiichi Muramoto |
muramoto.eiichi a t parc.com |
|
|
22 |
Zeng Xuan |
zeng.xuan a t orange.com |
|
|
23 |
Claudio Imbrenda |
claudio.imbrenda a t orange.com |
|
|
24 |
Dave Oran |
oran a t cisco.com |
|
|
25 |
Jörg Ott |
jo a t netlab.tkk.fi |
|
|
26 |
Olov Schelén |
olov.schelen a t ltu.se |
|
|
27 |
Christian F. Tschudin |
christian.tschudin a t unibas.ch |
|
|
28 |
Christian Kreuzberger |
christian.kreuzberger a t itec.aau.at |
|
|
29 |
Daniel Posch |
Daniel.Posch a t itec.aau.at |
|
|
30 |
Jungha Hong |
jhong a t etri.re.kr |
|
|
31 |
Antonella Molinaro |
antonella.molinaro a t gmail.com |
|
|
32 |
Joo-Chul Kevin Lee |
cms.rune a t orange.com |
|
|
33 |
Adeel Malik |
adeel.mohammad.malik a t ericsson.com |
|
|
34 |
Giovanna Garofiglio |
giovanna.carofiglio a t alcatel-lucent.com |
|
|
35 |
Dirk Kutscher |
dirk.kutscher a t neclab.eu |
|
|
36 |
Diego Perino |
diego.perino a t alcatel-lucent.com |
|
|
37 |
Manolis Sifalakis |
sifalakis.manos a t unibas.ch |
|
|
38 |
Sergey Slovetsky |
Sergey.Slovetskiy a t ericsson.com |
|
|
39 |
Bursztynowski Dariusz - Korpo |
Dariusz.Bursztynowski a t orange.com |
|
|
40 |
Akira Ito |
AIto a t us.fujitsu.com |
|
|
41 |
Paul Polakos |
ppolakos a t cisco.com |
|
|
42 |
George Xylomenos |
xgeorge a t aueb.gr |
|
|
43 |
Andrea Araldo |
andrea.araldo a t gmail.com |
|
|
44 |
Thomas Schmidt |
t.schmidt a t haw-hamburg.de |
|
|
45 |
Matthias Wählisch |
m.waehlisch a t fu-berlin.de |
|
|
46 |
Cedric Adjih |
cedric.adjih a t inria.fr |
|
|
47 |
Gill Bilal |
bilal.gill a t aalto.fi |
|
|
48 |
Ralph Droms |
rdroms a t cisco.com |
|
|
49 |
Ken Calvert |
calvert a t netlab.uky.edu |
|
|
x |
N N |
n.n a t dom.com |
|
|