Camada de Transporte

unesp - IBILCE - SJRP
Curso de Redes de Computadores 2010

Adriano Mauro Cansian adriano@acmesecurity.org
Captulo 3 Camada de Transporte

1
Captulo 3: Camada de Transporte

Metas do captulo:
Compreender os
O que veremos:
Servios da camada de transporte. Multiplexao/desmultiplexao. Transporte sem conexo: UDP. Princpios de transferncia confivel de
princpios dos servios da camada de transporte:

Multiplexao/ desmultiplexao. Transferncia confivel de dados. Controle de fluxo. Controle de congestionamento.
dados. Transporte orientado a conexo: TCP

Transferncia confivel Controle de fluxo Gerenciamento de conexes
Princpios de controle de
Instanciao e
implementao na Internet.
congestionamento. Controle de congestionamento em TCP.
Comparao entre as camadas

Camada Transporte processos
Camada de rede hosts
Protocolo da Camada de Transporte fornece comunicao lgica entre processos, rodando em hosts diferentes. Protocolo da Camada de Rede fornece comunicao lgica entre hosts.
Camada de transporte repousa exatamente sobre a camada de rede.
Esta distino sutil, mas MUITO importante!

3
Camada de Transporte X Camada de Rede (1)

Exemplo: 10 irmos numa casa em So Paulo, SP. e 10 irmos em outra casa em Manaus, AM. Os de SP so primos daqueles em Boa Vista. Escrevem cartas entre SP e AM semanalmente. Em So Paulo: Joo recolhe as cartas, e as entrega ao correio. Em Manaus: Maria recolhe as cartas, e as entrega ao correio. Tambm recebem e fazem a distribuio local das cartas que chegam.
4
Camada de Transporte X Camada de Rede (2)

Hosts (end systems) = Casas. Processos = pessoas que trocam mensagens. Mensagens da aplicao = cartas em envelopes. Protocolo da camada de rede:
Servio postal (correio).
Protocolo da Camada de Transporte:
Joo (de um lado) e Maria (do outro).
Servios e protocolos de TRANSPORTE (1)

Prov comunicao
lgica
entre processos de aplicao executando em hosts diferentes.

Protocolos de transporte
aplicao transporte rede enlace fsica
rede enlace fsica
rede enlace fsica rede enlace fsica
rodam em sistemas finais.
Camada de rede: dados transferidos entre hosts. Camada de transporte: dados transferidos entre processos.
rede enlace fsica
rede enlace fsica
Servios e protocolos de TRANSPORTE (2)

Do ponto de vista da APLICAO a camada de
transporte permite enxergar os sistemas como se eles estivessem fisicamente conectados.
Mesmo que existam vrios roteadores, links e outros equipamentos no caminho.
A Camada de Aplicao no tem que se preocupar com a
infra-estrutura de interligao, usada para carregar as mensagens.
Protocolos da camada de transporte (1)

Como j foi dito:
Protocolos de transporte
so implementados nos sistemas das pontas (end systems), e no nos roteadores intermedirios.
TRANSPORTE: Camada
rede enlace fsica
rede enlace fsica
rede enlace fsica
4, superior camada de rede.
Protocolos da camada de transporte (2)

Dois Servios de transporte na Internet:
Entrega confivel, ordenada, ponto
a ponto: TCP.

Controle Congestionamento. Controle de fluxo. Estabelecimento de conexo (setup).
rede enlace fsica
rede enlace fsica
rede enlace fsica
Entrega no confivel, (melhor
esforo), no ordenada, ponto a ponto ou multiponto: UDP.
Multiplexao/desmultiplexao (1)
MULTIPLEXAO: Juntar dados de mltiplos
processos de aplicaes, encapsulando dados com cabealho (usado depois para demultiplexao).
dados da camada de aplicao cabealho de segmento
P3
receptor
M M
P4 P2
P1
M
aplicao segmento Ht M transporte Hn segmento rede
aplicao transporte rede
10
MULTIPLEXAO: Juntar dados de mltiplos
processos de aplicaes, envelopando dados com cabealho (usado depois para demultiplexao). DEMULTIPLEXAO: entrega de segmentos recebidos para os processos da camada de aplicao corretos.
dados da camada de aplicao cabealho de segmento
P3
receptor
P4 P2
P1
M
aplicao segmento Ht M transporte Hn segmento rede
11
Segmento - Unidade de dados trocada entre entidades da
camada de transporte. Ou TPDU- Transport protocol Data Unit, ou 4-PDU (PDU da camada 4). No exemplo abaixo: P1 com P3, e P2 com P4.
P3 receptor
M M
dados da camada de aplicao cabealho de segmento segmento
P4 P2
P1
M
aplicao Ht M transporte Hn segmento rede
12
Multiplexao/demultiplexao: Baseadas em nmeros de porta e endereos IP de remetente e receptor: Nmeros de porta de remetente/receptor so enviados em cada segmento. Nmero de porta so bem conhecido para aplicaes especficas (WKS): E-mail na porta 25, telnet na porta 23, http na porta 80, e assim por diante.
32 bits porta emissor porta receptor
outros campos do cabealho dados da aplicao (mensagem)
formato genrico de segmento TCP/UDP

13
Multiplexao/desmultiplexao: exemplos
estao A
porta orig.: x porta dest: 23
servidor B
Web client host C
porta orig:23 porta dest: x
uso de portas: aplicao simples de telnet

IP orig: A IP dest: B porta orig: x porta dest: 80
IP orig : C IP dest: B porta orig: y porta dest: 80
IP orig: C IP dest: B porta orig: x porta dest: 80
Cliente WWW estao A
servidor WWW B
Uso de portas : servidor WWW

14
UDP: User Datagram Protocol [RFC 768]

Protocolo de transporte da
Internet mnimo. Best Effort: Servio melhor esforo, resulta que segmentos UDP podem ser: Perdidos. Entregues aplicao fora de ordem de envio. Sem conexo: No h setup UDP entre remetente e receptor. Tratamento independente de cada segmento UDP.
Por qu existe um UDP?

Elimina estabelecimento de
conexo (o que pode causar retardo). Simples: no se mantm estado da conexo no remetente/receptor. Pequeno cabealho de segmento. Mais simples. Sem controle de congestionamento: UDP pode transmitir o mais rpido possvel.
15
Mais sobre UDP

Muito utilizado para aplicaes de
meios contnuos (voz, vdeo) So tolerantes a perdas. So sensveis taxa de transmisso.
Comprimento em bytes do segmento UDP, incluindo cabealho 32 bits
porta origem
comprimento
porta dest.
Outros usos de UDP : DNS (servidor de nomes). SNMP (gerenciamento). Transferncia confivel com UDP: deve incluir confiabilidade na camada de aplicao. Recuperao de erro fica por conta da aplicao!
checksum
Dados de aplicao (mensagem)

