0

UNIVERSIDADE FEDERAL DE SANTA CATARINA - UFSC CAMPUS ARARANGU

Elias Renato da Silva Diniz Luiz Fernando Rosso Perraro Proxrio Manoel Felisberto

TRANSMISSION CONTROL PROTOCOL: Selective Acknowledgment (TCP SACK)

Ararangu, maio de 2012.

Elias Renato da Silva Diniz Luiz Fernando Rosso Perraro Proxrio Manoel Felisberto

TRANSMISSION CONTROL PROTOCOL: Selective Acknowledgment (TCP SACK)

Trabalho apresentado como requisito parcial para obteno de aprovao na disciplina Rede de Computadores I, no Curso de Tecnologia de Informao e Comunicao, na Universidade Federal de Santa Catarina. Prof. Dr. Ricardo Alexandre Reinaldo de Moraes

Ararangu, maio de 2012.

RESUMO

O presente trabalho trata sobre o protocolo da camada de transporte da internet que oferece um servio confivel de transferncia de dados, o Transmission Control Protocol (TCP). Este protocolo, entre outras funcionalidades, implementa o controle de congestionamento da rede. Em um ambiente onde ocorrem perdas de vrios
pacotes o seu desempenho fica seriamente comprometido, uma vez que o reconhecimento cumulativo oferece pouca informao ao protocolo remetente. Assim, um mecanismo

de reconhecimento seletivo (SACK), combinado com uma poltica de retransmisso seletiva, pode ajudar a superar essa limitao. O TCP receptor envia pacotes de SACK para o remetente informando ao remetente os dados que foram recebidos, cabendo ao remetente retransmitir apenas os segmentos de dados em falta.

Palavras-chave: TCP SACK, reconhecimento seletivo, controle de congestionamento.

SUMRIO

1 2 2.1 2.2 2.3 2.4 2.5 3 3.1 3.2 3.3 3.4

INTRODUO.................................................................................................. 4 FUNCIONAMENTO GERAL DO PROTOCOLO TCP...................................... 5 A CONEXO TCP............................................................................................. 5 O SEGMENTO TCP.......................................................................................... 6 TRANSFERNCIA CONFIVEL DE DADOS.................................................. 8 CONTROLE DE FLUXO................................................................................... 8 CONTROLE DE CONGESTIONAMENTO........................................................ 9 CONTROLE DE CONGESTIONAMENTO DO TCP SACK............................ 10 SACK-PERMITTED...................................................................................... 11 FORMATO DO SACK..................................................................................... 11 GERANDO OPES SACK: Comportamento do Receptor de Dados.......... 12 INTERPRETANDO A OPO SACK E A ESTRATGIA DE

RETRANSMISSO: Comportamento do Remetente de Dados.................... 14 3.5 3.6 4 5 6 EFICINCIA E COMPORTAMENTO PARA O PIOR CASO.......................... 15 EXEMPLOS DE OPO SACK...................................................................... 16 COMPARAO DO TCP SACK VERSUS OUTROS TCPs......................... 18 CONSIDERAES FINAIS........................................................................... 21 REFERNCIAS BIBLIOGRFICAS............................................................... 22

1 INTRODUO

O sculo passado foi muito significativo em termos de desenvolvimento tecnolgico. O pequeno lapso de tempo decorrido entre a descoberta dos materiais semicondutores e sua utilizao na construo de componentes eletrnicos propiciaram o rpido desenvolvimento dos circuitos integrados e,

consequentemente, sua utilizao na construo de computadores.

Com o desenvolvimento dos computadores sentiu-se a necessidade de compartilhar os dados neles existentes. Assim, iniciam-se as pequenas redes de computadores, inicialmente para conectar centros de pesquisa (Universidades) e em muito pouco tempo j tnhamos a nosso dispor a World Wide Web (WWW) como uma das principais utilizaes daquela que chegou para alterar nossos hbitos, a Internet.

A grande maioria das aplicaes existentes na Internet utilizam para seu funcionamento os servios oferecidos pelo protocolo TCP (Transmission Control Protocol), como por exemplo o transporte confivel dos dados. Atualmente, em um enlace tpico da Internet, medidas indicam que 95% dos bytes transportados so de trfego TCP, sendo que destes, 75% so provenientes de aplicaes HTTP. Desta forma, o desempenho do protocolo TCP de fundamental importncia para o desempenho global da Internet.

