[WLANware] warum TCP-Pacing und ein Loesungsansatz

[Daniel Nitzpon]

gibt es denn das testskript? wenn ich das richtig verstehe, muss es ja 
nur auf dem gateway laufen. warum also nicht mal einen desktop (falls 
openwrt oder ram/cpu da mucken) vor ein gateway hängen, und schauen, was 
als skript passiert? zur veröffentlichung müsste das doch erstmal 
reichen, und wenns gut funktioniert findet sich dann ja vielleicht auch 
jemand, der's mal codet.

dirk schrieb:
> 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