Minutes ICNRG-2015-01-Cambridge

note takers
    Tues morning: Alex 
    Tues afternoon: Ralph
    Weds morning 1: Cedric
    Weds morning 2: Jim
    Weds afternoon: Ravi


Tuesday, 09:00

09:00        Welcome and logistics, agenda bashing and Notes takers
09:15        ICN-enabled Video Streaming (Cedric Westphal), 25 min
09:40        Security
Authenticated Denial (Mark Stapp), 20 min
10:30        Coffee Break
11:00        IoT
IoT draft (Anders Lindgren), 15 min, ​http://tools.ietf.org/html/draft-lindgren-icnrg-efficientiot-02
CCN & IoT (Marc Mosko), 15 min
IoT & ICN (Ralph Droms), 15 min
IoT next steps discussion, 15 min
12:30        Lunch
14:00        CCN/NDN Control Messages (hop-by-hop etc.)
Nacho Solis, from joint discussion with Cisco, 20 min
some discussion

14:20        CCN/NDN Packet format I (timing and order may change)
                PARC (Nacho Solis), 20 min
                ALU (Massimo Gallo), 20 min

15:00        Coffee Break
15:30        Huawei (Ravi Ravindran), 20 min
                CCN/NDN Packet format II
                Cisco (Dave Oran / Mark Stapp), 20 min
                Comparison (Mark Stapp), 20 min
17:00        Adjourn
19:00        Dinner somewhere

Wednesday, 09:00

09:00        Named Functions (Christian et al) -- 60 min
10:00        Scalable Point-to-multipoint Communication (Börje Ohlman) -- 30 min
10:30        Coffee Break
11:00        Implementations I|
PARC stack update (Nacho Solis), 30 min
CCN/NDN end-host behavior (Nacho Solis), 30 min
NDN Packet Fragmentation: Hop-By-Hop or End-to-End (Alex Afanasyev), 30 min
12:30        Lunch
14:00        Other Topics
CCN-lite update (Christian Tschudin), 15 min
Congestion Control & ICN - open discussion, 30 min
Next steps for ICNRG, 20 min
15:30        Wrap-up

ICN-enabled Video Streaming (Cedric Westphal), 25 min

Authenticated Denial (Mark Stapp), 20 min

IoT draft (Anders Lindgren), 15 min, ​http://tools.ietf.org/html/draft-lindgren-icnrg-efficientiot-02

CCN & IoT (Marc Mosko), 15 min
IoT & ICN (Ralph Droms), 15 min
IoT next steps discussion, 15 min

CCN/NDN Control Messages (hop-by-hop etc.)
Nacho Solis, from joint discussion with Cisco, 20 min
some discussion

|| video over ICN by Cedric Westphal (CW)

document existing mechanisms and how to port them to ICN.  Want to look more .. other side of coin: if you have ICN architecture, how specific video distr. mech. would look in that arch.

video most of the traffic now. a lot of exist. mech. for vid. distr.  question of the draft how they would work. what new mechanisms should design, what they would look like?

throw ideas, start discussion.

video draft: 4th version, since Toronto. IETF.  need to be updated from the last discussion.

>> ICN specific video mechanisms.

Discussion, ideas.  2 things to discuss: look at high level, ICN abstractoins, more specific ccn-type mechanisms to enhance video distribution.  High-level, may be naive...

ICN enable store and forward.  Current adapt. mech. look at e2e path. in simple strawman example, you would achieve min e2e bandwidth.  with icn specifics, you can use extra mechanisms to fill cache, to draw from cache.  Basic observation, but could be powerful.

in the context of vid. distr: what kind of rate adaptation to use. How to maximize  QuE for use, what cache awareness mechanisms.

>>> QoE Maximizing algorithm.
You can come up with some algorithm.

Marie-José Montpetit: Talking about progressive download. You can use similer to almost real-time.
How do you define QoE?  PPl minimize age of buffering

CW: min buffering events, min rate variations, maximizing rate.  Different rate/diff. function, rate trajectory over finite horizon. Cache usage in the middle.

DO: Single path formulation? Is it accurate?

CW: Yes (point to later).  I don't have multipoint multipoint, multisource-fetching.

DO: Caches only reactive to requests and not proactive for predictive caching?  Caches wouldn't fill faster than clients request?

When client has higher capacity, ... has to anticipated.

:: are you maximizing .. coupled with cache dynamics, assyming cache dynamics...

CW: cache is used ..
video stream from the server. if you have cache, client would get from cache.  not going to get from the serer.  if you have a miss, you will get from the server.

Giovanna:: You still not considering cache dynamics?

CW: ... wait for later slide

Presented results with different utility measures.  Conclusion do better than now

You have to delegate some capacity to user. WOuld you better of using this, or ... How much caching capacity you need to use it?  This is good question (97 paper on the context of video in atm).  how do you allocate resources?

How to estimate bandwith? some prediction

how to scale to large number of flows.  horizon grows, rate grows.

Marie-José Montpetit:  semi-real time. I'll ask and share. THere was a lot of caching

Mark Stapp (MS): reason it helps: sharing fate. what is the popularity of static video.  population long tale.

CW: benefit is in every

Marie-José Montpetit: cachie on your own dvr. or you have a couple seconds of buffer.

MS: original picture with square waves. hypothesis: min bandwith will achieve until more bandwith arrives.  if there bottleneck, the cache will be drained.  where was the bottleneck?

CW: it should be time-variance

MS: how state machine works?  two oscillating state machines

Marie-José Montpetit: streaming over wireless. bottleneck wasn't real bottleneck (interaction with tcp state machine). by doing magic, you can avoid buffering events.  You cannot invent bandwidth.  a lot mechanisms are poorly adaptive.

MS: even it possible to have adaptation?  Oscillations with caches.  there is no model for effective bandwith estimation in this arch.
Where is proposal for flow control?

CW: Not ogin to have a specific answer.  The results are just observations:  presence of cache allows you smooth out variation of the capacity.

TCP either is not the best thing.  Throughput of e2e conn. will be sign. different.

There is a lot of issues associated with.

If you have icn-specific transport protocol,... what that means I don't know and should be discussed.

Video prefetching.  What looking at: cache in the middle and predict requests from the user. Daily pattern.

Youtube server: (curve for the capacity: inverse of the demand curve). you can shift. How much: gain at the peak (~20%).
Designed some mechanisms.

Bj: daily patterns. weekly month schedules. if you really want to predict  look what is the content.  different behavior for sports/ tv series.  better prediction if you look

