Liebe Liste,

ich habe ein technisches Problem, welches sich die Netztechnik von O2/Telefonica einmal ansehen sollte. Leider habe ich keinen direkten Kontakt und hoffe deshalb darauf, dass eine/einer unserer kompetenten und netten Moderatoren hier das ganze weiterleiten kann.

Das Problem ist recht technisch (aber fuer die Netztechnik sicherlich offensichtlich sobald die darauf schauen) ich werde aber trotzdem versuchen hier eine Beschreibung zu geben welche (hoffentlich) trotzdem nicht ganz unverstaendlich ist.

Im Internet verwenden wir fast ausschiesslich Datenpakete welche eines der beiden aktiven Internet-Protokolle verwenden, Version 4 (IPv4) und Version 6 (IPv6).
Beide Protokollversionen enthalten jeweils ein 8bit Feld (urspruenglich Type of Service fuer IPv4 und Traffic Class fuer IPv6) welches prinzipiell vom "Netzwerk" also von allen Nodes zwischen den Endpunkten veraendert werden darf, allerdings nur innerhalb der von der IETF in verschiedenen RFCs dokumentierten Regeln.
Aktuell ist dieses urspruengliche 8bit Feld in zwei kleinere Felder zerlegt worden, das 6bit Differentiated Services (DS) Feld und das 2bit Explicit Congestion Notification (ECN) Feld.
Das DS Feld dient dazu einen DIfferentiated Services Code Point (DSCP) aufzunehmen der z.B. dazu dienen kann Pakete mit unterschiedlicher Prioritaet zu behandeln. So verwenden manche ISP dieses Feld um z.B. VoIP Pakete auch unter Volllast zuegig weiterzuleiten, so dass Telephonate auch zur Primetime glatt durchgehen und nicht "ruckeln" oder Drop-outs haben. ISPs haben sehr grosse Freiheiten welche Werte sie in dieses Feld schreiben duerfen.
Beim ECN Feld sieht das anders aus, hier gibt es deutlich strikteren Vorgaben zur Nutzung, siehe z.B.:
RFC 3168: https://datatracker.ietf.org/doc/html/rfc3168
Kurz: normalerweise kann ein Netzwerkelement das mehr Pakete empfaengt als es weiterleiten kann (und dessen Warteschlange daher kontinuierlich anwachsen wuerde) irgendwann nur noch Pakete einfach "fallen lassen" (droppen) und die Endpunkte einer Verbindung die solche degroppten/verlorene Pakete detektieren muessen als Antwort darauf ihre effektive Senderate reduzieren (und wenn genug der Verbindungen ihre Senderate reduzieren kommt es am ueberlasteten Netzwerkelement dazu, dass die Empfangsrate unter die Senderate faellt und die aufgebaute Warteschlange wird abgebaut). Das verhindert den Congestion Collapse, bei dem die nutzbare Kapazitaet des Netzwerks dauerhaft massiv schrumpft.
Als optimierung dieses Prozesses hat rfc3168 vorgeschlagen, nicht erst zu warten bis ein Netzwerkelement keinen Platz in seiner Warteschlange mehr hat, sondern schon vorher (wenn die Wrteschlange gefuellt aber noch nicht ueberfuellt ist) die Signal zu senden, dass Verbindungen ihre Senderate senken sollen. Aber statt ein Paket zu droppen ist die Idee hier der entsprechenden Verbindung ein deutliches unzweifelhaftes Signal zu schicken "bitte auf die Bremse" zu treten. Da jedoch die existierenden Netzwerkelemente nicht (alle) darauf vorbereitet waren hat man eine spezielle Signalisierungsmethode geschaffen, mit der individuelle Pakete dem Netzwerk gegenueber signalisieren "ich verstehe Bremssignale" und Netzwerkelement koennen dann solche Packte mit einem Bremssignal versehen statt sie droppen zu muessen. Fuer das Netzwerk hat das den Vorteil, dass das Bitte-Bremsen-Signal schneller ankommt (gedroppte Pakete werden dadurch detektiert, dass mehrere Pakete mit hoeherer Sequenznummer ankommen waehrend eine niedrigere Nummer fehlt*) und danit die Ueberlast-Situation hoffentlich schneller vorbei ist. Fuer die Verbindung hat es den Vorteil, dass kein Datenpacket verloren gegangen ist und zeitauffendig erneut uebertragen werden muss.

Dabei wird das ECN Feld fuer die Signaliserung verwendet, die moeglichen 4 Werte haben folgende Bedeutung:
         0     0         Not-ECT
         0     1         ECT(1)
         1     0         ECT(0)
         1     1         CE

