Andere/Übergreifend Bufferbloat, wer, wie, was, wieso, weshalb, warum

[pufferueberlauf]

Wie erwartet/vorhergesagt bewirkt das ingress Keyword etwas aggressiveres Shaping (wobei mehr Bandbreite geopfert wird), wobei ingress quasi selbst-tunend sein sollte, d.h. mit nur 10 flows sollte das Bandbreitenopfer kleiner ausfallen... Grob betrachtet scheint Ingress die Latenz aehnlich eines 5% kleineren Egress Bruttos zu bewirken jedoch ohne genauso viel Durchsatz zu kosten.

Im Alltag verwende ich FQ-CoDel und verzichte dabei auf ca. 3 % der Nettodatenrate:

Auch eine gutes AQM. Selber bin ich seit Jahren bei sch_cake gelandet, da ich die interne-IP-fairness-Modi sehr hilfreich finde (die Kapazität wird erst fair zwischen den aktiven IP Adressen verteilt und innerhalb jeder IP Adresse dann wieder Flow-fair, dadurch kann kein einzelner Host das Netzwerk fuer die anderen voll ausbremsen.)

Mein Modem zeigt einerseits die Bruttodatenrate nicht an

Das ist auch egal, der Punkt hinter meiner Obsession fuer konservatives Overhead-Accounting kommt daher, dass wenn man das nicht macht die dem Shaper gesetzte Bruttogrenze nicht eingehalten wird:
hier ein Beispiel fuer 100 Mbps Ethernet und IPv4/TCP Goodput

100 * ((1500-20-20)/(1500+38)) = 94.93
100 * ((150-20-20)/(150+38)) = 58.51

Wenn man jetzt den Shaper nach den Speedtestresultaten (Annahme der Speedtest war perfekt und wir sehen das oben berechnete theoretische Maximum) einstellt so dass kein Bloat auftritt ohne explizit Overhead zu konfigurieren (dann bekommt man die Standatd 14 Byte die der Kernel kennt):

94.93 / ((1500-20-20)/(1500+14)) = 98.44

d.h stellt man den Shaper auf 98.44 hat man das Problem dass der Overhead falsch angesetzt war behoben...

Jetzt mal sehen was passiert wenn wir nur 150 Byte grosse Pakete haben:

98.44 * ((150-40)/(150+14)) = 66.0268292683

das entspricht einer echte Ethernet-Brutterate von

66.0268292683 / ((150-40)/(150+38)) = 112.85

was wiederum etwas mehr ist als die tatsächliche Flaschenhalsrate von 100, et voila, der cake/fq_codel haben keine Chance mehr die Latenzzunahme unter Last zu vermeiden. Deshalb die generelle Empfehlung den Overhead lieber etwas zu gross als etwas zu klein anzusetzen....

Klar, oft wird ein Link durch normale Downloads gesättigt und da ist die Paketgroesse meistens nahe am Maximum, aber z.B. bei einem 1000/50 Link wird bei einem sättigenden 1000 Mbps Download bis zu 1000/40 = 25 Mbps reverser ACK-Traffic erzeugt und dessen Pakete sind sogar kleiner als 150 Byte, und damit hat ein Egress Traffic Shaper das Problem, dass er effektiv das Upstream-Volumen signifikant unterschätzt.

 

[0-8-15 User]

sch_cake ... Overhead-Accounting

Das muss man sich mit pfSense leider beides abschminken - zumindest ohne weiteren Router dazwischen. 😞

 

[pufferueberlauf]

Mmmh, OK ist halt ein Trade-Off, "bessere/vielseitigere" Firewall oder bessere Traffic-Shaper. Ist dann halt von den lokalen Bedingungen/Vorlieben abhängig. Ich bin bei OpenWrt haengen geblieben, auch wenn vile pfSenser/OpenSenser da immer ein bisschen die Nase rümpfen, fuer meine Belange reicht es voll aus, aber ich habe xSense auch noch nie ausprobiert, und weiss vielleicht gar nicht was mir da entgeht.

 

[kingpin42]

http://icmpcheckv6.popcount.org/

Oder gibt es einen Thread für nützliche Netztools zum Debugging ?

 

[KernelMaker]

@pufferueberlauf
Mega cool, danke für deinen Post.

