amatör
Mitglied
- Mitglied seit
- 15 Feb 2014
- Beiträge
- 408
- Punkte für Reaktionen
- 10
- Punkte
- 18
Das war so gemeint: Laut https://en.m.wikipedia.org/wiki/Explicit_Congestion_Notification (und anderen Quellen, die ich gelesen aber jetzt nicht zur Hand habe) wird eine Verbindung nur dann ECN verwenden, wenn sich beide Enden dazu fähig erklären.
"Use of ECN on a TCP connection is optional; for ECN to be used, it must be negotiated at connection establishment by including suitable options in the SYN and SYN-ACK segments."
Sehr schön auch in http://ecn.ethz.ch/ecn-pam15.pdf zusammengefasst:
"a client sends an initial syn ece cwr to the server to negotiate ECN; to confirm negotiation, the server responds syn ack ece, or to deny, simply syn ack. Section 6.1.1.1 of RFC 3168 [1] recommends falling back to non-ECN support if the initial syn ack ece connection attempt fails."
Heißt also, dass kein ECN verwendet wird, wenn nicht beide beteiligten Endstellen dem zustimmen. Damit wäre es theoretisch möglich, dass der VPN-Server der Fritzbox optional die ECN-Fähigkeit bestreitet (also SYN ACK statt SYN ACK ECE antwortet). Die Verbindung müsste von da an also so funktionieren wie in iOS 8 bzw. OS X 10.10 und früher. Da UM vermutlich schon länger ECN auf x03 setzt, es aber bisher trotzdem funktioniert hat, müsste es eigentlich dann auch wieder funktionieren. Auf diese Weise könnte AVM einen Work-around bieten, indem die am UM-Anschluss hängende Fritzbox die ECN-Verbindung verweigert.
Das setzt allerdings voraus, dass der oben beschriebene Fallback to non-ECN support von Apple korrekt implementiert worden ist. In diesem Fall müsste ECN x03 ja wie bisher einfach ignoriert (oder genullt) werden. Das ist mit meinem Zusatz in Klammern "(Es sei denn, die Apple-Implementierung wäre auch in dieser Hinsicht fehlerhaft.)" gemeint gewesen.
In RFC 3168 ist sogar beschrieben wie ein Host reagieren kann, der nach ECN-Aushandlung keine Antwort mehr bekommt, nämlich indem er erneut sendet ohne ECN-Signalisierung (wenn ich das recht verstanden habe):
"A host that receives no reply to an ECN-setup SYN within the normal
SYN retransmission timeout interval MAY resend the SYN and any
subsequent SYN retransmissions with CWR and ECE cleared. To overcome
normal packet loss that results in the original SYN being lost, the
originating host may retransmit one or more ECN-setup SYN packets
before giving up and retransmitting the SYN with the CWR and ECE bits
cleared."
Was ich aber nicht verstehe, ist folgender Abschnitt über fälschlich signalisierte Congestion:
18.1.2. Falsely Reporting Congestion
This change is to set the CE codepoint when an ECT codepoint was
already set, even though there was no congestion. This change does
not affect the treatment of that packet along the rest of the path.
In particular, a router does not examine the CE codepoint in deciding
whether to drop or mark an arriving packet.
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.
"This is no worse [...] than if the [...] router had actually dripped the packet" bedeutet doch aber, dass die ECN-Signalisierung in jedem Paket wie ein Packetloss jedes Pakets behandelt wird?! In dem Falle würde es Apple vielleicht sogar nicht einmal falsch machen, denn die Symptome entsprechen ja genau dem. Warum aber wird das im RFC als nicht besonders schlimm angesehen? Wird hier nur der Fall einzelner fälschlich gesetzten ECN-Bits betrachtet?
Zuletzt bearbeitet:
