Protocolo de transporte TCP (Transmission Control Protocol)

Transcrição

1 Protocolo de transporte TCP (Transmission Control Protocol)

2 TCP Necessidade de entrega fiável de fluxos de dados Aplicação Grandes volumes de dados Aplicação TCP Transferência fiável TCP IP IP Transferência não fiável Perda de pacotes Entrega de pacotes fora de ordem Entrega de pacotes com atraso considerável Entrega de duplicados Restrições ao tamanho do pacote

3 TCP - características Orientado ao fluxo de dados - Do ponto de vista da aplicação, o TCP transfere um fluxo contínuo de bytes através da rede Orientado à ligação - A fiabilidade e o controlo de fluxo fornecidos pelo TCP requerem que este inicialize e mantenha alguma informação de estado para cada fluxo de dados Buffered Transfer - Para tornar a transferência mais eficiente e minimizar o tráfego na rede, o TCP recolhe, do fluxo, dados suficientes para encher um datagrama razoavelmente grande, antes de o transmitir Ligação Full-Duplex -Transferência concorrente em ambos os sentidos.

4 Relação entre TCP e outros protocolos TCP numa máquina utiliza IP para comunicar com TCP noutra máquina. máquina A Aplicação TCP Sistema de comunicações visto pelo TCP máquina B Aplicação TCP IP Int. de rede IP Int. de rede router IP Int. de rede Rede Rede 1 1 Rede Rede 2 2

5 TCP e IP IP oferece serviço melhor esforço (não fiável) TCP utiliza IP TCP fornece entrega fiável Como é que isto é possível? Confirmação Positiva O receptor envia uma mensagem curta quando recebe dados; Esta mensagem chama-se Confirmação (Acknowledgment). Retransmissão O transmissor inicializa um temporizador, sempre que uma mensagem é transmitida Se o temporizador expira antes que seja recebida a confirmação, a mensagem é retransmitida.

6 Confirmação positiva com retransmissão transmissor receptor envia mensagem 1 inicializa temporizador recebe ack 1 envia mensagem 2 inicializa temporizador pacote perdido envia ack 1 temporizador expira retransmite mensagem 2 inicializa temporizador envia ack 2

7 Portos, ligações e pontos terminais TCP assenta sobre IP, assim como o UDP TCP também utiliza portos para identificar o destino dentro da mesma máquina TCP permite que múltiplos programas numa máquina particular comuniquem em simultâneo Desmultiplexa o tráfego que entra para cada programa de aplicação TCP baseia-se no conceito de ligação Aplicação TCP UDP IP Interface com a Rede

8 Portos, ligações e pontos terminais Uma ligação é equivalente a um circuito virtual entre dois programas de aplicação Ligações são identificadas por um par de pontos terminais TCP define ponto terminal como um par de inteiros (endereço IP, porto) Porto TCP pode ser partilhado por várias ligações na mesma máquina porto aplicação X ligação (( , X), ( ,Y)) aplicação Y porto TCP ponto terminal TCP IP IP

9 TCP Serviços fornecidos pelo TCP ao nível da aplicação Estabelecimento e terminação de uma ligação TCP Transferência normal de informação com o TCP Serviços interactivos Serviços com transferência de grandes quantidades de informação Timeout e retransmissão (temporizadores) Novas funcionalidades do TCP e seu desempenho

10 Serviços fornecidos pelo TCP Camada de rede utilizada IP Fornece um serviço à camada de aplicação diferente do UDP Orientado à ligação, fiável, fluxo de bytes Analogia aos telefones O cliente diz Olá O servidor diz Quem é que está a chamar? Numa ligação TCP existem dois terminais a comunicar Os conceitos de broadcast e de multicast não são aplicáveis no TCP UDP tem de ser utilizado nesses casos

11 Fiabilidade no TCP Informação da aplicação dividida em segmentos com o comprimento óptimo TCP mantém temporizador por cada segmento que envia Se não é confirmada a recepção do segmento dentro de um determinado tempo, segmento é retransmitido Quando TCP recebe informação do outro extremo, envia uma confirmação TCP mantém checksum do cabeçalho e da informação extremoa-extremo Quando chega um segmento com um checksum inválido, TCP descarta-o e não envia confirmação TCP re-sequencia informação e enviar pela ordem correcta à camada de aplicação

12 Fiabilidade no TCP Retransmissões possibilidade de envio de informação duplicada TCP descarta informação duplicada Controle de fluxos: Cada extremo da comunicação tem uma fila de espera limitada de armazenamento de pacotes de informação Receptor tem capacidade de avisar o emissor de que ele está a enviar informação a uma taxa demasiado elevada Uma chamada é impedida de ocupar todo o espaço das filas de espera Pretende-se que estejam disponíveis para informação de terminais enviada a uma taxa mais lenta

13 Informação nos segmentos TCP Quantidade de informação que é colocada nos segmentos TCP pode ser diferente da quantidade de informação que a aplicação envia em cada escrita Várias escritas da aplicação podem criar apenas um segmento TCP TCP espera (durante um pequeno tempo) por mais informação para enviar, se esta for muito pequena para colocar num segmento TCP O outro extremo pode ler a informação de forma diferente que foi escrita Diferença em relação ao UDP TCP não interpreta o conteúdo dos bytes a aplicação tem essa função

14 Cabeçalho TCP Número de portos que identificam? Como é identificada a ligação? A combinação de endereço IP e número de porto é às vezes designada por socket O par de sockets (4 elementos?) especificam os dois extremos que identificam unicamente cada ligação TCP na Internet.

15 Campos do cabeçalho TCP Número de sequência identificação do primeiro byte de dados num segmento TCP Cada byte enviado é numerado número de confirmação contém o próximo número de sequência que o receptor espera receber; Enviar uma confirmação não custa nada Campo de número de confirmação encontra-se sempre presente no cabeçalho Informação pode ser enviada juntamente com confirmação TCP fornece um serviço nos dois sentidos à aplicação informação pode fluir num sentido independentemente do outro sentido Cada extremo de uma ligação tem de manter um número de sequência da informação a fluir em cada sentido

16 Campos do cabeçalho TCP TCP sem confirmações selectivas ou negativas Número de confirmação indica que o receptor recebeu até àquele número mas não incluindo esse byte Se os bytes e são recebidos, o receptor envia confirmação do byte 1025 Se os bytes chegam, mas com um erro de checksum, TCP apenas pode enviar uma confirmação do byte 1025 Tamanho do cabeçalho Sem campo de opções é de 20 bytes; Com campo de opções é no máximo de 60 bytes.

