Newsgroup: it.tlc.provider
Titolo: Flashnet & Infostrada

proprio un IP di Flashnet. 
Oddio oddio oddio..... temo il peggio.....
Spero che il buon e gentile Michele Trotta mi smentisca,
Interbusiness con Arcipelago non ci e' riuscita e
AlbaSlow ha per mesi _provato_ il contrario.... non
ditemi che e' cosi' anche per Infostrada ora....
Come funzia sta "cosa" ???
Ipotesi uno (come AlbaSlow e, mi pare di capire, Arcipelago):
Il "tunnel" dal POP al sistema del provider e' un "bruto"
tunnel per la serie "PVC" (Private Virtual Channel) dove i
_byte_ che arrivano dal modem dell'utente passano raggruppati
in pacchettozzi con i loro bravi protocolli di resequencing
e di "reliability check" _rimontati_ sopra a un protocollo
seriale (PPP) che incapsula a sua volta un protocollo
"unreliable e unsequenced" (IP) su cui poi nel 99% dei casi
viene "ricostruito" un protocollo "reliable e sequenced" (TCP).
Cioe': il "tunnel" porta brutalmente quel che arriva dal modem
e il computer del provider (non il router del POP) "interpreta"
il PPP: quando si tira giu' un FTP ci si ritrova con cinque
protocolli a catena incapsulati uno nell'altro: TCP(FTP) -> IP
-> PPP -> <tunnel-virtale> -> <rete-interna-dell'access-provider>
(quest'ultima a pacchetti....).
Insomma un orrore di overhead, di lentezza, di "stuck" nelle
connessioni..... non solo per la ridondanza (inutile) dei
protocolli ma soprattutto per la mostruosa ripetizione del 
"resequencing ed ACKing" a due livelli diversi del trasporto,
con relativi buffer e relativi resend etc etc etc, con ritardi
e "hang" che lungi dal sommarsi si.. moltiplicano tra i due
livelli... orrore, orrore, orrore... se all'universita' avessi
abbozzato una rete che funziona cosi' il prof Horowitz mi
avrebbe preso a schiaffi (fisicamente...).
Ipotesi due (vi prego ditemi che e' cosi'....):
Il _POP_ decodifica il PPP, estrae i pacchetti 
IP e li fa arrivare (in modo unreliable ed unsequenced, tanto e'
IP ed e' nato per funzionare cosi') al computer di Flashnet
attraverso la rete proprietaria di Infostrada appunto come
_pacchetti_IP_ (eventualmente incapsulati in un protocollo
comunque "connectionless") e da li poi Flashnet gestisce il 
routing.....
Temo che non sia cosi'... vorrei tanto essere smentito ma
temo .....
Se non e' cosi'.... beh... ripeto cio' che dissi a Flashnet ai
tempi di AlbaSlow e che dissi a Interbusiness tempo dopo riguardo
a Arcipelago: esiste una ampia, dettagliata, matematica dimostrazione
del perche' e percome il "tunneling" fatto nel "modo uno" non
funzionera' mai in modo decente su una rete con un moderato carico
che comporti un piu' che insignificante packet loss e una piu'
che insignificante latenza dei pacchetti nel protocollo sottostante
il tunneling.... upon request vi sparo una dettagliata analisi
matematica e tecnica della faccenda (in inglese la scrissi e non
ho nessuna voglia di tradurla.... avvisati).
AlbaSlow era (o e' ? esiste ancora ?) degna di tale nome perche' 
sovraccarica ma, lasciatemelo dire, per un grossolano, orrendo e 
sconvolgente errore di progettazione della rete frutto di una 
totale, radicale e inesorabile incompetenza in materia di analisi 
del funzionamento delle reti di trasmissione dati. Errore che ha 
in breve tempo (appena raggiunto appunto un "moderato" carico 
sulla rete)  manifestato la sua fatalita', errore puntualmente 
ripetuto da  "Arcipelago" e (mi pare ora di capire) anche da 
Infostrada, errore che anche in queste due reti bastera' a 
"sederle" non appena il carico raggiungera' valori "tangibili".
Vi prego, signori di Flashnet e di Infostrade, non fate questo,
state facendo un regalo troppo grande a TIN in questo modo....
Ciao,
Andrea.
[Non ho piu' un email perche' da meta' gennaio saro' in .nz, in
via definitiva... "provate" a rispondermi qui' se ritenete...]
-- Questo gruppo e' robomoderato - i messaggi sono processati automaticamente

via definitiva... "provate" a rispondermi qui' se ritenete...]
Un post come questo sarebbe stato un ottimo candidato per una email.
Chiediamo scusa a tutti gli altri frequentatori del gruppo, su :-)
Davide Marcato.
----------------------------------------------------
| -- Freelance International Consultant
| -- Windows & Internet Development
| -- Technical Writer
----------------------------------------------------
| -- Email: 
mar...@programmers.net
| -- Web: 
http://www.programmers.net/artic/Marcato
----------------------------------------------------


In it.tlc.provider The Black Hacker <User:blackye@Host:non.ho.piu.email> wrote:
 >Ipotesi due (vi prego ditemi che e' cosi'....):
Temo di no...
 >il tunneling.... upon request vi sparo una dettagliata analisi
 >matematica e tecnica della faccenda (in inglese la scrissi e non
 >ho nessuna voglia di tradurla.... avvisati).
Spara pure (su it.comp.reti.ip-admin) o posta un pointer.
 >[Non ho piu' un email perche' da meta' gennaio saro' in .nz, in
 >via definitiva... "provate" a rispondermi qui' se ritenete...]
Serve un feed di it.*?
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *
(il moderatore)


avrebbe preso a schiaffi (fisicamente...).
Non ho capito se ti serviva una conferma anche per Albacom........
Confermo, e' la PRIMA che hai detto :-((((
Per Albacom (Albaslow ;-))) si apre una connessione X.28 con il POP il
quale trasferisce i pacchetti ad una rete X.25. Questa poi, via PVC
porta i pacchetti fino al provider.
In caso di una connessione di tipo PPP (con protocollo TCP/IP)
effettivamente ti ritrovi il pacchetto TCP incapsulato in IP
incapsulato in PPP incapsulato in X.25 (abbiamo il router che suda
;-)). 
In questa configurazione ci accade una cosa curiosa.....
Fin troppo spesso :-((( il protocollo PPP rileva dei CRC error.
I CRC non vengono assolutamente rilevati a livello X.25 per cui non
capisco come si possa verificare. Sembra quasi che la rete X.25 mi
cambi il contenuto dei pacchetti incapsulati senza accorgersi di
niente. Possibile ?!?!?!?
Il risultato finale comunque non e' proprio un cesso, diciamo che ci
si riesce al lavorare......
Certo, anch'io quando ho visto questa "soluzione" sono rimasto
stupefatto dalla fantasia di Albacom !!!
Come la vedresti di far conoscere qualche tecnico Albacom al prof.
Horowitz ?   ;-))) 
 
