Tele2: Absichtlicher Verbindungsabbruch bei Vollast?

[ANOther]

Ich bin natürlich für jeden Input dankbar, aber es kann nicht Sinn der Sache sein, auf BT (oder irgendwas anderes P2P mäßiges) zu verzichten.

nicht verzichten, anpassen

Andere haben bei bis zu 2000 gleichzeitigen Verbindungen ohne Downloadbeschränkung keine Probleme

die, die keine probleme haben, haben vermutlich andere hardware, andere produkte, andere ...

Es hat nun 11 Monate problemlos funktioniert, dann murksen die Anfang März bei uns im Wählamt irgendwas rum, und seitdem treten diese Probleme auf.

das wählamt bringt dein modem zum absemmeln?
DAS ist allerdings nich uninteressant...

werde ich erstmal auf den Rückruf eines Tele2 Technikers vom 2nd Level warten

ich hoffe du lässt uns an der lösung teilhaben...

[Master One]

Ich habe da gerade was Interessantes in einem Beispiel für Ingress-Shaping gefunden:

Slow downloads down to somewhat less than the real speed to prevent queuing at our ISP. Tune to see how high you can set it. ISPs tend to have *huge* queues to make sure big downloads are fast. Attach ingress policer, filter *everything* to it (0.0.0.0/0), drop everything that's coming in too fast.

Also meine neue Vermutung ist nun, daß durch mein Upload-Shaping mit Bevorzugung der ACK-Pakete ganz einfach zu viel Traffic im Downstream angefordert wird, an einem gewißen Punkt die Queue beim Provider (also Tele2) übergeht, und der AC deswegen terminiert.

Was mir dabei aber nicht klar ist: Wie kann Ingress-Shaping das Problem beheben? Download-Shaping auf der Empfängerseite ist doch sinnlos, denn diesfalls sind die Pakete ja schon über die schmalbandige Leitung gewandert, und diese Pakete dann erst am WAN-Interface des Firewall-Gateway-Rechners zu droppen, wäre doch kontraproduktiv (Nutzdaten bereits empfangen, aber dann verwerfen?), oder habe ich da einen Denkfehler?

Leider habe ich auf die Schnelle keine Zeit, mich mit Ingress-Shaping zu beschäftigen, was ja wieder eine Versuchsreiche erfordert, und von Tele2 hat natürlich niemand zurückgerufen, und wir werden so vermutlich nie erfahren, was da bei Tele2 nicht funktioniert (denn auch wenn's die Download-Queue bei Tele2 sein sollte, so kann das doch nicht korrekt sein, daß der AC deswegen terminiert, oder?).

P.S. Gegen diese Vermutung spricht aber, daß es nun 11 Monate problemlos funktioniert hat, außer die haben diesbzgl. Anfang März bei der Tele2 Hardware verändert, oder irgendwas betreffend des Download-Queue-Verhaltens umkonfiguriert.

[Stefan Hedenig]

also _eigentlich_ werden pakete "nur" gedroppt wenn die queue voll ist, nicht gleich die ganze verbindung abgerissen...

[Master One]

Das habe ich ja auch gedacht, aber es bleibt ja sonst nichts mehr übrig. Das letzte TermReq war gestern um 10:36 Uhr, seitdem dümpelt der BT-Client mit sehr niedriger Rate dahin (und ist nun auf 850 KB/s im Download beschränkt), d.h. die Verbindung ist seitdem stabil. Der Upload kann's nicht sein, der wird hier geshaped, zusätzlich wurde ja schon ein Upload-Streßtest durchgeführt. Der Download bricht offenbar auch nicht einfach bei Totalauslastung ab, denn selbst wenn der BT > 1.2 MB/s saugt, und Spitzen bis 1.8MB/s erreicht, ist nicht sofort Schluß, sondern unvorhersehbar irgendwann, wenn dann eben mal das TermReq kommt. Auch ein inzwischen durchgeführter Download-Streßtest mit 10 gleichzeitigen Downloads von speedtest.inode.at bei Totalauslastung blieb ergebnislos. An der Anzahl der gleichzeitigen Verbindungen wird es auch nicht scheitern, da der BT-Client auf max. 200 beschränkt ist, was sicherlich drin sein soll. So gesehen könnte die Sache mit der Überlastung der Download-Queue beim Provider durchaus das Problem sein, wenn da irgendwas defekt oder falsch konfiguriert sein sollte.