Conforme Tanenbaum (2003), o TCP foi projetado tendo em mente o oferecimento de um fluxo confivel de bytes fim-a-fim sobre uma camada de rede no-confivel. Uma das caractersticas mais importantes desse protocolo sua capacidade de adaptar-se dinamicamente s propriedades dessa camada de rede no confivel e ser robusto diante dos muitos tipos de falhas que podem ocorrer.

2 FUNCIONAMENTO GERAL DO PROTOCOLO TCP

O TCP (Transmission Control Protocol) um protocolo da camada de transporte, orientado a conexo, desenvolvido em face de necessidade de garantias que deveriam ser oferecidas a uma conexo a fim de prover a entrega confivel dos dados em uma inter-rede no confivel. Para cumprir sua funo o TCP implementa um algoritmo que potencializa as vantagens apresentadas pelos protocolos GoBack-N e Repetio Seletiva, tais como: deteco de erro, retransmisses, reconhecimentos cumulativos, temporizador, campos de cabealho para nmeros de sequncia e de reconhecimento (Kurose e Ross, 2010).

2.1 A Conexo TCP

O TCP utiliza soquetes (portas) para efetuar a comunicao entre dois processos de aplicaes residentes em sistemas finais diferentes. Porm, antes de efetivamente iniciar o envio de dados, estes processos se apresentam, ou seja, trocam segmentos iniciais para definir como a transferncia de dados ser efetuada e por este motivo se diz que um protocolo orientado a conexo. Assim, as conexes TCP so estabelecidas por meio de um handshake de trs vias (Tanenbaum, 2003).

Possui a caracterstica de enviar e receber dados ao mesmo tempo, entre dois processos, provendo desta forma um servio full duplex. uma conexo ponto a ponto, pois ser sempre entre um nico emissor e um nico receptor.

Para iniciar uma conexo, um lado fica aguardando uma conexo de entrada at que o outro lado faa uma chamada, especificando o endereo IP e a porta a qual deseja se conectar, o tamanho mximo do segmento TCP que est disposto a aceitar, e opcionalmente, alguns dados do usurio. enviado um segmento TCP com o bit SYN ativado e um bit ACK desativado, e fica aguardando uma resposta. Chegando ao destino o TCP receptor verifica se existe algum processo na escuta da porta, esse processo receber o segmento TCP de entrada. Em seguida, ele poder

aceitar ou rejeitar a conexo. Se aceitar, um segmento de confirmao ser retornado.

O encerramento da conexo em um dos sentidos realizado atravs do envio de um segmento com o bit FIN ativado, informando no haver mais dados para transmisso. O recebimento da confirmao do FIN encerra a conexo neste sentido. Assim, so necessrios quatro segmentos para encerrar uma conexo. Porm, juntamente com um ACK pode ser enviado o segundo FIN, baixando para trs segmentos. (Tanenbaum, 2003).

2.2 O Segmento TCP

De acordo com os ensinamentos de Kurose e Ross (2010) o segmento TCP constitudo de um cabealho (com vrios campos, conforme mostra a Figura 1) e um campo de dados, que limitado pelo tamanho mximo do segmento (MSS), o que requer fragmentao de blocos grandes de dados.

Figura 1: Estrutura do Segmento TCP Fonte: Kurose e Ross, 2010, p.177

Para um melhor entendimento das funes de cada campo do cabealho TCP necessrio considerar, inicialmente, que um dos diferenciais deste protocolo ter uma numerao para cada byte de dados.