Bye 
Sergio


temo .....
smentito!!! :)
Il protocollo PPP viene terminato sul NAS (Network Access Server),
l'IP viene incapsulato (in questo caso di tratta di un protocollo
proprietario Ascend sopra IP) ed arriva al nostro NAS 'virtuale',
da dove poi il traffico viene normalmente instradato.
Con tecniche di policy routing ci si potrebbe risparmiare
il tunnel, ma la complessita' per il fornitore aumenta e
la gestione da parte del cliente (provider) diventa
difficoltosa (in termini di indirizzi IP e supporto all'utente).
tutto sommato il sistema funziona bene, si tratta
di dimensionare correttamente il canale
provider<-->rete di accesso.
In questi giorni Flashnet sta effettuando
un upgrade del PVC con la rete-accessi
Infostrada.
al contrario Albacom funziona come nella prima ipotesi,
c'e', pero', da dire che quando e' stato progettato
il servizio, di meglio non si poteva fare.
cordialmente,
Andrea Colangelo
Flashnet Staff


Spero che il buon e gentile Michele Trotta mi smentisca,
Ciao Andrea,
una cortesia (chiedo scusa per l' off-topic).
Avrei bisogno di scriverti in privato ma non so' piu' come beccarti :)
Ti faresti vivo?
                                                          Michele 



Uhmmm....
Che dire se si fa girare la rete "interna" di Infostrada con
IPv6 e si incapsula IPv4 in un tunnel IPv6 in modo che l'assegnazione
dell'indirizzo IPv4 viene gestita dall'altro lato del tunnel
(cioe' dal sistema di Flashnet) ? [Con IPv6 avendo 'n' provider
che condividono 'm' POP ognuno con 'p' porte avere 'n x m x p'
indirizzi assegnati non e' un problema....]
Si avrebbero vari vantaggi:
- Tutto standard (se cisco & ascend ce la mandano buona
  non dovrebbe esserci bisogno nemmeno di software/firmware
  apposta sui router...)
 
- Siam gia' pronti per IPv6 (ci sara' o non ci sara' ? questo e' 
  il problema.....) ... certo che cosette come l'anycast, il
  broadcast con preallocazione delle risorse, ed uno spazio
  di indirizzamento decente servirebero proprio a sta Internet...
- Con una gestione decente del QOS da parte di Infostrada sarebbe
  anche piu' facile "garantire" le prestazioni minime contrattuali
  ad ogni provider....
 
Boh... ci pensero' su.
Ciao,
Andrea.


Ti faresti vivo?
Eccomi, mailato in privato una mailbox che restera' viva
ancora per un po'... indipendentemente dalla mia collocazione
fisica :)
Tanto per sistemare l'off e non essere fucilati da Marco:
Il POP ISDN a Bari lo avete attivato o no ??
Quanto 'gagosta' un flat (ok ok.. vedo il web...) ?
Si puo' provare ?
Ciao,
Andrea


Confermo, e' la PRIMA che hai detto :-((((
A questo punto, pur non essendo un tecnico par vostro, e a giudicare da
cio' che vedo, anche Arcipelago funziona in questo barbaro modo. Non
riesco a spiegarmi altrimenti il motivo per cui, con connessioni a
28800, transitino in seriale (e li "vedo" benissimo) 3200 cps, con soli
2500 cps utili, il resto immagino sia overheading o schifezze del
genere. Spesso poi, nonostante la negoziazione vada a buon fine, non si
riesce ad uscire dalle pastoie di arcipelago medesima, non riesco
nemmeno a pingare il server del mio fornitore d'accesso (usando
l'IPADDR, naturalmente). Morale: ho fatto da poco un abbonamento con un
pop di IT.net che costa un pochino di piu', pero'.... ;)
Ciao.
-- 
Romeo Codari - Team OS/2 Italy
 e-mail: 
r...@XYZ.digicron.com
To reply via e-mail, please remove XYZ from the address
Per risposte via e-mail, eliminare XYZ dall'indirizzo
   ************ D I S C L A I M E R **************
   * No Microsoft stuff has been used to compose *
   *            and post this article            *
   *  This system is absolutely Microsoft FREE   *
   ***********************************************
       *** PGP key available on request ***
