[GTER] Porta do Kazaa Ligth

Marcelo Pias M.Pias at cs.ucl.ac.uk
Fri Apr 4 05:21:01 -03 2003


On Fri, 4 Apr 2003, [ISO-8859-1] João Carlos Mendes Luís wrote:

;Reinaldo Penno wrote:
;> Rubens,
;> 
;> em primeiro lugar a banda eh sempre fixa, P2P nao esta
;> consumindo "mais banda". O meu provedor me vendeu
;> 768kbs de download, se ele esperava que eu so usasse
;> 30kbs isso eh problemas dele. Isso nao tem nada a ver
;> com P2P per se, mas a razao de overprovisioning que o
;> carrier resolveu apostar.
;
;Aqui no Brasil, todo provedor de banda larga que eu parei para ler o AUP 
;tinha uma clausula dizendo que, a qualquer momento o provedor poderia 
;vir a cobrar um extra por byte caso o usuário ultrapasse uma franquia 
;definida.  Nao sei se algum já faz isso na prática.

No Reino Unido os provedores de banda larga se valem tambem desta
clausula em contrato. Um deles, a NTL, jah cobra por uso a
partir do limite de Gigabytes por dia. Quem excede o limite paga (sem choro!) por byte
transmitido. Foi uma confusao quando a noticia foi dada aos 
usuarios!

A BT, outro provedor, jah pensa em adotar a mesma politica
justamente pelo alto consumo de recursos por aplicacoes
'desestruturadas' de troca de
arquivos (gnutella, kazaa...). E cabe lembrar que nao trata-se apenas do
fato de baixar o arquivo, tem a pesquisa pelos dados que consume muita
banda nestes sistemas !!

http://www.darkridge.com/~jpr5/doc/gnutella.html

Acho que o modelo de tarifacao deve passar a cobranca pelo uso ao
inves do 'flat fee' praticado hoje, pelo menos por aqui. Algumas pesquisas
mostram que 'overprovisioning' eh extremamente caro e talvez
inviavel quando a maioria dos usuarios usarem aplicacoes como p2p,
video sob demanda, etc. Se bem que para audio/video tem-se
mecanismos de controle de banda mais eficientes. O problema que assombra os
provedores parece ser o p2p mesmo. Talvez quando sistemas p2p mais
estruturados como DHT (distributed hash tables), exemplo Chord e Pastry e DT (Distributed
Tables) tranformarem-se em realidade tenhamos um uso mais
eficiente de recursos. 

Um exemplo. Imagina que um provedor de acesso deva manter a estrutura
para comportar 'x' usuarios com dsl/cabo a 512k que usam no limite
por um periodo, digamos de 16 horas por dia. Quanto nao
custarah o link deste provedor com o
provedor de backbone? Com certeza as 28 libras, ou os 48 dolares ou os 95/105 reais nao pagarao os
custos de interconexao, salvo algumas excessoes.

Se o provedor que oferece o adsl/cabo (provedor de acesso) eh o que
possui o backbone (provedor de rede) talvez este possa comportar o custo. Agora nos
casos em que eles sao diferentes, fico imaginando como
manter o servico de banda larga sem limitar recursos. Tem algo estranho
que nao fecha nos precos praticados hoje...
   
;
;O problema disso é que esse tipo de medida foi feito pensando em 
;downloads e p2p, mas nego esquece que se vende banda larga no Brasil 
;como uma forma de ter multimedia real via internet, e que se eu quiser 
;ficar conectado em algum canal de audio/video o dia inteiro, pode ser 
;pior do que qualquer p2p, e o usuário médio nem vai saber por que foi 
;sobretaxado naquele mês...
;

Se o usuario foi sobretaxado a mais no mes, ele tem que receber uma
conta que mostre o uso pelo qual ele foi cobrado. Como o uso eh
medido, se nos equipamentos do provedor ou do proprio usuario eh outra
conversa... 

Isto sem contar que mais e mais usuarios exigirao
qualidade de servico nas conexoes de banda larga. Mesmo que o trafego
seja tratado de forma prioritaria por exemplo em classes, o modelo de
cobranca deve ser diferente do que temos hoje. Qualquer mecanismo para
QoS custa dinheiro em infraestrutura, quem paga isto?

Por ultimo, vao ser precisos novos mecanismos de medicao,
principalmente se envolver metricas para QoS. Minha hipotese eh que
estas medicoes DEVEM ser feitas no equipamento do usuario por
motivos de performance e escalabilidade, principalmente se for preciso estatisticas
refinadas por pacote!!??? Instalar um medido num roteador adsl/cabo nao
eh algo de outro mundo...

Abracos
Marcelo






More information about the gter mailing list