Newsgroup: it.tlc.gestori.fastweb
Titolo: Macs e i limiti di banda in UL a 50 KB/s

Caro Macs (aka Plany),
ho visto che hai postato qui sotto in risposta a "small business: max pc 
collegati". Visto che ti sei fatto vivo, ti volevo chiedere una cosa:
Ti ricordi quando, un anno e mezzo fa circa, mi sono lamentato dei limiti di 
banda in UL con gli esterni di FW con programmi P2P (bittorrent, emule, 
winmx)? Quella volta tu fosti abbastanza scettico e concludesti che forse 
erano miei problemi locali, o al massimo problemi della mia sottorete.
Ora non sono più il solo a lamentarmi, ma siamo diventati in molti. 
Difficile quindi che sia un mio problema "locale". Che spiegazione dai oggi, 
come oggi, dello stesso problema? E, sopratutto, durerà ancora molto?
Grazie.
Ciao,
somachi 

 oggi, come oggi, dello stesso problema?
Veramente conclusi - dopo le tue ultime prove - il 16 Giugno 2004 con :
************************************************************************
Se confermi di avere un tappo in upload verso l'esterno anche in caso
p.es
. di trasferimenti FTP (e quindi non solo P2P), devi richiedere una
verifica tecnica = potrebbero esservi problemi a livello del gateway di
uscita su Internet, per cui non saresti il solo utente impattato della
tua zona a risentirne. 
************************************************************************
proprio perche' il confronto su P2P con altre utenze attestate su NAT-R
diversi a quel punto faceva pensare sull'interfaccia MSFC/NAT-R di tua
attestazione.
Ti chiesi peraltro di ripetere per scrupolo il test in up sul tester Mc
Link onde verificare eventuali variazioni anche su HTTP rispetto alle
tue prove di Marzo 2004 -> non seguirono pero' su tale topic altri dati
da parte tua.
Nel frattempo successero un po' di cose tra cui una serie di problemi 
generalizzati (e validamente documentati) sulla rete FW di banda verso
l'esterno (non solo in UL, ma anche in DL) su vari NAT-R -> problemi che
rientrarono a fine Marzo 2005 in associazione anche alle variazioni
nelle mappature MAN/NAT-R (che comportarono il rientro ai parametri
normali di carico di vari NAT-R) :
==
- 
http://plany.fasthosting.it/test/fase2.shtml
Per il resto, restano tuttora valide le indicazioni fatte a suo tempo :
==
- Marzo 2004  - 
http://tinyurl.com/arrm3
- Giugno 2004 - 
http://tinyurl.com/8vrz5
==
con una variazione ma non lato FW = e' infatti confermato come siano
attive policy di traffic shaping sulle linee ADSL in wholesale di altri
provider, in primis Libero/Wind, per limitare la banda usata dalle
applicazioni P2P.
Tali blocchi sono invece assenti sulle utenze ULL o in Shared Access, in
quanto si appoggiano (salvo l'ultimo miglio) alla rete di proprieta' del
provider (e quindi non sono soggette a costi di traffico come avviene
invece per le linee Wholesale prese da TI, e che prevedono la raccolta
del traffico sulla relativa rete ATMosfera).
-- 
|Ż \/Ż | /Ż\ /Ż__/Ż__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|Ż|\/|Ż|/Ż_Ż\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|
|_|  |_/_/ \_\___|___/<|> *FAQ ITGF 
http://plany.fasthosting.it
 <|
|>- RST - Plany/MACS -<|> *FAQ GCN  
http://faq.news.nic.it/
 ____<|

 oggi, come oggi, dello stesso problema?
Veramente conclusi - dopo le tue ultime prove - il 16 Giugno 2004 con :
************************************************************************
Se confermi di avere un tappo in upload verso l'esterno anche in caso
p.es
. di trasferimenti FTP (e quindi non solo P2P), devi richiedere una
verifica tecnica = potrebbero esservi problemi a livello del gateway di
uscita su Internet, per cui non saresti il solo utente impattato della
tua zona a risentirne. 
************************************************************************
proprio perche' il confronto coi dati di altre utenze attestate su NAT-R
diversi (che non riscontravano la problematica UP su P2P) a quel punto
indicava piu' plausibilmente un problema (e.g. di gestione carico) sulla
interfaccia MSFC/NAT-R dove eri attestato.
Ti chiesi peraltro di ripetere per scrupolo il test in up sul tester Mc
Link onde verificare eventuali variazioni anche su HTTP rispetto alle
tue prove di Marzo 2004 -> non seguirono pero' su tale topic altri dati
da parte tua.
Nel frattempo ne sono successe di cose... tra cui - verso fine 2004 - 
una serie di problemi generalizzati (e validamente documentati) sulla
rete FW di forte decremento della banda verso l'esterno (non solo in UL,
ma anche in DL) su vari NAT-R, che mostravano limiti di gestione carico
in rapporto alle utenze attestate.
Problemi che rientrarono a fine Marzo 2005 in associazione anche alle
variazioni nelle mappature MAN/NAT-R :
==
- 
http://plany.fasthosting.it/test/fase2.shtml
Per il resto, restano tuttora valide le indicazioni fatte a suo tempo :
==
- Marzo 2004  - 
http://tinyurl.com/arrm3
- Giugno 2004 - 
http://tinyurl.com/8vrz5
==
dato che non risulta un tale problema a livello generale sui NAT-R della
rete, per cui potrebbe essere nuovamente un problema di carico sulla tua
interfaccia di attestazione -> al momento mi risultano (in virtu' della
validazione delle segnalazioni su forum/newsgroup) alcune questioni ma
di carattere diverso sul NAT-R 85.18.14.5 (e non quindi su quello a cui
dovresti essere associato).
Aggiungo solo un dato non da poco = e' infatti confermato come siano
attive policy di traffic shaping sulle linee ADSL in wholesale di altri
provider, in primis Libero/Wind (ma non solo), per limitare la banda


 oggi, come oggi, dello stesso problema?
