icnrg — IETF118

Date: 2023-11-07
Time: 09:30 (UTC+1)
Chairs: Dirk Kutscher, David Oran
Notetaker: Ryo Yanagida, Michael Toomim, (add yourself here)

1 ICNRG Chairs’ Presentation: Status, Updates

Speakers: Chairs

2 Reflexive Forwarding updates

Speaker: Dave Oran

3 File-Like ICN (FLIC) Update for draft -05

Speaker: Mark Mosko


Lixia Zhang: Why do you offer these flexibilities? It's up to the
producers how the segments are named. We are trying the equivalent, but
much more simpler sequential numbering of segments
Mark: Not recommending the particular examples of non-contiguous
numbering. We don't enforce any particular numbering.

Lixia: I suggest you make people do the safest way.

Mark: We do recommend you do it the obvious safe way.

Ryo: What's the next step?

Mark: I want to get Flic re-implemented. (Code is out-of-date from
draft.) I'm willing to help anyone who has resources to work on that;
just don't have time myself. I'm looking for someone to help!

Michael: It looks similar to things we are working on. When editing
files, it's more convenient to have contiguous blocks, numbered

Dirk: This is connecting to incoming work on State Synchronization
(c.f. braid.org) and set/change reconciliation.

4 Collection of Traffic Traces on the Wide-Area NDN Testbed

Speakers: Davide Pesavento


Ryo: What did you mean by synthetic?

Davide: Packets generated randomly, to some distribution on some

Ryo: On the throughput plot, did you say UCLA has the producer?
Davide: yes. So why is there less traffic on memphis?

Davide: If packets by all three routers were sent, then the UCLA
traffic would be the sum of the three. But that's not the case.

Ryo: Ok, so the traffic you see on UCLA is the largest, but it's not
quite the sum of all three of the others. i.e. caching/interest packet
aggregations are working

Ryo: For troubleshooting how far a packet goes -- how could you
measure that?

Davide: If we had all the logs, or a snapshot of the state of the
forward at every point in time, we could construct everything that
happened. But that would use a lot of storage and bandwidth to move that
around. We'd like to somehow compress all that state to something more
manageable to send around at a large scale.

Ryo: I suspect the logs of forwarding decisions (timestamps, names,
which face it went out to) could be potentially useful for this.

Davide: That's possible.

Yusaku Hayamizu: I'm interested in video streaming, like dash.
Curious about your implementation for video.

Davide: Based on Shaka Player
(https://github.com/shaka-project/shaka-player). Runs in browser, we
replaced the networking layer with a typescript NDN library
(https://github.com/yoursunny/NDNts). Packages stream requests in NDN
packets and sends requests as NDN interest packets.

DaveO: This was much needed work, thank you. Instrumentation
interests might be different between application dev. vs net. operator.
We need multiple things that are tuned for the two different needs. Path
discovery (soon-to-be published as experimental RFC) will allow the
application to tell where the packets went and what forwarders they
visited. Traceroute (also about to be an experimental RFC) can alos be
bery helpful. If we have these for NDN, application can ascertain where
the packets went.

Davide: That is a good idea. We are prioritising application
developer's needs, given that we need more applications and we need to
make the devs' life easier for that to happen.

Qi Zhang: We need real traces. Perhaps we need a model in order for
this to scale. Any plans to create models?

Davide: Agreed, but we don't yet have a plan to do this ourselves.
We hope to enable others to do that.

5 Collective Communication Optimisation

Speaker: Kehan Yao


Mark: Hard to figure out what the target is. Optimization work
exists in various forms.

Kehan: Yes, various work exists. We want to provide more general
solution w/o custom hardware/L2 protocols, that can be deployed widely
across the Internet. We'll focus on transport, but some work might exist
in the network layer. How to scope the area of work is needed.

Colin Perkins: Good to discuss this widely. You mentioned potential
work in various area including network layer, and you are presenting
here so presume you think ICN might be a good fit. Can you elaborate on
how you see this could work?

Kehan: I'm not an expert but thought this could be interesresting
for this group

Dirk: The intuition around is that [... TODO: fix]

Colin: You mentioned the deployment in limited domain. While this
makes sense in developing a product, but as this is a RG, it would be
good to consider and discuss research challenges e.g; how to make this
deployable in wider domain.

Lixia: Security is not an option for this work—it is a must.

Dirk: This is a initial introduction to this work. This could be a
interesting topic for this group. Current performance-focused
deployments use existing protocols. New protocol that can merry security
and performance requirements would be very interesting.

6 Distributed Architecture for Microservices Communication (DAMC)

Speaker: Xueting Li


Colin Perkins: This is great; we find it interesting hearing
large-scale systems. How are ICN concepts employed in the design, how
did they help, and what are the ongoing challenges applying the ICN
style of protocols in this domain?

Xueting Li: I'll delegate this to my colleage (Aijun Wang) onsite.

Aijun Wang: Centralized infrastrucutre has problems with
extensibility & manageability. ICN we base it on URL rather than IP
address; content rather than IP. Extensibility or forwarding traffic
based on contents.

Colin: So the challenge is efficienty?

Dirk: Would you also consider other ICN design options? Would you be
interested in getting more feedback from the group on ICN design options
for this problem?

Aijun Wang: We would like a protocol or product for ICN-based
routing and forwarding.

Ryo: One of the design goals was improving end-to-end telemetry.
We've talked in this session about how difficult it is to trace all this
data. Do you have any approaches to solving this issue? A lot of us are
discussing this challenge.

Aijun Wang: We want to use (current?) solutions.

7 Buffer, Wrap Up and Next Steps