[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] cache issues in LISP and CONS - it's bad . . .
There is an updated version of the comparison chart at the end of
this message.
Hi Bill,
I am keen for you and proponents of LISP-CONS to critique my example
of dropped (or excessively delayed) packets and sending host time-outs:
http://psg.com/lists/rrg/2007/msg00462.html
Can anyone provide typical first and second attempt time-out values
for host code which sends UDP packets to nameservers? Likewise,
what are typical first time-out values for establishing a TCP session?
Delaying the packet until a mapping response arrives will be better
than dropping the packet if the mapping arrives early enough that
the tunneled packet will generate a response which arrives at the
original sending host before that sending host times out. This will
still delay the establishment of communications compared to
LISP-NERD, eFIT-APT and Ivip, but not as much as would dropping the
packet.
People in the USA and I guess Western Europe may be used to pretty
fast DNS lookups in general for the sites they most commonly
communicate with, but that is not the case for folks in the colonies
like Australia or New Zealand who often access servers in the USA
and Europe. Does anyone have subjective impressions of this? Many
people on this list travel to far-flung places.
Thanks for clarifying my understanding of TRRP - reminding me of
something I did understand but did not recall when I wrote this chart.
> I'm unclear what you mean here. Would you clarify?
>
>> Caching ITR must Yes No No Yes
>> drop packets it
>> has no mapping for?
>
> Actually, the ITR for TRRP is not required to drop packets for which
> it has no map. It may drop packets if memory is tight or the mapping
> occurs too slowly, but should attempt to hold them for transmission on
> receiving a mapping. Specific strategies for determining which packets
> to hold and for how long are not proposed.
Also:
>> Incremental RRG Yes
>> deployment via messages
>> "anycast ITRs in 264 & 288
>> the core"?
>
> The answer for TRRP is Yes as well. Note the first sentence of phase 3
> at http://bill.herrin.us/network/trrp-implementation.html which
> explicitly envisions this step.
That sentence is:
Carrot: ISPs notice that by implementing a local ITR they get
better connectivity with servers hosted on the Micronets.
I think the most relevant sentence is in Phase 2:
ARIN contracts one ISP to provide a route-of-last-resort for the
the entire group of Micronets which leads to an ITR.
This form of the sentence is somewhat ambiguous, because one parsing
of it is that "the entire group of Micronets which leads to an ITR"
involves a description of this entire group leading to an ITR. A
better form of the sentence, according to my understanding, is:
ARIN (and likewise other RIRs, separately or together) contracts
one ISP to provide a route-of-last-resort for the the entire group
of Micronets. The ISP provides an ITR which advertises the BGP
prefixes from which the Micronets are allocated.
But this still involves "an ITR", which is not anycast. I am not
sure if you are saying that your proposal provides for "incremental
deployment", or "incremental deployment via anycast ITRs in the
core", so I have separated the two concepts in the chart.
In theory, I can imagine incremental deployment via a single ITR to
handle one or more prefixes which are split up by the ITR-ETR
system, but I think this would involve bottlenecks and overly long
paths often enough that it would soon be decided to create multiple
such ITRs, making it "anycast" as I have somewhat redefined the term
in Ivip.
If you want your proposal to be explicit about anycast, perhaps you
could change the last sentence and add some more sentences such as:
The ISP provides multiple ITR which advertise the BGP prefixes
from which the Micronets are allocated. Each ITR tunnels
packets which arrive from non-upgraded networks to the correct
ETR. While each ITR has a different IP address, this arrangement
of multiple BGP routers advertising the same prefix and
independently tunneling the packets to their destinations has
recently become known as "anycast ITRs in the core". This is
anycast routers with the same BGP advertisement, and with a single
destination host (reachable via one or more ETRs) for each address
or smaller subnet of addresses which the ITR maps. The original
RFC 1546 use of "anycast", involves multiple geographically
separate hosts with the same IP address, each with a separate BGP
router which advertises the same prefix which contains this
address.
But then your proposal will lose its terseness and start to resemble
a fulsome Ivip document!
Below is an updated version of the comparison chart.
- Robin
LISP-CONS LISP-NERD eFIT-APT Ivip TRRP
Full DB ITRs? No* Yes Default ITRD No
Mappers
Caching ITRs? All* No** ITR ITRC All
ITFH
Local query No* Default QSD No
servers for Mappers QSC
caching ITRs?
Caching ITR drops Drop No - No - Delay
packets it no sends goes to
mapping for or to >=0
delays them until Default ITRCs
mapping arrives? Mapper then
ITR
Distribution of Pull ITRs down Push Push Pull
database to CAR-CDR load DB & slow fast DNS-like
networks with global updates via Repli- global
ITRs etc.? network via HTTP BGP cator network
from DB system
servers &
other ITRs
Incremental Maybe: Yes: Yes:
deployment via Anycast Anycast Anycast?
one or more RRG mssg ITRs RRG mssg
(>1 = "anycast") 264 & 288 in the 484 ...
ITRs in the core? core
* Perhaps CONS might be changed to incorporate full DB ITRs to
which packets would be sent when the caching ITR has no
mapping information. See
http://psg.com/lists/rrg/2007/msg00464.html where Scott Brim,
co-author of the LISP-CONS ID, wrote: "default mapper :-)".
See also Dino's message 476 and following discussion 481 & 482
regarding Re-Encapsulating Tunnel Routers as "default mappers".
I suggested using these as local query servers.
** See RRG mssg 471 regarding LISP-NERD using CONS in the future if
it can't scale well for larger databases and/or more frequent
mapping updates - perhaps with some "regions" of EIDs being
handled quickly by NERD and others by CONS.
TRRP also has a method by which some ITRs (depending on how directly
they queried the authoritative DNS-like mapping information servers)
get push notification of changed mapping from the authoritative
mapping servers. However I think this would not would scale well.
LISP-NERD, eFIT-APT, Ivip are the only proposals in which all
packets are tunneled without delay. The original form of LISP-NERD
does it directly from the ITR, so path-lengths are always optimal -
but this is only for packets sent from sites which have been
upgraded. Messages 264 & 288 concern more distant ITRs, not unlike
Ivip's, to maintain connectivity from non-upgraded networks. With
Ivip, all packets find an ITR and so are tunneled immediately, but
the ITR may be far away (depending on where the nearest "anycast ITR
in the core" is), so the path may be sub-optimal. Every eFIT-APT
network has one or more default mappers (each is a full database ITR
and query server), which always tunnels packets, generally on
optimal paths - but there is currently no provision, AFAIK, for
tunneling packets sent by hosts in non-upgraded networks. (See RRG
mssgs 446 & 455.)
--
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