* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Mboned Status Pages

MBONE Deployment (Active WG)
Ops Area: Robert Wilton, Warren Kumari | 1996-Aug-26 —  
Chairs
 
 


IETF-114 mboned minutes


Minutes

minutes-114-mboned-00 minutes



          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
          
          



Generated from PyHt script /wg/mboned/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -