# ICNRG & COINRG   {#icnrg--coinrg}

**Joint Meeting @ IETF 114**

*   Agenda and Presentations:
    https://datatracker.ietf.org/meeting/114/session/icnrg

## ICNRG Chairs   {#icnrg-chairs}

https://datatracker.ietf.org/doc/slides-114-icnrg-chairs-presentation/

*   List of active documents presented
*   CCN info to be completed
*   Path steering for RG document? Follow up on the list - but the IPRR
    for IRTF is non-existent - not a standard - 3rd party disclosure by
    Dave.

### From the chat window:   {#from-the-chat-window}

*   Lixia Zhang: I believe the very initial idea (of using an Interest
    to set up path for another interest) came from Yu Zhang when he
    visited UCLA. Wonder whether the IPR application ACK'ed that fact.
*   Dave Oran: Well, for 3rd party declarations you only say what you
    know about, not what others may know about. It would be up to Yu
    Zhang to put one in. Is there anything written down? I'd be
    interested.
*   Lixia Zhang: Yu Zhang has an ICN poster some years back, also an NDN
    Tech report at the time.
*   Dave Oran: Thanks I'll try to dig this up - the stuff in the draft
    comes from Ilya & my ICN'17 path switching paper, so the patent
    application predates that by a few months or so.
*   Lixia Zhang: I just dug out the poster info:  
    Poster: "Kite: A Mobility Support Scheme for NDN"  
    Yu Zhang, Hongli Zhang, Lixia Zhang  
    ACM Information Centric Networking Conference, 2014.
*   Dave Oran: Oh, I know about Kite. It doesn't force packets onto a
    path, it just ensures the forwarder state is there.

## Ping Traceroute - Dave Oran - (update)   {#ping-traceroute---dave-oran---update}

*   https://datatracker.ietf.org/doc/slides-114-icnrg-pingtraceroute-updates-spyrosm-daveo/

*   If there are any questions they should be sent to the list

## Alternative Time Encoding - Thomas Schmidt (update)   {#alternative-time-encoding---thomas-schmidt-update}

*   https://datatracker.ietf.org/doc/slides-114-icnrg-alternative-delta-time-encoding-for-ccnx/

*   Rick Taylor: how this differ from IEEE???
    *   Thomas: We have looked at this.

*   Rick Taylor: Not including or including standards for using existing
    silicon?
    *   Thomas Schmidt: There were discussions but I don't remember the
        outcome.

### From the chat window:   {#from-the-chat-window-1}

*   Carsten Bormann: It is pretty easy to pick apart a float32 and get
    this.

## Selective Content Disclosure Nikos Fotiou (research)   {#selective-content-disclosure-nikos-fotiou-research}

*   https://datatracker.ietf.org/meeting/114/materials/slides-114-icnrg-selective-content-disclosure-using-zero-knowledge-proofs-pdf-00

*   Dirk Kutscher - do you have a paper?
    *   Nikos Fotiou: not yet

*   Dirk Kutscher - About the JSON object is this CRDT-like?
    *   Nikos Fotiou: This is an open issue

## Closing Comments from the ICNRG Chairs\*\*   {#closing-comments-from-the-icnrg-chairs}

*   FLIC needs to move forward
*   New work requested:
    *   Media over ICN (like is done for QUIC)
    *   Self learning/autoconfiguration/switch design
    *   Web over ICN

*   Joint work with COIN?

*   Lixia Zhang: (1) What are the key problems needing solutions? Why do
    you do that? (e.g. what problems are identified from running media
    over QUIC? That may be overcome by running media over ICN). (2) the
    basic idea of ICN is networking via *named*, *secured* data. Wish
    more ICNRG efforts look into the use of sematic naming, and
    solutuions to address security challenges.
    *   Dirk Kutscher: Some of these points are related to real problems
        e.g. real time distribution over the Internet. Security and web
        over ICN are pressing issue.

# COINRG Part   {#coinrg-part}

## COINRG Chairs   {#coinrg-chairs}

*   https://datatracker.ietf.org/doc/slides-114-icnrg-coin-rg-chairs-slides/

*   Documents need updating.
*   At the interim in September

## Traffic Steering at Layer 3 - Dirk Trossen (research)   {#traffic-steering-at-layer-3---dirk-trossen-research}

*   https://datatracker.ietf.org/doc/slides-114-icnrg-traffic-steering-at-layer-3/

*   IFIP networking paper:
    https://doi.org/10.23919/IFIPNetworking55013.2022.9829778

*   DirkK: Why call this "semantic routing"?
    *   DirkT: it's actual "service routing" – "semantic routing" is
        just a relict from previous work

*   KenCalvert: What is the advantage of doing this @ L3 vs L7? I think
    this paper has looked at doing something similar @ L7: E. W. Zegura,
    M. H. Ammar, Zongming Fei and S. Bhattacharjee, "Application-layer
    anycasting: a server selection architecture and use in a replicated
    Web service," in IEEE/ACM Transactions on Networking, vol. 8, no. 4,
    pp. 455-466, Aug. 2000, doi: 10.1109/90.865074.
    *   not average latency but variance of latency (jitter)
    *   variance would be reduced
    *   other scenario: resilience, e.g., when overloading servers
    *   in L3, you can distribute over all clients and thus get better
        performance
    *   The IFIP Networking paper:
        https://doi.org/10.23919/IFIPNetworking55013.2022.9829778

*   DirkT:
    *   @Kenneth sorry, only now realised your question at the bottom of
        the reference. Yes, the paper outlines the CDF to show the
        lowering of the variance through CArDS compared against the
        other mechanisms.
    *   @Kenneth, also note that CArDS only requires signaling the units
        used at deployment time, no regular metric reporting is
        necessary (such as suggested in the reference you sent)

## Namespaces - Andy Reid (research)   {#namespaces---andy-reid-research}

*   https://datatracker.ietf.org/doc/slides-114-icnrg-andy-reid-namespaces-security-and-addressing/

*   https://piccolo-project.org/

*   Dave Oran: Small point: Sidecars also act as a security perimeter,
    which is needed whenever you need to map between namespaces. So,
    unless you go full bore ICN, you still need something to do the
    mapping and isolation, and frankly sidecars seem to not actually
    have much overhead compared to other approaches.

## Building Adaptive Networks - Tushar Swamy (research)   {#building-adaptive-networks---tushar-swamy-research}

*   https://datatracker.ietf.org/doc/slides-114-icnrg-building-adaptive-networks-with-machine-learning/

*   Need to do ML fast to keep up with the dataplane; lead to Taurus
    switch pipeline design to supply line-rate ML inference. A
    programmable fabric. Published in ASPLOS.

*   How do we program Taurus? Led to Homunculus project, a framework for
    dataplane model generation. Homunculus provides net operators a
    high-level compiler to program ML switches.

*   See the last slide for a URL pointer to an archived version of the
    paper that is under submission
*   Take-away: an adaptive feedback look for network adaptation

*   Taurus: https://dl.acm.org/doi/10.1145/3503222.3507726
*   Homunculus: https://arxiv.org/pdf/2206.05592
*   Try it out! https://gitlab.com/dataplane-ai/taurus

*   Eve Schooler: the ML needs to be at line rate. That seems to be one
    of the challenges here – more than match-action. What kinds of
    feature extraction are targeting? What about image data?
    *   Tushar: haven't done this yet. Looking to start dealing with
        image classification in the data plane, but not certain what
        would be the best use case for motivating this. System is still
        fairly resource-limited on the switch.

*   Hesham ElBakoury: does the model get updated in the control plane
    (not only in the data plane)?
    *   Yes