9.00-10.30

• Welcome, Note Well, Agenda bashing, NOTES TAKERS!

• Solving the congestion problem using ICN principles - Ioannis Psaras

• Idea: in-net caching from a different angle; rather to alleviate congestion.

• "In-network Resource Pooling".

• Proposal: pooling sub-paths, taking advantage of caches to deal with uncertainty

• push traffic as fast & as far as possible.  Exploit all available subpaths, making decisions in a hop-by-hop manner.

• (Very) Initial results: more thruput using this technique, more than ECMP.

• Lots of open issues!  But here is an opportunity to deal with congestion at the network layer.

• Q[GQ]:What is definition of "path" here? In IP it is clear, in ICN not so clear.  Is path per-receiver?  A: We didn't design this for any particular ICN architecture, though we think it could be made to work.  Doesn't work if you need symmetric paths, but we believe we have ways to deal with that.

• Q[Mark S]: we are fans of in-network cng ctl.  This seems like it is sender-driven, but ICN architectures are mostly receiver-driven.  How are we to evaluate this?   A: might apply to unsolicited data.  Q: but then you have DoS opportunity. A: we haven't dealt with that yet.

• Q[Börje]: Could we look at this as a way to improve current Internet via ICN principles?  A: yes.

• Q[Dirk T]: Suggest looking at how to do hop-by-hop rate control for multicast.

• Information resilience in disrupted Information-Centric Networks - Vasilis Sourlas

• Goal: investigate potential of in-network caching to prolong info/content lifetime and serve interests when partition occurs and origin server not available

• Introduce "Satisfied Interest Table" as "bread crumbs" for following data.  Redirect interests to other clients who have requested when network is partitioned.

• Evaluation via analysis and simulation.  Conclusion: flooding and SIT both have advantages and disadvantages.

• Q[Mark Mosko]: Is there a way for the client to opt out?  Might not want tohave to deal with these interests, esp. for mobile devices.  A: guess so, but in a disaster we assume everybody is willing to thelp.

• Q[Mark Stapp, "privacy scold"]: What kind of data has no privacy or access control constraints, which seems required for this to work?  A: "tsunami coming".  Q: so this will be pushed? A: Yes.

• Q[Jan]: also looking at comm among authorities that help people. But aren't privacy and caching orthogonal?  A[Mark S]: No!  That's my point, people keep talking about caching but ignoring the privacy implications.  I am going to keep complaining about this.

• Q[Alfredo Grieco] What about SIT scalability?   Did you consider this? A: yes, future work includes scope based content prioritization scheme.

• Policy-driven cross domain name resolution - Jianping Wang

• Flexible generic namespace management system, suitable for use with any Future Internet Architecture

• Goal: unify various existing namespaces in a generic framework with open APIs.

• Examples of interoperability

• Q[Dirk K]: One good thing about Internet today is the single namespace.  Why do you want to introduce all these others?  A: Might want something different/specialized in local areas.  Want to minimize management overhead.

• Q[Jeff]: In example with NDN-MobilityFirst translation, is it your idea that packets will be translated from one format to the other?  If so, what happens to signature?  A: One scenario did not deal with translation, rather there were NDN-only and MF-only paths to the destination, each packet followed one.  Haven't really considered translation.

• Q[Ralph Droms]: We can't even translate between IPv4 and v6 namespaces, how will this really work?  If you're not doing translation, what's the benefit of unified management?  A: we're not focused on translation for now, depends on which protocol is associated with which packets.

• Q[Lixia, Mark Stapp]: FIA architectures are not compatible.  Translation doesn't work.  A: Our proposal is focused on flexibility.  One example is mobility - offload management work from ISPs.

11.00-12.30

• POINT project -IP over ICN, A Better IP? - Dirk Trossen (Max 15 min)

• Hypothesis: The internet itself is the killer app for ICN

• Shows an example of HTTP over ICN

• Mark Stapp: Does this work for HTTPS? A: This example is HTTP. We have solutions for HTTPS in some environments.

• G.Q.: Which ICN protocol? A: Pursuit. Because it has rendezvous, path computation and forwarding.

• Some Results of implementing the Bloom filter based NRS for ICN - Jungha Hong

• Note: These are results for a work in progress.

• Shows results for execution time vs. number of bloom filters, comparing CPU vs. GPU.

• Since a bloom filter does not delete, we plan to implement refresh, but haven't implemented it yet.

• (No time for questions)

