Artigo/Análise upstream FAQ

leexouce

Membro
Upstream FAQ

Após ter participado em algumas discussões sobre este assunto, passo a partilhar convosco a minha opinião pessoal na resposta a algumas perguntas. Isto parece-me pertinente porque numa época em que toda a gente fala desbocadamente sobre "banda larga" a situação está efectivamente na vizinhaça do rídiculo. Como alguém já escreveu publicamente "qualquer dia temos serviços 100Mb/384Kb".

Acrescento: o Google não poderia ter nascido numa garagem portuguesa.


1) Porque é que os débitos de upstream são tão baixos nos serviços ADSL e Cabo em Portugal?

As razões são várias:

a) As tecnologias são assimétricas por natureza [1,2] ... Isto é verdade mas não justifica de forma alguma as classes de tráfego como estão definidas em Portugal. As normas iniciais do ADSL já suportavam até 1Mbit de upstream e já me foi confirmado *verbalmente* que os DSLAMs existentes em Portugal o permitem.

b) O limite no upstream é o "cap" do tráfego p2p nacional. Ao aumentar este limite o tráfego p2p vai aumentar imediatamente, e os ISPs não estão particularmente interessados nisto (questões legais, tráfego trocado no GigaPix, ...).

c) Os circuitos com upstreams superiores a 512Kbps, que em Portugal são vendidos invariavelmente como “circuitos dedicados”, são extremamente dispendiosos (um circuito G.SHDSL 2Mbit simétrico pode custar entre 300 e 700 EUR mensais dependendo da capacidade negocial da empresa e da quantidade de serviços contratados). Por esta razão os ISPs acreditam que estão a proteger este mercado ao limitarem os débitos upstream do ADSL.

d) Os ISPs possuem serviços de datacenter/alojamento, e ao limitar os débitos de upstream estão a proteger este negócio, impedindo os clientes de se tornarem mais autónomos a nível de disponibilização de serviços e conteúdos.

Referências:

[1] http://en.wikipedia.org/wiki/ADSL
[2] http://en.wikipedia.org/wiki/Cable_internet


2) É expectável que a situação vá mudar de futuro?

A situação só poderá mudar quando os ISPs se aperceberem de que:

a) Os clientes pretendem maior flexibilidade na utilização que fazem do serviço de internet que contratam, incluindo alojamento do serviços

b) Ao tentarem proteger certos segmentos de negócio (ver acima) os ISPs estão a eliminar outros segmentos. Por exemplo, há muitos clientes potencialmente interessados em pagar um serviço um pouco mais caro, com um melhor upstream mas que nunca estarão interessados nos serviços dedicados cujo patamar de custo lhes é inacessível. Dada a diferença de custos, este tipo de cliente (tipicamente PME) acaba por se manter no serviço mais básico o que conduz a perda de negócio. Repare-se que mesmo que passe a ser disponibilizado com upstreams melhorados um serviço ADSL não terá o mesmo "nível de serviço" que um circuito dedicado (contenção, taxa de disponibilidade, prazos de reparação, etc) pelo que a diferença de custos continuará a fazer sentido.

c) Não se pode aumentar indefinidamente o débito downstream sem aumentar o upstream, visto que todo o tráfego TCP está sujeito ao respectivo tráfego de "acknowlege" [4] que flui no sentido inverso. Isto pode ser rigorosamente calculado em função dos tamanhos dos pacotes enviados. No entanto um simples teste sobre ADSL com ferramentas acessíveis a todos (wget, iptraf) permite obter que:

%tcp upstream rate ~ 1,84 %

de onde se obtém:

2 Mbps => 36.80 kbps
4 Mbps => 73.61 kbps
8 Mbps => 147.22 kbps
16 Mbps => 294.45 kpbs
20 Mbps => 368,06 kbps
24 Mbps => 441,67 kbps

Os valores acima referem-se a débitos efectivos a nível IP, ou seja os débitos calculados pelas aplicações, medidos sobre um serviço ADSL.

