Seltsame Paketlaufzeiten für Pakete <700 Bytes

[RFZ]

Hallo zusammen,
das ist jetzt vielleicht ein etwas ungewöhnlicheres Thema, aber ich habe durch Zufall seltsame Paketlaufzeiten bei meinem Anschluss von KD gemessen und würde mir diese gerne erklären...

Folgendes Testszenario: Von meinem Anschluss aus (32MBit/s down, 2MBit/s up) werden zwei UDP Pakete direkt hintereinander an einen Server gesendet.
Sind die Pakete je 200 Bytes lang, dauert die Übertragung je Paket rein rechnerisch etwa 800µs. Die Pakete müssten also mit 800µs Versatz beim Server eintreffen (jeweils das erste oder letzte Bit je Paket gemessen).
Diese Berechnung lässt sich natürlich für jede Paketlänge durchführen.
Festgestellt habe ich aber, dass Pakete < 702 Bytes immer mit einem Abstand von etwa 160µs ankommen, also viel schneller als dies rein rechnerisch machbar ist. Bei Paketen > 701 Bytes geht die Rechnung dann schlagartig auf.
Die einzige Erklärung die ich dafür habe ist, dass KD das erste Paket zwischenspeichert (und analysiert), das zweite aber nicht, wodurch die Pakete wieder näher aneinander rücken. Wieso aber die Grenze bei 701 Bytes?

Aus der Paketlänge und der Zeitdifferenz am Server lässt sich eine Datenrate errechnen, welche (angenommen die Pakete würden auf der Strecke gleich behandelt) der Datenrate des langsamsten Links der Verbindung entspricht (in der Regel mein 2MBit/s Upload).

Durch das Verhalten im Netz von KD ergibt sich dadurch diese Grafik:

http://yfrog.com/5ibitrateoverpayloadp

Hat jemand von Euch eine Erklärung für dieses Phänomen?

P.S. Falls ihr euch fragt, wie man da "zufällig" drüber stolpern kann... Ich wollte ein Verfahren (eben das oben erklärte) zur Messung der Datenrate des langsamsten Links implementieren und war über die Ergebnisse > 20MBit/s sehr verwundert

[RcRaCk2k]

in der Regel mein 2MBit/s Upload

Du hast also deinen Uplink mit 20MBits getestet?

Ich kann mir vorstellen, dass Kabel-Deutschland Pakete <= 700 Bytes ohne Traffic-Shaping (QoS) durch's Netz jagt. Schließlich sind 700 Bytes ja nichts. Zudem würde dies auch klarstellen, warum VoIP noch geht, auch wenn das Internet am Ende seiner Kapazität ist.

Ein alaw-Stream der FritzBox (3 Samples von G.711a @8000kBit) hat ungefähr 240 Bytes. Damit das Telefon richtig funktioniert könnte K.D. eingebaut haben, dass Pakete unterhalb 700 Bytes Proto UDP ohne Beschränkung durchgelassen werden.

Das wäre echt interessant Werde mal mein VPN auf 700 Bytes MTU herunterschrauben, und kucken ob ich dann einen höheren Upstream / Downstream erreichen kann Jetzt wo du's schreibst, könnte das echt Sinn ergeben *gg*

Grüße,
Michael.

[RFZ]

Hehe, das wäre ja was

Passt aber nicht ganz zur Theorie... Dann hätte meine Messung bei Paketen <702 Bytes einfach eine hohe Bandbreite ergeben und bei größeren hald wie jetzt auch etwa 2 MBit/s. Statt dessen steigt die Rate aber linear - bzw. der Paketabstand bleibt gleich, das wäre dadurch nicht wirklich erklärbar.

Wenn ich im übrigen drei Pakete sende und die letzten beiden zur Messung verwende, habe ich auch keine so deutlichen Ausschläge mehr. Es wird also wirklich nur das erste Paket verzögert. Darauffolgende werden "normal" behandelt.

"Weitere Pakete" definieren sich im übrigen nicht durch den Socket, sondern durch einen Timeout, wie ich festgestellt habe. Es ist nämlich egal, ob viele aufeinanderfolgende Pakete vom selben Port aus, oder von unterschiedlichen Ports kommen. Verzögert wird es immer dann, wenn vorher eine gewissen zeit (irgendwas <50ms) keines gesendet wurde.
Zielport ist wohl auch egal, war in meinen Fällen einmal 2000 ein anderes mal 6666.

Verwendet KD vielleicht Netzseitig irgendein Transportprotokoll, welches soeinen Effekt haben könnte? Weil z.B. Pakete je nach Größe in größeren Frames zusammengefasst werden?

Ich kann mir da einerseits sehr viel ausmalen, andererseits aber nichts wirklich brauchbares

[RcRaCk2k]

Ich kann mir da einerseits sehr viel ausmalen, andererseits aber nichts wirklich brauchbares

Ja, das ist wirklich eine verzwickte Sache.. Könnte schon sein, dass innerhalb des eigenen Netzwerkes ein "komisches" bisher uns noch nicht bekanntes Protokoll zum Einsatz kommt. Größere Pakete pro Timeslot zu verschicken macht natürlich Sinn, vielleicht macht sich das K.D. zu Nutze, füllt zuerst einen Buffer und sendet dann größere Junks durchs Netzwerk.... who knows.

Wenn jedes nachfolgende Paket normal behandelt wird, dann wird das mit meinem VPN wahrscheinlich nicht funktionieren *gg*

Vielleicht ist auch soetwas wie "Burst" aktiviert, dass man ein gewisses Volumen in einem Junk schneller übertragen kann, z.B. um SYN und ACK schneller abwickeln zu können. Keine Ahnung Oder es liegt, wie du sagst, einfach an der Paketübertragungs-Technik.

Grüße,
Michael.