[Fli4l_dev] Bufferbloat

[Matthias Prager]

Hallo Christoph,

bitte entschuldige, dass ich erst so spät antworte - kam einiges
dazwischen.

Am 25.10.2014 um 15:27 schrieb Christoph Schulz:
> Hallo!
> 
> Matthias Prager wrote:
> 
>> [...]
>> Also pfifo_fast. Nun wird empfohlen den FQ-Codel zu nutzen:
>>  > sysctl -w net.core.default_qdisc=fq_codel
>>  sysctl: short write
>>
>> Ich gehe mal davon aus, dass der nicht in den Kernel mit rein kompiliert
>> ist. Spricht etwas dagegen, diesen Scheduler aufzunehmen? (Um ihn später
>> evtl. zum default zu machen)
> 
> (1) Wenn der Scheduler nicht der Default-Scheduler ist, dann wird das seine 
> Gründe haben. Bitte bedenke, dass die selbstlernenden Algorithmen nicht 
> 100%-ig sind, also auch ihre Schwächen haben. Bedenke auch, dass der fli4l 
> ein breites Anwendungsprofil hat -- er wird nicht nur für superschnelle 
> Leitungen (VDSL) genutzt, sondern auch für langsame (ISDN); für Leitungen 
> mit niedriger Latenz (DSL) und mit hoher Latenz (UMTS). Solche 
> spezialisierten Algorithmen gehen i.d.R. von bestimmten Voraussetzungen aus, 
> für die sie optimiert sind. Somit ist ein "one size fits all"-Ansatz von 
> vornherein zum Scheitern verurteilt. Der von dir verlinkte Artikel enthält 
> den Satz:
> 
> "Unfortunately, the default queuing discipline cannot be changed, since it 
> will certainly disturb some user's workload somewhere."
> 
> Sogar die Befürworter von fq_codel sagen also, dass es negative 
> Seiteneffekte haben *kann*, wenn man wechselt.
Das habe ich nicht bedacht.

> 
> (2) Der Scheduler wird übersetzt, allerdings als Modul. Du musst einfach nur 
> ein OPT bereitstellen, welches dem Nutzer eine Scheduler-Auswahl erlaubt, 
> das entsprechende Modul auf den fli4l kopiert und während des Boot-Vorgangs 
> das Modul aktiviert. Dann kann man auch den Scheduler an seine Bedürfnisse 
> anpassen. Mit einer abstrakten Profilauswahl wäre dem unkundigen Nutzer noch 
> besser geholfen (der Nutzer stellt also nicht "codel", "pfifo_fast" etc. 
> ein, sondern "DSL (langsam)", "DSL (FastPath)", "ISDN" etc. ein).
Das wäre in der Tat eine feine Sache zum damit experimentieren.
Allerdings habe ich noch nie selbst ein OPT geschrieben (nur dran rum
gepatcht). Muss schauen, wann ich dazu komme mich darin einzuarbeiten.

> 
> (3) Im Kontext von FFL-506 mit Multi-Circuit-Unterstützung wird ein 
> automatischer Wechsel des Schedulers je nach verwendetem Uplink-Circuit 
> interessant, oder eine gleichzeitige Nutzung mehrerer Scheduler für 
> unterschiedliche Schnittstellen (falls das geht).
Ja das geht! Habe ich zwischenzeitlich beim experimentieren auf meinem
Gentoo-Server im Keller gehabt. (Mittlerweile habe ich dort aber einfach
'net.core.default_qdisc=fq_codel' in die /etc/sysctl.conf eingetragen.)

> 
> (4) Was ist mit der Einbeziehung benutzerdefinierter Traffic Control-
> Einstellungen (tc), wie sie z.B. vom qos-Paket vorgenommen werden? Immerhin 
> installiert qos die Scheduler HTB (Hierarchical Token Bucket) und SFQ 
> (Stochastic Fairness Queueing) -- warum also nicht das qos-Paket um CODEL 
> erweitern? Wie sehen mögliche Interaktionen zwischen qos und deinem 
> Vorschlag aus?
Das ist vermutlich die der einfachere Weg, als ein separates OPT zu
schreiben. Wo und wie genau HTB und SFQ eingesetzt werden habe ich mir
aber noch nicht genauer angeschaut.

> 
> Wie du siehst, wird die Thematik beliebig komplex, wenn man sich die Mühe 
> macht, über alles einmal nachzudenken.
In der Tat. Danke für die Denkanstöße!

> 
> -----
>  
>> Eine weitere Geschichte wäre evtl. (ab Kernel 3.18) TCP Congestion
>> control via DCTCP (Data-Center TCP). Momentan wird cubic verwendet:
>>  > sysctl net.ipv4.tcp_congestion_control
>>  net.ipv4.tcp_congestion_control = cubic
> 
> Auch hier ist ein sinnvoller Default gewählt worden.
> 
>>
>> Wäre dann dieser Befehl (oder im Kernel als default einstellen):
>>  > sysctl -w net.ipv4.tcp_congestion_control=dctcp
> 
> Warum sollte man Data Center TCP als Default nehmen? Welche Anwendungsfälle 
> werden durch dctcp besser abgedeckt als durch cubic? Welche schlechter? Ist 
> für das Gros der fli4l-Nutzer cubic die bessere Wahl als dctcp? Wenn ja, 
> warum? Wenn nein, warum nicht?
> 
> "DCTCP is an enhancement to the TCP congestion control algorithm for data 
> center networks." (http://simula.stanford.edu/~alizade/Site/DCTCP.html)
> 
> Und weiter:
> 
> "Cloud data centers host diverse applications, mixing workloads that
> require small predictable latency with others requiring large sus-
> tained throughput. In this environment, today’s state-of-the-art TCP
> protocol falls short. We present measurements of a 6000 server
> production cluster and reveal impairments that lead to high applica-
> tion latencies, rooted in TCP’s demands on the limited buffer space
> available in data center switches. [...]" 
> (http://simula.stanford.edu/~alizade/Site/DCTCP_files/dctcp-final.pdf)
> 
> Nicht jeder fli4l (vermutlich kaum einer) steht in einem Data-Center-
> Netzwerk als Router in einem Cluster mit 6000 Servern...
Nein, hier z.B. nur für den Familienzugang, ganz so viele Rechner sind
es noch nicht :-) . Ich habe mich darin auch noch nicht näher
eingelesen, aber vom Prinzip her entwickeln sich ja die Heimrouter in
diese Richtung (ok vielleicht nicht bei jedem), immer mehr Geräte machen
immer unterschiedlicher Dinge im Internet über den Router. Auch da
dachte ich eigentlich eher an die Möglichkeit damit zu experimentieren.
Ich fand es halt eine spannende Entwicklung, die ich erwähnte, da ich
sie mir selbst mal anschauen wollte.

> 
> -----
> 
> Bei all solchen Dingen muss man eine vernünftige Analyse durchführen. Ein 
> "ich habe da mal einen Artikel gelesen" reicht einfach nicht aus.
Ja da hast Du recht! Mir geht es auch eigentlich erst mal darum damit zu
spielen/experimentieren.

> 
> Danke für die Denkanstöße. Dennoch würde ich mich eher über ein externes OPT 
> freuen, das bei entsprechender "Reife" und der Berücksichtigung der o.g. 
> Punkte auch integriert werden kann (z.B. in advanced_networking).
Ich werde schauen, was ich machen kann. Will aber noch nichts versprechen.


Viele Grüße
Matthias