• Update to draft-lindgren-icnrg-efficientiot - Applicability and Tradeoffs of ICN for Efficient IoT - Bengt Ahlgren

• Objectives: Explore using ICN for IoT. Support efficient and scalable IoT over ICN, with as little changes to ICN as possible.

• Streams of sensor data: Represent with a name with sequence numbers (similar to live video). The application provides the mapping from sequence numbers to time.

• Dirk Kutscher (during the talk): For finding the current value, can use a manifest file? A: Using a manifest file is similar to the approach using advertised capabilities.

• 2 models to handle actuators:

• Model 1: Represent actuator state by a stream of immutable data, and the actuator requests its new state - More ICN-like but problems with latency.

• Model 2: Actuation is a side-effect of a request to the actuator.

• Dirk Kutscher: Are you aware of the new IRTF Thing to Thing research group? A: Not aware. Dirk: We should look at it and sync with them.

• Q: Definition of latency in a wide sensor network - the client sends a request and waits a long time for the acknowledgement, and maybe never gets it. A: The amout of time to wait could vary for different applications. It has to be combined with probing to get the latest value.

• Mark Stapp: The model suggests that arbitrary clients can communcate across the internet with light switches. But a building would not allow information from the outside internet. There should be room for a desgn where the gateway answers questions, not the sensors. A: In this work we tried to not put constraints on how you designt the IoT network. You can restrict the network, but that's outside the scope of the work. Agreed that in most cases you don't want outside access.

• Dirk Trossen: We can clarify if we divide into issues of information ability and reachability. Gateways are about reachability, not information ability. Also, in your actuation scenario, I'm concerned about your actuator model 1 where the actuator does polling. The latency is too high. A: Agree but we wanted to present all possibilities. Dirk: It might help to present along well-know constraints which the IoT community will expect. Also, there are ICN architectures which directly support push which don't require "side effects" as in your model 2.

• George Polyzos: You're focusing on getting info directly from actuators, not on the info itself which may be provided by one or more sensors. But in ICN we connect to the info, not to a particular sensor. A: We don't deal with providing higher-level data. There are systems that refine the data. We wanted to explore the part below that.

• ICN-IoT challenges - Ravi Ravindran

• Updates to two drafts: challenges and architecture.

• Dirk K: It seems that we have two strains of IoT work. Can we have a dialog to combine efforts? A: Fir the challenges draft, we didn't go into specific solutions as in the other work. For architecture, you have to take the broader view, how to do service discovery, etc. from an ICN perspective. In the architecture draft we discuss middleware components and provide guidance but don't go into a specific implementation. Börje: It would be really useful if you all can discuss during the breaks and come back tomorrow with a plan for a unified presentation from the group. Dirk Kutscher: We'd ike to make a consistent description for a contribution outside the group.

13.30-15.00

• C-DAX project - Michael Menth (Max 15 min)

• Dirk K - You said you implemented using the ICN paradigm?  What did you implement with what software?

• A:  pub sub server implemented. Focus on security and availability and also on getting along with legacy apps. ICN basically because we have topics for the different traffic to get through the system.  Its not a thing like automatic caching as discussed in other projects.

• Discussion on Privacy - Mark Stapp

• Doesn't ICN need parity with emerging IP consensus?  There are a cluster of issues that are not getting the attention they need.    

• Dirk K:  Question on motivation. Do you think the motivation for netflix / google to go with TLS is privacy?

• A: In the commercial world it’s enhanced content protection.  At the same time, nobody wants to be the last one to do it for privacy reasons.  Don’t want to be the one seen to expose customer’s privacy when others are not. Commercial reasons and publicity reasons.  Don’t want to be seen as the laggard on privacy. For a while netflix could argue it wasn’t technically feasible, but then they figured out how to do it. Part of the IETF’s impulse in this direction.  Its going to be TLS, or TLS with ephemeral keys.

• Borje: Comments.  TLS is fine when you have an end to end connection, but when you work in a  environment have to trust someone in the middle.  What is your view on attribute based encryption? Assuming people figure out how to make it work.

• A: I’m not a cryptographer so I’m not sure I can answer.  The point of the presentation today is more about the implications of what’s happening in IP for this world.  In IP - what is the baseline to meet a pervasive universal opportunistic high quality encryption with whatever we think are the right schemes. In contrast, in 2006 or 2009 it ws possible for ICN to not make that assertion but now the ICN community is still discussing moving things around with caching as if the IP line has not moved to a more demanding rigorous level.  We need the discussion.  Either we do not need to have parity with IP or we can get parity and still have opportunistic caching.  But now we aren’t even having the discussions.