Not-ECT ist der Standardwert und bedeutet, "ich verwende kein ECN", Pakte mit diesem ECN-Wert muessen bei Ueberlast zwingend gedroppt werden.
ECT(0) und ECT(1) bedeuteten urspruenglich beide, "ich verwende ECN", Pakte mit diesem ECN-Wert duerfen bei Ueberlast gedroppt werden koennen aber auch statt dessen CE markiert werden.
CE bedeutet, dieses Paket waere (wegen Ueberlast) gedroppt worden, und die Verbindung muss auf die Bremse treten.
Bei TCP mit aktiviertem ECN-Modus reagiert ein Empfaenfer auf eine CE Marken damit, dass er im TCP Header das ECE bit setzt (ECE: echo CE) und zwar solange bis der Sender den Empfang dieses Bits mit einem gesetzten CWR bit beantwortet (CWR: congestion window reduced, effektiv heisst dass die Senderate wurde reduziert).

Die Konsequenz ist, dass die ECT(0)/ECT(1) ECN-Werte nur verwendet werden duerfen, wenn eine Verbindung tatsaechlich ECN nutzt.

Mit RFC 8311 (https://www.rfc-editor.org/rfc/rfc8311.html) wuerde vor kurzem die Bedeutung von ECT(1) etwas geaendert, so dass normalerweise fuer rfc3168-ECN nur noch ECT(0) verwendet werden soll/darf.

Hier nun das Problem, in meinem Heimnetzwerk empfange ich regelmaessig Pakete die ECT(1)-markiert sind, obwohl die Sender der Verbindung dies nicht ausgehanelt haben:

Hier ein tcpdump Beispiel von meinem Router (der Filter sogt dafuer dass nur solche IPv4 und IPv6 Pakete angezeigt werden, die das ECT1) bit gesetzt haben):

user@router:~# tcpdump -i pppoe-wan -vv -n '(ip6 and (ip6#0:2] & 0x30) >> 4  == 1)' or '(ip and (ipm1] & 0x3) == 1)' # ECT(1)
tcpdump: listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
11:55:42.431111 IP (tos 0x1,ECT(1), ttl 117, id 21587, offset 0, flags 1df], proto ICMP (1), length 56)
    91.215.100.74 > 77.8.26.194: ICMP 91.215.100.74 udp port 443 unreachable, length 36
    IP (tos 0x0, ttl 53, id 0, offset 0, flags �df], proto UDP (17), length 1228)
    77.8.26.194.53406 > 91.215.100.74.443: UDP, length 1200
12:18:15.332012 IP (tos 0x1,ECT(1), ttl 47, id 28306, offset 0, flags df], proto TCP (6), length 1492)
    162.125.21.3.443 > 77.8.26.194.60123: Flags >.], cksum 0x58c5 (correct), seq 2569767887:2569769327, ack 1964796999, win 130, options 6nop,nop,TS val 1410367303 ecr 266148624], length 1440
12:18:15.332349 IP (tos 0x1,ECT(1), ttl 47, id 28307, offset 0, flags Idf], proto TCP (6), length 1492)
    162.125.21.3.443 > 77.8.26.194.60123: Flags P.], cksum 0x2174 (correct), seq 1440:2880, ack 1, win 130, options xnop,nop,TS val 1410367303 ecr 266148624], length 1440
12:18:15.332662 IP (tos 0x1,ECT(1), ttl 47, id 28308, offset 0, flags 2df], proto TCP (6), length 799)

 
Hier handelt es sich um Dropbox-Verbindungen, aber ich sehe das auch bei z.B. Apple. Ich sehe das jedoch nur in meinem Heimnetzwerk, wenn ich von einem anderen Netzwerk mit dem selben Endgeraet teste tauchen keine ECT(1) markierten Pakete auf.

Fuer mich deutet das darauf hin, dass hier irgendein O2/Telefonike Netzwerkelement seine Haende im Spiel hat. Mein Verdacht ist, dass das DSCP Feld veraendert werden sollte (also voll innerhalb der IETF-Regeln), dass aber statt des 6bit DSCP Feld der Wert in das 8bit TOS/TC Feld geschrieben wird. Aber egal aus welchem Grund die beobachtete Veraenderung des ECN Feldes ist falsch und sollte bitte korrigiert werden.

Das Ganze wird besonders relevant weil die IETF vor kurzem mit L4S** (https://datatracker.ietf.org/doc/rfc9330/) einen neuen Nutzer fuer ECT(1) ECN ratifiziert hat der sensibel gegenueber falsch-markierten ECT(1) Paketen ist.

So, dass was vielleicht ein bisschen viel (und trotzdem noch grob simplifiziert, im Detail ist also nicht alles ganz richtig in der Beschreibung). Ich bin gerne bereit mit weiteren Daten/Packetcaptures auszuhelfen, wenn das notwendig sein sollte, einfach per PN Bescheid geben...

*) Das kann jetzt daran liegen dass das Paket gedroppt wurde oder aber dass nur die Reihenfolge der Pakete durcheinander geraten ist. Ist also nicht ganz eindeutiges Signal welches einige Zeit dauert.

**) Ich bin nicht ueberzeugt, dass dieser Ansatz tatsaechlich bereits Internet-tauglich ist, aber so oder so nicht-RFC-konforme ECT(1)-Pakete werden nicht hilfreich sein.