Para se poderem comparar com os débitos anunciados pelos ISPs com os débitos efectivos é necessário descontar os overheads dos protocolos subjacentes: Ethernet para serviço de Cabo e PPP+Ethernet+ATM para serviços ADSL [3].

No entanto a existência de overheads não afecta a relação entre os valores, pois afecta ambos os lados da "equação" acima.

Daqui conclui-se que por exemplo o serviço 24/400 vendido pela clix [6] é matematicamente impossível, porque a taxa máxima atingível num download isolado está limitada pelo débito de upstream disponível que ficará saturado antes de se atingir o valor máximo downstream.

A Netcabo parece ter tomado a primeira iniciativa no sentido de aumentar as taxas de upstream disponibilizando o serviço Netcabo Pro com débitos 8Mb/1Mb [5].

Referências:

[3] http://tldp.org/HOWTO/ADSL-Bandwidth-Management-HOWTO
[4] http://en.wikipedia.org/wiki/Transmission_Control_Protocol
[5] http://www.tvcabo.pt/Internet/SpeedProMais.aspx
[6] http://acesso.clix.pt/internet/adsl_16megas_caracteristicas.html


3) Que alternativas económicamente viáveis existem para aumentar a taxa de upstream?

Enquanto a situação de mercado não se altera, uma alternativa a contratar um serviço dedicado é contratar N vezes o serviço de melhor upload disponível, à custa de algum investimento em tempo de configuração.

Por exemplo um serviço com 2 Mbits pode “conseguir-se” com dois serviços Netcabo Pro 8Mb/1Mb tendo em conta que:

- é necessário ter um servidor ou router com 2 interfaces de rede
- é necessário configurar DNS round robin [7] – vários Ips para o mesmo hostname
- só se conseguem obter 2Mbits no somatório do tráfego; cada ligação individual está limitada a 1Mb mas estatisticamente conseguem-se os 2Mbits

Referências:

[7] http://en.wikipedia.org/wiki/Round_robin_DNS
 
Última edição:
Excelente post leexouce.
thumb.gif

Não sabia que era possível ter duas ligações para obter um maior somatório de velocidade.
Mas é possível ter dois serviços de Netcabo ou outro ISP qualquer ao mesmo tempo?
 
desconhecia isso do tráfego de "acknowlege

engracado a clix com 24 megas e precisa de 430 kbs de upload mas so disponibiliza 400 :|

btw, qual e a difrenca de um pacote "caseiro" de um empresarial?
esse pacote de 1 mega de upload e empresarial, nao o posso ter em casa?
 
Poder podes, é mais caro, como eh obvio, a diferença está na taxa de contençao, prioridade de pacotes "Trafic shapping reduzido dizem eles", e um apoio ao cliente de superior qualidade.

mas tive ainda agora a ver o preço do netcabo Pro 8/1 ... 30 gigas internacionais, 54 €uros mês...


eu vou admitir...sim eu sou do Clix Directo, mas deixar de pagar 34€ por ADSL + Telefone, e passar a pagar 54 € so por internet, nao me deixa agua na boca para ser sincero.
 
c) Os circuitos com upstreams superiores a 512Kbps, que em Portugal são vendidos invariavelmente como “circuitos dedicados”, são extremamente dispendiosos (um circuito G.SHDSL 2Mbit simétrico pode custar entre 300 e 700 EUR mensais dependendo da capacidade negocial da empresa e da quantidade de serviços contratados). Por esta razão os ISPs acreditam que estão a proteger este mercado ao limitarem os débitos upstream do ADSL.
E não é verdade?
Tenta descobrir o ratio entre clientes/trafego/lucro e aparece qualquer coisa do género:
10% dos clientes (residenciais) geram 80% do tráfego (total) e 5% dos revenues. Ao passo que 5% dos clientes (empresariais) geram 10% do tráfego e 80% dos revenues.
Os ISP's não são a santa casa, são empresas que lhes interessa o lucro, logo é óbvio que quem lhes interessa proteger são os clientes que consomem poucos recursos e pagam muito, ou sejam os grandes clientes.
Para a maioria dos ISP's os clientes residenciais dão prejuízo, as pessoas têm de se mentalizar dessas coisas, no tempo da PT pública é que era obrigação fornecer telecomunicações "ao povo" independentemente dos lucros, com as empresas privadas isso não acontece.
 
ai vai bump :-D
eu ja conhecia esse trafego de upload necessario para o download
em testes efectuados por mim na altura em q ainda tinha 512kb de dowload, para sacar à velocidade minima o minmo q me ocupava de upload eram ~3kB(KB e nao kb), apenas com uma ligaçao, portanto acredito q esses valores sejam um bocado por baixo

alias qd vi as ofertas 24Mb da PT ri-me e achei q os 512Kb de upload n iam ser suficientes(n tenho no entanto provas a favor ou contra, ate pq muito pouca gente deve atingir os 24Mb)

agora tenho 1 MB e preciso de cerca de 6KB de upload livre, portanto acho q existe uma proporcionalidade
 
Post de qualidade!

De facto já me tinha apercebido disto há uns anos quanto andava a tentar optimizar o meu router caseiro (um pc velho c/ linux).
Acrescento só que o tráfego de TCP ACKs varia conforme o protocolo da camada de aplicação (HTTP, Bittorrent, SSH, etc.) O pacote típico de um TCP ACK de HTTP (browsing the web) tem apenas 40 bytes pois não tem dados em piggyback (cliente-servidor típico), e logo é pequeníssima a largura de banda de upstream que precisa para não baixar o downstream (muitos pacotes/tempo). Já os TCP ACKs de upstream de uma aplicação p2p não se distinguem dos pacotes de downstream, pois não existe a separação natural entre cliente e servidor, e os ACKs são usados para retornar dados (menos pacotes/tempo).
É por isso indispensável que o nosso upload nunca esteja no limite, senão os ACKs são perdidos e o servidor remoto baixa a tranferência e o nosso download (congestion avoidance do TCP).
Eu uso um esquema de prioridades, onde atribuo prioridade máxima a este tipo de ACKs HTTP. Desta forma mesmo com todos os p2p da rede a bombar ao máximo no upload, as páginas abrem-me sempre rápido, e consigo fazer downloads HTTP a taxas elevadas ~10Mbits com o upload no máximo.

TL
 
c) Não se pode aumentar indefinidamente o débito downstream sem aumentar o upstream, visto que todo o tráfego TCP está sujeito ao respectivo tráfego de "acknowlege" [4] que flui no sentido inverso. Isto pode ser rigorosamente calculado em função dos tamanhos dos pacotes enviados. No entanto um simples teste sobre ADSL com ferramentas acessíveis a todos (wget, iptraf) permite obter que:

%tcp upstream rate ~ 1,84 %

de onde se obtém:

2 Mbps => 36.80 kbps
4 Mbps => 73.61 kbps
8 Mbps => 147.22 kbps
16 Mbps => 294.45 kpbs
20 Mbps => 368,06 kbps
24 Mbps => 441,67 kbps



Estes cálculos estão errados.
O TCP permite enviar ACK apenas entre N pacotes, em que N pode ser até 65000.
Em Windows, este valor varia entre 1 e 255.
 
Estes cálculos estão errados.
O TCP permite enviar ACK apenas entre N pacotes, em que N pode ser até 65000.
Em Windows, este valor varia entre 1 e 255.

Esses "cálculos", não são cálculos, embora os cálculos se possam fazer.

Os valores apresentados são medidas experimentais efectuadas numa máquina Linux com kernel 2.6.x e configuração TCP default. Resultados experimentais não são certos nem errados... são como são.

O teste consistiu em fazer downloads simultâneos (HTTP) e medir o tráfefo resultante no sentido inverso. O facto de se poderem fazer afinações de stack TCP como referes, em nada altera a questão.
 
O teste consistiu em fazer downloads simultâneos (HTTP)