Formato de um sgmento UDP
16
Checksum UDP
Meta: detectar falha no segmento transmitido. Emissor:
Trata contedo do segmento
Receptor:
Computa checksum do
como seqncia de inteiros de 16-bits. Campo checksum zerado. Checksum: soma (adio usando complemento de 1) do contedo do segmento. Emissor coloca complemento de um do valor da soma no campo checksum de UDP . Envia...
segmento recebido Verifica se checksum computado zero: NO - erro detectado. SIM - nenhum erro detectado. Mas ainda pode ter erros? (Veremos mais adiante .)
17
Exemplo de clculo do checksum (1)

Ver RFC-1071 !
Considere 3 palavras de 16 bits sendo transmitidas:
0110011001100110 0101010101010101 0000111100001111

A soma das duas primeiras palavras :
0110011001100110 0101010101010101 1011101110111011

Adicionando a terceira palavra, a soma acima fica: 1011101110111011 0000111100001111 1100101011001010
Os complementos de 1 so obtidos convertendo
todos os 0s para 1s , e todos os 1s para 0s.

18
Lembrete 1: mtodo Polinomial

Modo Polinomial ( vai um) (Este o mtodo realmente usado pelo UDP. Em caso de dvida, consulte a seo 3.3.2 do livro texto d o curso Computer Networking: A Top-Down Approach Featuring the Internet - James F. Kurose & Keith W. Ross). Lembrar que: 0 + 0 = 0 = 00 (vai zero) 1 + 0 = 1 = 01 (vai zero) 0 + 1 = 1 = 01 (vai zero) 0 + 1 = 1 = 01 (vai zero) 1 + 1 = 2 = 10 (vai 1) 1 + 1 + 1 = 3 = 11 (vai 1 ) 01 11 01 1 0 1 0 1 + 0 1 1 1 0 0 0 0 1 1 0 0 0 1 0 1 11 1 0 01 01 1 0 1 + 1 1 0 0 1 1 0 0 1 0 0 1 0 0 0 1 Complemento de 1 = 0 1 1 0 1 1 1 0
19
Lembrete 2: carry
20

Assim o complemento de 1's da soma 1100101011001010 0011010100110101
Este valor se torna o checksum.

No receptor, todas as palavras de 16 bits so somadas,
incluindo o checksum.
Se no foram introduzidos erros no pacote, a soma no
receptor certamente dever resultar em 1111111111111111.
Se um dos bits for zero, ento algum erro foi introduzido no pacote.
Pergunta para casa: Por que o UDP usa checksum, se a maioria dos protocolos data-link (inferiores), incluindo o popular Ethernet, tambm fornece verificao de erro ??
21

Assim o complemento de 1's da soma 1100101011001010 0011010100110101
Este valor se torna o checksum.
22
Pseudo Header (1)

UDP (assim como o TCP) usa um pseudo
header no clculo do checksum, com informaes do IP (16 bytes).
Checksum usa os headers (pseudo header e header UDP), e os dados do UDP.
Comprimento do UDP pode ser um nmero
mpar de bytes.

Algoritmo do checksum soma palavras de 16 bits. Soluo: adicionar pad de zeros , no final, se necessrio.
Pad no transmitido.
23
Pseudo Header (2)
Pseudo header IP (usado pelo UDP) (16 bytes) Header UDP (8 bytes)
Violao da independncia das camadas
24
Princpios de Transferncia confivel de dados
Reliable Data Transfer (RDT)
25
Princpios de Transferncia confivel de dados Reliable Data Transfer (RDT)

Importante nas camadas de transporte, enlace No topo da lista dos 10 tpicos mais importantes em redes!
Caractersticas do canal no confivel determinam a complexidade
de um protocolo de transferncia confivel de dados (RDT).

26
Transferncia confivel de dados (RDT): como comear

rdt_send( ): chamada
da camada superior, (Ex: pela aplicao). Passa dados para entregar camada superior receptora
deliver_data(): chamada por rdt para entregar dados para camada superior.
emissor
receptor
udt_send(): chamada por ambos os lados para troca de pacotes de controle. UDT representa um unreliable data transfer.
rdt_rcv(): chamada quando pacote chega no lado receptor do canal.

27
Transferncia confivel de dados (rdt): como comear

Iremos:
Desenvolver passo-a-passo os lados remetente e receptor do
protocolo confivel RDT. Vamos Considerar apenas fluxo unidirecional de dados.
Mas a informao de controle flui em ambos sentidos!
Usar mquinas de estados finitos (FSM - Finite State Machine)
para especificar remetente e receptor.

ESTADO: quando o sistema est num estado, o prximo estado determinado unicamente pelo prximo evento.
28
evento causando transio de estados aes tomadas na transio de estado
estado 1
evento aes
estado 2
Rdt1.0: transferncia confivel usando um canal
confivel
Suposio 1.0: Canal perfeitamente confivel. No apresenta erros de bits. No apresenta perda de pacotes.
FSMs separadas, para remetente e receptor: Remetente envia dados pelo canal subjacente. Receptor recebe dados do canal subjacente.
Evento que causou a transio
Aes tomadas quando ocorre um evento 29
rdt2.0 - Modelo um pouco mais realista:

Bits num pacote podem ser corrompidos.
Falhas podem ocorrer nos componentes
fsicos da rede:
Por exemplo, quando um pacote transmitido, propagado ou bufferizado.
Entretanto, continuamos supondo que
todos os pacotes transmitidos so recebidos na ordem em que so enviados.
Ainda que bits possam estar corrompidos.

30
Rdt2.0: canal com erros de bits

Canal subjacente pode inverter bits no pacote O checksum UDP pode detectar erros de bits. A questo : como recuperar dos erros? Confirmao (ACK): receptor avisa explicitamente ao remetente que pacote chegou bem. Confirmao negativa (NAK): receptor avisa explicitamente ao remetente que pacote tinha erros.
Emissor retransmite pacote ao receber um NAK ( Lembrar de cenrios humanos usando ACKs, NAKs )
31
Mensagens de controle
Permitem o receptor informar ao emissor o
que foi recebido corretamente.
E o que foi recebido com erro, exigindo retransmisso.
Protocolos baseados em retransmisso so
chamados de Protocolos ARQ:
Automatic Repeat reQuest.
32
Novas capacidades em rdt2.0

Trs capacidades adicionais so exigidas em
protocolos de ARQ para lidar com a presena de erros de bits: Deteco de erros: mecanismo para permitir que o receptor identifique quando erros de bit ocorreram. Realimentao (feedback) pelo receptor: mensagens de controle (ACK, NAK) trocadas entre receptor e o emissor. Retransmisso: para corrigir os erros detectados.
Estes novos mecanismos esto presentes na proposta de protocolo rdt2.0

33
rdt2.0: especificao da FSM - Emissor

