Re: [RRG] Why delaying initial packets matters

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

Short version:

   We have choices other than pure push or pure pull.

   A suitably flexible hybrid push-pull system can be deployed
   according to all the prevailing conditions and provide
   minimal packet delays, due to the use of query servers which
   are always local - a lot closer and faster responding than
   relying on a global query server network of a pure pull
   system such as CONS or ALT.

David Conrad wrote:

> Conceptually, as far as I can tell, we have a tradeoff.  All
> things being equal and relative to each other:
>
> 1) push-based systems will
>
>    a) not significantly increase latency/packet loss
>
>    b) be less scalable
>
>    c) allow less dynamicity
>
> 2) pull-based systems will
>
>    a) increase latency/packet loss, at least for the first
>       packet of a new 'flow'
>
>    b) be more scalable
>
>    c) permit more dynamicity
>
> Does anyone disagree with these assumptions?

I agree with these statements for pure push and pure pull except
that a fast enough push system will allow dynamicity (faster changes
of mapping information) in accordance with its speed.

Also, the only way a pure pull system can achieve high rates of
mapping change is to reduce the cache time, which directly increases
the frequency of requests and responses.  A pull system could be
modified with "notify", so that when the mapping changes within a
certain time (less than the caching time of the ITR) after a request
was responded to, the query server (ETR in LISP-ALT) sends a
notification to every such ITR that the mapping has changed.  This
would be more complex, harder to make reliable and secure, and would
have bottlenecks, but would alleviate the problem of all ITRs
having to send queries and get responses ever minute in order to
maintain one minute "dynamicity".

We have choices other than pure push or pure pull.

APT is a hybrid push-pull system with default mappers, which are
local query servers which also function as full database ITRs.  All
the other ITRs are caching ITRs and can get their mapping data very
quickly from these local query servers.  Even if the caching ITR
didn't send the traffic packet (as a request for mapping) and have
it encapsulated by the default mapper, but held the packet until the
mapping data arrived, there would still be very little delay in
initial packets.

Ivip is a more flexible hybrid push-pull system.

Hybrid push-pull map-encap schemes need not delay initial packets by
more than a few tens of milliseconds (typical, unless the request or
response packet is dropped, which occasionally it will be), since
one or more local query servers and perhaps full database ITRs are
not far away.

(The LISP-NERD ID uses "hybrid" in a different way - ITRs might have
full mapping for some parts of the mapped address space and use a
query server network to get mapping for EIDs outside that space.
This is not the sort of "hybrid" I am referring to, though it may
have some benefits.)


I think the primary attraction of pure pull is that there is only
one copy of the database - fully distributed to the ETRs (or some
other kind of query server) which are closely associated with the
end-users.  That way, if an end-user wants to have a vast number of
EIDs, and to change their mapping every few seconds, this imposes no
cost on the rest of the system.

The primary objection to pure push is that every ITR in the world
would need to get every update for every EID, requiring a lot of
traffic and storage for updates which are never in fact used.


Hybrid push-pull enables mapping data to be pushed to some point -
for full database ITRs and query servers - and for the rest of the
ITRs to be caching ITRs getting mapping data quickly from these
local query servers.


In order for a pure pull system to be shown to be optimal, I think
it would be necessary to show that every possible hybrid push-pull
system would be unreasonably expensive, impractical etc. considering
the benefits they provide.


I need to write up my ideas for Ivip's fast push mapping
distribution system to show it is practical and desirable,
considering the benefits (minimal packet delay and support for a
new, efficient, kind of mobility).

I will do this as soon as I can, along with rewriting the rest of
the material in a more approachable fashion and updating my approach
to PMTUD and fragmentation.


A hybrid system such as Ivip - with notification from the full
database query servers to all ITRs which recently queried some
mapping information which has changed - will be highly flexible.  It
could deployed according to local conditions, traffic patterns, the
technology of the day and according to the size and rate of change
of the mapping database.

I will argue in greater detail later that even when the largest
realistic estimates of number of EIDs/micronets eventuate, it will
always will be practical and desirable to push to some number of
full database query servers around the Net.

That number is likely to be in the tens to hundreds of thousands,
but even if it was only to a hundred query server sites, that would
still solve the initial packet delay problem, since ITRs would get
their mapping information from the nearest such site which is far
faster and more reliable than relying on a global query server
network such as ALT.

Also, I think it is far more modular, secure and manageable to
control the mapping information with a completely separate system
which has nothing necessarily to do with ETRs.  NERD, Ivip and I
think APT either allow or require this, while my impression of ALT
is that the ETRs are typically, or always, the authoritative source
of mapping information.

 - Robin          http://www.firstpr.com.au/ip/ivip/


--
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