Short version: Effects of perceived performance degradation on
voluntary adoption rates.
Mobile Nodes could rapidly get new addresses just
due to RF and network traffic variations, even if
they are not moving at all.
Hi Noel,
Sorry about my "Joel". You wrote:
>> As far as I know, no-one in the main LISP team has developed a better
>> mapping system or suggested that one should or will be developed
>> ...
>> Please mention what this is, with references.
>
> After a great deal of work (extensive detailed simulation, etc), a paper has
> been written and submitted to a conference, but it's not public quite yet.
> Hopefully it will be public Real Soon. (Sorry, but it's not a paper I had
> anything to do with, so I don't feel I can say more than that - I merely
> commented privately on a draft.) Work has started on a spec, but again it's
> still not public, alas.
OK. Perhaps this paper could be mentioned in the "Rebuttal" or in
later debate.
> However, the Map-Resolver/Map-Server interface to the mapping system, which
> allows use of different mapping system 'back-ends' is already fully public.
>
>>> In light of that, you might want to move the ALT discussion to the
>>> end, and clearly separate it from the discussion of LISP as a whole.
>
>> Since I don't yet know what the alternative is, my critique is of LISP
>> with ALT.
>
> Understood, but that does not vitiate either half of the suggestion above.
> After all, as I pointed out, the mapping service interface _is_ already
> specified.
I have only got 500 words. I know various other things can be used
instead of ALT, but I am not aware of any which would be better.
>> I know there is a view that the delays which can easily be foreseen in
>> LISP-ALT are not significant enough to prevent it being adopted widely
>> enough to solve the routing scaling problem. I and some other people
>> disagree with this viewpoint.
>
> Pointing out the delays is fine. It's the flat assertion that this will
> produce a certain result out in the world I'm questioning. E.g. have you gone
> around to a significant subset of ISPs/large-content-providers, and asked
> them if these delays are unsupportable? If not, then the statement is merely
> your subjective, personal, opinion.
Absolutely. This is a subjective, personal opinion. It is a
negative value-judgement on LISP as it stands today and what
implications I foresee from this in the future. This is the nature
of a critique. This part of the critique concerns a vital aspect of
deployment that can't be experimented with - only found out the hard
way in the future.
I don't think it is hard to see that if end-user networks are given
the choice of LISP with significant perceived performance problems
and doing nothing, fewer of them will adopt LISP than if LISP or some
other architecture was offered and had no significant perceived
performance problems.
I don't accept arguments along the lines of "small end-user networks
won't mind so much" or "smaller networks won't have much choice if
they want affordable portability, multihoming etc.". If there is a
perception that the scalable routing solution provides second-rate
performance, and especially if larger end-networks avoid it for this
reason, and keep using PI prefixes, then most smaller end-user
networks will be keen to avoid it too.
>> With a global query server network, the delay in getting mapping will
>> frequently be longer than this, since the answer has to come from the
>> other side of the planet, which typically takes 350 to 400ms.
>
> There have been discussions on caching mappings in the Map-Resolvers, which
> will remove this delay for 'popular' destinations.
As I acknowledged, this will help - but only partially, to the degree
that other ITRs which use the same MR happened to have recently
requested mapping for an EID in the same EID prefix.
>> I assert that any global query server system for mapping lookups will
>> involve a significant performance degradation - sufficient to affect
>> the experience of users. I also assert that even if the measured impact
>> on end-users is minimal, the perception of this reduced performance
>> will significantly reduce the chance of widespread voluntary adoption
>> to a degree which threatens the ability of the system to solve the
>> routing scaling problem.
>
> And I assert the contrary. Arbitrary assertions, with no supporting evidence,
> have no place in this document.
They certainly do. I (and potentially others) am writing a critique,
and you and other people are going to respond to it.
To the extent that your response is credible to RRG folks, the
critique will be seen to be falsely based.
I am writing a critique - not an official RRG assessment of LISP.
>> Every time an LISP-MN gets a new RLOC address ... then all the ITRs in
>> the world need to suddenly change their mapping to the new RLOC address.
>
> No, only the ones the LISP-MN is currently communicating with. Why would some
> ITR which has never communicated with the MN, and never will, need the updated
> mapping?
OK - I should have written that all the ITRs which are sending to the
MN need to get new mapping at that instant (really a little before)
in order to avoid loss of connection via the EID address(es).
So all the cached mapping in ITRs anywhere in the world for this EID
prefix need to be updated instantly, since any of those could need to
tunnel a packet addressed to this EID a fraction of a second after
the MN gets the new ETR address.
Likewise any mapping stored in caching Map Resolvers.
Even if you had a real-time method of updating all those caches, it
is overly costly, since the MN could be getting new addresses very
rapidly. A MN on a cell-phone data system or WiFi can be perfectly
stationary, and due to varying RF propagation factors and especially
varying loads on the system, with various other devices changing
their transmission and reception patterns, the MN can be connected to
another part of the network.
I have been told that in a large city (Beijing was the example) that
a single 3G network with all its base-stations and base-station
controller has several IP gateways for the whole city. So just due
to varying RF and network conditions the MN could be tossed back and
forth between two base-station controllers in different sectors of
the city, and get a new IP address every time this happens.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
