[WLANware] Trafficshaping / Zugriff aufs Medium

Uwe Kamper uwekamper at wichte.de
Wed Sep 27 14:23:10 CEST 2006


Hallo!

> -normale Knoten bekommen von den vielen TCP-Verbindungen nichts  
> mit, auf
> dem Funklayer ist nur die grosse Menge an zu übermittelnden IP-Paketen
> pro Zeiteinheit problematisch. Dies führt zu Kollisionen und bremst  
> alle
> Funkteilnehmer aus. Kann sein, dass das interne Packetforwarding einen
> Flaschenhals darstellt.

Das ist allerdings dann kein Unterschied zu einem FTP-Download oder
dem Verschicken eine größeren E-Mail.

> -die vielen TCP-Verbindungen betreffen hauptsächlich die
> Internetgateways, da alles durch die NAT geschleust werden muss. Die
> Frage ist, wo die limitierende Grenze liegt.

Die Grenze wird normalerweise durch den Arbeitsspeicher des NAT-Routers
bestimmt. Der Linux-Kernel reserviert sich automatisch einen Anteil des
Speichers für die Connection-Tracking-Tabelle.

Auf meinem Linksys WRT54G v3.1 mit OpenWRT whiterussian RC5 ist die
Tabelle z.B. 5953 Einträge groß. Ich weiß allerdings nicht, ob dies  
der Wert
ist, den der Kernel automatisch alloziert, oder ob der Wert durch ein  
Skript
verändert wird. Die Größe des Conntrack-Tabelle kann man über das Proc-
Dateisystem  (/proc/sys/net/ipv4/ip_conntrack_max) beeinflussen.

Ein weitere nützlicher Parameter ist die Lebensdauer von TCP- 
Verbindungen.
Der Standardwert dafür sind 5 Tage. Da bei P2P viele Verbindungen auf-
aber nur die wenigsten sauber abgebaut werden, bleiben viele Einträge
sehr lange in der Conntrack-Tabelle hängen. Ich bin bisher mit einer
Lebensdauer von 12 Stunden immer ganz gut gefahren. Das verringert die
Anzahl der Connections in der Tabelle deutlich. (Den Parameter kann  
man hier
beeinflussen: /proc/sys/net/ipv4/netfilter/ 
ip_conntrack_tcp_timeout_established).

> -WLAN-Clients mit DHCP fallen zur Last, indem für sie eine NAT
> durchgeführt werden muss und sie den Funklayer beanspruchen ohne  
> selber
> aktiv beim Routing mitzumachen. Ich stelle mir vor, dass diese zwei
> Punkte einen Knoten ziemlich stark ausbremsen können.

Für den Hotspot-Anwendungsfall (also z.B. ein Café) könnte das OLSR-Netz
sogar entlastet werden, weil nicht so häufig mobile Knoten auftauchen  
und
wieder verschwinden. Die Routingtabelle bleibt also stabil.

> [..] fuehrt zum Ausschluss weiterer
> "Clients", weil der "Filesharer" priorisiert, weil zuerst da, viel zu
> viele Verbindungen offen hat. Ist das soweit richtig?

Richtig, die Filesharer werden am Ausgang ins Internet priorisiert,  
weil sie
viele Verbindungen offen haben. Da TCP so konstruiert ist, dass es die
Bandbreite meistens auf alle Verbindungen fair aufteilt, kommt es dazu
dass Clients mit vielen Verbindungen mehr Bandbreite ins Internet  
bekommen.
(Ich gehe jetzt einfach mal davon aus, dass die Filesharer hauptsächlich
Daten über die HNAs, also mit dem Internet austauschen.)

Vor längerer Zeit gab es hier schonmal einen Thread zu Traffic- 
Shaping für
die Freifunk-Firmware. Ich weiß allerdings nicht genau, was sich danach
getan hat. Gibt es inzwischen ein Plugin für das Traffic Shaping?
Wenn nicht hätte ich bis zum Anfang des neuen Semesters an der Uni
ein wenig Zeit mich damit zu beschäftigen, vielleicht bekommen wir ja
was hin.

Gruß,
Uwe Kamper
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.freifunk.net/pipermail/wlanware-freifunk.net/attachments/20060927/711fafac/attachment.pgp>


More information about the WLANware mailing list