Re: [RRG] Why delaying initial packets matters

[Stig Venaas <stig.venaas@uninett.no>]

Robin Whittle wrote:
> 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.

The other thing I would say, is that we have a tradeoff. But we
may need to look into host/stack/application behaviour to know
how important the various factors are when doing that tradeoff.

The main thing IMO is to have scalable routing, and some
in-optimal application behaviour or host/stack/application
changes may be a small price to pay. However, we should look
into those to make a more informed decision, not ignore them
until later. I guess this is where we need input from transport
or applications people...

Stig

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


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