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 _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