Aguarda dados da aplicao Possui 2 estados: Em um estado aguarda dados da camada superior. Em outro estado, aguarda ACK ou NACK do receptor Aguarda ACK ou NACK do receptor
Se recebe um NACK, re-envia o ltimo pacote atual, e retorna a aguardar um ACK ou NACK. No pode aceitar dados da camada superior (stop-and-wait)
Se recebe um ACK confirmando que o dado atual foi recebido, retorna ao estado de aguardar um pacote da camada superior 34
rdt2.0: especificao da FSM - Receptor

Possui apenas 1 estado: ao receber um pacote, responde com ACK ou NACK, dependendo se o pacote est ou no corrompido.
Pacote recebido apresenta erro. Emite um NACK, e retorna ao estado de aguardar.
Pacote recebido est ntegro. Emite um ACK, confirmando e retorna ao estado de aguardar.
35
rdt2.0: em ao (sem erros)
FSM do remetente
FSM do receptor
36
rdt2.0: em ao (cenrio de erro)
FSM do remetente
FSM do receptor
37
Mas o RDT2.0 tem uma falha fatal...
38
rdt2.0 tem uma falha fatal!

O que acontece se ACK ou NACK com erro ? Emissor no sabe o que aconteceu no receptor! No se pode apenas retransmitir: h possibilidade de pacotes duplicados. O que fazer? Remetente usa ACKs/NAKs p/ ACK/NAK do
receptor?
E se perder ACK/NAK do remetente?
Retransmitir? Pode causar retransmisso de pacote recebido certo!

39
rdt2.0 tem uma falha fatal!

O que acontece se ACK ou Lidando com duplicao: Emissor inclui nmero de NACK com erro ?
Remetente no sabe o que
aconteceu no receptor! No se pode apenas retransmitir: h possibilidade de pacotes duplicados.
O que fazer?
Remetente usa ACKs/NAKs p/
ACK/NAK do receptor?
seqncia para cada pacote. Emissor retransmite pacote atual se ACK/NAK recebido com erro. Receptor descarta pacote duplicado.
E se perder ACK/NAK do remetente?
Stop and wait
Retransmitir? Mas pode causar retransmisso de pacote recebido certo!
Remetente envia um pacote, e ento aguarda resposta do receptor.
40
rdt2.1: EMISSOR, trata ACK/NAKs com erro

1
Insere No. de seqncia 0 no pacote
2
4
Aguarda a chegada do No. Seq. correto
Deve verificar se ACK/NAK recebido tinha erro
41
rdt2.1: receptor, trata ACK/NAKs com erro

Pacote corrompido Deve checar se pacote recebido duplicado. O estado indica se No. de seqncia esperado 0 ou 1
No. Seq. errado
42
rdt2.1: discusso (1)

Emissor:
Insere No. de sequncia no pacote. Bastam dois Nos. de sequncia (0 ou 1).
Deve verificar se ACK/NAK recebido tem erro.

Duplicou o No. de estados
Estado deve lembrar se o pacote atual tem No. de sequncia 0 ou 1.
43
rdt2.1: discusso (2)

Receptor:
Deve checar se pacote recebido duplicado
Estado indica se No. de seqncia esperado 0 ou 1.
Receptor no tem como saber se ltimo
ACK/NAK foi recebido bem pelo emissor.
44
rdt2.2: um protocolo sem NAKs

Mesma funcionalidade que
rdt2.1, mas s com ACKs. Ao invs de NAK, receptor envia ACK para o ltimo pacote recebido bem. Receptor deve incluir explicitamente o No. de seqncia do pacote reconhecido. ACK duplicado no remetente resulta na mesma ao que o NAK: retransmite pacote atual.
FSM do EMISSOR
45
rdt3.0: canais com erros e perdas (1)

Nova suposio: alm de corromper dados, o canal tambm pode perder pacotes (dados ou ACKs). Como lidar com perdas?

Ou seja, como detectar perda de pacotes ? O que fazer quando pacotes so perdidos?
Checksum, No. de sequncia, ACKs, e
retransmisses podem ajudar, mas no sero suficientes.

46
rdt3.0: canais com erros e perdas (2)

Abordagem: remetente aguarda um determinado
tempo pelo ACK em trnsito. Exige uso de temporizadores (timers).

Timeout esgotamento do timer. Retransmite se nenhum ACK recebido neste tempo. Se pacote (ou ACK) est apenas atrasado (no perdido): A retransmisso ser duplicada.
Mas uso de nmero de seqncia resolve este problema. Receptor deve avisar o nmero de seqncia do pacote sendo confirmado.
47
rdt3.0: remetente
Inicia o timer e aguarda o ack
Esgotou o timer: reenvia o anterior
48
rdt3.0 em ao
49
rdt3.0 em ao
50
Protocolos dutados (pipelined)
51
Problema com protocolo stop & wait

Em longas distncias: retardo fim-a-fim grande. Pacote em trnsito, ainda no confirmado.
52
Desempenho de rdt3.0
rdt3.0 funciona, porm seu desempenho muito ruim.
Exemplo:

Link de 1 Gbps (10**9 bits/seg); Pacote de 1 KByte (8K bits) retardo fim a fim de 15 ms, :
T = transmisso
8 kbits/pacote = 8 microseg 10**9 b/seg 8 microseg = 0,027 % Desempenho = 30.016 mseg
Pacote de 1KB a cada 30 mseg vazo de 33kByte/seg num enlace de 1 Gbps ! Protocolo limita uso dos recursos fsicos!
Tempo de ida e volta
53
Protocolos dutados (pipelined)

Dutagem (pipelining): remetente admite mltiplos pacotes em trnsito, ainda no reconhecidos.

Faixa de nmeros de seqncia deve ser aumentada. Buffers no remetente e/ou no receptor.
Duas formas genricas de protocolos dutados: Volta-N (GBN Go Back N) Retransmisso Reletiva (selective repeat).
54
GBN - Go Back N (1)

Tambm conhecido como Volta-N. Emissor: pode enviar mltiplos pacotes,
sem aguardar ACK do receptor. Entretanto: No pode haver mais do que um valor mximo de N pacotes no confirmados no canal.
55
GBN - Go Back N (2)

send_base = Seq. # do pacote mais antigo no confirmado no duto. nextseqnum = Menor Seq. # no usado (Seq.# do prximo a enviar).
[0, send_base - 1] = Pacotes transmitidos e confirmados (verde) [send_base, nextseqnum -1] = Pacotes enviados mas no confirmados (amarelo) [nextseqn, send_base + N - 1] = Disponveis para serem usados imediatamente, assim que dados chegarem da camada superior (azul). Sequence number (base + N) : no podem ser usados at que um pacote no confirmado que esteja atualmente no duto tenha sido confirmado.
56
GBN - Go Back N (3)

