Limitiert Kabel Deutschland FTP und HTTPS Traffic?

[robert_s]

Speedtest.net mit EINER Verbindung
[ externes Bild ]
[...]
Man kann also erkennen, dass einzelne TCP-Streams bei 80 MBit/s gedrosselt werden.
Sobald man Multiple Streams startet, dann wandert der Speed nach oben, aber nicht n*80 MBit/s (linear) sondern algorithmisch.

Hatte heute morgen nur für einen Test Zeit:

Speedtest.net mit EINER Verbindung
https://www.speedtest.net/result/8758370606
[ externes Bild ]

Auf Anhieb 600/37Mbit/s, mit einzelnen TCP-Streams.

[RcRaCk2k]

@robert_s danke für deinen Test. Dann scheinst du eine sehr gute Anbindung in die Übergangsnetze zu haben und auch dein Backhauling funktioniert gut.

@reneromann was bist du denn für Einer?

1) TCP ACK Pakete gehen mit einer Geschwindigkeit, wo der Upstream keinerlei Bedeutung beigemessen werden kann. Der RTT zeigt dir bei 21ms ganz genau, dass die Pakete in einer geschätzten Zeit mit einer Verzögerung von 10ms Up / 10ms Down an der jeweiligen Gegenstelle eintreffen. Je nach asymmetrischem Routing kann UP/DOWN variieren.

2) TCP-Window zu klein eingestellt. Weißt du überhaupt, wovon du redest? Mit diesem Argument kannst du kommen, wenn irgendjemand im Jahr 2005 stehen geblieben ist. Jeglicher Rechner mit Windows 7 oder Windows 10 hat die automatische Anpassung des TCP-Window-Sizes implementiert. Je nach Latenz zwischen beiden Endstellen ist der Receive-Buffer in der Lage bis zu 16 MByte zu verwalten. Das sollte ausreichend genug sein, um 1 GBit/s "Aknowledgen" zu können.



Fakt ist: Dass das Backhauling im Vodafone bzw. Kabel-Deutschland-Netz (welches ja noch nicht vollständig in AS3209 integriert wurde) Probleme hat. In meinem Trace habe ich von jetzt auf gleich von 100 MBit/s nur noch 4,8 MBit/s. Diese Änderung der Geschwindigkeit ging mit einem Route-Change einher.

[Flole]

Ich konnte es nicht lassen mal genau den selben Test mit wget laufen zu lassen (von einem Vodafone Kabel Anschluss):

Code: Alles auswählen

#wget -O /dev/null -4 --report-speed=bits http://download.rsm-connect.net/1gb.iso
--2019-11-13 17:53:18--  http://download.rsm-connect.net/1gb.iso
Auflösen des Hostnamens download.rsm-connect.net (download.rsm-connect.net) … 185.58.31.10
Verbindungsaufbau zu download.rsm-connect.net (download.rsm-connect.net)|185.58.31.10|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 1162083328 (1,1G) [application/octet-stream]
Wird in »/dev/null« gespeichert.

/dev/null                                            100%[=====================================================================================================================>]   1,08G   824Mb/s    in 13s

2019-11-13 17:53:30 (737 Mb/s) - »/dev/null« gespeichert [1162083328/1162083328]
#

Hätte ich da jetzt nicht das Problem sehen sollen? Ist jetzt nicht grad mega super schnell (da gehen ja noch fast 400Mbit/s mehr) aber beschweren würde ich mich darüber nun auch nicht.....

Vielleicht gibt gibt es ja noch so einen Fall wie den von mir weiter oben schon beschriebenen:

Wie ich letztens erfahren durfte gibt es sogar bei einzelnen IP Blöcken Unterschiede, es gibt ein PNI zwischen VF und Hetzner allerdings werden dort einige IP Bereiche (ich weiß von über 2800 IPs) nicht übergeben sondern die müssen dann über den De-CIX wandern, dadurch gab es auf der Strecke Paketverluste. Woran das genau liegt konnte nicht geklärt werden, da sind aus dem /17 Netz aus irgendeinem Grund mitten drin einfach mal 2800 IPs vom Peering ausgeschlossen worden.

Dann müsste man nun die problematischen IPs ermitteln und schauen ob die am PNI mit übergeben werden oder ob die hier auch einen anderen Weg nehmen müssen.

[Meister Voda]

Bei mir sieht das an einem VFKD 1 GBit/s Anschluss auch alles ganz schick aus:

Code: Alles auswählen

$wget -O /dev/null -4 --report-speed=bits http://download.rsm-connect.net/1gb.iso
--2019-11-13 19:49:39--  http://download.rsm-connect.net/1gb.iso
Auflösen des Hostnamens download.rsm-connect.net (download.rsm-connect.net)… 185.58.31.10
Verbindungsaufbau zu download.rsm-connect.net (download.rsm-connect.net)|185.58.31.10|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 1162083328 (1,1G) [application/octet-stream]
Wird in »/dev/null« gespeichert.

/dev/null                               100%[=============================================================================>]   1,08G   864Mb/s    in 11s     

2019-11-13 19:49:50 (850 Mb/s) - »/dev/null« gespeichert [1162083328/1162083328]