M(parc): viewing platform also a factor.

MS: this will be opaque/private. Places where it is now, will be unsupportable.

Bj: question now will this be totally encrypted or object security.

DO: this particular effort: ocncentrate on what is different in icn and how to exploit icn (caching, prediction, prefetching... how to adapt to wireless).  much of that work exactly in icn. some of the work could be completely different.   value : what would be different when switching.  multi-source. the fact that there is per-packet state: congestion control.  wondering to other areas dilutes the focus on what icn bring.

... a lot of research in genreal community that can apply to icn as well...  is it differnet from tcp/http

... the right track, but there is a lot of general stuff.

... (answer to MS q.) security. some icn arch. do integrity on one layer, privacy conf. at diff. layer. quest of what encr./not is more flexible in icn. protect data different keys from structural info .  some things can be unencr.

in today none of the structural info is encrypted only video itself.  build-in integrity/not build in confidentiality

CW: Lab experimentation.  If cache in the middle, of course better.  WIth prefetching video rate much higher

Marie-José Montpetit:  prefetching based on popularity?

CW: prefetching on the existing session (e.g., prefetching in parallel with client requests).

Multi-source video.  Question mark.  What multi-source v. mechanisms would look like.  May be network coding.

DO: dont have answer either.  dns tricks, load balances... oppose to inherent multi-source distrib. in icn where you can go different way.


what CCN semantics give you. what can you do this.  can i/d exchange be leveraged?
metadate shared with network?  different types of interest for data and meta?  can manifest help/populate fib with manifests?

manifests with location?

interests set path for data. back to 90s.

requesting chunk of video stream. can interest set up reservation on the router (rsvp)?

Preliminary ideas.

Open for discussions: abstraction in icn suited for video distr.  store and forward mechanisms. there is a gain, how do you get in practice. transport.  QoS.
what kind of shape document on this would look like?

* * *

Mark Stapp (cisco).  Just say no: authenticated denial for NDN.

what should i do if i get interest for the name that doesn't exist.  you can drop it or you can create "message" where you take you private key, sign name of the interest (authoritative for some part of the namespace).  A little bit naive.

- If do nothing: you can't say no.  Current default ~ 4 sec.  Client waits 4 sec... Seem weak from flow control/network.

- public key crytpo: also not an answer.

some sensible ways.

idea. client ask for something that doesn't exist. interest shows up somewhere.

the returned:  auth. fo piece of namespace that include name gap.  I'm willing to produce extra info in the sorted list of names.  Will not respond to the input, but will find position in the sorted list of names.

gives a way to give strong deina without on-demand public key crytpo.

Another things.  The thing about gap is cacheable.  Router doesn't necessary need to forward those interests.

Alex Afanasyev (AA)

DO: abstract from AA question. approach like this prsumes: it is easy for somebody who produces names to know all the names that may or may not exist.  opposite to dist. where distributing info about names is expensive.

for somebody who creates name objec.  has shared state with everobyd else in this namespace.

RD: you cna generalize farther.  Entity produdicng: knows gaps.

if you believe name creation is reasobly centralize (sharing is cheap), then you can use it.
If not true, other mech. needs.

Nacho: ask node that cannot auth. note that cannot deny.  You ask all nodes?

RL: if you cannot figure out?

MS: personal view: sensors will send a samle with naming that understood by collector only.

M(parc): group publishers that cannot agree than there will be no efficient routing.

RL: cannot be efficient routing or name generation.

MS: there is a mechansism  if you know a gap, you can sign a gap.  Much better than signing random thing "attacker" sends.

G.Q.Wang: yellow pages service provider.  Google-type of servive.  Why don't use the same approach to ... gap.  Get the name that is authenticated by somebody.
you wouldn't get that name

MS: there is no problem you have good names and get back good data. the problem what happens when you ask for something that is not there?

no DNS. even DNS, object may still not exist.

Jim Gibson: signing and caching. Comment on dynamics.  How do you manage long signed gap

MS: long-standing problem managing the cache.  up to the producer.  it should make reasonable judgement. with 75% static content on the internet, it is "permanent". Goal of suggesting caching, push back various ddos attacks.  cacheable deniablity huge thing in dns.  we need same benefit in ndn.

Christian: 2 things: no such route and no such content.  Very hard to link them one-to-one

MS: "no such name".  not making proposal for internal network messaging.  this could be flavor for nack message.  (will be talk later)

Ravi: avoid denial of service attacks.  you could exploit to ?  you learned some name, not trying to avoid malicious users.

MS: gets harder. ...

what dns does: doesn't send real names.  tells hashes.  another possibility: auth. names. produce hashes. then sort the hashes. ordering hash versions of the names not directly tied, but gaps still exist.

Cerdic: if hashed properly. there will be gaps everywhere.

MS: not per-name. send back gap.  You can compute hash name and verify.  Number of gaps = number of names.  Doesn't change mechanism, changes what is exposed in the denial.

potential to expose. deniability for the whole chunks of the namespace without need to expose actual namespace.

Challenge: if producer obliged to perform hash computation.  If you give me stuff and force me to do hash that can be expensive.  Can we force the client to do the work?

If client wants deniability, will be willing to compute hashes along the name.

Cedric: how to revoke stale cached content? need to remove all the gaps that cover that content.

MS: if the client send bogus value, hurts the client.  if client sends a bugus name.

manifest-based denial.  distinguished type of data, recognizable by the network.
Catalog tells you a bunch of names.  It can say it is "exclusive set" of names.  The act of producing a catalog of names, producing list of valid names (there are no children there...).  + example

AA: there could be complex processing of manifest, which could complicate cache processing (to enable cacheable deniablity)

MS: manifest format TBD

dedicated denial manifests. you may not want to provide real names of the content.  you can create a kind of manifest that exist for deniability purposes.  Hash values that lexicograph. sorted (hash value of namespace).


Is denial necessary?  How far we should go?  What about dynamic content? How important name exposure?
What's manifest?

G.Q.Wang: what if the name is not registered in the routing scope?
MS: how do you get interest?


different question.  not about what to do with interests that cannot be forwarded, but about applications that received interests and know that data does not exist.  unrelated to routing

Giovanna: several drawbacks (..., additional state in caches, extra computeation to update, ....)  does it still benefitial/necessary.

MS: if alternative drop it, yes.  if alternative public key cryptopgraphy, yes.  bulk of content is not changeable. those names are not going to change (month, year, decade).  question: other types of content need diff. mechanisms.  how router can find out?   Want a singlan that reasonable to compute that allows to remove state from the router.

