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 [EMAIL PROTECTED] 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
