[Fli4l_dev] Bufferbloat

[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.

(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).

(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).

(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?

Wie du siehst, wird die Thematik beliebig komplex, wenn man sich die Mühe 
macht, über alles einmal nachzudenken.

-----
 
> 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...

-----

Bei all solchen Dingen muss man eine vernünftige Analyse durchführen. Ein 
"ich habe da mal einen Artikel gelesen" reicht einfach nicht aus.

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).


Viele Grüße,
-- 
Christoph Schulz
[fli4l-Team]