Limitiert Kabel Deutschland FTP und HTTPS Traffic?

[RSQuattro]

Hallo zusammen,

ich habe eine grundlegende Frage, ob Kabel Deutschland den HTTPS und FTP Traffic begrenzt?

Wir haben in der Firma ein Kundenportal für Down- und Uploads. Den Kunden wird ein https link z.b. per Mail geschickt und sie können sich von uns diverse Sachen wie neue Software usw runterladen, ebenso ein Upload Portal für Fehler, Logfiles usw.

Da wir Weltweit agieren, ist jetzt unsere Meinung das Kabel Deutschland den Traffic stark begrenzt, da User von anderen Anbietern mit voller Bandbreite von uns runterladen können.
Wir haben eine 1Gbit synchrone Glasfaser Leitung in der Firma. Privat habe ich 500/50 Business Leitung und bekomme gerade mal zwischen 60-100Mbit zusammen, wenn ich von der Firma was runterladen möchte. Das gleiche mache ich mit einem anderen Anbieter und ich kann mit maximalen Download runterladen.

Wir haben jetzt Wochenlang Fehleranalyse betrieben und jedesmal kommen wir auf den gleichen Punkt. Kabel Deutschland muss den Traffic begrenzen. Bei FTP und VPN ist es übrigens genau das gleiche.
Da leider unsere Kunden in Deutschland viele Kabel nutzen ist das grad ein akutes Problem. Natürlich sind jetzt 60-100Mbit nicht langsam, aber nicht das was unser Firmen Anschluss kann. Darum die Frage!

Dieses Thema muss ja andere Firmen auch betreffen. Soweit ich weiß, schaltet Vodafone bei den ganz großen Firmen für den Traffic IP Adressen frei.
Kann man sowas beantragen?
Vielen Dank für Eure Hilfe!

[dirk1405]

Ich habe schon öfters von solchen Vermutungen gehört.
Wenn ein solcher Fall eintritt, ist es Möglich mal einen Speedtest zu machen?
D.h. auszuschließen dass nicht die komplette Bandbreite reduziert ist?
Habt ihr ein Monitoring in der Firma? Ich hatte mal den Fall während im Hintergrund Updates auf den Firmenrechner liefen. Aber das betrifft bei dir ja eigentlich nicht den Upload.
GGf. wenn du dir für zuhause einen vernünftigen VPN mal testweise zulegst und das damit testest?

[Flole]

Vielleicht ist das Peering einfach nur "suboptimal" ums mal milde auszudrücken? Der Anbieter des Firmenanschlusses sollte einem Geschäftskunden da entsprechende Daten zur Auslastung liefern können.

[RSQuattro]

An unserem Firmenanschluss liegt es nicht, da Kunden aus aller Welt von uns mit deren voller Bandbreite runter laden können. Wir hab deswegen schon extremem Aufwand betrieben. Per Teamviewer beim Kunden usw.
Fakt ist, das Telekom und Vodafone Kunden begrenzt werden.
Lädt man die Datei per Jdownloader mit 20 Verbindungen, dann liegt die volle Bandbreite auch an, aber das können wir keinen Kunden zumuten ein extra Programm zu installieren.
Das mit VPN werde ich morgen mal testen.

[robert_s]

ich habe eine grundlegende Frage, ob Kabel Deutschland den HTTPS und FTP Traffic begrenzt?
[...]
Da wir Weltweit agieren, ist jetzt unsere Meinung das Kabel Deutschland den Traffic stark begrenzt,

Meinung widerlegt:

Code: Alles auswählen

$ wget -O /dev/null https://speed.hetzner.de/1GB.bin -4 --report-speed=bits
--2019-11-12 20:48:33--  https://speed.hetzner.de/1GB.bin
Resolving speed.hetzner.de (speed.hetzner.de)... 88.198.248.254
Connecting to speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1048576000 (1000M) [application/octet-stream]
Saving to: ‘/dev/null’

/dev/null           100%[===================>]   1000M   921Mb/s    in 9,3s    

2019-11-12 20:48:43 (899 Mb/s) - ‘/dev/null’ saved [1048576000/1048576000]

Code: Alles auswählen

$ wget -O /dev/null -4 --report-speed=bits ftp://speedtest.tele2.net/1GB.zip
--2019-11-12 20:51:11--  ftp://speedtest.tele2.net/1GB.zip
           => ‘/dev/null’
