Hi Hesham,
on 2006-05-07 01:28 Soliman, Hesham said the following:
...
>> > The NETLMM approach is described on a high level in the current
>> > charter. Simply put, NETLMM expects to place a mobility anchor point
>> > in the visited network, which acts like a home agent. The mobile node
>> > will be configured with an address on the anchor point's link and
>> > keep it for the time it is located in the NETLMM domain. The anchor
>> > point binds the mobile node's address to its current default router
>> > (or Access Router, AR). Hence, whenever the mobile node moves, the
>> > new AR will bind its address to the one allocated to the mobile node.
>> > Tunneling is done between the anchor point and the AR. Therefore,
>> > the AR's address can be seen as a Care-of address for the mobile
>> > node. On a more detailed level, several minor changes can be made;
>> > however, the overview above gives the general idea.
>>
>> This description is in part incorrect:
>> 1. The mobility anchor point *does not* act like a home agent.
>
> Well in the sense that it binds one relatively stable address to
> another.
No. It does *not* bind one address to another. It updates the
routing rules for an IP address - there's no two addresses here to
bind together.
> Of course it's not exactly an HA.
Right. Except it seems you're still sticking to the idea that it's
'kind of' an HA. But again: it's not.
>>
>> It is important to understand that the basic functionality of a
>> NetLMM domain is to provide dynamic intra-domain routing, and if
>> you disregard scaling problems, this functionality could be
>> provided in part by use of e.g. OSPF. That the
>> proposed internal
>> architecture happens to have a local mobility anchor node (or
>> nodes) does not mean that these are like a home agent. They are
>> not.
>
> Not really an important issue, but ok you don't have to see it like
> an HA.
>
>>
>> 2. The introduction of the term 'Care-of address' is misleading.
>> A node attaching to a NetLMM domain gets an address by usual
>> means, just as when attaching to any other internet subnet.
>> The exact mechanism by which the route updates are done is
>> immaterial to this, and most importantly, there is no other
>> address involved which is associated with the node, that
>> would warrants the term 'Care-of address'. The node's IP
>> address is simply the node's IP address.
>
> Again, it's a simple analogy to the anchoring mechanisms in MIP.
> I'd rather not delve into a terminology debate at this point, I think
> we both understand the overall picture of the NETLMM approach described
> in
> the charter.
Sorry, Hesham. From the whole content of the draft, the basic problem
I see is that it seems you don't understand the overall picture. So
please don't try to dodge this as you do above - I think you need to
take a second look at this, and re-evaluate the 'simple analogy to the
anchoring mechanisms in MIP'.
>> 3.1. Applicability to different link layers
>>
>> Good discussion, apart from the sligth bias towards NetLMM-
>> bashing.
>
> I'm not bashing anything, I don't think that interpreting criticism
> as "bashing"
> is helpful. This is an emotional description that has nothing to do with
> the
> technical points made.
That's how I read it. Even if it was a good discussion, it wasn't a
purely objective discussion. If you don't want me to read it like that,
re-word. If you don't like to hear me read it like that, close your
ears. I'm not going to pretend that I read it differently than
I did.
>>
>> This part is incorrect. There is no inherent reason
>> why a network-
>> based mobility management scheme may not handle this in a
>> deterministic manner, based on policy or heuristics. Examples:
>> move to the a) link with highest basic bandwith; or b) the
>> link with highest user policy ranking; or c) link with lowest
>> cost; or indeed the link determined by any evaluation function
>> using these and other criteria.
>
> I think the important point here is who is evaluating this? I think
> both sides (the MN and a networking entity) should evaluate and make
> their ultimate decisions based on their preferences. Making this a
> network-only
> decision is not workable. The network can't assume it knows everything
> about the types of connections that the device has or will have in the
> near future. It can't even tell if a device's interface is functioning
> properly!
Of course not. And the essential point here is that NetLMM *is not
trying to remove the device's part in this* ! You seem to persist in
believing this is so, when it isn't. Really.
> As for the reliable manner,
>> reliability is related to quality and determinism, and if the
>> link quality is made part in the evaluation, this may also be
>> covered. WHAT IS NOT given is that the resulting choice is
>> *optimal* from a user viewpoint. But consider that given the
>> posited availability of both network-based and
>> host-based mobility
>> support, the mobile may very well have the option of
>> establishing
>> a different ID for the different access types, and use host
>> mobility to switch between these...
>
> So you're jumping over many assumptions here. 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.
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.
> Having NETLMM *excludes* the host's ability to
> communicate with a local anchor. Hence, when you say host mobility is
> possible you must mean a host-HA relationship. This isn't efficient
> enough
> for the types of handovers, flow movement or multihoming decisions that
> a host might make. This also assumes that the overhead of having the
> remote
> HA is acceptable. It's not acceptable in many cases.
Oho! Please be very aware that here you're *not* arguing host-based
mobility versus network-based mobility; you're arguing one particular
type of local mobility-support versus another type. THIS can be a
very interesting discussion indeed, but it is *not* a host-based
mobility versus network-based mobility discussion, which is what
your draft seems to be about.
>
>> But we do! There's nothin inherent or planned in NetLMM to
>> prohibit this! On the contrary, it is quite likely that this
>> will be the most common way of deploying NetLMM in combination
>> with host-based mobility.
>
> I really think you should reconsider this assumption. You seem
> to assume that an inter-access technology handover is host-based
> while not limiting the definition of a mobility domain to a single
> access technology. You can't have it both ways :)
Of course I can. There are more degrees of freedom here than can be
captured in the simple view that 'since A is able to handle inter-
access mobility, B has lost the freedom to handle it'. Both the set
of possible radio technologies, and the set of potential providers
of such are open-ended, and provide for much richer possibilities
than that.
>> Section 3.2., para. 5:
>>
>> > (b) Multi-homed end nodes will at some point be able to use different
>> > links for different applications depending on link
>> > quality/capabilities. It is easy to see that the level of complexity
>> > increases significantly when taking into account flow movement. The
>> > proliferation of applications and possibility that the end node is
>> > enabled with interfaces unknown to any given network-based mobility
>> > scheme makes this a difficult problem. How would a network based
>> > mobility management system know which flows to move to
>> which link?
>>
>> It wouldn't. And, more to the point, nobody has claimed that
>> it would or should!
>
> Same answer. Check the definition of local mobility. Not
> my definition!
I don't know what you want to say with this.
I'm trying to show that your fears about NetLMM is largely unfounded, and
it seems to me that you're wed to your fears, and won't let go of them
even if they're unfounded.
>> > (c) Since the coverage area of different technologies is likely to
>> > overlap, the decision to use one technology or the other becomes a
>> > policy decision. The end nodes will have to deal with making such
>> > policy decisions between different networks and they should be able
>> > to make the same decisions between different technologies. The
>> > network operator should define metrics (like cost, loading etc) but
>> > it should let the end host decide what to do. This is not a
>> > philosophical point; there are concrete reasons why the host needs to
>> > make this policy decision. For instance, the host is most
>> > knowledgeable about the applications it runs and what radio
>> > technologies are best suited to those applications.
>>
>> Agreed. And nobody has claimed otherwise!!
>
> Same answer ;)
Sorry, still doesn't fly. If you're just going to say that it doesn't
matter if things aren't the way you thought, you're still going to believe
what you've already decided, then there's no idea putting forward any
response at all, is there?
>> > End to end signaling is important and necessary in order to maintain
>> > the end to end design philosophy of the Internet. When it comes to
>> > localized mobility management, the end to end concept remains crucial
>> > to the robustness of the mobility management mechanism. Handovers are
>> > uncertain by nature and in some cases the new attachment point may
>> > change during the handover process. This is due to the volatile
>> > nature of the radio link at cell borders, which is typically the case
>> > in most cellular technologies. It is also known that mobile nodes can
>> > experience ping-pong movement, or cellular thrashing, during
>> > handovers; i.e. the mobile node may quickly move back and forth
>> > between two different access points for a short period of time. A
>> > network-based mobility management protocol can cause the mobile
>> > node's traffic to be routed to the wrong AR, i.e. the AR that the
>> > mobile node was expected to move to, but did not. This can result in
>> > packet losses. In contrast, if the IP mobility signaling is initiated
>> > from the mobile node, it would be able to discover that the next AR
>> > has changed and inform the network of its new choice. When the action
>> > is taken by the mobile node it can be done in a quicker manner for
>> > predictive or reactive handovers.
>>
>> I don't see that this follows. What would make it quicker,
>> when it has less predictive ability than the network, and
>> longer signalling paths?
>
> It's quicker because of most link layers the mobile knows
> first what it's best candidate will be. The mobile
> is in the best position to measure signals from other basestations
> to itself. So of course it will know first.
What you're describing here is not predictive capability, but reactive:
measuring what is. For the access technologies *known to it* a network
may be predictive, where a mobile node has a harder time of it. Of course,
for access technologies outside those known to a network, it will know
nothing (unless the mobile tells it about those).
So, my question above stands:
I don't see that this follows. What would make it quicker,
when it has less predictive ability than the network, and
longer signalling paths?
>> > One of the unwritten motivations of NETLMM is that some operators and
>> > vendors "believe" that the network must control the handover. Lets
>> > explore this belief a bit more. Specifically, what does network
>> > control mean? Why is it needed? And how does a network-based mobility
>> > management mechanism allow for more control?
>>
>> Since this is an allegation of unwritten motivation, it is of
>> course hard to prove otherwise.
>
> It was a spoken motivation that I heard for many many people
> over the last 5 years. So it's not something I made up.
Since the NetLMM work is *much* younger than 5 years, I don't know
what other efforts you're overloading on the current one here.
> I believe this is more in the
>> mind of the author than in the minds of those who work on the
>> NetLMM design.
>
> Not at all. I think you're doing the mind reading now.
Be my guest.
>> But there is a MUCH deeper danger here than mis-representation
>> of motivations; and that is to perpetuate the either-or
>> dichotomy
>> between host-based and network-based mobility support. Looking
>> closer at the respective advantages of network-based
>> and host-based
>> mobility, we find that in their pure state, both have
>> clear draw-
>> backs, which best can be complemented by the other. So the
>> title of the current section paints a picture of strife, where
>> the optimal solution is cooperation.
>
> All I'm asking for is a clear and coherent problem statement that
> justifies what you claim above. The claims in the current statement
> are frankly well below the average engineering common sense. I really
> hope someone can show me how these claims make any sense or are backed
> by
> any data. Simply saying that "each approach has its problems" is not
> good
> enough or technical enough for me to agree.
Fine. So comment on the problem statement.
>> > The above situation is more difficult to support when a network-based
>> > mobility management mechanism is adopted. In particular, the
>> > following problem arises. An anchor point may be required to setup a
>> > security association with any access router in the network at any
>> > time. A network administrator is suddenly forced to consider the
>> > impacts on memory capacity and the speed of the security association
>> > establishment at the critical handover time. This situation does not
>> > arise when the signaling is done end-to-end because in this case only
>> > one security association is needed, regardless of the mobile node's
>> > location. Furthermore, the security association does not need to be
>> > established during the critical handover time.
>>
>> And neither does it in a NetLMM case -- the most natural to
>> me would be to pre-configure these, not to try to do it ad-hoc.
>
> I don't think this is feasible in a practical deployment. I've worked
> on and seen these networks deployed. Imagine a situation where you have
> a 100 - 200 local agents and 10 - 20 K basestations, each containing an
> AR. Now
> try to manually configure SAs between all ARs and all anchors and
> maintain
> those SAs, i.e. roll the keys ....etc I don't think you'll find many
> people wanting
> to manage things this way.
No. Of course you don't want to manually manage 20 K base-stations' SAs.
But that doesn't mean that you can't pre-configure the relationships
using other means than manually handling each of them. The point is
that you wouldn't do it ad-hoc.
>> > The endorsement of more than one alternative for the same problem
>> > needs to be strongly justified. Unfortunately this was not the case
>> > for the NETLMM work in IETF. Both NETLMM BoFs clearly stated that the
>> > WG will exclude the mobile node from the IP mobility management
>> > signaling, which is not a typical requirement related to a problem,
>> > but one designed around a solution. This premise was challenged in
>> > both BoFs. Despite lack of clear consensus, the IESG decided to form
>> > the WG. The problem here is two-fold: How do we decide on new WGs?
>> > And what is the impact of solving the same problem in two different
>> > standards? Both questions are not specific to the NETLMM WG, however,
>> > this WG illustrates the need for a uniform and
>> predictable process.
>>
>> This argument seems to be based on the idea that there exists
>> an alternative to NetLMM within the IETF. This I don't see,
>> maybe because I see host-based and network-based mobility
>> support as complementary technologies, and mutually beneficial.
>
> Right, I think we disagree on that. I don't think they're
> complementary.
This is a pity, and also, I think, the essence of the difference in
views. I've seen how they can be, in very beneficial ways, and I'm
sad that you don't...
Henrik
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
