Replying to Avatar semisol

For my design, it starts with subscribing to the multicast stream

You then initiate a TCP connection to the source as a “management” connection, you get the latest packet ID

For a low-latency high-throughput system, you see if there are any packet ID gaps and request.

If you go low-throughput, you may include constant empty messages (which will increase B/W, and higher rate of empty messages = faster recovery from loss)

You can also do a client ack system if you do not have a very high amount of clients for lower B/W usage

You also have buffer memory for retransmits, and that can run out, so clients that cannot recover fast enough need to start over (causing complete loss of the stream)

Avatar
phil 1y ago

That makes sense, so the TCP connection is used to request the retransmits?

When I was looking at this earlier today I came across a draft for multicast extensions to QUIC which looked interesting. I haven’t read the document completely but it does look like it includes recovery mechanisms for dropped packets. It needs to operate in conjunction with a unicast QUIC connection.

https://datatracker.ietf.org/doc/draft-jholland-quic-multicast/

Reply to this note

Please Login to reply.

Discussion

Avatar
semisol 1y ago

You could do it via TCP, yes

Thread collapsed