O cabealho de um segmento TCP formado pelos seguintes campos: - Porta da Fonte e Porta do Destino: de 16 bits cada, usados para identificar as portas (do emissor e do receptor, respectivamente) nas quais os processos da camada superior esto aptas troca de dados com o TCP; - Nmero de Sequncia e Nmero de Reconhecimento: campos de 32 bits, utilizados na implementao de um servio de transferncia confivel de dados do TCP, no qual o nmero de sequncia o nmero do primeiro byte do segmento e o nmero de reconhecimento o nmero do primeiro byte que um hospedeiro espera receber do hospedeiro situado na outra ponta da conexo; - Comprimento do Cabealho: especifica o tamanho do cabealho em palavras de 32 bits (normalmente 20 bytes); - Janela de Recepo: campo de 16 bits, utilizado no controle do fluxo, e serve para especificar quantos bytes um receptor est apto a receber; - Valor de Verificao da Internet: comumente conhecido por checksum, o complemento de 1 da soma de todas as palavras de 16 bits do segmento, que serve para detectar possveis erros; - Ponteiro para Dados Urgentes: normalmente no utilizado. Sua utilizao est vinculada ao flag URG, quando a camada superior marca que h dados urgentes no segmento, ento este campo informa a localizao do ltimo byte desses dados taxados como urgentes; - Opes: de tamanho varivel, porm limitado a 40 bytes. Utilizado, por exemplo, para os TCPs emissor e receptor negociar o MSS, passarem informaes de SACK, negociar um fator de escala de aumento da janela de recepo, como tambm, informaes de temporizao utilizadas no clculo do RTT mdio; - FLAGs: de 6 bits, cada bit com uma funo especfica. URG, define se h dados urgentes no segmento (normalmente no utilizado); ACK, indica se o valor do campo nmero de reconhecimento valido, ou seja, se contm um reconhecimento para um segmento recebido com sucesso; PSH, informa que o receptor deve passar os dados camada superior imediatamente (normalmente no

8 utilizado); RST, SYN e FIN, so utilizados no handshake e para finalizar a conexo.

2.3 Transferncia Confivel de Dados

Uma vez que os segmentos so entregues ao servio de camada de rede da Internet, e este por sua vez no confivel, o TCP prov um servio de transferncia confivel de dados, garantindo que a cadeia de bytes recebida da aplicao emissora ser a mesma entregue aplicao receptora.

Sucintamente, podemos descrever que o TCP implementa apenas um temporizador de time-out para o segmento mais antigo, porm faz o reconhecimento cumulativo, assim faz o envio de segmentos, dentro da capacidade da janela de transmisso, e fica aguardando um ACK vlido para cada segmento.

Neste cenrio, pode ocorrer trs eventos distintos. No primeiro evento o TCP recebe dados da camada superior, encapsula-os e passa ao TCP receptor. O segundo evento ocorreria com o estouro do temporizador de time-out, situao que provocaria a retransmisso do segmento que provocou o esgotamento do temporizador e a reinicializao deste. O terceiro evento ocorre com o recebimento de um ACK vlido, que provoca o deslocamento da janela de transmisso direita at alcanar o prximo segmento que ainda no teve seu recebimento reconhecido. (Kurose e Ross, 2010).

2.4 Controle de Fluxo

Conforme comentado anteriormente, no estabelecimento de uma conexo TCP, cada hospedeiro reserva um buffer de recepo para a colocao dos dados recebidos corretamente e em sequncia, que posteriormente sero passados a aplicao receptora, o que pode demorar algum tempo.

Para evitar que o buffer de recepo seja saturado pelo emissor, o TCP dispe de um servio de controle de fluxo, ou seja, compatibiliza a taxa de emisso de dados com a taxa de recepo de dados. (Kurose e Ross, 2010).

2.5 Controle de Congestionamento

Para prover um servio confivel de transferncia de dados, alm do controle de fluxo, o TCP possui outro componente que seu mecanismo de controle de congestionamento.

Assim, o TCP procura compatibilizar a taxa de emisso de dados com a capacidade de transmisso da rede naquele momento, fazendo uso de reconhecimentos para regular o tamanho de sua janela de congestionamento. Para desempenhar este papel, utiliza uma das trs tcnicas abordadas a seguir.

Na Partida Lenta o TCP inicia a transferncia de dados com uma taxa de transmisso baixa, a qual vai aumentado de acordo com os ACKs vlidos recebidos.

Na Preveno de Congestionamento o TCP aumenta linearmente de 1 MSS por RTT e, quando houver um evento de ACK duplicado triplo, reduz a taxa de transmisso metade.

Na Recuperao Rpida, o valor da janela de congestionamento aumentado de 1 MSS para cada ACK duplicado recebido ocasionado pelo no recebimento do segmento que disparou o modo de recuperao rpida. Se houver um time-out o TCP deixa o modo de recuperao rpida e entra no modo de partida lenta, reduzindo assim sua janela de congestionamento metade. (Kurose e Ross, 2010).

10

3 CONTROLE DE CONGESTIONAMENTO DO TCP SACK