Veramente conclusi - dopo le tue ultime prove - il 16 Giugno 2004 con :
************************************************************************
Se confermi di avere un tappo in upload verso l'esterno anche in caso
p.es
. di trasferimenti FTP (e quindi non solo P2P), devi richiedere una
verifica tecnica = potrebbero esservi problemi a livello del gateway di
uscita su Internet, per cui non saresti il solo utente impattato della
tua zona a risentirne. 
************************************************************************
proprio perche' il confronto coi dati di altre utenze attestate su NAT-R
diversi (che non riscontravano la problematica UP su P2P) a quel punto
indicava piu' plausibilmente un problema (e.g. di gestione carico) sulla
interfaccia MSFC/NAT-R dove eri attestato.
Ti chiesi peraltro di ripetere per scrupolo il test in up sul tester Mc
Link onde verificare eventuali variazioni anche su HTTP rispetto alle
tue prove di Marzo 2004 -> non seguirono pero' su tale topic altri dati
da parte tua, per cui dovevo supporre che o ti fossi rassegnato al
problema o che si fosse risolto.
Nel frattempo ne sono successe di cose... tra cui - verso fine 2004 - 
una serie di problemi generalizzati (e validamente documentati) sulla
rete FW di forte decremento della banda verso l'esterno (non solo in UL,
ma anche in DL) su vari NAT-R, che mostravano limiti di gestione carico
in rapporto alle utenze attestate.
Problemi che rientrarono a fine Marzo 2005 in associazione anche alle
variazioni nelle mappature MAN/NAT-R :
==
- 
http://plany.fasthosting.it/test/fase2.shtml
Per il resto, restano tuttora valide le indicazioni fatte a suo tempo :
==
- Marzo 2004  - 
http://tinyurl.com/arrm3
- Giugno 2004 - 
http://tinyurl.com/8vrz5
==
dato che non risulta un tale problema a livello generale sui NAT-R della
rete, per cui potrebbe essere nuovamente un problema di carico sulla tua
interfaccia di attestazione -> al momento mi risultano (in virtu' della
validazione delle segnalazioni su forum/newsgroup) alcune questioni ma
di carattere diverso 
p.es
. sul NAT-R 85.18.14.5 (e non quindi su quello
a cui dovresti essere associato).
Le prove di upload da eseguire verso l'esterno della rete sono comunque
ancora quelle indicate a suo tempo :
==
- Controllo Upload via HTTP (ved. anche tester Mc-Link)
- Controllo Upload via FTP
- Controllo Upload ad un'utenza esterna tramite 
p.es
. Look@File o Iperf
  usando come porte remote anche quelle note associate a software P2P
