Minutes IETF116: icnrg: Tue 00:30
minutes-116-icnrg-202303280030-00

Meeting Minutes Information-Centric Networking (icnrg) RG
Date and time 2023-03-28 00:30
Title Minutes IETF116: icnrg: Tue 00:30
State Active
Other versions markdown
Last updated 2023-04-03

minutes-116-icnrg-202303280030-00

ICNRG Meeting at IETF-116 – 2023-03-28, 09:30 to 11:30 UTC

Notetakers: Ryo Yanagida (add yourself!)
Meeting began at: 0938

Agenda

1. ICNRG Chairs' Presentation: Status, Updates — Chairs

  • Reminders: IRTF goals

  • Admin

    • We need notetakers -> Ryo volunteered — asks for helpers
    • Dirk: do say who you are so that it's easier for note taking
    • Agenda

  • RFC9344

    • Published
    • Tools to provide the CCN networks' capabilities

  • Ongoing RFC drafts

    • ccnx timetlv: in IRSG review
    • flic (we'll hear today)
    • icnping (finished IRSG Review - waiting on pathsteering)
    • icntraceroute (finished IRSG Review - waiting on pathsteering)
    • pathsteering - finished RG last call, waiting on document
      shepherd to submit for IRSG Review

2. Reflexive Forwarding Update (draft-oran-icnrg-reflexive-forwarding) — Dave Oran

  • the two-way comms we have is not enough

    • restful
    • RMI
    • Phone-home
    • Peer state sync

  • We want:

    • Pushing data
    • RESTful-like session

  • And we want this without completely destroying the architecture

  • Changes in 05

    1. updated terminology for better understanding, clarifictions
    2. fixed labels in ladder diagrams
    3. Fixes bsed on early feedback from IANA

  • Would be good to see more implementations (currently NICT is
    interested in implementing in Cefore CCNX)

No questions/Comments

3. Media Delivery over QUIC (QUICR) (draft-jennings-moq-quiqr-arch) — Cullen Jennings

Title: Evolving Media Requirements

  • "This is more of a problem description"
  • AR/VR holographics interactive media

  • 3d representation techniques

    • Point Clouds
    • Light field holograms (used in current work w/ holographic Webex
      work)
      • Potentially more appropriate for ICN

  • Latency issues

    • We want computation closer to the clients receiving the 3D
      models
    • Edge nodes between the clients and the cloud?

  • Demands:

    • Current limits for online conferencing tools; 200–500 (Teams,
      Webex, Zoom) and we need more
    • Popularity in Live-streaming w/ interactivity
    • w/ DASH etc. we can get 15 sec. or so latency and more
      interactivity benefits from shorter latency
    • There is a demand for both reducing latency and increasing
      scalability

  • We need something like ICN, Pub-Sub etc.

  • Approach: QuicR

    • Motivated by Cisco's hICN
    • has named data, pub-sub
    • Data Objects w/ globally unique name
    • The applications use Pub-Sub model

    • Uses QUIC for actual transfer

      • Deployability (while UDP is blocked QUIC gets a pass in
        various scenarios)

    • end-to-end encrypted/authenticated

    • Relay Mesh (i.e. forwarders, overlay routers)

      • Some might be in AP at home

        • Gets closer to edge, helps with scalability

      • Some might be in CDN-like environment (this handles billing)

  • Current status:

    • Some running code
    • Experimenting
    • minimal working audio/video clients and relays for
      experimentation
    • We need: better drafts, wider range of contributors, and broader
      experiments

Discussion

Dirk Trossen: Routing over.. has similar aspects. Why would you
have/need centralised content distributions and CDNs? Drive towards
decentralisation is there.
Cullen: These more decentralised distributed systems are happening in
various areas, while the demand for controlling data sovereignty is
there too. Would have been good to discuss in the talk too.
Dirk T.: We need something that is decentralised but also controls where
the data resides

Richard Li: Why pub-sub is a good model for holograms or other problems?
This sounds more ideal with connection based model.
Cullen: Let me clarify: traditional connection model works too but more
types of media, more users, puts strain in terms of bandwidth. With
larger amount of data, with different amount of data at any given point.
It might be easier to distribute the data, using the pub-sub model.
(just needs 1 copy, instead of relaying n clients worth of flows at a
particular link)
Richard Li:...

Hang Shi: How do you chose paths/relays?
Cullen: Didn't talk about that here because the example is quite simple
and what we have now is quite simple too. There are quite a lot of
interesting work there

David Oran: Is the pub/sub broker based? or direct, is it topological?

Cullen: No topology in the name, not used in routing informations.
Relays keep the state of # of subscriptions + any routing informations
to the other relays.
David O.: Needs good authentication system
Cullen: The application gets authorisation tokens ...

Dirk Kutscher: How do you do congestion control?
Cullen: QUIC layer does some congestion control. Application has to set
bitrate sensibly and do some rate controls. let's say 5 Mbps doesn't
work, then step it down to 3 Mbps

Colin Perkins: You identified a key difference between the existing and
this new media — the new media is not linear as the existing media. Why
are you using relatively unstructured name?
Cullen: We have not written drafts about this yet. If you look at the
URL to distribute the media, they are basically just arbitrary numbers
(numeric URIs). These have some sort of schema to tie to meaningful
names.
Colin P.:
Cullen: It will be a string to 128-bit conversion schema based mechanism

Kazuaki U.: Rate adaptation — Let's say we have home wifi AP, does it
have to subscribe to many rates?
Cullen: see slide 16 here : if R3 and R4 is using one rate, Relay B will
subscribe to a single rate, but if the R3 and R4 subscribes to different
rates, Relay B then needs to subscribe to the new rate. For now, relay
subscribes only subscribes to the rates the 'child' relays needs.

Dave O.: Does relay cache?
Cullen : Yes
Dave O.: Caching and different rates can get ugly — can cause congestion
collapse, let's chat offline
Cullen : Agreed
Dave O.: There are ways to avoid this but will require relays to be
smarter

Dirk K.: We invited Cullen as there are quite a interest in these new
medium and this is very interesting work

4. Adaptive Media Streaming in ICN — Cedric Westphal

Title: ICN- From Streaming to Metaverse

  • Background

    • Metaverse

      • There are several definitions

      • Taxonomy:

        • Env: Realistic, unrealistic, fused
        • Iface: 3D, immersive, physical methods
        • Interaction types: social, collaboration
        • Security: Data security, privacy,
          software/hardware/network security
        • Also Centralised/ddecentralised?
        • Defining taxonomy and requirements is part of the
          objective here

      • Current ecosystem: see Jon Radoff "How to build a metaverse"

  • Metaverse draws from various technology/application/concepts (non
    exhaustive):

    • Video streaming
    • Video conferencing
    • Social Network

  • the key issues for video streaming in ICN?

    • ref: RFC7933

    • Streaming metaverse views:

      • what enconding?
      • How to interact w/ ICN?
      • How to integrate w/ ICN?

    • IPTV and ICN -> multipath/multicast?

    • Digital Rights Management in ICN -> ACL, owner, authentication?
      Who owns the material?

  • Metaverse challenges:

    • Strict QoE req.
    • security req.
    • complex ownership/access privileges
    • Do we adapt ICN to metaverse? metaverse to ICN?

  • Metaverse and ICN — objects:

    • objects distributed to render a metaverse env.

    • within the env. there exists "virtual physical" objects

      • objects/ avatars for the users
      • Persistence objects left in metaverse by users?
      • How do we deal with access rights? Who can add? Change?
        remove?

    • How do we deal with ownership?

      • platform owns the virt. env.
      • users own objects with in the platform

  • Metaverse & ICN: Decetralisation

    • How do we manage these access req. objects management in
      decentralised manner?
    • If hierarchical structure is imposed for scalability, can the
      edge run independently? to what extent? Cna it run disconnected
      from central authority?
    • ICN decouples

  • Metaverse: Interoperability:

    • How can we provide a common framework to provide connectivity
      for metaverse?

  • Research challenges:

    • Interop
    • Scalability
    • Privacy/Security

    • Low-latency

      • interaction needs low-latency
      • both physical, logical (proto. level) issues respectively
      • side meeting for LEO satellites might be interesting ->
        constellational comm. can be better than fiber

    • ML for behaviours w/in metaverse

      • predictability of immersive video streaming might be useful
        (FoV in Metaverse)

    • Programmability

      • COIN arch?

    • High precision of the traffic -> improving latency

    • How to evaluate research proposals?

      • Sure, build something but needs evaluation. maybe
        simualtion?

    • Sustainability?

  • Conclusion: What are the ICN research challenges?

    • Is it worth exploring RFC7933 for the metaverse?
    • draft is in progress, will be sending the drafts in the mailing
      list

** No questions **

5. FLIC Update (draft-irtf-icnrg-flic) — Mark Mosko

  • What FLIC does (recap)

    • provides a manifest of hashes
    • manifest is hierarchical
    • there is a canonical traversal order (can also provide hints)
    • FLIC has encryption (extensible)

    • has several Interest construction techniques

      • publisher can choose one or more of these naming techniques.
        More could be added

    • Unencrypted manifest struct:

      • Node TLV
        • Hash Group TLV
          • Ptr TLV
            • | Hash TLV | Hash |

    • NDN:

      • content type 1024 is reserved to indicate FLIC
      • HashType is ImplicitSha256

      • FLIC uses segmented names:

        • common prefix + segment number + hash

      • if manifest has one name and the application data has
        another, two sets of seg. num to track (?)

    • Supports out-of-order traversal if aplication desires

    • HashGroup w/ Annotations (new from -05)

      • SegmentId Annotation TLV w/ number field
      • Alternative: put that in GroupData TLV

    • Routing hints:

      • Topological names are used to hint which way to go

        • -04 called Locators - effectively a name prefix
        • name should change (will be fixed)
        • routing hints may or may not be inherited from parnt
          manifest

      • Multiple routing hints:

        • can't be done with just one routing hints
        • tree needs to be organised to put multiple locators
          accordingly/appropriately

    • Not discussed but present

      • Encryption
      • Metadata
      • schemas
      • flags

Discussions

Dirk K.: Let's take this to mailing lists

6. Loss Detection for ICN — Kazuaki Ueda

Title: Loss Detection for ICN — Probe based approach

  • Two approaches:

    1. loss detection in network (link layer, forwarding strategy)
    2. End host-based approach at ICN socket

  • In-network approach at face/link layer protocols:

    • good to detect path failure
    • can introduce complications with application demands/behaviours
    • using seq. num can get simple and fast recovery
    • previous demo encountered issues w/ loss
      • loss detection only works when every hop performs it

  • End host-based

    • timer based retrans
    • much like TCP uses RTO

    • Problem: Spurious timeout

      • known issues in TCP - false loss detection
      • RTT of packet is not consistent and exceeds RTO -> false
        loss detection

      • Example: STO from in-network cache

        • when fetching additional packets, spurious retrans
          happens from consumer

      • large minRTO can help avoiding this

      • optimal parameter is hard to know

    • How should we deal with STO in NDN?

      • Traditional RTO decision is not optimal

      • Proposal — NDN PTO

        1. discovers current RTT with a probe

        2. updates Loss detection timer with new RTT, check s
          actual timeout

          • Two timers and probe interest approach
            ^

          • Probe timeout (PTO) recent RTTs, triggers probe

          • Loss Detection Timer (LDT)
          • Probe Interest
            • A single interest to request new data
            • obtains the latest RTT, update LDT
            • CCNinfo 9344 might be a good alternative

      • Evaluation

        • Scenario Switching of producer
          • Result: NDN-PTO achieved comparable goodput for the
            optimal PCON w/o configuring min RTO
          • Overhead:

  • Conclusion:

    • CCN/NDN is prone to STO
    • Next step: actual testbed evaluation

7. Buffer, Wrap Up and Next Steps — Chairs

  • New project: Named Data microverse
  • Workshop: Metacom 2023
  • ACM ICN 2023 Revkjavik CFP published
  • Sidemeeting today: Fujitsu Trust-Enhanced Networking in G301 1700
    today

Meeting end: 11:32