O TCP usa um esquema de reconhecimento cumulativo, no qual o recebimento de segmentos que no so da borda esquerda da janela de recepo no so reconhecidos. Isso obriga o remetente a esperar um tempo de ida e volta para saber mais sobre cada pacote perdido, ou desnecessariamente retransmitir segmentos que foram corretamente recebidos. Com o regime cumulativo de aviso, vrios segmentos perdidos geralmente causam a perda do temporizador do ACK-base do TCP, reduzindo consideravelmente o rendimento geral.

Diante deste panorama e fazendo uso da proposta apresentada por Jacobson e Braden (1988), atravs do RFC 1072, que Mathis et al. (1996) prope, atravs do RFC 2018, um artifcio denominado Selective Acknowledgment (SACK Reconhecimento Seletivo), com o objetivo de solucionar o reconhecimento cumulativo. A proposta consiste no receptor enviar no ACK a informao dos segmentos j recebidos, dando uma maior possibilidade ao TCP origem inferir quais segmentos enviados foram perdidos. No decorrer desta Seo a estratgia proposta por Mathis et al. (1996) ser abordada mais detalhadamente.

Reconhecimento Seletivo (SACK) uma estratgia que corrige esse comportamento em face de vrios segmentos perdidos. Com reconhecimento seletivo, o receptor pode informar o remetente sobre todos os segmentos que chegaram com sucesso, cabendo ao remetente retransmitir apenas os segmentos que foram de fato perdidos.

Especificamente, o envio de um reconhecimento seletivo para os dados mais recentemente recebidos reduz a necessidade de SACK. Alm disso, o SACK deve carregar completamente uma sequncia de nmeros de 32 bits, facilitando a implementao do SACK e respondendo s preocupaes sobre a robustez.

A extenso do reconhecimento seletivo usa duas opes TCP. A primeira uma opo que permita, "SACK-Permitted", que pode enviado em um segmento SYN para indicar que o SACK pode ser usado uma vez que a conexo seja estabelecida. A outra o bloco SACK em si, que pode ser enviado atravs de uma

11 conexo estabelecida uma vez que foi dada a permisso atravs do SACKPermitted. O blobo SACK deve ser includo num segmento ACK enviado pelo TCP receptor.

3.1 SACK-Permitted

uma opo de dois bytes que enviada em um segmento SYN por um TCP que foi estendido para receber a opo SACK uma vez que a conexo foi aberta. No deve ser enviada em segmentos no-SYN.

3.2 Formato do SACK

O SACK usado para transmitir informaes de confirmao estendida a partir do receptor para o remetente atravs de uma ligao TCP estabelecida.

12

O receptor envia um bloco SACK ao remetente informando quais os blocos de dados no-contguos que foram recebidos e que esto no buffer. O receptor aguarda o recebimento dos dados (talvez por meio de retransmisses) para preencher, sequencialmente, o espao das lacunas entre os blocos recebidos. Quando os segmentos que faltam so recebidos, o receptor reconhece os dados normalmente, avanando a borda esquerda da janela e o campo nmero de reconhecimento do cabealho TCP. A opo SACK no altera o valor do campo nmero de reconhecimento.

Esta opo lista o espao ocupado pela sequncia contgua de dados que foram recebidos e esto no buffer da janela de recepo. Cada bloco contguo de dados no buffer do receptor definido no SACK por dois inteiros sem sinal de 32 bits, na seguinte ordem: - Margem Esquerda do Bloco - este o nmero do primeiro byte do bloco. - Margem Direita do Bloco - este o nmero do ltimo byte do bloco, acrescido de uma unidade. Cada bloco representa os bytes de dados recebidos que so contguos e isolados, ou seja, os bytes, logo abaixo do bloco, (margem esquerda do Bloco - 1), e logo acima do bloco, (margem direita do Bloco), no foram recebidas. Uma opo SACK que especifica n blocos ter um comprimento de 8*n + 2 bytes, de modo que os 40 bytes disponveis para as opes de TCP pode especificar um mximo de 4 blocos. Espera-se que o SACK seja frequentemente utilizado em conjunto com a opo data-hora utilizada para o clculo do RTT mdio, que tem um adicional de 10 bytes; nesta situao, um mximo de 3 blocos SACK ser permitido. O SACK consultivo, uma vez que, quando ele notifica o remetente que o receptor recebeu os segmentos indicados, ao receptor permitido descartar dados que foram relatados em um SACK e recebidos novamente.

