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