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

[dirk]

elektra schrieb:
> 
> 
> Welches Routingprotokoll verwendet wird ist nicht das Thema. Die
> Probleme beim Medienzugriff sind auch da, wenn alles statisch
> eingetragene Routingtabellen wären. Bis zwei Hops funktioniert RTS/CTS,
> darüber hinaus ist es ein Krampf. Jedenfalls solange es nicht mit einer
> Überwachung arbeitet, ob der angeblich reservierte Kanal tatsächlich
> verwendet wird.

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.