3.3 Gerando Opes SACK: Comportamento do Receptor de Dados Se o receptor recebeu uma opo SACK-Permitted no segmento SYN para esta conexo, o receptor pode gerar opes SACK. Se o receptor gera opes

13

SACK sob qualquer circunstncia, ele deve ger-las em todas as circunstncias permitidas. Se o receptor ainda no recebeu uma opo SACK-Permitted para uma determinada conexo, ele no deve enviar opes SACK nessa conexo. Opes SACK devem ser includas em todos os ACKs duplicados. Nesta situao a rede perdeu ou inverteu a ordem dos pacotes, de tal modo que o receptor detm dados no-contguos em seu buffer de recepo. O receptor deve enviar um ACK para cada segmento vlido que chega contendo dados novos, e cada um desses ACKs "duplicado" deve ter uma opo de SACK. Se o TCP receptor optar por enviar uma opo SACK, as seguintes regras devem ser observadas: - O primeiro blobo SACK (colocar imediatamente na opo os campos kind e length) deve especificar o bloco contguo de dados contendo o segmento que desencadeou este ACK duplicado, a menos que seja um segmento alm do nmero de reconhecimento no campo do cabealho. Isto assegura que o ACK com a opo SACK reflita a mudana mais recente ocorrida no buffer do receptor; - O receptor deve incluir tantos blocos SACK distintos quanto possvel na opo SACK. Note-se que o espao mximo disponvel no campo opo pode no ser suficiente para relatar todos os blocos presentes no buffer do receptor; - A opo SACK deve ser preenchida atravs da repetio dos blobos SACK mais recentemente que no so subconjuntos de um bloco SACK j includo na opo SACK que est sendo construda. Isto assegura que, em operao normal, qualquer segmento restante parte de um bloco no-contguo de dados mantido pelo receptor relatado em pelo menos trs opes SACK sucessivas. Aps o primeiro bloco SACK, os demais blocos SACK podem ser listados em ordem arbitrria na opo SACK.

muito importante que a opo SACK sempre relate o bloco que contm o segmento mais recentemente recebido, porque mantm o remetente informado sobre as mais recentes informaes sobre o estado da rede e fila do receptor.

14

3.4 Interpretando a Opo

SACK e a Estratgia de Retransmisso:

Comportamento do Remetente de Dados Ao receber um ACK contendo uma opo SACK, o remetente deve registar o reconhecimento seletivo para referncia futura. O remetente assume que h um buffer de retransmisso que contm os segmentos que tenham sido transmitidos, mas ainda no reconhecidos, na ordem do nmero de sequncia. Se o remetente realiza reempacotamento antes da retransmisso, os limites do bloco em uma opo SACK recebida no pode extrapolar os limites dos segmentos do buffer de retransmisso, no entanto, isso no representa uma grave dificuldade para o remetente.

O remetente pode implementar, para cada segmento no buffer de retransmisso, um bit sinalizador (novo) "SACKed", a ser usado para indicar que aquele segmento foi relatado numa opo SACK. Quando chega um ACK contendo uma opo SACK, o remetente altera o estado do bit sinalizador SACKed dos segmentos que foram seletivamente reconhecidos. Mais especificamente, para cada bloco da opo SACK, o remetente de dados ir alterar o estado do bit sinalizador SACKed de todos os segmentos no buffer de retransmisso que esto totalmente contidos dentro desse bloco. Isto requer comparaes diretas do nmero de seqncia. Aps o bit SACKed ser ligado (como resultado do processamento de uma opo SACK recebida), o remetente saltar esse segmento durante qualquer retransmisso posterior. Qualquer segmento que tem o bit sinalizador SACKed desligado e menor do que o maior segmento SACKed est disponvel para a retransmisso. Depois de um time-out de retransmisso o remetente deve desligar todos os bits SACKed, uma vez que o tempo limite pode indicar que o receptor recusou os dados.

15

O remetente deve retransmitir o segmento da borda esquerda da janela depois de um time-out de retransmisso, com ou sem o bit SACEKed ligado para esse segmento. Um segmento no sair do buffer at que a extremidade esquerda janela seja avanada at ele.