• Börje: We could do both

• A:  But that isn’t happening.  The slides aren’t reflecting this. 5 or 6 years ago it was ok to say it will all work out but not any more.  We are below parity - is this acceptable? 

• Nacho: I agree with Mark  - we should look at encryption and provide solutions to these problems.  But in some networks this is not a requirement (e.g. proprietary networks or internal system that can provide those features).  Can’t always assume but need to acknowledge that it works in some.

• A: Nothing is in the clear traffic in google data center.  Going to make everything TLS.  Soon will become the baseline. No way to protect the traffic with encryption. 

• Ken C: NDN only works if you don’t want any privacy. Talk about the specific threats.  Reason use end to end encryption is to prevent snooping on whats happening between endpoints because the network is not trusted.  If the network needs to be able to see the Names, privacy is a problem. One of the claimed advantages of the ICN architecture is that I don’t have to route to an endpoint - the network will resolve - so the network has to be able to do that.

• A: There is a conflict between what some people assume is the best most beneficial property of ICN and this clear force around privacy and confidentiality.  We don’t see 10 presentations a day about that.  Nobody is talking about it. What we have is all about caching.  Needs to be more thought there.

• GQ: clarify -what you’re thinking is not specific to ICN.

• A: IP is doing something about it, we aren’t.

• GQ: if we treat ICN as a transport. We need something to the transporter that is new to IP or ICN

• A:  Not the same thing.  The IP world doing something.  If all the things they used to like aren’t working any more, that

• s too bad.

• GQ: Same things apply to IP

• A:  Yes, but they accept it as a requirement and are doing something about it. We need to understand what impact this has on our architecture.  I think there is no caching except for repair.  Still plenty of ICN goodness - ( Active, intelligent forwarding features, Receiver-driven flow control, In-network local repair, local retransmission (for individual clients); Mobility still may benefit; Provenance/'publisher' concepts still available; Opportunity for in-network congestion control; Opportunity for native CDN support; New "layering" model; Opportunity for more explicit signalling; Opportunity for API clarity and richness)

• George P: You should change your example, because with netflix what I want to keep private is from netflix not the network.  not a good  example

• A:  I don’t want someone else to see what I’m watching

• George:if you concentrate traffic to major hubs the major problem is at the source, not elsewhere. can provide diffusion of where you get your content from

• A:  Can do that but its grody.  

• G: ACM community has been working on this for awhile - maybe not as much as caching and caching doesn’t necessarily mean in the clear.  I don’t have the final answer and I know TLS does the thing, but not supporting caching at all is not the answer

• A:  I would give up caching to get all of these other things in heartbeat, but giving up privacy at this point is bad.

• Dirk Trossen:  Not true that ICN community hasn’t had a debate on  caching.  Our  direction - general in path caching is a bad idea.  Dedicated caching ok.  Good to see your passion and I want to support it.  I like your list of benefits.  I agree that some people looking at fancy caching schemes should wake to the reality.  Don’t give up on explicit caching - we talk about surrogates - caching as authorized copies.  very good discussion to have. Feel vindicated for all the rejected papers saying on path caching a bad idea.

• Alvin: fully homomorphic encryption - for a while thought this would help get around the problem but a) Not yet fully practical and  b) couldn’t work out how to do it.

• A: Have to get the key to the clients and that communication path has one set of issues and then the change in IP where it used to be you got netflix in clear but payload encrypted with key changing every few seconds. Still several issues even if you thought that was ok. but in IP world even that isn’t ok.  But I don’t hear that conversation - we’re taking for granted that everything is in the clear.

• Marc Mosko: We have a project started  a while ago some work a little ago packet format and encrypting different parts of the packet - maybe by next meeting we can have more on that.

• Fragmentation proposal (update) -Marc Mosko

• Ken C:  draft says this is only for use over networks that don’t reorder packets. But you said bluetooth and ethernet?  Assume don’t reorder ?

• A:  Effect is that you’d you drop the chunk. 

• KC: So you're saying that you can use it with an unreliable channel but no guarantee.  So losses are Ok and will cause the whole chunk to be discarded

• A:  yes

• Manifest proposal - Nacho

• jeff Thompson: slide 11 - thats the interest that goes out 1) does the Content Object that comes back have the same full name in the name section? have you dropped the idea of nameless objects?

• A; No but orthogonal to manifests.

