Re: [RRG] Why delaying initial packets matters

[Robin Whittle <rw@firstpr.com.au>]

Hi David,

You wrote, in part:

> The mapping service (e.g., DNS) servers can exist in locator
> space.  

Yes, but I think we want end-users who run their own DNS to be happy
putting their servers on their own map-encap space machines.

If there are too many gotchas, such as "It might be best not to run
DNS on map-encap addresses", then this puts up another barrier to
the widespread adoption we are relying on.

> In fact, this makes many things much easier (e.g.,
> avoiding circular dependency).  

Any aspect of the map-encap system which depends on some part of the
DNS will come with a requirement that all such DNS servers are on
ordinary addresses (RLOC in LISP).  This is unlikely to involve
end-users.

In Ivip, each end-user's mapping is changed via a system which is
secured with a username and password.  It doesn't rely on any
physical infrastructure of the end-user, and could be done manually,
or by some multihoming monitoring system run by another company.

Ivip would involve being able to download snapshots of various parts
of the mapping database, probably by HTTP.  The organisations which
provide these (Root Update Authorisation System) would be using PI
space for all their servers, including DNS.


> I believe Brian's point was that extra delays of measurable kind
> have _not_, even when perceptible by end users, been fatal in the
> past. 

I am not saying they would be "fatal".

People will have a choice whether to adopt the new address space or
not.  Any cause of extra delay, unreliability etc. will make them
very wary of adopting it.   This may be true even if in our wiser
judgement we consider the problem to be negligible.  As long as
there is a perceived deficiency, it will be much harder to have the
new space widely adopted.


> People adjust.  Software developers adjust.

They do when there is no choice.  Maybe for some or many end-users
there will be no choice - they can't get PI space for one reason or
another.  In that case, it doesn't matter a lot if the map-encap
space has problems.

Rapid adoption would be fostered by the new space having no such
problems.


> And to be clear, the delays you are concerned with are at
> communication initiation with a "new" endpoint only. A time when
> a few hundred more milliseconds of latency would likely be lost
> in the noise of DNS lookups, connection handshake, crypto
> handshake, etc.

I am not convinced it would only be a total of a few hundred msec.
with ALT.

DNS lookup of B's IP address, A -> B and B -> A all could involve
delays while ITRs wait for a request (or initial packet) to traverse
this global query server system.  ALT also is likely to be less
reliable than a full database ITR or a caching ITR using a local (0
to a few hundred km) query server, due to the much longer path
length and therefore chance of packet loss.

The fact that extra delay beyond a few tens of milliseconds exists
is a reason for people to avoid it.  How strong a reason, I can't
say for sure - but waiting for things to respond on the Net is so
tiresome.  Anything which makes it worse will be thought of very dimly.


>> It will be difficult to convince end-users to pay money
>> (including less money) for the slower type of address space.
> 
> You are aware that there are still companies around that sell
> dialup, partly because they're significantly cheaper than DSL and
> cable, right?

Sure, but we don't want just the lower echelons of end-users to
adopt map-encap space.  We need it to be adopted widely, ultimately
ubiquitously.  Ideally this will happen because it is good and cheap
and flexible, not because it is second rate and cheap and a subset
of people adopt because they are cajoled into it and/or because they
aren't as fussy as other people.


>> LISP-NERD, APT and Ivip avoid these delays.
> 
> At the cost of scalability and slower update cycles.  TANSTAAFL.

APT and Ivip only need to get the mapping database updates to a
subset of the ITRs and to the query servers which the remainder of
the ITRs use.  NERD needs to get the updates to all ITRs.

I was hoping to write up more details of the fast database
distribution system which Ivip relies on, in the next few weeks, but
 work commitments will probably delay this.


>> Are there any major arguments for ALT (or CONS or any other
>> global query server system) other than that it can scale to
>> indefinitely large database sizes,
> 
> A pull system can potentially provide for much higher rates of
> change than a push system.  

Not unless there was some way of pushing updates to ITRs which might
need to know about it, or unless there was such a short caching time
that the query and response traffic would be excessive.


> As I believe has been mentioned in
> the past, a pull system (if augmented by forwarding) could even
> be used for mobility.

Do you mean by "forwarding" a way that the query server (in ALT, one
or more ETRs) remembers which ITRs asked it for mapping information
in some recent time period, and then sends updated mapping
information to those ITRs whenever the mapping is changed?

Ivip's Query Servers will do this, but this is a less onerous task
than with ALT, CONS or TRRP where the single (or one of a few) query
servers for the entire world has to do this, over much longer
distances to far more numerous ITRs.


>> while any architecture involving local query servers
>> (supposedly) could not handle such a large database?
> 
> In my mind, the question isn't so much about the size of the
> database (DRAM is cheap, disk is cheaper), but rather propagating
> updates.  It seems to me that pull systems are merely replicating

I think you mean:               push systems (e.g. NERD, APT & Ivip)

> some of the problems we face in the existing routing system since
> all updates must be propagated globally, regardless of whether
> they are of any interest to the source network, on the (given
> potential scaling targets essentially, statistically speaking,
> insignificant) chance that the source edge network _might_ want
> the update.

Yes.  With NERD, every ITR in the world gets to know about every
change in the mapping of every EID.

In APT, only the Default Mappers get all the updates.

In Ivip, only the full database ITRs and query servers get all the
updates.  Ivip is more flexible than APT regarding the location of
full database ITRs and Query Servers, with the rest of the work
being done by caching ITRs.

This greatly reduces the problem you refer to, but doesn't make it
go away entirely.

I don't think it is OK for any end-user to change their mapping
frequently (and they could change it once every few seconds with
Ivip) and have each change propagated around the world.  For one
thing, they could use it as a free broadcast channel . . .

I think mapping updates in any push system need to be either at a
low rate covered by some flat fee, or be charged for in some way, so
that those who make really frequent changes contribute in some way
to the cost of pushing the changes all round the world, and so will
think more carefully about making these changes.


>> Later, I will post an argument about why it is, and always will
>> be, practical and desirable to push even the largest imaginable
>> mapping database to a system of local query servers and/or
>> ITRs.
> 
> I'll be quite interested in reading it.

I am waiting for some more LISP-ALT folks to resurface on the list.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg