[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