Re: [RRG] Why delaying initial packets matters

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Robin Whittle <rw@firstpr.com.au>

    > We have choices other than pure push or pure pull.
    > A suitably flexible hybrid push-pull system can be deployed

Yes, but... A hybrid system is inevitably going to be more complex, and I
think we should avoid complexity unless absolutely unavoidable.

(This statement may come as a bit of a shock to some people, given some of
the complex systems I have been involved with in the past, such as:

  http://ana-3.lcs.mit.edu/~jnc/nimrod/nimrod_block_30_60.jpg

but I refer you to the end of my statement - "unless ... unavoidable".)

Complexity is bad for the whole usual bunch of reasons, but one big one in
this case (which isn't applicable in all cases) is that such a system will
need extra configuration, and we all know that extra configuration is often
problematic.


    > a lot closer and faster responding than relying on a global query
    > server network of a pure pull system such as CONS or ALT.

You can have systems which are 'pure pull' but which have the property that
queries are answered "a lot closer and faster", close to as fast as a push
system - just add intelligent caching. There's no reason on G-d's green earth
why a query for "google.com" shouldn't be answered at the nearest possible
node in the pseudo-hierarchy.

Best of all, with good caching, you get most of the speedup of a mixed
push/pull system with i) *no* configuration, and ii) almost no extra
mechanism (the caching I finally designed for CONS uses one counter in every
entry, and 1 bit in responses).

So I'd really like to see us try an optimized 'pull' system (one that
includes the optimization of forwarding un-mapped packets over an alternative
forwarding structure, i.e. no waiting for the binding to arrive, which could
worst-case be a complete round-trip, even with caching), and see if that
provides an acceptable level of service, before we get into the complexities
of hybrid push/pull systems.


    > the only way a pure pull system can achieve high rates of mapping
    > change is to reduce the cache time .. A pull system could be modified
    > with "notify", so that when the mapping changes within a certain time
    > .. after a request was responded to, the query server ..  sends a
    > notification to every such ITR that the mapping has changed.

There are other ways to do this. E.g. the ETR could notice that the packet is
for a destination EID which is no longer at that location, and return a "not
here now" error message to the source ITR. I haven't thought about it hard,
to find the best optimization; this is another place where there's a complex
tradeoff between performance, complexity and overhead.

	Noel

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