O erro do teste está precisamente aqui. O tráfego em SYNs é directamente proporcional ao número de sessões TCP activas.

Numa máquina Linux, com apenas 1 sessão TCP activa, com débito de 100Mbps, o tráfego de SYNs não chega a 10 Kbps, experimental.
 
olá!

Para obter uma velocidade de upstream superior, indo pela opção de 2 pacotes do mesmo ISP, tipo a Netrabo 18/1 mbps x 2 que preços sao de esperar ?! Há algum preço especial para quem tente fazer estas cenas ?

Em termos de ligação, seria um novo cabo a chegar aqui a casa ou na mesma ligação de cabo partia-se em 2 ?

Obrigado!
 
olá!

Para obter uma velocidade de upstream superior, indo pela opção de 2 pacotes do mesmo ISP, tipo a Netrabo 18/1 mbps x 2 que preços sao de esperar ?! Há algum preço especial para quem tente fazer estas cenas ?

Em termos de ligação, seria um novo cabo a chegar aqui a casa ou na mesma ligação de cabo partia-se em 2 ?

Obrigado!

info aqui
 
bem mas o que gostava era mesmo de ter 18 mpbs 1mpbs de upstream no pacote residencial...ppois o netempresas é muita caro e nao tem isso antes do 30 mbps.
 
Fala com eles existia um pacote para clientes residências / empresariais que por mais x por mês eles aumentam APENAS o upload.

Melhores Cumprimentos
 
O erro do teste está precisamente aqui. O tráfego em SYNs é directamente proporcional ao número de sessões TCP activas.

Numa máquina Linux, com apenas 1 sessão TCP activa, com débito de 100Mbps, o tráfego de SYNs não chega a 10 Kbps, experimental.

A questão é que não se consegue ter uma única sessão activa com o débito todo:

1) porque nem sempre o servidor tem essa largura upstream disponivel de forma não controlada (é habitual haver controle por IP)
2) porque o débito máximo de uma sessão individual TCP está limitado pela latência entre os dois peers

O ponto 2), que muita gente desconhece, significa que se tiveres um link dedicado de 10Gbps em fibra óptica entre dois pontos distantes do planeta nunca vais conseguir utilizar nada que se pareceça com o valor máximo numa única sessão TCP.

Em conclusão:

O teste foi feito num cenário realista, com o número mínimo de sessões TCP necessárias a atingir a largura de banda máxima.




 
A questão é que não se consegue ter uma única sessão activa com o débito todo:

1) porque nem sempre o servidor tem essa largura upstream disponivel de forma não controlada (é habitual haver controle por IP)
2) porque o débito máximo de uma sessão individual TCP está limitado pela latência entre os dois peers

Nenhum dessas duas condições são da responsabilidade do ISP.

Já agora, o último não é verdade.
 
Nenhum dessas duas condições são da responsabilidade do ISP.

Já agora, o último não é verdade.

Não são da responsabilidade do ISP... por outro lado já é da sua responsabilidade saber que as condições existem e são incontornáveis.

Relativamente ao último ponto, sugiro que se informe melhor antes de falar.

Veja as curiosas formulas no final deste artigo:

http://www.potaroo.net/ispcol/2004-08/2004-08-isp.htm

e uma ilustração igualmente esclarecedora.

http://www.potaroo.net/ispcol/2005-06/fig4.jpg

do Geoff Huston.
 
Relativamente ao último ponto, sugiro que se informe melhor antes de falar.

Eu estou bastante bem informado sobre o TCP Congestion Control, sou das poucas pessoas que alguma vez leu os RFPs que o definem e escreveram código sobre ele.

O RTT apenas influência o débito, se os buffers nas pontas não suportarem o débito*RTT.

Segundo a tua bela teoria, não seria possível teres ligações transpacíficas a 10Gbps.

Se tivesses ligo o resto da aula em http://www.potaroo.net/ispcol/2005-06/faster.html não terias usado a simulação sem saber do que se trata.
 
Última edição:
Back
Topo