ICNRG/T2TRG Meeting, Sunday, November 13th, 2006 Seoul =================================================== =================================================== Note takers: Ari Keränen, Dirk Kutscher, [add-your-name-here] Michael Koster Carsten introduced joint meeting. Morning session together with T2TRG, afternoon ICNRG only while many T2TRG folks will be going to NMRG IoT meeting. First part 4 presentations, second part focusing on discussions. Carsten introduced T2TRG. Dirk introduced ICNRG. Presentations ============= Research and Development of the Hyper-connected IoE Network Technology - Taewan You Taewan presented AETHER for future IoE networking. Fog computing, ICN, and IoT. N.N.: specifics of naming scheme? Taewan: self-certifying IDs used. Also source address integrity procedures. Jairo Lopez: ID-Net proposal had a generic model -- is that continuing research? Taewan: not using new concepts here. Can send URL for more info about details. ---------------------------------------------------------------------- Device and Network naming structures and ICN for IoT applications - Lopez Jairo Jairo presented work on naming. Names very context dependent (Barcelona city vs Football Club; more than one of both). Dirk: do we need addressess? Jairo: yes, if you need to get somewhere. But you have to be careful of the context you're talking about. Conclusion: everything is a name. Address is how to get to a name. Jairo presented mapping of RFC1498 concepts to ICN. No "path" in ICN. Jörg: there are flavors of ICN that have concepts of path. Using bloom filters for example. Jairo: Namespaces seem to be independent. Each layer only needs to know the relevant names (e.g., network -> nodes). Börje: differences between ICN approaches -- you seem to primarily refer to CCN/NDN. In other approaches, you may have name resolution services that would give you an address for a name. Jairo: afternoon discussing mobility part. Do we need all parts in the same namespace? Could we make them independent? Will in IoT scenarios want to know what particular node is doing. Börje: Do you mean that names should be different from names in addresses? Jairo: no, one namespace (e.g., service namespace), then node name would be come address for service name -- these namespace would become independent Ravi: have system for managing namespace. Collapsing two namespaces become unmanageable. For mobility etc want to have separation of namespaces. Marc: don't know what you say ICN has no node names -- everything ICN system uses something like this for mapping interfaces to routes Jairo: have not read completely the area. Main difference: one thing to identify node but another if it's in namespace need management how to give those names Marc: It might make management easier, but not all names may be topologically relevant. Like in IP Lixia: NDN does router announcements for reaching data name prefixes, not node name Marc: does NLSR announce router names? Lixia: yes, but only for "management". As far as routing info is concerned, we realy announce data prefixes Marc: not sure how you run Dijkstra without node identifiers? Jairo: had long discussion on this at Kyoto. Complicated topic. ---------------------------------------------------------------------- A RESTful, Distributed and Enhanced ICN System for IoT " for ICNRG/T2TRG meeting - GQ Wang Some reseach questions looked into: should ICN use URIs or REST be extended to different kinds of names? Can ICN be used to create distributed Resource Directory? Can ICN reduce the amount chatter generated by IoT devices thanks to caching in network? the concept is discovery and routing based on semantic attributes found in Resource Directory entries and links application components form a mesh, not a single monolithic application Christian Groves: about filtering at the edge, filtering data at edge was discussed at the T2TRG meeting at Ludwigsburg. Dirk: mentioned translating between IoT networks and Internet. What's vision, is such translation always needed? every namespace has its own domain GQ: probably yes right now because every namespace has their own domain. Flat namespace for local network. But global network needs some mechanism. In RESTful systems we use URIs. For scalability for routing prefixes needed. For node/application/service name; need someone to manage the names. Can one name serve all purposes? Lixia: yes NDN data names serve three purposes: identifying data, forwarding interests, and security. Findsing the best way to handle the tradeoffs among the three is one of the basic research challenges. GQ: need different names if want all different functionality. Need rechability from network. But different for application. Lixia: can reach each other without attachment in local settings; only in large scale need attachment to scale the forwarding. Matthias: on mapping on ICN to REST; do ICN systems come with their own interaction model? Every system has their own methods? Dirk: yes, different applications use different things. For example DASH-based video using manifests. For IoT no common agreement yet; want to figure out one. Matthias: have impression that ICN could solve lots of issues with intermediaries. Could roughly be replaces by ICN. For naming URIs help because just agreed scheme how they are put into string that is opaque to the (RESTful) application itself. GQ: Could put that fucntionality to access point Michael: is there a URI scheme that we could use? Right now, DNS chances names to addressed -- how about ICN? GQ: personal view: will be up to application. If all aps use URI, simple mapping to URIs. Dirk: different variants of nams in ICN. Not only hierarchical names. Also tuples (type-value), etc. N.n:: ETSI m2m group have standardized names. GQ: When you know URI programming, it's easy to use this in ICN ---------------------------------------------------------------------- [coffee break; back 10:50] ---------------------------------------------------------------------- I3: some thoughts towards an Industrial Information-Centric Internet of Things - Thomas Schmidt i3: Industrial ICN. IoT surveillance scenario. Can ICN outperform IP in such case? Looking into routing, mobility, security, reliability, caching, deploymen environment. Dirk: potential for cost efficient and safety critical infra for IoT here. Hoping to get more practical experience. Ravi: one question is basic benefits of ICN in IIoT. Have probably done survey on this. See ICN having upperhand compared to current IIoT stacks? Thomas: not looking at proprietary stacks. Looking into IP world and ICN implementations. Have industrial partner who needs to see if there's benefits. Jörg: comment: we built this for underground mines, using DTNs. We found that there is no spectacular routing -- you just want to collect all data (so use epidemic spreading). Mostly message coding for robustness. Also, management issues (updates etc.). Also had gas sensors. Most problems were not very researchy. Mostly engineering issues. Lixia: Mobility support -- what are the application scenarios you are having in mind? Thomas: scenarios are still under debate. Refinery with relatively large space with "factory units" spread across place apart from each other. Cars and people moving in between in field. Endpoint (istead of network) mobility. Finite field mobility and re-attachments. Sensor devices on person and other machinery. Mesh of sensors. Lixia: recent DDOS attack was lauchned on IoT devices, so IoT urgently need security. Thomas: security is issue. Was implementation failures on IoT device level. Different story. Lixia: but it makes the point that IoT today is not built with security in mind Carsrten: if it's not usable secure, it's not IoT. Call it IoC(rap), IoS or one of those. Dirk: mentioned publish side & pub/sub. Need to extend current ICN protocols? Thomas: core problem is event driven reporting. Push needed. Several solutions how to implement this. Need initiation from alerting entity -- I'm your content and want to share content; that's publish. Putting content to interest is one of the suggestions but reverting the paradigm and causes other issues. Initiated data flow needs to correspond to routing to get stuff from A to B. In CCN have routing that guides interest, but also reverse path pointers. But no RPP without interests. Need to cope with this. Don't necessarily want to exten protocol, but need to think what would be semantically correcly, elegant, solution. Alex: comment: ICN opportunities in IoT, naming is very important. Forwarding based on interest names. For example, in some applications, geographic coordinates could be embedded in names. "Interest can figure out itself how it is forwarded". Thomas: two things: need routing and forwarding to work hand in hand. Need setting up FIBs. Lixia: Alex's point: can do forwarding without routing protocol. Fundamental point: be careful in using the word routing. The fundamental goals is forwarding. Routing is to assist forwarding when needed (for scale). Thomas: do not believe in namespace engineering that only works for selected applications. Naming is important, but if constraints are too specific, then you exclude apps that cannot deal with this naming. Alex: that's why I said it's for subset of applications. ---------------------------------------------------------------------- Dirk gave summary on ICN & IoT discussions. Claimed benefits on access to data, security, availability, stack simplicity, etc. But need to substantiate these claims. Open research questions on naming, semantics, security, IP Internet interaction. Jörg: is semantics discussion tied to network? Will deploy contained with data and can refer to with ID. Could argue that not pushing too many bits and pieces to the interaction of two things might be helpful. Not sure semantics part is intertwined with data retrieval. Carstren: important with discovery Dirk: what doing at ICN IoT is to figure out how -- you can see the whole stack in a different way and optimize the stack. Integrate interest information to help with forwarding. Börje: when doing computation on things need to know what to do with data Jörg: not sure if the things are that intertwined Carsten: don't need to change CoAP for semantic interop Dirk: do these need to be considered together? Carsten: both groups have the problem, for ICNRG probably not yet painpoint but for T2TRG already is Carsten: whole term GW is loaded. Gateway used to be router in the past. Term has changed its meaning to something that can be complicated (and allows to make money). In e-mail, we used to have all kinds of mail gateways, and we managed to get rid of them, because we developed a common of how e-mail should be handled in the network. Would it be useful to think about the functions of an ICN-IoT that works for many different applications, so that we can do permissionless innovation (main point of the Internet). Can we come up with a gw abstraction that is powerful enough that we don't have to come up with a gw for every new application? Discussion today: how we can show that ICN is better in IoT than application/network protocol X. More interesting: Understanding the common major issues, so that both groups can benefit from these insights. Carsten presentation, starting with: "endpoints..." slide. In REST world transport addresses used. But rather need something bound to identity (but identity is overloaded term). Börje: folks see areas of common interest and things to work together? Thomas: Carsten's last point (Identity Confusion, APIs) is very important. To have applications that can run in both Restful and ICN environments. Ravi: Naming is from applicatio perspective. Want to name services. In ICN everything does not need to be content centrinc (depening on protocol). ICN IoT requirements draft discusses the intersection between two groups. Michael: interesting discussion content vs naming. Ravi: Fundamentally, can you impose one kind of naming for all applications? Jairo: we should maybe talk about having mechanims to include the things we want on naming; have policy in network what to use. If no mechanism to add or remove this, not good. GQ: @T2TRG: ICN could be a candidate technology for mapping application to networking layer. Do you have support for multipoint communication/distribution? Carsten: elements in architecture like proxies but should take the details off-line Lixia: should work together and figure out the API together. Instead of talking should build applications. That would teach us more than discussions. It is not that NDN enforce any specific naming structure but we learned from real implemnetations the relations among naming, security, and forwarding. Let's put 10-20 different things together and see how they can talk. Jörg: There is clearly potential to explore things jointly. Building apps certainly useful. Last week, there was a fair on industrial sensors in Munich -- lots of proprietary solutions. We have a hard time getting CoAP and ICN deploy individually. Could be interesting to discuss how we can create something that creates some value so that people can pick it up. Carsten: large part matter of education . Should examine this. Dirk: in business environments need to build stuff and demostrate key benefits. Not just conceptual slides. Ravi: can also learn from existing systems. Fixed, power efficient, naming is clearly important. Börje: how to get people to care about this, what are the real problems people have. Then can have impact. Some design guideline for IoT and ICN in the ICNRG which T2TRG folks could give feedback on would be good. What should be in such document. Contact Ravi. Ravi: authors of the document come from ICN perspective. Getting IP IoT perspective would be quite beneficial. Carsten: not lof of T2TRG people would be interested to write doc that says there's another architecture that's better. Rather want to take home bits that are useful. Need to make sure it's reseach doc, not marketing doc. Börje: need to be closing now. Sense of the room was this useful exercise? (folks nodding) Carsten: probably was too short Matthias: is someone actively working on both sides? Many quesions for example what parts can be modularized? Someone who could comment. Someone who participates in both communities? Börje: Thomas, Matthias, Lixia, Börje Lixia: more than welcome to join also our sessions. Matthias: already participating in many groups. More meetings not helping. If can have people who participate in two and can give executive summaries between would be good. (joint meeting adjourned) ====================================================================== 13:30-15:00 Session 3 Note taker: Dirk Kutscher ICNRG is using this github project to share working documents for several activities (e.g., harmonization, terminology): https://github.com/icnrg ---------------------------------------------------------------------- IPoC: IP over CCN for seamless mobility - Greg White (25 min) Greg presenting Ravi: what is the reason for this approach Greg: want to use unmodified applications Ravi: something like a proxy on the client? Greg: more like a tunneling endpoint Ravi: where is the protocol translation happening? Greg: no translation Ravi: what is tunnel stack? Greg: TCP/IP/IPoC/CCN Ravi: why do tunnel IP over CCN? Greg: because unmodified applications can benefit from CCN transport Dirk: what is the cacheable unit? IP packet? Greg: yes, you wouldn't get application data unit caching with that Greg: for HTTP it might be more beneficial to do "HTTP over CCN" Dirk: with this approach, you are losing the interest/response balance property Greg: yes Dirk: what about the response to an Interest packet with an IP packet? Greg: explanation on slide Dirk: are you dropping packets? Greg: yes, drop tail at the moment GQ: for upstream traffic, you are sending IP packets in interests? Greg: yes, like a tunnel Marc: are there interactions with timing of transport protocols Greg: should be fairly weak interaction. There could be latency peaks, when packets queue up at gw. But not much different to normal IP router Marc: if you were looking at TCP window size, you could maybe make a better estimation of the number of the interests you need Greg: Can pack multiple IP packets into one Content Object, so this gives a lot of elasticity GQ: did you compare with Mobile IP (PMIP etc.)? Greg: no concrete results yet, but goal is to be competitive with EPC Greg: in terms of latency performance, with most parts it should be very competitive with EPC, especially considering user mobility GQ: performance comprison to native approach? Greg: this is definitely a tunnel protocol, but 3GPP today is also using tunnels Ravi: for consumer mobility, you are expecting the ICN layer to resend all interests (at handover time) Greg: just the empty interest (no need to resend IP payload), also can do soft-handover Ravi: do you benefit from caching also? Greg: for handover, yes, we retransmit interest packets which could pull from cache Ravi: there is no semantic match for re-sending Interest Greg: no, but not sure whether there needs to be Dirk: comparison with TCP/CCN? Greg: this one can support all IP-based transports, also can do bi-directional communication directly ---------------------------------------------------------------------- Seamless mobility for ICN -- Keping Yu (25 min) Jairo Lopez presenting Ravi: have you looked at inter-domain mobility? Jairo: you would have to keep the topological meaning of names for the whole network Ravi: domain == AS -- how would you handle that? Jairo: with globally unique ICN names, and with topologically significant names, it would work Lixia: what do you mean by topolgy? AS relationship is not network domain topology Jairo: mathematical topology, not network routing topology Lixia: remember landmark routing? Jairo: will take a look Lixia: producer mobility -- producer does not know latency etc. This maybe similar to geo-hyperbolical routing Jairo: possibly Ravi: How would you manage mobility? Jairo: we assume reactive network -- user has to tell network that it is moving or has moved Jairo: network can buffer for you if you told it that you move before Jairo: when producer moves, it has to tell the consumer the new node name Dirk: wonder whether Saltzer's RFC is a good guidance for ICN? Jairo: objective was to enable two namespaces and keep topology namespace from ICN namespace Marc: maybe also look into mobility in LISP Lixia: Saltzer is 30 years old -- may not match too well to ICN -- should not be taken as a bible Jairo: maybe some of these concepts have not changed (names vs. addresses) Marc: also look at custodian ICN forwarding (Jacobson paper) Lixia: Survey of ICN mobility paper, one category "signalling free" mobility Ravi: but this is not seamless mobility management Lixia: in ICN, with facebook-like publishing, you don't need to chase producers Jairo: mobile networks rely on mobility anchor Lixia: pre-knowledge vs. post-knowledge. With well-known rendezvous (pre-knowledge) points, you can avoid real-time signaling GQ: what is the different to home agent then? Lixia: you still need to do chasing GQ: but centralized rendezvous point would not scale Lixia: do it distributed Lixia: move the data, instead of chasing the producer Ravi: how does the rendezvous point get the data from the moving producer with "chasing" Lixia: rendezvous can be the namespace (so distributed) Lixia: also K.K.'s paper at ICN-2016 ---------------------------------------------------------------------- NRS Requirements Update -- Jungha Hong (25 min) ---------------------------------------------------------------------- Status update on the CCN/NDN harmonization efforts - Alex/Lixia?? (30 min) Marc explaining status and recent process Current write-up: https://github.com/icnrg/draft-icnrg-harmonization ---------------------------------------------------------------------- Terminology document (20 min) Bastiaan: submitted first version before Berlin, got some comments, now addressing them for a next revision current question: should this be focussed on one approach or talk about ICN in general telcos on Thursdays, f2f meeting during this IETF week Lixia: agree on broaad coverage, would like to focus on one thing first ---------------------------------------------------------------------- IoT document (20 min) Ari agreed to provide some feedback on Iot requirements drafts ---------------------------------------------------------------------- RG maintenance/admin (20 min) Planning for future Interop / Hackathon Planning future meetings January interim? note: QUIC interim from Jan 24 to 26 in Tokyo (could be a conflict)