Re: question on RDNSS, RFC 6106 part 5.1

[Pavel Simerda <[e-mail]>]

On Tue, 2012-05-15 at 09:47 +0200, Dan Luedtke wrote:
> > Since then, router solicitations would be issued regularly until
> > client recieves RA with RDNSS, connection is cancelled by user or:
> 
> We have a setup here were we have 50+ clients on some access points
> with about 100 access points distributed over the campus, all merged
> into one network. Let's say we have about 3k clients in the network
> which is a good average value. Let us further assume we loose these
> three RA before they reach the access points, so that no access point
> sends them out. (Of course they usually get lost on some access
> points, not on all at the same time, but it might happen in some
> situations). Since not all clients connected to the network at the
> same time, we assume that one third of them hasn't received the third
> RA in a row at some point in time. At this particular point at least
> 1k clients start sending out RS in a short period of time, at least
> until the first RA makes it through. A way of distributing this RS on
> a time scale might be a good idea. At some point we should use a
> random value to make the hosts delay sending RS with different values
> 
> Long story short: Please include Teemu's suggestion (randomization) in
> a possible errata. IMHO this must be part of it!

I agree. We definitely consider this but also other problems. Looking
forward to publishing the ideas and discussing it here.

Just a note. Current code of NetworkManager for Linux sends RS
non-randomized 5 seconds before expiration.

Pavel

> FYI: Although I see the race condition and I would also like to see an
> errata on this issue, I'd like to point anyone having problems with
> lossy links to RFC 1256, page 3.
> > Links that suffer high packet loss rates or frequent partitioning are accommodated by increasing the rate of advertisements, rather than increasing the number of solicitations that hosts are permitted to send.
> 
> regards
>   Dan