… wird allerdings über Düsseldorf nach Salzburg geroutet:

Code: Alles auswählen

$traceroute download.rsm-connect.net
traceroute to download.rsm-connect.net (185.58.31.10), 30 hops max, 60 byte packets
 1  *** (10.XXX.XXX.XXX)  1.047 ms  0.967 ms  5.958 ms
 2  ipXXX.dynamic.kabel-deutschland.de (77.21.XXX.XXX)  15.099 ms  18.456 ms  18.531 ms
 3  ip53a99f1e.static.kabel-deutschland.de (83.169.159.30)  27.552 ms  27.583 ms  27.432 ms
 4  ip5886c2f5.static.kabel-deutschland.de (88.134.194.245)  22.637 ms  24.766 ms  24.412 ms
 5  145.254.3.58 (145.254.3.58)  24.466 ms  24.385 ms  22.323 ms
 6  145.254.2.183 (145.254.2.183)  26.954 ms  21.075 ms  21.856 ms
 7  145.254.2.183 (145.254.2.183)  20.809 ms  17.514 ms  14.395 ms
 8  ae3-1.dus10.core-backbone.com (194.146.118.151)  24.998 ms  21.562 ms  24.744 ms
 9  ae4-2057.slz10.core-backbone.com (81.95.2.38)  33.408 ms  33.364 ms  33.290 ms
10  at-sbg-itz-tz-k10-r10-bgp02-et6-v101.rsm-connect.net (5.56.17.162)  33.281 ms  33.187 ms  33.137 ms
11  monitoring.rsm-connect.net (185.58.31.10)  29.830 ms  32.926 ms  30.620 ms

[reneromann]

1) TCP ACK Pakete gehen mit einer Geschwindigkeit, wo der Upstream keinerlei Bedeutung beigemessen werden kann. Der RTT zeigt dir bei 21ms ganz genau, dass die Pakete in einer geschätzten Zeit mit einer Verzögerung von 10ms Up / 10ms Down an der jeweiligen Gegenstelle eintreffen. Je nach asymmetrischem Routing kann UP/DOWN variieren.

Das ist gerade bei den 1 GBit/s-Verbindungen mit nur 50 MBit/s Upload eine gewagte These.
Bedenke, dass alleine die ACK-Pakete bei den 50 MBit/s im Upload schon Einiges an Traffic verursachen...
Weiterhin kann eine gute Auslastung des Upstream im Segment (sind bei 4x QAM64 halt "nur" knapp 144 MBit/s für ALLE Kunden) dir genau wie auch eine hohe Auslastung im Downstream (wären bei der derzeit maximal gefahrenen Konstellation knapp 2,8 GBit/s) ziemlich schnell in die Suppe spucken.

2) TCP-Window zu klein eingestellt. Weißt du überhaupt, wovon du redest? Mit diesem Argument kannst du kommen, wenn irgendjemand im Jahr 2005 stehen geblieben ist. Jeglicher Rechner mit Windows 7 oder Windows 10 hat die automatische Anpassung des TCP-Window-Sizes implementiert. Je nach Latenz zwischen beiden Endstellen ist der Receive-Buffer in der Lage bis zu 16 MByte zu verwalten. Das sollte ausreichend genug sein, um 1 GBit/s "Aknowledgen" zu können.

Auch wenn du es nicht glauben willst: Die automatische Anpassung der Window Sizes klappt meist nicht so gut, wie sie klappen könnte. Da reicht schon die kleinste Verzögerung und deine 16 MByte fallen sehr schnell in sich zusammen. Und mit 20 ms Delay und 1 GBit/s Verbindung schon 20 MBit auf der Leitung, die bestätigt werden müssen - also eine nicht gerade unerhebliche Menge. Außerdem weist ja die Problematik mit mehreren Streams genau darauf hin, dass es zu solchen Problemen kommt.

[RcRaCk2k]

Ich habe hier mal ein Video davon gemacht.

Ich habe ein paar Mal den Test neu gestartet und dabei immer andere Werte bekommen.
Das kann mir doch keiner erklären, wo hier der Fehler liegt?

Ab 02:45 mache ich mehrere schnelle Tests.

https://youtu.be/f9WUAjYfpdQ

Bei 25 MBit/s sieht die Window-Size, RTT und Speed wie folgt aus:
[ externes Bild ]

[reneromann]

Wenn ihr in der Firma "nur" eine 1 GBit synchron habt, dann führt doch jeglicher anderer Traffic automatisch zum Einbruch der Leistung, die du hier messen willst...
Oder übersehe ich da gerade etwas?

Sprich: Ein Mitarbeiter oder Programm, der gerade etwas hochlädt, verringert automatisch deine Testgeschwindigkeit...

[RcRaCk2k]

Da hast du natürlich vollkommen Recht, das würde den Traffic beeinflussen.
Aber der Server hängt ganz alleine an einer 1 GBit/s Leitung.

Und im Monitoring sehe ich die Auslastung des Servers am Ethernet-Port.