No Emissor: O intervalo de nmeros de seqncia para
pacotes transmitidos, mas ainda no confirmados, poder ser visto como uma janela (window) de tamanho N sobre o intervalo de nmeros de seqncia.
medida que o protocolo opera, a janela se desloca sobre o espao
de nmeros de seqncia: sliding-window protocol = Janela deslizante
Pergunta: por que limitar o nmero de pacotes no confirmados ?
57
GBN: FSM estendida do emissor

Recebe um ACK(n): confirma que todos pacotes at, e inclusive, o No. de seqncia n foram recebidos no receptor: ACK cumulativo pode receber ACKs duplicados. Chamada superior: verifica se a janela est cheia. Se no est, forma o pacote e envia. Se est cheia, recusa.
Temporizador Timeout(n): retransmite pacote n e todos os pacotes com No. de seqncia maiores na janela.
58
Se ocorrer um esgotamento do temporizador, o emissor reenvia TODOS os pacotes que tinham sido previamente enviados, mas que ainda no tinham sido reconhecidos.
Temporizador: um cronmetro para o pacote mais antigo transmitido, mas que ainda no foi reconhecido
59

Se for recebido um ACK, e ainda houver pacotes enviados mas ainda no confirmados, o timer ser reiniciado. Se no houver nenhum pacote pendente (aguardando confirmao), ento o timer desligado.
Temporizador: um cronmetro para o pacote mais antigo transmitido, mas que ainda no foi reconhecido
60
GBN: FSM estendida do receptor
Receptor muito simples: Usa apenas ACK: sempre envia ACK para pacote recebido o.k. com o maior nmero de seqncia em ordem.
expectedseqnum = expectedseqnum + 1
Pode gerar ACKs duplicados S precisa se lembrar do expectedseqnum

Descarta (no armazena) receptor no usa buffers ! Manda ACK de pacote com maior No. de seqncia em ordem.
61
Pacote fora de ordem:
GBN em ao
Janela = 4. Envia de 0 a 3 e o 2 se perde
Confirma os pacotes 0 e 1
Pacote 2 se perdeu. Descarta o 3 e pede o 2 (confirma o 1).
Descarta o 4 e o 5, e continua pedindo o 2.
Timeout do ack de 2. Retransmite o 2.

62
GBN no o TCP
GBN incorpora quase todas as tcnicas que sero
encontradas nos componentes do TCP (visto mais adiante):

Nmero de seqncia; Checksum; ACK cumulativos; Timeouts; Operao de retransmisso
Entretanto existem diferenas entre o TCP e o GBN. Por exemplo: muitas implementaes TCP fazem buffering
de segmentos recebidos corretamente, mas fora de ordem.

TCP um hbrido de GBN e Repetio Seletiva (a seguir).
63
Problemas do GBN
GBN tem problemas de performance.
Se o tamanho da janela grande e o atraso da rede tambm grande, muitos pacotes podem estar no duto. Um nico erro em um segmento resulta na retransmisso de um grande nmero de segmentos, a maioria desnecessrios.
medida em que a probabilidade de erro
do canal cresce, o duto fica lotado de retransmisses desnecessrias.

64
Repetio Seletiva
65
Repetio seletiva
Evita retransmisses desnecessrias. O emissor retransmite apenas os pacotes que ele suspeita terem sido recebidos com erro pelo receptor.
Receptor confirma individualmente todos os pacotes
recebidos corretamente.
Armazena pacotes no buffer, conforme necessrio, para posterior entrega em ordem camada superior.
Emissor apenas re-envia pacotes para os quais o ACK
no foi recebido.
Timer de EMISSOR para cada pacote sem ACK.

N nmeros de seqncia consecutivos. Outra vez limita Nos. de seqncia de pacotes enviados, mas ainda no reconhecidos.
66
Janela do emissor

Repetio seletiva: janelas de remetente e receptor
O emissor j ter recebido confirmao para alguns pacotes da janela.
67
Repetio seletiva no emissor

Dados recebidos de acima. O emissor verifica o prximo nmero
de seqncia disponvel para o pacote.
Se o nmero de seqncia estiver dentro da janela do emissor, os dados so empacotados e enviados;

caso contrrio so bufferizados ou devolvidos camada superior para transmisso posterior.
Timeout. Temporizadores so usados para proteger contra perda de pacotes.
Somente um nico pacote ser transmitido no caso de timeout.
ACK recebido. Se um ACK for recebido, o emissor marca o pacote como recebido.
Se o nmero de seqncia do pacote for igual send-base, ento a base da janela avana at o pacote com o menor nmero de seqncia no-confirmado. Se houver pacotes no transmitidos, com nmeros de seqncia que caem agora dentro da janela, estes pacotes so transmitidos.
68
Repetio seletiva no receptor (1)

Pacote com nmero de seqncia no intervalo [ rcv_base, rcv_base+N-1]
recebido corretamente:
Neste caso, o pacote recebido cai dentro da janela do receptor e um pacote seletivo de ACK retornado ao remetente. Se o pacote no foi recebido previamente, ele armazenado. Se este pacote tiver um nmero de seqncia igual base da janela da recepo (rcv_base), ento este pacote, e os quaisquer pacotes previamente armazenados e numerados em seqncia (comeando com o rcv_base) so entregues camada superior. A janela de recepo movida ento para a frente pelo nmero total dos pacotes entregues camada superior.
Pacote com nmero de seqncia recebido dentro de
[ rcv_base-N, rcv_base-1 ]: Neste caso, um ACK deve ser gerado, mesmo que este seja um pacote que o receptor j tenha confirmado previamente. Se no: Ignora o pacote.
69
Repetio seletiva no receptor (2)

Pacote com nmero de seqncia recebido dentro de [ rcv_base-N, rcv_base-1 ]: Neste caso, um ACK deve ser gerado, mesmo que este seja um pacote que o receptor j tenha confirmado previamente.
[ rcv_base-N, rcv_base-1 ]: pacotes j confirmados anteriormente
Intervalo dentro da janela [ rcv_base, rcv_base+N-1]
70
Repetio seletiva - resumo

emissor Dados de cima:
Se prximo No. de seqncia na
receptor Pacote n dentro de [rcvbase, rcvbase+N-1]:

Envia ACK(n). Fora de ordem: buffering Em ordem: entrega (tb. entrega pacotes em ordem do buffer), avana janela p/ prximo pacote ainda no recebido.
janela, envia pacote.
Timeout(n):
Reenvia pacote n. Reinicia o temporizador.
ACK(n) em [sendbase,sendbase+N]:
Marca pacote n como recebido.
Pacote n em
[rcvbase-N,rcvbase-1]
Se N for menor pacote no
confirmado, avana base da janela ao prximo No. de seqncia no confirmado.
ACK(n), mesmo que j tenha enviado antes.
Seno:
Ignora.
71
Retransmisso seletiva em ao
72
Retransmisso seletiva em ao
Quando um pacote com um nmero de seqncia de rcv_base=2 recebido, ento ele e os pacotes rcv_base+1 e rcv_base+2 podem ser entregues camada superior.
73
Repetio seletiva: dilema
74
Repetio seletiva: dilema

