Location: Park Suite 6, Hilton Vienna Park, Vienna, Austria
Date Time: 2026-07-22, 1600–1800
Chairs: Dave Oran, Ryo Yanagida
Notetaker(s): Ali C. Begen
Attendees: 42
Speakers: Chairs
Speaker: Jeremiah Davis
Slide 3: Overview of ICN+SCION
Slide 4: Showing inter-domain interest-data exchange
Slide 5: Motivations
Slide 6: SCION background
Slide 7: Trust structure
Slide 8: SCION Control plane
Slide 9: Data plane
Slide 10: Key design components
Slide 11: RHINE (name resolution system)
Slide 12: Why use RHINE
Slide 13: Reflexive forwarding
Slide 14: ICN+SCION
Slide 15: Locating data with RHINE
Slide 16: ICN-SCION interoperation
Slide 17: ICN-SCION interface
Slides 18, 19, 20: Ongoing work, future work, summary
Tilmann Zäschke: Using the gateway a lot or going to the clients
directly?
Jeremiah: Some of the clients will be SCION aware; this will allow
them to have multi-path capabilities. The choice of a gateway is for two
purposes. (i) is to allow ICN applications that are not aware of SCION
and (ii) allows for some use of ICN caching if you can have these
prefixes advertised.
Dirk Kutcher: Any performance results?
Jeremiah: Not yet, ongoing.
Stuart Card: How to use one-way broadcast links?
Jeremiah: Not yet.
Speaker: Htet Htet Hlaing
Slide 2: From centralized to distributed AI
Slide 3: Challenges
Slide 4: Existing DAI approaches
Slide 5: Prior work
Slide 6: System design
Slide 7: Content-aware function execution
Slide 8: Function execution
Slide 9: Adaptive data and function coordination
Slides 10, 11-13: Evaluation, results
Slide 14: Summary
DaveO: Caching the results and saving recomputation. Training or
inference. Where would this happen?
Htet Htet: Most obvious usecase is the vehicle/object detection. In
this types of autonomous system, multiple view points exists, this
system would allow processing of data in such scenarios.
Shuai Liu: How does your system react to changing situation?
Htet Htet: (referencing to slide 8) our system uses capacity score and
available resources to select a node
Speaker: Lixia Zhang
Slide 2: Revisiting routing scalability
Slides 3, 4: IP's dual role (identifer/locator)
Slide 5: Architectural fix (map-and-encap)
Slide 6: LISP (proposals vs. reality)
Slide 7: MPLS (why MPLS was deployed against LISP)
Slide 8: IP multicast forwarding, state grows quickly
Slide 9: Multicast forwarding scales worse than unicast
Slide 10: BIER as a new multicast forwarding
Slide 11: The scaling principle
Slide 12: Repeated discovery
Slide 13: Remaining scaling wall: inter-domain
Slide 14: Lessons for future designs
Ken C.: What do you think of SCION as a form of Map and Encap.?
Lixia: I have some comments but will follow-up with an email
Roland Bless: There are schemes ID-based addresses without any to
locator mapping. KIRA: https://telematics.tm.kit.edu/projects_KIRA.php
Lixia: There's a lot to say... Are you aware of ROFL? Perhaps we
should continue this on ML or some other occasion.
DaveO: Mentions hyperbolic routing as a scalable approach.
Lixia: Perhaps I should have mentioned that. But again, the point is
the mapping mechanism is the crucial point for map and encap.
Junxiao Shi: Prefix aggregation in IP is dying. Most BGP
announcements today are /24 prefixes. If you own a /24, you can change
providers without renumbering your network.
David Oran: yes - good point.
Stuart Card: Host Identity Protocol is also map-encap but does not
require Internet wide change: it can be adopted incrementally &
immediately brings benefits to adopters.
David Oran: The motivation for MPLS wasn't routing scalability but
rather traffic engineering
Ryo Yanagida: I classified HIP as uh SHIM layer approach in my
thesis if I remember correctly
David Oran: @Stuart - yes, another good example which also tried to
solve the host authenticity problem by using key hashes as the
identifiers
David Oran: Of course the question remain of why use OP multicast in
the first place rathe than a layer 4 or 7 approach like MOQ
Stuart Card: @Ryo I just found your thesis, thanks!
Roland Bless: There are scalable routing schemes that do not require
a mapping system. KIRA is a scalable routing system that even does not
need an ID->LOC mapping system.
David Oran:for slide 13 - it seems SCION nails solutions to most of
the problems for interdomain scalability across AS's
Ryo Yanagida: Stuart Card hmm i think it should still be not
public... (and perhaps not so relevant in this context 😅 )
Stuart Card: We are seeing adoption & deployment of Drone Remote
Identification Protocol (DRIP) based on Hierarchical Host Identity Tags
(HHITs) adapted from HIP. I am still working to generalize it to
multicast & CIDR.
Slide 2: NDN routing scalability concerns
Slide 3: Map-and-encap
Ken:Sync interest needs to go to every member of group? i.e. every
edge routers?
Tianyuan: Sync interest announce needs to get to the old routers.(?)
Ken: But not for application sync interest, just for mapping table
update?
Tianyuan: Correct
Ken: Understood
Lixia: From the lessons from BGP update overhead, when designing
BIER, we separated prefix updates from topological changes, which
changes how convergence occurs.
David Oran:Q: Do consumers as well as producers need to register
with the mapping system? if so, how does that square with the
(desirable) consumer anonymity property of NDN?
Junxiao Shi: Only the producers need to register with the mapping
system. However, it's unclear how this interacts with Reflexive
Forwarding.
David Oran: @Junxiao - thanks
David Oran: @Junxiao - I suspect one could construct PIT tokens for
the reverse tunnel to get to the right ingress router without the
consumers to have public identities.
Tianyuan Yu: Yes consumers do not need to register prefix. The
prefixes are for the producers.
Kenneth Calvert: Tianyuan Yu, does there need to be a PIT entry for
every sync application instance (i.e., multicast group)?
Tianyuan Yu: @Ken, Yes you need to by design. We are working on some
on-demand mechanisms so that routers dynamically write popular prefixes
into the PET.
Kenneth Calvert: @Tianyuan, thanks.
Lixia: Thanks for the work, I've sent a link to the technical report
on chat.
Tianyuan: Could you talk a little more about Ownly slide? What do
you mean by authority?
Ferhat: This is talking about governance. I'm under the authority of
PKI key issuers, but when I access a content from another domain, their
keys are under another authority. One solution is to create a central
authority to manage both domains and issue keys to both parties but that
creates another problem.
Tianyuan: I see. More recently, Ownly made content security
orthogonal to the infrastructure security. Now the content security keys
do not come from say UCLA. Secondly, we are moving towards MLS style
group encryption where keys auto rotate as group membership changes with
forward secrecy.
Ferhat: In group communication, there are keys shared amongst many
participants. If we are using hybrid key scheme, symmetric key has to be
changed. Our approach removes the need of central authority
Tianyuan: The community is moving towards an approach that does not
need a traditional 'group keys'
Lixia: Latest release of ownly adapted to MLS, which handles the key
rotation and updates, i.e. we don't need to explicitly handle group keys
Ryo: We should take this to ML
Junxiao Shi: The risk of ABE and ABAC is the lack of well-maintained
libraries. NAC-ABE is fighting with OpenABE that is incompatible with
OpenSSL 3. ABAC-NDN is using PBC library that still works for now, but
PBC is not actively maintained either.
Lixia Zhang: this NDN TR seems relevant to this talk (regarading a
layer between app and net, see
https://named-data.net/wp-content/uploads/2021/01/NDN-TR-0071-ndn-lite-pubsub.pdf
Lixia Zhang: the issue of prodiucer and consumer belonging to
different trust domains is resolved by inter-domain trust management,
see an early poster at ICN 2022,
https://dl.acm.org/doi/pdf/10.1145/3517212.3559489
Lixia Zhang: Ownly adopted IETF standard MLS in the latest Ownly
release
Tianyuan Yu: dev.ownly.work and
https://datatracker.ietf.org/doc/rfc9420/
Lixia Zhang: As I said earlier, let's keep the communication channel
open and update each other on the latest work. We still run weekly NDN
coordination calls that are open to everyone, where we discuss/debate
new changes (just join nfd-dev mailing list to receive call agenda every
Thursday).
But it is our fault for not reporting NDN updates to the ndn-interest
mailing list. We will fix that.
David Oran: @lixia - it may be valuable for a subset of things that
may have wider interest to occasionally post to th eICNRG list as the
membership only partially overlaps
Lixia Zhang: yes we can do that.