Re: [Ninux-Wireless] ICaaS
On 26/12/2016 15:52, Darkman wrote: Non conosco questa soluzione, ma, a naso, credo che non faccia al caso nostro. TCP? Hai link? https://www.multipath-tcp.org/ Una volta un utente Ninux dentro l'isola di Roma aveva necessita' di fare upload su Vimeo e chiedeva se poteva utilizzare una connettivita' piu' veloce rispetto la sua ADSL di qualcun altro attraverso la Rete Wireless. Gli e' stato risposto che era possibile utilizzare il Multipath TCP all'interno di Ninux per questo. Utilizza tutta la banda in download o upload di tutte le connessioni internet messe a disponizione all'interno di Ninux per avere quella velocita' necessaria al trasferimento di file pesanti. L'unica limitazione e' che non lo puoi utilizzare con servizi che per loro natura si aspettano di trovare pacchetti che arrivino solo da un IP esclusivo per tutta la durata della connessione (es. SMTP e sicuramente ce ne sara' qualcun altro). Vediti anche qualcosa sul multihoming. https://www.noction.com/knowledge-base/multihoming ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] ICaaS
Non conosco questa soluzione, ma, a naso, credo che non faccia al caso nostro. TCP? Hai link? Quando hai l'esigenza di offrire un canale logico più ampio hai principalmente 3 strade: - bonding L2 con collaborazione dell'ISP (es. ML-PPP, con un piccolo fix del kernel per disattivare la frammentazione) - bonding L2 over L7 senza collaborazione dell'ISP, più inefficiente ma compensato dall'economicità(?) (es. l'accrocchio di Daniele Capasso) - load-balancing L3 (es. Multipath routing nativo o politiche gestite da netfilter), con efficienza direttamente proporzionale al numero degli utenti/flussi e senza overhead Diciamo che in contesti abbastanza saturi, ovvero con flussi di gran lunga maggiori del numero dei singoli canali e con capacità del singolo canale maggiore di quella che si vorrebbe offrire all'utente finale, la strada migliore, a mio modo di vedere, è un banale load-balancing. In altre parole, se hai delle misere ADSL da 7Mbit e vuoi dare all'utente finale la brezza di andare a 20Mbit (almeno come burst), allora devi bondare in qualche modo. Se invece hai a disposizione FTTCAB da 50-100Mbit, allora non mi stresserei l'anima a fare accrocchi o bonding, tanto all'utente finale arriverebbe comunque una banda inferiore a causa dei limiti del WiFi. Questo TCP Multipath di cui parli può permettere di streammare all'utente finale un flusso audio-video live con bitrate maggiore di quello del singolo canale? Se la risposta è NO, allora non fa assolutamente al caso nostro. Tanto vale fare load-balancing. Il giorno 24 dicembre 2016 19:40, Massimiliano CARNEMOLLA < massimili...@null.net> ha scritto: > C'e' chi ha dovuto affasciare ADSL per unire i flussi in download/upload > di piu' connessioni, chi ha utilizzato server su Internet per fare la > stessa cosa. > > > Dentro Ninux Roma utilizzano il TCP Multipath per ottenere lo stesso > obiettivo. > > > Nei vs casi non era possibile utilizzare questa soluzione ? > > ___ > Wireless mailing list > Wireless@ml.ninux.org > http://ml.ninux.org/mailman/listinfo/wireless > ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
[Ninux-Wireless] Proposte x Rete overlay
Nei limiti di quello che sarei in grado di fare posso darvi una mano a metter su questa rete overlay ? C'e' gia' un gruppo di lavoro e documentazione sulla quale sperimentare ? 1) Con SIXXS a quale IPv4 di quale nazione un utente dovrebbe collegarsi per fare tunneling IPv6 ? (es. America, Nord Europa) Si puo' valutare la possibilita' di adottare Hurricane Electric che offre un tunnel broker dove il piu' vicino punto di connessione mi pare sia in Svizzera ? La Rete Ninux puo' creare un proprio servizio di tunnel broker IPv6 senza affidarsi a servizi di terze parti ? (cosi' la connessione non esce dal routing italiano) 2) Si potrebbero utilizzare ground router a basso costo tipo i NEXX per accedere alla rete overlay Ninux ? Modelli WT3020AD (non riesco a trovarlo da nessuna parte, sarebbe l'ideale) WT1520F (potrebbe andare al limite come requisito minimo) WT3020F (questo potrebbe andar bene) Ci installiamo su OpenWRT con una configurazione Ninux adatta per accedere alla ns Rete IPv6 in overlay Potrebbe incentivare la regola di permettere l'accesso alla rete overlay solo a coloro che sono proprietari di nodi attivi reali sulla Rete Ninux ? (che non hanno link wireless con l'isola Ninux Roma o nodi che non riescono a linkarsi con altri per troppa distanza o perche' non ce ne stanno proprio) Nel senso che non devo aspettare la possibilita' di linkarmi a qualcuno per entrare in Ninux o trovare gia' qualcuno esistente al quale linkarmi : devo iniziare a fare copertura. Basterebbe iniziare con una rete a 2.4 con antenna omnidirezione a 15-20 dBi, un dispositivo tipo https://routerboard.com/RBMetalG-52SHPacn per fare copertura nel vicinato e far conoscere il progetto. Una volta che qualcuno sara' interessato a linkarsi con te il dispositivo e' dual band quindi e' convertibile per lavorare a frequenze di 5 Ghz (e' necessario solo cambiare l'antenna, il trasmettitore rimane quello che e'). 3) Sul Map Server si possono introdurre altre tipologie di nodi ? Si puo' di default visualizzare solo i nodi attivi e poi chi vuole visualizzare anche quelli potenziali ? La Rete Ninux deve apparire come una Rete di nodi reali e relativi link wireless, non un'accozzaglia di persone che mette li' il proprio segnaposto che lascia il tempo che trova... 4) Si potrebbero introdurre 3 tipi di link sul map server ? VErdi Link Reale Gialli Link Reali che pero' in un dato momento i nodi non riescono ad associarsi per qualche motivo (es. manutenzione, disservizi o altro), ma rimane una traccia/idea di come la Rete sia strutturata Rossi Link Nodi attivi connessi alla Rete Ninux in overlay, VPN e quant'altro (che utilizzano la Rete Internet per fare tutto cio') 5) Invece di fare tunneling centralizzati tutti a Roma non sarebbe piu' logico che ogni nodo attivo si linkasse al nodo piu' vicino della sua regione o limitrova in VPN/tunneling/overlay che abbia una connessione internet decente per offrirgli un servizio del genere ? Perche' altrimenti continueremo ad avere un'infrastruttura di Rete e Servizi di tipo centralizzati e invece la direzione giusta sarebbe decentralizzare per poi distribuire. Secondo me questa possibilita' alle persone di far parte della Rete overlay da una parte serve per incuriosire e poter scoprire come funziona Ninux, quello che ci puoi fare e incentivare alla partecipazione di qualsiasi tipo ma dall'altro non dev'essere un modo per fermarsi li' e non andare piu' avanti. Diamo accesso a tutti e poi la maggior parte si mette a giocare (pseudo sperimentazione) nel senso che si fa i fatti suoi all'interno sperimentando non per il progetto stesso rivolto al benessere della collettivita' ma per propri interessi personali. Sarebbe giusto secondo me dare accesso solo a chi e' disposto a tenere un ground router o mini pc attaccato alla propria rete internet 24/24 ore o chi si impegna a tenere nodi attivi sul tetto accesi 24 ore su 24 e che con tutto cio' contribuisce alla crescita del Progetto Ninux. Che ci sia da parte ns massima disponibilita' nei confronti delle persone ma dalla loro parte un minimo impegno di qualsiasi tipo (comunita', nodi, servizi etc.) per cercare di portare avanti questo progetto. ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