Exemplo:
Nos. de seqncia : 0, 1, 2 e 3.
Tamanho de janela = 3. Receptor no v diferena entre
os dois cenrios (a) e (b) !!! Incorretamente passa dados duplicados como sendo novos em (a). Pergunta: Qual a relao entre tamanho de No. de seqncia e tamanho de janela?
Um tamanho de janela que seja igual ao tamanho de numerao sequencial, menos 1, no vai 75 funcionar.
TCP: Viso geral (1)

RFCs: 793, 1122, 1323, 2018, 2581
Peer-to-Peer (P2P):
nico emissor transmite para um nico receptor.
Fornece fluxo de bytes ordenados e confivel:
No estruturado em mensagens.
dutado (pipelined):
Tamanho da janela ajustado por controle de fluxo e congestionamento do TCP.
Usa Buffers de envio e recepo, e variveis de
estado para cada conexo.

socket door application writes data TCP send buffer
segment
application reads data TCP receive buffer
socket door
76
TCP: Viso geral (2)

RFCs: 793, 1122, 1323, 2018, 2581
O trfego Full Duplex: Fluxo de dados bi-direcional na mesma conexo. MSS: o tamanho mximo de segmento de dados.
(Falaremos de MSS mais adiante)
1500 bytes, 536 bytes ou 512 bytes
orientado a conexo: Handshaking de 3 vias (troca de msgs de controle) inicia estado de remetente, receptor antes de trocar dados.
Tem o Fluxo controlado: o receptor no ser
afogado.
77
TCP: estrutura do segmento

32 bits
URG: dados urgentes (pouco usado)
PSH = push: fora envio de dados imediatamente. Contagem de dados por bytes (no segmentos!)
No. porta origem
No. porta dest
nmero de seqncia
Tamanho do header em palavras de 32 bits
nmero de confirmao (ACK)

tam. sem UAP R S F cab. uso
janela receptor ptr dados urg.

No. bytes que o receptor quer aceitar: Controle de Fluxo.
ACK: No. ACK vlido

RST, SYN, FIN: gesto de conexo (comandos de estabelecimento, liberao) checksum Internet (como UDP)
checksum
Opes (tamanho varivel)
dados da aplicao (tamanho varivel)
20 bytes fixos no header
78
Header TCP
Porta Origem e Porta Destino identificam o processo de aplicao que est enviando dados e o processo de aplicao que ir receber os dados. Nmero de seqncia identifica os bytes enviados. Na prtica ele a identificao do primeiro byte de dados contido no segmento enviado. Os demais so seqenciados a partir deste byte. Acknowledgement identifica os bytes que foram recebidos e tratados sem erro pelo destino, bem como a seqncia do prximo byte esperado Tamanho representa o tamanho total do frame TCP Reservado um campo ainda no utilizado FLAGS identifica as flags (syn, fin, psh, rst, ack, urg) Window identifica o tamanho da janela para o controle de fluxo Checksum destina-se a verificao de erros de transmisso. calculado usando o pseudo header, o header TCP e tambm a rea de dados Urgent Pointer um ponteiro para dados urgentes, contidos na rea de dados.
Gerenciamento de conexes no TCP
80
TCP: Gerenciamento de Conexes (1)

Lembrete: Remetente e receptor TCP estabelecem conexo antes
de trocar segmentos de dados.
Conexo full duplex : fluxo de dados vai nos dois
sentidos. Inicializam variveis TCP: Nmeros de seqncia e confirmao. Buffers, informaes de controle de fluxo (por exemplo RcvWindow) e temporizadores. Cliente: aquele que inicia a conexo.
Active Open
Servidor: aquele chamado pelo cliente. Passive Open.

81
TCP: Iniciando Conexo (1)

Inicializao em 3 passos (3-way handshake): (1): Cliente envia segmento de controle SYN do TCP ao servidor.
Bit SYN do TCP ajustado como 1. (SYN=1; ACK=0) Cliente especifica No. de Seqncia inicial.
(2): Servidor recebe SYN, responde com segmento de controle SYNACK
Ajusta SYN=1 E ACK=1
(SYN=1; ACK=1)
Confirma SYN recebido. Aloca buffers, especifica No. seq. inicial de servidor para o receptor. (SYN=0; ACK=1)
(3): Cliente recebe SYN=1; ACK=1, e responde com segmento de

controle ACK e comea a enviar dados.
82
TCP: Iniciando Conexo (2)

(SYN=1; ACK=0)
(SYN=1; ACK=1)
Servidor confirma o No. seq. do cliente, e envia seu prprio No. de seq.
(SYN=0; ACK=1)
Cliente confirma o No. seq. do server, e comea a enviar dados seguindo seu No. de seq. 83
Estabelecimento da Conexo
Origem A
SYN 1415531521:1415531521 (0) <mss 1024>
Destino B
SYN 1823083482: 1823083482 (0) <mss 1024> ACK 1415531522
ACK 1823083522
Encerramento da Conexo
Half Close Conexes TCP so full-duplex. Cada lado da conexo deve finalizar a conexo de forma independente Quando um dos lados envolvidos recebe uma solicitao de finalizao, deve enviar a notificao para a aplicao.
Uma aplicao aps receber o pedido de finalizao ainda pode mandar dados.
TCP: Fechando uma Conexo (1)

Encerrando uma conexo: Passo 1: cliente envia
segmento de controle FIN ao servidor.
fechar
cliente servidor
Passo 2: servidor recebe FIN,

espera temporizada
fechar
responde com ACK. Tambm pede encerramento da conexo, enviando FIN.

( Segue.... )
fechada
86
TCP: Fechando uma Conexo (2)

Passo 3: cliente recebe FIN,
responde com ACK.
cliente
servidor
fechando
Entre em espera temporizada responder com ACK a FINs recebidos

espera temporizada
fechando
Step 4: servidor, recebe ACK.

Conexo encerrada.
fechada
fechada
87
Encerramento da Conexo
Origem A
FIN 1415531522:1415531522 (0) ACK 1823083522
Destino B
ACK 1415531523
FIN 1823083522: 1823083522 (0) ACK 1415531523
ACK 1823083523
TCP: Ciclo de vida do SERVIDOR

Ciclo de vida do servidor TCP
89
TCP: Ciclo de vida do CLIENTE
Ciclo de vida do cliente TCP

90
MSS e numerao de segmentos
91
MSS (Maximum Segment Size)

