[fli4l] SIP - dynamische Umschaltung von udp auf tcp

[Christoph Schulz]

Hallo!

Erwin Lottermann schrieb:

>> Allein dies ist schon nicht RFC-konform.
> 
> Du meinst also, dass es sich die Draytek-Entwickler zu einfach machen,
> wenn sie UDP-Pakete mit Fragmentierungskennung prinzipiell verwerfen.

Exakt.

>> Ein UDPv4-Datagramm kann bis zu 65535 - 20 - 8 = 65507 Byte
>> Nutzdaten haben.
>> Das würde bedeuten, dass der Draytek-Router standardmäßig nicht
>> einmal ein
>> Vierzigstel der RFC-konformen Größe durchlässt.
>> 
> 
> Gibt es tatsächlich Applikationen, die von der prinzipiell vorgesehenen
> UDP-Datagrammgröße Gebrauch machen?

Gibt es einen Beweis, dass es sie nicht gibt?

Analogie: Wenn die Post Großbriefe bis 500 g erlaubt, dann darf sie nicht 
die Großbriefe mit >= 450 g einfach wegwerfen mit der Begründung, die wären 
so selten, dass ein solcher Brief quasi eine Briefbombe enthalten muss und 
somit eine Gefahr für die Post und die Allgemeinheit darstellt.

> Zumindet im SIP RFC3261 gibt es eine klare Ansage, dass SIP auf
> Applikationsebene dafür zu sorgen hat, dass UDP-Datagramme nicht
> fragmentieren.

Du meinst:

"If a request is within 200 bytes of the path MTU, or if it is larger
 than 1300 bytes and the path MTU is unknown, the request MUST be sent
 using an RFC 2914 [43] congestion controlled transport protocol, such
 as TCP."

Nun, hier verstößt die Telekom (oder wer auch immer) klar gegen das RFC, 
denn nach deinen Ausführungen wird nicht auf TCP umgeschaltet. Das ist aber 
kein Verbot von Fragmentierung, denn schließlich kann im Falle einer 
unbekannten MTU diese auch wesentlich kleiner sein als 1300 Bytes. Es soll 
nur Fragmentierung vermeiden:

"This prevents fragmentation of messages over UDP [...]"

Weiter unten wird auch ausgeführt, warum 1300 Byte als Richtwert genommen 
wurden ("1300 is chosen when path MTU is not known, based on the assumption 
of a 1500 byte Ethernet MTU."). Also alles nur Hilfen und Heuristiken, aber 
Fragmentierung wird dadurch nicht verboten, nur unwahrscheinlicher.

Es steht weiter der Satz drin:

"However,
 implementations MUST be able to handle messages up to the maximum
 datagram packet size.  For UDP, this size is 65,535 bytes, including
 IP and UDP headers."

Das heißt also: Fragmentierung ist zu vermeiden, aber sie kann auftreten, 
und dann *muss* es auch funktionieren. Und genau das passiert eben nicht, 
wenn eine Middlebox Fragmente verwirft.

> Im Zusammenhang mit Routern, die fragmentierten UDP-Traffic aus Prinzip
> blocken, ist an einigen Stellen von "braindead routers" die Rede. Das
> scheint ja dann so ähnlich gemeint zu sein.

Ja. Einfaches Wegwerfen von Paketen ist z.B. in Ordnung, wenn es um 
Überlaststeuerung (congestion control) von Paketströmen (z.B. bei TCP) geht, 
wenn man davon ausgehen kann, dass das Paket später nochmal verschickt 
werden wird, wenn die Leitung nicht mehr "zu" ist. Wegwerfen von Paketen, 
nur weil ein Bit gesetzt ist, das nur selten verwendet wird, ist fahrlässig 
und/oder paranoid. Schließlich kann es Anwendungen geben, die genau dieses 
Bit benötigen. Und es ist egal, ob es Fragmente bei IP, Urgent Data bei TCP 
oder Funktion X bei Protokoll Y ist -- solange die RFCs eine solche 
Verwendung erlauben, sollte sich ein Router dem nicht widersetzen (natürlich 
nur, wenn er vom Benutzer nicht explizit angewiesen wurde, genau dies zu 
tun).

Ich wüsste in dem Zusammenhang auch gerne, wie man auf maximal 1628 Byte 
kommt -- Ethernet-MTU (1500) + 128?


Viele Grüße,
-- 
Christoph Schulz
[fli4l-Team]