Minutes IETF114: mboned
minutes-114-mboned-00

IETF 114 Philadelphia
MBONED Agenda
Thurs, July 28, 2022
13:30-15:30 EDT
Thursday Afternoon session II, Independence C

Note-takers: Jake Holland, Vinod Nagaraj
Chat Log: https://zulip.ietf.org/#narrow/stream/mboned
Video log: https://www.youtube.com/watch?v=ApUGFb9EDUc

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

Status of WG items
Chairs, 10 min

    draft-ietf-mboned-multicast-yang-model:
        please review
    draft-ietf-mboned-redundant-ingress-failover:
        please review
    multicast to the browser drafts:
        jake: still planning to finish these. Next is probably mnat

AD Update
Warren, 5 min
    Lenny: Warren not avail, term ending soon, consider volunteering

draft-ietf-mboned-multicast-telemetry
Haoyu Song, 10 min

    Jake: impementation status?
        IOAM is present in a product, but not yet the multicast part
    Jake: how do branch ids work under topology changes in the DEX version?
        static config per interface
    Nils: how does it aggregate?
        different multicast streams can be aggregated from the IOAM data on the
        packet Flow ID doesn’t change from source, branch id reflects the
        interface id one router supports up to 256 branches, can’t scale to
        more interface Nils: our routers have more than 256, and interface is
        key and needs to be included in the postcard. 8 bits seems not enough
        for us. Dino: support solving this. Olympics US broadcaster needs data
        on the tree both upstream and downstream, we did this with olympics in
        LISP Requesting more folks to read the draft [ Poll :- Read draft :- 2
        ; Not Read draft :- 7]

draft-jholland-quic-multicast, W3C Update
Max Franke/Jake Holland, 20 min

    Dino: server = source, client = receiver, right? Server controls who joins
    the group, providing some kind of access control.
        Jake: note, server and client are QUIC terms, and that’s the context
        for those. There’s always a QUIC connection Dino: it would be hard for
        me to join a channel and decrypt without a unicast connection, right?
        (yes)
    Stig: in BIER there’s some work about source control of joining also
    Jeffrey: how does it scale if you have 10k clients?
        Max: better than having unicast
        Kyle: still linearly, but the constant is lower
        Lenny: so the control plane scales the same but the data plane scales
        better? Kyle: Jeffrey: one diff between this and 10k different unicast
        sessions. Stig: Dino: Did you look at norm (PGM)? (yes) Gorry:- QUIC
        does not have to ACK every packet. DINO :- this is really good
        architecture as you have solved source discovery. Retransmitting
        multicast packet that’s lost somewhere in path, how do you plan to do
        it ? Some of these was tried in PGM but it turned out to be complex.
            Jake: Server implementation detail, in this architecture. But
            definitely a server endpoint decision, not a router.
        Nils: kudos, good approach. interesting to couple this not just to
        native multicast but also to amt, and also regarding retransmission we
        should consider, especially if this is for live events there’s only a
        tiny time frame where you have buffering when it makes sense to rexmit
        the data packets (like 50-60ms), so if you don’t have to think about it
        that’s useful.
            check out the moq work (warp & rush)
            also the ack-bundling in quic
        Dino: regarding live & rexmit: for live events use FEC, consider using
        that. Solana blockchain uses FEC without rexmit, will send info on what
        they’re using, it’s open source. Dino: 100 participants in a whiteboard
        session would not be any-to-any, right? (right, it would have to go
        thru server or separately make another p2p unicast connection, not
        any-to-any multicast) Lenny: mixing of multicast/unicast, can you do
        something like unicast bespoke advertising?
            Max: yes, server can decide what data is multicast vs. unicast
        Lenny: this is great.

Offnet Sourcing with the Multicast Menu
Lauren Delwiche, 25 min.

    Applause for streaming IETF114 mboned room video.
    Applause for the Demo.
    Greg: other source options? If I have an existing IP camera can I source
    that too? (not built in but possible) Max: SRT sent to a
    uniast-to-multicast translator?
        Yes, it’s changing the SRT UDP to “regular UDP”
        Jake: “regular UDP” means raw mpeg-ts over UDP, right? (yes)
    Kyle: nice work, first live demo that worked at IETF I think
    Nils: nice work, a multinational insurance company tried this and where
    yours worked, theirs they had to reschedule Greg: who’s funding this?
        Lauren: still on my credit card at the moment
    Lenny : multi year project which started 5 years ago. William worked on
    first AMT relay. Lauren picked up from William couple years ago.

Client Options for Receiving Multicast Video
Erik Herz, 20 min

    Jake: what do you do for mobile ? ( answer:- doesn’t support mobile)
    Lenny:

TU Berlin Student Multicast projects
Max Franke, 10 min

    Dino: is there an equivalent GR on client side ?
        Jake: if the membership update is sent, it’ll already stop sending. If
        not, it has the same fallback timeout as IGMP if there’s no new
        membership reports
    Lauren: what’s he tracking for trending streams? Is there value in tracking
    how many opens happen?
        Max: yes. There’s questions, do you weigh them differently? Was it from
        console or command line? Stig: long-term tracking different from
        launching, if it’s just a few seconds of watch it maybe shouldn’t count
        as much