Subject: [rrg] Ivip fast-push mapping sys. I am simplifying the Launch server part

From: Robin Whittle <[email-masked]>
Date: Fri, 15 Jan 2010 23:01:38 +1100

When reading about Ivip's Fast push Mapping distribution System (FMS)
 in the current IDs:

  http://tools.ietf.org/html/draft-whittle-ivip-arch-03
  http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-02

please ignore the material about the Launch servers being different
from the Replicators, operating as a single system with complex
protocols for them by which they form a quorum and decide which
packets to send the level 1 Replicators.

There's a much easier way.  I will describe it properly in a later
message and will update the drafts.  Here's a short version:

I will probably drop the term "Launch server" and replace it with
"level 0 Replicator".  4 to 6 of them should be fine.  They are the
same as Replicators, but this set of 6 or whatever are "fully
meshed": each drives all the others.  Each RUAS sends update packets
to, ideally, all level 0 Replicators.  There is no need for the
RUASes to be synchronised or to communicate, except perhaps for the
purpose of each RUAS having a quota of packets it can send in the
next second or so, in order to limit the total number of packets sent
to all Replicators.

This is a flooding system at a packet-by-packet level, with each
packet being identified by the RUAS number and a sequence number for
that RUAS.  Each would also carry a timestamp for when it was sent,
but the RUAS number and sequence number is all the Replicators use
when deciding whether they have already received a packet with these
contents before.  As per the current IDs, packets arrive from RUASes
or from other Replicators protected, for each such link, by DTLS.
These identifying numbers, timestamp and mapping data are in the
deciphered version of the packet.

Two packets with deciphered payloads containing identical RUAS and
sequence numbers carry the same payload of mapping information, even
though the packets themselves, from different sources, will be
different when they arrive due to the DTLS encryption.

The Replicator sends 20 or so (more is probably practical) "copies"
of the first packet it receives with a new combination of RUAS number
and sequence number.  It ignores subsequent copies.  These resultant
packets have the same two numbers, time-stamp and mapping
information, but are separately DTLS encrypted for each destination
device (another Replicator or a QSD).

This is a simple, packet-by-packet, flooding system which should be
really simple, robust and fast.  It is asynchronous.  I find it hard
to imagine a simpler or faster global system for distribution of
mapping.  Has anyone heard of such a system?  It wouldn't be
surprising if someone has already worked on a system like this.

One thing I will add to future drafts is a note about the length of
these packets.  Today, and no-doubt in the future, the packets would
have to be of some sub-1500 byte length, such as 1470 or 1470.  All
QSDs and all Replicators would need an MTU of at least this between
each other.

In the probably distant future, with jumbo-frame (~9k bytes) capable
DFZ and with most ISP and large end-user networks also with ~9kbyte
MTUs, it would be desirable to build a second, parallel, FMS system
with Replicators and QSDs handling fewer ~9kbyte packets.  This would
require a separate set of packets being emitted by the RUAS for the
second system, which has ~9kbyte MTUs between all its Replicators and
QSDs.  Each QSD would get its mapping feed from either the original
~1.5kbyte system or from the new one.  There would need to be a
second set of copies of packets in the lost-packet servers too.

  - Robin