Nacho: dropping interest is not free. it consumes state all the way down.

Bj: there is no right or wrong answer. Is it something you wnat to do?
If you want to have thins, we want this types of mechaniss.

Nacho: everything is best effort. nobody saying you must reply.

* * *

Applicability and tradeoffs of icn of efficient IoT by Anders Lingers (AL)

what can we do with the existing proposals/arch. what can we not do.

IoT nodes as ICN nodes (or not). Not clear cut.

Confusion about push/pull.

How to deal with actuators.  Added a little text, but no big updates yet. Needs more discussion and work.

no dramatic changes in this version.

looking at IoT as one ICN application.

How to deal with streams of data and how to get the most recent object.


Previous draft we had iot nodes and icn nodes. iot not acting as intermediary. not probably a good idea.
Roles are different (IOT: sensing, actuation..., ICN: caching, transport, ...).  Not necessary for node to implement both roles, but possible.

Question about what will do with push in the draft.  we think that it is good to have "give me data when something happens---when fire, when tempretature exceeds..."  How to define these triggers?  Allow requester to find these triggers in some way.  Flexible, but may have scalability issues.  Predefined: more scalable, but much simpler.

iot data dynamics. 2 options: icn model where you support dynamic objects, or model stream of mutable objects.
Some sort of sequence number...

Get latest reading: "latest sequennce number" has cache implications.  if you have support for subscription mechanism, whenever you subscribe, you will get the latest reading.

Same model can apply when dealing with time.  Metadata?
Suggest / might be possible to provide mapping bw sequence numbers and real time. Timestamp for sequence number. Could be gaps.

next steps:  how to do things more realistically. how to map discussed things and start implementing and testing.  Will start working on a complementary document, answering questions to the posed questions.

* * *

CCN & IoT by Marc Mosco

ccn and ndn tlv encoding 802.15.4 packets.

look how small u need for packets to be in sensor networks.

1+0 encoding (1 byte for T and L). assumes contextual type values.

what real packets look like in 802.15.4 encap.


overview of 802.15.4.
same problem ipv6 has.  .4 has 127 bytes of MTU.  ~81 layer 3 payload.  can fudge to 93 bytes.

Assumption: 8 byte addressing with PAN ID. AES-CCM-16 encryption mac layer.  ContentObject/Data uses 16-byte HMAC sig.  12 byte name, only mandatory fields. Up to 32 byte payload.  No fragmentation.

disclaimer: can fiddle to save some bytes.  objective to stick with tlv.

compare 2-2 ccn, 1-1 ccn, 1-1 NDN

details are on the presentation:
- fixed things.
- data (name componetns, payload, signature).
- encoding overhead

Take out points:
- 2-2 encoding in IoT really big.  Doesn't fit.
- Even 1-1 is still over what can be put. Better, but still don't fit.
- 1-0  gives 16% overhead and barely fits into the packet.

- ccn 2-2  max payload 3 bytes
      1-1 23 bytes
      1-0 33 bytes

- ndn 1-1  28 bytes
      1-0  39 bytes

1-0 encoding is worthwhile.  don't have much space to include various fields, unless fragment across multiple frames.

saves a lot of bytes, but would require new specification.  Make sure that you don't exceed the number of elements, due to restricted values.

Combining in NDN

leading bits indicating format:
- 001.....  <5-bit type>  VAR-NUMBER
- 000x    type 0 5-bit length
- 01x     type 1 6-bit length
- 10x     type 2 6-bit length
- 11x     type 3 6-bit length

+ example pseudocode

Combinding 1+0 in ccn 2+2

Similar, but with slightly different details.

Presentation to check if we can go to very small encoding.

DO: some of the fields outside the security. for things outside securoity envelope.  interesting to see analysis... using fixed things inside the security envelope. will this things will survive.

MM: every name component has encoding overhead.  every component has overheads.

MS: there still interesting possibility on how things should work in the space. this is specialized space.  treat it specially and not necessarily going to support sending actuation over the Internet.

DO: less comfortable with that
Consider defining an architecture: separate formats for "security enveloper" and require support both.  choose one or another: space sensitive or not.  translation at boundaries sets warning bells.  somebody creates a tunnel, which suppose to look like link and it doesn't.  Expected a link, but it is a tunnel and world falls apart...

MM: am i allowed to use network authentication, versus using NDN/CCN message auth.

* * *

Where are the opportunities for ICN in Sensor networks by Ralph Droms (RD)

Complementary and Andrew's presentation.

sensor network geenrate data objects.  no addresses.  network technilogies don't much requirements of IP.

IETF has parallel space of protocols in IP.  Recent proposals: two forms of ipv6: for sensors and rest of the world. We don't know boundaries of the problem, but see opportunities.

Where are the places?  Let's go exploit those advantages.
These opportunities is not one place / not focusing on one technology.

Can we show that ICN requires fewer resources, compared to IP?
Are there opportunities to take adv. of specific characteristics of MAC/PHY transport to optimize ICN app/stack?

Routing in IoT requires much overhead.  Is ICN routing can be better? Geo routing?  Virtual nodes (object will be near that virtual node).
Address assignment/management (DHCP, distributed assignment).

Object security.  Are there ways in which we can use secure objects where devie is provision enough info to geenrate secure objects, getting to ICN distribution system, not worry about the rest.  (more efficient that session based)

ICN network generate object, shipping to some place (repo).   Can ICN bridge the gap with the existing network: realistically we'll have IP world.  Is secure object model good way to bridge that gap?

There is a whole issue designing for actuators.

RaviR: is any consideration: zero configuration which is issue in ip domain.  Can it self-configured.  Self-certified names?  How to bootstrap?
Is it easier or harder with ICN.

RD: Place to explore. Alternatives in IP is expensive either way.  New way of self-config. needs to be developed in IETF.  Exisitng mech. wouldn't work.  You cannot assign and defend address mechanisms.   Is there a way we can do name assignment that works "better" than in IP?

Christian: IP and new world. Directions to consider?  People leaving in IP accessing ICN content and vice versa.
Which direction is more interesting

RD: From IP accessing ICN (sensors are not interested in IP)

Christian: Home kit.  All appliances in IP space.

RD: Transition space.  Haven't thought about it....
Relates to separation of IoT devies and ICN devices.

Bj: Separation is more problematic.  Are the IoT things specialized?

MS: do they need to directly communicate with the rest of the Internet?  Plenty of stuff that nests do that doesn't involve talking to the "nest could".  Commerical nests...