• Jeff: I’m concerned about privacy - if I get a manifest and it’s a list of hashes,  it would be advantageous to be able to  request my objects if I only had to be put routing prefix and hash instead of full names.

• A: yes. current manifest supports that as is. 

• Ken C. -  Is the intent that network elements (routers) will read and understand these things or not?  in either case, will you talk about the design considerations that go into that in view of earlier discussion on privacy and other things network boxes do today that they were never intended to do

• A;  yes, yes, and yes. network elements - apps, stack, forwarde etc - can understand Manifests and can do something with them.  Having said that, our current spec, in our design for privacy can have a manifest that points to an encrypted manifest that can’t be understand by intermediate elements.  We can provide privacy of data without preventing the router from helping you. That way the router can still help with transport without knowing more.

• ravi: relationship between manifest and MT restrictions. Can forwarders define manifests dynamically?  Who comes up with a manifest?

• A:  Everything is possible but I don’t expect routers to come up with manifests.  Generally the top level of the stack comes up with it - I have this large thing to send out and it will decide how to do it.  Is there a case where a router would come up with one?  maybe.  

• Ravi: do you want to use manifests to avoid fragmentation?

• A:  You could do that.  A manifest could have hashes of smaller MTU things.  The manifest itself does not discover MTUs but it can.  Might have multiple manifests that depend on the MTU size being answered back you

• Mark S. all the streaming video schemes, all the dash schemes, all the thing that allow you to coordinate things or maybe just the stack makes a choice about which representation.

• A: current draft doesn’t have those options internally but could still do externally. The idea is that the advanced version will deal with this.

• George P: I see the usefulness of advanced manifest but not the single much.

• A: the most trivial of all uses is that you don’t have to sign every packet and that helps a lot.  Otherwise you have to sign every packet.  With manifests, you gather all the hashes and then sign the manifest. It provides you with many capabilities.  Even with the simple version, prefix data can move and you only have to change the prefix. Transport stack can download things in 

• Q: ???

• A: nameless objects - no name at all, just hash.  manifest can point you to the location. Interest still has a name. although there could be a protocol that does auto discovery and helps you find the location. also useful in the case where  - have to download something and you need to do accounting and have the key.  Companies still need to do tracking.  Manifests could have short lifetimes

• Mark S - Also useful for archival purposes.  I have a piece of a doc - what happens when key expires?   Could produce a new piece of metadata with a fresh key - can still access that archived piece. Aren’t bounded by the lifetime of the keys.

• A: a simple manifest can do that - use it as a building block.

• MS: The data object may be good for many years

• Dirk K:  Everyone - think about advanced manifest things we need and potential issues.  Now is the right time to have this discussion.

15.30-17.00

• Bon Voyage project -- Alfredo Grieco (Max 15 min)

• MM: Why wouldn’t you use something like - why wouldn’t your names they be hierarchically related? 

• A;  second name specifies level in hierarchy

• Elastic ICN packet format - Ravi Ravindran

• A new packet format proposal.

• We need one protocol format that can be applied both to IoT (resource constrained side of the network) side of the network and the infrastructure side of the network

• Want to minimize the transport overhead for mobile and IOoT scenarios

• Proposal is for a 3 byte fixed header; Reduces fixed packet overhead by 5B

• Need to consider IoT opportunity now.

• Proposal: Fixed header - 3B; variable length Extended header TLV for your hop by hop headers

• Jeff Thompson:  talking about a 20 byte Content Object packet.  Typically when a student proposes something like this and you ask them they say in reality this low powered device knows the gateway; so I ask them, why is that ICN?  It’s not signed, no routable name, not meant to be multicasted.  Why talk about a 20 B byte packet?

• A: Just look at wireless world.  They define their transport overheads in 2-3B. That’s a given in wireless world. Can be more restricted.  The key is to avoid this kind of protocol gateway.  If you can have an app just sitting there.  An advantage to ICN - its transfer agnostic.  Can have one app running on bluetooth interfaces or.  

• Mark S - Did you just say that IP is complex and compare it to your middleware?

• A: You’re wasting bits for connectivity reasons. If names are app centric you’re using the bits more wisely. ICN could provide a more meaningful format rather than doing a lot of protocol layers.

• MS: What makes it ICN? Still hop by hop routing, and still stable path, benefits from application level stuff.  Just the basic transport simplification is worthwhile.  Doesn’t make sense to do all of this work to go local.

• A:  Can’t avoid a service gateway, but can avoid a protocol gateway.

