Zusammenfassung

  • IntServ bezahlte Genauigkeit mit Zustand pro Datenfluss; DiffServ bezahlte Skalierbarkeit mit geringerer Kenntnis über einzelne Anforderungen.
  • RFC 2990 vermisste Signale vom Kern zur Zulassungsgrenze und von dieser Grenze zur Anwendung.
  • Erst getrennte Nachweise für Entdeckung, Zulassung, Behandlung, gemessene Lieferung und Nutzung konnten eine Premiumklasse rechenschaftsfähig machen.

Verhalten ohne Lastgrenze reichte nicht

Eine bevorzugte Warteschlange erzeugt keine Ressource. Differenzierter Dienst braucht ein Verhalten und eine Regel dafür, wie viel Last zu diesem Verhalten zugelassen wird. Sonst wird Knappheit nur anders verteilt.

Integrated Services koppelte die Lastkontrolle an eine konkrete Anwendung. Sie beschrieb ihr Verkehrsprofil, RSVP trug die Reservierung entlang des Pfades, und Netzelemente hielten Ressourcen-, Klassifikations- und Messzustand. Eine Anforderung konnte angenommen oder zurückgewiesen werden.

Mit jeder Reservierung wuchsen Speicher und Verarbeitung. Im schnellen Kern trafen besonders viele Flüsse zusammen. Die genaue Zuordnung, die am Rand tragbar war, wurde dort zum Skalierungsproblem.

Differentiated Services fasste Flüsse zusammen. Grenzen klassifizierten und konditionierten; der Kern wandte wenige aggregierte Verhaltensweisen anhand eines Codes an. Das Netz skalierte, weil es einzelne Gespräche nicht im Inneren fortsetzte.

Wenn die Ressource fehlte, konnte die angeforderte Behandlung jedoch ausbleiben, ohne dass die Anwendung einen Fehler erhielt. Sie musste aus ihrer Beobachtung schließen, dass der Dienst nicht geliefert worden war. Schweigen war kein verwertbares Nein.

Zwei fehlende Schnittstellen

RFC 2990 nannte DiffServ grenzzentriert. Die Grenze konnte Richtlinien durchsetzen und Verkehr in Aggregate einlassen; der Kern konnte diese effizient behandeln.

Nicht definiert war, wie aktuelle Ressourcenlage aus dem Inneren die Konditionierer erreichte. Eine Grenze konnte mit einer statischen oder veralteten Annahme zulassen. Ebenso fehlte der Weg, auf dem die Zulassungsentscheidung die Anwendung erreichte.

Die Architektur benötigte deshalb Kern-zu-Grenze-Signalisierung für Kapazität und Grenze-zu-Anwendung-Signalisierung für Annahme oder Scheitern. Eine Kapazitätsmessung war nur Entscheidungsgrundlage. Eine Zulassung war nur ein Beschluss. Die spätere Lieferung blieb ein dritter Sachverhalt.

Der Routingpfad war noch kein Dienstpfad

Beide Architekturen folgten gewöhnlich dem Best-Effort-Pfad. Bei stückweiser Einführung konnte ein alternativer Pfad dienstfähig sein, während der kürzeste es nicht war.

Es gab keinen robusten Mechanismus, mit dem eine Anwendung mehrere Pfade nach einem Profil befragen konnte. Eine Markierung entdeckte keine Route. Eine Reservierung auf dem gewählten Pfad schloss bessere Kandidaten nicht aus.

Als Qualitätsmetrik genügte auch ungenutzte Kapazität nicht. RFC 2990 dachte an das Potenzial, zusätzliche Last mit einer Qualität zu tragen, notfalls durch Verlagerung niedriger priorisierten Verkehrs. Darin steckte bereits eine Verteilungsregel.

Entdeckung, Pfadwahl und Zulassung brauchten eigene Entscheidungen und Belege.

TCP machte den Rückweg messbar

TCP steuert den Versand anhand zurückkehrender Bestätigungen. Werden Daten und ACKs unterschiedlich behandelt, entsteht die Anwendungsleistung aus beiden Richtungen. Jitter kann ACKs verdichten und anschließend einen Datenstoß auslösen, der die Vorwärtskapazität belastet.

Symmetrische Behandlung konnte helfen, warf aber Fragen nach Anforderung und Abrechnung beider Richtungen auf. Ein Zähler der Vorwärtsklasse konnte nicht für das gesamte Ergebnis sprechen.

Lieferung und Rechnung waren getrennt

RFC 2990 unterschied die Messung verfügbarer Ressourcen für die Zulassung von der Messung des gelieferten Dienstes. Der Betreiber brauchte objektive Werte, um Konformität zu belegen. Der Kunde brauchte sie, um einen Mehrpreis durch bessere Anwendungsleistung zu rechtfertigen.

Das Dokument erwartete Aufpreise für Premiumdienste, stellte aber fest, dass weder ein QoS-Abrechnungsmodell noch die Datenerhebung zur Zuordnung an einen Kunden definiert war.

Identität, Berechtigung, Anforderung, Zulassung, Ressourcenzuteilung, beobachtete Lieferung, Nutzungszuordnung, Tarif und Rechnung bildeten eine Kette. Eine korrekte Paketzählung bewies nicht automatisch eine korrekte Leistungsabrechnung.

Die Grenze als Übersetzer

IntServ über DiffServ bot eine Aufgabenteilung. RSVP konnte den Dialog pro Fluss am Rand erhalten. Eine DiffServ-Region erschien im Ende-zu-Ende-Pfad als aggregiertes Element. Die Grenze ordnete das individuelle Profil einem passenden Aggregat zu.

Bei statischer Kapazität konnte sie bekannte Grenzen laden. Bei dynamischer Kapazität benötigte sie ein Signal aus dem Kern. Scheiterte die Zulassung in der Region, musste dies zur Anwendung zurückkehren, damit sie Anforderungen änderte oder abbrach.

Die Übersetzung des Erfolgs war nur die Hälfte. Erst die Übersetzung des Scheiterns verband Präzision mit Skalierung.

Vielfalt mit beobachtbaren Grenzen

RFC 2990 erwartete keine einheitliche Technik für das gesamte Internet. Kleine Inseln, unterschiedliche Mechanismen und Brücken machten Entdeckung, Aufruf und Messung gleich wichtig.

Die Schlussfolgerung bevorzugte Aggregate im Kern und Flusspräzision am Rand, wo sie tragbar blieb. Durch Lu Hengs Linse der minimalen Anfangsspezifikation genügt eine gemeinsame Schicht für Anforderung, Kapazität, Entscheidung und Ergebnis; spätere Ressourcenpolitik bleibt lokal.

Lokalität erlaubt aber kein Schweigen. Markierung, Zulassung, Kapazität, Behandlung, Leistung, Messung, Zuordnung und Rechnung liegen in verschiedenen Realitätsschichten. Laufender Code muss ihre Übergänge belegen.

Das Netz durfte Nein sagen. RFC 2990 zeigte, warum es dieses Nein auch zurücksenden musste.

Quellen