When does IB Multicast drop?

I've been reading* through the IBA spec (Release 1.3 2015-03-03), trying to understand IB multicast and its pitfalls.

I understand that IB multicast only supports Unreliable Datagram sends (10.5.2.1), and that there are neither delivery guarantees nor acknowledgments for UD sends. Furthermore, flow control is only available for Reliable Connections. I thought I saw that there was an ordering guarantee within a multicast group for a specific sender, but now I can't find that section again.

How far is the send guaranteed to propagate? What would cause the data to be dropped? Is it possible for an oversubscribed (e.g. a 80 Gb/s burst of multicast bandwidth trying to fit through a link with only 40 Gb/s of bandwidth) link to slow down multicast data on a different network path, or will burst be "clipped" by dropping packets?

In testing some co-workers of mine have done we have found that when multicast is run in parallel over IB and Ether, the IB is occasionally slower, but does not seem to drop packets. This seems to suggest that flow control /is/ working for multicast (which would be great, as long as we know where the pathological cases are and avoid them).

Thank you,
Peter Chinetti

*Honestly, more like Control-F'ing for "multicast". Not super effective. --
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

InfiniBand flow control is done at the link layer, so UD does not drop packets due to congestion.

AFAIK, UD only drops packets due to irrecoverable bit errors and network device failures. Mellanox's FDR physical layer has BER less than 10^(-15), and forward error correction on top of that, so an irrecoverable bit error is extremeley extremely rare.

If the network topology does not have multipath, (Mellanox) UD will not reorder packets to a particular destination sent from the same UD QP. There is probably some guarantee in multipath topologies, too.

I don't have experience with multicast, but here's some info.

InfiniBand flow control is done at the link layer, so UD does not drop packets due to congestion.

AFAIK, UD only drops packets due to irrecoverable bit errors and network device failures. Mellanox's FDR physical layer has BER less than 10^(-15), and forward error correction on top of that, so an irrecoverable bit error is extremeley extremely rare.

If the network topology does not have multipath, (Mellanox) UD will not reorder packets to a particular destination sent from the same UD QP. There is probably some guarantee in multipath topologies, too.

--Anuj (rdma_guy)

Quoted 30 lines · Peter Chinetti

I've been reading* through the IBA spec (Release 1.3 2015-03-03), trying to understand IB multicast and its pitfalls.

I understand that IB multicast only supports Unreliable Datagram sends (10.5.2.1), and that there are neither delivery guarantees nor acknowledgments for UD sends. Furthermore, flow control is only available for Reliable Connections. I thought I saw that there was an ordering guarantee within a multicast group for a specific sender, but now I can't find that section again.

How far is the send guaranteed to propagate? What would cause the data to be dropped? Is it possible for an oversubscribed (e.g. a 80 Gb/s burst of multicast bandwidth trying to fit through a link with only 40 Gb/s of bandwidth) link to slow down multicast data on a different network path, or will burst be "clipped" by dropping packets?

In testing some co-workers of mine have done we have found that when multicast is run in parallel over IB and Ether, the IB is occasionally slower, but does not seem to drop packets. This seems to suggest that flow control /is/ working for multicast (which would be great, as long as we know where the pathological cases are and avoid them).

Thank you,
Peter Chinetti

*Honestly, more like Control-F'ing for "multicast". Not super effective. --
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Correct. But multicast packets are droped at the QP receive level if the app does not provide enough buffers to accept the data stream. The bufers can easily be overrun if one does not code carefully given that the maximum number of those is 16K or so. These drops occurs silently. Currently there is no accounting for these drops in the upstream kernel.

Quoted 5 lines

Correct. But multicast packets are droped at the QP receive level if the app does not provide enough buffers to accept the data stream. The bufers can easily be overrun if one does not code carefully given that the maximum number of those is 16K or so. These drops occurs silently. Currently there is no accounting for these drops in the upstream kernel.

How about when one of the destinations for the multicast group has its connection to the switch overloaded (because it is subscribing to many multicast groups whose combined bandwidth is momentarily greater than the bandwidth of the link to the switch). Are the messages destined for that endpoint dropped at the switch, or is traffic to the entire multicast group delayed?