Hat schon mal jemand TCP BBR aktiviert? Ein neues standartisiertes TCP feature „BBR“ Faster Networking with TCP BBR (Cloud Performance Atlas) - YouTube
Braucht man wohl nur auf dem server aktivieren und dann ist es für alle Clients doppelt so schnell bei Verbindungen mit packet loss.
Nein noch nicht getestet, ist wohl ab 4.9-x im Kernel.
Aber auf den Gateway bringt dir das absolut nichts, denn Congestion läuft zwischen Client / Server.
Du brauchst dazu also ein Linux Client mit Kernel 4.9+ und einen Endpunkt (bsp. Webserver) mit BBR.
Naja, irgendwo muss man ja mal anfangen…
Aber bis wir 4.9er-Kernel im Gluon haben wird es natürlich noch dauern, bei den Smartphones noch länger.
Bei Servern und Desktop-Clients: kein Problem…
In dem Video sagt der aber, dass die legacy clients da nix brauchen
BBR ist ziemlich kaputt. Das müllt einfach die Netzwerkswitche mit Paketen zu und verhält sich ziemlich rücksichtslos, nicht gerade die feine Art: Googles TCP-Flusskontrolle BBR bremst fremde Downloads aus | heise online
Das Video habe ich nicht geguckt, aber evt. ist der Kontext falsch?
(-> Überlaststeuerung_als_Forschungsfeld)
oder hier noch etwas ausführlicher.
(Überlaststeuerung (Congestion Control))
https://www.elektronik-kompendium.de/sites/net/2009211.htm
@NOCO Ist halt auch die Frage, ob man im einem Entwicklungsland lebt oder nicht. In Deutschland muss man schon überlegen ob die 50MBit/s VDSL Murks reichen oder ob es doch 100 MBit/s für 45€ sein sollen die immer wieder ihre sync verliert. 
In Zürich darf man überlegen, ob die 1GBit/s für 40€ reichen oder ob’s doch lieber 10GBit/s (natürlich synchron) für 38€ sein sollen. 
STM/ATM ist Sonet und damit eigentlich alles was als GPON derzeit angeboten wird. Frage ist nur: Meinst Du nicht eher „symmetrisch“?
Ja, mein ich. 
Hat damit aber auch nichts zu tun.
TCP-Flusskontrolle braucht man eigentlich immer, sobald die Summe der Eingänge größer als die Kapazität im Backbone ist. Eigentlich sogar sobald es Sender gibt die mehr Senden können als ein Empfänger verarbeiten kann. TCP wurde nicht nur aus akademischen Interesse in den 70ern erfunden, sondern weil es konkrete Probleme die bereits im Schmalband-Internet auftraten löste.
(Entgegen dem populären Glauben ist die Absicherung der Daten inkl. ARQ und Reordering nicht Hauptzweck von TCP sondern eher Nebenprodukt der Flusskontrolle. Den Rest könnte man auf Anwendungsschicht theoretisch auch eh viel besser lösen.)
Das ist auch der Grund warum BitTorrent (UDP-basiert) den ISPs immer so viel mehr Ärger macht als vom Volumen viel sifgnifikanteres Videostreaming (TCP-basiert).
Tja 