O MSS representa o tamanho do maior bloco de
dados que o TCP pretende enviar num nico segmento para o destino. Para a maioria dos computadores o MSS ajustado automaticamente pelo sistema operacional.

Default (obrigatrio): 536 bytes.

(20 bytes IP, 20 bytes TCP, para um total de 576 bytes).
Ethernet padro: 1460 bytes.

(20 bytes IP, 20 bytes TCP, para um total de 1500 bytes)
Quanto maior o MSS, melhor

Em geral, quanto maior o MSS melhor o
desempenho da rede.

Mais dados so enviados num nico segmento. Desde que no ocorra fragmentao. Quanto maior a quantidade de dados enviados em um nico bloco, menor o overhead de headers TCP e IP. O MSS est limitado pelo MTU, que est limitado pela tecnologia ou protocolo da camada de enlace.
Esta relao ser discutida mais adiante, junto com a discusso sobre MTU na camada de rede.
MSS e numerao de segmentos

Aplicao quer enviar 500.000 bytes de dados, Em TCP com MSS = 1.000 bytes Transmisso TCP: 500 partes de 1.000 bytes
1o. segmento
ltimo segmento
94
O No. de sequncia do emissor incrementado pelo No. de bytes enviados
TCP: Nmeros de seqncia e ACKs

Nos. de sequncia:
Host A
Usurio tecla C
Host B
nmero do primeiro byte de dados do segmento. ACKs: No. de sequncia do prximo segmento esperado (em bytes). ACK cumulativo.
B reconhece chegada de C, ecoa C de volta
A reconhece P: Como receptor trata chegada segmentos fora da ordem? do C ecoado Especificao do TCP omissa - deixado ao implementador. Maioria das vezes: buferiza.
tempo cenrio simples de telnet

95
TCP: transferncia confivel de dados no TRANSMISSOR (1/2)

event: data received from application above create, send segment
Passagem dos dados da aplicao ao TCP, e transmisso de um segmento.
wait wait for for event event
event: timer timeout for segment with seq# y retransmit segment
Se no chegar o ACK: Cada vez que o TCP entrega um segmento ao IP (abaixo), ele inicia um temporizador para aquele segmento. Se este temporizador expirar, o TCP responde ao evento de timeout, re-enviando o segmento que causou o timeout.
event: ACK received, with ACK# y

ACK processing
Chegada de um segmento de reconhecimento (ACK) vindo do receptor.
96
TCP: transferncia confivel de dados no TRANSMISSOR (2/2) processamento do ack
event: data received from application above create, send segment
wait wait for for event event
event: timer timeout for segment with seq # y retransmit segment
Chegada de um ACK o emissor deve determinar se o ACK um first-time ACK (para um segmento o qual o remetente ainda est esperando um ACK), ou uma duplicata de ACK, que rereconhea um segmento para qual o remetente j tenha recebido ACK anteriormente.
event: ACK received, with ACK # y

ACK processing
Chegada de um ACK first-time o emissor informado que todos os dados at (inclusive) o byte que est sendo confirmado foram recebidos no receptor. O emissor atualiza sua varivel do estado do TCP que segue o nmero de seqncia do ltimo byte que tenha sido recebido corretamente (e em ordem), no receptor.
97
ACKs duplicados
First time ack sinal que est tudo ok. Mas, o que acontece se o emissor recebe um
ACK duplicado ?
Ou seja, uma duplicata de ACK, que rereconhea um segmento para qual o emissor j tenha recebido ACK anteriormente.
Veremos em seguida como isso usado pelo
TCP...
98
Retransmisso rpida (1/2)

Quando um receptor recebe um segmento com
um nmero de seqncia maior do que prximo nmero de seqncia esperado, ele detecta uma falha no fluxo de dados
Ou seja: detecta um segmento faltante.
Uma vez que o TCP no usa NACK, o receptor
no pode emitir uma negativa de ACK de volta ao emissor.
Ao invs disso, re-reconhece simplesmente o ltimo byte em ordem dos dados que ele recebeu corretamente. Isto , ele gera um ACK em duplicata para o ltimo byte recebido ok.
99
Retransmisso rpida (2/2)

Se o emissor receber trs ACKs
duplicados (ou seja, 4 ACKs idnticos) para o mesmo segmento que ele enviou, ele assume que foi perdido o segmento que vem em seguida ao segmento que foi confirmado 4 vezes.
Neste caso, o TCP executa uma retransmisso rpida re-envia o segmento faltante, mesmo antes que o temporizador do segmento expire [RFC 2581].
100
Entendendo os 3 ACKs duplicados
ACK xxxxxxx523
Ainda no ocorreu timeout
ACK xxxxxxx523
1o. ACK duplicado
Timer
ACK xxxxxxx523 ACK xxxxxxx523
2o. ACK duplicado 3o. ACK duplicado
A chegada de 4 ACKs idnticos antes de vencer o timer daquele ACK, resulta na retransmisso rpida.
101
RFC 2581 - TCP Congestion Control
" The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (4 identical ACKs without the arrival of any other intervening packets) as an indication that a segment has been lost. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire."
http://www.faqs.org/rfcs/rfc2581.html
102
Gerao de ACKs no TCP [RFCs 1122, 2581]

Evento Chegada do segmento em ordem, com nmero de seqncia previsto: todos os dados at o No. de seq. previsto j reconhecidos; nenhum buraco nos dados recebidos. Ao do receptor TCP Promove ACK atrasado Espera at 500ms pela chegada de um outro segmento em ordem. Se o prximo segmento no chegar em ordem neste intervalo, emita um ACK do anterior . Chegada de um segmento em ordem Emita imediatamente um nico ACK com nmero de seqncia previsto. Um cumulativo. Confirmando ambos os outro segmento em ordem aguardando segmentos em-ordem. transmisso de ACK. Nenhum buraco nos dados recebidos. Chegada do segmento fora de ordem com nmero de seqncia mais alto do que esperado detectada falha na sequncia. Emita imediatamente o ACK duplicado, indicando o nmero de seqncia do prximo segmento esperado.
Chegada de segmento que completa Emita imediatamente o ACK, contanto que o parcial ou completamente uma falha nos segmento comece no fim mais baixo da falha. dados recebidos.
103
TCP: cenrios de retransmisso (1)

Estao A Estao B
temporizao
perda
tempo
cenrio do ACK perdido

104
Timeout antes da chegada do ack do primeiro segmento. Reenvia
O ACK do segundo segmento chega on-time
Recebe o ACK do primeiro e host A acha que do re-enviado
Este ACK do reenvio do 1o. Segmento desconsiderado

105

Envia dois segmentos de uma vez e aguarda
O ACK do primeiro segmento se perde
Recebe a indicao que B recebeu tudo certo, at o 100, e no re-envia nada.
Indica que B recebeu tudo certo, at o 100 (aguarda o 120)
106
Controle de FLUXO no TCP
107
TCP: Controle de Fluxo (1)

