Die Idee mit net.inet.tcp.ecn_negotiate_in und net.inet.tcp.ecn_negotiate_out war, dass damit generell - sozusagen für jedwede Verbindung - unterbunden wird, dass sich Client und Host auf die Anwendung von ECN einigen. Wenn ich es recht verstanden habe, dann soll ECN ignoriert werden, falls nicht beide Endgeräte die Unterstützung signalisieren.
Das ist ja auch sicherlich mit den Variablen möglich ... aber IP-ECN ist eben nicht TCP-ECN, TCP gibt es bei IPSec (in den "äußeren Paketen") nicht und die inneren Pakete darf UM ja gar nicht "anfassen" (das ist nur "scrambled content" für den Carrier).
Ich habe in der Zwischenzeit noch mal in dem IPSec-ECN-Draft versucht herauszufinden, was genau Apple sich daraus nun eigentlich zu eigen gemacht hat ... aber das ist ein uralter Vorschlag, der über den "Entwurf" offenbar niemals hinausgekommen ist und eigentlich seit Juni 2000 "verfallen" ist.
Dort werden verschiedene Szenarien beschrieben (u.a. auch das Verhalten von UM, ständig "CE" zu signalisieren) und die daraus abzuleitenden Konsequenzen. Wenn Apple das so wie dort beschrieben implementiert haben sollte (Abschnitt 4), dürfte sich das Problem eigentlich gar nicht stellen ... also hat Apple da wohl irgendetwas zusammenprogrammiert, was ein abweichendes Verhalten (auch ggü. anderen Betriebssystemen, ja selbst ggü. FreeBSD/OpenBSD, wenn ich es richtig verstanden habe, was sich im Netz dazu so findet) aufweist.
Auch kann man von außen nicht sehen, ob Apple nun die SAD-Erweiterung für "ECN tunnel" implementiert hat (die wäre dann Teil der anzubietenden Proposals und ist bei AVM vielleicht gar nicht implementiert - ist halt "closed source", leider - und damit per Definition nicht zu verwenden bei Verbindungen mit Gegenstellen, die diese Option nicht kennen) und/oder es auch daran scheitert, daß sich die Peers nicht einigen können.
Wobei das dann eigentlich dazu führen müßte, daß für P2 ein entsprechender Fehler signalisiert wird ... dieses zusätzliche Attribut dient ja eigentlich auch nur dazu, auf der "nicht IPSec"-Strecke einer solchen Verbindung (also links und rechts vom jeweiligen IPSec-Gateway) den ECN-Mechanismus verwenden zu können.
Aber das alte Dokument ist eben nur ein "draft" ... weiß irgendjemand, wie andere das umgesetzt haben? Für FreeBSD kann man ja anhand der Dokumentation einen Verdacht haben ... auch wenn ich - anders als in #159 angeführt - den "non-zero"-Wert eher dafür stehen sehe, daß da ein Kopieren der äußeren ECN-Bits in die inneren Pakete stattfinden soll (was hier ja eigentlich unerwümscht ist, daher ist "0" m.E. tatsächlich der richtige Wert).
Der Draft stellt für das Verhalten von UM jedenfalls folgendes fest (Abschnitt 4.2):
However, this could result in the application unnecessarily invoking end-to-end congestion control, and reducing its arrival rate. By itself, this is no worse (for the application or for the network) than if the tampering router had actually dropped the packet.
Nachdem es bei der äußeren Verbindung (ist eben UDP) erst einmal gar keinen Mechanismus für "end-to-end congestion control" gibt, kann es (ist aber Spekulation, die zu prüfen wäre) ja eigentlich nur noch daran liegen, daß Apple da das ECN-CE aus dem äußeren Paket in ein entschlüsseltes inneres Paket kopiert ... aber selbst das sollte nicht zu einer Reduktion des Traffics in einer (gekapselten) TCP-Verbindung auf Null führen (nur die hat per se die erforderliche "end-to-end congestion control", wenn man mal von anderen ungebräuchlicheren Protokollen wie RTP absieht), wenn nicht irgendjemand diese Pakete mit "congestion encountered" dann doch als "dropped" betrachtet und/oder behandelt.
Interessant wäre halt (kriegt man aber nur mit einem Packetdump heraus, der sowohl die äußeren als auch die inneren Pakete enthält), welche Bitkombinationen Apple da wann von den äußeren Headern in die inneren kopiert (das geht ja erst nach der ganzen Validierung der IPSec-Kapselung) bzw. ob die Pakete mit ECN-CE überhaupt dechiffriert werden und das Resultat dann weiterverarbeitet wird.