Zeitgleich funktioniert der Download aber an einem TELEKOM DEUTSCHLAND LAN IP FIBER 1.000 "korrekt" 91,7 MB/s (733,6 MBit/s), da limitiert dann aber die CPU und der WGET-Befehl zeigt 99% CPU-Last an (ist ein Quad 1.2 GHz MIPSEL 64-Bit Router auf dem ich den Download durchführe). Der Upload wird von einer "großen" Maschine durchgeführt, welche bei 6,8 GBit/s seine Probleme findet bei MTU 1500b.

Fakt ist, dass die KD mehrere Routen zum Ziel (mich als Kunde) hat. Keine Ahnung wie die Netz-Topologie gebaut ist, aber sicherlich gehen keine 100G von der Mitte durch das ganze Mesh bis zum CMTS. Ich gehe davon aus, dass n * 10G oder n * 40G verwendet wurde, und als aggregation-Protokoll LACP / LAG mit Layer2+Layer3+Layer4 Hash verwendet wird. Das würde zumindest erklären, warum bei mehrfacher Wiederholung der Tests die Geschwindigkeit so immens schwankt.

Hier Test von Telekom Business Fiber 1000

Code: Alles auswählen

root@ubnt:/home/rack# curl -o /dev/null --interface 192.168.178.2 http://download.rsm-connect.net/1gb.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 67 1108M   67  745M    0     0  88.6M      0  0:00:12  0:00:08  0:00:04 91.3M

Kabel Deutschland Business 500

Code: Alles auswählen

C:\Users\Michael Rack>wget -O NUL --report-speed=bits http://download.rsm-connect.net/1gb.iso
--2019-11-14 07:49:10--  http://download.rsm-connect.net/1gb.iso
Resolving download.rsm-connect.net (download.rsm-connect.net)... 185.58.31.10
Connecting to download.rsm-connect.net (download.rsm-connect.net)|185.58.31.10|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1162083328 (1,1G) [application/octet-stream]
Saving to: 'NUL'

NUL            41%[=====================================>                                ] 454,90M   437Mb/s    eta 12s   
^C

C:\Users\Michael Rack>wget -O NUL --report-speed=bits http://download.rsm-connect.net/1gb.iso
--2019-11-14 07:50:06--  http://download.rsm-connect.net/1gb.iso
Resolving download.rsm-connect.net (download.rsm-connect.net)... 185.58.31.10
Connecting to download.rsm-connect.net (download.rsm-connect.net)|185.58.31.10|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1162083328 (1,1G) [application/octet-stream]
Saving to: 'NUL'

NUL             0%[                                                                      ]   6,63M  27,6Mb/s
^C

C:\Users\Michael Rack>wget -O NUL --report-speed=bits http://download.rsm-connect.net/1gb.iso
--2019-11-14 07:50:08--  http://download.rsm-connect.net/1gb.iso
Resolving download.rsm-connect.net (download.rsm-connect.net)... 185.58.31.10
Connecting to download.rsm-connect.net (download.rsm-connect.net)|185.58.31.10|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1162083328 (1,1G) [application/octet-stream]
Saving to: 'NUL'

NUL           100%[=====================================================================>]   1,08G   301Mb/s    in 35s

2019-11-14 07:50:43 (266 Mb/s) - 'NUL' saved [1162083328/1162083328]

Man sieht, dass die Geschwindigkeit einmal bei 437 MBit/s war.
Es ist also möglich.... Ich gehe einfach von einem überlasteten Segment aus.
Und den LAG / LACP sieht man auch gut... Manche Streams sind langsamer, bis 20 MBit/s runter.

[robert_s]

Hier Test von Telekom Business Fiber 1000

Code: Alles auswählen

root@ubnt:/home/rack# curl -o /dev/null --interface 192.168.178.2 http://download.rsm-connect.net/1gb.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 67 1108M   67  745M    0     0  88.6M      0  0:00:12  0:00:08  0:00:04 91.3M

Vodafone Red Internet & Phone Cable 1000:

Code: Alles auswählen

$ curl -o /dev/null http://download.rsm-connect.net/1gb.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 84 1108M   84  940M    0     0  94.1M      0  0:00:11  0:00:09  0:00:02  111M

[robert_s]

Fakt ist, dass die KD mehrere Routen zum Ziel (mich als Kunde) hat. Keine Ahnung wie die Netz-Topologie gebaut ist, aber sicherlich gehen keine 100G von der Mitte durch das ganze Mesh bis zum CMTS. Ich gehe davon aus, dass n * 10G oder n * 40G verwendet wurde, und als aggregation-Protokoll LACP / LAG mit Layer2+Layer3+Layer4 Hash verwendet wird.
[...]
Man sieht, dass die Geschwindigkeit einmal bei 437 MBit/s war.
Es ist also möglich.... Ich gehe einfach von einem überlasteten Segment aus.

Du beschreibst eine Überlastung von einzelnen Backbone-Routen, schreibst dann aber Segmentüberlastung?

Mach mal die Gegenprobe: Während es zu rsm-connect lahmt, speedteste mal andere, leistungskräftige Server. Wenn die volle Geschwndigkeit bringen, kann das Segment nicht überlastet sein.