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