AULA 04 FUNDAMENTOS TÉCNICOS DOS PROTOCOLOS DE ALTA VELOCIDADE

1. AULA 04 FUNDAMENTOS TÉCNICOS DOS PROTOCOLOS DEALTA VELOCIDADE Diogo Nunes de Oliveira Here comes your footer

2. Fundamentos Técnicos dos Protocolos de Alta Velocidade • No começo dos anos 90 começaram a aparecer as redes operando a velocidade de gigabits. • A primeira reação das pessoas foi de usar protocolos antigos nessas redes, mas logo surgiram vários problemas. • Quais foram esses problemas? • Como os novos protocolos devem ser implementados para solucioná-los?

3. Sequenciação • O primeiro problema é que muitos protocolos utilizam números de seqüência de 16 ou 32 bits. • Antigamente, 232 era um valor praticamente infinito. Contudo, com as novas taxas de Gbps, são necessários cerca de 32s somente para transmitir 232 bytes. • Se os números de seqüência se referirem a bytes, como ocorre na rede TCP, então eles passam a se repetir a cada 32 segundos.

4. Sequenciação • Na Internet, por exemplo, o tempo máximo de vida dos pacotes é de 120 segundos. • Logo, poderá haver repetição de número de seqüência de bytes que ainda não foram confirmados pelo receptor. • O problema é que muitos projetistas de protocolos assumiram que o tempo total para a utilização de toda a faixa numérica das seqüências é muito maior que o tempo de vida máximo de um pacote. • Em uma velocidade de Gigabits, essa suposição caiu por terra.

5. Velocidade • Um segundo problema é que a velocidade dos meios de comunicação tem melhorado com maior rapidez do que a velocidade dos computadores. • Logo, os protocolos estão exigindo mais das CPU’s em termos de processamento e, para que isto não gere um colapso nos sistemas futuros, os protocolos precisam ser mais simples para exigirem menos processamento das CPU’s.

6. Velocidade • Só para se ter uma idéia, em 1970, a ARPANET operava a 56Kbps, com computadores de 1 MIPS (Mega Instruções por Segundo). Os quadros possuíam 1008 bits. Assim eram processadores 56 pacotes por segundo, com 18ms disponíveis para cada pacote, sendo que um host poderia usar 18.000 instruções para processar um pacote. • Isto ocuparia toda a CPU, logo, seria possível usar 9.000 instruções por segundo para deixar metade da CPU alocada para outros trabalhos pesados.

7. Velocidade • Já nos computadores de 100 MIPS, o fluxo de pacotes é de 30.000 p/s e, portanto, o pacote deve ser processado em 15ms para preservarmos metade da CPU somente para tratar dos protocolos. • Em 15ms um computador de 100 MIPS executa 1.500 instruções por segundo, o que equivale a 1/6 do que os hosts antigos tinham disponível. • Além disso, as modernas instruções RISC fazem menos do que as instruções CISC, o que significa que o problema é ainda maior.

8. Retardo de transmissão • Um terceiro problema é que o protocolo go-back-n tem um desempenho ruim em linhas com um grande produto da largura de banda pelo retardo. Considere, por exemplo, uma linha de 4.000 km operando a 1 Gbps. • O tempo de transmissão de ida e volta é de 40ms, durante o qual um transmissor pode enviar 5 Mbytes. • Se algum erro for detectado, serão necessários pelo menos 40ms para o transmissor ser informado. • Se o go-back-n for utilizado, o transmissor terá de enviar novamente não só o pacote com problemas, mas todos os 5 megabytes subseqüentes. Isto significa um enorme desperdício de recursos da rede.

9. Largura de Banda • Um quarto problema é a diferença entre as linhas de gigabits e as de megabits. • Estas são limitadas pela largura de banda e aquelas pelo tempo de retardo da linha. • Assim, o aumento da largura de banda em linha de gigabits não produz qualquer efeito em termos de performance, pois o tempo de retardo é extremamente elevado se comparado com o tempo que o transmissor gasta para inserir os bits no cabo. • A 1 Gbps, o retardo de 40ms da viagem de ida e volta domina o 1ms necessário para colocar os bits no cabo de fibra ótica.

10. Largura de Banda • A figura demonstra que os protocolos stop-and-wait, como o RPC, têm um limite superior inerente em seu desempenho. Esse limite é ditado pela velocidade de luz. • Não há progresso tecnológico em termos de ótica que possa melhorar isso (novas leis da física, entretanto, poderiam ajudar).

11. Variações de taxa • Um quinto problema que vale a pena mencionar não é tecnológico nem proveniente dos protocolos, e sim um resultado das novas aplicações multimídia que operam em gigabits, cujas variações nos tempos de chegada dos pacotes é tão importante quanto o próprio retardo médio. • Uma taxa de transferência baixa mas constante é quase sempre melhor do que uma taxa alta mas flutuante.

