> From: Pekka Savola <pek...@netcore.fi>
> 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 <l...@cisco.com>
> 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
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
