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

Rispondere a