Para emissor no esgotar os buffers do receptor transmitindo demais, ou muito rapidamente.
RcvBuffer = tamanho do Buffer de recepo. RcvWindow = informa ao emissor quantidade de espao vazio no buffer do receptor.
Este valor mantido como varivel em cada emissor (lembrar que Full Duplex).
buffering pelo receptor

108
TCP: Controle de Fluxo (2)

RECEPTOR: explicitamente avisa o emissor da quantidade de espao livre disponvel (que muda dinamicamente). Campo RcvWindow (janela) no segmento TCP . EMISSOR: mantm a quantidade de dados transmitidos, porm ainda no reconhecidos, MENOR que o valor mais recente de RcvWindow. (isso vale para cada lado da conexo)
109
Troca de informaes sobre controle de fluxo TCP

(1) Aplicao envia 2 Kb (0) 4 Kb = Tamanho do buffer do receptor.
(3) Aplicao envia 3 Kb, mas emissor TCP s pode enviar 2 Kb
(2) Receptor confirma e avisa que pode enviar mais 2 Kb.
(...) Emissor aguarda...
(4) Receptor confirma e pede para aguardar (buffer cheio) win=0
(6) Receptor agora pode enviar at 2 Kb; envia o 1 Kb que falta.
(5) Aplicao l 2 Kb do TCP ; Receptor TCP avisa que pode enviar mais 2 Kb (reconfirma o ltimo recebido e envia janela de 2048)
110
Tempo de resposta (RTT) e ajustes da temporizao de timeout

Retransmisso adaptativa
111
TCP: Tempo de Resposta (RTT) e timeout
P: Como escolher valor do temporizador de timeout do TCP?

Deve ser maior que o RTT.
P: Como estimar RTT?

RTTamostra: tempo medido entre
Note que o RTT pode variar.

Muito curto: temporizao prematura. Retransmisses so desnecessrias. Muito longo: reao demorada perda de segmentos.
a transmisso do segmento e o recebimento do ACK correspondente. Ignora retransmisses, e segmentos com ACKs cumulativos RTTamostra varia.
Necessita ponderador de RTT.
Usa vrias medies recentes, no apenas o valor corrente (RTTamostra)
Atribuir mais peso s amostras
recentes do que s amostras antigas.

112
Mas, no to simples
Ainda h a questo entre o RTT e o timeout. Necessrio ajustar o timeout com o RTT.
No algo simples.
O TCP utilizava normalmente timeout = B*RTT.
Mas, neste caso a dificuldade determinar B. Nas implementaes iniciais, B era fixado em 2. Ou seja, duas idas e voltas (2 x RTT).
Estimativa emprica (leia-se chute).
Mas, um valor constante era inflexvel, e no
atendia os casos em que a variao era maior.

113
Algoritmo original
Medir RTTamostra para cada par segment/ACK Calcular a mdia ponderada do RTT: RTT_estimado = a*RTT_estimado + b*RTTamostra, onde a+b = 1 a: deve ser entre 0.8 and 0.9 b: deve ser entre 0.1 and 0.2 Ajustar timeout baseado no RTT_estimado
TimeOut = 2 * RTT_estimado
114
Proposta de Van Jacobson (1)

1988: Van Jacobson props tornar B
proporcional variao do RTT. Portanto, uma grande variao significa um valor alto para B, e pouca variao significa um valor baixo.
Na prtica ele sugeriu usar o desvio mdio do RTT como uma forma de estimar o desvio padro.
No exato, mas uma aproximao razovel. Desvio mdio dado pela mdia aritmtica dos desvios. Desvio = | valor mdio - valor medido |
115
Proposta de Van Jacobson (2)

A maioria das implementaes atuais usa este algoritmo
e define o intervalo de timeout (ajuste do temporizador) como: timeout = RTT + 4*DevRTT A escolha do fator 4 arbitrria. Minimiza o nmero de retransmisses necessrias:
Menos de 1% de todos os pacotes chegam com atraso de mais de 4 vezes o desvio padro.
Exerccio: Pesquisar e estudar algoritmo Jacobson/Karels.

116
Se voc pensa que acabou (1)

Temporizador de retransmisso no o nico
usado pelo TCP. Na verdade so 4 timers. Retransmisso (j visto) Persistncia Keep-alive Time-wait
117
Temporizador de persistncia
Temporizador de persistncia: Para evitar impasse. Receptor envia pacote de tamanho de janela 0, pedindo para emissor aguardar. De tempos em tempos o emissor faz um teste para ver se pode enviar (devido a risco de perda do pacote de atualizao do receptor)
118
Temporizador keep alive

Temporizador keep alive (mantenha vivo): Para verificar conexes inativas por muito tempo. Um lado verifica se o outro ainda est l.
119
Temporizador Time Wait

Temporizador time wait (tempo de espera):
usado durante o encerramento de uma sesso. ajustado para 2 vezes o tempo de vida mximo de um pacote (TTL - Time to Live). Tenta garantir que quando uma sesso for encerrada, todos os pacotes criados por ela j tenham sido entregues.
120
Controle de Congestionamento
121
Princpios de Controle de Congestionamento (1)
Congestionamento:
Informalmente: trata-se de fontes enviando muitos
dados mais rapidamente do que a rede pode suportar.
Diferente de controle de fluxo.
Retransmisso de pacotes trata o sintoma do
congestionamento da rede (que a perda de segmentos), mas no trata a causa do congestionamento:
Origens tentando enviar dados numa taxa muito alta.
122
Princpios de Controle de Congestionamento (2)

Como se manifesta:

Perda (drop) de pacotes

Esgotamento de buffers em roteadores.
Retransmisso de pacotes.
devido aos drops.
Longos atrasos
Grande enfileiramento nos buffers dos roteadores.
123
Soluo para o Congestionamento

Verdadeira soluo para o congestionamento
diminuir a taxa de transmisso de dados.
No inserir novos pacotes na rede, at que os antigos tenham sado.

Ou seja, at que os antigos tenham sido entregues.
TCP tenta alcanar esse objetivo.
Manipulando dinamicamente o tamanho da janela.
124
O que o TCP faz para evitar congestionamentos:

Quando uma conexo estabelecida, escolhe um
tamanho de janela adequado.
Veremos mais adiante como esta escolha.
O receptor pode especificar uma janela a partir do
tamanho de seu buffer.
Indica o quanto ele est disposto a receber.
Se o transmissor se mantiver dentro do tamanho da
janela, no haver problemas causados pela sobrecarga dos buffers no receptor. Mas eles ainda podem ocorrer devido a congestionamentos internos na rede.
125
TCP: Controle de Congestionamento (1)

Deve-se entender que existem dois
problemas potenciais:

Capacidade do receptor. Capacidade da rede.
Deve-se tratar cada um em separado.