Resolving speedtest.tele2.net (speedtest.tele2.net)... 90.130.70.73
Connecting to speedtest.tele2.net (speedtest.tele2.net)|90.130.70.73|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD not needed.
==> SIZE 1GB.zip ... 1073741824
==> PASV ... done.    ==> RETR 1GB.zip ... done.
Length: 1073741824 (1,0G) (unauthoritative)

1GB.zip             100%[===================>]   1,00G   902Mb/s    in 9,9s    

2019-11-12 20:51:21 (867 Mb/s) - ‘/dev/null’ saved [1073741824]

Wir haben jetzt Wochenlang Fehleranalyse betrieben und jedesmal kommen wir auf den gleichen Punkt. Kabel Deutschland muss den Traffic begrenzen.

An unserem Firmenanschluss liegt es nicht, da Kunden aus aller Welt von uns mit deren voller Bandbreite runter laden können. Wir hab deswegen schon extremem Aufwand betrieben. Per Teamviewer beim Kunden usw.
Fakt ist, das Telekom und Vodafone Kunden begrenzt werden.
Lädt man die Datei per Jdownloader mit 20 Verbindungen, dann liegt die volle Bandbreite auch an, aber das können wir keinen Kunden zumuten ein extra Programm zu installieren.

Das erweckt jetzt nicht wirklich den Eindruck, dass ihr wusstet, wie man so etwas überhaupt analysiert. Was hat traceroute ergeben, was tcptrace?

[Abraxxas]

Fakt ist, das Telekom und Vodafone Kunden begrenzt werden.

Wenn das Fakt ist dann würde ich VF und Telekom damit konfrontieren und nicht in einem Internet Forum um Hilfe ersuchen.
Ich muss da @robert_s Recht geben, ihr geht da anscheinend recht laienaft ran.
Zu behaupten die würden den Traffic begrenzen ist schon sehr weit hergeholt. Denn, warum sollten sie das tun? Weisst du wieviel Traffic Limiter im Carrier Umfeld kosten?

[Flole]

Allein schon die Aussage "Kunden aus aller Welt haben keine Probleme" als Antwort auf ein vermutetes schlechtes Peering zeigt das es wohl schon am Verständnis des Prinzips des Peerings scheitert, denn wenn man das verstanden hat dann weiß man sofort, das ein schlechtes Peering genau solche Auswirkungen hat. Die Telekom lässt sich das Peering gut bezahlen, daher wundert es mich da nicht das es Probleme gibt, insbesondere wenn jemand nicht bezahlen will, VF ist einfach nur elendig langsam im Kapazitäten vergrößern, da gab es ja schonmal Probleme vor einigen Jahren mit den Google Diensten (Youtube, PlayStore etc.), da wurde auch nicht begrenzt sondern da war einfach der Link dahin hoffnungslos überlastet, Auswirkungen sind aber letzendlich dieselben. Wurde dann aber auch ein dreiviertel-Jahr später schon repariert.

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.

[RcRaCk2k]

Servus Leute,

lange nichts mehr von mir hören lassen, aber mein Kunde hatte hier dieses Problem geschrieben und jetzt möchte ich auch kurz ein paar technische Details dazu abgeben:

Router-Standort: Salzburg
Anbindung: n * 10 GBit/s an die Carrier CORE BACKBONE und TELIA SONERA.
Netzübergang zu Kabel-Deutschland: PNI mit 100 GBit/s in München

So schaut der Traceroute von meinem HTTP-Server zum Kabel-Deutschland Anschluss aus:

Code: Alles auswählen

                                                             Packets               Pings
 Host                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. at-sbg-itz-tz-k10-r10-bgp01.rsm-connect.net             0.0%    50    0.3   0.4   0.1   1.8   0.2
    at-sbg-itz-tz-k10-r10-bgp02.rsm-connect.net
 2. xe-0-2-3-0.slz10.core-backbone.com                      0.0%    50    0.6   1.2   0.4  27.7   3.8
    ae0-403.slz10.core-backbone.com
 3. ae7-2030.muc10.core-backbone.com                        0.0%    50    4.0   2.9   2.3  11.9   1.7
 4. 145.253.34.13                                           0.0%    50    2.6   2.7   2.5   3.1   0.0
 5. 145.254.2.184                                           0.0%    50    7.9   8.0   7.8   8.5   0.0
 6. 145.254.3.101                                           0.0%    50    8.6   8.5   8.2   8.8   0.0
 7. 83-169-156-62.static.superkabel.de                      0.0%    49   11.6  11.7  11.3  13.6   0.3
 8. ???
 9. ipbcc07149.dynamic.kabel-deutschland.de                 0.0%    49   22.3  20.1  17.7  23.6   1.2

