[WLANware] warum TCP-Pacing und ein Loesungsansatz

[dirk]

hallo,

ich nutze das Thema nicht mehr für zu meinen Abschluß, da ich mit der
C-Programmierung nicht weiter voran kam. Dennoch möchte ich gerne die
Gründe für TCP-Pacing und die Lösungsansätze aufzeigen, vielleicht will
sich jemand der Sache annehmen.

Warum: TCP-Traffic wird durch häufiges Paketloss (wir haben ein häufiges
Paketloss an Nodes nach dem GW zwischen leitung -> funkmedium, an Nodes
welche viele Routen auf sich vereinen und weitere Sonderfälle) sehr
"Bursty" quasi ein ständiges Auf- und Ab der Übertragungsrate, in einem
Diagramm dargestellt als ein Sägezahn. Würde man nun Wege finden dieses
"bursty"-Verhalten auf ein Minimum zu reduzieren, also die Varianz der
Übertragungsrate möglichst klein hält würde dies letztlich in der Summe
zu einem höheren Durchsatz führen, da primär der Overhead durch
Retransmissions reduziert wird (damit Verbunden auch die Wartezeiten auf
die Timeouts). Vorallem bei long-term TCP Verbindungen würde dies
merklich die Übertragung steigern)

die Idee ich sende nicht alle Pakete am GW einfach weiter - und sorge so
für Verstopfungen auf den nachfolgenden Nodes sondern warte bis die
Pakete zumindest 2 Hops weiter sind, somit behinderen sich
aufeinanderfolgende Pakete nicht gegenseitig und dem Sender wird durch
längere RTT ein langsamer Kanal signalisiert, so daß er seine Senderate
runterfährt.
http://www.cs.washington.edu/homes/tom/pubs/pacing.pdf
http://www.cs.caltech.edu/~weixl/research/summary/infocom2006.pdf


Wie: Eine dynamische Verzögerung am GW zwischen leitung und funk, welche
die TCP-Pakete ins Funkmedium verzögert um die Faktoren Hopzahl und der
RTT im Funkmedium. Konkret beschrieben hier:
http://rvs.informatik.uni-leipzig.de/de/publikationen/papers/TCP-GAP-MSWiM06.pdf


Lösungsansätze: Mittels Skript würde ich es  wohl testweise hinbekommen.
Dienlich sind folgende Programme:

TC ist ein im Kernel-implementiertes Traffic Control um Pakete nach
verschiedenen Kriterien in auch verschiedene Warteschlangen-Mechanismen
zu packen und zu behandeln. Hier brauchen wir nur eine gewisse Zahl an
Paket-FIFO's, deren Anzahl ergibt aus der Nodes welche den Gateway auch
nutzen. Leider gibt es keine "Verzögerungswarteschlange"

NETEM ein Zusatzmodul zu TC eigentlich zur Netzwerk-Emulation kann aber
auch Pakete verzögern, Verzögerungswert kann per tc update-Option
dynamisch gestalltet werden.

ULOG aus dem netfilter/iptables-Paket muß jedes TCP-Paket anschauen und
 für jedes Ziel bzw. für jeden Sender zu/von einem Node die
Sequenznummer sich merken um dann die RTT im Funkmedium aus dem
Eingangszeitstempel und zwei nacheinanderfolgenden  Sequenznummern zu
bestimmen, quasi so:

I-net -> TCP-Paket mit Seq-Nr n  (DATA) -> Ziel-Node/ein Client vom Node
    	Ankunftszeit t1

I-net <- TCP-Paket mit Seq-Nr n+1 (ACK) <- Ziel-Node/ein Client vom Node
	Ankunftszeit t2

RTT-wireless=t2-t1	dies ist das Wichtigste deswegen so ausführlich.

Weitere Information ergibt aus der Paketgröße und Zeit -> Bitrate
TCP-Netto-Bandbreite = Summe Bitraten...alles natürlich angenäherte
Werte, determiniert ist bei der verbindungslosen Paketübertragung aber
eh kaum was.

Aus der Routing-Table würde ich dann noch die Hopzahl betstimmen.


Besser wäre: ein Kernel-Modul was direkt mit dem sk_buff.h arbeitet,
leider weiß nicht wie damit umgehen. Wie ich damit das Aussenden der
Pakete steuern kann. Darüber hinaus gibt es dann auch noch andere
Möglichkeiten welche z.B. doch auf TC zurückgreifen aber die benötigten
Daten sich dann direkt aus den Lib's holen. libpcap z.B. dafür gibt es
sogar auch eine Phyton-Lib - nur ist Phyton auch nicht einfach für mich.


Wäre schön wenn sich jemand der Sache annehmen kann, ich würde auch
gerne mithelfen und beim C-programmieren mit Linux dazu lernen, da mir
bei dem theoretischen Vorgeplänkel noch weitere Ideen gekommen sind um
den "Flow zu verbessern"


Dirk