[linux-l] Re: ACKs bevorzugen mir fli4l

[Peter Ross]

On Mon, 21 Jul 2003, Steffen Dettmer wrote:

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

Prinzipiell kannst Du doch folgendes tun:

Annaehernd allen Upload in eine Queue packen, und der Queue, sagen wir
mal, 80% Deiner Bandbreite geben. Die Verbindungen, die Du mit hoeherer
Prioritaet behandeln willst, packst Du nicht in diese Queue. Da es
"kleine" Pakete sind, kommst Du mit dem Rest immer aus..

Zusaetzlich kannst Du die Queue der priorisierten Pakete halt auch noch
mit hoeherer Prioritaet entsprechend der erwaehnten QoS-Methoden
versenden.

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

Mach Dir nichts draus.. ich auch nicht;-) Einige habe ich das erste Mal
gelesen.. werde mich bei Gelegenheit mal schlau machen.

RED kenne ich und es ist eigentlich dafuer da, um "Staus" zu vermeiden.
Und es gibt einen RFC dazu ( bitte unter http://wwww.ietf.org suchen )

Uebrigens hat der BSD-Code noch einen Algorithmus auf TCP-Ebene, um mit
schnellen Sendern und langsamen Verbindungen umzugehen (um z.B. auch
"kleinen Paketen" Vorrang zu lassen, wie sie bei X Windows oder telnet
vorkommen, und die oft interaktiv sind, so dass "Haenger" nerven). Bei
Linux weiss ich es nicht, es ist denkbar. Auch wenn ich schon ein paar
peinliche "Ausrutscher" gesehen habe, die mir die Vermutung lassen, dass
auf der Ebene Linux nicht besonders sophisticated ist. Roch sehr nach
schlichtem FIFO ohne Optimierungen, aber Genaues weiss man erst, wenn man
den Sourcecode begriffen hat (ich bin's nicht;-)

Eventuell verhindern lizenzrechtliche Gruende, die BSD-TCP/IP-Strategien,
die sich in den meisten kommerziellen OSen befinden (Windows, MacOS,
verschiedene Unixe) wiederfinden, unter Linux einzusetzen. Man kann,
glaube ich, keinen Code mit BSD-Lizenz in einen Kernel packen, der dann
unter GNU-Lizenz steht.

Ich beschaeftige mich gerade mit iSCSI und vermute, dass das der
Hauptgrund ist, warum die Cisco-Implementierung (unter BSD-Lizenz) fuer
Linux im Userland statt im Kernel arbeitet.

Langsam denke ich, dass jedes IT-Studium Lizenzrecht beinhalten sollte.
Hatte ich nicht.. Aber vielleicht uebernehmen ja die Juristen und
Telephondesinfizierer das Geschaeft ja auch ganz. Sie tun jedenfalls
derzeit so, als ob sie von I.T. mehr verstuenden als Techniker;-)

Es wird eine Zeit kommen, in der man dem letzten Farmer das Handwerk
gelegt hat und wir anfangen, BGBs zu essen. Guten Appetit!

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

Man hofft, dass Dir der Provider Dir wirklich das gibt, was er
verspricht.. Wenn nicht, kannst Du o.g. Strategie mit defensiveren
Vorgaben, wann die Leitung "voll" ist, arbeiten.

Ich glaube, das Ganze lohnt sich nur, wenn Du Deine Verbindung fuer recht
gut bestimmbare Zwecke nutzt. In einem "Mischbetrieb", wie ich ihn bis
jetzt immer hatte, wo gleichzeitig 100 Leute 10 verschiedene Services
nutzen, wechselten die Anforderungen so haeufig, dass ich der Meinung bin,
dass das "Schrauben" nicht so viel bringen wuerde. Da verlasse ich mich
auf die o.g. Builtins (und nicht auf Linux, wenn man mich laesst;-)

Bevor jemand die Spezialitaeten der QoS-Strategien liest, schlage ich vor,
Stevens "TCP/IP Illustrated" in die Hand zu nehmen. Ist m.E. die beste
Grundlage, fuer diesen Fall z.B. Kapitel 19 und 20 des ersten Bandes.

Gruss
Peter