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

Excelente post leexouce. http://members.shaw.ca/wenpigsfly/smileys/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 (http://www.zon.pt/Empresas/Internet/detalheinternet.aspx?detail=XzUC1C1)

info aqui (http://www.zon.pt/Empresas/Internet/detalheinternet.aspx?detail=XzUC1C1)

obrigado!

E tenho de ser empresario ?! Posso ser como particular ou nao?
E se for como liberal será que aceitariam.....so querem é mesmo facturar....hehe:004:

obrigado!

E tenho de ser empresario ?! Posso ser como particular ou nao?
E se for como liberal será que aceitariam.....so querem é mesmo facturar....hehe:004:

isso já não te sei dizer... liga-lhes...

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.

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.

E no caso geral não se tem qualquer tipo de controle sobre os buffers, os quais são partilhados para todo o tráfego que lá passa. E a experiência mostra que com uma única stream TCP obténs um determinado débito, mas com várias ligadas streams ao mesmo servidor o débito cresce.

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

Bummer. Não percebeste o que está em causa. A agregação de tráfego num link é uma coisa. Uma stream TCP isolada nesse mesmo link, é outra.

De qq modo, o artigo fala por si.

E no caso geral não se tem qualquer tipo de controle sobre os buffers


Errado. O TCP congestion control baseia-se apenas na gestão dos buffers em cada ponto.


Bummer. Não percebeste o que está em causa. A agregação de tráfego num link é uma coisa. Uma stream TCP isolada nesse mesmo link, é outra.


Eu percebo perfeitamente o que está em causa. A conclusão que queres tirar do artigo é que não existe. É bastante fácil demonstrar isso. Basta teres 2 PCs ligados por Gb, e fazeres uma tranferência por FTP, de onde obtens 120MB/s, com 1 ligação.

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.

Basta que haja perda de pacotes em qualquer ponto do trajecto, para que a recuperação dependa do RTT. E perda de pacotes pode haver muito facilmente.

Um exemplo disso é teres um emissor a 100Mbps e um link de saída a 10Mpbs. O emissor pensa que pode emitir a 100 e vai acelerar até detectar perda de pacotes e depois entra no ciclo de congestion control, onde a velocidade média de emissão é inferior a 10Mbps.

(entretanto com essa brincadeira o emissor vai mantendo cheio o buffer de saída aumentando ainda mais o RTT, mas essa parte com QoS resolve-se)

Errado. O TCP congestion control baseia-se apenas na gestão dos buffers em cada ponto.



Eu percebo perfeitamente o que está em causa. A conclusão que queres tirar do artigo é que não existe. É bastante fácil demonstrar isso. Basta teres 2 PCs ligados por Gb, e fazeres uma tranferência por FTP, de onde obtens 120MB/s, com 1 ligação.

Esta "demonstração" é equivalente a medir a performance do IC19 fazendo voltas de carro no Autódromo do Estoril (é obrigatório fazer analogias com carros quando as pessoas não se entendem :-) )

Isto porque no cenário indicado - 2 PCs ligados por Gb - tem-se:

- latência muitíssimo baixa, RTT próximo de zero
- ausência de botlleneck; não há perda de pacotes nem congestão

Ou seja, as duas condições que originam o fenómeno não estão presentes.

Neste caso, de facto só depende dos buffers suportarem débito*RTT, mas este cenário não representa aquilo de que se está a falar nesta thread.

bla bla bla bla bla



É o suficiente para provar que os teus cálculos do upstream mínimo estão errados, e carecem de verificação experimental.