12. Fundamentos Técnicos dos Protocolos de Alta Velocidade • Algumas soluções • O axioma que todos os projetistas de redes de gigabits deveriam saber de cor é o seguinte: “Crie projetos para obter mais velocidade e não para otimizar a largura de banda.”

13. Simplificação no processamento • Antigamente, os protocolos eram projetados para diminuir o número de bits no cabo. Hoje em dia, há largura de banda suficiente. • O problema está no processamento dos protocolos que devem ser projetados para ser o menor possível. • Uma maneira de aumentar a velocidade é usar interfaces rápidas de rede. Contudo, isto encareceria estas interfaces. Logo, utilizam-se interfaces mais lentas e baratas. • Para que a CPU principal não fique muito ociosa enquanto a placa de rede trata do recebimento dos bits do cabo, o ideal é simplificar os protocolos e fazer com que a CPU principal realize o trabalho.

14. Eliminação do Feedback • Outro fator a ser levado em consideração na implementação dos protocolos de alta velocidade é o “feedback”. • Como o tempo de retardo nas linhas de alta velocidade é muito alto, então o “feedback” deve ser evitado. Leva muito tempo para o receptor enviar um sinal para o transmissor. • Um exemplo de “feedback” é controlar a taxa de transmissão através de um protocolo de janela deslizante. Para evitar os longos retardos, é melhor usar um protocolo baseado na taxa. Nesse protocolo, um transmissor pode enviar tudo o que quiser, desde que nunca mais rápido que uma taxa negociada previamente com o receptor.

15. Eliminação do Feedback • Um outro exemplo de “feedback” é o algoritmo de início lento de Jacobson, que promove várias investigações para descobrir qual o volume de tráfego que uma rede pode escoar. • Isto desperdiça um grande volume de largura de banda. Um esquema eficiente é fazer com o que o transmissor e o receptor reservem os recursos necessários no momento do estabelecimento da conexão. • Em resumo, buscar altas velocidades leva o projeto a uma operação voltada a conexão.

16. Leiaute dos pacotes • O leiaute dos pacotes é uma questão importante nas redes de gigabits. O cabeçalho deve ter um mínimo de campos possível para reduzir o tempo de processamento. • Estes campos devem ser grandes o suficiente para facilitar o processamento e o alinhamento de palavras, e não deve haver problemas como a repetição de números de seqüência enquanto pacotes antigos ainda estiverem circulando pela rede. • O cabeçalho e os dados devem ter soma de verificação distintas para que os dados sejam extraídos se e somente se o checksum do cabeçalho estiver correto.

17. Leiaute dos pacotes • O tamanho máximo dos dados deve ser grande de forma que permita uma operação eficiente mesmo com longos retardos. • Além disso, quanto maior for o bloco de dados, menor será o “overhead” da rede e maior a eficiência de transmissão.

18. Envio de dados na solicitação de conexão • Outra característica valiosa é a possibilidade de enviar um volume normal de dados junto com a solicitação de conexão. • Assim, economiza-se o tempo de uma viagem de ida e volta.

19. Software do protocolo • Por fim, é interessante fazer algumas considerações quanto ao software do protocolo. • Um procedimento chave é concentrar-se em um caso bem sucedido. • Muitos protocolos antigos tendem a enfatizar o que fazer se algo der errado, por exemplo, quando um pacote é perdido. • Para tornar os protocolos mais rápidos, o projetista deve se empenhar em minimizar o tempo de processamento e tomar como importância secundária um erro de perda pacote.

20. Software do protocolo • Uma segunda questão relacionada com o software do protocolo é minimizar o tempo de cópia dos dados da memória da interface de rede para a memória do computador. • Deve-se usar blocos contíguos de dados e, em vez de usar rotinas de loops para a cópia, deve-se usar uma seqüência enfileirada de instruções MOVE com tantas instruções quanto for o tamanho em bytes do bloco de dados, ou seja, deve haver uma instrução MOVE para cada byte a ser copiado. • A rotina de cópia deve ser cuidadosamente desenhada em código assembly, pois ela é uma das funções mais usadas pelo protocolo.

21. Conclusão • No final dos anos 80, houve um pequeno arroubo de interesse em protocolos rápidos e de uso especial, como o NETBLT (Clark et al., 1987), o VTMP (Cheriton e Williamson, 1989) e o XTP (Chesson, 1989). • Pode-se encontrar uma pesquisa em Doeringer et al., 1990. A tendência futura, entretanto, é simplificar os protocolos de uso geral para torná-los rápidos também. • O ATM já apresenta muitas das características que foram discutidas anteriormente, e o Ipv6 também.

22. Dúvidas

23. Exercício • Pesquisa na internet • O que é o protocolo go-back-n? • O que é o protocolo de janela deslizante? • O que é o protocolos stop-and-wait? • Atividade: 15 minutos