[icnrg] Minutes and meeting materials from the Tuesday meeting

[Börje Ohlman <[e-mail]>]

Minutes and meeting materials from the Tuesday meeting are now linked from our Wiki page
> http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg <http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg>

The minutes can be reached directly via
http://www.ietf.org/proceedings/92/minutes/minutes-92-icnrg

Please let me know if you have any additions and/or corrections.

Great thanks to Laura for taking the notes!

	Börje

————————————————————

ICNRG meeting Dallas, TX, March 24, 2015
Time: Tuesday, March 24, 2015, 1520-1720
Location: Continental
Etherpad for notes: https://neclab.titanpad.com/ICNRG-IETF92 <https://neclab.titanpad.com/ICNRG-IETF92>
Agenda
Welcome, Agenda Bashing, Status [Chairs] -- 20 min
Baseline Scenarios Status
ICN Challenges Status (draft-irtf-icnrg-challenges-01)
Adaptive Video Streaming over ICN (draft-irtf-icnrg-videostreaming-03)
Cedric - Video draft timeline:  next week submit version to authors, by end of next week have update (in April)  
Evaluation draft...
Report from interim
Report from Sunday’s interim meeting: all material uploaded
Update on ongoing research in GreenICN project - "Using ICN in disaster scenarios” (draft-seedorf-icn-disaster-03, draft-seedorf-icn-wot-selfcertifying-01, draft-jiachen-icn-pubsub-01) - Jan Seedorf -- 20 min
Disaster scenarios; European and Japanese partners
Key use cases
Seeking feedback from community: (lots of work in DTN community). ICN has many beneficial advantages out of the box. Now trying to enhance with DTN capabilities - could do the opposite, other people are doing that, but we are coming from ICN starting point. 
Want solution that works before and after disaster - can work on regular network to start but continue after.
We have a couple of drafts - now want to show overview of initial research results.
Enhanced ICN with concept of Data Mule. Had a demo at ICN 2014.
NREP - Name based replication (name includes attributes such as  time, place; name shows priority like “Emergency”
Security - data centric security; data can be retrieved from anybody and maintain its security; Ciphertext-policy measurements.
Web of trust trust relationships in small compressed file. Scales less than 100ms with 2 million nodes.
Energy considerations: after disasters need to be energy efficient so comms can continue until power restored. Ongoing work.
Ravi: based on the graph - at what level is the web of trust getting established?  At the  device level? app level?
A: assuming every user is a member of the web of trust and this is reflected in the name. Could say WoT for users, but by name that is under their signing control. 
Ravi:  model has been tested with disaster scenario of islands that can be rejoined. routing?
A:  This approach is only looking assuming messages forwarded in hop by hop fashion.  Other options are considered and eventually combined. Assumes you fetch some content and want to authenticate - can do it with the WoT in a decentralized fashion but get content through router forwarding.
John:  Why chose DSV?
A:  paper outlines why we chose distance vector protocol.  Off the top of my head couldn’t tell you.  Also easy to integrate with ICN.  Not saying its not possible to use the other.
Georges (Huawei): What kind of ICN protocol used?
A: Building on CCNx 0.8 / NDN - which was almost the same when we started,  Not so much any more. A bit of a challenge.
Georges: Have you also compared performance of ICN protocol with traditional DTN?
A: Very hard, lot of DTN protocols don’t solve the problems we want to solve.  We want to spread information which is why we start with ICN.
Chris Wood:  why did you choose CP-ABE (ciphertext policy attribute based encryption)
A: Want to have something that works when you’re offline and don’t have access to a PKI authority or similar.  And can still encrypt things with access control embedded
Chris: Suppose a new user wanted o get credentials after the disaster?
A: an old research challenge to be able to do this. 
Chris:  Performance results - plotted as increasing number of attributes.  How did the attribute tree scale?
A:  Cant tell you from the top of my head. Send me email and I’ll send back.
Model driven protocol/platform for ICN - Mach Chen -- 20 min
GEARS:  Generic and Extensible Architecture for Routing & SIgnalling
Model driven generic platform
Lixia: I’m confused about the purpose of quoting OSPFN. OSPFN is not NDN. This work is not ICN.  OSPFN  was only a pragmatic quick & dirty way to get our testbed up and running quick.
Dirk: This is just showing how they can use it.
A:  Ok - it is clear.
Lixia: Given OSPFN is unrelated to ICN, this is not the right thing to use as your illustration.
Georges: goal of presentation is to show how you can use building blocks of OSPFN?  Future goal is to use ICN building blocks and integrate into this platform? When we have the ICN building blocks ready we can use them?
A: Yes
NDN-based architecture for optimizing content delivery in social networks (draft-truong-icnrg-ndn-osn-00) - Emile Stephan -- 20 min
Mark Stapp: reason the requests go to the other servers is because that is the business model, right?  Its not in Facebook’s interest to do it another way. What is the model of the draft? If the info has to go to the CDN, how would the CDN tell
A:  Some interfaces are missing with regard to this.
Marie Jose - what is different between your scheme and  p2p distribution model with super peers? 
A:  Difference is that work is done by two or several nodes.
Dave Oran: what are the privacy properties of this?  OSN knows the social ground, and local distribution knows communication graph and so in absence of cooperation between OSN and local routing control, nobody learns that people are delivering data. don’t learn the social graph but in architecture you have someone responsible for delivering data now that has learned the social graph.  Potentially two diff orgs and business models and two diff relationships - so what kind of privacy properties? 
A: not in the scope of this project.  Naming is trigger?
Dmitry P.- Key question: where request to ask for a redirection should initiated? 
A:  your point was very long - what was the question? 
Mark stapp: In your graphs did you examine diff in scheme some service changing rules and ordinary ICN as exists right now - gets cached on way upstream and  requests get cached copies  It looked to me that would have same effect,.  Did you compare that?
A: No.
Protocol wrap up discussion - Dave Oran --15 min
Have been some convergence among some of the drafts.
Have first draft version of requirements for systematics / taxonomy (Sunday)
Issues remain in a number of areas:  semantics, architectural features, extensibility …
Three options to move forward:
-  Continue as we have been
-  Focus on the requirements document
 Adopt an experimental platform (not exclusive)
Nacho: Had good discussions in group tho sometimes seems like low bar to entry and not a research group.  We’ve been having a lot of regular calls with groups that are involved in this research group.  I think we have rough consensus and wed like to adopt the specification documents.  In our Boston meeting, we discussed the fact that we are not required to limit our adoption to just one proposal.  I think we have the agreement in the room to agree on something experimentally and move forward.
Stapp: People will keep doing what they are doing - that is not going to go away.  Discussions on higher level things have been going on for a long time and will continue.  At the other level, there is some advantage to there being an ICNRG platform - things that we can do to provide people with a more consistent platform would be desirable.  People from various kinds of perspectives would be using the same platforms.  If there were two platforms, people might say we had to use platform A because of what was missing from platform B.  Don’t think the three options are exclusive.
Lixia: We should focus on the requirements discussion.  Haven’t heard any feedback yet and would appreciate some.  2nd comment - doing experimentation is fundamentally important. Doing experimentation is not about adopting one proposed format, but the availability of running code so everyone can try things out.   NDN is an open source effort, everything on the GIT, trying to get more people to join the design and development effort.  We have a three-continent testbed for people to use, anyone can connect to testbed following the documented procedure.
Dave Oran:  If someone wanted check in code that would change the NDN architecture in a fundamental way (e.g. manifests, or exact matching) Would they be allowed to check it in?
Lixia:  They would go through the community change process. Our code is modular - you can set up your own version if you like and make your changes - if you prove something is right we would consider adopting it. Future architecture is everybody’s interest and  everybody’s responsibility.  Summary:  for research 1) need a test bed to try things and 2) need multiple implementations to compare.
Rob Calvert;  We have a doc for requirements and doc for wire format - does the latter satisfy the former?
Dave: No because there is not agreement on requirements.  We have the beginning of a doc to give a place for that conversation
Nacho:  Did we agree to adopt the req doc?
Dave: No.  By the way the taxonomy part of it is potentially more interesting.
Nacho: We can still adopt the protocols we have proposed - I haven’t heard a reason to not adopt the protocol - it does not prevent people from doing Open source, or stop them from doing something else.  It actually helps some entities and doesn’t  hurt anybody else.  We would like a vote on adoption.
Dave.  make sure we define entities - not just companies.
Glenn Scott: We had an earlier slide on lots of interesting next steps for the working group but I fear that if we don’t have some agreement on at a packet format that we can interoperate with, we won’t be able to do any of those things and they will just languish.
Georges: Think 2nd and 3rd bullet should be combined.  Think should have better consensus on requirements first and then move to looking at the drafts. But can work on both in parallel.
Ken Calvert: I’m expressing skepticism about agreement on requirements. In general stepping back and thinking about what you need is good, but having more experience with apps would help.
Lixia: I agree with Ken that understanding app requirement is important.  haven’t even talked abut apps yet, never mind agreeing.  Should be discussing these other things like metrics, requirements.  This is a research group - lets keep that in mind.  Some companies have agreement on their packet formats, that does not need the RG adoption, they can simply go ahead doing it.
Marc Mosko - Requirements - would be great to work on and come to agreement; in terms of experimental code we should move forward with getting something adopted - having multiple (e.g. NDN) ok in a research group.  CCN Lite does do CCN 1.0 and NDN protocols.  Our binaries are out now and we are putting out the CCNx 1.0 SDK in the imminent future and so will have code available.
Nacho:  Adopting document doesn’t mean we control what people do but if we adopt a requirements doc it does constrain what people do so that seems like it goes against the research principles of the group.  
Cedric: Feedback I get from working group - it would be nice if you could converge on an underlying protocol so things can be built on top of it so adopting a packet format would be very helpful.
Hums overwhelmingly agreed we should go forward with the adoption of the documents as an experimental option.  Leaders will pursue on mailing list.

