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

[Sven-Ola Tuecke]

Hi,

TCP ist end-to-end. Eine Zwischenstation kann da wenig machen AFAIK. Meine 
Empfehlung: erstmal Westwood und FRTO aktivieren (/etc/sysctrl.conf):

net.ipv4.tcp_frto=1
net.ipv4.tcp_congestion_control=westwood

Westwood bringt am meisten, ab zumindest mit ([xk]ubuntu) muss man dafuer 
den Kernel selber kompilieren und das dabei einschalten. Auf den FF-WRTs 
isses standardmaessig an.

// Sven-Ola

"poelzi" <poelzi at poelzi.org> schrieb im Newsbeitrag 
news:es78si$63t$1 at dirus.intra.poelzi.org...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo,

wir haben ja alle schon erlebt, daß selbst über backbone Strecken die
tcp Datenrate auf Distanz deutlich abnimmt.

Einer der Gründe dafür ist ja, dass tcp sehr schlecht auf jitter
reagiert und ständig mit Packetverlust rechnet, welcher so garnicht
vorhanden ist.

Es gibt natürlich bessere TCP Implementierungen, die dieses Problem
nicht so sehr haben, aber da TCP Senderseitig ist, müsste man ja das
ganze Internet umstellen.... Keine guten Aussichten (ja, proxy geht auch
etc)

Nun kam mir eine ganz lustige Idee, es währe doch möglich, ein ipfilter
modul zu schreiben, welches die Roundtrip Time des TCP analysiert. Und
einen künstlichen Ausgleichs Delay einfügt.

schauen wir mal einen typischen Ping an:

PING 104.61.80.1 (104.61.80.1) 56(84) bytes of data.
64 bytes from 104.61.80.1: icmp_seq=1 ttl=60 time=20.7 ms
64 bytes from 104.61.80.1: icmp_seq=2 ttl=60 time=5.82 ms
64 bytes from 104.61.80.1: icmp_seq=3 ttl=60 time=34.0 ms
64 bytes from 104.61.80.1: icmp_seq=4 ttl=60 time=30.0 ms
64 bytes from 104.61.80.1: icmp_seq=5 ttl=60 time=54.7 ms
64 bytes from 104.61.80.1: icmp_seq=6 ttl=60 time=13.0 ms
64 bytes from 104.61.80.1: icmp_seq=7 ttl=60 time=55.8 ms
64 bytes from 104.61.80.1: icmp_seq=8 ttl=60 time=28.9 ms
64 bytes from 104.61.80.1: icmp_seq=9 ttl=60 time=8.33 ms
64 bytes from 104.61.80.1: icmp_seq=10 ttl=60 time=18.6 ms
64 bytes from 104.61.80.1: icmp_seq=11 ttl=60 time=29.0 ms
64 bytes from 104.61.80.1: icmp_seq=12 ttl=60 time=16.6 ms
64 bytes from 104.61.80.1: icmp_seq=13 ttl=60 time=59.2 ms

starke Schwankungen über mehrere Hops. Der Filter würde nun sehen, ahh,
starke Schwankungen.
rtt min/avg/max/mdev = 5.826/30.724/64.849/18.250 ms

Er berechnet nun z.b. (min(rttmax,100)-rttavg)/2 oder so, und verzögert
alle einkommenden Packete, daß sie diese rtt haben.
TCP setzt darauf hin die Puffer größer, aber vermutet nichtmehr
Packetverlust, falls Packete mal etwas länger auf sich warten lassen.

Was haltet ihr davon ?

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

iD8DBQFF5ybSy/mkIQp7AD0RAiuaAJ9Y0FNC9S2DzKGcxLItlFK4hG25IwCeJDct
YZSW54zYrBpGsYCRJRNbesA=
=UhQv
-----END PGP SIGNATURE-----
_______________________________________________
WLANware mailing list
WLANware at freifunk.net
Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlanware

Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung 
unter http://freifunk.net/mailinglisten