Avalia¸c˜ao das Propostas

Uma avalia¸c˜ao do TCP Limited Transmit ´e apresentada em [64]. Neste artigo ´e demons- trado que o uso deste algoritmo reduz a latˆencia para a transmiss˜ao dos arquivos, j´a que reduz a ocorrˆencia de timeouts. Apesar de ter sido desenvolvido com o objetivo otimizar o mecanismo de recupera¸c˜ao de perdas do TCP para conex˜oes TCP de curta dura¸c˜ao. Neste artigo ´e apresentado que conex˜oes TCP de longa dura¸c˜ao tamb´em se beneficiam, j´a que a redu¸c˜ao significativa na ocorrˆencia de timeouts faz com que a diminui¸c˜ao na latˆencia seja ainda mais acentuada.

Em [11], foi verificado que o uso em conjunto do algoritmo Limited Transmit com TCP Reno (reno-lr ), TCP NewReno (newreno-lt) e TCP Sack (sack-lt), pode melhorar o desempenho do TCP na recupera¸c˜ao de perdas. As trˆes vers˜oes do TCP foram comparadas em ambiente dinˆamico de rede fazendo-se simula¸c˜oes exaustivas utilizando o simulador de redes NS [65]. Um gerador de tr´afego foi utilizado para gerar tr´afegos espec´ıficos FTP e WEB baseados nos modelos das distribui¸c˜oes estat´ısticas que os descrevem. A carga foi variada para cada tipo de tr´afego com o intuito de verificar a eficiˆencia das varia¸c˜oes TCP em diferentes est´agios de congestionamento. Neste artigo, tamb´em foi verificado que conex˜oes TCP de curta, bem como de longa dura¸c˜ao beneficiam-se com o uso do TCP

Limited Transmit.

No algoritmo Fast Retransmit apresentado em [31], apenas um ´unico pacote ´e re- transmitido depois que um ACK parcial ´e recebido. A id´eia ´e utilizar um mecanismo conservativo para minimizar retransmiss˜oes desnecess´arias de pacotes, retransmitindo-se

um ´unico segmento perdido por RTT. Desta forma, quando v´arios segmentos s˜ao perdi- dos em uma ´unica janela, o TCP emissor ir´a se recuperar das perdas apenas ap´os um atraso consider´avel. Por este motivo, esperava-se que o TCP que apresentasse o melhor desempenho seria o que fizesse uso em conjunto do algoritmo de Limited Transmit com o TCP SACK, sack-lt. Entretanto, o que apresentou o melhor desempenho, reduzindo o n´umero de ocorrˆencias de timeout e com maiores valores de goodput foi o newreno-lt (uso em conjunto do algoritmo de Limited Transmit com o TCP NewReno).

Uma justificativa para o NewReno ter um melhor desempenho ´e que existem evidˆencias de que as informa¸c˜oes retornadas na op¸c˜ao SACK n˜ao est˜ao sendo utilizadas pelo TCP emissor para fazer as retransmiss˜oes dos segmentos perdidos [66]. Desta forma, mesmo quando h´a suporte a SACK, o TCP emissor ter´a o mesmo comportamento do TCP Reno quando m´ultiplas perdas acontecem, e assim, um comportamento inferior ao TCP NewReno. Uma poss´ıvel ´e o fato de que quando SACK foi definido em [59], n˜ao foram especificados mecanismos de controle de congestionamento espec´ıficos para serem uti- lizados em conjunto com SACK. Assim, apesar de terem suporte a SACK, algumas im- plementa¸c˜oes n˜ao usam as informa¸c˜oes contidas nos blocos SACK para decidir quais segmentos devem ser retransmitidos.

Em [67] ´e apresentada o TCP FACK, uma proposta que utiliza os blocos SACK para fazer uma estimativa mais precisa sobre a quantidade de dados que est´a em trˆansito, e as- sim, determinar mais corretamente a taxa de transmiss˜ao mais adequada com o estado da rede. Em [68], ´e apresentada uma proposta de um mecanismo conservativo de recupera¸c˜ao de perdas para o TCP. A id´eia ´e substituir o algoritmo de Fast Recorevey proposto em [7] por um algoritmo que utiliza a op¸c˜ao SACK para determinar quais e quantos segmentos devem ser retransmitidos na ocorrˆencia de m´ultiplas perdas.

