This is becoming rather long, but I still prefer (barely) not to
start snipping. I've tried to be lucid and concise in the comments
inline, below:
=> Thanks! I think we can close some of the points as it seems that we're
at least seeing where we agree and disagree.
>> Heh! As I've seen it in action, you'll have hard time sweet-talking
>> me into closing my eyes to this. I've seen the benefits of running
>> both in parallel. If you want to close your eyes to the
>> mere possibility,
>> go ahead, but don't expect me to agree. It is indeed *very*
>> practical.
>
> It depends on what you mean by "both in parallel". I'm
> comparing a *host-based LMM mechanism* to an exclusively *network-based
> LMM mechanism*. Have you run those two in parallel? I don't think it
> would make sense to do that.
If you mean to do that in order to handle the same local mobility domain,
I would agree. I could however easily imagine cascading these, so
a small area would be handled by one, and a larger area by another,
each invisibly to the other.
=> Well, that might be possible in some cases, but I'm questioning the need for two
mechanisms to begin with. I'm afraid that the root of my problem here has
not been addressed. I.e. the problem statement. I don't expect you to answer
that; I'm trying to get a collective understanding of what the problem is. I don't
think there is one. If there is, it's certainly not documented in the PB draft. I think
that document is well below average in terms of logic, of course that's my opinion.
And I'd strongly maintain that your statement above:
"You're assuming that both host and network mobility can coexist.
On the surface this sounds conciliatory and ideal, but I'm afraid
it's not practical."
is clearly incorrect.
=> Well, it's inaccurately worded, I agree. I meant host-based LMM
and network-based LMM.
The proposal of using host-based mobility and network-based mobility
together in the manner proposed by NetLMM, with host-based mobility
handling global mobility and NetLMM (where deployed) handling local
mobility makes a lot of sense, and I haven't seen convincing arguments
to the contrary.
=> So let me summarise my contrary opinion as follows: I think its important,
and will continue to be important in future, to be able to get the same features
locally as those we get globally. I don't think we will be able to do that using
NETLMM. Examples of those features include the ability to select a particular access
technology over another, selecting an AP over another, managing flows over different
paths ....etc. IMO, it is insufficient to rely on Global mobility to do this. We need
to be able to do this *locally*. I know you mentioned some examples of attempts to
do this using NETLMM below but I think they're not practical and I'll respond to them
below. Well, I intended to make this short, but failed again :)
>
> Of course I am! I'm raising concerns against network-based
> LMM and my reference is the existing host-based LMM.
Oh! Oh, I see. This is not at all what I got from reading the draft.
What I understood was an attempt at arguing against network-based local
mobility support, in absolute terms, not relative to host-based *local*
mobility support.
=> Sorry, I guess that was my hidden plane of reference :)
> I don't see how it is possible that the network can predict
> better than the mobile since every link I've seen that is capable
> of this prediction bases such prediction on the information received
> from the mobile.
Aha. I've seen (and designed software for) systems which correlate
movement with roads and statistics of traffic flow, and from this
together with knowledge of radio lobes from the base station predict
where and when a handover is possible / desired.
=> Sure, I've seen a significant amount of research on this. However,
it is certainly more complex and so far it hasn't been close to being
in products. I believe mainly due to the inaccuracy of such predictablility.
Remember that you're mapping static information (a map) to a cell. That doesn't
tell u if a bus just stopped infront a mobile and reduced its coverage (giving
a simple example to illustrate the point). It might work fine if your MR is
on a train, but certainly not a generic model.
This can fairly
easily be done on the network side, but not as easily on the MN side.
=> I have to strongly disagree with that. I'm not a radio expert but I work
with those people, as I'm sure you do, and I believe they completely
disagree with this assumption.
> Of course,
>> for access technologies outside those known to a network, it
>> will know
>> nothing (unless the mobile tells it about those).
>
> Sure, but whether an access network is "known" is itself
> another big question. "known" should mean "known and functional".
> An AP might be present, responds to pings, but it's radio isn't
> functioning. So a server in the core would certainly know less
> about the state of the radio than a mobile which can detect whether
> an AP is funtional, available, limited ...etc.
No, I don't think that's a given. I see alarms going off if a
normally busy AP suddenly has no traffic, while the traffic
of neighbour APs are higher than normal. This is complex,
=> Exactly, it's a complex intelligent guess. I think you're willing
to accept it as a viable option because of your statement below:
but there's
nothing obvious about a statement that the MN always knows more
about everything.
=> This is I think where we come from completely different view points.
I think it is trivial and more ereliable that the MN is aware of all the surrounding choices
based on its available interfaces and the PHY measurements avaialable on those
interface.
> Ah, the WG is very new of course, the culture of "network control"
> is very old and we had these discussions for many years in MIP. Some
> of "no mobile involvement" approaches are even reflected in certain
> modes of FMIPv4 and v6.
So maybe it's time to lay those old argument to the side,
=> No problem, I'm happy to not mention the old arguments :)
and
acknowledge that both network-based and host-based mobility support
can bring good things to the table?
=> I'd be happy to acknowledge that if I thought it were true. I'm willing
to acknowledge, for example, an obvious point: There *can* be less BW consumed
over the air, in some link layers, if MN signalling is eliminated. But I don't
think that's worth all the troubles I see.
Right. What I was trying to say was 'Send comments about specific
text in of the problem statement to the netlmm list, to discuss it
there and try to improve it'. I think that is a more profitable
road for all...
=> Sure. Since netlmm is on this correspondence, I'd like to refer everyone
to section 2 of the draft which is all I have to say right now on the current
problem statement. If more comments come to mind I'll send them later.
> Not sure what you mean by "ad-hoc". You can certainly pre-config
> with Certificates ...etc but the point raised in the draft was two
> fold (assuming that you agree manual config is not practical):
> A. You don't want SA establishment during handover because it adds
> time. Since we don't want permanent NxM SAs (no of ARs times number
> of anchors), we have a timing problem. This is specific to NETLMM.
No, no, no. There is no reason why you can't set up these in advance,
and have N SAs in each anchor point, and M SAs in each AR, permanently.
N here is thousands, and M probably less than ten.
=> Yes, you can do that. But I want to put a real number for M, I'd estimate
for a country like the US, on average, N is about 25K (give or take depending
on the link layer) and M is more like 200-300.
The SAs are preconfigured and predicted easily. A network operator knows exactly how many
ARs he has, gives each of them a shared secret and scales
the AAA infrastructure accordingly. The SA is set at bootstrap and not on
the fly during handover time.
=> Nice take on my statement :) There is a difference though:
When you have millions of subsribers, you can associate them with different
AAAHs so you can say put 200K subs on each server (again a simplified example).
But in the netlmm case, you can't put N/100 ARs on each anchor, you need to put
all ARs on each anchor. I think the scalability here is clearly worse.
> B. It's not easy to deduce how many SAs are needed in the anchor based
> on the number of MNs it can support. This is a dimensioning
> challenge
> which only exists in NETLMM.
Again, not so. There is one SA needed in the anchor for each AR, not
for each MN.
=> Sure, I would agree with that.
An operator able to handle SAs for millions of MNs should
be able to handle SAs for thousands of ARs...
=> Not so easy with existing products. I looked at this
for real deployments.
Hesham
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
