a me la soluzione dell'ipv6 pubblico senza troppe complicazioni convince di piu'...<br>Tra l'altro qui a Pisa gia' la mesh e' tutta ipv6<br><br>secondo tentare di usare piu' adsl per aumentare la banda non e' cosi' comune come setup e sbattersi la testa per qualcosa che poi va fatto ogni volta a mano non ne vale la fatica<br>
<br><div class="gmail_quote">Il giorno 06 luglio 2010 23.55, Darkman <span dir="ltr"><<a href="mailto:darkman@darkman.it">darkman@darkman.it</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
L'asimmetria delle ADSL che ben conosciamo strozza il goodput in downstream<br>
a causa dell'Ack appesantito.<br>
Pur usando UDP come trasporto per il tunnel, l'ack "pesante" del TCP<br>
tunnellizzato saturerebbe<br>
l'upstream con un modesto traffico. Non ci credevo nemmeno io finché non<br>
l'ho visto. Ebbene, quei 384Kbps<br>
d'upstream che ci danno sono appena sufficienti a mantenere il traffico di<br>
acknowledgment<br>
di una sessione TCP a 8Mbps, ne consegue che se appesantisci l'ack ti<br>
strozzi il downstream,<br>
vai in congestione e tutto diventa una merda.<br>
<br>
Soluzioni? Ne ho pesate diverse, ma non ne ho implementata/trovata nessuna,<br>
non posso rubare altro tempo<br>
alla mia vita sociale, per cui aspetto che qualche nerd lo faccia al posto<br>
mio, nel pieno dello spirito open source :)<br>
<br>
1) per ridurre il traffico di acknowledgment ci sono due vie:<br>
riduci il numero degli ack (ma va?) -> aumentando l'MSS (con conseguente<br>
aumento dell'MTU),<br>
ma, ovviamente, devi abbandonare UDP come trasporto per tunnel.<br>
A questo punto, la folle idea di usare TCP non sarebbe + tanto folle. Anche<br>
se incrementeresti<br>
il numero di ack (leggeri) ridurresti di gran lunga quelli pesanti,<br>
recuperando un bel po' di banda.<br>
2) Van Jacobson (RFC 1144), situazione ideale.<br>
<br>
Cmq, ci sono altri aspetti da considerare che rendono complicato "sommare"<br>
la banda.<br>
Primo fra tutti il jitter.<br>
Immagina 2-3 adsl, ognuna con le sue tempistiche, mandi 3 pacchi<br>
round-robinnati o con qualunque<br>
altre politica fica, come credi che si comporteranno gli algoritmi di<br>
controllo della congestione TCP? -> Goodput a puttane.<br>
<br>
Per cominciare potreste prendere un server in tedeschia a 4 lire e<br>
tunnellizzare tutti li..<br>
<br>
--------------------------------------------------<br>
From: <<a href="mailto:reiser4@gmail.com">reiser4@gmail.com</a>><br>
Sent: Tuesday, July 06, 2010 11:13 PM<br>
To: <<a href="mailto:wireless@ml.ninux.org">wireless@ml.ninux.org</a>><br>
Subject: [Ninux-Wireless] R: Re:  la VPN in tutta Italia<br>
<br>
> Idee migliori? Alternative?<br>
><br>
><br>
><br>
> -- msg. originale --<br>
> Oggetto: Re: [Ninux-Wireless] la VPN in tutta Italia<br>
> Da: "Darkman" <<a href="mailto:darkman@darkman.it">darkman@darkman.it</a>><br>
> Data: 06/07/2010 22:57<br>
><br>
> Non lo fai. Se vuoi una soluzione __trasparente__ devi tunnellare il<br>
> livello 2.<br>
> Cmq pagheresti un prezzo alto in termini di traffico acknowladgment,<br>
> lasciando perdere l'overhead.<br>
><br>
><br>
> _______________________________________________<br>
> Wireless mailing list<br>
> <a href="mailto:Wireless@ml.ninux.org">Wireless@ml.ninux.org</a><br>
> <a href="http://ml.ninux.org/mailman/listinfo/wireless" target="_blank">http://ml.ninux.org/mailman/listinfo/wireless</a><br>
><br>
_______________________________________________<br>
Wireless mailing list<br>
<a href="mailto:Wireless@ml.ninux.org">Wireless@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/wireless" target="_blank">http://ml.ninux.org/mailman/listinfo/wireless</a><br>
</blockquote></div><br>