Re: Traffic Sharper testen - Balancing/Bandbreitenbegrenzung

* Michael Haertl <michael.haertl(at)gmx.net> [020110 23:27]:

Hallo Michael,

> > du hast zwei Rechner, einer empfaengt Daten (deiner) und ein anderer
> > sendet. Dort hast du jetzt deinen Download auf 98% der Bandbreite
> > begrenzt? Wie geht das denn?
> > Flusskontrolle bewirkt AFAIK nichts [...]
> Warum soll das nichts bringen ?
> Wenn dein Uplink dicht ist, bleiben die Antwortpakete eines Downloads
> von dir im Uplink-Stau stecken. Durch die nur verzoegert oder nicht
> weitergeschickten Antwortpakete sinkt deine Downloadrate, obwohl noch
> Download-Bandbreite frei waere.

Das meine ich nicht mit Flusskontrolle. Das was du da beschreibst ist ja
genau das Problem: die Packete sind so ungünstig verteilt, dass die
Bandbreite nur in eine richtig wirklich genutzt wird. IdR hat man es ja
umgekehrt, weil man man saugt als hochlädt und wenn man selbst der
Sender ist kann man ja auch selbst entscheiden, was man sendet.

Was ich meinte: Es gibt bei TCP (obwohl es dort ja QOS und TOS,
SourceQuench und Congestion-Control etc. im Prinzip gibt) keine
Möglichkeit als Empfänger dafür zu sorgen, dass bestimmte Packete mit
Priorität behandelt werden. Und damit kommt es dann oft zu dem Problem,
dass der Download die gesamte Leitung verstopft.

> > Oder hast du auch noch Zugriff auf den sendenden Rechner.
> Indirekt ueber die Flusskontrolle halt.

Wenn du beim Download Packete nicht ACKst, dann werden sie nochmal
gesendet. Du musst also beim Verzögern der ACKs sorgfältig sein und
beim Begrenzen der Downlink-Bandbreite wird sowas gar nicht gemacht.

> > Dein Rechner kann doch erst eingreifen und regeln,
> > wenn die Daten schon auf seiner Seite der PtP-Verbindung angekommen sind
> > und dann Daten zu droppen oder in eine Warteschlange einzureihen bringt
> > ja nicht mehr viel.
> Auf bereits empfangene Pakete wirkt sich das ja ansich nicht mehr aus.
> Die "Regelung" geht mehr ueber das zeitliche Mittel.
>
> Damit der Download-Server nicht auf jede Bestaetigung einzeln warten
> muss, gibt es dass von Oliver genannte "Transmissionwindow". Ein Server
> kann schon n Pakete weitersenden, bevor er auf die jeweiligen
> Bestaetigungspakete wartet (n = Fensterlaenge).

Das Problem:
Vom Server kommen zwei Datenströme:
1. Ein normaler Download mit hoher Geschwindigkeit
2. Eine interaktive Session mit wenigen Daten
Vom deinem PtP-Partner werden jetzt viel viel mehr Packete von Strom 1
über die Leitung geschickt (weil die Warteschlange damit richtig
überflutet wird, denn die Verbindung zw. dir und ihm ist ja der
Flaschenhals) und die Packete von Strom 2 stauen sich dann auf dem
Server.

Ideal wäre hier, wenn der PtP-Partner Packete aus dem Strom 2 direkt
versenden würde, z.B. weil sie höhere Priorität haben, oder weil einfach
noch Platz in der Leitung ist (Begrenzung der Bandbreite von 1). Erstere
Lösung wäre natürlich feiner, aber beide lassen sich leider AFAIK nicht
in der Realität (ohne Zugriff auf den PtP-Partner) realisieren.

Gruss
 Christian

-- 
Murphys Law 9:
Jedes Programm, das läuft. ist veraltet.
Jedes fertige Programm kostet mehr und dauert länger.
Jedes nützliche Programm wird geändert.
Jedes nutzlose sofort dokumentiert.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message