• Jeff: Is this 20B packet - are you saying it’s meant to bypass my home router and go on the internet?

• A: No - architecture prevents.  Basically someone collects the data, processes it, and send it on.

• Jeff: wouldn’t expect on the wider network to see one of these short packets - it would have signature etc by the time it goes further.

• A: Basically the bootstrapping protocol would have enough to verify these packets. Good enough to tell them it came from the right source.

• Nacho: Echo previous comments on whether traffic goes in and out.  1) In googles efforts to do protocols at this level they don’t do this kind of optimization in Nest.  Mostly try to organize and talk between things. 2) More importantly, you cited some papers - citation 4  (Feeney, 2001) does not imply “power consumption is proportional to packet length”.  When the radio is on you’re consuming power.

• A:This is purely for the transmission costs.

• Nacho - you will ten seconds to transmit x, 9 seconds to send less. Unless you can turn off the radio in 1 sec it won’t matter

• A: Simply the transmission costs.

• Marc M: For the most basic modulation schemes  phi a linear equation might be correct, but more advanced modulation schemes - 5B might not save you a symbol.

• A; Take something like sigfox - can buy you something 

• Glenn Edens - SIGfox format allows 32 bits of information transmitting 4  times per day.  That is not available to you.

• A: I’m looking for something public - maybe a public version of the spec. Other protocols to support low power. In wireless world, 2B overhead - general norm in the wireless industry.  This is a better story for IoT world.

• GQ: design philosophy between wireless guys and wire line guys.  Wireless guys - every bit counts. Reduce the overhead as much as possible. There is a purpose for power.

• Nacho: I agree 100% which is why I think you need an actual compression protocol - that is different than creating a protocol that reduces 5b out of a standard header.

• Link negotiation discussion (also discussed on NDN list) - Marc Mosko

• Would like input on moving this forward.

• Requirements slide may serve as the beginning of a requirements document

• Four general steps of operation:  Pre-authentication; Authentication; Post-authentication; Data & maintenance.

• Who is interested in working on this?  Get a subgroup going to flush out requirement doc; specify common protocol operations and messages; define control and data plane; figure out if we’re going to have a common wire format between CCN and NDN or not.

• GQ: ??

• A:  in a simple system I may have a 1:1 association with my peers; a peer could be layer 2 peer, layer 3 peer, but we should also consider the case where you might have hundreds of peers especially on an ethernet segment and I don’t think doing 1:1 associations on that would be right.  Might want to do a reflector type association.

• Mark S:  I like the work. We have some people in UK interested in these things and I’ll connect you Are you saying you think there should be mandatory encryption?

• A: No - if you have encryption, you do this.

• CCNx over UDP specification (enabling interop, related to link negotiation) - Nacho

• CCNx + Cisco code + CCNLite interop over UDP at CCNxCon hackathon - mostly worked.  We want to make sure we write down what happens in Interop work going forward.

• Looking for interested parties and authors willing to contribute.  Maybe by next IETF we’ll have something more concrete.

• Scope for now:  how to transport CCNx messages over UDP between two nodes.

• Virtual link between nodes

• GQ: clarification -  we are using ccnx pre 1.0 over up today.  Are you saying some of the functionality isn’t there?  why UDP specific?

• A;  How to use UDP to establish a link.  Some of it is generic to links (e.g. like determining an MTU).  That is not necessarily a change in CCN. Need to be able say - when you use this kind of link - does it provide ordered delivery or not?  Then any forwarder will have to do what it needs to do assuming not in order

• GQ Which link are we talking about?: 

• A: two forwarders talk to each other.  In this case, through UDP socket.  In current 1.0 implementations you manually set this up. In old implementation also manual but doesn’t determine a lot of stuff.  Works ok in our forwarder but if you try to inter op  or your network behaves in ways you didn’t expect…

• A;  We do not assume UDP over ethernet.  Just looking at UDP characteristics. 

• GQ: If I put the ccn protocol on raw IP then I would have to do this?

• A; This would be a different protocol. May have practical effects on going through firewalls etc.

• Ravi: ?? (not using mic)

• A the controlling of the link should not interfere with the data packets.  When you send from one node you send a packet out.  Then a second.  At a link level, may arrive out of order. For a certain class of service on ethernet, if you send in one order will receive in same order.  You make assumptions - for example, fragmentation you assume will come in order or you lost them.  In our case, we need to specify our expectations in order to be able to interoperate.  I’m in favor of order.