[linux-l] Re: ACKs bevorzugen mir fli4l

[Ihno Krumreich]

On Tue, Jul 22, 2003 at 03:57:36PM +1000, Peter Ross wrote:
> 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;-)

Es gibt ein allgemeines Verfahren fuer TCP-Verbindungen, das auch im RFC
dokumentiert ist, bei dem bei einer TCP-Verbindung mit einem kleinen
Fenster begonnen wird. Kommen die Empfangsbestaetigungen entsprechend
schnell, wird die Fenstergroesse erweitert. Analog wird die
Fenstergroesse wieder verkleinert, wenn Fehler auftreten/Bestaetigungen
ausbleiben.

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

Man kann vielleicht keinen Code KOPIEREN. Neu programmieren ist erlaubt.

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

Sollten es lizenzrechtkiche Gruende geben, so ist es egal ob der Code
im Kernel oder Userland laeuft.

Die Entscheidung ob man etwas im Kernel oder userland macht haengt von
anderen Dingen ab:

- entwickeln und debuggen ist im Userland erheblich einfacher.
- achtet man bei der Entwicklung etwas darauf, laesst sich der Code
  meistens schnell in den Kernel portieren.
- Unter den Kernelentwicklern gibt es unterschiedliche Meinungen
  darueber, welche Funktionen im Kern laufen sollten und welche nicht.

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

Gruss

Ihno