Um dos desafios atuais dos provedores de Internet está na demanda por banda. Os planos precisam ser cada vez maiores para atender uma necessidade crescente dos usuários, por outro lado, os preços desses planos são cada vez menores, o que torna difícil o provedor fechar essa conta. O que o provedor deve fazer para alcançar a expectativa do cliente se mantendo no mercado competitivo?
Uma forma inteligente unindo o comercial ao técnico e utilizada por muitos provedores é o sistema de rajada (burst). O provedor formata um plano com velocidade nominal maior e depois de um pequeno período de rajada de dados nessa velocidade, diminui a velocidade para a configurada nos parâmetros do plano.
Por exemplo, Plano 10Mbits: possui velocidade garantida de 5Mbits para Download e 3Mbits para Upload, entregando picos de 10Mbits (rajada).
Essa estratégia de mercado é inteligente, contudo, uma mudança crescente do perfil dos usuários tem exigido dos provedores cada vez mais qualidade no acesso. Hoje, além dos usuários consumirem mais, migrando o entretenimento para dentro de suas casas, como jogos online e filmes em HD, é cada vez mais comum usuários que realizam constantemente testes com velocímetros, pings e até traceroutes. É por esse motivo que os provedores precisam se adaptar, criando cada vez mais condições de melhorar a experiência do usuário, inclusive nesses testes.
A melhor forma de se fazer isso é entregar o máximo de conteúdo possível na velocidade nominal do plano sem aumentar custos. O conteúdo local do provedor por exemplo, emails dos clientes, sites hospedados no próprio provedor, porque não entregar todo esse conteúdo local na velocidade nominal do plano? Isso além de não aumentar os custos, melhora consideravelmente a experiência do usuário.
Para apresentar esse conceito, as configurações descritas foram realizadas no MikroTik. Além de muito prático para aplicar e visualizar as configurações é um sistema muito comum entre os provedores.
Vamos iniciar pela regra de limitação de banda. Para um controle mais eficaz, dando prioridade a alguns tipos de tráfego, é preciso utilizar as Queues Tree.
Nesse exemplo, o tráfego será dividido e priorizado entre 4 subfilas.
NAVEG é a fila destinada a velocidade nominal do plano. Aplicando o exemplo acima, seria 10Mbits.
DOWN é a fila destinada a velocidade garantida do plano, nesse caso 5Mbits.
ICMP e VOZ serão as filas destinadas ao conteúdo respectivo aos seus nomes.
Agora, uma vez criado as queues, precisamos marcar o tráfego.
Inicialmente, todos os pacotes são marcados como DOWN para que sejam limitados a velocidade de download, que é 50% da velocidade nominal do plano. Contudo, desse ponto em diante, queremos retirar desse tráfego geral o que desejamos dar prioridade e/ou velocidades diferentes.
Tráfego ICMP e VOZ são tratados separadamente. Garantindo uma prioridade para esses serviços, melhoramos a experiência do usuário e o “protegemos” dele mesmo. Por mais entendido que o usuário seja para realizar testes de pings, velocímetros e outros, ele nunca se da conta que já está utilizando parte ou toda a banda contratada comprometendo os resultados dos seus testes. Então, cabe aos provedores tomarem medidas para minimizarem isso.
Garantindo prioridade e um pequeno limite de banda reservada para o ICMP, os testes de latência dos jogos ou de outros testes como o velocímetro, terão resultados muito melhores.
Agora um dos pontos altos desse artigo, por que deixar o conteúdo do provedor concorrer com outros conteúdos, se relativamente não há custos que inviabilizem o provedor entregar esse conteúdo em uma velocidade maior? Pelo contrário, esse é exatamente o tipo de tráfego que estamos procurando para entregar na velocidade nominal do plano.
Com uma simples marcação desse tráfego, (provavelmente pelo endereço de origem dos servidores do provedor), é possível entregar esse conteúdo na velocidade nominal do plano melhorando então a experiência do usuário em relação a velocidade do acesso.
Seguindo o mesmo conceito, o próximo passo é procurar por outros conteúdos que não tenham custo ou ao menos, custos mais acessíveis para marcar esses pacotes e entregá-los na velocidade nominal do plano.
Imagine por exemplo o provedor que possua um cache de conteúdo. Por que não, também entregar esse conteúdo de custo muito mais acessível em uma velocidade maior? Nesse caso, como desejamos que os endereços de origem e destino sejam transportados de forma transparente, não será possível marcar esse conteúdo por esses endereços. Como então seria possível também entregar esse tráfego na velocidade nominal do plano? É aqui que podemos aplicar a marcação DSCP (Differentiated services code point), uma marcação realizada nos pacotes desejados que será encaminhada entre os roteadores da sua rede sem ser alterada ou só será alterada se algum roteador for configurado para isso, caso contrário, uma marcação DSCP realizada no primeiro roteador, chegará até o último roteador, permitindo que decisões em relação aquele tipo de tráfego sejam tomadas.
Muitos caches permitem marcar o conteúdo que o próprio cache está entregando com uma marca DSCP e essa marca poderá ser resgatada no servidor que atende o usuário permitindo entregar esse conteúdo na velocidade nominal do plano, melhorando consideravelmente a experiência do usuário.
Nesse exemplo, todo conteúdo que o cache possui, foi entregue com a marca 22 no DSCP. Em seguida, outro roteador, o concentrador PPPoE, analisa os pacotes procurando pela marca DSCP 22 e ao encontrá-la, encaminha esse pacote para ser entregue na velocidade nominal do plano.
Desta mesma forma, outros conteúdos poderão ser marcados e entregue com mais velocidade. Tráfego de CDNs como Akamai e GGC, tráfego de peering entre provedores e PTTs.
Aplicando técnicas como esta, melhoramos a experiência do usuário sem aumentar custos, permitindo aos provedores entregar planos cada vez maiores, garantindo a satisfação do cliente.