==
confrontando eventualmente i risultati con quelli di analoghe prove
effettuate attivando l'IP Pubblico IPPD FW (tenendo anche conto del
bundle delle 20 ore mensili previsto per le utenze Internet senza Limiti
e MegaLinea/Base con opzione Giorno & Notte).
Aggiungo infine un dato non trascurabile, dato che incide pesantemente
proprio nei trasferimenti P2P tra utenze ADSL di ISP ITA = e' infatti


 del traffico sulla relativa rete ATMosfera).
Non so cosa succede con la banda degli altri provider italiani, studio la 
lingua inglese e quindi i miei scambi sono esclusivamente con l'estero.
Dati il ripetersi costante ed immutabile nel tempo del limite di banda 
esclusivamente con applicazioni p2p, dato che questo accade solo con l'IP di 
NAT e mai con l'IP pubblico, e solo con la rete esterna, mi si sto sempre di 
più convincendo che FW abbia implementato un'attività di controllo e 
limitazione di banda selettiva, applicata cioè solo a determinati utenti FW 
che scambiano attivamente con l'esterno mediante programmi p2p.
Ci sono comportamenti molto tipici: all'inizio di una sessione, la banda 
sale velocemente, sfonda per pochi secondi (2-4) il limite dei 50 KB/s 
(arriva a 60-70 KB/s) , per poi ripiombare giù sui 50 KB/s, come se il 
controllo intervenga *dopo*, quando cioè le varie connessioni stabilite, 
cumulate insieme, sfondano effettivamente il limite dei 50 KB/s. A quel 
punto qualcosa interviene, e riporta la banda complessiva negli ambiti 
stabiliti (50 KB/s).
Mi ha molto interessato un recente articolo apparso su Punto Informatico 
(
http://punto-informatico.it/p.asp?i=56172&p=3&r=PI
), nel quale si fa 
riferimento al Cisco SCE 1000 Series Service Control Engine 
http://www.cisco.com/en/US/products/ps6150/products_white_paper0900aecd8023500d.shtml
 e 
http://www.cisco.com/en/US/products/ps6151/
.
Guardando le caratteristiche di quella macchina Cisco, mi ha colpito il 
fatto che ha tutte le caratteristiche necessarie per provocare una 
fenomenologia come quella che mi sta capitando da troppo tempo (limitazione 
di banda esterna).
Ora, visto che sei la persona che io conosco che ha più conoscenze sulla 
struttura e le apparecchiature in dotazione a FW, ti vorrei porre una 
schietta e franca domanda.: a tua conoscenza, ha FW implementato delle 
apparecchiature e/o tecniche atte a limitare la banda esterna degli utenti 
residential che utilizzano programmi p2p?
Grazie per il tempo e la disponibilità,
somachi 

somachi ha scritto:

Ciao, ti rispondo anche io per confermarti che ultimamente non ho piu' 
alcuna limitazione in upload, riesco sempre a raggiungere il massimoo 
quasi dato dal server a cui mi collego.
Tale situazione e' iniziata da quando non utilizzo praticamente mai 
banda in uscita, primo avevo un flusso 24h su 24 per 365gg l'anno.
Da cui si deduce che vengano applicate restrizioni sulla quantita' di 
traffico in uscita.
Dovresti sacrificarti,bloccare tutto per 3 4 gg, e poi ripartire, 
dovresti veder sparire il tappo a 50k almeno sino a che raggiungerai un 
livello x di traffico in uscita.

 di traffico in uscita.
