Minutes for ICNRG at interim-2015-icnrg-2

Meeting Minutes Information-Centric Networking (icnrg) RG
Title Minutes for ICNRG at interim-2015-icnrg-2
State Active
Other versions plain text
Last updated 2015-03-24

Meeting Minutes

   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


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:
    + 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
    + A: currently trying to improve algorithm for that
    + A Lixia: here only one consumer per stream -- so effect does not become
  - Q Dimitri: link rate between client and bridge varied?
    + A: not in the simulation, but it should be varied in more realistic
  - 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
    + 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
    + 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
    + 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 ->
      - 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
  - 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
    + 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
    + 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
    + 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.

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

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

Lixia:  Might be a good ICNRG research topic.  [Describes cong ctrl

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

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

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

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.