[Berlin-wireless] RTS/CTS - geeignete Lektüre

[elektra]

ich möchte das papier ja ungern jetzt nochmal zusammenfassen. in einem satz:

die implementierung von rts/cts für 802.11 taugt nicht fürs mesh, 
medienzugriff glücksache

was wunder: es wurde nicht für den einsatz in einem multihop-grid entwickelt

prinzipiell ist der einsatz von rts/cts wünschenswert. aber: ein 
taucher, der nicht taucht, taucht nix. wie es aussieht schadet der 
einsatz bedeutend mehr als es nützt: zusätzliche pakete werden 
verschickt - als resultat werden die sender fälschlicherweise geblockt, 
gehen fälschlicherweise in den exponentional backoff, das desaster kann 
ein netz - zumindest partiell - fluten und im schlimmsten fall kommt es 
zeitweise zum deadlock. es gibt nur ein sinnvolles szenario wenn man dem 
papier glauben schenken darf: ein mesh mit maximal zwei hops

mag sein, dass 'da draussen' implementierungen rumschwirren, die sich 
nicht an den standard halten - das kann sich dann ausnahmsweise mal 
positiv auswirken.

und: ich habe keine intensive feldforschung betrieben. ich habe 
lediglich für das mesh-buch recherchiert und mir deshalb die papiere 
angesehen. die schlussfolgerungen finde ich einleuchtend und die 
resultate vom roofnet halte ich für überzeugend

dass 'ICMP irgendwie immer durchgeht'  sollte zu denken geben - kein 
wunder, sind ping-pakete doch üblicherweise 64 byte klein und bemühen 
rts/cts nicht

ich gehe davon aus, dass man mit möglichst kleiner fragmentation und 
ohne rts augenblicklich am besten 'fährt'.

cu elektra
> hm... - ich hab das roofnet-paper leider immer noch nicht gelesen - und
> ja RTS/CTS macht viele Nodes im Umkreis erstmal dicht, aber ist es nicht
> auch das was wir wollen um sicherzustellen das jenes Datenpaket welches
> wir übertragen wollen nicht durch unsere eigenen Übertragungen auf
> Nachbarnodes stören wollen?
>
> RTS/CTS behindert zwar auch TCP da es verzögert, aber was verzögert mehr
>    bzw. wie sind die Wahrscheinlichkeiten verteilt das mein TCP-Paket im
> zweiten, dritten ... Versuch durch geht und bevor ich eine
> TCP-Retransmission habe, hatte ich entweder ein TimeOut vom TCP oder
> 7mal Paketloss vom MAC. Bzw. wo ist die RTT höher mit RTS/CTS oder ohne?
>
> Und hier beginnen dann auch Details...da ICMP irgendwie immer durch
> geht, aber selbst ein TCP-SYN auf der selben Verbindung ein vielfaches
> der ICMP-RTT besitzt. (wie hoch der Fehler von zwei mit NTP-gestellten
> Rechnern ist hab ich jetzt berücksichtigt) für die folgenden TCP-Pakete
> siehts dann noch schlechter aus. Dann hab ich RTS/CTS  eingesetzt und
> zumindest die Retransmissions minimiert.Und dann hab ich auch noch
> BATMAN, welches Overlay lief abgeschaltet, und es ward noch besser.
> (also UDP-Dauerrauschen verringert)
>
> Anderseits hab ich ohne RTS/CTS in einer relativ Nodebefreiten Umgebung
> eingesetzt auch sehr gute Durchsatzraten erzielen können.
>
> Es ist halt so eine Abwägungssache wo macht es Sinn wo nicht, wir haben
>  (zumindest in Leipzig) keine homogene Netzstruktur hinsichtlich der
> Lastverteilung, Auslastung usw. und ich denke ein dynamischer Ansatz ist
> da recht gut.
>
> Es gibt da TCP-GAP [1] was die RTT im wireless Bereich bestimmt und
> eingehende TCP-Pakete mit einer zusätzlichen Warteschlange am
> Wire<->Wireless-Gateway belegt und dynamisch den Abfluß ins Drahtlose
> bestimmt (Leaky Bottle)...was zumindest in Simulationen gut wegkommt,
> wie alles ;-) aber dies muß/ist ja nicht die Lösung sondern
> gemeinsam/Diskussion überlegen was noch alles Relevanz hat, das wäre
> halt so mein Ideal für Samstag. Wobei der Überraschungseffekt jetzt
> schon weg ist und ich viel hier schon erzählt hab.
>
>
> Dirk
>
>
> [1]
> http://rvs.informatik.uni-leipzig.de/de/publikationen/papers/TCP-GAP-MSWiM06.pdf
>
> PS: ich habe hier keine Aktien dran, ich bin an einer FH und schreibe -
> ohne in dieser Forschungsgruppe involviert zu sein - über die
> Realisierung/Implementierung von TCP-GAP mein Diplom. Ich darf aber ihr
> Paper verwenden und hoffe natürlich das die Forschungsgruppe mich dann
> als wiss. Mitarbeiter einstellt.
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>
>