[linux-l] Re: ACKs bevorzugen mir fli4l

Steffen Dettmer steffen at dett.de
Mo Jul 21 09:10:07 CEST 2003


* Peter Ross wrote on Mon, Jul 21, 2003 at 14:20 +1000:
> Es gibt ein sogenanntes "Window" (ein Feld des TCP-Headers), in dem steht,
> wieviel Daten uebertragen werden sollen.

Ja, so sinngemäßt steht da drin, "wieviel vom Window noch frei
ist".

> Wenn Pakete nicht bestaetigt werden, setzt der Sender es
> kleiner, annehmend, dass der Puffer des Empfaengers noch voll
> ist.

Genau, er darf maximal das Fenster ausnutzen (obwohl das selten
gleich gemacht wird).

> Meines Erachtens solltest Du also keine ACKs bevorzugt
> behandeln, sondern Verbindungen, die Du schnell "erledigt"
> haben willst.

Na ja, ich hab das so verstanden: er macht da massiv
uploads/downloads. Die Datenpakete sind hübsch groß. Damit ist
der upstream erstmal ca. platt. Der Download läuft erstmal durch
den "anderen" Teil der Fullduplexverbindung (der sich langweilt).
Nu geht download natürlich nur weiter, wenn ACKs immer schön und
möglichst auch gleich kommen, sonst können die netten
exponentiell (?) eskalierenden Timeouts zu schlagen. Also möchte
er, daß die kleinen ACK Packete, die seinen Upload quitieren, mit
höhrerer Priorität behandeln, als die großen Datenpackete, also
daß nicht die Uploads die ACKs plätten und so den Download
ausbremsen.

Interessant ist hier das verhalten bei schnellen Gegenstellen:
irgendwie "bündelt" sich dann die Bandbreite auf einen, wenn man
nichts dagegen tut. Die Tools sind hier aber clever geworden und
erlauben Millionen von Einstellungen, aber man bekommt das auch
gut mit drei gleichzeitigen FTP-Verbindungen hin :-)

> erwaehnt vorhandene "Queuing Disciplines":
> 
>     * Class Based Queue (CBQ)
>     * Token Bucket Flow (TBF)
>     * Clark-Shenker-Zhang (CSZ)
 [...] 
> 
> Mehr als genug, oder?

Zahlenmäßig auf jeden Fall :-)

Aber mir sind die Unterschiede/Vor- und Nachteile nicht klar. 

However, jedenfalls bleibt das Problem, daß man auf der anderen
Seite des Drahtes nichts machen kann. Wenn der Router hinterm
Uplink Pakete verwirft, weil aus seiner Sicht die Leitung voll
ist, sei es der Draht zu "mir" oder sein uplink, hilft mir das
weniger. So kann es sein, daß er mein ACK nicht weiterschickt,
weil meine Sende-daten zu fett sind. Aber bei den Tools kann man
oft Bandbreite limitieren, um das zu vermeiden. Das ein
eingehendes Datenpaket nicht verschickt wird, weil ein ACK zu
fett ist, ist wohl eher unwahrscheinlich ;-)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.




Mehr Informationen über die Mailingliste linux-l