Minutes IETF116: mboned
minutes-116-mboned-00

IETF 116 Yokohama
MBONED Agenda
Wed, Mar 30, 2023
15:30-17:00 JST
Wednesday session III, G412-G413

Note-taker: Nate Karstens
Chat Log: https://zulip.ietf.org/#narrow/stream/mboned
Video log: https://www.youtube.com/watch?v=FOiD870r_KY

Notes taken in etherpad at https://notes.ietf.org/notes-ietf-116-mboned#

Text captured on 3/30/23:

Lenny reviewed the Note Well, asked people to log in online, and reviewed the
masking policy

Reviewed status of active WG docs:

    draft-ietf-mboned-mulitcast-telemetry – not enough non-author supporters to
    advance the draft draft-ietf-mboned-multicast-yang-model
    draft-ietf-mboned-redundant-ingress-failover

MTTB (multicast to the browser) drafts:

    draft-ietf-mboned-dorms
    draft-ietf-mboned-ambi
    draft-ietf-mboned-cbacc
    draft-ietf-mboned-mnat

Jake has been reassigned, so if anyone is interested in taking them over they
are encouraged to do so

Yisong Liu (remotely) presented “YANG Model for Automatic Multicast Tunneling”

    Version 02 – added statistics on AMT gateway
    Next steps – questions and ask for WG adoption
    No questions
    Lenny took a poll on who had read the AMT YANG draft
        6 have read, 6 have not
    Lenny took an poll on who supports adoption
        9 support adoption, 0 do not support adoption
        Will start an adoption call on the mailing list shortly

Dino presented GAAP (draft-farinacci-pim-gaap-02)

    Based off of work in pim group based on problem from Nate
    Decentralized multicast group address allocation protocol (no central
    entity) GAAP nodes have zero configuration No collisions at L2 to support
    multicast snooping functionality Supports both IPv4 and IPv6 Works on both
    L2 and L3 Networks that do not support L3 can use overlays on L2 Can
    coexist with other group allocation protocols by using an IANA GAAP
    allocation block How does it work
        Both senders and receivers participate
        Hashes group name to calculate group address
        Claim messages sent every minute (+/- 10%), but designed to only have a
        single claimer Handles collisions by adding “+1”, “+2”, etc. to group
        names Provides partition repair Messages are encrypted with Chacha20
        cipher, key is group name GAAP only has a single message – the claim
        message Protocol can detect bad actors (sending too fast, forging
        timestamp, etc). Rekeying can occur.
    Protocol API
        Four calls: init(), allocate(), release(), and close()
        A lightweight app can use a lighter-weight REST API to a GAAP proxy
        node that runs the protocol Need to experiment with IoT and using both
        Python and C
    GAAP library
        First phase implemented in Python
        Suite of utilities to help simulate collisions, partitions, etc.
    Question from Stig:
        Noticed that claim message has both v4 and v6 address field.
        Dino indicated this was on purpose for now (wanted to allocate both at
        once for now) Stig asked if we could have one number calculate both
        Dino indicated there were complications with handling collisions and
        needing to support multicast snooping
    Another question from Stig:
        Demo uses link-local scope
        Dino indicated that was an oversight
        May need to think about how scoping works
        Some talk about dividing existing allocations into different blocks
    Nate mentioned that he had a document that describes that, sent to Dino and
    will send to Stig Played video of demo. Used docker bridge to provide
    single-subnet multicast capability Dino mentioned simulations they ran with
    different collisions Next steps
        More testing
        More security features (Shamir’s MPC algorithm)
        Test on an overlay when no native multicast exists
        Seek more developers
        Write something in C to meet Nate’s embedded environment
    Acknowledgements
    Zheng Zhang
        Liked protocol design
        Wanted to understand if link-local, site-local, etc. would be used
        Dino indicated he wanted to use global scope (ff01)
    Stig Venaas
        Which protocol is being used to accomodate assignment of both v4 and v6?
        Dino: Needs to go over both to support collision detection
        Two messages need to be sent
        Dino indicated he would update to make that clearer
    Siyu Chen
        Asked for additional simulation data for collisions
        Also asked why we can’t avoid the issue with configuration
        When a collision happens, how long will it take to solve it?
        Dino answered 1 second
    Nate
        Pointed out that zero-configuration comes from his requirements
        Clarified that the global scope is ff0e
    Adoption call
        Might be an adoption call in pim
        No rush on this
        Plan to do additional testing and presentations
        Need to figure out GAAP and mDNS, or just one of them

Enhancements to Signal-Free LISP Multicast (presented by Prasad Govidan,
co-authored with Dino and Aswin)

    Problem statement: RFC 8378 defines signal-free mechanisms for an ingress
    replication-based underlay for overlay multicast Scope: keep the overlay
    signal-free semantics intact Reviewed procedures defined in the draft and
    showed diagram of reference model Question from Dino
        Mentioned that Daryl made comment in LISP working group. Wanted to know
        if some of the members are not on the overlay at all Prasad mentioned
        he would look into it
    Lenny asked if they were looking for feedback from LISP or mboned.
    Prasad asked chairs which WG they thought it belonged it
        Stig indicated that it was heavy on LISP content so thought it belonged
        there

TreeDN: Tree-based CDNs for Live Streaming to Mass Audiences (Lenny -
presenter, Chris Lenart, Rich Adam)

    draft-ietf-mops-treedn – also presented in mops WG and that group asked for
    more feedback from mboned to review multicast aspects of this Problem: With
    live audiences exploding (10s of millions) and increased bit rates
    (4K/8K/AR), are we at an inflection point? If so, what should we do?
        Live streaming is not the same as on-demand. Expectations for low
        latency means shorter playout buffer Join rates are vastly different
    Believes addressing the problem with network-based replication is correct,
    but Internet multicast has not been successful
        “All or Nothing” problem
        “It’s Too Complex” problem
        “Chicken and Egg” problem
        Good news: Network Replication technologies are now available to
        address those problems – TreeDNs
    TreeDN (Tree-based CDNs)
        Leverages native and overlay concepts to deliver service to end users
        Native (On-Net): SSM
        Overlay: AMT (RFC 7450)
        Incremental Deployment
    Showed diagram
    Benefits
        More efficent
        Allows SPs to offer new Replication-as-a-Service (RaaS)
        Democratizes and decentralizes content sourcing
    Use Cases / Applicability
        Any multi-destination content (live-streaming, large file downloads)
    Summary
        Crossing supply/demand curves
        Demand: exploding LiveStream audiences and increasing bitrates
        (4K/8K/AR) Supply: network-based replication is easier and more
        available than ever
    Feedback from MOPs
        Add diagrams
        Gaps - what else is needed to deliver a useful product?
            Transport issues with non-TCP traffic
        Scope - point out the gaps, not necessarily the solutions
    MOPs would welcome review and input from MBONED
    Question from Zhaohui (Jeffrey) Zhang: have they thought about working with
    MeetEcho team to use TreeDN to broadcast a few small sessions, like MBONED
        Yes, they have, thanks for the reminder.
        Jeffrey recommends starting here (i.e., an IETF meeting)