3.5 Eficincia e Comportamento para o Pior Caso Se o caminho de retorno levando ACKs e opes SACK no sofrer perdas, um bloco por pacote de opo SACK ser sempre suficiente. Cada segmento que chegar enquanto o receptor contm dados descontnuos far com que o receptor de dados envie um ACK com uma opo SACK contendo o bloco alterado na fila do receptor. O remetente , portanto, capaz de construir uma rplica exata do buffer do receptor.

Como o caminho de retorno no sem perdas, a opo SACK responsvel de incluir mais de um bloco SACK em um nico pacote. Os blocos redundantes nos pacotes de opo SACK aumentam a robustez da entrega SACK, na presena de ACKs perdidos. Para um receptor que tambm est usando a opo data-hora, a opo SACK tem espao para incluir trs blocos SACK. Assim, cada bloco SACK ir geralmente ser repetido pelo menos trs vezes, se necessrio, uma vez em cada trs pacotes ACKs sucessivos. Entretanto, se todos os pacotes ACK reportando que um bloco SACK em particular for perdido, ento o remetente pode supor que os dados desse bloco SACK no foi recebido, e no necessariamente retransmitir esses segmentos. A implantao de outras opes TCP pode reduzir o nmero de blocos SACK disponveis para 2 ou at mesmo para 1. Isto ir reduzir a redundncia de entrega SACK, na presena de ACKs perdidos. Mesmo assim, a exposio do TCP SACK em relao a retransmisso desnecessria de pacotes estritamente menor do que a exposio das implementaes anteriores do TCP. Implementaes mais antigas do TCP que no tm a opo SACK no so prejudicadas quando competindo contra TCPs com opo SACK.

16

3.6 Exemplos de Opo SACK

Com o objetivo de demonstrar o comportamento adequado de gerao de SACK pelo receptor de dados, ser desenvolvido alguns exemplos abordando diversas situaes.

Suponha que o valor da borda esquerda da janela 5000 e que o transmissor de dados envia uma rajada de 8 segmentos, cada um contendo 500 bytes de dados.

Caso 1: Os 4 primeiros segmentos so recebidos, mas os ltimos 4 so perdidos. O receptor de dados ir retornar um segmento TCP ACK normal reconhecendo nmero de seqncia de 7000, sem opo SACK.

Caso 2: O primeiro segmento perdido, mas os 7 restantes so recebidos. Ao receber cada um dos ltimos sete segmentos, o receptor de dados ir retornar um segmento TCP ACK que reconhece o nmero de seqncia 5000 e contm uma opo SACK especificando um bloco de dados do buffer:

Segmento Enviado 5000 5500 6000 6500 7000 7500 8000 8500

ACK (perdido) 5000 5000 5000 5000 5000 5000 5000

Borda Esquerda -5500 5500 5500 5500 5500 5500 5500

Borda Direita -6000 6500 7000 7500 8000 8500 9000

Caso 3: Os 2, 4, 6 e 8 (ltimo) segmentos so perdidos. O receptor envia o primeiro pacote ACK normalmente. O terceiro, quinto e stimo pacotes acionam opes SACK como segue:

17

Segmento Enviado 5000 5500 6000 6500 7000 7500 8000 8500

ACK 5500 (perdido) 5500 (perdido) 5500 (perdido) 5500 (perdido)

1 Bloco Borda Borda Esquerda Direita ----6000 6500 --7000 7500 --8000 8500 ---

2 Bloco Borda Borda Esquerda Direita --------6000 6500 --7000 7500 ---

3 Bloco Borda Borda Esquerda Direita ------------6000 6500 ---

Suponhamos que, neste ponto, o quarto pacote recebido fora de ordem.

Isto pode ser porque a rede alterou a ordem dos pacotes, ou porque houve a retransmisso dos pacotes perdidos e o segundo pacote perdeu-se novamente e o quarto pacote foi recebido. Neste ponto, o receptor tem apenas dois blocos SACK, para relatar. O receptor responde com o seguinte Reconhecimento Seletivo:

Segmento Enviado 6500

ACK 5500

1 Bloco Borda Borda Esquerda Direita 6000 7500

2 Bloco Borda Borda Esquerda Direita 8000 8500

3 Bloco Borda Borda Esquerda Direita ---

Suponhamos que, neste ponto, o segundo segmento recebido. O receptor, em seguida, responde com o seguinte Reconhecimento Seletivo:

