[Berlin-wireless] Foo-over-UDP (FoU) oder L2TP+Tunneldigger als Alternative zu OpenVPN für VPN03, c-base heute

[Philipp Borgers]

On Tue, Mar 01, 2016 at 02:01:18AM +0100, Bastian wrote:
> Hi,
> 
> Am 2016-02-29 22:12, schrieb Justus Philipp Beyer:
> > Nochmal hi,
> > 
> >> On 24.02.2016, at 15:25, Bastian <fly at d00m.org> wrote:
> >> 
> >> Das kann sicherlich ggf. Lynxis beantworten.
> >> Diese Frage sollte aber erst gestellt werden, wenn es konkrete 
> >> Argumente
> >> gegen L2TP und gleichzeitig für ein anderes Tunnel-Protokoll gibt. Das
> >> ist AFAIK momentan noch nicht der Fall.
> > 
> > Doch, die gibt es. VPN03 soll den IP-Verkehr der Clients mit einer
> > Absender-IP-Adresse des Fördervereins ins Internet zu leiten, das ist
> > der Zweck des Dienstes. Diese IP-Pakete sind Layer 3, welche
> > MAC-Adressen die Clients haben, müssen wir zu diesem Zweck hingegen
> > nicht wissen.
> 
> Völlig richtig. Wir wollen in erster Linie 4 Byte Absender-IP ersetzen.
> Und evtl wollen wir sogar mal IPv6 unterstützen.

Ist Teil des Plans.

> Wie sieht das denn mit so Sachen wie router advertisements und
> prefix-delegation aus? Zumindest typische IPv6 Konzepte sollten wir im
> Hinterkopf behalten.

Hängt wohl von der Art des Tunnels ab, ob wir das nutzen können. Ich sehe aber
auch kein Problem darin, wenn der Client einen Präfix vom Server per
Control-Channel gepushed bebekommt.

> > Der Overhead, den wir auf Paketen anbringen, um sie auf dem Weg zu
> > unseren VPN-Servern und zurück durch das Internet zu transportieren,
> > muss so klein wie möglich sein: Ein paar Bytes Header mehr oder
> > weniger machen auf den ersten Blick in Relation zu Paketen mit einem
> > Kilobyte an Daten oder mehr nicht viel aus. Tatsächlich werden aber
> > bei typischer Nutzung zahllose sehr kleine Pakete - DNS,
> > IP-Handshakes, NTP, VoIP - übertragen und auf jedes dieser Pakete
> > kommen nun die zusätzlichen Tunnel-Header-Bytes.
> 
> Wie sehen denn die Header-Overheads bei den getesteten Technologien im
> Vergleich aus?

Vielleicht mal in den RFC gucken und Bytes zählen? Aus Justus Blog-Eintrag lässt
sich auch einiges schließen.

> > An einem Standort wie der NUK Mertensstr. werden etwa 1.000 Pakete pro
> > Sekunde pro Richtung übertragen. Sagen wir, wir könnten IPIP-Tunnel
> > nutzen und würden lediglich 20 Bytes an Extra-IP-Headern an ein
> > einzelnes Paket anhängen, dann kommen allein durch diese 20 Bytes pro
> > Paket in der Summe etwa 156 Kbit/s an Traffic zustande. Da der
> > Anschluss dort im Upstream nur 2 Mbit/s schnell ist und wir mit
> > OpenVPN nicht nur einen weiteren IP-Header anhängen, sondern mehr,
> > verursacht schon allein der Tunnel-Overhead eine Bandbreitenauslastung
> > von deutlich über 10%. Je mehr Nutzer über eine so schmale Verbindung
> > surfen, desto schlimmer wird das Verhältnis zwischen Nutzdaten und
> > Übertragungs-Overhead.
> 
> 2mbps Upload ist natürlich durchaus realistisch. Aber rechne ich
> richtig, wenn ich nun behaupte das 'nur' 1/13 bzw. 7.7% vom Upload bei
> Linespeed für den Tunnel drauf gehen?
> Wie sieht denn unser typical internet-mix eigentlich aus? Haben wir
> echte Daten bzgl der statistischen Verteilung von Packet-Sizes beim
> momentanen vpn03?

Nein. Wenn jemand einen Vorschlag macht wie wir die erheben können, kann ich die
mal erheben.

> Cheers, Bastian

> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> Diese Mailingliste besitzt ein ?ffentlich einsehbares Archiv

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160301/910bb5a3/attachment.sig>