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!