17 Campos do cabeçalho TCP 6 flags: URG apontador de urgência é válido ACK número de confirmação é válido PSH o receptor deve enviar esta informação à aplicação o mais rapidamente possível RST reset da ligação SYN sincronizar os números de sequência para iniciar a ligação FIN emissor finalizou o envio de informação Controlo de fluxo em TCP é possibilitado por cada extremo anunciando o tamanho da janela de transmissão Número de bytes, a começar pelo especificado no número de sequência de confirmação, que o receptor pode receber Limitação do tamanho da janela? Opção de escala da janela possibilita a utilização de janelas maiores

18 Campos do cabeçalho TCP checksum é obrigatório Utiliza o pseudo-cabeçalho, tal como no UDP Ponteiro de urgência Número de sequência do último byte com informação urgente Opções Opção de tamanho máximo do segmento (MSS) Opção especificada no primeiro segmento enviado (estabelecimento da ligação) Especifica o tamanho máximo do segmento que o emissor pode receber No estabelecimento e terminação da ligação, segmentos enviados contêm apenas o cabeçalho TCP Cabeçalho sem informação confirmações, se não existe informação para transmitir

19 Estabelecimento e terminação de uma ligação TCP svr4 % telnet bsdi discard Trying Connected to bsdi. Escape character is '^]'. ^] telnet> quit Connection closed. Estabelecimento svr > bsdi.discard: S : (0) win 4096 <mss 1024> (0.0024) bsdi.discard > svr4.1037: S : (0) ack win 4096 <mss 1024> (0.0048) svr > bsdi.discard:. ack win 4096 Terminação (4.1482) svr > bsdi.discard: F : (0) ack win (0.0013) bsdi.discard > svr4.1037:. ack win (0.0014) bsdi.discard > svr4.1037: F : (0) ack win (0.0225) svr > bsdi.discard:. ack win 4096

20 Protocolo de estabelecimento. da ligação Iniciar a ligação (cliente) - envia segmento SYN Número de porto do servidor onde o cliente se quer ligar Número de sequência inicial do cliente (ISN), etc Servidor responde com o seu segmento SYN Número de sequência inicial do servidor (ISN) Confirmação do SYN do cliente, confirmando o ISN do cliente +1; Um SYN consome 1 número de sequência Cliente confirma o SYN do servidor, confirmando o ISN do servidor +1 3 segmentos estabelecimento da ligação - three-way handshake.

21 Protocolo de estabelecimento da ligação O extremo que envia o primeiro SYN efectua um open activo O outro extremo efectua um open passivo O ISN é escolhido por cada extremo da comunicação Varia ao longo do tempo Cada ligação tem um ISN diferente Contador de 32 bits que incrementa 1 por cada 4 microsegundos Prevenir que os pacotes que se atrasam na rede sejam interpretados como pertencentes a outra ligação

22 Protocolo de terminação da ligação Quatro segmentos para terminar uma ligação Meio fecho do TCP Ligação com envio independente de informação nos dois sentidos Cada ligação é terminada de uma forma independente Cada extremo envia um segmento FIN (resultado de um close na aplicação) quando termina o envio de informação Quando TCP recebe um FIN, necessita de notificar a aplicação que o outro extremo terminou o envio de informação nessa direcção No entanto, TCP pode enviar informação no outro sentido Cenário normal - os dois extremos fecham a ligação com pouco tempo de intervalo. Primeiro close - close activo Último close - close passivo

23 Protocolo de terminação da ligação FINs são causados pela aplicação ACK dos FINs são enviados automaticamente pelo software TCP Close da aplicação Cliente FIN ack do FIN FIN Servidor Envio de EOF para a aplicação Close da aplicação ack do FIN

24 Timeout do estabelecimento da ligação Servidor de discard encontra-se desligado bsdi-1024 > svr4.discard: S : (0) win 4096 <mss 1024> [tos 0x10] ( ) bsdi-1024 > svr4.discard: S : (0) win 4096 <mss 1024> [tos 0x10] ( ) bsdi-1024 > svr4.discard: S : (0) win 4096 <mss 1024> [tos 0x10] Tipo de serviço 0x10 baixo atraso Frequência de envio do SYN por parte do cliente Tempo que o cliente TCP continua a retransmitir antes de desistir: 76 segundos bsdi % date ; telnet svr4 discard ; date Thu Sep 24 16:24:11 MST 1992 Trying telnet: Unable to connect to remote host: Connection timed out Thu Sep 24 16:25:27 MST 1992

25 Comprimento máximo de um segmento Comprimento máximo de um segmento (MSS) - quantidade de informação que o TCP pode enviar para o outro extremo Se não é enviada a opção de MSS, por defeito o MSS é de 536 bytes Quanto maior o MSS (sem fragmentação), maior é a amortização do custo dos cabeçalhos IP e TCP Ethernet MSS de 1460 bytes Rede com o mesmo ID de rede mas diferente ID de sub-rede pode ser uma rede física diferente Maior parte das configurações têm opção em que o administrador do sistema especifica se as sub-redes são ou não locais

