Good question! Right now the implementation is pretty simple, but I think will work well in most cases: It always splits a range into 16 equal-sized ranges unless the range has 32 or fewer IDs, in which case it just sends the whole list of IDs. I think there is probably some low-hanging fruit on tuning that threshold.

The nice thing is that nothing in the protocol needs to change to tune this. In fact, the protocol theoretically supports dynamic adjustment of those parameters to target a particular point in the latency/bandwidth tradeoff space.

There are also some other reasons you might want to customise the range selection, which I described here: https://logperiodic.com/rbsr.html#range-choice