Damit dem neuen Mac-Tool werde ich direkt mal ausprobieren, das kannte ich noch gar nicht. Vielen Dank.

 

[0-8-15 User]

Ich hab mal spaßhalber mit Selenium die Zeit (domComplete - navigationStart) gemessen, die es braucht, um die 30 meistaufgerufenen Internetseiten meines Browserverlaufs jeweils mit und ohne Hintergrundlast (iperf3 mit 4 TCP-Streams) bzw. mit und ohne Traffic Shaping vollständig zu laden. Ergebnis:

Hintergrundlast​	Nativ​	FQ-CoDel​
-​	35 s​	36 s​
Download	47 s​	40 s​
Upload	63 s​	40 s​

 

[pufferueberlauf]

Interessant, wie reproduzierbar ist das Ganze? Und was passiert wenn Du als Hintergrundlast Down- und Upload testest?

 

[0-8-15 User]

wie reproduzierbar ist das Ganze?

Ziemlich, solange der zeitliche Abstand zwischen den einzelnen Messreihen nicht zu groß wird, man sich von den (abendlichen) Stoßzeiten fernhält und man für einen konsistenten Zustand der beteiligten DNS Caches sorgt.

was passiert wenn Du als Hintergrundlast Down- und Upload testest?

Hintergrundlast​	Nativ​	FQ-CoDel​
-	30 s​	30 s​
Download​	40 s​	34 s​
Upload	55 s​	35 s​
Download + Upload	70 s​	39 s​

 

[pufferueberlauf]

Sauber! Zeigt IMHO was auch unter Last geht, wenn man sich etwas Muehe gibt. Waere noch interessant zu wissen wie hoch die RTT zu den Webseiten ist, aber da die ja alle aus vielen individuell gehosteten Assets bestehen gibt es wahrscheinlich keine eindeutige RTT pro Website.

 

[0-8-15 User]

Waere noch interessant zu wissen wie hoch die RTT zu den Webseiten ist

Zu vielen < 8 ms, zur Mehrheit zwischen 10 und 20 ms und zu wenigen > 100 ms.

 

[pufferueberlauf]

Ah, interessant, unter Last erlaubt fq_codel 5ms standing queue, was aber effektiv oft eher 10ms pro belasteter Richtung, das passt in etwa zu der milden Latenzerhoehohung die Du siehst. Waere sicherlich auch interssant mal den NetworkQuality Test von Apple laufen zu lassen, wenn Du aktuelle iOS oder Macos Geraete hast.

 

[0-8-15 User]

Waere sicherlich auch interssant mal den NetworkQuality Test von Apple laufen zu lassen

Nativ:

==== SUMMARY ====                                                                                         
Upload capacity: 32.292 Mbps
Download capacity: 254.306 Mbps
Upload flows: 12
Download flows: 12
Responsiveness: Medium (867 RPM)

FQ-CoDel:

==== SUMMARY ====                                                                                         
Upload capacity: 30.382 Mbps
Download capacity: 242.405 Mbps
Upload flows: 12
Download flows: 12
Responsiveness: High (3678 RPM)

 

[pufferueberlauf]

Wie sieht das mit dem -v switch aus, wird der Output dann detaillierter?

 

[0-8-15 User]

Mit -v gibt er zusätzlich noch Base RTT: 11 ms und das Datum aus, aber -c liefert mehr Details:

{
  "dl_flows" : 12,
  "dl_throughput" : 254429104,
  "lud_foreign_h2_req_resp" : [
    32,
    20,
    25,
    21,
    18,
    15,
    12,
    12
  ],
  "lud_foreign_tcp_handshake_443" : [
    14,
    14,
    14,
    14,
    14,
    16,
    14,
    16
  ],
  "lud_self_dl_h2" : [
    502.18307495117188,
    472.52593994140625,
    470.57293701171875,
    999.9530029296875,
    1554.9649658203125,
    1517.4189453125,
    1477.820068359375
  ],
  "lud_self_ul_h2" : [
    9.5859766006469727,
    56.864974975585938,
    15.82491397857666,
    128.98004150390625,
    182.29306030273438,
    157.74893188476562,
    121.56594085693359,
    115.95893096923828
  ],
  "responsiveness" : 3542,
  "ul_flows" : 12,
  "ul_throughput" : 31828856
}

 