Der Rückweg ist ja nicht interessant, da es sich um ein Problem im Download handelt.
Daher ist nur der Weg vom SERVER zum KABEL-DEUTSCHLAND-KUNDEN interessant.

Download-Speed von meinem HTTP:Server
[ externes Bild ]

Speedtest.net mit EINER Verbindung
[ externes Bild ]

Speedtest.net mit MEHREREN Verbindungen
[ 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.

Der PNI in München ist komplett frei.

Test Download über die 1 GBit/s Anbindung direkt im RZ:

Code: Alles auswählen

rack@monitoring:~$ wget -O /dev/null -4 --report-speed=bits http://download.rsm-connect.net/1gb.iso
--2019-11-13 07:45:22--  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: /dev/null

/dev/null            100%[======================>]   1.08G  1.01Gb/s   in 9s

Test von einem 10G Server aus:

Code: Alles auswählen

rack@mirror-x14:~$ wget -O /dev/null -4 --report-speed=bits http://download.rsm-connect.net/1gb.iso
--2019-11-13 07:55:46--  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: /dev/null

/dev/null                100%[====================================>]   1.08G  6.44Gb/s   in 1.4s

2019-11-13 07:55:48 (6.44 Gb/s) - â/dev/nullâ saved [1162083328/1162083328]

Der Server gibt also Gigabit und mehr her.
Das kann man auch schon einmal ausschließen.

[RcRaCk2k]

Jetzt hat Kabel-Deutschland das Routing geändert und es wurde noch schlimmer.
Nur noch 600kByte/s (4,8 MBit/s).

Download-Screenshot:
[ externes Bild ]

Code: Alles auswählen

                                                         Packets               Pings
 Host                                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. at-sbg-itz-tz-k10-r10-bgp02.rsm-connect.net         0.0%    89    0.3   0.8   0.3  24.6   2.5
    at-sbg-itz-tz-k10-r10-bgp01.rsm-connect.net
 2. ae0-403.slz10.core-backbone.com                     0.0%    89    1.2   1.2   0.5  23.0   2.6
    xe-0-2-3-0.slz10.core-backbone.com
 3. ae7-2030.muc10.core-backbone.com                    0.0%    89    5.9   2.9   2.3  16.0   1.6
 4. 145.253.34.13                                       0.0%    89    2.8   2.8   2.5   3.2   0.0
--------- Ab hier anderer Weg ----------
 5. 145.254.2.200                                       0.0%    89    3.4   3.3   3.0   5.6   0.2
 6. 145.254.3.103                                       0.0%    89    4.0   4.1   3.8   4.7   0.0
 7. 83-169-156-59.static.superkabel.de                  0.0%    89    8.4   8.4   8.1  11.7   0.4
 8. ???
 9. ipbcc07149.dynamic.kabel-deutschland.de             0.0%    88   19.1  18.7  14.5  24.1   2.1

Route-Change from 100 MBit/s to 4,8 MBit/s:
[ externes Bild ]

[reneromann]

[...]
Der Rückweg ist ja nicht interessant, da es sich um ein Problem im Download handelt.
Daher ist nur der Weg vom SERVER zum KABEL-DEUTSCHLAND-KUNDEN interessant.
[...]

Vielen Dank - du bestätigst gerade selbst, dass du von Netzwerken keine Ahnung hast. Damit hat sich sämtliche weitere Diskussion eigentlich erledigt.

Nur so als Denkanstöße:
- Der Rückweg IST sehr wohl INTERESSANT, weil über den Rückweg ALLE Bestätigungspakete der TCP-Verbindung müssen.
- Weiterhin: Wenn das TCP-Window zu klein eingestellt ist, dann erreichst du auch nie volle Geschwindigkeit auf einer einzelnen Connection - sehr wohl aber mit mehreren Verbindungen, weil das Window für jede Connection einzeln gilt. Das Window muss dabei als Maximalwert mindestens den Wert aus der Round-Trip-Time multipliziert mit der Bandbreite erhalten, damit der Server nicht selbst anfängt, Daten trotz "leerer" Leitung zurückzuhalten, nur weil das Window vollgelaufen ist und die Bestätigungspakete noch nicht da sind.