Mmmh..., purtroppo non è il mio caso. Io ho bloccato qualsiasi attività 
sulla rete per 4 mesi (avevo anche cambiato piano di abbonamento, portandolo 
a solo base e scaricavo la posta tramite un'altro ISP). Quando ho ricambiato 
l'abbonamento FW a Flat, e ho iniziato di nuovo a scambiare in rete, ho 
subito ho ritrovato i limiti di banda, per quanto incredibile questo possa 
sembrare. Se esiste un software che FW sta utilizzando (tipo Cisco SCE 
1000/2000 Series Service Control Engine), quello l'hanno puntato su di me.
Ciò che più mi irrita non è tanto il fatto che la mia banda sia limitata, 
quanto che FW *neghi* assolutamente e ripetutamente di farlo. O 
all'assistenza sono una manica di bugiardi, oppure anche loro vengono tenuti 
all'oscuro di ciò che il ramo tecnico di FW mette realmente in atto.
In ogni caso è una situazione incresciosa e snervante. Posso anche capire le 
limitazioni di banda (ma dovrebbero dirlo chiaramente nel contratto), ma non 
tollero gli inganni, specie se perpetrati ai danni di clienti che da 4 anni 
pagano costantemente e fedelmente 85 euro al mese. Che senso ha tutto ciò da 
parte di una società che si definisce all'avanguardia?
Grazie per l'aiuto :-)
Ciao,
somachi

 tecniche atte a limitare la banda
FW - come qualunque altro provider che utilizzi dispositivi Cisco lato
rete - ha ovviamente apparati destinati a gestire la priorita' del
traffico ed il bilanciamento del carico, necessari per gestire nel modo
piu' efficiente (secondo il provider) la banda a disposizione -> se per
assurdo non l'avesse fatto - ved. scenario caos totale lato rete - oggi
plausibilmente non sarebbe piu' in attivita'.
Il problema reale non e' quindi il protocollo bensi' la presenza o meno
di criticita' a livello di banda/carico sui NAT-R, e quando questa c'e'
si riscontra (a livello di tutte le utenze attestate) nelle applicazioni
di trasferimento dati (e.g. P2P e FTP) con priorita' secondarie rispetto
ad altre (e.g. HTTP e SMTP).



Mah,
La mia situazione indica velocità di download differenti dalla stessa 
sorgente semplicemente cambiando ip interno ed Il routing verso quella 
destinazione varia dagli hop che vanno dal 3 al 7.

 ha scritto nel messaggio 
news:qi_ff.6485$tc5....@tornado.fastwebnet.it...

Scusa, ho solo adesso capito il senso ^_^ 

> schizzo tranquillamente verso i 300-400 KB/s in UL. Quindi, non è un



Ok, io ho un IP interno 1.94.134.xxx ed esco sul NAT 
81.208.106.73.La
 mia 
zona è San Donato Milanese. Non so quanti altri utenti FW escano sullo 
stesso NAT, ma credo che siano sull'ordine delle decine di migliaia, forse 
vicino al limite massimo possibile (oltre 60.000). Dalle proteste su questo 
NG e su altri, non sembra proprio che anche tutti gli altri utenti che hanno 
il mio stesso NAT di uscita abbiano i miei stessi problemi. E allora la 
domanda è: a che livello dentro la rete FW si crea il mio problema? A San 
Donato Milanese? A livello del mio catalyst? A Milano? Dove, cioè? Oppure tu 
dici che davvero tutti gli utenti istradati sul NAT 81.208.106.73 hanno i 
miei stessi limiti sul p2p?
Non ho mai pensato che FW potesse dare piena banda a tutte le ore e quindi 
una policy di Load Balancing mi sembra perfettamente normale. Quello che 
invece è difficilmente accettabile come cosa normale è che un utente, o 
anche molti altri, ma pur sempre una parte minoritaria del totale degli 
utenti residential FW debbano avere dei limiti fissi a tutte le ore, 24h/24, 
7 giorni/7. E che limiti! 50 KB/s piatto, sia che siamo alle 10 del mattino 
che alle 4 di notte. E' un Load Balancing questo? Non si bilancia nulla, si 
assegna una banda massima fissa (il 5% del limite massimo teorico di banda) 
e così il problema è risolto. Ma è davvero credibile che neanche alle 4 di 
notte FW abbia banda disponibile?
Ok, Macs, dimmi quello che devo fare con l'assistenza FW (192.193) per porre 
fine a questo situazione per me altamente incresciosa. Che cosa devo dire e 
chi devo contattare?
Grazie ancora per la tua disponibilità.
Ciao,
somachi

 devo dire e chi devo contattare?
Saro' duro, ma tu non puoi porre termine a problematiche di carico sulla
interfaccia NAT-R di attestazione = come e' finora avvenuto, a meno di
un rientro autonomo della problematica, e' FW che decide tempi/modi di
'scarico' -> l'unica cosa che tu puoi fare - in virtu' dei tuoi diritti
contrattuali - e' segnalare un tuo reclamo ufficiale in merito tramite
l'invio di FAX + Raccomandata A.R. ai recapiti indicati nel contratto e
nella Carta Servizi.
A quel punto, in virtu' della risposta che FW sara' tenuta a darti,
avrai sufficienti dati per regolarti e continuare (o meno) nella 
fruizione dei loro servizi.


 fruizione dei loro servizi.
Esatto.


Wow Macs, ...mi stai prospettando un futuro di radiosa connettività con 
FW!!! :-)
Bene, stabilito che FW fa quello che vuole con la sua banda e che ridurla di 
quasi 20 volte rispetto alle condizioni esistenti al momento del contratto 
stipulato 4 anni fa non sembrerebbe nulla di cui gli utenti debbano 
lamentarsi (almeno secondo FW), avrei una curiosità:
ammesso per assurdo che FW voglia riassegnare la mia connessione (il mio IP 
interno) ad un NAT-R meno congestionato, quanti altri utenti della mia zona 
dovrebbero essere altresì "spostati di NAT" come minimo. Sarebbe una cosa 
fattibile a livello di singolo utente? Oppure, diciamo, almeno 3-400 altri 
utenti si ritroverebbero con il NAT cambiato oppure, che cosa altro è vero?
Grazie ancora per le tue gentili risposte.
Ciao,
somachi

 Grazie ancora per le tue gentili risposte.
