Zusammenfassung

  • draft-ietf-ccwg-ratelimited-increase-11 erlaubt ein begrenztes Wachstum der cwnd, wenn Anwendung oder Empfänger-Flow-Control den Versand bremsen, und bindet die Obergrenze an die größte beobachtete FlightSize.
  • maxFS diszipliniert lokalen Senderzustand. Die Variable reserviert keine Bandbreite, öffnet kein Empfänger-Credit und garantiert weder Pacing noch den Erfolg eines späteren Bursts.

Eine Verbindung darf zwanzig Segmente unbestätigt halten. Die Anwendung liefert nur vier; alle vier werden bestätigt, Verlust ist nicht sichtbar. Das Dashboard zeigt Reserve.

Aber sechzehn Segmente haben den Pfad nie geprüft.

Der am 6. September veröffentlichte CCWG-Entwurf draft-ietf-ccwg-ratelimited-increase-11 soll unterschiedliche Regeln in TCP, QUIC, SCTP, DCCP und CUBIC vereinheitlichen. Manche Spezifikationen stoppen das Fensterwachstum, sobald ein Sender seine cwnd nicht ausschöpft. Andere Verhaltensweisen können einen Wert entstehen lassen, der weit über dem jüngst erprobten Datenvolumen liegt. Der Entwurf erlaubt Wachstum, ohne ungenutzten Raum als Messung auszugeben.

Rate-limited ist hier ein Sender, der weniger überträgt, als die Congestion Control erlauben würde. Vielleicht liefert die Anwendung keine weiteren Bytes. Vielleicht begrenzt der Empfänger den Connection- oder Stream-Credit. Dann bleibt FlightSize—gesendete, noch nicht kumulativ bestätigte Daten—unter cwnd. Beides ist nicht automatisch ein Stauhinweis.

Als Gedächtnis dient maxFS, die größte FlightSize seit der letzten cwnd-Reduktion. Eine größere Messung hebt den Wert an; jede Reduktion setzt ihn zurück. Ein späterer Anstieg muss unter limit(maxFS) bleiben: dem Wert, den der jeweilige Algorithmus nach ACKs für ein erfolgreich übertragenes Fenster dieser Größe ergeben würde. Im Slow-Start-Beispiel liegt die Grenze bei 2*maxFS, in Congestion Avoidance bei maxFS+SMSS.

Damit wird nicht genutzte Kapazität nicht angespart. Wer im vorigen RTT ein Fenster vollständig genutzt hat, darf den normalen nächsten Wachstumsschritt mitnehmen. Bleibt der Versand dagegen über mehrere RTTs wegen Anwendung oder Empfänger kleiner, kann das Fenster nicht so weiterwachsen, als wäre der gesamte Spielraum getestet worden.

Auch gute Historie altert. Der Entwurf warnt ausdrücklich, dass maxFS lange bestehen und die Realität des Ende-zu-Ende-Pfads verfehlen kann. RFC 7661 ergänzt deshalb Congestion Window Validation. Dort beschreibt pipeACK das innerhalb eines Messintervalls bestätigte Volumen und trennt frisch validierten Zustand von einer Fenstergröße, die auf früherer Kapazität beruht. FlightSize ist eine Momentaufnahme, pipeACK eine zeitlich begrenzte Beobachtung. Keiner der Werte ist ein Anspruch auf morgen.

Drei Steuerungen dürfen nicht verschmelzen. Die Anwendung stellt Daten bereit. Der Empfänger vergibt Credit. Die Congestion Control begrenzt die Einspeisung anhand von Netzsignalen. Eine hohe cwnd erzeugt keine Nachfrage, überstimmt keinen Back-pressure und hält weder Route noch Queue, Policer oder konkurrierende Flows konstant.

Pacing bleibt ebenfalls ein eigener Nachweis. Ein Stack kann mehr Daten im Flug halten dürfen und Pakete trotzdem zeitlich verteilen. Der Entwurf verhindert das nicht, bestätigt aber auch nicht, dass eine konkrete Implementierung Pacing aktiviert, ein sicheres Intervall gewählt oder Burst-Bildung durch Offload vermieden hat.

Ein ACK berichtet schließlich über frühere Daten nach den Regeln eines Transportprotokolls. Es aktualisiert Verlustbehandlung und Congestion State. Es verspricht keinen künftigen Credit, keine unveränderte Route und keine Annahme durch die Anwendung. Authentisierung kann die Quelle absichern, nicht die Zukunft.

Bei Annahme würde der Entwurf die RFCs 4341, 5681, 9002, 9260 und 9438 ändern. Noch ist er ein veränderliches Internet-Draft ohne IANA-Anforderung. Standardstatus, Code-Unterstützung, Aktivierung und Produktionswirkung brauchen getrennte Belege.

Quellen