Segmento Enviado 5500

ACK 7500

1 Bloco Borda Borda Esquerda Direita 8000 8500

2 Bloco Borda Borda Esquerda Direita ---

3 Bloco Borda Borda Esquerda Direita ---

18

4 COMPARAO DO TCP SACK VERSUS OUTROS TCPs

Da Simulao dos Mecanismos de Controle de Congestionamento do TCP realizada por Santos e Vasconcelos (2000) pode-se observar que as verses mais antigas do TCP apresentam deficincias advindas da sua poltica de reconhecimento cumulativo. O TCP SACK busca suprir esta deficincia implementando uma poltica de reconhecimento seletivo, a fim de otimizar as retransmisses.

Um ponto crtico apresentado pelas verses de TCP consideradas, e que fora o esgotamento do time-out, a relao entre o nmero de segmentos perdidos e o tamanho da janela de transmisso, uma vez que o TCP utiliza os ACKs para calcular do RTT mdio e implementar sua poltica de transmisso e/ou retransmisso. Sabendo que o TCP utiliza trs ACKs duplicados para executar a retransmisso rpida, pode-se inferir que se houver trs perdas em uma janela de seis segmentos, no importando a ordem das perdas, a retransmisso rpida no ser disparada. Assim, a nica alternativa para efetuar uma retransmisso aguardar o time-out.

No Tahoe, a retransmisso rpida seguida da partida lenta, tratando este momento como o incio de uma conexo, no dependendo da chegada de mais reconhecimentos. Porm, o TCP Reno e sua modificaes (New Reno e SACK) entram em modo de recuperao rpida, reduzindo a janela metade e incrementando-a em um segmento a cada ACK duplicado. Assim, o emissor precisa esperar pelo reconhecimento de meia janela de ACKs para conseguir efetuar nova transmisso. Isto porque ao notar uma perda, uma quantidade de pacotes equivalente uma janela j foi enviada.

O TCP Tahoe adota como estratgia realizar uma partida lenta toda vez que ocorre uma perda, esvaziando o canal mesmo em situaes de congestionamento moderado, em que no h necessidade de uma reao to radical. Assim, a eficincia do Tahoe fica muito comprometida. Quanto maior o RTT da conexo, maior ser a degradao da vazo, pois o aumento da janela demora mais a

19

ocorrer. Nas situaes em que houve mais de uma perda na mesma janela, o TCP Tahoe retransmitiu pacotes desnecessariamente.

O TCP Reno tem como opo a retransmisso de um pacote perdido em cada RTT, que o tempo necessrio para a chegada de reconhecimentos aps cada retransmisso, trazendo novas informaes ao emissor. O TCP Reno inclui o mecanismo de recuperao rpida, criado para evitar o esvaziamento do canal em situaes do congestionamento moderado e assim melhorar esse comportamento em relao ao Tahoe. O Reno solucionou algumas limitaes do Tahoe, mas por outro lado introduziu novos problemas, sua otimizao para o caso de uma perda por janela. A medida que o nmero de perdas aumenta, seu desempenho degrada rapidamente, uma vez que o Reno executa a retransmisso e entra em recuperao rpida a cada perda verificada. Este fato provoca a reduo da janela de transmisso pela metade repetitivamente, tantas vezes quanto forem os pacotes perdidos em uma janela, reduzindo a janela muito mais do que o necessrio para contornar uma situao de congestionamento. Este fato atrapalha em muito o desempenho do Reno, uma vez que ao sair da recuperao rpida ele passa preveno de congestionamento, onde o crescimento da janela ser linear, tornando muito lento o retorno da janela ao seu tamanho ideal.

No caso de uma perda, o Reno leva 1 RTT para se recuperar, e a janela reduzida metade do valor inicial. Se ocorrem duas perdas, ele levar 2 RTTs e a janela reduzida a um quarto. Nesta situao, a recuperao do Reno mais rpida que a do Tahoe (a menos que a janela inicial seja menor que 8, o que foraria um estouro no temporizador). Contudo, ele entra em preveno de congestionamento com a janela igual metade do valor da janela do Tahoe. Esta situao j comea a ficar desfavorvel para o Reno. Com trs perdas o Reno levaria 3 RTTs para se recuperar, no entanto nestes casos, quase sempre ocorre um estouro no temporizador.

