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

[Dave Taht]

On Wed, May 27, 2015 at 2:51 PM, Juliusz Chroboczek
<jch at pps.univ-paris-diderot.fr> 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