ICNRG Meeting @ IETF-91 ======================= Monday, November 10, 2014 15:20 -- 18:30 ICNRG web page: http://irtf.org/icnrg ICNRG Wiki: http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg Dirk Kutscher, Chairing [admnistrivia] [review of agenda] Documents Update - Dirk ICN Baseline Scenarios - passed ISRG review, now IESG review ICN Research Challenges - mostly complete, will consider outcome of current QoE discussion, call for final RG review soon. Evaluation Methodology - Editorial work required, mostly on sect 2.1 on simulators/testbeds; aim for RG review early '15. First ACM ICN Conference was in Paris in September - nice event. Next one next year in SF. Followed by full day meeting at LIP6/SystemX in Paris. Discussed video distribution, ICN and IoT, CCN/NDN packet format discussions, Scalable mobile backhaul via ICN, Distributed latency-aware caching, named function networking (championed by Christian Tschudin) - likely we will come back to that in the future. See wiki for all materials and minutes. ================================================================ Video Update - Cedric Westphal - https://tools.ietf.org/html/draft-irtf-icnrg-videostreaming - http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-7.pdf Focus: most traffic in today's net is video; no reason to assume that will be differnet, so it needs to be supported efficiently. Can current Internet mechanisms be adapted to an ICN? [Other question, not considered here: should new mechanisms be designed for ICN?] No recent major changes, some reorg and two new sections. Draft focus on current use-cases, to capture requirements. Expanded list of research items: potentially the structure of an "ICN-specific video mechanisms" document. Real-time issues, requirements of flash crowd, local video distribution (no infrastruct), heterogeneous environments, network coding? Packet formats for Video? [Nacho Solis]: hard to understand some of the documents in the group (not just this one) - we at PARC are driven by what we are doing, but some general documents ... it's not quite clear what the conserations are. I'm happy to work on this document. [Dirk]: what would be the contribution of these documents? [Nacho]: would be good to have docs to point newcomers to, so that they can learn about areas or contexts (e.g., video, IoT) that they are not familiar with, so they can design the protocols correctly. Don't see that in the current documents, including this and IoT [implication: docs are too high level]. [Cedric]: Fair point - document (and WG, to some extent) tries to be agnostic about what ICN is going to be. At some point you have to be specific, not sure when that will be. We can start that discussion, but it's not what's in this document right now. Caching discussed mostly to reduce BW usage in the network by avoiding repeating dup requests. But can be used to increase capacity for a single network xmission. May allow you to find "niches" or reservoirs of capacity. E2E adaptation (a la DASH) uses minimum of server-cache and cache-client rates. What to do with this doc? Next document? Native ICN video streaming, what would that look like? Agree with Nacho that if you are going to design for a specific architecture you should at least say what that looks like. Q [name unknown]: Are you trying to solve everything listed in this doc? You list many tough tasks - are they potential work items? A: this could be an outline for potential new drafts. Or look at what issues might come up, e.g., what happens if you wnat to run DASH over ICN? Q: Hard to figure goal of THIS document itself. A: Outline scenarios/use cases, which have different requirements. [Dirk]: What to do with the document? We should be confident that this will be something that people would be interested to read... We got some feedback. Proposal: keep this draft mostly as-is, but clarify assumptions about what "ICN" means, without going into packet format details. [Nacho]: for these documents the incentives are mis-aligned = to finish this and go onto something else. It's informational anyway. You are asking "Are we done with this discussion doc?" I say stop before adding a lot of protocol-specific stuff. Question [Cedric]: who has read 01-version? (about half a dozen hands) So: go ahead with 02 version, get more input from group. ================================================================ IoT Update - GQ Wang - http://tools.ietf.org/html/draft-zhang-iot-icn-challenges - http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-1.pdf Quick review of doc after comments from Paris meeting. Updated portions only. Draft was split to encourage participation: Architecture and Use cases, then ICN CHallenges. Only latter was changed. Naming and Name resolution: smart homes, smart grids, ... Caching and Storage: where to cache - unconstrained vs. constrained envs. What to cache - pub/sub info in routers? Caching in context of actuation - little meaning for authenticated requests, e.g. Building Mgt Systems. Scenaro-specific challenges for caching - similar. Routing & Forwarding: requirements (direct & indirect) Direct Name-based Routing - flat names, producer mobility introduce challenges. Indirect routing: name resolution system; static vs dynamic binding, later requires router to handle (?) Scenarios: some for each. Req Most Specific to IoT: contextual communication - constraints related to timing, power, trust, ... Info-gathering for self-config - Contexts processed in network layer Again, challenges across all contexts. In-net computing: security requirements, filtering noisy data, context reasoning, services for networks... Security & Privacy - "crucial to all IoT applications". Most concern about privacy. Also BW limitations - when you get only 100 bits, how are you going to do, e.g., authentication? Contributions are welcome. Q: [Al ? ] are you looking at what's been established last few years? E.g., refrigerators - they don't have TCP/IP. How will you convert them? How will you accommodate the security? A. Some of these folks have said their intent is to replace TCP/IP. Our view: TCP/IP is overkill for tiny things. Just need a very simple packet format, just room for the name. You use TCP/IP, you need a babysitter - not workable for IoT. Q: But how you going to get it across the globe? A: Agree with you. Talking about in a certain domain. Q: Then you gotta build a gateway, and that's costly. Who's gonna pay that cost? A: People build gateways today. Look at Nest. We do have an implementation, if you do another protocol stack, then we pay the penalty of gateway. [Nacho]: we work on many different networks. Not connecting fridges across the country. We can run as overlay or native. Power co uses in an island. Goal is to build a complete stack... [Dirk]: whole thesis of IoT work is that there is value in having an abstraction poerful enough to connect IoT with big-I internet, without having to have application-specific gateways all over the place. Q: [Dirk]: When you explain challenges (e.g., routing), do you think this document should make recommendations? A: Not in the architecture. We don't impose any solution in this document. ================================================================ BF-based Flat Name Resolution Update - Jungha Hong - https://tools.ietf.org/html/draft-hong-icnrg-bloomfilterbased-name-resolution - http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-6.pdf This is version 02. Presented twice before, but will go over basics for those who haven't seen it.. "Location indepedent flat name assumed in ICN" NRS maintains and resolves bindings. Proposed B-NRS imposes hierarchical structure - network of B-NRS servers, a forest of disjoint trees. No constraint on peering. Use BFs to aggregate name. Announce BF instead of full name. 2 components: BF and lookup table. Lookup table stores loc(s) of already-resolved names. BFs store names for children and peers. No constraints on name registration - BF updates via insert-through. BF cannot handle deletion. Locator information is inserted/deleted into name lookup table. "Inherently supports mobility" because info of locator can be changed. Forward to all children/peers with positive output from BF. If fail - send up to parent. BF can't handle deletion, this is a problem. How to handle? - ignore - update all BFs on every deregistration - counting BFs. Expands BFs; size is already a challenge - have two copies, refresh periodically. Results on BF size vs. FPP Assume 1M names in BF => 2MB BF size k: (optimal # hash functions) = 11.09. Example: assume server at top with 1M children, 1M names each (1T names). Lookup in child BFs via hardware assist (GPU). Q [Nacho]: you aggregate BFs from children and then send that to peers. So are you XORing the million BFs? A: This is only at the top. This shows how to do it for 1T entries. Q: so every query goes through the top node? A: Just showing an extreme case. Q: You assume flat names, not all architectures assume that. Also, flat names => flat traffic, so most queries will go throught the root? Q: [unknown] What about false negatives? A: No such thing in Bloom Filters. Q: [Dirk]: what about maturity of this work? Implementations? A: work in progress, we are working on hardware implementation. Q: [Nacho]: At the beginning, you queried the first server. Does it have the BF of it's parent? So if it misses, it queries the parent? A: Yes. ================================================================ CCN/NDN Protocol Wire Format & Functionality Considerations - GQ Wang (also Christian Tschudin) - http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-0.pdf Current TLV discussions focus on performance. But other considerations: flexibility, scalability, expressiveness - these also need support @ wire format level. "One TLV to rule them all" is bad. Need support for multiplicity of schemata. - one(few) for header, but more flavors for payload. Examples: backward compatibility, NFN, service composition Elastic TLV: Variable "length" - 2B for type, 2bits + 14 bits for length, with 2bits defining units: 00 = B, 01 = KB, 10 = MB, 11 = GB. Selection of per-unit resolution can be chosen by the application, based on feedback from ICN fwding layer, based on strategic path level feedback. Q [Nacho]: now you have to have padding options, because units are too big. What is the big win in transmitting big things as one unit at L2? Don't agree with this, we can argue whether 64K is right thing... Q [Kevin Fall]: DTN bundle protocol, FYI, many fields are variable/extensible. Use a bit in each byte so they can be as long as you want (at expense of more processing). Might be convenient if they were the same format. A: fragmentation is per-interface. Optical is most reliable link today. Q [Nacho]: when you are transmitting your 2TB bundle, do you keep it in memory or do cut-through? If the latter, you can do that with little ones. A: but then there's lots more overhead. Example: Vint Cerf gave a speech and said "I really regret that we decided 32 bits was big enough". I don't want to make that mistake again. Q: [Ken Calvert] There is also a multiplexing cost - you can't interleave with anything else. There may be scenarios where this makes sense - suggest you describe the parameters and analysis where it really matters, and see if it's really worth it. A: OK. [Nacho]: flexibility causes problems when you do exact matching - have to go over every field to make sure it's encoded properly, or else have multiple hashes. [Kevin]: another place to do it IPv6-like: stuff it in an extension header for the terribly large ones. Q [Ralph Droms]: what is the intention of this work? Is it to lay out diffs between CCN/NDN, or are authors making recos? Are you recommending that this be adopted as the unifying approach? How to understand the rest of the work being presented? A: Want to make sure the protocol definition is flexible enough. [Dirk]: at this stage different people are bringing reports on the status of their implementations. My understanding: this is their perspective on the packet formats. Forwarding Target Pointer (aka locator). Allow Interest Forwarding to operate on something other than the interest name proper, which remains in the packet. Supports mobility a la Kite, late-binding,. FT flag plus forwarding header. Header compression - hooks for header compression - ask downstream node to allow use of "name abbreviations". [Nacho]: agree, it's a per-link thing. Caching as a service: Introduce packet processing complexity where it is more useful. Q: Ralph: is there more to it than this? A: no Shareable vs. non-shareable. non-share can be on fast path without PIT/CS processing. Optional Header TLV. Don't have to use cache. [Nacho]: cacheable/non is not the same as shareable/non. Might want to cache, e.g., upstream from a lossy link. Selectors - optional feature. Implications for PIT design. Should be a feature that can be optionally enabled. Q [Nacho]: if traffic with the option goes through a node that doesn't understand it, what happens? A: like IP today, just ignore it. [Nacho]: we proposed a selector protocol that runs on top of CCN that works like this. Context handling - Summary Q [Nacho]: The only thing you discussed that wasn't optional was the TLV, right? A: right. [Nacho]: we are in agreement with others that static format is the way to go. Q [GQ, to Nacho]: why is 64K the magic number? [Nacho]: unlike the 32 bits in IP, it doesn't impose a fundamental limit. It imposes a unit size; the only question is whether the overhead it imposes is too big. ================================================================ QoE in ICN - Damien Saucez - http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-3.pdf Just discussion now; to decide if it's an important topic. Question: For a given infrastructure, woudl the QoE be better, equal or worse with ICN than IP. Def' (ITU): QoE = overall acceptability of application or service as subjectively experienced by the user. Objective part = QoS; Subjective part - nothing to do. So: focus on objective measures. 3 Main factors: i) Service factor = how to design caching and routing to preserve or improve QoE? (e.g., changing source from one chunk to another may cause variability). People may be more influenced by variation than by quality itself. ii) Transport factor = how to design the transport mechanisms (e.g., congestion control) in ICN context to preserve or improve QoE? (e.g., caching may have negative effect on completion time of least popular contents. Consider big popular and small unpopular file requested at same time. Big file served from cache, takes more BW than small file. iii) Application factor = how to design applications to preserve or improve QoE? QoS = characteristics of service that bear on its ability to satisfy stated and implied needs of the user. Q [GQ]: What is the "QoE Model"? A: ITU takes people, puts them in a room, measures their "happiness". [Dirk]: fear we are re-inventing problems and labeling them "ICN problems". A: Don't think there is really anything new here, but we need to take into account the user experience. In some cases it may be better, on some worse, but we need to take into account the user. Need to be able to say "if you do it this way, the result will be this". Q [Ken]: Can you really say anything aboout QoE in isolation? Caching example that hurts the less popular object has an assumption of fairness. There will always be a context... and the answer will depend on it. A: Yes, there is fairness question but it's not all about fairness. [Dirk]: keep discussion going on the mailing list. ================================================================ Network API for ICN - Cinyoung Hur - https://tools.ietf.org/html/draft-hur-icnrg-abstracted-network-api-01 - http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-4.pdf API = language spoken by application. Well-designed API is important to adoption of ICN. Network Independent Model on top, Network Specific Model below. Intent modeling: separates concerns vertically. E.g., voice call requires security and QoS. Mechanisms: IPSec + jitter control. Loosely-coupled modeling - separates concerns horizontally. E.g., get(), retrieves data regardless of protocol. Prototype of Abstracted Network API: IPlug and DSocket. Upper layer: Bind - identification of application Plug-in and Plug-out: dynamic association between application and network (DSocket)? Q [Nacho]: do you somehow in your API detect where the content is, to go and get it? A: Yes. didn't show it. Monitor or mgr who can provide... [Nacho]: but application is trying to provide or consume. For consuming, what is the info you give the API, and how does the stack figure out how to get the content? TCP/IP, etc. A: [note-taker could not follow...] [Nacho]: Side note: Stack Evolution will be discussed tonight in tech plenary. May be relevant to this. ================================================================ Demo: Web of trust in ICN - Jan Seedorf - https://tools.ietf.org/html/draft-seedorf-icn-wot-selfcertifying-00 - http://www.ietf.org/proceedings/91/slides/slides-91-icnrg-2.ppt Part of GreenICN project. Verifying key-ID binding based on WoT. Uses a double-sided BFS algorithm to find cert chains between initiator of the request and the publisher of the content. Use "trust metrics" to assess the graph/chain. E.g., how many paths shorter than a given length. Current PGP web only has about 50K users. (!) Developed a methodology to synthesize large-scale WoT graphs, maintaining several key graph-theoretic props. Want to see how this scales, depending on trust metric, size of WoT, etc.