RE: [LinkSec] Failure of probe mechanisms to scale
Yes, particularly to your comment "I guess if the network is designed to
"encourage" user mobility, the
rate of mobility related events will generally be much higher than
other types of reconfig events".
In this case it is likely that there will be many more events, but each
event will involve fewer things moving, so the dynamics of races may be less
intense on the smallest time scales. Overall this means that the efects on
each move are less dramatic and must not be made dramatic, i.e. if one
station moves then other stations must not see any change in service,
whereas a reconfig that affects a significant perecentage of the stations
may affect connections from many others to those, so the entire population
of stations may be affected by the networks response - the aim is just to
get the reconfig over for everyone quickly.
Mick
-----Original Message-----
From: owner-stds-802-linksec@majordomo.ieee.org
[mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Mats
Naslund
Sent: Thursday, May 08, 2003 1:14 AM
To: mick_seaman@ieee.org
Cc: stds-802-linksec@ieee.org
Subject: Re: [LinkSec] Failure of probe mechanisms to scale
Thanks Mick,
Mick Seaman wrote:
>
>
> Mats,
>
> Depends what you mean by fundamental, since this is a question of scale
I guess I am asking if a solution to the bridge failure/reconfig case
would imply a solution to the mobility problem and/or conversely.
I guess one fundamental difference is that mobility can in many cases
be predicted/signalled some time in advance, whereas failures cannot.
Thus, handling mobility by a general reconfig solution might be
unnecessarily clumsy (though perhaps theoretically possible).
> i.e.
> of numbers. How many systems appear to move, in what timescale, in what
> time
> do other systems need to detect and restore or replace out dated
> information, where are the systems that can directly detect the move and
> how
> much information do they need to transfer to those that need to know but
> have no way of detecting the change. Conversely, is the set of information
> that could be shared before hand to remedy a time race large, and indeed
> what classifications of system types against a number of architectural
> variants are permitted.
>
> I suppose that if the number of end stations is 'E' and their mobility
rate
> 'e' while the number of bridges is 'B' and their acceptable
reconfiguration
> time rate for 95% upper case failure is 'b' then one could describe
> solutions as fundamentally different as they scale as O(Ee) or O(Bb) or
> some
> powers thereof or relationship between these and other parameters. In
those
> cases one could identify, against any particular solution, that some
> network
> changes are fundamentally different to some others.
I guess if the network is designed to "encourage" user mobility, the
rate of mobility related events will generally be much higher than
other types of reconfig events...
Thanks
/Mats
>
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Mats
> Naslund
> Sent: Wednesday, May 07, 2003 7:37 AM
> To: Russ Housley
> Cc: mick_seaman@ieee.org; stds-802-linksec@ieee.org
> Subject: Re: [LinkSec] Failure of probe mechanisms to scale
>
>
>
> Hi
>
> Out of curiosity: is there a fundamental difference (in terms
> of discovering/solving) between this scenario and the case of "mobiltity"?
>
> E.g. the fact that Y is connected via C rather than B could
> depend either on the fact that:
>
> * the path A -> B is down
> * Y has moved and is reachable from C, but no longer from B
> (e.g. Y pulled the 802.3 plug and is in the corridor using 802.11)
>
> Thanks
>
> /Mats