Para isso, cada transmissor mantm duas janelas:
Janela fornecida pelo receptor. RcvWin Janela de congestionamento: CongWin

126
TCP: Controle de Congestionamento (2)

Cada uma identifica o nmero de bytes que o
transmissor pode enviar
pode enviar o valor mnimo das duas janelas.
Ento, a quantidade mxima de dados no
confirmados que um host pode enviar em uma conexo:

LastByteSent - LastByteAcked min{CongWin, RcvWin}
127
TCP: Controle de Congestionamento

Controle fim a fim (sem apoio da rede). Taxa de transmisso limitada pela tamanho da janela de congestionamento Congwin:
Congwin
A janela efetiva o mnimo do que o transmissor e o receptor consideram vivel. Veremos exemplo a seguir....
128
TCP: Controle de Congestionamento

A janela efetiva o mnimo do que o
transmissor e o receptor consideram vivel. Se o receptor disser: envie 8KB, mas...
se o transmissor souber que qualquer rajada com mais de 4 KB poder congestionar a rede,
ele enviar apenas 4 KB.
Se o receptor disser: envie 8KB, e o
transmissor souber que rajadas de at 32 KB passam pela rede sem problemas, ele enviar os 8 KB solicitados.
129
Como funciona o controle:

Sondagem para banda a ser
Duas fases
1.
2.
usada:
Transmitir o mais rpido possvel sem perder pacotes. (ou seja, Congwin ajustado ao mximo possvel) Aumentar Congwin at perder pacotes isso causa congestionamento.
Partida lenta. Preveno de congestionamento. Congwin threshold:

define limiar entre fases de partida lenta e controle de congestionamento. Tambm chamado de patamar.
Variveis importantes:
Quando houver perdas: diminuir Congwin.

Depois volta a sondagem (aumentando) novamente.
Tudo explicado a seguir...

130
Partida lenta e sondagem do congestionamento (1)

Conexo estabelecida transmissor ajusta
a janela de congestionamento igual ao MSS em uso.
Em seguida, ele envia este segmento mximo. Se esse segmento for confirmado antes de ocorrer um timeout, o transmissor:
Adicionar o nmero de bytes de 1 segmento na janela de congestionamento, de modo que ela tenha capacidade equivalente a 2 segmento mximos. Enviar os 2 segmentos... .... (continua...)
131
Partida lenta e sondagem do congestionamento (2)

medida que cada um desses segmentos for
confirmado, a janela de congestionamento aumentada em um tamanho deste segmento mximo, de tal forma que - quando ambos forem confirmados - a janela ter agora 4 vezes o valor inicial.
Quando a janela de congestionamento chegar a n segmentos, e se todos os n segmentos forem confirmados a tempo, a janela de congestionamento ser aumentada pelo nmero de bytes correspondentes aos n segmentos.
Na prtica, cada rajada confirmada duplica a janela
de congestionamento atual: crescimento exponencial.
132
TCP: Partida lenta

Algoritmo de Partida Lenta
inicializa: Congwin = 1 for (cada segmento c/ ACK) Congwin++ until (evento de perda OR CongWin > threshold)
RTT
Estao A Estao B
Veremos o que isso a seguir...
A cada RTT ocorre um
aumento exponencial no tamanho da janela.
tempo
Partida no to lenta!
133
Quando parar o crescimento?

Mas, quando parar o crescimento ? Obviamente este crescimento ter de ser
interrompido em algum momento, devido a congestionamento da rede ou capacidade do receptor. Para isso usado o parmetro de threshold. Vejamos como...
134
Threshold
Algoritmo de controle de congestionamento
TCP utiliza um terceiro parmetro limitante: o threshold.
Tambm chamado de limiar ou patamar.
Threshold definido inicialmente como 64KB. O crescimento exponencial interrompido quando o threshold alcanado. Ento o crescimento passa a ser linear.
Quando atingir o threshold, a varivel congwin passa a aumentar de um MSS para cada rajada.
135
Threshold e o timeout
Quando h um timeout, o threshold atribudo
metade da janela de congestionamento atual, e a janela de congestionamento reinicializada para 1 MSS. Na prtica, esse algoritmo diminui o tamanho da janela de congestionamento metade, e depois retoma seu crescimento a partir da.
136
TCP: Evitar Congestionamento (1)

(2) Quando atinge threshold, o crescimento passa a ser linear (fase de preveno de congestionamento) timeout
(3) Quando h timeout, congwin volta para 1 MSS, e threshold cai pela metade
(1) Fase de partida lenta
(2.1) Quando atinge o threshold o aumento de um segmento mximo para cada rajada em vez de um para cada segmento. 137
TCP: Evitar Congestionamento (2)

Evitar congestionamento
timeout
/* partida lenta acabou */ /* Congwin > threshold */ Until (event de perda) { cada w segmentos reconhecidos: Congwin++ } threshold = Congwin/2 Congwin = 1 faa partida lenta
138
AADM / Additive-Increase, Multiplicative-Decrease (AIMD)

Desconsiderando a
Justeza do TCP
Meta de justeza: se N sesses TCP compartilham o mesmo enlace, cada uma deve ganhar 1/N da capacidade do enlace.
TCP conexo 1
fase de partida lenta: TCP usa AADM:
Aumento Aditivo, Decremento Multiplicativo
Aumenta janela em 1 a cada RTT. Diminui janela por fator de 2 quando um evento de perda acontece.
TCP conexo 2
Roteador gargalo capacidade R

139
Captulo 3: Sumrio
Princpios por trs dos servios
da camada de transporte:
Multiplexao / desmultiplexao transferncia confivel de dados controle de fluxo controle de congestionamento Instanciao e implementao na Internet. UDP TCP
Prximo captulo:
Samos da borda da rede
(camadas de aplicao e transporte) Entramos no ncleoda rede.
140
141
Exerccio proposto:
Estudar a diferenas e semelhanas entre os
algoritmos TCP Reno e TCP Tahoe, entendendo como eles atuam com relao emisso de ACKs e recuperao de falhas.
142
143

Camada de Transporte

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Camada de Transporte

Uploaded by

Copyright:

Available Formats

unesp - IBILCE - SJRP

Curso de Redes de Computadores 2010

Captulo 3 Camada de Transporte

unesp - IBILCE - SJRP

Captulo 3: Camada de Transporte

princpios dos servios da camada de transporte:

Multiplexao/ desmultiplexao. Transferncia confivel de dados. Controle de fluxo. Controle de congestionamento.

dados. Transporte orientado a conexo: TCP

Transferncia confivel Controle de fluxo Gerenciamento de conexes

congestionamento. Controle de congestionamento em TCP.

unesp - IBILCE - SJRP

Comparao entre as camadas

Esta distino sutil, mas MUITO importante!

unesp - IBILCE - SJRP