MONDAY - July 20th ICNRG meeting
• Welcome, Agenda Bashing, Minutes taker, Status [Chairs]
- In research challenges - published soon after final review after IETF 93.
- Evaluation methodology - ready for review
- Video - no update since last meeting
- åcedric: just a couple of days away
- Reports from ICNRG interim meeting on Sunday
- Packet format, fragmentation, link negotiation, etc.
- ICN native approach (Bengt) systems arch draft (Ravi) - possible to work together
- Ravi: We need to discuss further - started discussions yesterday. Will try to come back with 1 ICNRG working document on challenges
- Nacho: Yesterday we discussed manifests a little bit. Wilson out email on mailing list for anyone who would be interested in meeting this week to talk in person about what to do next.
- Privacy: Lots of effort in encryption, transport layer, some business demands and user privacy concerns. Given the ICN initial idea of opportunistic caching, how does that relate to privacy. Want to continue discussion. Check out Mark’s slides.
- Towards ICN-based data-locality in HPC - Michael Alexander
- HPC range: Classic HPC, Data intensive Computing, 3rd thing
- Challenges: parallel file system limitations, fault toleranec resilience recovery, physics of spinning disks etc
- Ongoing challenges: multi level storage hierarchies, fast forward I/O and storage stack. Can transparent POSIX continue as main pattern?
- Modify HDF5 to have a strange target which is NDN possible. What would a demonstrator stack need to be able to do? To demonstrate NDN applicability
- Questin (Spiros): Mentioned NDN concepts a number of times = I missed what the NDN concepts are that would be helpful
- A: More namespaces - if they’re flexible even nicer. caching property along the path is a nice thing. Routing aspect and the resolution is nice usually in parallel file system it resolves but its flat so no multiple layers.
- Question (Dave O): is this API for storage intended to be used at the site of data publisher or intermediaries?
- A: Most of the need for it is clearly on the client side. Client having to specify more metadata about where the data should go and how to be kept. main objective. Could also look at server side items but the client is the big win. Huge step forward if client would specify it.
- IP services over an ICN (over SDN) - Dirk Trossen
- Came up on mailing list a couple of weeks ago - people asking for other use cases
- One use case: The Internet (presented yesterday). Biggest one you can come up with. Yesterday about the project; today how the system works.
- The Internet is the killer app for ICN
- Hypothesis - works better along many dimensions (KPIs). Project to show this is true.
- Hypothesis only - could fail
- Expected benefits: Coincidental multicast (close to demonstrating)
- committed to makingIP/HTTP over ICN work
- Question(Dave O): is the intent (since multicast in the internet works terribly) is the intent to make it better or just as badly as it does now on IP
- A: Typical multicast services and yes there is an argument that these services in a single operator domain might run better. They are not services designed to run multicast they just happen to be able to utilize the multicast underneath.
- Kireeti: You expect this to last well beyond the transition. We assumed ICN would replace the Internet or will it still be around? or just a transition mechanism to ICN
- A; Both. I can’t answer whether internet will still be around or not. The point of this use case - there is the Internet - I don’t know how long it will be around - this is a transitional story. Gives you a transition of your services. In addition you get ICN. You get both sides but is a transition story.
- Kireeti: question to the chairs - is there anything in the Internet today that you want to preserve if we transition to ICN.
- Dave O: Terminology problem. Dirk said “The Internet” and “an operator”. Talk about running IP protocols on top of ICN whether they can do the same thing we do on int today or not. Do those IP protocols on ICN will they operate transparently to someone who today thinks they are running on the Inet. You need to disentangle
- One more thing - if I wrote an app which today runs on TCP/HTTP - will it run unmodified in this env?
- Kireeti: Are the benefits of ICN such that - my app still runs but now I want to take advantage of ICN - should I rewrite my apps? Is this a transition strategy or a replacement strategy?
- A: The technical problem were — to run IP based apps on top of ICN. the pitch is flippant - internet use case.
- Dave O - if something only runs in a single operator, its not the Internet
- Dave O: To clarify - Since many operators run IP over MPLS - the analogy here is that you run over ICN confined to a single operator but nobody else knows what is happening.
- Kireeti - running over MPLS - never said we will give you a better protocol or be a replacement. ICN is a replacement. So this is a nice transition strategy.
- A: mobility within the operator domain - we have solutions
- Spiros(?): I think its a relevant area. Many details I have questions about. I think how without infrastructure like rendezvous server … there are other ICN designs that don’t have those components. What it would take in other environments to run TCP would be interesting. Whether its viewed as a transition possibility or whether its the big philosophical q how does this become the thing underneath. Work would be interesting to do.
- A: If there is interest in formulating the use case - could be a good starting point. Crossing ICN flavors could be difficult.
- Presentation of results from NetInf field trial at the Ski World Cup in Falun - Börje Ohlman
- Jeff Thompson: I understand how you can have a list of videos for static and request video by hash - but what is mechanism in real time to discover the right hash in streaming video?
- A: client subscribe to name of header then we have publish notification when new name becomes available - sent over UDP. were pushing the names out to the clients and then they can request it. If we do it for sensor data well include in notifications -w not have to do it twice.
- GQ: so the push for notifications is a kind of controlled push
- A: send the subscription all the way up; when next subscription comes here this one has already been made and will get aggregated. node will keep subscription state.
- Interest-Notification - Ravi Ravindran
- Support for notifications in CCN
- Proposal: new PacketType: TYPE_NOTIFICATION. When forwarder encounters this - only FIB state in forwarder should be used.
- Notification message is a Content Object. Use Name in Content Object to route - push out to a bunch of end points. Can incorporate relevant metadata. Do it if you want to separate routing namespace from content producer namespace (namespace)
- Q: difference between piggy backing and ?
- A: Piggy back interest? Primarily saying you want to push info which consumer doesn’t know is being generated. In that context this proposal. Piggybacking fits more into the request response model. Whole point here is sending interest - want to push it to the end points
- Q: Adding a new message type is a big deal. We want to simplify things.
- A: Much simpler to do it this way. Another issue about how to derive names,
- Mark Stapp: Problem is - Sending unsolicited message in CCN or NDN is an open issue. Its definitely worth understanding how that works but then moving beyond that to say we're not only not going to answer those questions we're going to add new category of unsolicited message - we should work on rules on unsolicited messages - not new problems and this doesn’t solve any of them. If we identify some specific property that can’t be addressed there then we should talk about a new message. What should the limits be?
- A: The whole point is that I laid out these challenges.
- Kireeti: These are important problems to solve. Not sure the mechanism is right but we do need to solve it.
- Dave O: What I find passing strange about this all the other architecture that support notifications do them in the context of publish / subscribe. no publish operation here to scope the state necessary to process these notifications. How will you ever do anything beyond scoped broadcast? The idea that this is an unsolicited message type that flies all over without the heavy state that all the pub sub architectures have makes my brain hurt.
- A: You could use a notification message itself.
- Nacho: good that we're having this discussion. Part of why we're doing this is because people use the interest to do this. They overload the function Interest provides to push stuff. Part of what we're trying to do is at least somehow define it. It is a larger topic - there are many open questions and we should keep looking at it.
- Update on PARC IPR disclosures (Lars - chair of IRTF)
- RFC 5743 - the RFC that defines the IRTF RFC stream.
- IRTF follows same disclosure rules as IETF - anything else would be crazy. If you’re a contributor to a research group and you or company own a contribution (speaking at microphone, submitting doc…) obliged to disclose IP. Same obligation as IETF. IETF doesn’t have rules about kinds of licensing schemes that are good or bad. Slightly different in IRTF. IRTF prefers the most liberal terms - however although disclosures are required, no rule on the type of licensing.
- CCNx Semantics document (WG update) - Marc Mosko / Nacho
- Next set of work items for documents:
- Nameless objects: allows Interest to carry a locator and hash identified to match a CO by hash name only.
- Hop count in a Content Object - measure of how far a Content Object has moved in the network
- PIT behavior for aggregation - currently implemented in code base but not in spec.
- Encapsulation type - one mechanism - send a link and append the linked object; alternative - wrap the object. Need discussion.
- Question (Dave Oran): Clarifying - is the purpose of this to figure out cases where concatenation is signed by one key but if you need different pieces to be signed by different keys you need encapsulation. Is that the reason for multiple ways?
- A: One reason to do encapsulation is because you want to send a response with different name or security environment. A couple of methods proposed for doing that. 1) sign the link with the new name and signature pointing to original message 2) fully encapsulate one within the other. Useful to start talking about those two.
- Nacho: Was your question why multiple ways done in the past?
- Dave O: trying to understand entanglement of which keys sign which
- Nacho: Not independent. Given that we expected encapsulation used in different locations should the main document incorporate or separate them out.
- Dave O: Whatever document talks about that has to talk about the keys
- Q: Can you give an example of a locator name?
- A: In normal behavior, a Content Object has a Name - that name is part of the signature envelope - that cant be changed. Routing must point to that name, so I can’t take that Content Object and say put it on a replica somewhere else and expect routing to deliver an Interest to that location without some new cache figuring out behavior. With nameless objects, the Content Object has no name, only identified by hash based name. So the name in the Interest is only to steer the interest to designated replica and then at that replica the matching is done based on the hash and there is a change to forwarder behavior to specify what happens when you get a Content Object with no name. That is the scope of that work item
- CCNx Format document (WG update) - Marc Mosko / Nacho
- Changes to Vendor specific info, PayloadID changes to allow two interests with different payloads to have name segments identifying that difference for different matching.
- Ravi: on payload id - you have a Content Object has id - how is that different.
- A: Previously, if I want to put state in an Interest such as http cookies, I would append that to the name and make a big long name. We want to say if you’re going to put a lot of state in an interest, put it in a payload section and indicate that it's there with a payload ID. If you’re putting a two byte integer, stick in the name - thats fine - but if its a big long thing, put it in the payload. It's app metadata thats part of my request . The Content Object that comes back - name must match, but not same payload. Not interpreted by the forwarder, that's why you need a multiplexer in the name. Also saves bytes in the forwarder state.
- Lars: feedback to take to Xerox legal. Clearly you see value discussing CCN with this RG. I'm asking myself what is my interest in helping Xerox improve an architecture that is proprietary. Licensing makes this difficult. Others in the community may be asking as well.
- Using ICN in disaster scenarios (draft-seedorf-ICN-disaster-03), RG Update and how to proceed with this document - Jan Seedorf
- Hum on acceptance - mild hum to accept.
- ICN and 5G discussion in the light of ITU-T and 3GPP initiatives on this
- ICNRG has recently received a liaison statement from ITU-T study 13. They are starting new work on requirements and architectures of data aware networking. Letter we received informed us of this activity and invited contributions. IRTF is set up to do liaisons. We forwarded to IRTF and someone replied clarifying. No immediate follow up for us. But wanted to make you all aware that his is going on. Also aware that ITU-T is discussing this now. I believe people working for companies in this room may be participating. What does it mean for ICNRG. In principle we operate in open fashion - anyone can come and comment or contribute to our work. Lots of designs and public statements on ICN in 5G. Welcome in this group as long as its not pure marketing :-) People who have been following more closely invited comment.
- Nacho: A lot of interest talking about technologies in general. Some hype, some seems like it's going somewhere. Lots of interest. We also are interested in this - who else is? Some of our stuff with Manifests, links, encapsulations … has to do with mobility and how to provide a better environment for data, voice, etc. If anyone wants to bring up we're happy to collaborate.
- GQ: one of the picture of 5G - service enabling for new apps and services in future. IOT will become service enablement. Thats what we see as link between ICN and 5G umbrella. In could become platform for future 5G.
- Borje: if anyone in room has been at the meeting and would give a short report would help.
- Lars: We are an open community - presentations from anyone can be presented here. Having anyone come here is easy. Making statement for other organziations is not possible. Scott told them - if you want a consensus statement from an Internet related org, ask the IETF, not us.
- Costa: clarification. If there was an ICN working group, then we could have cooperation with them?
- Lars: The IETF can because they are a standards body, The IRTF is not a standards body. Research groups don’t need to operate by consensus. Even if you did and came to a consensus you still couldn’t send to ITU. IETF can have liaisons, IRTF can’t.
- Jan: Question is can we form a working group? I think the answer to that is you can try if its reasonable. Others have done it
- Costa: Follow up. If ICN is going to have any kind of cooperation with anyone in 5G space - we would need an IETF working group.
- Lars: Depending on what you mean by cooperation. You can’t say “The ICNRG believes this” and send it to them. If there was a standards group on ICN in IETF you could.
- Dave O: It would be interesting to see if the IETF would charter a working group with such a broad charter as ICN. If someone wanted to propose that IETF work on a standard for CCN or NDN or whatever, nothing would prohibit you. But I would counsel you that you’re more likely to be successful if you propose something specific rather than a mirror of this research group.
- Costa: The way I see it, if this is going to play any role in 5G it can only happen in a working group.
- Dirk: Thats a viewpoint. Right now “we” are a research group. Right now we're moving to a mode of specifications that could be moved into a standards process. There are also other bodies that could look at ICN if they want to.
- Kevin: Echoing Dirk's point. It is true in DCNRG case. There were individuals who were members of other standards organizations who ended up making references to experimental documents from IRTF that were desired by other SDOs because they were in the stream of documents. They wanted point to a thing that wasn’t a draft that would disappear.
- Glenn Edens: Our understanding of the previous conversation is pretty clear. We totally understood that IRTF was not a body to interact with ITU. I would just make a broad invitation that anyone interested in their activities should get involved. There is a lot happening - several sub groups forming. Hot bed of activity right now. Get involved while it is getting set up. I can’t represent their organization - we're just getting involved ourselves. I suggest getting on the ITU website because its all open and get involved.
- Interim meeting Oct 3rd - hosted at PARC - after ICN conference
- NDN community meeting just before ICN conference
- Nov 1-6 - next meeting Yokohama Japan. Do we want a meeting and an interim meeting?
- Dirk: INC and open stack summit the week before
- Jan: We should definitely have a regular meeting.
- Dave O: Less than a month between SF interim andYokohama.
- Costa: Support having at least an ICNRG slot in Japan.
- Lars: This IETF have the most research groups meeting. We are bumping against the limit of how many groups really need the space. Might consider skipping an IETF meeting if inconvenient.
- Dirk: Thing to Thing research group starting. Discussing things similar to our IoT work. Check it out.
- Dave O: planning an informal bar meeting on Manifests - watch for the email.