Ich meinte nicht, daß die FRITZ!Box da irgendwie "active queue management" macht ... da sie kein Core-Router ist, halte ich das auch für unwahrscheinlich.
Zu "UDP ist UDP":
Das meinte ich auch nicht wirklich ... ich dachte/denke eher daran, daß die Mechanismen einer über das UDP getunnelten TCP-Verbindung dort zum Tragen kommen und die FRITZ!Box ist ja - wenn ich das richtig verstehe - an der ganzen Sache nicht beteiligt, ausschließlich als Router. Das Ein- und Auspacken übernimmt ein Client hinter der FRITZ!Box, oder?
Außerdem lasse doch mal den iperf-Test für UDP-Pakete mit voller Bandbreite laufen bzw. gib eine Rate an, die weit über der theoretischen Kapazität des Tunnels liegt (sagen wir mal 200%), damit man auch eine Regelwirkung des Tunnels erkennen kann. Bisher begrenzt Du ja selbst auf 20 MBit/s, da wäre dann u.a. auch die Frage, wie schnell die VPN-Endpoints mit Ver- und Entschlüsseln sind (auch wenn sie bei Tunnel über UDP 53 die Rate schaffen, das nehme ich zur Kenntnis). Mach doch einfach mal (wenn Du das 60 Sekunden laufen läßt) auch alle 2 Sekunden ein Reporting, damit man das geschilderte Phänomen des abnehmenden Durchsatzes auch sieht. Wenn das bei UDP auch auftritt, muß es ja von außen kommen, da gibt es die Mechanismen von TCP ja nicht. Wenn das bei UDP einheitlich derselbe Durchsatz ist, begrenzt ein anderer Faktor den Durchsatz, was dann mit einiger Wahrscheinlichkeit aber auch auf zwei unterschiedliche Ursachen zurückzuführen ist. Auch für TCP wäre mal ein iperf-Test mit Reporting in Intervallen interessant, einfach damit man sieht, ob das ein plötzlicher Abriß ist oder ob das schleichend bis zu dem von Dir beobachtenen Wert heruntergeregelt wird.
Die Ausgabe des ersten Kommandos verstehe ich ohnehin nicht ... bist Du da event. nur mit dem Kopieren in den Beitrag durcheinander gekommen? Das erste Kommando macht ja TCP (-u fehlt, oder hast Du einen iperf-Client, der auch ohne -u UDP verwendet?) und der Report dahinter sagt eindeutig UDP Port 5001.
Irre ich mich oder ist der letzte Wert (bzw. die zwei letzten und damit die "58%") bei der ersten Ausgabe die Paketverlust-Rate? Ich habe die iperf-Ausgabe gerade nicht im Kopf und bin auch zu faul, da jetzt nachzusehen (bzw. das habe ich gemacht, aber nur Beispiele für TCP gefunden, wo es keine Verluste gibt, weil eben Retransmissions erfolgen) oder selbst mit UDP zu testen ... aber die andere Verbindung hätte dann (wenn meine Interpretation stimmt) nur geringe Paketverluste, was mit anderen DSCP-Tags ja ohne weiteres zu erklären wäre.
Die FRITZ!Box kann ja nur ausgehenden Traffic regulieren (und im Rahmen von TCP über L4 in gewissen Grenzen den Downstream, aber auch nur dann, wenn sie selbst Endpoint ist), auch wenn sie intern (meiner Erinnerung nach und eine 7412 zum Nachsehen habe ich jetzt nicht) UDP 53 schon priorisiert bzw. zumindest eine gesonderte Queue dafür benutzt. Das findest Du in den Support-Daten oder über Telnet irgendwo über das proc-Interface des kdsdl (cat /proc/kdsld/dslifaces/internet und irgendeine dort vorhandene Pseudo-Datei). Wenn es tatsächlich die FRITZ!Box wäre, die da (dann eher unabsichtlich) "bremst", dann könnte man mal versuchen, eine identische Rule wie für "normales DNS" testweise per ar7.cfg für den vom Tunnel verwendeten Port zu setzen und sich das Ergebnis dann ansehen (geht über GUI nicht, bleibt dann immer noch anders, wenn ich mich richtig erinnere). Glaube ich aber auch eher nicht ... solange es nicht an anderen TOS-Werten in den IP-Paketen liegt, die dann von der Infrastruktur zwischen (VPN-)Server und (VPN-)Client so ausgelegt werden, daß der beobachtete Effekt auftritt.
Spannend wäre ja auch noch, wie sich denn nun der Tunnel verhält, wenn man die MTU (die derzeit eine resultierende Paketgröße von 1470 (lt. iperf) ergibt) einfach mal um 100 Byte heruntersetzt ... zwar verschenkt man dann vielleicht Kapazität, aber es sollte dann definitiv 1:1 eine Umsetzung eines unverschlüsselten in ein verschlüsseltes Paket ermöglichen. Wenn nämlich bei Deiner Messung die Pakete so groß sind, daß aus einem unverschlüsselten iperf-Paket immer zwei (fragmentierte) VPN-Pakete entstehen, dann hast Du die doppelte Anzahl von Paketen für den Tunnel und - da die auf Empfängerseite ja wieder defragmentiert werden müssen - auch eine entsprechende Verzögerung.
Das erklärt zwar die Abhängigkeit vom UDP-Port des Tunnels auch noch nicht, aber da gedroppte UDP-Pakete für DNS-Abfragen bei den Kunden ja extreme Phänomene hervorrufen (das braucht dann erst einmal ein Timeout und eine zweite Anfrage seitens des Clients, bis da z.B. irgendeine HTTP-Seite aufgerufen werden kann und das stößt den Kunden als "bemerkte Reaktionszeit" natürlich sauer auf), könnte ich mir vorstellen (nicht mit wissen verwechseln), daß seitens des Providers eben doch andere Vorkehrungen getroffen werden bzw. auch, daß die FRITZ!Box ihrerseits bereits ausgehenden DNS-Traffic (also die IP-Pakete) mit anderen DSCP-Werten taggt. Auch da hilft wieder der Packet-Dump ... sehe ich auch nicht als letzten Ausweg/letzte Lösung, weil es eben viele Aspekte aus dem Bereich der Spekulation und der "Annahme" in die Kategorie "gesicherte (empirische) Erkenntnisse" befördern kann.
Die ganze Rechnung bzgl. der MTU des Tunnels kann man auch nur nachvollziehen bzw. überprüfen, wenn man das eingesetzte VPN kennt (damit den dort verursachten Overhead) und auch die verwendete Technologie beim Anschluß der FRITZ!Box, weil natürlich das PPPoE beim 1&1-DSL-Anschluß auch noch einmal 8 Byte für den entsprechenden Header braucht. Wäre also schön, wenn das noch einmal explizit "aufgeklärt" wird, bisher ist das alles nur als deduktiver Schluß aus der Box in der Signatur möglich und auf welcher Basis ein "Freifunk-Tunnel" arbeitet, muß man auch erst selbst nachsehen. Das macht es (den anderen Lesern des Threads, ggf. auch erst in 5 Jahren, wenn beim Freifunk vielleicht schon ein ganz anderes Projekt das VPN macht) nur unnötig schwer, die Zusammenhänge zu recherchieren.
EDIT: Um das noch einmal deutlicher zu schreiben ... wenn das mit den Paketverlusten tatsächlich stimmt (einmal 58% und nur 0,14% über den DNS-Port), dann treten die eigentlichen Verluste natürlich nicht in der getunnelten Verbindung auf. Die verlorenen Pakete gehören dann zum Tunnel und während eben eine über den Tunnel aufgebaute TCP-Verbindung dann wegen der TCP-Sicherungsschicht zu erneuten Übertragungen (mit entsprechenden Auswirkungen auf den Durchsatz) greifen wird, hat UDP solche Mechanismen nicht und deshalb ist ein verlorenes Paket eben verloren - was sich dann auch in der getunnelten UDP-"Verbindung" manifestiert. Die Verlustrate wird m.E. errechnet, indem am Ende des Tests der Server befragt wird, wieviele Pakete er gesendet hat und das mit den am Client eingetroffenen Paketen verglichen wird.
