Minutes for ICNRG at interim-2015-icnrg-2
minutes-interim-2015-icnrg-2-1
| Meeting Minutes | Information-Centric Networking (icnrg) RG | |
|---|---|---|
| Date and time | 2015-03-22 07:00 | |
| Title | Minutes for ICNRG at interim-2015-icnrg-2 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2015-03-24 |
minutes-interim-2015-icnrg-2-1
ICNRG Interim meeting Dallas, TX, March 22, 2015 ¶ Time: Sunday, March 22, 2015, 09:00 -- 17:00 Location: Fairmont Hotel, Room: Royal Supported by PARC and Cisco Sytems Agenda 9.00-10.30 Morning 1 - Welcome, agenda bashing - Hop-by-hop fragmentation proposal - Nacho Solis and Christian Tschudin - Congestion Control in CCN/NDN - Ryota Ohnishi 11.00-12.30 Morning 2 - An improved PIT aggregation scheme - Nacho Solis - Bloom Filter-based Flat Name Resolution System (draft-hong-icnrg-bloomfilterbased-name-resolution)- Jungha Hong - Name segment index performance implications (Comparing the plain 2+2 format vs ALU proposal)l - Nacho Solis 13.30-15.00 Afternoon 1 - ICN communication privacy - Mark Stapp - Authenticated denial - Mark Stapp - ICN Packet Format Design Requirements -- Alex Afanasyev 15.30-17.00 Afternoon 2 - Initial Next steps discussion: What should ICNRG focus on? Which key issues are we missing? - CCN/NDN Protocol Wire Format and Functionality Considerations(draft-ravi-ccn-forwarding-label-00) - Ravi Ravindran - CCN packet format update (semantics, messaging, etc) ---------------------------------------------------------------------- Morning 1 note taker: Dirk Kutscher Welcome, agenda bashing Hop-by-hop fragmentation proposal - Nacho Solis and Christian Tschudin - Marco Mosko presenting - hop-by-hop: earlier discussions with Christian Tschudin - Multilink PPP inspired - Q Ken: channel order? + A: in-order channel, minimum requirements on receiver - ICN approach: protocol ID (for different fragmentation implementations) - additional (idle) control frames are possible (e.g., for link-up detection) - peer concept: IP socket etc. -- seq numbers per peer - variable len seq nums - other extensions beiing looked into (link quality measurements for idle frames etc.) - applicability to NDNLP being investigated - Q Ravi: negotiation? + A: no link neg protocol required, want to specify for CCN, not yet - Q Ken: seq num wrapping? + A: yes, they wrap - Q Dirk: intended applicablity? general Layer 2 for CCN (or ICN)? + A: yes + A: experimenting with different implementation and options Congestion Control in CCN/NDN - Ryota Ohnishi - focus on RTT fairness - use case: RT video streaming - targets: + low latency + best available video quality - approach: receiver-driven CC + lack of RTT fairness in AIMD may be a problem + ndnsim-based simulation with bottleneck scenario - Q Nacho: what are running as a CC? + A: ndnsim with our own scheme - Panasonic approach to CC + RTT-based bw estimation + Timer-based interest rate control - simulation results show better fairness - current work + implementation on NDNVideo + implementation on NDNRTC + submitting paper to IEICE - Q Dave: effect of short-term caching in routers and noise that this generates? + A: currently trying to improve algorithm for that + A Lixia: here only one consumer per stream -- so effect does not become visible - Q Dimitri: link rate between client and bridge varied? + A: not in the simulation, but it should be varied in more realistic settings - Q Dimitri: asynchronous information exchange and its effects? (cross flows) + A: not here - Q Dimitri: what is actually the baseline scenario? can you document? + A: yes - Q: Nacho: how is this different from what happens in IP today? RTT fairness sounds odd. + A: biggest difference is existence of in-network caches - Q Nacho: not clear how caching effects system behavior + A: more detailed eval is planned - Q: Dave: queuing dicipline on router + A: drop-tail - Q Dave: OK, but drop is seriously creating RTT-unfairness -- better try AQM + A: yes - Q Marc: how much tail-dropping observed? + A: unclear - Q Nacho: how much caching? + A: no caching PIT aggregation - Marc Mosko, Nacho Solis, J.J. Garcia-Luna-Aceves - Marc presenting - pretty small window for lively data exchanges - interest loss (main motivation for this work) - probing for new content - Q Dave: flash crowd use case + A: time window for aggregation could still be small - previous CCN approach: aggregrate up to Interest life time,router is doing pro-active re-sends on its own - NFD approach: aggregate interests, depending on application-defined interest life-time - fixed MIN_RETRAINSMISSION_INTERVAL: 100ms -edge aggregation is another approach documented in literature - DHT approach:different interest timeouts, no retransmission - RTT strategies have a few shortcomings - estimation difficult - state complexity - throttling retransmissions - can create huge delay - NACK could be sent - Q Dave: why do you say that? + A: NACK consuming resources, too. benefit is going to be small - Q Börje: does not make sense in flash crowd scenario + A: you would have to send N NACKs back - approach: distinguisn between re-transmission and interests from different previous hops - Q Dave:how does this interact with Congestion Fairness if next hop is bottleneck? + A: we wanted to decouple RTX timer from interest-lifetime aggregation - Q Dave: architecture question: client or object fairness? + A: have not talked about NACKs - Q Dave: NACKs are just an optimization technique - clients can use subscription times (no need to do RTT estimates) - forwarders do not need RTT estimates - forwarders could use LRU to evict old PIT entries - much greater flow isolation than previous PIT aggregation schemes - Q Alex: agressive/malicous creation of PIT entries? + A: incorrect implementation exist today,too - Q Dave: have to look into interactions with congestion control and fairness - A: retransmissions can indeed be aggressive - Q Dave: different for client and object fairness - Q lixia: important question: how should fairness be measured + A: yes, and we assumed some AIMD scheme - Q Lixia: NDNLP design goal: best effort loss recovery -- for quick recovery between adjacent nodes - Q Dave: can we come up with a good analytical model to figure out good balance between extremes (X.25 and no-hop-by-hop mechanisms) - Q Dave: undetected loss rates assumptions and corresponding recovery mechanisms - Q Lixia: good topic for ICNRG - Marc: multi-layer ARQ - Q Dave: other point in design space than multi-layer ARQ: rather: certain bound on undetected loss rates - Q Alex: different between local and global system recovery - Q Dave: that's why you want to detangle error detection from recovery ---------------------------------------------------------------------- Morning 2 note taker: Chris Wood Bloom Filter-based Flat Name Resolution System (draft-hong-icnrg-bloomfilterbased-name-resolution)- Jungha Hong, Woojik Chun, Heeyoung Jung - acronym: B-NRS - goal: return corresponding locator (e.g., content name) for a given name - key operations: + name registration + locator updates + locator lookup - BFs used to aggregate flat names and forward request names to the appropriate party (parent, peer) - Q Borje: how it is decided how peers are established? + A: policy determines peering relationship, possibly driven/influenced by "performance" needs - Q Borje: can a node have two parents? + A: tree topology imposes a single parent, but the notion of parents extends this to include multiple parents - Lookup requests are propagated up the tree based on contents in bloom filters, replies take the reverse path down the tree - B-NRS main requirements: + scalability: DHT is a good/popular approach for implementing the hierarchical structure of B-NRS (wtih bloom filters) - problem: lookup requests may propagate along non-shortest path - problem: binding must be stored in a server that is distinctly not the owner + fast resolution - use peers as shortcuts through the tree - be smart about name resigration in servers to exploit locality + fast update - important for mobile nodes with changing locations + resilience (w.r.t. failures) + security - DoS attacks --> need to authenticate - use self-certifying names for quick message authentication - no mention of privacy concerns - BFs are periodically refreshed to keep false positive rate low + frequency of refresh is policy-driven + use shadow memory (ping pong) when rebuilding the BF - plan for GPU-assisted implementation for high parallelism in the BF lookup + the number of indicdent server connections determines the number of BFs that need to be indexed - p children and q peers -> (p + q + 1) BFs - Q Borje: What's the status of your implementation? + A: in progress, hope to have results in July - Q: what kind of error rates do you need to make this system usable? + A: not answered - Q Dave: What's the advantage of the tree+peer topology instead of a DAG (directed acyclic graph) -- note that peering links cannot induce loops (for correctness reasons) + A: just the first one picked - Q Dave: who is "the operator". The Internet has no operator. + A: people can spawn domains (set of one or more servers) and then connect with other servers to form the tree -- the operator is the owner of that particular domain Name segment index performance implications (Comparing the plain 2+2 format vs ALU proposal)l - Marc Mosko - rebuttal to ALU Cambridge presentation about name hashing performance - only evaluation the time to hash name components + ALU included FIB lookup times into their estimates - main result: negligible difference between 2+2 and NDN TLV style names - ALU hashing techniques + "all-in-one" - full name, and then backpedalling + "multiple" hashes - one component at a time - evaluation details: + name types: ALU, 2+2, NDN + hash funciton: CRC32C (not a hash function) - cycle benchmarks include all cycles, even stalls due to memory accesses - Results: + 12Bx5: little difference in average cycle counts, ~5 cycles -> negligible - different observations than what ALU presented + 10B x 6: - ALU scheme prevailed - difference between 2+2/NDN and ALU is unclear + N(7.3, 11.7)B x 8: virtually no difference between either scheme - Conclusion: + for short names, quantization differences due to 8, 4, 2, 1 CRC32C operations + for random N(7.3, 11.7), no clear difference between name types + for "all-at-once" strategy, very little difference in doing everything at once - Q Dave: there are other lookup schemes besides hashing (e.g., tries), can someone repeat this encoding analysis assuming those techniques? - Q Dave: CRC32C is not a safe hashing function -- this experiment needs to be done with appropriate hashing function (e.g., Siphash, CityHash) + A: CRC32C is "okay" for small names. Maybe different hash functions need to be used for larger names. Python uses a type of hybrid approach with CRC32C+Siphash for hash table lookup - Q Mark: Are names assumed to be in cache lines? + A: payloads of names came from separate memory, but there exists a linear array that stores all of the name data (possibly crossing cache line boundaries) - Q Mark: can you share the random name generation program? We (as a community) could use this a reference for experimentation. + A: intention is to release C code for generating names. Will try to release Python scripts that help generate names. ---------------------------------------------------------------------- Afternoon 1: note taker: Laura Hill ICN communication privacy - Mark Stapp - open question: “there should be no communicated that is not encrypted” - in ICN world this is a proposal that hasn’t had much consideration so far - A whole class of apps that we couldn’t do that way now. - Walk through some info and ideas on topic - don’t have strong proposal yet. - Parity with emerging IP consensus - bottom bullet - most important - Forward secrecy challenging right now. Should be aiming a little higher - see IP world - We don’t need a single authentication approach - having a well known public key is all you need is contradictory. if everyone knows your key no longer private - if they get at your key all comms become available to them - IP: use short lived symmetric keys that are derived from other places. so even they broke master cryptography, could only expose a limited amount of your comm. we should be in same boat. offer other choices beaides public key that I carry around - Object security: + A bunch of content, encrypt with keys, stuck in caches … but stuff itself is reversible encrypted + If I had used ephemeral keys, not clear how that fits in. distributing those into caches doesn’t mean much because lifetime is short. In order to generate ephemeral key material, c and s have to have bidirectional exchange. - Session security approach + not clear how ensure all Interest messages would end up at same producer node that I’ve arranged key exchange with. + The fact that we use names exposing something. new IP working group now studying schemes to protect DNS interactions so not easy to correlate name requests… + need to understand how much info is given away by using names, and how can we use them to give away less info - TLS + most of us use / built into browsers … + not clear we want to start from position that binding together source host, dest host and binding scheme and crypto material is best starting point. + TCPcrypt - opportunistic. Allow any client with TCPcrypt capable client and destination have ephemerally key prat TCP channel. No requirement to bind to cert chain, or ? + In TLS - too many choices ; tcpcrypt made more limited choices - easier + server does the end crippling - typically cheaper - Translation to NDN - what could you do that would allow a similar negotiation? + Try to include info from TCPCrypt exchange into 2 CO and 2 Interests + help you derive the keys - not the hard part - Q: when you get to multiple producers, that part gets harder + A: Agreed; But that should be in the conversation. If having the multi-path thing means you can never do your banking, thats not good. Whatever choices are getting made, they can be made consistently on some basis for people who need that kind of service. (I think should be the default. We don’t support any combination that isn’t encrypted. Must establish private communication channel - Q KC - pushing to link layer? Still have to have something end to end + A: Still need to have something end to end but I wonder about the layer below that also - KC: doesn’t protect against some of the things that have been done + A: But not doing it all, relying on systems like broadcast that rely on open comm on a shared link must be stamped out. - As we think about apps and APIs - how do they learn about what is happening nd are they willing to continue in the network they find themselves. Part of legacy in IP world, its hard tfor apps o learn whats happening in your stack and whats going wrong. Not enough discussion on private communication and we should be leading there - not following IP world (as we are) ---------------------------------------------------------------------- Authenticated denial - Mark Stapp - If someone sends routed to you you an Interest and the name doesn’t exist what do you do? can’t just ignore. - Some suggest just signed name to client data and send back - An awareness that these distributed attacks are very real - part of day to day level in any CDN. In IP world, good means of communicating whats going on hasn’t evolved. Only firewalls, and service providers can see. how do you know that something bad is happening in someone else’s network. - QLZ: Are you talking about DDOS situation for whole slides? + A: different bullets discussing different situations. Only last bullet was specifically about DDOS - LZ: Work has been done about DDOS + A: DDOS people will be able to move the %Inetrest satisfaction. - Objectves: + start to explore different approaches to authenticated denial of existence + Simple: send back authenticated message with name gap - prove it doesn’t exist. + Could we have something that is catchable? Offers a vector to help resist distributed attacks + Not happy about exposing real names in this scheme + (DNS sec) + Diff mech - generate hashes, sort them and show that gap - virtual name space related to real name space in one direction. - still have cachablity but can’t see the “real” names. Difficult for someone to convert two hash values to into two real names if they cared. performing these hashes is not as expensive as doing real crypto - client supplied name hash: + client could send you the hash of the name so producer doesn’t have to do the work. - Q (Alex M): would only solve first problem - it would not help with DDOS + A: Idea here wasn’t that you had no other way to signal, but just something yo could do on behalf of the good client. For DDOs you’d also need another choice to be available. Producers decision to decide which mechanism to start using. May decide at some point its worth it to push some info out to help downstream nodes to help him resist things only he can perceive (DDOS) - Could add semantics to various name prefixes etc - Q BO: Push info downstream, things may start to exist. + A up to you to manage lifetime. Typically slow changing things like video files - Q BO: when you use caches hard to predict what caches exist + A: you’re the producer you know. Don’t use something and claim it will be valid in a cache for two days if it will change in a second - Q BO: you have no way of knowing - A: The somebody doing the publishing is the somebody doing the hashing - you should keep your hashing and timelines in line. If you have content changing dynamically there are some approaches that are not useful. Not useful if you can’t predict. If your content is static there is benefit in providing denial information to the caches. Your Skype is not the good DDOS target, its the Skype directory that will be the target. your apps producing dynamic things aren’t the best target + A Once netflix encodes movie its done, it doesn’t change for years. - Q BO: Any new thing (like a new episode) may get added into the hash range + A: should manage where hashing starts and ends so you can manage it to a prefix. Manifest type things are best for that kind of content. As you download manifest may as well get denial info at the same time. i.e. if you have catalog of names - could say these are the only names that exist below this point in the tree. Has high caching value (directory for content) also offers you a bunch of denial info. dedicated denial manifest - Build a manifest - there is a prefix here but here are all the hashes I actually have. Don’t ask downstream to cache a record for every pair of gaps. Instead you send something that says you’re having a problem in a space, if you have the time check some of your requests in this prefix and see if they are real -if they are the problem you can stop it there. - Next steps and questions: + All the things in the world that have names have problems right now. Nobody is interested in attacking us right now (yet) - Q(MM) Could you combine the two presentations? How would authenticated denial work if everything is encrypted + A: I think its true but I don’t have a good answer yet. Right now, commercial streamed content. Its not the real bulky content. 99.x% actual bytes are encruypted (DRM) - its the side channel that the authenticated user uses to get updated keys every few seconds to be able to decode. Thats the bit we don’t have the mechanism for yet. If that continues to be the case, there may still be value for something like that this. - Q(LZ) Should the denial info be cached? Thomas ? wrote paper 1988 about what he learned from DNS. Original design did not have the caching. 2) should use the hash of the gaps vs manifest. manifest would be better solution for the consideration about the sides. Not just for one denial of service. + A. Agreed. Manifests are important. need to discuss. - Q (DK) - thought about how much more painful with dynamic names? + A: Can’t precompute thing as readily. On he other hand, many diff adaptive bit rate systems do dynamic names as well and they do manifests. If you have the right kind of metadata - Q(DO) Don’t update the manifest that frequently. Microsoft - embed the name of the next thing its going toprovude in the data of thing they produce. Client is told the name of the next + A: client gets told next thing in current representation - DO: that has challenges because we want o integrity protect that. Interesting convoluted dependencies when you sign vs when things appear. + A: In dash standard - dash standard gives algorithm for predicting names. Only have to reissue manifest when name scheme in next section changes. int tradeoff - they do that dso don’t have to keep creating manifests and sign. + A: If you have rule for valid names, could make clear that names that don’t match aren’t valid - Q(DO): accommodate clients who have been give predictions, help them distinguish good predictions from attackers. If its a real time scheme can’t get it on demand. Need to think about number of time time scales: long (bibliographic), intermediate (changing predictably); very raapid - things getting scattered all over the place. - Q(DO) - same intuition as Lixia - manifests will work well here. If such an interest arrive at a producer, what should the producer do? If it has to manufacture a valid signed object, back to where you started. - Q(LZ): If we make names more predictable can help facilitate solutions for many problems. - Q(DO) - can learn from the DASH standard actually communications from producer to client what name algorithm should be as opposed to client trying to figure it out. deterministic algorithm embedded in the manifest to help client. - Q(LZ): when will the scheme be communicated to users? + DO - every time they fetch a manifest. If you design it right, manifests are recursive - Alex m: another challenge routers need to infer whether or not name exists. If you go with manifests, - DO - why would routers need to understand? - LZ: if honest clients understand naming scheme, then bad names can only be generated by bad guys. - DO Mark focused on computational attacks against producer DDOS. - MS - only way to handle the bandwidth attack, need to ensure the messages don’t all converge on the producer. - DO - First talk covered all encrypted. If Manifests encrypted, would mean routers would need to decrypt messages. - MM - partial encyrption - exposing to intermediaries enough to help ward off attacks but not exposing confidentiality of the private parts - MS: if someone sets up secure channel with me and then DDOS me, then producer will withdraw. - MM -good thing to think about alternatives to negatively acknowledge individual with a signature. Initial Next steps discussion: What should ICNRG focus on? Which key issues are we missing? - (DP) Challenges doc: How do we deal with information specific metrics? What category? Put into research challenges ? - DO: Question for the RG - smooth has to be meet two criteria for it to be useful for us. A body of researchers actively working on topic. We have this (JJ, Giovanna, Northeastern). Need to decide how much of it to bring in to this group - what value do we have - a stronger valuation function on research, or tuning research into first phase of protocol… - Is there a new class of metrics that would help with routing protocols? - MM - content discovery, nearest replica routing - loots other things become routing concerns. Having a clearer framework in how to describe some of what you’re seeing would help a lot. - DP need 10 page document with design goals and objectives. - DK: Manifests topic - DP- specificaiton for experimentation. baseline for forwarding architecture. can use specification as a starting point in order to have something that is progressing. would help in order to have different groups working together. - What are we close to “finishing?” What should we keep working on? - LW: NDN takes an application driven approach. Specific application scenarios to understand how to make NDN reliable for their requirements. This group could consider using that approach. - DO: have some documents that are trying to do this. - DK: Second that. in addition to apps like video streaming, lots of work in broader IETF contects like multi interface gateways, caching for them et. Could make some nice prototypes and bring to group. Based on practical experience. - LZ: Effort on requirements doc is great, who for App developers or network engineers? - MS: App people live in a world where everyone is well behaved, and 10 packets/ sec is great… Some negative aspects of that because people have done ICN over TCP and it has stopped people from understanding fragmentation, flow control etc - other fundamental pieces. If you think you’re studying ICN and really just end up looking at your stack, you miss exaining work at scale, how to provide services, need flexibility and sensible congestion control. These are hard problems and should be front and center. - LZ: What applications need - they know better than us. - DO: There is a imddle ground in between building apps and making network work well. How do you run app x over ICN? And when you approach from that direction you discover that if you design the app as you would have for TCP/IP you end up putting requirements on ICN that drive it to make same restrictions; however, by talking to app people we can understand deep characteristics of application we have to capture vs what are the shallow characteristics that assume running over todays network infrastructure. Need to rethink and recast apps that match better to ICN. If have trouble doing that it may expose gaps or bad tradeoffs in ICN protocol design. - GS: introducing for people right now - name choices - taxonomy will have impact on app writers. Need to do something that enables app writers to participate - KC: how you structure the namespace is an important question. Apps have to drive that. What does the network have to know about the namespace? Like trust structures. How does the router know what names to look for and keys to get etc. Namespace - right question is not how do I run app x over ICN but how do I design app x to leverage ICN. - Alex A: What are the design patterns available from ICN, CCN, NDN? What can apps take from this collection. - BO- what apps are just too hard to build on current app infrastructure that would be easier on ICN? - Marie-jose montpetit: multi source multi destination video sessions. Adding DRM even worse (different countries, diff DRM regs). If you could name what you want, and caching etc helps you get that content. Currently very hard to do on current internet. TAPS session tomorrow will present. Paper with cedric a few years ago started thinking about things like that. Application people are working very hard to understand the transport - Ravi: Need more concentrated effort - focus group - on some subjects? ---------------------------------------------------------------------- Afternoon 2: note taker: Ken Calvert ICN Packet Format Design Requirements - Alex Afanasyev Talking about their (NDN folks') draft... Goal is to identify gen'l reqs for packet format, priority among them, tradeoffs. Learn & apply lessons from the past. Basic requirements... 1. Universality/Elasticity: able to support diversity above and below from constrained IoT envs to ultra high speed network channels. Lesson: 6LoWPAN needed to do IPv6 in IoT. 2. Flexibility & Flexibility. Still in research stage! Need to keep it flexible. IETF Lesson: TLV offers these properties. 3. Packet Processing Efficiency. This conflicts w/other requirements! Variable length fields -> higher processing cost. But we are designing for the future; new approaches to hard problems will be discovered over time. 4. Auditability/Robust Design. Unique Type code for each element enables packet audit w/o tracking semantics. Downside: requires co-ordination. Packet Format Elements: Info-centric, transport elements to assist multi-hop retrieval. ICN uses application-level info (viz: name) at network level. Name, constraints, payload, security context, sec context constraints - these are enough to enable endpoints to communicate. Add'l info required for wide-area. E.g., s/t to kill looping packets. Problem reporting between neighbor nodes. (NACK) AS-level traffic engineering/QoS support. Frag/reass. These types of info are not related to the information itself. Q [Mark S]: Are you saying the application doesn't want to know that a NACK was received? Lixia: two kinds of NAK: Info (application)-level and network/transfer level. Dave O: is this list exhaustive? Alex: no. What's missing? Dave O: cacheability hints, lifetime constraints, ... The point: how to encode these different kinds of info in the packet? One spec or two? (Or Multiple.) Tradeoffs: single spec: easier to implement, but may require inclusion of unnecessary elements. Separate specs give maximum flexibility and allow separate evolution of the the ICN and transport functions. Dave O: Another angle: semantics vs. encoding. Sometimes it's not clear which we are arguing about. Ex: semantics of address in IPv4. Another example: AS numbers in BGP were defined to be 16-bit integers. Conflated encoding and semantics. Alex: have we conflated these things? Mark S: somewhat. E.g.: There has been discussion about whether multi-gigabyte objects ever need to be encoded. There should be a clear semantic statement about what sizes are "reasonable". Then it can be encoded in an efficient way. Lixia: But examples from history show that what we think is "reasonable" is sometimes wrong. Nacho: But you are focusing on the cases where we were wrong - there are lots of cases where folks got it right. Dave O: But also cases where we have sacrificed a lot to get flexibility we never needed or used. Lixia: Remember when TCP was so slow b/c of bad implementations. Dave Clark wrote a paper explaining how it could go faster. Mark S: I wish we were talking about flow control, congestion control, and other important things... Dmitri: Look at RFC3168 about adding ECN to TCP - it says if you don't consider extending from the beginning, you're in a lot of trouble. We need to look at the class of processing expected for those messages. Some are sender-intensive, some receiver-intensive, some need to be processed in the middle. Dave O: Want to revisit the point about concentrating on cases where we made mistakes. There are other cases where we decided to limit ourselves didn't turn out to be a problem: protocol numbers, version numbers. OTOH, premature optimization can kill you; there are places where limiting turned out to be a bad idea. Lixia: agree. for the things we didn't get right, we should understand why. Example: version numbers. Why didn't we run out? B/c changing version number is impossible. :-) Mark M: in the written draft you had a section on reserving type space for different packet types... Alex/Lixia: those are details, not the main point of the draft. Nacho: We require inter-operability between endpoints. You said "minimize the number of required fields". So have to make some choices that we agree on. There is slightly more than just that "name" is the only required field. Example: why would nonces or something be required - not needed for regular comm. If you have a common global type-space, you require co-ordination -- if you don't, no interop. Also: You are trying to divide the Info-centric & forwarding parts cleanly. Name is both. There will be lots of other things in between. Georgios: related to previous discussion about choices: Business opportunities are important, in addition to right & wrong choices from history. Dirk: What does that actually mean? Flexibility or time-to-market? Georgios: Could be both or either one. Time to market is important, but flexibility is more related to long-term thinking. Lixia: This is what we "identified" - it is not supposed to be a complete list. Need everyone in RG to help extend that. Main point was that the info-centric elements are not the only things. Tried to do a classification. Just saying that or the current experimentation this is what we identified as minimal. Spirit is to say we need to be very careful about adding things. Lots of back-and-forth about what's required and not. Experimentation will teach us how our intuition can be wrong. Dave O: Example typed name components. Has to do w/ the ICN part, probably doesn't affect the transport part at all. But other parts, e.g., whether you have avoid aliasing/multiple encodings, do affect forwarding. Instead of saying "it's in both buckets", we need to dis-entangle these things. Mark M: the term "packet" becomes problematic. Are we targetting a layer 4 entity? 3? 3+convergence? That kind of distinction has caused problems in the past. Would be good to talk about where this format can be injected...what do you need below it? Mark S: if "forwarding" class of info includes PIT and CS, there may be even more ambiguity. Devices doing forwarding are doing a lot more other things than routers in IP. May make this not productive to try to draw this line. Lixia: We are just trying to understand... Mark S: We won't until we get packets flowing. Dave O: I think what is being said is that we'd like to have some things that network elements are NOT to look at -- try to ensure that concerns continue to be separated, so they don't get ossified. Point is not to talk about which words get written in which document. Mark S: My point is just that this distinction is extremely unclear. Mark M: What about flow control? We have a concept of taking a large user object and segmenting it into chunks, each individually named, and doing flow control to bring those in... [so that relates to the name...] Lixia: Might be a good ICNRG research topic. [Describes cong ctrl approaches...] Mark M: that layer is going into the ICN concern bucket? Lixia: we are looking at the format - what do you put into the packet and not? Nacho: Agree with Mark S, it gets pretty tricky to look at the middle area, which is probably the biggest part. Applications might not care about fragmentation. Nodes may not care about what signing algorithm. Everything else between those is blurry. What we should be thinking about what goes inside the security envelope and outside it. While we are defining what goes into the fields, it's really hard. Layering is not clean like in IP. Dave O: You mean layering's not useful as a structuring principle? Mark S: Just not clear that it's that clean. --------------------------------------------------------- CCN/NDN Wire Protocol Format and Functionality Considerations Ravi Ravindran Last meeting, brought up several features. This time: focus on forwarding-label. Look for add'l drafts... Fwding label = name other than the one in the internet. Can be modified in the network, to handle mobility, ... Different from "Link" proposed in NDN. Useful in several scenarios, routing scalability. Fast forwarding interests... Depending on the use case scenario, implications for PIT/CS/FIB operation is different. Routers needn't trust application-inserted labels. Reg, Resolution process needs to be secure. This draft considers within a single administrative domain. Extend by federation... Optional Header. Wire format for CCNx1.0. Type is "Locator-Name". Dave O: is this intended to support stacks, a la MPLS? Nacho: Just trying to do the simple thing first. [Ravi continues] If FL is present, prefer it for FIB lookup. During FIB lookup, check if locator-name exact-matches service name. If yes, related service logic re-resolves the Interest name to another locator-name, or decide to remove it and subject FIB processing based on the Inerent name. Discussion about whether FL is subject to LPM? [Describes PIT processing... see slides. Mitigates cache poisoning problem...] Dave O: you have redefined path symmetry on the routing labels? That's a deep change. Ravi: that's not the intent. Dave O: You should not be looking at anything in the Routing Label on the data packet. This seems to overload two orthogonal things: (i) how data packet is forwarded... (ii) whether you believe a data packet coming back b/c it includes some things in the RL that an attacker couldn't do. [Nacho attempts to clarify...] [Discussion about whether this is a good idea.] Dave O: I need to go off and think about this. "I'm nervous." Multi-domain Scenario: whether FL is removed/replaced depends on trust relationship. Mark S: So, if I strip FLs at my ingress b/c I don't trust them, but I still have to put them back on when I forward? A: Yes. Mark S: "We need things in packets to support this cool thing." Dave O: MPLS was a separate layer because it wasn't invented until after we discovered that source routing didn't work in IP. Mark S: problem is that this is an obligation on EVERYONE, and if somebody doesn't play, it breaks. Dave O: well, sort of. You could impose the req on your neighbor that they have to strip the FL before they forward to you if they want things to work. Describes FIB processing, Caching, PIT processing. Describes using FL for Producer Mobility... Mark M: combining resolution process with FL is a bad idea. Dave O: please separate into a different draft. Security Threats: Injecting incorrect mapping or manipulating mapping... [See slides...] Dave O: Suggestion for people with proposals like this: Talk to John Byers and Dave Anderson and see why you would want to do as opposed to running NDN over XIA. This is looks like it is implementing a lot of what you would get by running over XIA. Need to convince us that this level of complexity competes well with what you get by running on top of XIA. Nacho: What level of complexity? Dave O: How you deal with multiple labels, find the resolution service (securely), ... Not advocating XIA, but you are walking really far down that path. Dirk: would be good to be aware of the differences between XIA and this. Dave: Name Resolution = you can't forward the packet until you get the answer; you have to hold it. Rendezvous point = anything else. Q: [Dmitri] What defines the forwarding equivalence class here? How do you map the name into the label? I missed that. Ravi: Mobility was the one use case we looked at.