DO: we are mixing set of entities... with whom going talk will be small. but where they are can be ... unconstrained.  That's create requirement "talk to anything on the internet".

MS: segregated world speaking radio friendly encoding that visible base station.

current draft: big bag of questions.  detailes scenarios: home gadgets... industry controls...,  building management...

MS: good to have specific examples in the draft with specifics

DO: not arguing use case. be careful, as they can be very biased.  e.g., enenry monitors:  under assumption, you cant monitor your power witout talking to PGE...  many instances you start with presumption you have one cloud...
Selection of use cases...  you can end up with use cases that are highly containing.

MS: like to talk about use cases and scenarios

Advocation: if work item, much more interesting to talk about scenarios

Dirk: Presented a list of questions.  what things ... actuation is one things that tangent... Async..

RD: The bigger picture of async comm. not necessarilty in place where we find advantages of ICN, but an area that should be solved.

Bj: W should be looking in ICN vector.  Use cases look not what ppl looking today, but what we can do and don't know how to do it today.
What is next step?

Andres: No point of iterating the same question.  WOuld make sense to be a little more concrete.

Bj: Another thing interesting is zero-configuration.

MM: anayze different thing we doing things. cellphone that wants to control device at home. and consisent way to store: battery cost, key operations, hmac operations, radio on for some many bytes.
What is the attack surface?

Bj: suggestion to continue on evaluation in IoT

Dirk: figure out ... common software development in one particular application.  select icn software basis.  ppl from diff. companies/projects and demonstrate... tricky...

MS: does spectrum inlcudes no-name arch. (name resolution, ...).  we cannot converge on name format.  a little ambitious.

Tuesday after lunch

CCN Control Messages
Nacho Solis

This talk will focus on one type of "feedback" message: interest return

Use case: object producer will not produce an object in response to some received interest "returns the interest" to give positive indication of "no response"
DaveO: three preconditions:
Kirk: how is the returned interest trusted?
Marc: no guarantee that interest is exactly the same as the original interest

Giovanna: why send back entire interest
Marc: alternative would be to make an assumption about what is important and just send that part of the interest

Ralph: for this path, what is behavior in "B"?

A-->B-->C (interest)
       B--<C (interest return)

B may send back to A; consumes PIT entry
B may retry; leaves PIT entry

Alex: what about multi-access link?
Marc: multicast interest doesn't make much sense
Mark: might be such a network, won't use interest return

Luca: how does this work for packet loss
Dave: there are other reasons to send interest return:
Dave: Trying to do ICMP w/o ICMP
GQ: Is this a NAK
Marc: Trying to convey more (or different) information than NAK

GQ: Why not call it "data"
Mark: because it's not data

Giovanna: How can this message be useful if the PIT entry has been deleted?
Nacho: Don't confuse PIT entry with copy of interest
Dave: If PIT entry has timed out, drop the interest return

Nacho: there is a mesage type "interest return" and a code for, e.g., path error, congestion, prohibited

JimG: are interest returns cacheable?
Marc: no
Alex: interest return could influence "strategy layer"
Jim: ah, not "cacheable", but it might have an influence on forwarder behavior
Mark: congestion notification is input into decision among multiple available paths

Neighbor messages (forwarder to forwarder)
neighbor discovery
link management
Dave: never forwarded

Ravi: DHCP?  How does a device get a prefix?  From local gateway?
Nacho: prefix may come from elsewhere
Dave: stuff of interest between neighbors
Marc: MAC layer security
Dave: generally link-layer parameterization

Christian: what about talking to the caching system?
Dave: haven't thought about it

Nacho: we are working on an implementation

Packet Formats
(slide 2) Alex: is there a goal of contiguous block signing?
Marc: yes

(slide 9)
Ralph: global TLVs; registry?
Marc: registry but not (necessarily) global TLVs
Alex: agree with Ralph; global values may make parsing error recovery easier

(slide 14)
There was a "creation time" that was really a "signature time"; now, time is part of the signature to indicate a "signature time"

Nacho: "what is a time"
Marc: UTC+milliseconds

Update on ALU packet format
Massimo Gallo

Now using 2+2 format

Fixed header ("convergence layer")

(Name encoding)
Nacho: What is the nonce used for
Massimo: Interest with same nonce does not add to PIT
Nacho:  dropping by nonces breaks the protocol
Mark: hides existing problems and adds new problems
Nacho: for breaking loops, it breaks aggregation
Massimo: list of nonces is enough, not significant additional state
Mark: loop prevention requires keeping nonce entry for as long as loop diameter 
Alex: hop limit does not preclude nonce
Marc: backstop of hop limit or other state in packet is required
Nacho: nonces won't break loops and will break aggregation

(Name encoding)
Nacho: is there a separator character between components?
Massimo: yes
Nacho: can the separator character also be a valid character in a component?
Massimo: no
Nacho: alisaing is now possible; have to escape the separator characters

Mark: hash the whole name then probe; how is the algorithm different
Massimo: real difference is just the difference of parsing
Marc: could rearrange computation to save intermediate results so multiple parsing is linear
Mark: data transport is the expensive part

CCN/NDN Wire Format (Huawei)
Ravi Ravinindran

Focusing on future considerations

Nacho: why is one form of TLV bad?
Ravi: may need for different types of parameters
Nacho: not including XML, why different schemas
Ravi: routers should be able understand different schemas
Marc: no single TLV can encode all possible Vs
Ravi: provides more richness
Nacho: why is it a problem of any encoding?
Ralph: example?
Christian: 1+0 vs 2+2
Dave: can see how transformations work outside the security envelope; within secure envelope, message protection can be based on wire format (precludes transformations) or based on canonical representation (allows transformations to canonical)
Mark: would be helpful to have constraints - like a common format - so we can get to interop experimentation; freedom and switching between formats is a hindrance now
Luca: tradeoff between experimentation and fixed format
Mark: we haven't converged on anything fundamental
Dave: argument against Ethertypes is no common negotiation to talk to the other endpoint
Mark: we can't even agree on names
Dave: that's ok with a magic byte that does demultiplexing
GQ: design target for ICN is applied lots of places; no common agreement on requirements for TLVs

Elastic TLV: retain 2+2 but allow different allocation of bits between T and L.

Dave: will have to pad because chunk length has to be included in signature if not actually included on the wire.  Go look at security impacts
Nacho: send number of GB, thn number of MB, then number of KB then B

