[Babel-users] Rate limiting [was: New Version Notification...]

Dave Taht dave.taht at gmail.com
Wed May 27 22:25:41 UTC 2015


>>> What if you had, say, a small city's worth of source specific routes?
>>> (say 10,000, which I think equates to about 125 full size packets?).
>>
>> 125 packets is fine, it fits in the bucket.  Double that, and you'll want
>> to increase the constants at the beginning of message.h.  I'll make them
>> into config variables as soon as you build a network with more than 10 000
>> nodes.

Heh. don't tempt me. I actually would like to fire up that many vms to
see what would break. Or that many emulated iot nodes under some
routing protocol or another.

When I did some work at powertv back in 2000s they had a whole lab
dedicated to city scale testing their cable devices. (I wasn't there
for this, so this is just a story I half remember) A simulated power
failure of 40,000 nodes was "interesting" - it wasn't that individual
components failed, it was that the combined components did  - in
particular the tftpboot (udp based, not congestion controlled) process
for the devices failed over and over and over again, for minutes,
whilst everything else tried to come up. And then they would try tftp
again, with no exponential backoff (on that first attempt)...

Given where I live, I do, generally, worry, about what happens when a
city gets rebooted.

> If you send them all in a burst that will definately induce tail loss on many
> networks. Randomizing your start point in your update would ensure more
> routes got through.

So that was sort of one of the things they did, rate limiting AND
randomizing what got handed dhcp grant requests, to keep the tftpboots
under control.

in the babel case, solving for, and handing out default routes and
routing information, in the full routing table dump, with a random
starting point (since they are independent), would have led to the
network congestion induced by the followon tftp requests being more
spread out across the nodes, and also make for tail loss not hurting
so much.

Not that is really a current use case for babel but I keep hoping.

(by the time you wait for 10,000 nodes to show up in a deployment, it
would already be too late to fix)

But agree, this is not a problem now, I was pleased to understand how
independent from packets the updates were in the first place.



More information about the Babel-users mailing list