On Wed, May 27, 2015 at 2:51 PM, Juliusz Chroboczek <[email protected]> wrote: >> while this has been discussed elsewhere, perhaps the nature of the >> rate limiter for a full (source) routing request dump should wind up >> in the rfc? > > It doesn't belong here, it should be discussed in the main spec. But > really, it's an implementation detail. > > Babeld (the implementation) has two rate limiters: > > (1) it has a token bucket for all packets, full at 200 packets, > replenished at 40 packets/s; and > > (2) it has a limit for full updates, at most once per hello interval.
If the bandwidth is 1Mbit it would extend past the hello interval. > (1) never triggers in practice, since (2) triggers before that (it can > trigger if a whole network is rebooting at the same time). > >> what happens [...] with loss > > As usual -- Babel doesn't care. :) > >> 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. 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. > (At that scale, a full update is around 1MB of data. I'd probably split > the network into a dozen subnets, assign a separate prefix to each subnet, > and perform aggregation at subnet boundaries.) My vision here is the city of SF (or, Paris, take your pick), all meshed together with a koruza/wired/wifi backbone supplementing (or one day supplanting) the existing half dozen ISPs. Or take a guifi, for example. > >> Is the entire update processed at once? > > No, each update is processed separately (except for prefix compression). > So if a packet contains 40 updates, each update results in a separate call > to update_route, with no interaction between the updates. cool. > > To make things clearer, there's nothing preventing you from sending > a packet that says > > update(p) > retract(p) > update(p) > retract(p) > > and update_route will be called four times, leading to p being updated, > retracted, updated, retracted. Only the final retraction will cause an > update to be sent out, however. > >> If a packet is dropped is the whole thing invalid? > > If a packet is dropped, all the other packets are still processed > normally. There's no interaction between packets whatsoever. cool. If you get around to updating the babel doesn't care document or main rfc, these might be good points to call out. > -- Juliusz -- Dave Täht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
