[WLANware] Hässlicher workarround für tcp ?

[Daniel Poelzleithner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Morlang wrote:

> http://rvs.informatik.uni-leipzig.de/de/publikationen/papers/TCP-AP_MobiHoc05.pdf 
> ist doch die annahme, das paketloss nur durch uebergelaufene puffer 
> entsteht und man dann langsamer senden muss, einer der gruende, warum 
> tcp im mesh nicht performed.
> Wie realistisch ist es, das sie mit der arbeit recht haben? Liesse sich 
> das implementieren?

Ich hab die arbeit jetzt nicht gelesen, aber ja. Das ist eigendlich die
TCP annahme. TCP berücksichtigt ersten nicht wo die packetloss auftritt,
und zweitens muß man packetloss ja auch erkennen.
Und letzteres ist unser Problem. TCP ermittelt packetloss nach
wartezeiten. Kein Packet, ok, nicht angekommen nochmal, wieder nicht
angekommen, ok ich warte und sende nochmal. Das ganze hängt sehr stark
von der RTT ab, denn ich muß ja mindestens eine RTT warten bis ich die
antwort bekommen. (hier spielt jetzt auch die windowsize eine rolle. Je
länger ich warten muß, muß ich einen puffer der größe RTT*Bytes/s haben
um bei einem Verlust das packet nochmal senden zu können.)
Die jeweilige TCP implementierung unterscheidet nun aus diesen
Parametern RTT, Loss bissher, mögliches Empfangswindow (das sind z.b.
die parameter in /proc/sys/net/ipv4 ), etc die maximale Geschindigkeit.
Mit was eigendlich keine Implementierung rechnet, ist das RTT bei
unserem Mesh extreme Schwangunkungen hat.
Und dazu noch das Problem: Sender entscheidet. Was bringt uns jetzt ein
tolle TCP Implementierung die im Mesh super funzt. Wollt ihr das
komplette internet umstellen oder proxy benutzen müssen ?
(sowas haben wir hier z.B. um westwood beim surfen benutzen zu können).

Nun, darum würde ich gerne einfach versuchen den Effekt des schwankenden
RTT garnicht auftretten zu lassen und mit einem zusätzlichen Puffer dem
völlig normalen TCP Server vorzugaugeln: He, der host hat keine Loss,
ist halt einfach ein bisschen weiter weg (ping höher, aber packetloss
gering). TCP stellt daraufhin das window größer und die daten gehen
schneller durchs netz und weniger Retransmits und damit auch weniger
Netzbelastung.

Klingt doch logisch oder ?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF73Qny/mkIQp7AD0RAn+aAKCdmcC+r3lKMAB0TzENrn5a6c2z5ACfekl2
5++Y7yY6/0Q5fHjxu5dQmZU=
=uyu7
-----END PGP SIGNATURE-----