GQ: ICN will run on IP; while duplicate what's in IP
Nacho: why not use HTTP?
Massimo: why design a wire format if we always send over IP?
GQ: don't have to chop packet into 64k if MTU can carry it
Nacho: huge objects require that huge objects cached, carried around everywhere
Luca: big objects reduce cache efficiency
Dave: we run 100GB links with 9K MTU; when will that change?
Massimo: multi-GB "thing" is *not* a packet
Ravi: there are applications that use GB messages
Dave: all huge datasets are actually lots of small objects - CERN, medical images, etc.
Marc: new message type for "aggregation type"
Massimo: still don't have 1GB for a single frame

Forwarding Target
Dave: extra chunk must be covered by security envelope
Christian: why not wait to delivery and let receiver decode
Dave: needs more work than just a new TLV

Shareable/non-shareable content
Nacho: caching useful even for these communication modes
Alex: useful for measuring data plan performance
Dave: dense topology so packets all go across different routers
Dave: can do strong symmetry - packets from A to B follow reverse path fro B to A

Dave: if we need to bypass PIT/CS for conversational traffic, we have a scaling problem
Ravi: Can reduce resource requirements for PiT
Dave: 10,000 calls in a router is 10,000 PIT entries
DIrk: does the tradeoff between extra work and reduction in PIT have a meaningful effect on overall system?

Interest notification and handling
Interest w/ data
Marc: makes cache poisoning really easy
Ravi: cacheable object is optional

Usng selectors
Optional protocol feature

Context based name compression

"Caching as a service"
No state in the middle of the network

GQ: what about bigger MTU on 5G?
Marc: Infiniband supports 64KB frames; nobody uses more than 4KB...we need evidence for supporting multi-GB frames

----------- Wednesday 1/14/15 ---------------------------
9am NDN Packet Fragmentation: Hop-By-Hop or End-to-End (Alex Afanasyev), 15 min

Why NDN uses hop-by-hop fragmentation?

het net, different MTU sizes; 
paper "fragmentation considered harmful"  (Mogul, Sigcomm) -> authors urge for "transparent fragmentation"

NDN architecture: give a name, network returns data

NDN and fragmentation: 
- Interests cannot be fragmented (routers need whole question to answer it)
- Data should not be fragmented: to cache, the whole packet is needed; the same data requested by multiple clients with different path MTUs; 
- PIT entry satisfied only when Data packet arrives or time out occurs (routers are required to reassemble Data packet) -> when packet size > link MTU, NDN performs huh fragmentation & reassembly

DO: you did not mention the most frequently used reason to avoid hbh: delay.
AA: it's on this slide
DO: you can do  hbh with cut through
AA: there is potential for repeated FAR which causes delay. What kind of optimization? One way is to do cut through in some cases (not always possible)
AA: repeated fragmentation can be avoided by careful selection of segment sizes

NDN at research stage, not yet fully considering the performance overhead. 

HBH fragmentation is the only option for NDN

MM: are you doing multi-link PPP; begin/end flags?
AA: we haven't defined for this specific protocol

RR: effect on real time services?
AA: one more optimization technique I did not mention: you would not bluntly send a large data packet; as an app developer, you have to consider in which network you are sending data packet. There is no reason for you to send data packet in some of the real time cases. 

RD: one of the details you mention, would you recommend reliable delivery of fragments in HBH? 
AA: simple answer: yes; more complex: it depends. You would need some type of BE reliable transport
RD: and you need to be careful of the impact on congestion control

DO: how much does this increase the attack surface? FAR on physical link does not increase, since you would need access to this link. But for this type of architecture, a lot of running atop tunnels. Many opportunities in between what is logical link to do injection attacks. Are there new games you can play against the FAR scheme
AA: I suspect yes
DO: particularly if you run over UDP tunnels or ethernet bridging, urge you to consider attack issues. 
AA: in some environment, no tunnels; 

BO: still, if you make an architecture, it should run everywhere.
DO: potentially avoid some complexity

LM: it's not so simple to be MIM in a tunnel.
DO: I can give you interesting attacks; say you learn the decapsulating ID of the tunnel, attack that node 
LM: in GRE tunnels, the source is authenticated
IS: samed on shared channel.

RD: interestingly, the IETF is considering a proposal (they use HBH for 802.15.4 for 6LOWPAN) to do e2e; look at their arguments, keep it in mind.

MM: CCN uses e2e, would be nice to compare with others, have a proposal with CT.

-------------Named Function Networking -----------------------
DK: wanted to continue the Paris discussion  and see what is the reasonable design space for computation in ICN; what is a good way to implement these functions; all based on CT's work. 
Applications: network function service chaining; aggregation/filtering in IoT, others?
Objective for the discussion is to figure interest, benefit, should we continue working on this?

Computation in ICN: names can represent static data or dynamic computation results. 
Immutable names, idemptotency, dynamic computation. For example, live video chunks can be considered "dynamic computation." Name is immutable, request processing idempotent. 
Dynamic computation: request for NDO triggers dynamic computation; web service modeL place for computation is fixed
NFN idea: make computation an ICN node capability: evaluating expressions and creating result NDOs.

