Google doesn't do the UDP stuff anymore. IIRC, they never did it for channels not in the subset, and I don't think it'd make sense to given the goal of having a stable subset choice. And they haven't been able to actually send RPCs over a channel in UDP mode since LOAS IIRC, so the UDP stuff was useless and eventually removed. I'm not sure it was ever that useful anyway...

They do still deactivate inactive channels, just totally rather than downgraded to UDP. Annoyingly, they only compute this inactivity for channels to individual tasks, not the greater load-balancing channels, and freshly started backend tasks always come up as active. So if you have a lot of inactive clients, when your tasks restart the inactive clients all rush to connect to it and your task sees noticeably higher health-checking load until the clients hit the inactivity timeout and disconnect again.

To more directly answer twic's question: I can think of a few reasons multicasting all the load reports probably doesn't make sense:

* That sounds like an awful lot of multicast groups to manage and/or a fair bit of multicast traffic. Let's say you have a cluster of 10,000 machines running 10,000 services averaging 100 tasks per service (and thus also averaging 100 tasks per machine). (Some services have far more than 100 tasks; some are tiny.) Each service might be a client of several other services and a backend to several other services. Do you have a multicast group for each service, and have each client tasks leave and join it when interested? I'm not a multicast expert but I don't think switches can handle that. More realistically you'd have your own application-level distributor to manage that, which is a new point of failure. Maybe you'd have all the backend tasks on a machine report their load to a machine-level aggregator (rather than a cluster-wide one), which broadcasts it to all the other machines in the cluster, and then fans out from there to all the interested clients on that machine. That might be workable (not a cluster-wide SPOF, each machine only handles 10,000 inbound messages per load reporting period, and each aggregator's total subscription count is at most some reasonable multiple of its 100 tasks) but adds moving pieces and state that I'd avoid without a good reason. edit: ...also, you'd need to do something different for inter-cluster traffic...

* They mention using power of two choices to decrease the amount of state ("contentious data structures") a client has to deal with. I think mostly they mean not doing O(backend_tasks) operations on the RPC hot path or contending on a lock ever taken by operations that take O(backend_tasks), but even for less frequent load updates I'm not sure they want to be touching this state at all, or doing it in a lockless way, and ideally not maintaining it in RAM at all.

* The biggest reason: session establishment is expensive in terms of latency (particularly for inter-cluster stuff where you don't want multiple round trips) and CPU (public-key crypto, and I don't think an equivalent of TLS session resumption to avoid this would help too often). That's why they talk about "minimal disruption" being valuable. So if you had perfect information for the load of all the servers, not just the ones in your current subset, what would you do with it anyway?