[RRG] Is 12 bytes really so scary?

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

I listened to the Friday morning meeting via a 64kbps MP3 stream -
and didn't notice any glitches whatsoever.  This is a modest,
commonplace, consumerish, data rate - completely uneventful, across
the planet in 17 hops from Oregon to Melbourne, Australia.

An ITR-ETR scheme with real-time (a few seconds ideally) push
distribution of mapping data only needs 12 bytes for each mapping
change, for IPv4:

  4 bytes  Micronet start address
  4 bytes  Length
  4 bytes  ETR address

Length would compress well, since in virtually all updates the upper
16 bits would be zero.  There's no need for lists of alternative
ETRs or for ITRs to decide between them.  This is assuming that the
ITRs are not required to follow instructions regarding load
splitting - ie. that the desired TE can be done by having some IP
addresses mapped to ETR-A and others to ETR-B etc.

12 bytes is all we need for IPv4.

IPv6 requires 32 bytes:

   8 bytes  Micronet start (bits 127 to 64)
   8 bytes  Length (bits 127 to 64)
  16 bytes  ETR address

but it will be a long time, if ever, before IPv6 is highly utilized
- and by then bandwidth, RAM etc. will be even cheaper.

Lets ignore protocol overhead for a moment.  There needs to be
authentication, error detection etc.  Also some management guff and
flags to say the following updates are all for IPv4 traffic with
IPv4 ETRs.  Also, I will ignore the likelihood that each full
database ITRD and QSD probably needs to get two separate streams of
data for robustness.

64kbps = 8k bytes = 666 updates a second = 20 billion a year.

Lets say we get to 100,000,000 multihomed end-user networks and each
has, on average, two micronets.  This is 200,000,000 micronets with
an average change rate of 2 a week.

The BGP system today, with ~240,000 prefixes, gives a router about 3
updates a second:

  http://bgpupdates.potaroo.net/instability/bgpupd.html

but quite a bit of this is convergence towards a final state.  I
think it is fair to say that the actual change of advertisements,
including those caused directly by outages, is half, a third or less
of this rate.

I don't see why the ITR-ETR proposals other than Ivip are based
entirely on the belief that it is impractical or undesirable to fan
out mapping changes to a few hundred thousand or a million ITRDs and
 Query Servers (QSDs).  Even if they all had to stream across the
globe like my MP3 packets travelled, I don't see it as so scary as
to be unthinkable.

Bandwidth, RAM and CPU power are cheap.

Distributing mapping in real time might involve several tree-like
structures, similar to multicast (maybe actual multicast, over a
tunneled overlay network), with each ITRD or QSD receiving (ideally)
two streams from different trees so the chance of packet loss is
minimised.  If a packet is not delivered, it can be requested from
one of several servers run by whoever created that packet (whoever
runs one or more Mapped Address Blocks).

By the time we get to this 100 million micronet stage, bandwidth,
RAM and CPU power will be cheaper still.

Planning and building an ITR-ETR scheme like this is non-trivial,
but it can be fast, efficient and robust - because it doesn't
involve routers chattering to their peers, spreading information
across the Net like rumours propagating through a crowd.

I don't see what is so scary about real-time control of the global
ITR system.

The advantages are obvious - simplicity for ITRs, simpler mapping
data, modular user control of mapping (multihoming service
restoration detection and logic as they choose, not all built into a
monolithic system) - and a whole new gutsy, efficient, approach to
mobility which doesn't require host changes and which works fine
with IPv4 and IPv6 alike.


I see a huge amount of activity with LISP based on the fervent
belief that we can't and never will be able to do real time push for
this growing stream of 12 byte update messages.

First there was LISP-CONS - a mess of new stuff to create a global
scale query server system.  It was clearly going to be slow, complex
and costly.  Now it is superseded.

LISP-NERD is a "push" system, but with each ITR asking for updates
from one of multiple relatively centralised servers.  At least there
is no packet delays or dropping.  But there isn't a concept of a
multicast-like replication system to fan the data out efficiently.
Nor is there the concept (as far as I recall) of caching ITRs and
local query servers.  LISP-NERD is to be left on the back-burner, in
favour of ALT.

eFIT-APT has even slower aspirations for distributing the data
globally, but has some smart (I think) arrangements for local
full-database Query Servers (Default Mappers) which are also ITRDs -
so most of the traffic is handled by caching ITRCs.  Now (according
to what I heard in the meeting), APT is to be merged with, or
adapted to, LISP.

TRRP relies on a global DNS-like query network.  I think this would
be simpler faster and more robust than CONS or ALT.  However it is
still too slow for realtime control and the simplifications and
modularity this enables.  I figure Bill Herrin will be busy for a
while with democrats.org .

LISP-ALT sounds nifty, but there are all sorts of delays in the
paths taken across the world in this global query server system too.
 One level of aggregation may be a router in the the USA, the next
in Japan, the next in the Netherlands.  The query packets traverse
the long tunnels between these routers, and have to make it all the
way back along the same tunnels.  There's no clear way of
authenticating the ETRs which are the authoritative query servers
for particular micronets, so the whole ALT overlay network needs to
be tied together carefully, manually, according to business
relationships.  That makes it expensive to administer and costly to
change.  Yet when the customer decides on a new ISP, they need to
change the IP address and the administrator of their ETRs.  So this
seems to defeat the purpose of ending provider lock-in.  (Ivip uses
username and password access, with a simple, lasting business
relationship to the organisation which runs whichever Mapped Address
Block the micronet is part of.  See RRG message 536.)

LISP is a complex mess of stuff and the IDs are now longer than Ivip's.


Ivip isn't finished, but it has a clear vision and is a lot better
explained than LISP.  There are no contradictory, incompatible,
variants - one cast aside after the other - as with LISP.

Since its inception in mid-June, Ivip has had a plan for
reachability from non-upgraded networks.  LISP finally adopted the
same system ("Anycast ITRs in the core" AKA "Proxy Tunnel Routers")
in late November.  APT doesn't have such a scheme and TRRP's
deployment plans uses the word "stick" and "carrot" frequently.

Ivip is the only ITR-ETR proposal to recognise that PMTUD problems
need to be solved.  I understand from the meeting today that the
LISP folks are of the view that there is no problem.  I would like
to see their reasons for this.  It would be nice if these problems
could be ignored, while still allowing for deep and flexible
placement of ITRs and ETRs.

My IPTM proposal looks pretty good to me for the current situation
of typically ~1500 byte MTU hosts and data links.  However, it has
problems when most hosts and most links are jumboframe compatible,
but we still need to assume ~1500 PMTUs between ITRs and ETRs.
Then, Fred Templin's critiques start to bite and his sprite-mtu
proposal starts to look better.  But sprite-mtu tends to assume that
most hosts will implement RFC 4821 - and I think this is unlikely to
occur any time soon, if ever.

I think Ivip or some other scheme with real-time, simple, mapping
data distribution is clearly the way forward - and the whole LISP
effort will be of little lasting value.  Alternatively, if LISP is
built, many people would soon start ripping it apart in order to
speed it up and achieve the simplicity, modularity and mobility
support that Ivip aspired to from the start.


  - 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