[WLANware] ANN: meshferry - tcp be gone

[poelzi]

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

thoralf wrote:

> ich war, so rein intuitiv, immer der meinung, dass ip in verbindung mit
> tcp als so einer art flußkontrolle schon recht effizient und effektiv
> wäre: ein paket wird halt so lange neu übertragen, bis es seinen
> empfänger tatsächlich unversehrt erreicht hat. was sollte da (abgesehen
> von multicasts) noch besser gehen? imho bringt jede implementierung
> einer fehlerkontrolle oberhalb von verbindungslosen verbindungen (hehe
> :-) mindestens denselben protokoll-overhead wie tcp mit sich.

1. problem: tcp ist rein senderseitig. es gibt tcp implementierung die
besser geeignet sind als andere, z.b. westwood. jetzt mußt du nur noch
jedem im inet dazu überreden westwood zu benutzen.

2. problem: tcp mag kein packet reordering. ein kurzer test über 3 hops
hat schon gezeigt, daß packete total durcheinander ankommen

3. problem: tcp hängt stark mit der latenz zusammen. stetige latenz ist
ok, dann werden die puffer vergrößert und gut ist, bei uns schwankt die
latenz aber enorm.

PING 104.61.71.1 (104.61.71.1) 56(84) bytes of data.
64 bytes from 104.61.71.1: icmp_seq=1 ttl=58 time=1180 ms
64 bytes from 104.61.71.1: icmp_seq=2 ttl=58 time=181 ms
64 bytes from 104.61.71.1: icmp_seq=3 ttl=58 time=25.6 ms
64 bytes from 104.61.71.1: icmp_seq=4 ttl=58 time=68.9 ms
64 bytes from 104.61.71.1: icmp_seq=5 ttl=58 time=24.6 ms
64 bytes from 104.61.71.1: icmp_seq=6 ttl=58 time=48.4 ms
64 bytes from 104.61.71.1: icmp_seq=7 ttl=58 time=53.5 ms
64 bytes from 104.61.71.1: icmp_seq=8 ttl=58 time=21.9 ms
64 bytes from 104.61.71.1: icmp_seq=9 ttl=58 time=25.6 ms
64 bytes from 104.61.71.1: icmp_seq=10 ttl=58 time=25.2 ms
64 bytes from 104.61.71.1: icmp_seq=11 ttl=58 time=23.3 ms
64 bytes from 104.61.71.1: icmp_seq=12 ttl=58 time=83.1 ms
64 bytes from 104.61.71.1: icmp_seq=13 ttl=58 time=40.7 ms
64 bytes from 104.61.71.1: icmp_seq=14 ttl=58 time=36.8 ms
64 bytes from 104.61.71.1: icmp_seq=15 ttl=58 time=213 ms
64 bytes from 104.61.71.1: icmp_seq=16 ttl=58 time=106 ms
64 bytes from 104.61.71.1: icmp_seq=17 ttl=58 time=39.2 ms

sowas gibts im normalen netz nicht, da tcp ja irgendwie erkennen muß ob:
- - leitung voll
- - packet verloren
- - packet noch unterwegs

und das stark vom RTT (roundtriptime) abhängt, macht das nicht immer
sinnvolle entscheidungen. retransmits z.b. obwohl das packet einfach
noch in irgendeinem puffer liegt...

wir haben andere eigenschaften in unserem netz. packetloss tritt außer
bei wirklich schlechten verbindungen eigendlich nicht wirklich auf, da
wlan selbst ein ack implementiert.

tcp ist an sich ist schon ok, aber ist eben nicht für ad-hoc netze
gemacht, damals gabs sowas nicht :)

ich denke da lässt sich einiges testen mit anderen arten von ack und
flusskontrollen, mal schauen ob sich was tolles draus ergibt. ganz zu
schweigen von multicast streaming etc. z.b. könnte man ein non continues
tcp (was für ein paradoxon) damit implementieren, da mp3 oder ogg
streams durchaus damit klar kommen wenn mal ein paar bytes fehlen
sollten anstatt gleich einen verbindungsabbruch durchzuführen...

für ack hab ich mir schon folgendes überlegt:
bei datentransfer sind die packete ja meist nahe dem mtu, dann werden
nur gruppen acks gesendet und ziemlich große puffer benutzt. sind die
packet klein, handelt es sich wahrscheinlich um interaktiven transfer
und packete werden öfters quittiert. vielleicht sollte man auch etwas
messtatistisch an die sache rangehen und messen wie stark die packete
durcheinander ankommen bei jeder verbindung und davon die puffergrößen
abhängig machen.

PS: diskussion wird auf freifunk.de.firmware weitergeführt ;)

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

iD8DBQFGbermy/mkIQp7AD0RAsjXAKDHHwFpVQlRNDzX3jm/eM4/+A526QCbBipr
oYs1iatL2n096n0rFef0pz0=
=I+i/
-----END PGP SIGNATURE-----