From: kris@tpki.toppoint.de (Kristian Koehntopp)
Subject: Re: Z-Netz-Gateways :-(
X-Copyright: (C) Copyright 1992 Kristian Koehntopp -- All rights reserved.
		 Reproduktion, auch auszugsweise, ausserhalb elektronischer,
		 nichtkommerzieller Datennetze nur mit ausdruecklichem,
		 schriftlichem Einverstaendnis des Autors.
Organization: Toppoint Mailbox e.V.
Date: Sat, 22 Aug 1992 09:38:53 GMT
X-Excuse: X-Copyright wegen Emma, Suedwestpresse und /C'T/DISKUSSIONEN.

In <7396413a@p0.f55.n242.z2.fidonet.org> Thorsten_Seidel@242/55.fido.maus.de (Thorsten Seidel) writes:
>koennen, wenn ich das denn schon eingebaut haette. Sucht ihr im Z-Netz erst
>mal die Schwarzen Mailloecher...

Aufgrund der Struktur von Z-NETZ und den verwendeten
Algorithmen kann dort keine sichere Zustellung von
persoenlichen Nachrichten garantiert werden. Ob und wann eine
persoenliche Mail in diesem Netz ankommt, ist Glueckssache.

------------------------------------------------------------------------------
> From kris Thu Aug 20 16:52:45 1992
> From: kris
> Newsgroups: znet.koordination.diskurs
> Subject: PMail-Routing (war: MAP Der ELOI)
> Distribution: znet
> References: <39.1266@innoTEC1>
> X-Copyright: (C) Copyright 1992 Kristian Koehntopp -- All rights reserved.
> 		 Reproduktion, auch auszugsweise, ausserhalb elektronischer,
> 		 nichtkommerzieller Datennetze nur mit ausdruecklichem,
> 		 schriftlichem Einverstaendnis des Autors.
> X-Excuse: X-Copyright wegen Emma, Suedwestpresse und /C'T/DISKUSSIONEN.

In <39.1266@innoTEC1> g.klauberg@innotec1.zer.sub.org writes:
[ ... fuer dieses Repost nicht wesentliche Teile geloescht .. ]
>eigenes  Sueppchen kochen.  Vielleicht kann Kris ja nochmal seine Idee mit
>dem PMail-Netz etwas konkretisieren, vielleicht loest das ja das Problem.

Was ich zum Thema P-Mail-Routing zu sagen habe, ist folgendes:

	Generalzusammenfassung meiner Betrachtungen zum Routing
	von Mail in Netcall3.8-Netzen.

Das Zerberus-Mailboxprogramm ist ein Monolith, der weder
horizontal die verschiedenen Dienste trennt, noch vertikal die
verschiedenen Layers eines Netzwerks.

Das hat einen fatalen Denkfehler zur Folge: Man nimmt im
Z-NETZ, im CL, im FRAS und sonstwo an, dass sich dabei um
verschiedene Netzwerke handeln wuerde. Man meint damit, dass
diese Trennung bezueglich des Austausches von oeffentliches und
persoenlichen Nachrichten gilt.

Das ist nicht der Fall.

Es mag sein, dass bezueglich des Austausches von oeffentlichen
Nachrichten alle diese Netze klar unterscheidbar sind. Man muss
sich das wie Mengen vorstellen, die sie teilweise ueberlappen:

Die Elemente der Mengen sind die Systeme "im Netz" (also in der
Vereinigungsmenge aller Netze, aber jetzt wird die Definition
zyklisch, wenn wir schon formale Haare spalten wollen). Ein
einzelnes System kann in der Menge "FRAS" sein, wenn es die
FRAS-Bretter bezieht. Ein anderes System kann in der Menge
Z-NETZ sein, wenn es die Z-NETZ-Bretter bezieht. Ein drittes
System kann in den Mengen CL und Z-NETZ sein, weil es beide
Bretthierarchien bezieht. Alle diese Betrachtungen beziehen
sich, ich betone das noch einmal, auf den Austausch von
oeffentlichen Nachrichten.

Bezueglich des Austausches von persoenlichen Nachrichten kann
man den Unterschied nicht machen, solange es Systeme gibt, die
in mehr als einem Netz sind. Es gibt nur eine Menge, in der
alle Systeme drin sind, die nach dem Netcall-Verfahren
persoenliche Nachrichten austauschen, egal welchen anderen
(Brett-)Mengen das System sich selbst noch zurechnet.

Warum das so ist, habe ich in anderen Nachrichten schon
erlaeutert, aber ich will es hier noch einmal tun (ggf.
vorblaettern):

	Im Netcall-Format kann der Absender nur den Empfaenger
	einer Nachricht angeben, jedoch nicht den Weg dorthin.
	Der Weg zum Empfaenger wird von jedem System auf dem
	Weg neu entschieden.

	Im USENET nennt man so etwas aktives Rerouting, weil
	mit jedem System auf dem Weg die Route der Nachricht
	neu bestimmt wird. Im UUCP-Teil des USENET verwendet
	man aktives Rerouting wegen der sich daraus ergebenden
	Probleme nur mit aeusserster Vorsicht.
	
	Stattdessen legt der Absender den kompletten Pfad der
	Nachricht zum Empfaenger einmal fest und gibt ihn der
	Nachricht im Uebertragungskommando mit. Die
	Empfaengeradresse steht also im Header der Nachricht,
	daher nennt man diese auch "Headeradresse". Der Pfad
	zum Empfaenger steht im UUCP- oder SMTP-Kommando, mit
	dem die Nachricht uebertragen wird, also gewissermassen
	im Briefumschlag. Daher nennt man diese Adresse auch
	Envelope-Adresse.

	Z-NETZ kennt keine Envelope-Adresse, auch in ZCONNECT
	fehlt sie. Daher _muss_ jedes System die Route zum
	Empfaenger neu berechnen, es hat gar keine andere Wahl.

	Dabei koennen verschiedene Probleme auftauchen:

	- Wenn ein System auf dem Pfad der Nachricht das
	  Empfaengersystem nicht kennt, kann es keine weitere
	  Route berechnen. Die Nachricht ist nicht zustellbar
	  und verschwindet. Ein Mail-Loch.

	  Grafisch: 
	  
	  a-->b-->c-->?

	  Mail an user@d und c hat keine Ahnung.
	  
	- Wenn ein System auf dem Pfad andere Vorstellungen
	  hat, welchen Weg die Nachricht zu nehmen hat, als das
	  vorige System, kann es vorkommen, dass die Nachricht
	  zum vorigen System zurueck geht. Mail-Ping-Pong.

	  Grafisch:

	  a-->b-->c
	      ^---|

	  Mail an user@d und b und c spielen Ping-Pong. Solche
	  Schleifen koennen auch mehr als 2 Systeme umfassen.

	  WIR FOLGERN: Alle Systeme im Netz muessen die gleiche
	  Routing-Datenbasis benutzen, wenn man diesen Fall
	  ausschliessen moechte. Das ist unabhaengig davon, wie
	  diese Datenbasis generiert wird.

	  Die gleichzeitige, automatische Generierung einer
	  Routingdatenbank auf der Basis eines gemeinsamen
	  Datenbestandes kann da helfen. Mit anderen Worten:
	  ZMAP und Pathalias.

	- Die bisherigen Betrachtungen gehen davon aus, dass
	  die Zustellung von Mail atomar ist und keine Zeit
	  erfordert. Das ist in der Realitaet nicht der Fall.
	  Die Map sich aendern, waehrend eine Mail unterwegs
	  ist. Dann kann es vorkommen, dass eine Mail Teile
	  ihres Weges zurueck laeuft, also Pseudo-Ping-Pong
	  spielt. Das ist in diesem Fall korrekt.

	  Grafisch: Zeitpunkt t, es gilt Map m.

	  a-->b-->c (Mail) -->d-->e

	  Mail an user@e, die Mail ist bei c. Die neue Map
	  tritt in Kraft, die Mail laeuft weiter:

	  Zeitpunkt t', es gilt Map m'

	  a-->b<--c (Mail) <--d
	      |
	      +----->e

	  Der korrekte Pfad der Mail waere also a!b!c!b!e. Das
	  ist fuer diese eine spezielle Mail der optimale und
	  korrekte Pfad.

	  Ich rede von Pseudo-Ping-Pong, weil das Umkehren der
	  Mailrichtung nicht endlos ist. Gewissermassen fehlt
	  das Pong.

	- Die bisherigen Betrachtungen gehen davon aus, dass
	  die Zustellung von Mail nicht atomar ist, die
	  Umstellung der Map aber atomar und netzweit
	  gleichzeitig ist. Da die Map aber selbst als
	  Nachricht uebertragen wird (jedoch als oeffentliche!),
	  ist das nicht der Fall.  Die neue Map breitet sich
	  langsam im Netz aus und wird zu unterschiedlichen
	  Zeitpunkten installiert.

	  Daher kann es bei Aenderungen des Routings zu
	  lokalen, kurzfristigen Ping-Pong-Effekten kommen:

	  Grafisch: Zeitpunkt t, es gilt Map m.

	  a-->b (Mail) -->c-->d-->e

	  Mail an user@e, die Mail ist bei b. c, d und bekommen
	  per Netcall die neue Map.

	  Zeitpunkt t', es gilt Map m' auf c, d und e, aber
	  noch Map m auf a und b.

              v-----------+
	  a-->b (Mail) -->c<--d
	      ^
	      +------ e

	  Die Zeichnung ist etwas kompliziert: b routet noch
	  nach der alten Map an c. c nach der neuen jedoch
	  schon an b. Zugleich routet e schon Mail nach b, aber
	  b routet Mail fuer e noch ueber c und d. Wenn jetzt b
	  einen Netcall ausloest, passiert folgendes:


	      v----+
	  a-->b--> c (Mail) <--d
	      ^
	      +----e

	  Jetzt will c die Mail fuer e via b routen. c kann nur
	  hoffen, dass b inzwischen die neue Map einspielt, um
	  die Situation zu bereinigen. Ansonsten kann es
	  passieren, dass es zu einem echten Ping-Pong kommt.

	  Netcall3.8 nimmt Netcalls nur an, wenn der Transfer
	  in beiden Richtungen erfolgreich war. Dieses
	  Misfeature koennte sich in diesen Zusamenhang sogar
	  mal positiv auswirken, wenn man annimmt, dass auch
	  oeffentliche Nachrichten mit Mapdaten zwischen b und
	  c ausgetauscht werden. Dann klaert sich die Situation
	  sofort. Diese Annahme gilt im allgemeinen Fall jedoch
	  nicht.

	  Mit anderen Worten: Wegen des nicht-atomaren
	  Characters des Transfers kann es sogar mit ZMap und
	  Pathalias zu lokal begrenzten, sporadischen
	  Ping-Pong-Mails kommen. Das ist okay, wenn man
	  annimmt, dass die neue Map in kurzer Zeit alle
	  betroffenen Systeme erreicht. Da die Systeme
	  benachbart ist, sind die Chancen dafuer gut.
	  
	  BEACHTE: Bei persoenlichen Nachrichten und nur da
	  sind "Rekursionen" im Pfad erlaubt.

	  BEACHTE: Die betrachteten Probleme treten auf, weil
	  das Transferprotokoll nicht zwischen Envelope- und
	  Header-Adresse unterscheidet. Auch ZCONNECT tut das
	  nicht.

	Weitere Probleme treten auf, wenn es Systeme im Netz
	gibt, die nicht alle anderen Rechner im Netz kennen.
	Es kommt zu Mail-Loechern, also dem oben geschilderten
	ersten Fall.

	Beispiel:

	System a kennt alle CL- und Z-NETZ-Rechner.
	System b kennt alle CL-Rechner.
	System c kennt alle CL- und Z-NETZ-Rechner
	System d kennt alle Z-NETZ-Rechner.

	Die Mail,die auf a ankommt, auf a ist an user@d
	adressiert. a routet c und d via b.

	Der Rechner b kennt jedoch das Ziel d nicht und
	schmeisst die Mail weg.

	Ein anderes Problem entsteht, wenn in scheinbar
	getrennten Netzen zwei Rechner denselben Namen haben.

	Beispiel:

	System a kennt alle CL-Rechner. ("ist im CL").
	Ein anderen System a kennt alle Z-NETZ-Rechner.

	Ein System b kennt bisher alle CL-Rechner, moechte
	jetzt aber auch am Z-NETZ teilnehmen. Das ist nicht
	moeglich, denn dann muesste es a im CL und a in Z-NETZ
	unterscheiden. Das kann es nicht. Auf b ist immer eines
	von beiden Systemen nicht erreichbar.

Ab hier koennen wieder alle mitlesen:

KONZEQUENZEN:

- Alle Systeme, die Netcall 3.8 einsetzen, teilen sich fuer die
  Zustellung von persoenlichen Nachrichten einen gemeinsamen
  Namensraum.

  DAS HEISST: Alle diese Systeme sind in einem gemeinsamen
  Mail-Netzwerk. Dieses Netzwerk muss nicht "gegruendet"
  werden, es existiert schon jetzt als eine einfache Folge des
  verwendeten Protokolles.

  WIR FOLGERN: Es muss eine gemeinsame Koordination fuer CL,
  FRAS und Z-NETZ gebildet werden, die administrativ in den
  Griff bekommen muss, was technisch schon lange in einer Liga
  spielt.

- Alle Systeme, die Netcall 3.8 einsetzen, betreiben staendig
  aktives Rerouting von persoenlichen Nachrichten. 

  DAS HEISST: Alle dieses Systeme koennen Ping-Pong-Effekte
  erleiden, wenn lokal unterschiedliche Datenbasen fuer das
  Routing verwendet werden.

  WIR FOLGERN: Die Aufgabe der oben erwaehnten
  Globalkoordination muss sein, Routinginformationen fuer alle
  Netcall3.8 verwendenden Systeme zentral zu sammeln,
  aufzubereiten und an alle beteiligten Systeme verteilen.

  Mit anderen Worten: Jedes System, das in diesem Netz
  erreichbar sein soll, ob im FRAS, CL oder Z-NETZ, ob Gateway,
  assoziiertes System oder Vollmitglied, _muss_ eine Map abgeben,
  in der es sein P-Mail-Routing und nur das offenlegt. In die
  Map gehoeren keine Angaben ueber Brettrouting und keine
  Angaben ueber Direkt-, Eil- oder Crashmail, wie immer man das
  bezeichnen mag.

  Jedes dieser Systeme _muss_ sein Routing konform zu dieser
  Map durchfuehren.

- Alle Systeme, die Netcall3.8 einsetzen, koennen trotz der
  gemeinsamen Routingdatenbasis noch lokale, kurzfristige
  Ping-Pong-Effekte bei PMail erleiden. Solche Mails _sind
  keine Rekursionen_ und sollen nicht aussortiert werden.

  WIR FOLGERN: Rekursionstests duerfen nur bei oeffentlichen
  Nachrichten durchgefuehrt werden. Bei persoenlichen
  Nachrichten darf nur das Empfaengersystem (also dasjenige
  System, das hinter dem @ steht) Duplikate verwerfen.

- Alle Systeme, die Netcall3.8 einsetzen, koennen trotz der
  gemeinsamen Routingdatenbasis noch lokale, kurzfristige
  Ping-Pong-Effekte bei PMail erleiden. Diese Effekte
  verschwinden um so schneller, je schneller die aktuelle Map
  uebernommen wird.

  WIR FOLGERN: Alle Systeme sollten wenigstens das Brett mit
  den Routinginformationen ueber einen moeglichst kurzen und
  schnellen Pfad von der Koordination beziehen.

  WIR FOLGERN: Alle Systeme sollten die neue Map moeglichst
  schnell, das bedeutet automatisch und sofort, einspielen.
  
Man kann den letzten Gedanken noch weiter treiben: Angenommen,
alle Systeme beziehen die Map direkt ein einem zentralen
Server. Dann koennten sie auch gleich ihre Mail ueber diesen
Server abwickeln. Dann waere eine Map ueberfluessig.

Man sieht: Wenn alle Systeme im Netz aktives Rerouting machen
und wenn man trotzdem sicheres Mailrouting haben moechte, dann
wird der Gedanke des Netzes ad absurdum gefuehrt.

Weitere netzpolitische Konsequenzen:

Wenn sich der Gedanke des Mailnetzes durchsetzt, werden
/Z-NETZ, /CL und /FRAS zu dem, was sie eigentlich sind: Sie
sind keine Netze, sondern Nachrichten-Hierarchiebaeume mit einem
Stammpublikum.

Fuer diese Hierarchien ist es dann auch egal, auf welche Weise
die weiterbefoerdert werden, ob mit Netcall, Maustausch, Fido,
RFC oder ZConnect.

Das Mailnetz selbst wird irgendwann wegen seiner
konstruktionsbedingten Maengel und inhaerenten Unsicherheit
immer kleiner werden.

Kristian

-- 
Kristian Koehntopp, Harmsstrasse 98, FRG W-2300 Kiel, +49 431 676689
"More Hardware! Less Software!" -- Old Marketing Chant