Subject: Re: [rrg] Alternative LISP critique

From: [email-masked]
Date: Fri, 22 Jan 2010 06:27:59 EST

In einer eMail vom 22.01.2010 11:27:24 Westeuropäische Normalzeit schreibt  
[email-masked]:

share  some skepticism about buffering of packets, but there are a few
mitigation  methods that Noel didn't go into, such as pre-fetching of
EIDs that are  known (somehow) to be active, or maintaining a longer
cache for those that  are popular.  I would view this as an area of
future research,  something that it might be a good idea to more clearly
call out in each of  the proposed work items, since that perhaps is a
starting point for the  next phase of what is happening here.

Eliot,
Don't you recognize that caching is THE  repair-tool of a  miserable 
routing technique ?
Wouldn't it be better to implement a routing technology which doesn't need  
caching at all ?
 
Robin,
You several times emphasized the disadvantageous delay of the first packet  
due to LISP/ALT.
Wouldn't it be more appropriate to emphasize the disadvantageous delay of  
ALL packets due to the  Moore's law sabotaging routing technique as of  
today and as of all proposed mainstream-solutions ?
 
Heiner

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 22 Jan 2010 08:58:37 -0500 (EST)

> From: Pekka Savola <[email-masked]>

    > Easy to change to buffer instead of discard?  How, exactly?
    > High-speed routers do not do buffering in similar scenarios

Well, OK, maybe 'easy' was a bit too aggressive... :-)

What I really meant is that it was 'easy' from the point of view of the
overall system - i.e. you don't need to change the protocol, or do anything
at all _outside_ the ITR that is changing how _it_ handles cache misses.

The sense I got from the router people I talked to was that it was possible,
just that there was a certain amount of complexity in doing it right - you
have to have limits on the number of packets you buffer (to prevent DoS
attacks), etc, etc. But as you point out, its feasability in a particular
router design will of course depend on the internal design of that router.

    > even though required by specs today (example: buffering packets waiting
    > for ARP resolution).

Actually, that was one of the examples that was discussed in deciding whether
to deal with this now, or put it off! One side said 'look, most routers don't
bother buffering packets which have an ARP cache miss', and the other said
'yes, but the ARP cache has a much smaller fan-out, so you'll see a very
small number of dropped packets when a host first re-starts, and then no
more'. We could reach no firm conclusion. However, the fact that we _could_
put it off meant we did - we'll wait for empirical evidence to see whether or
not we need to handle it before putting out the time/energy to do so.

    > How deep such a buffer could be?

Well, for a non-malicious host, it shouldn't be more than one packet per
destination - it shouldn't retransmit the SYN (or equivalent) that quickly,
since it has no idea of the RTT to the destination).

    > From: Eliot Lear <[email-masked]>

    > there are a few mitigation methods that Noel didn't go into, such as
    > pre-fetching of EIDs that are known (somehow) to be active, or
    > maintaining a longer cache for those that are popular.

Well, these reduce the number of EIDs that you need to look up in 'real
time', but they don't get rid of the need for the host to re-transmit the
packet if you discard it - only buffering (or forwarding it through the
resolution hierarchy) can do that. So they are solving different problems.

BTW, pre-fetching is something that has already been discussed, as an easy
side-optimization of the optimization of caching mappings in the Map-Resolver
(ITR interface to the mapping system, for those who aren't familiar with
LISP). If the MR has a cache of all the recently-requested EIDs, an ITR
which is (re-)starting can simply go to the MR and say 'hey, give me the
contents of your mapping cache'; that will pre-load the ITR's cache with
most popular destinations.

	Noel