Minutes interim-2017-icnrg-01: Sun 09:00
minutes-interim-2017-icnrg-01-201703260900-02

https://trac.ietf.org/trac/irtf/wiki/icnrg

ICNRG Interim meeting @ IETF-98 Chicago, IL, USA, March 26th, 2017

Agenda
9:00 Meeting starts
     •       Welcome, Agenda Bashing, Minutes taker, Bluesheets, Status -
     Chairs (15 min) •       Comparison of Security and Privacy features in
     major FIA architectures - Chris Wood (30 min) •       FD.IO open source
     CCN forwarder - Luca Muscariello (30 min) •       ICN testbeds - Luca
     Muscariello (20 min) •       NDN community meeting update/report - Lixia
     Zhang (20 min) •       Deploying Information Centric Networking in LTE
     Mobile Networks - Prakash Suthar (30 min)
12:30-14:00 Lunch
            •   GGIE::Leveraging IPv6 Glass to Glass - Glenn Deen (30 min)
            •   Merged NRS requirements draft - Jungha (30 min)
            •   Reliable ICN transport - Ideas and issues - Börje Ohlman (30
            min) •   Terminology document (30 min) •   Breakout sessions ◦  
            Terminology draft ◦   ICN & IoT ◦   … •   Wrap up, Next meetings -
            Chairs (10 min)
17:00 Meeting ends (the latest)

Notes

1. Session:
Note taker: Prakash

Comparison of Security and Privacy features in major FIA architectures - Chris
Wood - Why are we comparing ICN security wth IP and not with full stack (e.g.
https) - How do you manage trust relations - (Ravi Ravindran): ICN packets have
source ID and how does work with MobilityFirst.

FD.IO open source CCN forwarder - Luca Muscariello
Comments from Chair - Cisco IPR covers experimental RFC and not just standard
RFC - How does ICN relates to HTTP? - for hICN what is advantage of putting
name inside IPv6 header?. - for hICN do we use overlay or embedded naming?

2. Session:
Note taker: Dirk

NDN community meeting update/report - Lixia Zhang
Collaborations with LoRA for rooftop mesh.
- What devices using LoRA for NDN
-(Prakash): With NDN you do not have to know about network at all. Is  that
possible because in reality to implement NDC/ICN natively we need  to know the
network?

Lixia Zhang presenting on NDN community meeting update/report
Q (Dirk): on slide 5, is the solar-rooftop network using mesh networking?
    - Lixia: yes, with LoRa
Q (Eve Schooler): what do you mean when you say "security" (as a research topic)
    - Lixia: we have been building apps and worked on things like schema-based
    security focus - Lixia:  security is difficult, first of all, what does it
    mean? ICN allows highly granular security approaches -- not one cert for
    signing everything - Lixia: principle of limited privilege

Deploying Information Centric Networking in LTE Mobile Networks - Prakash Suthar

Q (DaveO): in the first two deployment scenarios, you are still running a GTP
tunnel all the way, so that ICN would not get involved in mobility at all?
    - Prakash: In this case ICN is not involved in mobility management (control
    plane) however ICN is involved for content delivery.

Q (DaveO): on "implementing ICN in EPC": what is the encapsulation?
    - Prakash:  Right now it is GTP but 5G architecture with network slicing
    might use SDN based protocol e.g. open flow. We are doing some POC and can
    disclose once we have good data to share

Q(DaveO): what is the protocol you are proposing, e.g., ICN at eNB?
    - Prakash: we are working on that

Q(RaviR): In 5G, there is a proposal for non-IP protocols. Do you have an idea
how that could be used here?
  - Prakash: yes, ICN could be the non-IP. Next-gen 5G could support IP and
  non-IP.

Q(Ravi): is there any push in 3GPP towards non.-IP
      - Prakash: there is a smaller team

Q(Akbar): is there conversion to HTTP or other protocols? What do you assume
about the other end?
    - Prakash: data does not have to be native IP. You could use ICN e2e. If
    you cannot, then you have to think about gateways.

Q(Akbar): if other end is pure HTTP /IP server, then you would have to use some
translation, correct?
  - Prakash: yes

3. Session:
Note taker: Luca Muscariello

GGIE Leveraging IPv6 Glass to Glass - Glenn Deen (30 min)
Jan: clarification question about the usage of the IPv6 address as a name

DaveO: Privacy about using IPv6 addresses leaking information about all frames.
DaveO: routing on a per session basis seems unscalalable

Q(Prakash) - How do deal with NAT64 when publisher is not connected through
IPv6?. Q(Prakash) - Do you see synergy between your project and Cisco hICN
project? Q(Ravi) - How to you track content cache in CLASS? Q(Dirk): how to you
take care of security on the session?

LucaM: There is something missing with chart: TCP.
HTTP is not a transport protocol, TCP is.
DaveO: this is anycast TCP. Which does not work except in very special cases.
Discussion in the room
There is one TCP socket per 2 seconds segments which can be downloaded in few
ms. That means that there is one socket open and a close for every single HTTP
video segment. This is probably going to kill the server. Socket management is
already complex today, this will add complexity. The client cannot take
advantage of TCP caching anymore as there is one socket per video segment.
Socket parameter reuse is lost. Content networking requires to change the
transport not only the forwarding layer. Glenn: need to look into Transport too.

Junga Hong: NRS in ICN
DaveO: there is likely a need for a name resolution function. It can be made in
the routing protocol, in a name resolution service like the DNS or elsewhere.

Lixia: I do not feel that we are ready for it. Requirements are not clear.
Ravi: many routing scalability problem that can be addressed in the resolution
system. Dave: good material in the document. Requirement vs service. There is
something we should do on the topic.

JH: We need a name resolution function. Is it enough to change the term?
Dirk: the term requirements has a specific meaning in standards so that the
system design can trace back to requirement in the standardization process to
verify that the system satisfies those.   Having examples with experiments on
how to use the system might also help.

EveS: the approach of defining an API might be useful
DaveO: if you needed an NRS this is important to consider. Might be better not
to assume the existence of the NRS. Starting point for moving forward: do not
require NRS in the system but focus on what properties an NRS needs to have
have in case it is included as part of the system.

Börje:  Reliable ICN transport - Ideas and issues - Börje Ohlman (30 min)
DaveO: discussion about where loss detection recovery and congestion control
can be located. The figure seems to indicate that they have to be located at
the same place. One of the advantages with ICN is that they can be separated
and potentially located at different places in the stack. Börje: The intention
with the picture is *not* to suggest that L, R and CC has to be located in the
same place. The picture only indicates *possible* places where they can be
applied and they could definitely be separated and located at different levels.
Luca: would add N (notification) to L(Loss), R (recovery) and CC (congestion
control) DaveO: TCP/QUIC has to be optimized at end point because they cannot
optimize in routers. This is constraint not an advantage in comparison to ICN.

4. Session:
Note taker: Börje

Terminology document
Baastian presented an update on the document.
More contributors are welcome.
There will be breakfast meetings Monday and Tuesday. Details will be sent to
the mailing list.

AOB
Carsten Borman announced that T2TRG will have breakout sessions at their
meeting on Monday. Some of them might be of interest for ICNRG participants.
People are encouraged to attend the meeting.

ICNRG meeting Thursday:
Please check that everything is on the agenda. If not contact the chairs ASAP.
Please come to the meeting!