Gerenciamento de Filas em Redes

TCP/IP

Os mecanismos de controle de congestionamento do protocolo n˜ao s˜ao suficientes para prover servi¸cos de boa qualidade em todas as situa¸c˜oes, como tamb´em n˜ao impedem que o congestionamento ocorra, dado que outros protocolos n˜ao diminuem a taxa de transmiss˜ao na presen¸ca de congestionamento. Desta forma, mecanismos adicionais s˜ao necess´arios para se obter controle de congestionamento fim-a-fim.

Os mecanismos de controle de congestionamento nos roteadores monitoram o tamanho da fila, podendo detectar o congestionamento incipiente e tomar decis˜oes sobre a noti- fica¸c˜ao do congestionamento e o descarte de pacotes. Dentre os mecanismos de controle de congestionamento presentes nos roteadores est˜ao os algoritmos de gerenciamento de filas, que descartam pacotes quando necess´ario.

Neste cap´ıtulo, s˜ao discutidas pol´ıticas de gerenciamento de filas em redes TCP/IP. ´

E apresentada, primeiramente, a mais simples das pol´ıticas denominada tail drop, e s˜ao levantados seus principais problemas. Na se¸c˜ao 3.2, discorre-se sobre a necessidade de utiliza¸c˜ao de um novo mecanismo de gerenciamento de filas denominado gerenciamento ativo de filas ou AQM. Na se¸c˜ao 3.3 s˜ao discutidos os requisitos que as pol´ıticas de gerenciamento ativos de filas devem atender. Na se¸c˜ao 3.4 ´e apresentada RED, que ´e a pol´ıtica padr˜ao de AQM utilizada na Internet. Na Se¸c˜ao 3.5, s˜ao descritas algumas pol´ıticas de AQM propostas para aprimorar RED: FRED, ARED, FPQ, BLUE e sua varia¸c˜ao SFB. Na Se¸c˜ao 3.6, s˜ao introduzidas algumas pol´ıticas anal´ıticas de AQM, de- senvolvidas utilizando-se a Teoria da Otimiza¸c˜ao e a Teoria do Controle. Na Se¸c˜ao 3.7, o mecanismo Explicit Congestion Notification (ECN), que permite dissociar a notifica¸c˜ao do congestionamento do descarte de pacotes ´e introduzido.

3.1

Tail Drop

A forma mais simples de se fazer o gerenciamento do tamanho das filas dos roteadores ´e conhecida como tail drop. Nesta t´ecnica, existe um valor m´aximo para o tamanho da fila, em termos de n´umero de pacotes. O roteador aceita pacotes at´e que o valor m´aximo de pacotes na fila seja atingido, depois disto os pacotes seguintes ser˜ao descartados, ou seja, pacotes s˜ao aceitos enquanto existir espa¸co na fila [69].

Esta t´ecnica foi utilizada por muitos anos na Internet por ser muito simples, no entanto, apresenta algumas deficiˆencias:

Monop´olio: tail drop permite que uma simples conex˜ao ou um conjunto m´ınimo de fluxos monopolize o espa¸co na fila, enquanto outras conex˜oes tˆem seus pacotes descartados por falta de espa¸co. Um outro problema relacionado `a justi¸ca, ´e que tail drop n˜ao faz descarte de pacotes de um tr´afego proporcional a sua utiliza¸c˜ao da fila. Desta forma, um tr´afego pode ter seus pacotes descartados mesmo sem ter utilizado nenhum recurso da fila. Al´em disto, como apenas alguns fluxos monopolizam a fila, os fluxos que transmitem em rajada ser˜ao prejudicados, j´a que encontrar˜ao a fila cheia e ter˜ao todos os seus pacotes descartados, e portanto, sua taxa de perda ser´a maior; Filas Cheias: tail drop permite a ocupa¸c˜ao total da fila por muito tempo, dado que

sinaliza congestionamento apenas quando a fila est´a cheia. Quando a fila est´a cheia, pacotes de tr´afego em rajada s˜ao descartados podendo causar injusti¸cas, como des- crito anteriormente. Al´em disto, o problema de filas cheias favorece a ocorrˆencia do fenˆomeno de sincroniza¸c˜ao global, que ocorre quando diversos fluxos TCP tem pacotes perdidos, e assim, reduzem simultaneamente sua taxa de transmiss˜ao.