26 Comprimento máximo de um segmento MSS permite evitar fragmentação sun.1093 > slip.discard: S : (0) <mss 1460>? (0.00 slip.discard > sun.1093: S : (0) ack <mss 256>? (0.00) sun.1093 > slip.discard:. ack Mesmo tendo sun anunciado um MSS de 1460, não vai enviar mais do que 256 bytes de informação, para evitar fragmentação Se os dois estiverem ligados à Ethernet, e uma rede intermédia tem MTU de 296, ocorre fragmentação; única possibilidade é descobrir o MTU do caminho

27 Meio fecho da ligação TCP Um extremo da comunicação termina a sua saída de informação, enquanto ainda recebe informação do outro extremo Nem todas as implementações suportam esta funcionalidade Quando o extremo que recebeu o FIN termina o envio de informação Fecha a sua extremidade da ligação, enviando um FIN Provoca o envio de uma mensagem de fim do ficheiro à aplicação que iniciou o meio fecho Quando este segundo FIN é confirmado, a ligação é completamente fechada

28 Meio fecho da ligação TCP Porquê a existência do meio fecho da ligação? Algumas aplicações necessitam de uma forma de o cliente dizer ao servidor que terminou de enviar informação, mas permitir que o cliente ainda receba informação Uma possibilidade sem recorrer ao meio fecho é utilizar duas ligações, mas apenas uma ligação com meio fecho é mais simples

29 As regras de início e terminação de uma ligação TCP podem ser sumariadas num diagrama de transição de estados.

30 Estados TCP Estado ESTABLISHED é o estado em que existe transferência de informação entre os dois extremos nos dois sentidos As duas transições para o estado ESTABLISHED correspondem a abrir uma ligação As duas transições do estado ESTABLISHED correspondem à terminação da ligação Close activo: estados FIN_WAIT_1, FIN_WAIT_2, CLOSING, TIME_WAIT Close passivo: estados CLOSE_WAIT, LAST_ACK

31 Estados TCP O estabelecimento e terminação normal de uma ligação TCP:

32 Estado TIME_WAIT (2 MSL Maximum Segment Lifetime) TIME_WAIT - 2MSL wait MSL é o tempo máximo que um segmento pode existir na rede antes de ser descartado (dependente da implementação 2 min, 1 min ou 30 seg) O tempo de vida de um datagrama IP é baseado no número de saltos, não no tempo Quando o TCP faz um fecho activo e envia o ACK final, a ligação pode estar no estado TIME_WAIT um tempo 2xMSL Este tempo permite ao TCP reenviar o ACK final no caso de o ACK se perder (se não recebe o ACK dentro de um timeout, o outro extremo retransmite o FIN final) Enquanto a ligação TCP se encontra no estado 2MSL wait, o par de sockets que define a ligação (?) não pode ser reutilizado

33 Estado TIME_WAIT Quaisquer segmentos que cheguem quando a ligação se encontra no estado 2MSL wait são descartados Normalmente é o cliente que faz o fecho activo e entra no estado TIME_WAIT O servidor normalmente faz o fecho passivo, e não entra neste estado Se se terminar um cliente e iniciar o mesmo cliente de imediato, o novo cliente não pode reutilizar o mesmo número de porto local. Problema? Com os servidores a situação é diferente, pois eles utilizam portos definidos: Se se terminar um servidor que tem uma ligação estabelecida, e de imediato se tentar iniciar o servidor, ele não pode associar o seu número de porto, pois ele faz parte de uma ligação que se encontra no estado 2MSL wait Entre 1 e 4 minutos até o servidor poder ser reiniciado

34 Estado TIME_WAIT Inicia-se um servidor, liga-se-lhe um cliente, e termina-se o servidor. sun % sock -v -s 6666 connection on from Termina-se o servidor sun % sock -s 6666 can't bind local address: Address already in use (encontra-se no estado 2MSL wait) sun % netstat Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) Tcp 0 0 sun.6666 bsdi.1081 TIME_WAIT

35 Estado TIME_WAIT Mesmo erro no cliente se ele tenta atribuir um porto que faz parte de uma ligação no estado 2MSL wait sun % sock -v bsdi echo connected on to hello there hello there ^D sun % sock -b1162 bsdi echo can't bind local address: Address already in use sun % sock -v -s 6666 (como servidor) connection on from ^? sun % sock -b6666 bsdi 1098 (como cliente) can't bind local address: Address already in use (porto local cliente 6666, liga-se ao bsdi no porto 1098) sun % sock -A -b6666 bsdi 1098 (como cliente opção SO_REUSEADDR) active open error: Address already in use (porto local 6666 ok, mas o porto 1098 pertence à ligação no estado 2 MSL wait)

36 Conceito de quiet time 2MSL wait dá protecção contra segmentos atrasados de uma ligação anterior que sejam interpretados como fazendo parte da nova ligação Apenas funciona se um terminal com ligações no estado 2MSL wait não crasha Se no estado 2MSL wait existe um crash, o terminal faz o reboot, e imediatamente estabelece novas ligações com os mesmos endereços IP e portos Segmentos atrasados de ligações anteriores podem ser confundidos como pertencentes à nova ligação Pode acontecer devido à forma como é escolhido o número de sequência inicial após o reboot Para se proteger contra este cenário, TCP não deve estabelecer novas ligações no espaço de MSL segundos depois de um reboot: quiet time

37 Segmentos Reset Bit no cabeçalho TCP: RST para reset Reset é enviado pelo TCP sempre que chega um segmento que não parece correcto na ligação referenciada (?) Qualquer informação em espera é descartada Pedido de ligação para um porto não existente Pedido de ligação chega e não existe processo à escuta no porto especificado UDP utilizava uma mensagem ICMP de porto inatingível TCP utiliza o reset bsdi % telnet: svr (não deve ser utilizado) Trying telnet: Unable to connect to remote host: Connection refused bsdi.1087 > svr : S : (0) win 4096 <mss 1024> [tos 0x10] (0.0038) svr > bsdi.1087: R 0:0(0) ack win 0

38 Detectar ligações meio estabelecidas Ligação meio estabelecida um extremo fechou ou cancelou a ligação sem o conhecimento do outro extremo Se um dos extremos cracha, é desligado sem avisar o outro extremo Enquanto não houver necessidade de transferir informação, o sistema que se encontra activo não detecta que o outro crachou Desligar o cabo Ethernet no terminal do servidor Reboot do servidor após desligar o cabo Re-ligar o cabo após reboot e tentar enviar nova linha do cliente ao servidor O servidor fez o reboot e perdeu a memória das ligações que existiam antes do reboot Nada sabe da ligação que o segmento referencia O receptor TCP (servidor) responde com um reset

39 Detectar ligações meio estabelecidas bsdi % telnet svr4 discard inicia o cliente Trying Connected to svr4. Escape character is '^]' hi there linha enviada ok reboot do servidor another line linha activa um reset Connection closed by foreign host bsdi.1102 > svr4.discard: S : (0) (0.0048) svr4.discard > bsdi.1102: S : (0) ack (0.0017) bsdi.1102 > svr4.discard:. ack (5.1612) bsdi.1102 > svr4.discard: P 1:11(10) ack (0.0340) svr4.discard > bsdi.1102:. ack ( ) bsdi.1102 > svr4.discard: P 11:25(14) ack (0.0050) arp who-has bsdi tell svr (0.0007) arp reply bsdi is-at 0:0:c0:6f:2d: (0.0025) svr4.discard > bsdi.1102: R : (0)

40 Estabelecimento simultâneo da ligação Duas aplicações fazem open activo ao mesmo tempo TCP está preparado para suportar estabelecimentos de ligações simultâneos Apenas uma ligação resulta do processo Transições de estados diferem dos apresentados anteriormente Ambos os extremos enviam SYN quase ao mesmo tempo, entrando no estado SYN_SENT Ao receber o SYN, o estado muda para SYN_RCVD, e cada extremo reenvia o SYN e confirma o SYN recebido Quando cada extremo recebe o SYN e a confirmação, o estado muda para ESTABLISHED 4 segmentos enviados no estabelecimento da ligação

41 Terminação simultânea da ligação Possível que os dois extremos terminem de uma forma activa a ligação ao mesmo tempo Ambos os extremos passam do estado ESTABLISHED para FIN_WAIT_1 quando a aplicação faz o close Quando o FIN é recebido, cada extremo transita do estado FIN_WAIT_1 para CLOSING, e cada extremo envia o ACK final Quando cada extremo recebe o ACK, o seu estado muda para TIME_WAIT

42 Opções TCP Cada opção começa com kind tipo; Tamanho da opção; Informação sobre a opção; Kind=1 Enchimento para ser múltiplo de 4 bytes.

43 Projecto de um servidor TCP Servidores TCP concorrentes Quando chega um novo pedido ao servidor, este aceita a ligação, invoca um novo processo para processar o pedido do cliente Invocar novo servidor Dependente do sistema operativo Unix - função fork(), threads Interacção entre TCP e servidores concorrentes Número de portos associados a cada cliente Múltiplos pedidos de ligação chegam praticamente ao mesmo tempo

44 Projecto de um servidor TCP - portos no servidor TCP Proto Recv-Q Send-Q Local Address Foreign Address (state) Tcp ESTABLISHED Tcp ESTABLISHED Tcp ESTABLISHED Tcp 0 0 *.23 *.* LISTEN TCP desmultiplexa os segmentos que chegam, utilizando todos os 4 valores que compreendem os endereços locais e não locais O único extremo no porto 23 que pode receber pedidos de ligação é o que se encontra no estado LISTEN Os extremos no estado ESTABLISHED não podem receber segmentos SYN O extremo no estado LISTEN não pode receber segmentos de dados

45 Projecto de um servidor TCP - restrição de endereços locais Restringir o estabelecimento de ligações pela interface Se um cliente se ligar através desta interface local, consegue Proto Recv-Q Send-Q Local Address Foreign Address (state) Tcp ESTABLISHED Tcp *.* LISTEN Mas se um terminal noutra rede se tenta ligar através de outra interface, o pedido não é aceite pelo módulo TCP O SYN é respondido com um RST bsdi.l026 > sun.8888: S : (0) win 4096 <mss 1024> (0.0009) sun.8888 > bsdi.l026: R 0:0(0) ack win 0

46 Projecto de um servidor TCP - fila de espera de chegada ped. Valor Backlog Máximo número de ligações em espera BSD Solaris Um servidor concorrente invoca um novo processo para processar o pedido do cliente Devia estar sempre disponível para processar o novo pedido Múltiplos pedidos de ligação podem chegar enquanto o servidor cria um novo processo, ou o sistema operativo está ocupado a correr processos com maior prioridade Como é que estes pedidos são suportados no TCP? Fila de espera de tamanho finito para armazenar pedidos Limite para a fila de espera - backlog Quando chega um pedido, existe um algoritmo do TCP que, com base no número de ligações em fila de espera, decide se pode ou não aceitar a ligação

47 Primeiro SYN no estabelecimento da ligação TCP para suportar o FTP

48 Resposta de confirmação e SYN do receptor

49 Confirmação do estabelecimento da ligação TCP para o FTP

50 Estabelecimento da aplicação FTP

51 Aceitação do estabelecimento da aplicação FTP

52 Envio do login

53 Pedido de password

54 Envio da password

55 Informação de login efectuado

56 Close da aplicação FTP

57 Terminação da ligação TCP

58 Serviços interactivos Transferência de informação com o TCP Aproximadamente metade dos segmentos TCP contêm informação transmitida em grandes volumes (FTP, ) Outra metade contém informação interactiva (Telnet e Rlogin, por exemplo) Em relação à quantidade de informação, esta é maior em informação transmitida em grandes volumes do que a interactiva Algoritmos diferentes no TCP para suportar ambos os tipos de informação Transferência de informação interactiva Suporte de confirmações atrasadas Algoritmo de Nagle para reduzir o número de pacotes pequenos em redes muito grandes

59 Funcionamento do Rlogin Comando interactivo numa ligação Rlogin Rlogin envia um caracter de cada vez do cliente ao servidor Cada vez que se pressiona uma tecla, é gerado um pacote de informação Enviadas do cliente para o servidor, um byte de cada vez Segmento de pressão da tecla enviado pelo cliente Confirmação do servidor Echo da tecla no servidor Confirmação do echo no cliente Escrita de date\n gera 6 conjuntos de envio de informação e confirmações

60

61 Atrasos nas confirmações Normalmente o TCP não envia a confirmação assim que recebe informação Atrasa a confirmação, na esperança de haver informação para enviar no mesmo sentido da confirmação Atraso de 200 ms na maior parte das implementações Tempo para gerar cada echo dos caracteres é de 16.5, 16.3, 16.5, 16.4, and 17.3 ms Menor que 200 ms não existem confirmações retardadas

62 Algoritmo de Nagle Envio de 1 byte de cada vez: pacotes de 41 bytes Aumento da congestão em redes de grande dimensão Solução: algoritmo de Naggle Uma ligação TCP pode ter apenas um segmento pequeno que não tenha sido confirmado Não podem ser enviados segmentos pequenos adicionais enquanto a confirmação não é recebida Agrupamento da informação e envio num único segmento quando a confirmação chega Quanto mais rápidas são as confirmações, mais rapidamente a informação é enviada Menos segmentos são enviados Falta de confirmações atrasadas Existe sempre informação para transmitir antes do temporizador expirar O cliente colecciona informação, mas não a envia enquanto a anterior não for confirmada Apenas 9 segmentos foram utilizados para enviar 16 bytes

63 TCP Fluxo de volumes de largura de banda TCP

64 Fluxo de volumes de largura de banda TCP Protocolo utilizado no TFTP - stop-and-wait TCP forma diferente de controle de fluxos protocolo da janela deslizante Emissor pode transmitir múltiplos pacotes antes de parar e esperar por uma confirmação Transferência de informação muito mais rápida não tem de esperar por uma confirmação de cada vez que um pacote é transmitido Slow start técnica utilizada quando é detectada congestão na rede Em conjunto com Congestion avoidance e fast recovery

65 Transferência de 8192 bytes: cliente realiza 8 escritas de 1024 bytes para a rede.

66 Fluxo normal de informação Segmento confirmação do 2049 e não do 3073 Pacote inicialmente processado por uma rotina de serviço e colocado numa fila de espera de entrada de pacotes IP Os 3 segmentos são colocados na fila de espera pela ordem em que são recebidos IP passa os pacotes para a camada TCP pela mesma ordem Quando o TCP processa o primeiro segmento, a ligação é marcada para gerar uma confirmação retardada TCP processa o próximo segmento, e dado que tem dois segmentos à espera para confirmar, a confirmação dos 2 é gerada e a flag de envio de confirmações atrasadas é desactivada TCP processa segmento seguinte, a ligação é marcada novamente para atrasar a confirmação Confirmação anuncia uma janela de 3072 bytes, porque ainda existem 1024 bytes de informação na fila de espera de recepção TCP que a aplicação não leu

67 Fluxo normal de informação Algumas confirmações de 2 segmentos recebidos Protocolo de janela deslizante receptor não tem de confirmar cada pacote recebido Confirmação de que o receptor recebeu correctamente todos os bytes até ao número de sequência confirmado menos 1 Ordem dos pacotes depende de muitos factores Implementação TCP de envio de informação Implementação TCP de recepção de informação Leitura da informação pelo processo que recebe informação Dependente do escalonamento dos processos efectuado pelo sistema operativo Dinâmica da rede Colisões, etc Não existe forma única de dois extremos TCP trocarem uma quantidade de informação

68 Mesmo exemplo realizado uns minutos depois Receptor não envia confirmação do 3073; espera e envia confirmação do 4097 Confirmação dos últimos 1024 bytes aparece no segmento 17, com a confirmação do FIN

69 Emissor rápido, receptor lento Emissor transmite 4 segmentos? Pára e espera por uma confirmação Receptor envia confirmação com janela a 0: recebeu toda a informação mas encontra-se na fila de espera TCP (aplicação ainda não leu informação) Outra confirmação actualização da janela 4096 bytes

70 Janelas deslizantes Visualização do protocolo de janela deslizante: Janela anunciada pelo receptor: janela oferecida (bytes 4 a 9) Receptor confirmou todos os bytes até e incluindo o número 3, e anunciou uma janela com tamanho 6 Tamanho da janela é relativo ao número de sequência confirmado O emissor determina a janela utilizável: quantidade de informação que pode enviar de imediato

71 Movimento da janela Janela move-se para a direita à medida que o receptor confirma informação Janela fecha quando o extremo esquerdo avança para a direita Informação é enviada e confirmada Janela abre quando o extremo direito avança para a direita, permitindo que mais informação possa ser enviada Processo no receptor lê informação confirmada, libertando espaço na fila de espera de recepção TCP Extremo esquerdo atinge o direito, janela nula Emissor pára de transmitir

72 Exemplo (primeira transferência de informação) Emissor não tem de transmitir uma janela completa Confirmação de informação janela desliza para a direita (relativo ao número seq.) Tamanho da janela pode diminuir (apenas pelo lado esquerdo) Receptor não tem de esperar que a janela encha para enviar confirmação

73 Exemplo Escrita de 8192 bytes com fila de espera de recepção de 6144 Cliente envia 6 segments e pára Segmento 10 confirma toda a informação, mas anuncia uma janela de 2048 Aplicação de recepção ainda tem de ler 2048 bytes Segmento 13 contém uma actualização da janela Janela diminui quando são enviados os dois últimos, mas vai sendo actualizada até fechar a ligação

74 Flag PUSH Notificação do emissor ao receptor para passar toda a informação que tiver para o processo de recepção Numa aplicação interactiva, quando o cliente envia um comando ao servidor, deve activar a flag PUSH e esperar pela resposta do servidor

75 Começo Lento (Slow Start) Enviados vários segmentos para a rede, até ao tamanho da janela anunciado pelo receptor Funciona bem enquanto os dois extremos da comunicação se encontram na mesma LAN Problemas quando existem routers e ligações lentas entre o emissor e o receptor Router intermédio pode armazenar pacotes na sua fila de espera até ficar sem espaço Taxa de envio de informação numa ligação TCP pode ser drasticamente reduzida TCP tem de suportar o algoritmo de slow start Taxa a que novos pacotes devem ser enviados para a rede deve ser igual à taxa à qual as confirmações são retornadas pelo outro extremo

76 Slow Start Slow start adiciona uma nova janela ao emissor TCP: a janela de congestão, cwnd Quando uma nova ligação é estabelecida com um terminal numa outra rede, janela de congestão é inicializada a 1 segmento: tamanho do segmento anunciado pelo outro extremo De cada vez que é recebida uma confirmação, a janela de congestão é aumentada de 1 segmento Emissor pode transmitir até ao mínimo entre a janela de congestão e a janela anunciada Janela de congestão representa um mecanismo de controle de fluxo imposto pelo emissor Janela de recepção representa um mecanismo de controle de fluxo imposto pelo receptor

77 Slow Start Emissor começa por transmitir 1 segmento e espera pela confirmação Quando esta é recebida, a janela de congestão aumenta, e podem ser enviados 2 segmentos Quando cada um dos 2 segmentos é confirmado, a janela é aumentada para 4 Crescimento exponencial do tamanho da janela de congestão Assim que a rede fica congestionada, um router intermédio pode começar a descartar pacotes Descarte de pacotes é uma informação (ao emissor) de que a janela de congestão era demasiado grande O emissor reage diminuindo a janela de congestão Se a congestão desaparecer, a janela aumenta novamente da mesma forma que anteriormente

78 Slow Start exemplo Informação atravessa uma ligação SLIP Quando é recebida uma confirmação do primeiro segmento, a janela de congestão aumenta para 2 Quando é recebida a confirmação do segundo segmento enviado, a janela de congestão é aumentada para 3 segmentos Embora possa ser enviado mais um segmento de informação, apenas 2 são enviados antes de chegar a próxima confirmação

79 Produto entre largura de banda e atraso Janela anunciada pelo receptor deve ter este tamanho - limita a quantidade de informação transmitida pelo emissor Capacidade da ligação: cap (bits) = band (bits/seg) x rtt (seg) Exemplos Linha telefónica T1 (1,544,000 bits/seg) com rtt de 60 mseg, dá um produto de largura de banda/atraso de 11,580 bytes Linha telefónica T3 (45,000,000 bits/seg) com mesmo rtt, dá um produto de largura de banda/atraso de 337,500 bytes, que é maior do que a máxima janela que pode ser anunciada pelo TCP (65535 bytes) Opção TCP de mudança da escala da janela

80 Produto entre largura de banda e atraso Aumentar rtt da ligação para o dobro, aumenta a capacidade da ligação TCP (número de bytes que podem ser enviados) Aumentar a largura de banda da ligação para o dobro, também aumenta o número de bytes que podem ser enviados Capacidade da rede aumentou, velocidade de transmissão, permitindo que os segmentos sejam enviados em metade do tempo

81 Congestão Ligação com capacidade elevada que envia pacotes para uma ligação lenta Router 1 ponto de congestão Espaçamento das confirmações no retorno igual ao da ligação lenta Assumiu-se que o emissor não utilizou slow start e que o router 1 tem espaço para armazenar todos os 20 segmentos (senão seriam descartados)

82 Modo urgente Suportado no TCP Extremo diz ao outro que informação urgente foi colocada em conjunto com o fluxo normal de informação Extremo receptor decide o que fazer nessa situação Dois campos no cabeçalho TCP Activação da flag URG Ponteiro de urgência é colocado a um offset positivo que tem de ser adicionado ao número de sequência, para obter o número de sequência do último byte com informação urgente TCP tem de informar o processo de recepção quando um ponteiro urgente é recebido Enquanto existir informação na posição corrente de leitura até ao ponteiro de urgência, a aplicação é considerada estar em modo urgente Depois de o ponteiro passar, a aplicação retorna ao modo normal

83 TCP Timeout e retransmissão

84 Timeout e retransmissão Fiabilidade do TCP: cada extremo da ligação confirma a informação que recebeu; Assim como os segmentos de informação, as confirmações também se podem perder; Como são suportadas estas perdas no TCP? Quando é enviada informação, é iniciado um temporizador; Se a informação não é confirmada quando o temporizador expira, a informação é retransmitida; Elementos críticos da implementação: temporizador e estratégia de retransmissão. TCP gere 4 temporizadores diferentes para cada ligação: Temporizador de retransmissão quando se espera uma confirmação do outro extremo; Temporizador de persistência que mantém informação do tamanho da janela, mesmo que o outro extremo feche a janela de recepção; Temporizador keepalive que detecta quando o outro extremo cracha ou faz o reboot; Temporizador 2MSL que mede o tempo que a ligação esteve no estado TIME_WAIT.

85 Exemplo de timeout e retransmissão bsdi.1029 > svr4.dis: S : (0) win 4096 <mss 1024> (0.0048) svr4.dis > bsdi.1029: S : (0) ack win 4096 <mss 1024> (0.0016) bsdi.1029 > svr4.dis:. ack 1 win (6.0958) bsdi.1029 > svr4.dis: P 1:15(14) ack 1 win (0.1571) svr4.dis > bsdi.1029:. ack 15 win (18.220) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (1.0136) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (3.0001) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (6.0002) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (11.990) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (24.000) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (48.001) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (64.001) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (64.001) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (64.001) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (64.001) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (64.001) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (63.991) bsdi.1029 > svr4.dis: P 15:23(8) ack 1 win (64.001) bsdi.1029 > svr4.dis: R 23:23(0) ack 1 win 4096 bsdi % telnet svr4 discard Trying Connected to svr4. Escape character is '^]'. Hello, world (enviada normalmente) (desligar o cabo antes de enviar a linha) and hi (TCP desiste depois de 9 minutos) Connection closed by foreign host.

86 Medição do rtt Timeout modificado de acordo com o rtt. Este varia ao longo do tempo: Rotas podem modificar-se; Tráfego da rede modifica-se. Medição do rtt: Envio de um byte com um número de sequência particular e recepção da confirmação; Especificação TCP original actualiza um estimador rtt: R αr + (1-α)M, em que α é um factor de suavização (0.9) e M é o rtt medido: 90% de cada nova estimativa tem informação da estimativa anterior, e 10% da nova medição. O rtt é actualizado em cada medição; O temporizador de retransmissão é dado por RTO = Rβ, em que β é um factor de variação do atraso (2).

87 Medição do rtt É necessário captar a variância das medições rtt além do estimador rtt; Cálculo do RTO com base na média e variância do rtt permite ter uma melhor resposta a flutuações nos rtts: Err = M A A é o estimador rtt A A + gerr Ganho g (média) é D D + h( Err - D)D é o desvio médio, ganho h (desvio) 0.25 RTO = A + 4D Um grande ganho do desvio, faz aumentar o RTO rapidamente quando o rtt muda.

88 Medição do rtt algoritmo de Karn Quando um pacote é transmitido, existe um timeout, o RTO é recuado, o pacote é retransmitido com o RTO maior, e uma confirmação é recebida: Confirmação é da primeira ou da segunda transmissão?: Problema da ambiguidade da retransmissão. Para resolver esse problema, o algoritmo de Karn especifica que quando existe um timeout e retransmissão, o estimador rtt não é actualizado quando a confirmação chega; Não se calcula um novo RTO enquanto não chegar uma confirmação de um segmento que não foi retransmitido.

89 Medição do rtt exemplo Envio de bytes de informação; Informação passa por duas ligações SLIP de 9600 bits/seg atrasos; 32 escritas de 1024 bytes: MTU de 296 da ligação SLIP, 128 segmentos, cada com 256 bytes de informação: Tempo total de transferência é de 45 seg; Um timeout e 3 retransmissões. Transferência de informação nos primeiros 3 seg; Slow start.

90 Medições do rtt Maior parte das implementações TCP derivadas da Berkeley medem apenas um rtt por ligação em determinado tempo; Temporização efectuada através do incremento de um contador de cada vez que a rotina do temporizador de 500 ms é invocada; Quando chega uma confirmação com o número de sequência correcto, o temporizador termina; Se a informação não foi retransmitida quando a confirmação chega, o rtt e o desvio médio são actualizados, com base nas medições; 1º segmento 3 pulsos do relógio - rtt de 1500 ms; 2º segmento 1 pulso do relógio - rtt de 500 ms; 3º segmento 2 pulsos do relógio - rtt de 1000 ms.

91 Medições do rtt Relação entre os rtts actuais e os pulsos do relógio: 128 segmentos transmitidos, 18 amostras de rtt; rtt medido, e RTO utilizado pelo TCP para o timeout; Faltas das amostras de rtts são derivadas por retransmissões; Nesta implementação o RTO determinado pelo TCP é sempre um múltiplo de 500 ms.

92 Cálculo do estimador rtt Inicializações, actualizações dos estimadores rtt e cálculo do timeout de retransmissão; A= 0 e D =3 seg; Timeout inicial de retransmissão: RTO=A+2D=0+2x3=6 seg - RTO para a transmissão do SYN inicial; Se o SYN se perder slip.1024 > vangogh. dis: S : (0) win 4096 <mss 256> (5.8024) slip.1024 > vangogh. dis: S : (0) win 4096 <mss 256> (0.4670) vangogh.dis > slip.1024: S : (0) ack win 8192 <mss 512> (0.0014) slip > vangogh.dis:. ack 1 win 4096 Quando ocorre o timeout após seg, o RTO é actualizado RTO=A+4D=0+4x3=12 seg; O recuo exponencial é aplicado ao RTO de 12: Como este é o primeiro timeout, utiliza-se um multiplicador de 2: 24 seg; O próximo é determinado utilizando um multiplicador de 4: 48 seg. Valores de A e D não são actualizados devido à retransmissão; Segmentos de confirmação apenas não têm temporizadores.

93 Cálculo do estimador rtt Quando a confirmação do primeiro segmento chega, 3 pulsos de relógio são contados, e os estimadores são inicializados: A=M+0.5= =2 D=A/2=1 RTO=A+4D=2+4x1=6 seg; Confirmação do segundo segmento (1 pulso de relógio): Err=M-A=0.5-2=-1.5 A=A+gErr= x1.5= D=D+h( Err -D)=1+0.25x(1.5-1)=1.125 RTO=A+4D= x1.125=

94 Exemplo de congestão Transmissão de segmentos de informação; Normal: aumento do número de sequência com o declive sendo a taxa de transmissão; Retransmissões 3 quebras no gráfico: Apenas um segmento é retransmitido de cada vez. Depois de o segmento final e do FIN serem enviados, levou 4 seg para receber as 14 confirmações finais.

95 1ª retransmissão - segmento 45 é perdido Confirmação de todos até ao byte confirmações com o mesmo número de sequência Recepção do segmento 62 força a retransmissão da informação anterior

96 Exemplo de congestão Algumas implementações não esperam pelo timeout, contam o número de confirmações duplicadas, e quando o terceiro é recebido, retransmite apenas um segmento, aquele que pensa que foi perdido Algoritmo de retransmissão rápida, seguido do algoritmo de recuperação rápida Após retransmissão, o emissor continua a transmissão normal de informação, sem esperar que o outro extremo confirme a retransmissão Receptor Informação recebida em sequência: processo TCP de recepção passa a informação ao processo de utilizador Segmento 46 fora de ordem TCP armazena os 256 bytes erespondecom uma confirmação do número de sequência maior recebido 7 segmentos seguintes fora de ordem: informação armazenada pelo processo TCP e confirmações duplicadas são geradas

97 Exemplo de congestão Não existe forma de o TCP avisar o outro extremo que um segmento falta ou que chega fora de ordem Envia confirmações do último recebido correctamente Quando chega o segmento que se perdeu, o receptor TCP passa essa toda a informação armazenada ao processo de utilizador, e toda a informação é confirmada Todas as retransmissões foram causadas por confirmações duplicadas, indicando que um pacote foi perdido Em cada um dos casos, apenas um pacote foi retransmitido

98 Algoritmo evitar congestão (congestion avoidance) Aumento da janela de congestão: situação em que pacotes são perdidos Algoritmo de congestion avoidance suportado pelo TCP para lidar com pacotes perdidos Duas indicações de perda de pacotes Timeout Recepção de confirmações duplicadas Congestion avoidance e slow start são algoritmos independentes com objectivos diferentes Quando existe congestão, é necessário diminuir a taxa de envio de pacotes, e por isso, o mecanismo de slow start ou de congestion avoidance são invocados Timeout Slow start Confirmações duplicadas congestion avoidance Na prática os dois algoritmos são implementados em conjunto Após slow start pode-se entrar em congestion avoidance

99 Algoritmo evitar congestão (congestion avoidance) Congestion avoidance e slow start requerem que sejam mantidas 2 variáveis para cada ligação Janela de congestão, cwnd Tamanho limite de slow start, ssthresh Funcionamento da simbiose entre os dois algoritmos Inicialização: cwnd =1, ssthresh = bytes Rotina de saída TCP envia min(cwnd, advwnd) percepção de congestão da rede vs espaço disponível na fila de espera do receptor Quando ocorre congestionamento, metade do tamanho da janela corrente é colocado em ssthresh. Se o congestionamento é indicada por um timeout, cwnd é colocada a 1 segmento

100 Algoritmo evitar congestão (congestion avoidance) Funcionamento da simbiose entre os dois algoritmos (cont): Quando informação é confirmada, cwnd aumenta, dependente se é efectuado slow start ou congestion avoidance: Se cwnd ssthresh - slow start; senãocongestion avoidance; Slow start continua enquanto a janela for metade da que era quando ocorreu congestionamento e depois inicia-se congestion avoidance cwnd começa com 1 segmento, e é incrementado por 1 segmento por cada confirmação recebida Em congestion avoidance, cwnd é incrementada por 1/cwnd cada vez que uma confirmação é recebida: aumento aditivo Aumento de cwnd de no máximo 1 segmento em cada rtt Slow start aumento de cwnd do número de confirmações recebidas num rtt

101 Visualização de slow start e congestion avoidance Assume-se que congestão ocorreu quando cwnd tem um valor de 32 segmentos ssthresh é colocado a 16 segmentos e cwnd a1 1 segmento é enviado no tempo 0 e, assumindo que confirmação é recebida no tempo 1, cwnd é incrementada a 2 Crescimento exponencial continua até que cwnd = ssthresh Após este ponto, o aumento de cwnd é linear, com um aumento máximo de 1 segmento num rtt

102 Algoritmos de retransmissão rápida e recuperação rápida TCP tem de gerar uma confirmação imediata (duplicada) quando recebe um segmento fora de ordem; este tem de ser gerado sem atrasos Não sabendo se uma confirmação duplicada é causada por um segmento perdido ou por reordenação dos segmentos, tem de se esperar por algumas confirmações duplicadas Se 3 ou mais confirmações duplicadas existirem, é uma indicação forte de que um segmento se perdeu É feita de imediato a retransmissão sem esperar que o temporizador expire - algoritmo de rápida retransmissão Depois, o algoritmo de congestion avoidance deve ser efectuado, e não o slow start algoritmo de fast recovery

103 Algoritmos de retransmissão rápida e recuperação rápida 3 confirmações duplicadas não existiu slow start Se o receptor só pode gerar confirmações duplicadas se outro segmento seguinte foi recebido, significa que ainda existe informação a fluir na rede, e não se quer reduzir abruptamente a taxa de transmissão Algoritmos de retransmissão e recuperação rápidas: Quando é recebida a 3º confirmação duplicada, ssthresh =½cwnd (corrente); retransmite-se o segmento De cada vez que chega outra confirmação duplicada, cwnd= cwnd+ss (tamanho do segmento) e transmite um pacote (se possível com o novo cwnd) Quando vem uma confirmação de nova informação cwnd=ssthresh Este passo é congestion avoidance, dado que se está a diminuir a taxa de transmissão para metade do valor quando o pacote foi perdido

104 Exemplo de congestão Segmento Acção Variável Envio Recepção Comentário cwnd ssthresh SYN SYN Inicializar Retransmissão SYN, ACK ACK 1 1:257(256) :513(256) ACK 257 slow start :769(256) 5 ACK 513 slow start :1025(256) 1025:1281(256) 8 ACK 769 cong. Avoid :1537(256) ACK 1025 cong. Avoid :1793(256) 12 ACK 1281 cong. Avoid

105 Exemplo de congestão Timeout actualização de ssthresh e cwnd slow start ACK 257 e ACK 512 actualização de cwnd ainda em slow start ACK 769 sistema já não se encontra em slow start congestion avoidance cwnd cwnd + segsize x segsize/cwnd + segsize/8 Aumento de 1/cwnd cwnd x 256/ /8 = 885 ACK cwnd x256/ /8 = 991. Aumento continua até à primeira retransmissão

106 Exemplo de congestão Cada retransmissão aconteceu devido a 3 confirmações duplicadas: fast retransmit ssthresh é colocado a metade do tamanho da janela, mas cwnd aumenta enquanto as confirmações duplicadas são recebidas - fast recovery

107 Exemplo de congestão Duas confirmações duplicadas - cwnd igual Terceira confirmação cwnd aumenta de 3 segmentos ssthresh =1/2 cwnd=1/2*2048 cwnd =ssthresh+3*ss ( * 256) retransmissão Confirmações seguintes - cwnd incrementada pelo tamanho do segmento Confirmação nova - cwnd = ssthresh (1024) e termina congestion avoidance

108 Erros ICMP Suporte de mensagens de erro ICMP - erro de terminal e rede inatingíveis é ignorado, pois são considerados erros transitórios Estabilização dos protocolos de encaminhamento quando existe mudança na topologia da rede Estes erros não fazem terminar a ligação TCP TCP continua a enviar a informação que causou o erro, até existir um timeout

109 Re-paquetização TCP efectua um timeout e retransmite não tem de retransmitir um segmento idêntico repaquetização envia um segmento maior. bsdi % sock svr4 discard hello there Desligar cabo Ethernet line number 2 and 3 Religar o cabo bsdi > svr4.discard: P 1:13(12) ack (0.1405) svr4.discard > bsdi.1032:. ack 13 Cabo Ethernet desligado ( ) bsdi.1032 > svr4.discard: P 13:27(14) ack (1.2317) bsdi.1032 > svr4.discard: P 13:27(14) ack (3.0001) bsdi.1032 > svr4.discard: P 13:27(14) ack 1 Escrita da terceira linha (6.0002) bsdi.1032 > svr4.discard: P 13:33(20) ack ( ) bsdi.1032 > svr4.discard: P 13:33(20) ack ( ) bsdi.1032 > svr4.discard: P 13:33(20) ack 1 Cabo religado (0.0783) svr4.discard > bsdi.1032:. ack 33

110 Interacção entre IP e TCP Forma como os routers tratam os datagramas IP pode ter efeito significativo no desempenho de uma ligação TCP e na taxa de envio agregada de todas as ligações Se um router atrasa uns datagramas mais do que outros, temporizador de retransmissão do TCP é aumentado Se o atraso excede temporizador de retransmissão, TCP assume que existiu congestionamento Router não tem mais capacidade de armazenamento de pacotes e descarta-os: fila de espera enche Primeiro algoritmo de escalonamento baseado em tail drop Quando a fila de espera enche, router descarta todos os datagramas adicionais; router descarta a cauda da sequência Muitas perdas colocam TCP em slow start Quando os datagramas são de várias ligações TCP diferentes Router descarta segmentos de N ligações e não N segmentos de uma ligação Todas as instâncias TCP entram em slow start ao mesmo tempo (sincronização global)

111 Interacção entre IP e TCP Evitar sincronização global: RED (Random Early Detection): Utiliza dois valores limite para marcar posições na fila de espera, T min e T max ; Três regras que determinam a disposição de cada datagrama que chega: Se a fila de espera contém menos de T min datagramas, adiciona-se o datagrama à fila de espera; Se a fila de espera contém mais de T max datagramas, descarta-se o novo datagrama; Se a fila de espera contém entre T min e T max datagramas, descarta-se aleatoriamente o datagrama de acordo com uma probabilidade p. Em vez de esperar que a fila de espera encha, router descarta datagramas aleatoriamente à medida que aumenta a congestão.