ICNRG Wednesday meeting 9:30am - 12pm Karlin Room- Hilton - Prague.  Note taker: Cedric Westphal (Huawei) --------------------- * Sunday Meeting Summary (Chairs) On Sunday we had in the morning: - readout from ICN/IoT Workshop in Stockholm - readout from Intel-NSF Research program kickoff 6/21-22 - research talks from ICN'7 TPC members: new NSF CC* project on using NDN for data-intensive science (Edmund Yeh); ICE-AR under the NSF/Intel-WEN program (Lixia Zhang); ICN Network Coding (Cedric Westphal); Keyword-based mobile application sharing (Ioannis Psaras) - Update on CICN community Open Source work (Luca Muscariello) - Configuration/management and control of an CICN network demo (Marcel Enguehard) In the afternoon: - Update on Harmonization Work (Alex) - ICN principle discussion (DaveO/AlexA) - Hyper-connected IoE network technology (Jungha) Drafts:  - draft on Status update and discussion on Terminology (Bastiaan Wissingh) - draft Enabling Network Identifier draft (Ravi Ravindran) - Name Resolution Services (Jungha Hong) - Introduction to the draft Consideration of the Applicaiton of Multi-Service Tag (Duan) -------------------- * Results of last Call on CCNx protocol documents (chairs): - from the point of view of the chairs, positive feedback and no issue raised. Consider the last call complete and suggest to move the documents forward. - DaveO: Allison, these two documents are coming to you for IRSG review. Expect by end of the week. Intended as Experimental RFCs. Reasonably high degree of importance to this community.  - DirkK: good milestone; we want to do more of this in the future. If you have work of this nature, we are happy to help progressing that.  - BörjeO: a number of other protocols in the pipe; please take a look at them, as they are coming up for last call pretty soon.  ------------------------------- * ICN-LTE document. Prakash Suthar (+Milan Stolic, Anil Jangam, Cisco Cystems) Native deployment of ICN over 4G/LTE networks. v0: March 2017, first draft; v1: May 2017, feedback from IETF-98; Version 2: June 2017 (additional in-depth review and feedback at IETF-99) Objectives: ICN deployment scenarios for 4G/LTE mobile networks. Because current research/projects covers: ICN as an overlay; ICN scenarios to date are either in fixed wireline or wifi network; .. ICN Deployment Options in UE - Dual Stack of Native?  Involved as well in 3GPP, proposed in parallel there.  * In the UE: Proposing to put an ICN forwarder that co-exists with IP for ICN packets (e.g. interest packet to eNodeB or response "data packet" from eNodeB to the application). Propose a transport selector (ICN or IP) and radio interface (LTE,WiFi or both), preference (content location, content type, publisher, cost, QoS) PDCP layer updated to support ICN (sequencing, drop detection, retransmission), ROHC, ciphering/deciphering.  * In the Base Station: handle ICN request, can send on ICN transport handle IP as well; can handle selection of "IP or ICN" transport: ICN, IP, dual stack ICN/IP * ICN Deployment in the transport Envision a dual stack scenario (IP/ICN) to remove encapsulation tunnel (GTP tunnel for instance);  Native ICN removes the need for GTPTunnel or do it only locally.  Intent to implement ICN natively from the radio all the way up to the GWs.  Northbound API to influence decisions along QoS/Cost/Etc * ICN Security considerations 7 key security domains: 1 UE authentication/authorization;2 radio interface security;3 DoS attacks on mobile GW, services;4 content poisoning either in transport or servers;5 content cache pollution attacks;6 secure naming, routing and forwarding;7 application security Call for more input in these areas. 1/2/3 addressed in existing security specs TS33.310, TS33.320; but not the others considerations. Additional issues: DPI, Lawful Intercept (LI)   * Next steps: working group draft? Q/A: Akbar: read the previous version, and it was good. One comment, on security. I will be presenting deployment considerations next. RFC7945 (security considerations) actually covers some of the issues. A: I went through that, but there is more to be done.  Akbar: U/E stack. Proposing a dual stack approach, right? ICN function: when would you use that? When you have 4G deployment that is fully upgraded to ICN? A: when IPv6 was deployed in the network, they introduce some capability when the client attaches, it can indicate a preference for IPv6 or v4; now is the time to do something similar to introduce ICN. when introduce ICN function along with IP, it will help UE indicate its choice: I want to attach as an ICN client.  Akbar: so it would be UE initiated? A: right; we went with anchorless quite a bit, but especially when the user is attaching to the network, it has to indicate its point of attachment. It has to indicate: "I'm an ICN client".  Dirk Trossen: I like the draft, very good to integrate into LTE. Question I have is at the top box, you talk about existing application, and you slot the transport. Do you believe a transport selector is the key issue? Do you believe an HTTP-based application, merely selecting the transport would be enough? A: Between client and GWs, the application are requesting the content; all they need is the socket to connect to the IP layer and send it out. We're trying to introduce an additional mechanism in addition to IP. Tomorrow you might have some app that uses only ICN, but other can be agnostic ICN/IP based upon network performance. DT: so you using ICN as a pure channel? A: yes John Dowdell (Airbus Defence and Space): I work on DTN, where we have the concept of using any transport layer and a protocol layer on top of this. We have in between a convergence layer, to adapt the protocol with the underlying transport. I cannot make sense of your picture in that context. Maybe you should take a look at this work. I believe the concept of transport selector is implicitly defined in DTN.  A: more choices in transports DK: good comment, perhaps the ICN community has a bit of DTN background and more can be learned. There has been some work on running ICN over DTN. Steven Farrow had a draft on this.  Chairs: quite a bit of interest in this work. Question to Prakash: do you have work in the pipeline for a new version? Also from today's feedback? A: yes, lot of additional input to work on, plus what DaveO send to us. If it's a working draft, we'll have more consideration.  DT/Chair: provide an updated version, and we'll have an adoption discussion on the mailing list. BO/Chair: ask the room and provide a round of comment, do we have volunteers? Dirk Trossen, Ravi, Greg, Ankbar. Thanks! Also ask your colleagues on the mobile side.  ------------------------------------------------------------------------------- * Akbar Rahman (InterDigital) Deployment Considerations for ICN (+Dirk Trossen, Dirk Kutscher, Ravi Ravindran) 2nd revision of the draft.  ICNRG charter identifies deployment guidelines as an important topic; specifically, defining concrete migration paths for ICN deployments which avoid forklift upgrades and define practical ICN internetworking.  Revision history: rev0 in Chicago, good feedback; rev1: addressed feedback; rev2: addressed detailed comments from Dave Oran Main changes: title changed from "configurations" to "considerations"; rework definitions to refer to existing RFCs and ICN-terminology draft; added more details on ICN-in-a-slice; all deployment trials grouped under "overlay" and "underlay"; added ICN2020 trial summary; generalized ICN gaps to potential protocol effort only; removed references to IETF WGs/BoFs; expanded conclusion to cover points from all sections; added Security considerations (key deployment related point from RFC7945) as well as new issues (end-to-end context for security); added more references; editorial changes... Q: Thomas Schmidt (UHamburg) What I'm missing is the activities of ICN over wireless, and in particular over lossy low-power networks. There has been work, we have done some, to experiment and deploy ICN on wireless and in particular on low-power constraint nodes. Can you add something about it?  A: this would fit in Section 5, deployment trial experiences. I'll talk to you, find the references and I'll take an action to that. Dirt Trossen (as a co-author): I actually suggested the reference too late. But it will be significantly expanded in v03.  Application migration: new applications enabled by ICN? CDN is a key use case to redeploy. Good candidate for ICN deployment. What are the issues for edge/core network deployments. Q: Eve Schooler (Intel): I was curious, you say your trial that range from a few to a couple hundreds nodes. Do you know of trials that have larger deployments?  A: in the corpus, we didn't see anything in the 10,000s. The largest was in the low 1,000s.  Q: ES - is that enough to understand the gaps? More a question to the larger community.  A: the problem has been looked at from many different angles; some protocols have been tested and are RFCs.  Comment (DT): scale is obviously an issue; limiting factor in Amazon cloud is budget but could scale to 10,000. Engineering factors.  Remark on excluding simulations, and we have one reference on socio-economic studies; this one is looking at large-scale migration, considering a dual-stack deployment. This is not a deployment, but a deployment-oriented study. I could not find the NDN study on the same topic.  Lixia: our work has not so much of a transition; we believe the most advantage of a new architecture can be explored by taking new apps that fully take advantage of it. I'm not confident that transition architecture will deliver most of the advantages of ICN.  Lixia: regarding the previous presentation, having transport selector on top of ICN would lead to a long discussion.  A: application is a key area to look at. If apps are ICN-enabled, it should be considered.  Lixia: existing apps can benefit greatly from ICN; but given that they work on top of, and are designed for point-to-point address based delivery model. My personal view is that they would not fully benefit from ICN.  DK: research group, we should investigate more both ICN-only and transitions. Not exclusive. BO: I'll give you a NetInf pointer regarding IoT/COAP extensions to NetInf.  Deployment configs:  1- wholesale replacement (clean slate); IP infrastructure is replaced 2- ICN-as-an-Overlay (tunneling approach): ICN-over-UDP, name mapping, etc 3- ICN-as-an-underlay. Support ICN infrastructure islands (at the edge or core); protocol mapping at ingress/egress Network Attachment Points (NAPs); allows backward-compatible introduction of ICN infra while reaping ICN benefits of multicast delivery, fast indirection, etc.  4- ICN-as-a-Slice. With introduction of 5G network slicing, deploy ICN there (Ravi suggested this) Lixia Zhang (UCLA): the point I care most is not there: native ICN running directly on top of wireless, with apps directly on top of ICN. ICN-WEN program, most interesting deployment; fully utilize wireless heterogenous technology Dirk Trossen: I respectfully disagree. Draft has ICN at the edge, it's in the draft. Service migration is considered as well. You have to read the draft multi-dimensionally. IoT scenario fits in migration and deployment at the edge.  Dave Oran: one of the teams working on the WEN project is explicitly looking at running ICN over a slice in 5G. So one of the ICN-WEN is explicitly in this. You can contribute to the draft.  Ravi Ravindran (huawei): I don't think you are missing anything. If you listened on the talk yesterday on 5G from the 3GP folk, it's the most flexible architecture. It's an opportunity that we see to deploy ICN.   Lixia: saying that ICN can run on wireless is not the picture. It's a new way of trying things out; native ICN wireless. If you segment the picture (ICN on wireless and on the other side, something else), that's a different picture.  I want to reply to Ravi: I understand 5G has its own picture. From my angle, 5G is nothing but one of the wireless. You could use 5G/bluetooth and WiFi simultaneously, and that's a different picture.  Next steps: potential to do another ref on this;  BO: same as previous document: continue to comment.  DO: let's get more comments, rather than issuing another version of the draft now.  BO: we agree, get more comments now, then do a new rev.  DO: let's get more comments, ball is in your court Jan Seedorf (Stuttgart): does the research group think we should publish this? I believe we want this, this is useful to put out. I cannot comment on the maturity of the text. But the primary issue is: does the group want this to be worked on. I support moving this ahead and eventually adopted it.  BO: how many people think it's valuable. [lots of hands raised...] Yes, the group thinks it's of interest.  BO: Do we have volunteers to review? Prakash volunteer to review, Haru (?) as well. Dave Oran - After the 2 volunteers review the current -02 revision, the authors should update it quickly to -03.  The -03 will then go for WG adoption call on email list.  The authors can feel free to contact the Chairs to push the volunteer reviewers if there is too much delay. ------------------------------------------------------------------------------ Jan Seedforf (Stuttgart): Research Directions for Using ICN Disaster Scenarios. (+ M. Arumaithurai, A. Tagami, KK Ramakrishnan, N. Blefari Melazzi) Taking into account Akbar's comments mostly. Akbar, feel free to chime in. First comment: change in the name to add a research perspective.  Scope of document: scenario and use cases.  History: multiple initial versions (2013-16), output of GreenICN project. Various feedback incorporated (how ICN relates to existing DTN...); adopted as RG item in February 2016.  Comments/diffs: Mention existing disaster services in mobile networks; there is already some support that has to be mentioned.  Mention some services work without authentication (say, emergency calls).  List of ICN benefits is not exhaustive. Or is it? We should not wait until we have all possible benefits to move this document forward; list closed now..  Voice calls after disaster: how does this fit in ICN? We think that voice calls are not possible and that messages should be DTN/not real time/disconnected network.  Akbar: I agree with how you handled my comments Dirk Trossen: shouldn't be one of the advantages of ICN to have the choice between real time or non-real time?  A: maybe I can add text to say this. We can do VoICN in certain cases, but we considered the case where it's not.  DT: what matter is availability of content, so if the user is reachable, it should be a choice.  Comment: is there existing work for ICN data mules? mentioned some.  if further work needed? -> yes! how does this relate to IETF standardization?  Objectives: informational RFC. Explain why ICN is a good starting point for addressing communication challenges after a disaster; concrete example of existing work in the ICN research community;  DK: chairs are inclined to last-call this pretty soon.  DO: we could last-call this one and include today's comment as a last-call comment. DK: nit comment. You use the acronym WG, it should be RG.  ------------------------------------------------------------------------------------------- * Cenk Gundogan (HAW Hamburg) Pub/Sub deployment option for the constrained IoT (+Thomas Schmidt, Matthias Waehlisch) Scenario: IoT Sensor and Actuator Networks. Sensors produce data, immediate data propagation, alert notification. Naive approach in NDN/CCN: polling; wakes sleepy devices, superfluous traffic.  Polling unfeasible in large scale deployments. Problem: data propagation. Push is bad. Breaks flow balance; cache poisoning, DoS. We should preserve the NDN/CCN request/response channel.  Publish/Subscribe option: data immediately propagated towards content proxy; data is NOT PUSHED; name advertisements on control plane; data is replicated hop-wise on data plane.  Built/Maintain Routing topology using Prefix Advertisement Message (broadcast, link-local scoped) and NAM (Name Advertisement Message) DaveO: clarifying question, as maybe others didn't misunderstand as badly as I did. In most designs, the control plane is running on top; you are running the control plane on top of layer n-1 in parallel with the request/response paradigm of the regular ICN data plane? Is that the correct understanding? A: yes DaveO: then people would be confused that you call this a control plane.  Thomas: NAM is not an interest message, it's not a data message DaveO: this is fine, but that does not make it a control plane.  Thomas: I would consider this a classic control plane.  Cenk: objective was to not overload the semantic of the interest Ravi: one entry in the FIB prefix? Cenk: there is a default FIB entry with the upstream router? Ravi: you may have more entries for the different names Thomas: you have one FIB entry per prefix; if you have different name spaces, you have different entries in the FIB. But all name that have a common prefix clearly aggregate to this content prefix. So per prefix, one entry in the FIB.  Publish: hop-wise propagation of data to the Content Proxy (CP) DaveO: why did you discard the idea of interest/interest/data exchange? In other word, the publisher sends an interest to the CP; the CP then issues an interest to the publisher. it seems your hop-by-hop scheme reintroduces all the push problems, but just localized at the edge. A bad sensor can flood the network Thomas: a bad sensor can always flood the wireless on a local link. DaveO: we already have to build some congestion control tools for interest; with your proposal, you have to add another layer for the hop-by-hop mechanism.  Advantages: Publisher Mobility: Publish = NAM -> interest -> data Network partitioning.  Ravi: I thought publish was a control plane action. You are actually pushing data? Cenk: in response of receive the signaling, we request the name.  Ravi: it's still a trigger.  Thomas: it's probably easier. no new attack vector on the network layer . Experimentation using RIoT and CCN-lite. 300 constrained devices.  Ravi: publisher mobility depends on the CP staying the same; Thomas: if you move the GW or the border route, you are moving the whole network.  ----------------------------------------------- * Ravi Ravindran (Huawei) Support for Notifications in CCN Draft history: v0 IETF95; IETF96: more discussion around flow and congestion control; current version attempts to respond to why current Interest/Data abstractions fail.  Motivation for PUSH in CCN: upstream heavy traffic, with inter-arrival distributed over mins to days.  CCN Push requirements: PUSH intent support, multicast support, security, routing and forwarding support, minimizing processing.  Four approaches in this draft: using interest/data abstraction for push.  1- Long lived interests;2 polling;3 overloading interests;4 interest trigger Draft offers design choices for all. + description of all four approaches.  Thoughts? Comments? DK: what is your plan with this draft?  A: flow balancing is not enough, you need other mechanisms for congestion control. ChronoSync does not cover the case of mission critical. People are not happy with having only one mechanism for all their requirements.  Thomas: I agree with most of what you say in the presentation. But it does not fit the title of the draft. The title should be "problem statement and brief survey"  A: yes, it was proposed as an extension to the CCNx protocol, then it took a more research direction. I can change the title to reflect the scope. There is a significant sized community looking at this issue.  DK: most agree that asynchronous notification is an interesting topic. It would be good to keep working on this. Keep it as a living document as more people are working on this field. I  A: sure. I haven't read Cenk's draft either, so will include this.  ----------------------------------------------------------------------------------- * ICN based Architecture for IoT (Ravi Ravindran, Huawei) ICN-IoT system architecture: added authentication manager, a key component for on-boarding and validating their ES IDs at a system level. Thomas (HAW): can you relate the entities in the draft to the 6lopan architecture?  Ravi: it's a border router.  Lixia: there was a bar BOF on Monday. Experience shows that naming is fundamental. I don't see this discussed here. Where is your name architecture? Ravi: we have a local ID.  Lixia: I'm talking about your name space architecture. Name space structure.  Ravi: you want to give a name to a producer Lixia: what is your name structure that ties together identity, security? Ravi: the draft discusses this with NDN and MobilityFirst BO: what Lixia is looking for is in the design consideration document Lixia: I'm asking about name space structure, I don't see this in the draft. Maybe we can take this offline.  Ravi: Figure 2 is just an architecture, there is no specific names associated with this. Lixia: if people talk about Information-Centric, it's that we care about information instead of location. The fundamental challenge is how you name the information.  BO: Lixia, can you provide a presentation at the next ICNRG meeting.  Lixia: I owe this group of presentations. The discussion on Pull/Push, it's an architecture decision, it's not an application. You can list me, I'm always working for deadlines. Muhammad Akhbar: naming ??? Ravi: when we talk about name, how you map name to location is name resolution. Here we focus on giving name to service, content and devices, and then you can place on any transport.  DaveO (chair hat off): I think it's 3 years too early to talk about ICN IoT architecture. We need a lot more work on many pieces before we can do a systems architecture. It presumes that we know a lot about how the pieces work. Lixia: I strongly second DaveO. Build a system first.  Ravi: this is very typical architecture in any IoT system.  Lixia: paper design is one thing, build a system.  Ravi: come to our lab and see the system we build DK: is it fair to say that this document does not reflect the system that you build? Ravi: it's true that it's high level. There are basic functions that ICN provide that are ICN functions. You have to build basic middleware functions to make IoT system self-configurable, scale, and to do large scale  Emmanuel Bacceli (INRIA): what are the aggregators on Fig2? Ravi: they are the unconstrained nodes to which the sensors talk to. They are called proxy.  EB: There are some function of the GW? Ravi: I separated the GW Thomas: question, what do the arrow mean on Fig2? The aggregators are border routers, or are they outside? Ravi: the aggregators are the roots.  Thomas: if the arrows are communication, the aggregator would talk to the others? Ravi: Embedded Systems can talk to each other and aggregators. Aggregators can talk to other aggregators and ES to get the data.  BO: show of hands for this? Only a few hands. We need more input.  ------------------------------------------------------------ BO: show of hand on IoT Design Consideration.  BO: that's also only a few hands. We need more people to look into this.  Eve Schooler: I have volunteered last time for the comments on the draft , I will send my comments.  Eve Schooler: I think overarching IoT architecture. I wonder if other architectures are discussed in other IRTF/IETF, there needs to be coordination there.  DK: IoT and ICN is an important topic. If you are doing some work, please feel free to tell people about it, just give a presentation about experiment, it doesn't have to be a 100 pages draft. We're interested in having discussion and learning things.  ----------------------------------------------------------- * Wrap-up (Chairs) - Upcoming ICN events: ACM ICN conference, September 26-28, Berlin; RiOT event as well; ICNRG Interim meeting, September 29th 2017, Berlin. Future ICNRG meetings.  - We are planning on meeting in Singapore. Week-end Sunday meeting would depend on contributions, topics of discussion - IEEE Com Mag feature topic on ICN security. Manuscript submission deadline: November 1, 2018.