# ICNRG Meeting at IETF-116 – 2023-03-28, 09:30 to 11:30 UTC {#icnrg-meeting-at-ietf-116--2023-03-28-0930-to-1130-utc} * [MeetEcho][1] * [Notes][2] * [IETF-115 Agenda][3] Notetakers: Ryo Yanagida (add yourself!) Meeting began at: 0938 # Agenda {#agenda} ## 1. ICNRG Chairs' Presentation: Status, Updates — Chairs {#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][4]) — Dave Oran {#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][5]) — Cullen Jennings {#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 {#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 {#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][6]) — Mark Mosko {#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 {#discussions} Dirk K.: Let's take this to mailing lists ## 6. Loss Detection for ICN — Kazuaki Ueda {#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 {#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 [1]: https://meetings.conf.meetecho.com/ietf116/?group=icnrg&short=icnrg&item=1 [2]: https://notes.ietf.org/notes-ietf-116-icnrg [3]: https://datatracker.ietf.org/meeting/116/agenda/ [4]: https://datatracker.ietf.org/doc/draft-oran-icnrg-reflexive-forwarding/ [5]: https://datatracker.ietf.org/doc/draft-jennings-moq-quicr-arch/ [6]: https://https://datatracker.ietf.org/doc/draft-irtf-icnrg-flic/