[KernelMaker]

Telekom FTTH und pfsense 2.6.0

Normal:

==== SUMMARY ====                                                                                        
Upload capacity: 250.825 Mbps
Download capacity: 904.050 Mbps
Upload flows: 20
Download flows: 12
Responsiveness: High (3086 RPM)

FQ-Codel:

==== SUMMARY ====                                                                                        
Upload capacity: 226.795 Mbps
Download capacity: 896.006 Mbps
Upload flows: 16
Download flows: 16
Responsiveness: High (4137 RPM)

 

[pufferueberlauf]

Mit -v gibt er zusätzlich noch Base RTT: 11 ms und das Datum aus,

OK, zumindest die Base RTT ist interessant, da man daraus die Ruhe-RPM abschätzen kann*:

60 [sec/min] * 1 / (Base RTT [msec] / 1000 [msec/sec] ) = RPM [1/min]
60/(11/1000)  = 5455 RPM

aber -c liefert mehr Details:

Grossartig, daraus kann man dann die gemittelte Latenz unter Last rekonstruieren:
(60/3542)*1000 = 16.939582157 ms

was ziemlich genau dem Durchschitt von lud_foreign_h2_req_resp + lud_foreign_tcp_handshake_443 entspricht:

(32 + 20 + 25 + 21 + 18 + 15 + 12 + 12 + 14 + 14 + 14 + 14 + 14 + 16 + 14 + 16) / 16 = 16.9375 ms

*) Das ist natürlich nur grob, da nicht klar ist was genau als Base RTT reportiert wird, sollte aber als Abschaetzung der Obergrenze taugen (mit RPM Obergrenze <= (60 * 1 / (BaseRTT / 1000))

 

[0-8-15 User]

Auf der Suche nach der Bedeutung von lud_self_dl_h2 bzw. lud_self_ul_h2 bin ich in der Bloat mailing list über folgenden lesenswerts Abschnitt gestolpert: https://www.mail-archive.com/bloat@lists.bufferbloat.net/msg06726.html

 

[pufferueberlauf]

Noch mehr theoretische Details, wenn auch keine direkte Erklaerung der Variablen im IETF draft:
https://github.com/network-quality/...lob/master/draft-ietf-ippm-responsiveness.txt:
"4.2. Measuring Responsiveness

Once the network is in a consistent working conditions, the RPM Test
must "probe" the network multiple times to measure its
responsiveness.

Each RPM Test probe measures:

1. The responsiveness of the different steps to create a new
connection, all during working conditions.

To do this, the test measures the time needed to make a DNS
request, establish a TCP connection on port 443, establish a TLS
context using TLS1.3 [RFC8446], and send and receive a one-byte
object with a HTTP/2 GET request. It repeats these steps
multiple times for accuracy.

2. The responsiveness of the network and the client/server
networking stacks for the load-generating connections themselves.

To do this, the load-generating connections multiplex an HTTP/2
GET request for a one-byte object to get the end-to-end latency
on the connections that are using the network at full speed.

4.2.1. Aggregating the Measurements

The algorithm produces sets of 5 times for each probe, namely: DNS
handshake, TCP handshake, TLS handshake, HTTP/2 request/response on
separate (idle) connections, HTTP/2 request/response on load-
generating connections. This fine-grained data is useful, but not
necessary for creating a useful metric.

To create a single "Responsiveness" (e.g., RPM) number, this first
iteration of the algorithm gives an equal weight to each of these
values. That is, it sums the five time values for each probe, and
divides by the total number of probes to compute an average probe
duration. The reciprocal of this, normalized to 60 seconds, gives
the Round-trips Per Minute (RPM)."

 

[riversource]

Gibt es für sowas Tools abseits der Apple Apps, mit denen man das messen kann? Für Linux zum Beispiel?

 

[pufferueberlauf]

Gibt es für sowas Tools abseits der Apple Apps, mit denen man das messen kann?

Halt https://github.com/network-quality/goresponsiveness aber das ist momentan etwas buggy und wartet darauf dass Fixe upstream integriert werden... aber das laeuft auch unter Linux, aber momentan halt buggy