J o TCP SACK, consegue alcanar o desempenho timo para um TCP com recuperao rpida. O SACK consegue se recuperar em 2 RTTs de qualquer situao em que o nmero de perdas seja menor que um quarto da janela. Para compreender isto nota-se que o SACK utiliza a retransmisso rpida, e assim como

20

o Reno, necessita receber uma quantidade de ACKs equivalente meia janela para aumentar a janela e continuar a transmisso. Dessa forma, para aumentar a janela o suficiente para a retransmisso de todos os pacotes perdidos, ser necessria a chegada de ( ) ACKs (sendo J o tamanho da janela e P a quantidade de

pacotes perdidos) de modo que o SACK consiga se recuperar, retransmitindo todos os segmentos perdidos, em 2 RTTs. Essa quantidade de pacotes, ( ), portanto

o nmero de pacotes transmitidos que precisam chegar com sucesso ao receptor. Assim o nmero mximo de pacotes que podem ser perdidos, neste caso, . Desta forma, fazendo ao mximo permitido, teremos , igualando o nmero de perdas

, que o nmero mximo de perdas para um

dado tamanho de janela. Assim, se o nmero de ACKs for metade da janela (e maior que 4), O SACK ainda consegue manter-se ativo, porque o segmento que foi transmitido na retransmisso rpida mantm os ACKs chegando (mesmo que seja um de cada vez).

Mesmo em casos onde o nmero de perdas chega a metade da janela ele ainda pode se recuperar, levando no mximo x RTTs, onde x o nmero de perdas. Para as duas afirmativas acima, necessrio atender a condio de que haja ACKs duplicados suficientes para disparar a retransmisso rpida.

21

5 CONSIDERAES FINAIS Segundo Tanenbaum (2003) a camada de transporte a chave para a compreenso dos protocolos em camadas. Ela oferece vrios servios, dos quais o mais importante um fluxo de bytes confivel, orientado a conexes e fim a fim, do transmissor at o receptor. Porm, um protocolo que oferea todos esses servios requer um algoritmo com um elevado grau de complexidade para sua implementao.

Podemos observar que o TCP tem evoludo ao longo do tempo, porm os avanos tecnolgicos alcanados no desenvolvimento de novos meios fsicos utilizados na transmisso de dados e os novos tipos de dados nela transmitidos requerem sempre mais confiabilidade, aceitabilidade, velocidade e robustez.

Atualmente j existem outros protocolos da camada de transporte que fornecem recursos mais avanados que o TCP (por exemplo, o DCCP, o SCTP ou o TRFC), mas a difuso de sua implantao ainda incerta. Para Kurose e Ross (2010) a vitria do melhor sobre o bom o bastante depender de uma mistura complexa de consideraes tcnicas, sociais e comerciais.

22

6 REFERNCIAS BIBLIOGRFICAS

Allman, M.; Paxson, V.; Blanton, E. (2009). RFC 5681 - TCP Congestion Control. Disponvel em: <http://tools.ietf.org/html/rfc5681>. Acesso em: 09 maio 2012. Jacobson, V.; Braden, R. (1988). RFC 1072 - TCP Extensions for Long-Delay Paths. Disponvel em: <http://tools.ietf.org/html/rfc1072>. Acesso em: 05 maio 2012. Kurose, James F.; Ross, Keith W.. Redes de Computadores e a Internet: uma abordagem top-down; traduo Opportunity translations; reviso tcnica Wagner Zucchi. - 5 edio So Paulo: Addison Wesley, 2010. Mathis M.; Mahdavi, J.; Floyd, S.; Romanow, A. (1996). RFC 2018 - TCP Selective Acknowledgment Options. Disponvel em: <http://tools.ietf.org/html/rfc2018>. Acesso em: 05 maio 2012. SANTOS, Guilherme Paulo Teixeira dos; VASCONCELOS, Saulo Vaz de. Avaliao por Simulao dos Mecanismos de Controle do TCP. Universidade Federal do Rio de Janeiro, 2000. Disponvel em: <www.gta.ufrj.br/ftp/gta/TechReports/Vasc00/Vasc00.ps.gz>. Acesso em: 17 maio 2012. Tanenbaum, Andrew S.. Redes de Computadores; traduo Vandenberg D. de Souza - 4 edio Rio de Janeiro: Editora Campus, 2003.