Arumaithurai et al: expl[oiting ICN for flexible management in SDN, ACM ICN 14; policy specifies where packets/function go and has to be implemented; you couple policy spec and implementation in controller; inflexible approach since all decided in one central place. Idea in this paper is to separate the policy specification adn the forwarding decision using "normal ICN mechanism." Chain of function is brought into ICN network as a label stack. No need to invoke a centralized controller. Instead of dealing with 5-tuple, you name the function logically and in case there are multiple instances of function A, you can take the best one using already available ICN service. Stateful services need to be handled specifically (say stateful middleboxes).

ICN for service chaining: uses ICN routing and forwarding for implementing chaining policy in the newtork; benefit from ICN routing/forwarding (multipath, load-balancing);

What if? What if programmability and computation were a first-order principle in ICN networks

Christian Tschudin: Named Function Networking, service chaining, big picture, division of labor boundaries

I will not focus on implementation detail, but provide a mindset and how we see the landscape

Session overview: service chaining (DK); gentle introduction; NFN in one sentence

Raising the semantic level of the network API = filling the gap between data object abstractions and network. 
Filling the gap: redesign transport fabric to handle names; new name-to-FIB mappings; "name space operations" -> from publish to exploration, mgmt and removal. 

From Named-Data to Named-Functions: raw data in abundance, but clients want cooked data.

Example: /downScale( /this/video) /getAverage( /sunShineHours/in/CA, 2014) /geoFence( /my/heart/rate, /my/gps/location, 10ft ) <- problem of restricting data acess!
The goal of NFN: clients name the desired results, server-agnostically; network is in charge of finding execution space

Network does NOT execute, NFN only orchestrates the computation by juggling around names and trigerring exec, later returning the collected result.

MS: it would be nice, but I don't have no way to know if the results are secure; etc.
CT: you are making the assumption that it would not be expressive enough
MS: but what is different from other cloud request? 
CT: today you make some filtering already. For instance, in CCN, you say, I dont' want this CCN hash or this publisher; you can make some filtering saying: only from this cloud provider. There are many parameters that you can add. Currently, you are restricted to only filtering data
IS: in CCN, we only say: we want that hash; we don't say we don't want that hash. Also: all exmaples you have said thus far, we can do already
CT: I'm not claiming to be different, just trying to generalize existing and open the box
RR: my comment regarding the dynamic personalization would be at the edge of the network (MS: untirely unsupported assertion; RR: let me finish) When you make the data more contextualized, then this become more valid; more context parameters is required; simple name is not enough; you need more rich; 
IS: nobody is arguing against in-network computing. 
RR: more real time basis
MS: this is a ridiculous statement, it is done in your web browser in real time
CT: packet formats, how much expressiveness can be put in there. Some of the packet header considers only forwarding part; but more is needed; 

Results as Names as Programs: lambda-expressions: most general approach, probably not your cup of tea.
Other ways of expressing results. NFN enables choice: /iFeelLucky( Hotel Sonesta Boston)
MS: when the results come back, how do you trust the results?
CT: that name is provided by google, so you trust google
CT: google could be in the name, but I wanted to show a non-hierarchical name.
IS: how is this different from what we do? Right now, I can have a packet that I call /iFeelucky
CT: that's exactly the discussion I want to have, we can have this nameoutside of the hierarchical structure
GC: why do we need a new framework to do network programming, to do something that we cannot do with the current framework; can you do some example to do it?
CT: composition of service do not live in the network; the operator configures outside of the network; the network can find alternative automatically
MS: what do you mean by " in the network": transparent by client; configured by network; the fact that I type a URL and conjure several DCs in the Eastern US, I get a result,  it's transparent,  it's a simple question and I get composite dynamic results that get from the network.
CT: for a home network, I can access the raw result, or I can access the average of the temperature in the first floor; you populate the network with data and functions and services. You have to delegate that task
IS: I'm not sure what the network is. In our discussion, we talk about packet format, stuff that every nodes need to know to inter-operate, vs functions that only some networks will understand. 
CT: the question is what is the name? You see data, I see an entry to a service. 
MS: interest messages to do sensor actuation, the goal is not to retrieve data, but to use the interest to change some state, this is already achievable in the current framework. 
DK: dynamic computation is not new, exists today, ICN needs to suport; but your exmaple of triggering several processing steps in multiple DC is different. All I needed to compute the composite steps, in this approach, some of this processing can be pulled where it makes more sense; the ICN nodes that do forwarding and caching today would in some cases be enabled to do some of the processing that is useful for some user's service.
MS: load balancing, move load within or around DCs, all this is existing, and the reason my laptop is not computing averages to you is that you have no reason to trust the results and that it's a burden on me. 

NFN foor network tasks: NFV, IoT, Mgmt

DO: if your mental model is: I want to name a function  and the function figures out what data is needed, and return a result. Is there a difference between these two things, or is it new. Which is name related, or which implies different function of the protocol?
CT: I use the function view, for instnace /rightmostChild function, it's a name space operation, can the network fabric answer this? The function is helpful, there are different ways to map them?
IS: are you expecting everybody to have permission to ask?
DO: everybody has permission to ask, but who gets the answer?

PP: new class of names that involve different kind of action in the network, that require data object, but very different process. When I express this name, I don't request an object, I create an object. Is it the same protocol, or a completely different protocol.
MS: or is this just an application?
BO: you make this point, try to be a bit more constructive
DO: return me the home page of NYTIMEs. com. The name schema, something else associated with that name, it knows what is associated. In your network function, you would have "compose home page" and you could get CNN, NYTimes, LeMonde, you make the function you want to do "get the most recent news" the primary thing that get represented, and the particular input to that are parameters. It seems to me you want to have to do more than this, this is just a name schema function. Are there some modules that exist in a lot of nodes in the network that is generic enough that it.
JG: how about "translate the NYTimes home page"?
GQ: when you ask someone to provide you a service
MS: but you're not asking anyone to provide you a service
RD: I do care, maybe I only trust the google translation service
MS: or the government will censure the content… where is the trust? I feel it's incumbent on you to say how the people asking the request is supposed to understand. Or is it an application, where the provenance can be checked.
CT: I want to know 
MM: biggest problem in service composition is the description of the data itself; big JSON descriptions of the expected input/output so that the data format flows through. Is there anything that addresses this?
CT: if there are different representation schemes, you make a function that translates. Now, there is no way to select and recompose.

Search for a good "expression language": exact match, selective match, DB query languages, datalog, intentional naming, prolog, lambda expressions. How much should be in the network?

PP: We're asking for an object to be created and delivered; there is a level of indirection; the function exist and the object does not exist. 

NFN in one sentence: "NFN is an ICN style where a requests carries at least two names in order to be satisfied."
MS: that exists already, we have published something that carries other names outside of the packet name for a year and a half!
DO: I think this is saying something different! Payload is opaque to the router! Because this functional model has to component, name of the function and name of the argument, rather than opaque payload, the intermediaries can understand and use with the routing/processing. It is different from having payloads that are opaque to the intermediaries. There are elements int he protocols that have other names. 

"role-based architecture" (braden/faber/handly, hotnets 2002) provide header space for more than one "network function"

Roles in CCN (would be nice if NDN could add this too): interest name (is for the forwarder); interest payload and opt header space - for the rest of us.

RD: what is the impact of this on the generated data object. Is this response is cached some place, how do you differentiate from other requests?
CT: I can't answer. In the lambda-calculus, there are anotations. But I can't generalize. It's one of the interesting discussions. 
RD: I don't understand the service chaining, what you are applying the service to is the interest message; I would have thought 

Gradual spectrum: stupid network - CCN- "domesticated NFN" - lambda calculus

-------------------------CCN Lite update ----------------

CCN-lite is a forwarder (ccn-lite-relay). Pure C, still light in code size, modular; runs in user space and as a linux kernel module
CCN-lite is a toolset: peek, fetch, mkContent, mkInterest, chunkify; the tools work witht he ccn-lite-relay, bt also with the NDN testbed; 'universal' pktdumpt, autodetects encoding
Incomplete at crucial places: signature validation (except for mgmt channel), routing protocol, selectors
CCN-lite is multi-protocol: ccnb, ndn2013, ccnx2014, ito2015, cisco2015, rpc
includes a fully functional NFN
Roadmap 2015: soon v0.2.1 with "boston packet format"; April/May 2015: interop (NDN done; CCNx1.0 forthcoming); packet tap and reinjection interfaces, python binding, TLV encodings for higher level stuff (Rivest's S-expression)

CCN-lite: What is your wishlist? Ask and CT shall try!

GQ: does this work over any L2?
CT: there is a raw ethernet access; no L2 discovery.

Day 2, session 2, 11:00-13:00

[Topic: "Scalable point-to-multipoint communication information centric networking" (BO)]

- RR: Is endpoint aware of first router
- BO: Proxy discovery

- RR: How is DNS done
- BO: Lookup up publisher in DNS. <missed sentence>. Could do everything with DNS.

- RR: Names are flat
- BO: Yes, no structure to names.

- RD: Can you explain more about formal ICN semantics of pub-sub model? e.g. is sub request an interest? How do responses come back?
- BO: We don't use CCN naming. Publisher publishes and registers name in name resolution service. Name is made known to subscriber through some unspecified means. Subscriber registers, which gives ACK and sets up a series of breadcrumbs for later. Notifications of new data flow along breadcrumbs to subscriber.

- GQ: Do clients share same flows or different flows
- BO: Haven't thought about that yet?

[Topic Area: Implementations I]

[Topic: "CCNx Portal API" (GS)]

AA: What about security, e.g. of control messages. Who gets to register names?
GS: Control messages are rate-limited and internal to the node (i.e. these aren't the "Interest Return" control messages). Nacho will talk about end-station behavior.

[Slide on "CCNx Assembly framework" (which abstracts away network messages)]

DO: When you say "Name" do you mean "Name prefix"
GS: May be Name prefix, may be Manifest name

DO: Let me see if I understand. If I ask for a name that turns out to be a manifest, does that get all the data?
GS/NS: Not necessarily

[CCNx 1.0 Software]

DK: Does the download give me binary?
GS: Yes, it's binary. You get header files which contain doxygen tags and can be used to generate doxygen manual. It's the "tutorial subset", which is trimmed down vs. what's available in the future. 

[Topic: "End-host behavior" (NS)]

[Possibilities behaviors for interest name LPM match in end host with multiple publishers, and how it might be the same or different as the behavior of routing at intermediate nodes.]

MS: Is this a problem we need to solve to get NDN to work, or are we introducing a new model?
NS: My preference is that end-station behavior matches routing behavior and that whatever gives an entity permission to advertise a route gives matching permission for registration.

There needs to be some level of entity that is coordinating and preventing random entities from poking holes in someone elses namespace unless that's appropriate in some sort of wild-west name space. (It's the green box labeled "Network Naming" on the slide)

CT: We've had an assumption of single root for routing (and that's a significant piece of work)

DO: Two separate items are being thrown into that green box.
    - Who ascertains/verifies whether someone will be able to publish data under a prefix with keys that people will believe
    - Who ascertains how interestes are routed?
    These are neither the same nor are they orthogonal and unrelated.
    They aren't the same but if someone can inject routes, they can create black holes.

AA: Also there's a strategy decision, ultimately everything's about data, and
DO: In failure cases, can get two content objects, only one of which is believed.

NS: We're not talking about strategy. Strategy can choose to go to node 2 or node 1
MM: CCNx 0.x had annotations for expressing what was wanted at intermediate or end node, not sure what NDN currently has, would be great to agree on a set of useful annotations.

CT: Is there an implicit question of whether we should work on the mechanisms to assemble a routing cloud?
NS: Yes

MS: Shouldn't combine topic of dynamic content generation and <?>
NS: Yes, we're working on local registration

Topic Area: CCN/NDN Packet format II

[Topic: Highlights of NDN packet format (AA)]

Slide: "Encoding Key-Values in Names"

AA: Applications have freedom to use names to express anything they desire.
DO: Do you mean that names are picked independently by apps, or is there still a central registry that ensures no key aliasing?

NS: Need to know which app generated data, to retrieve it.
AA: If you're retrieving data, you need to know what you're retrieving.

(Discussion about type system for names and what's global vs. application-specific.)
NS:  Within a name, are you saying that only the segment type is global and other items (e.g. version) is application-specific?

NS: Is name type space protected, to avoid aliasing problems between segments and binary data?
AA: Can't get confused between segment and binary data.

NS: For instance, I believe there are tools to put objects into network and retrieve them. How does tool know what to retrieve? Does segment need to be included?
AA: Only retrieve a single object.  Simplification for application developers, but everything is application logic at this point.

MM: Given that you can to 1/2/8 byte types, why should key/value be two name components instead of having key be the type.
AA: For variables, I'd rather use names than numbers and associate number with name.

NS: Do all your named components have types?
AA: We have types but only 2 defined at the moment: named component and (implicit) digest/hash.

DO: What's the difference betweeen this and CCN?
AA: There's a typing system with two types (named component, hash), and another application-specific type system within named component, that an app can choose to use or not.

NS: Okay, why did you have the two types in the (outer) type system?
AA: Need to know if a component is a hash because affects forwarding.
DO: Hash is a separate TLV part of the name, rather than a separate hash restriction as in CCNx.

CT: Would you be interested in having a version 2.5 to allow interoperability between NDN and CCNx fheader even if NDN doesn't care about those fixed header fields?
AA: Not sure

[Topic: Cisco packet format (MS)]

LM: Interest packet vs. interest message: is term overloaded?
MM: We've been thinking about different terms for packet and network.
MS: It's a useful distinction that we're capturing with packet vs. interest.

GQ: For definition, which is primitive? packet or message?
MS: Both. Potentially can carry messages in packets without needing an encapsulation scheme. Can decouple application-level message from packet.

RD: Can network nodes find everything they need from packet type?
MS: No, need to look at name, and at items such as lifetime that are in message part.

RD: Do routers need to know how to handle cross-product of packet type and message type.
MS: To be determined.

[Topic: Packet format comparisons (MS)]

MS: What should we do to make progress with packet formats. What about Nonce? What about RR's presentation yesterday.

DO: RR's presentation yesterday included some items that are packet encoding (e.g. MTU) and others that are functional items. Let's put aside functional items (two names, routing hints) aside and talk about the function and, once that's determined, come back to how it affects packet formats, and let's talk about the items that are purely about encoding. Which items go into each bin?

LM: We don't care about Nonce, got that from older CCNx that we're experimenting with.  We care about hop-by-hop, fragmentation, caching, how to handle loss and whether it's worth retransmitting.

DO: Likely some hop-by-hop things are link independent (hidden from L3) and others not (handled as IP-over-foo that sometimes need a layer 2.5 and other times not). We're talking here about the hop-by-hop items that are link independent.

MM: Would like wire format to be able to run on L2 without additional spec for the 90% case
GQ: Not the 90% case, consider wireless.
DO: If we can start by focus on the link-independent items, sticking to the ones we're pretty sure we need (e.g. might be able to skip QoS now, and avoid the situation where DSCP is nominally link-independent but doesn't map smoothly onto the various L2)

LM: Looking for a way to be positive in how to go forward, we need more experimentation with different name encodings to get more data, not yet ready to pick an encoding.
MS: Yes, should determine costs of various schemes and figure out if they're worth it.

Afternoon Session (2-3:30)
DO : Dallas meeting agenda, make concrete progress on the packet format, list of things we agree and dont agree on.

Congestion Control issues to be taken up in the dallas meeting, contributions welcome

Other aspects anything that folks bring in.

BO: Any other topics of interest ?, 

NS: Packet format scope discussion ?

BO: Mark's documents as that starting point

NS: Does each of them get their own proposals ?

DO: A lot of the new items bought in other than packet format..start with the base level of things we all agree on, discuss other proposals too

NS: How long are we going to continue these basic topics ?

BO: Do we see any alternative ?

DO : Chairs have prerogative to chanelize the discussion

DO: Multiple groups can  converge to propose a RG document

NS: How many people ?

BO: Majority should be in consensus..

DO: Concrete 

G.Q: See the consensus, but see some gaps, folks see things from different angle, like taking a performance perspective, others take an application view. If the gap is wide, do we need a requirements document ?

DO: Not a standard for requirements, as we dont come up with a standard. The crieteria is to evolve a research agenda.

G.Q: Keep the flexibility to provide scope for experimentation, 

NS: One of the considerations is how do we get this to run in the real world. We have to start some where, we have scope for extensibility. But some consideration towards performance has to be considered.

G.Q: Goes back to seeing things from the different perspective, e.g. IoT is a good example. 

NS: We dont have enough proof to show it is not good for IoT, we need solid proof...

G.Q.: We envision a single protocol, for all type of the link layers. 

NS: But we have to see, why the packet format is not good enough 

MS: We learn from observations what new consideratoins have to be considered.

NS: Hopefully we can converge to a format, not go on forever

G.Q: Atleast we all converging on the same protocol, is a significant first step

DO: Can we converge on what we can agree on in dallas based on the different proposals.

DO: Recurse on the comparison draft, to make it more concrete

DO: AA presentation on hop-by-hop fragmentation, would people be interested in taking up a hop to hop working draft ?

MM: Working on a draft (Parc and some other collaborators)

NS: Would it have an affect on the protocol and packet processing ?

AA: Consider a end-to--end path MTU discovery, along with hop-by-hop fragmentation, they complement each other

DO: Nice suggestion, should consider into the discussion.

NS: Existing document that needs our input.

Action item for the chairs to identify documents that are close to be finalized. Communicate with the group.

RR: What is the course of action for the other video/iot document ?

DO: Should progress to work to make the work more concrete.

CW: Prepare a architecture draft for video, what benefits with ICN ?

DO: IoT Document ?

RR: We plan to follow up the ICN ioT challenges with architecture document

DO: Do we meet for multiple days at Dallas...interim meeting on Sunday ?

DO: Congestion control work in dallas ? , poll on the mailing list

DO: Any thing else ?

Arrival flight/Time
Departure flight/time
Dave Oran
oran at cisco.com
Dirk Kutscher
kutscher at neclab.eu
Royal Sonesta
Anders Lindgren
SICS Swedish ICT
andersl at sics.se
Early morning Jan 13
Boston Park Plaza
Jan 15
Ralph Droms
rdroms.ietf at gmail.com
Marie-José Montpetit
mariejo at mit.edu
Massimo Gallo
massimo.gallo at alcatel-lucent.com
Jan 12 afternoon
Jan 15
Ravi Ravindran
ravi.ravindran at huawei.com
Jan 12
Royal Sonesta
Jan 14
Nacho (Ignacio) Solis
ignacio.solis at parc.com
Jan 12
Royal Sonesta
Jan 15
Marc Mosko
marc.mosko at parc.com
Jan 12
Jan 15
Glenn Scott
glenn.scott at parc.com
Jan 12
Jan 15
Christian Tschudin
U of Basel
christian.tschudin at unibas.ch
UA1263 - Jan 13, 6:57am
Royal Sonesta
LH423 - Jan 14, 4:10pm
Börje Ohlman
Borje.Ohlman at ericsson.com
Jan 12
Royal Sonesta
Jan 14
Alex Afanasyev
alexander.afanasyev at ucla.edu
Jan 12
Royal Sonesta
Jan 14
T Sugerbaker
tsugarba at you-guessed-it dot com
Jan 12
Ryota Ohnishi
ohnishi.ryota at jp.panasonic.com
Jan 12
Royal Sonesta
Jim Gibson
gibson at cisco.com
Sergey Slovetskiy
sergey.slovetskiy at ericsson.com
Jan 12
Royal Sonesta
Jan 15
Giovanna Carofiglio
Jan 12
Royal Sonesta
Jan 16
Luca Muscariello
Jan 12
Royal Sonesta
Jan 16
Jim Welch
jim.welch at ineoquest.com
gq.wang at huawei.com
Jan 12
Jan 14
Cedric Westphal
first.last at huawei.com
Jan 13 6:57am
Jan 14
Edmund Yeh
Northeastern U.
eyeh at ece.neu.edu
Milad Mahdian
Northeastern U.
milad.mahdian at gmail.com
Ran Liu
Northeastern U.
liuranapply at gmail.com
Wen Tong
tongwen at huawei.com
Jan 15
Mark Stapp
mjs at cisco.com
Paul Polakos
ppolokos at cisco.com
Jan 13
Royal Sonesta
Jan 16
Ashok Narayanan
ashokn at gmail.com