Avoid bottleneck in UDP multicast

Question

The question is that a server is serving a multicast group with UDP. Lets say that its a file server and it will be serving big files (~10GB). Now we have a multicast group with multiple clients. Some of those clients have really good bandwidth, like 1Gbps, while the others just have 100Mbps. We can assume that the ratio is 1:1 (50% of each). Now we want to deliver the file to every user with multicast but we also don't want to limit the highest speed equal to the slowest receiver in the multicast group. We want that every user get the file at highest speed possible speed for him. For example, 100Mbps user will get it at 100Mbps while 1Gbps will get it at 1Gbps. If we send traffice from serve at 1Gbps, then 100Mbps clients will be overloaded and they will drop their packets as they cannot handle this speed. If we transfer at 100Mbps then we are limiting the clients with 1Gbps to just 100Mbps.

Idea here is to not drop the users from multicast group while also achieve maximum possible speed for each client.

Answer 1

First a caveat:

Multicast (resp all UDP based transport) by itself has no flow control, no congestion avoidance mechanisms, no ways to retransmit lost packets, and no inherent receive buffer scaling, as TCP offers them. Delivering large files (~10Gbytes) might call for some of these mechanisms, to ensure that eventually, the file is complete and uncorrupted at the remote end.

With multicast, the applications must compensate for many things they would not have to care about if the transfer were done with TCP.

• The sending application must make sure not to oversubscribe any link along the path
• The receiving application must make provisions to detect missing or corrupted packets
• Both sender and receiver must make provisions to compensate for lost packets, this might turn out to be "expensive" on the software side. [1][2][3]

And now for the actual answer:

To cover for different bandwidth of different receivers: For each bandwidth level, use a seperate Multicast group and adjust sending rates accordingly.

Also: Be sure to check if the receivers are capable of ingesting, checking, reordering (and writing to disk) such large streams of UDP traffic. Remember: UDP does not have the "native" receive buffer scaling that TCP has. More than once (I'll admit: in the past) I've been seeing IP stacks that bailed out at ~130Mbit/s of UDP traffic, but were able to pump >800Mbit/s of TCP.

And finally:

It is expensive (in terms of programming/application design and network infrastructure) to use multicast to deliver data in a bit-complete, loss-free and reliable fashion. If these are a requirement, you should make sure that you cannot achieve the same goal with a well-designed solution based on unicast and TCP, possibly with some preloaded caching servers near the clients. Mutlicast is good for financial market data, video streams, audio streams, where the occasional lost packet is "just as well", possibly compensated for by the video/audio codec on the receiver.

[1] for example: by sending the same stream with one mcast group address "A", across one network path, and the same stream with a mcast group address "B", across a different network path (might require pretty advanced multicast routing setup). At the application level, packets or data chunks are sequentially numbered and checksummed. The receiver subscribes to both groups, ingests both streams and does a logical comparison of all data chunks received before writing one good chunk to disk.

[2] other possibility: using a single group (per bandwidth class), each chunk is multicasted 3 times. Receivers have enough temporary storage to receive each chunk three times and logically combine one good chunk to write to disk.

[3] third possibility: since chunks should be numbered/checksummed anyway, clients can detect missing/incomplete/corrupted chunks and re-request them via unicast; of course, this needs a service on the server and a unicast capable client on the receiver, and it needs proper preparation of the data to be sent (segmentation into suitably sized chunks, sequence numbering, checksumming).