Re: [RRG] Why delaying initial packets matters

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

Hi Noel,

You wrote, in part:

> Yes, but... A hybrid system is inevitably going to be more
> complex, and I think we should avoid complexity unless absolutely
> 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.

Yes, I am keeping an eye on that.

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

However if you expect those local caches to accumulate a large body
of information - large enough to make reliance on the slow ALT
global query server system rare enough not to be much of a problem -
then you are going to have to cache mapping information for a long
time.  This has the severe cost that you either need to accept low
rates of mapping change by end-users, or you need to add complexity
in the form of a "notify" system when the mapping is changed.

Even with such a caching scheme with notification, the worst case
situation will occur frequently enough to be a blight on this new
kind of address space: where the mapping and initial packet delivery
depends on the slow and not necessarily reliable ALT network.

I would rather have a clean, ideally fast, push system to get the
mapping data out to lots of ITRs and full database query servers.

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

I think this definitely should be pursued in parallel with hybrid
push-pull arrangements.


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

But what if the ETR is not reachable?  This reliance on ETRs for
functions other than decapsulating packets and responding to
reachability and PMTU probing strikes me as problematic and overly
complex.  For one thing, you have to have inter-ETR communication.
For another you need a lot of *configuration* and authentication
stuff, since an ETR is likely to be owned by an ISP, but it would
need a way of proving to ITRs all around the Net (and the ALT
network etc.) that it is one of the authoritative sources of mapping
information for an EID which is assigned to an end-user.

With a push or hybrid push-pull system, the ETRs are not involved in
the mapping information at all.  So a whole bunch of ETRs can
disappear and the system still works fine, using other ETRs.

> We're jacking up the internetwork layer and putting a whole new
> layer in there, and also adding another layer of binding. That's a
> Big Step. Let's do something significant, not just the minimal
> patch.

Yes, so let's think boldly.

Extra complexity is sometimes necessary to cope with some problem or
effect some kind of trade-off.  This is a bore, but can at times be
justified.

Complexity is better justified when it does more than round the
edges off an uncomfortable design.  When one piece of complexity
solves more than one significant problem, or provides multiple
benefits, then it is really earning its keep.

The most radical thing about Ivip is the proposal to push mapping
data fast - a few seconds or so - to as many full database ITRs and
Query Servers as people feel like running.  I believe this
complexity is justified by multiple benefits:

  1 - Simpler mapping information - just an ETR address.
      (A cost of this is no explicit TE in the ITRs - end
      users need to do load sharing by using small micronets,
      including single IP addresses, and pointing some to one
      ETR, some to another etc.)

  2 - Removing the need for ITRs to test for reachability,
      make decisions about which ETR to use etc.  (ITRs will
      still need to do some PMTUD and fragmentation work.)

  3 - Removing from the map-encap system the process of
      determining in real-time where the packets are forwarded
      to.  Instead, that is controlled by the end-user, in
      whatever way they like.  This modularisation is a major
      feature of Ivip.

  4 - Support for a new kind of IPv4/6 mobility with optimal
      or typically close to optimal path lengths, without
      fundamental change in the TCP/IP stack or applications.


The future map-encap architecture is at least as big a step as
designing IPv6 - because if we get it right, it is assured of
widespread adoption.  So I think we should be bold and contemplate
additional and novel complexity if it brings us fruitful results.

   - 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