Prego ;).


somachi ha scritto:

Ho avuto un cambio nat qualche giorno fa.
Dopo un tentennamento iniziale (risultavano addirittura perdite di 
pacchetti) ora pare filare come un treno.
Siamo  a 800K su 
ftp.leo.org
 in download e a 120-130k in upload verso la 
  mia azienda (interbusiness) che tradotto in soldoni significa che sto 
saturando la banda messa a disposizione dal server aziendale e siamo al 
limite fisico della adsl attestata.
Vediamo  se dura.
Ps 85 uero sono troppi.. chiedi un cambio piano tariffario.
A 79 ci arrivi sicuramente per meno mi sa che devi disdire..

 limite fisico della adsl attestata.
-----------
quale è il NAT in questione? io ne ho uno che inizia per 85 e va che è 
un disastro
-- 
|         _|_   __  o  __
|_, (__(_  |_, |  ' | |  )
/et cum falsa damus, nihil nisi nostra damus/

 
Confermo : adsl in wholsale telvia = pesanti limitazioni sul p2p come 
lamentato dall'85% dell'utenza.
Non sussistono problemi su http ftp e ssh.
Quindi attenzione ai fornitori di connettivita' in wholsale se il vostro 
interesse e' il p2p

 
213.140.22.71
Eseguito mappatura sull'apposito form di macs.
Assegnato alle utente fibra 1.0.0.0. Milano Citta' a quanto pare in 
esclusiva (macs potra' confermare o meno)
In realta' ho sempre avuto nat in esclusiva su utenze fibra di Milano a 
quanto pare eccetto due disgraziatissimi mesi da Agosto 2003 a Novembre 
2003 quando mi misero su un nat condiviso con Genovesi e Napoletani :era 
uno spettacolo : ban a raffica,spam,lentezza disumana e altre 
piacevolezze. Fortunatamente duro' poco :)

 213.140.22.71
------------
ci credo che ora va bene, quello era il *mio* NAT fino a poco tempo fa e 
non avevo nessun problema, poi me l'hanno tolto... per assegnarmi questo 
attuale con cui ieri non potevo neppure raggiungere certi siti che con 
altre connessioni si vedevano benissimo


 A 79 ci arrivi sicuramente per meno mi sa che devi disdire..
Scusa, ho sbagliato, In effetti credo di pagare già 79 al mese, perchè ho 
fatto un cambio tariffario ad ottobre. Ora ho le 20 ore di IPPD, che mi 
hanno permesso di notare l'abissale differenza tra NAT e non-NAT per il p2p.
Appena ho tempo chiederò un cambio di NAT, ma dubito che lo concederanno. 
Per loro va sempre tutto bene :-)
Ciao,
somachi