Next steps discussion - Börje Ohlman -- 15 min
Sunday discussion protocols slide:
Lixia: There are two distinct parts to the apps question - 1) existing apps migrating to ICN and 2) (more fundamental) need to understand new applications requirements to see how ICN design needs to be adjusted to satisfy the new app req, I think thats what you were trying to capture in the bullet.
Börje:  I haven’t captured #2 well, it should be on there.
Lixia: rephrase. Not so much that they might do better on ICN, but rather we need to design ICN to support these kinds of applications.
Börje: If we manage to get ICN out there and deploy it I’m sure people will come up with new apps we haven’t thought of. It would be interesting if people would bring us apps.
Ken Calvert:  Design patterns came up on Sunday.  Someone said this is something we need to be better at.  Identifying classes of apps so people can apply the patterns.  But I think we need to do more apps to better understand how to define the patterns.
Börje;  OK
Mailing list suggestions:
Georges: I don’t see a topic emphasizing some kind of aggregation.  Suppose have non ICN type of clients and they might be enabled to also support an ICN type of infrastructure.  How could we do it
Börje: That's certainly a topic even though it is not included.  This is not an exclusive list.  This is just what we have so far.
Continue discussion on mailing list. 
Volunteers to drive specific issues.
Feel free to start your own small group to work on a topic of interest and get it started.
John: routing protocols which are currently finished or near completion. will have place for metrics.  Should have room for arbitrary metrics so that can be pushed in to newer routing algorithms. The hooks are there in Manet to do that already.  I’m sure there are also some in fixed route 
Dmitri: Where and what is the source of names in the ICN system.  Social network on top of an ICN system brought this up.  Are we considering ??? in names in different levels of applications? Might see more and more of these layouts / framework so it might be interesting to consider
Dmitri:  Which class of policy are we going to have and allow in our routing processes.  Enforcement will be a difficult part. I haven’t seen the Policy enforcement topic introduced.
Dave Oran: Reflections - routing metrics are a subset of kinds of metrics we're interested in.  Our scope is for all sorts of metrics, cache hit rates … both to measure and adapt the system - not to exclude routing metrics, but we should think more broadly. Second thing - interaction between designing apps to fit ICN vs adapting ICN arch to fit the apps.  classic app dev model - design functions, build models, put up and then figure out how to access them with names like URLs.  In model allows us to think differently - already discovered that design of name schema is not something you do after the app design - it's a deep part of the app design itself.  A different way of thinking about apps.  Work that explores that whole question - what part of name schema specifies semantics of apps vs what parts are there for efficient routing, caching etc.  Very rich area for people to work on.
Börje:  In principle can design an app like FB on top of ICN so you don’t have to have a business model.
Mark Stapp: The apps discussion concerns me a lot because I don’t think IETF does apps very well.   1) the people that run the business - FB exists - business people can explain why they have CDNs.  We may not have the people here who can explain the business rationale for decisions.  2)  the people writing the piece you interact with (eg the swift programmers). Someone said people write the apps to conform with TCP but I don’t agree.  Most people think of apps from the URL perspective, not the low level stuff. I’m not sure we're going to be great at either of the two dimensions of apps.  We should focus on providing network services - 
Börje:  We are not the IETF building protocols, we are the research group which gives us more opportunity to for example collaborate with app people.
What should ICNRG focus on?
Which key issues are we missing? What happened to
Access control
Routing
Mobility
Transactional data
New ideas?
NFN - Dirk Kutscher
Wrap up, Next meeting -- 10 min
Prague IETF meeting -   4:50
Sunday already taken by ACM ICN TPC. Could meet twice during the week.
Jan:  Many people at the TPC meeting so another full day not advisable.  Two meetings during the week if we can get it.
CCNxCon in May in Palo Alto
ACM ICN conference end of Sept in SF.
NDN Community Meeting Sept 28-29 at UCLA, right before ACM ICN (Sept 30-Oct2) in SF to make travel easy for people from Europe and Asia.