Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> wrote:
    >> So assuming some decent high-power 802.11ac in the Bradford house
    >> (http://en.wikipedia.org/wiki/Eight_Is_Enough) to link the per-room 
router to
    >> legacy 802.11b and per-person (phone) router to BTLE/PAN, it means we 
have
    >> about 30 routers on the wifi.

    > I'm under opposing pressures relating to scaling.  A lot of people, like
    > you, seem to think it's irrelevant, some others feel very strongly about 
it.

I'm not claiming its irrelevant, I'm claiming that it won't bite us all at once.
I accept that some homenet-type installations will go up to 250 routers
(which is only 1 order of magnitude larger than 30, btw), but they won't go
up to 250 without some thought about it.  So I totally agree with you:

    > The thinking is that if Homenet routers are cheaply and widely available,
    > then people will use them for larger deployments; no amount of legislating
    > such uses out of scope will change that fact.  The obvious example would
    > be a hotel: why pay for a professionally installed network when you can
    > just plug in a bunch of $40 Homenet routers and be done with your customer
    > network.  I can well imagine a hotel using 200 routers.

but, what I'm claiming is that the 200 routers won't be in a single wifi
channel.    The network will get a small amount of tuning, if only because
the walls will get in the way and some people will have to run some cables in
places.  That's exactly what most of think: that to scale things we need
wired back hauls, so while we hit 250 routers in the routing table, we don't
have to accomodate 250 routers forming adjacencies on a single wifi channel.

    > If hotels don't meet your fancy -- think schools, think appartment blocks
    > in third world countries, think hippy communes.  Do we wish to explicitly
    > support such use cases?  Hopefully not.  But do we wish to have our
    > protocols collapse just because we didn't have the foresight to avoid
    > gratuitious limitations?

So, there are limitations like:
      struct router all_the_routers[256];

and then there are protocol collapses due to taking the entire channel for
adjacencies as happened with OLPC.  The trickle mechanism of DNCP ought to
deal with that.

What we need to do is to make sure that whatever parameters we pick for
scaling fail in a safe way when exceeded.  I'd rather that the router which
has HomeNet v1 parameters in it just stops when it reaches some limit rather
than cause congestion collapse.  The router will then get replaced (or
better, reflashed), but if not, it won't get in the way of the newer, better
tuned devices.

--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to