unesp - IBILCE - SJRP Curso de Redes de Computadores...

unesp - IBILCE - SJRP

1

Curso de

Redes de Computadores

2010

Adriano Mauro [email protected]

Captulo 3

Camada de Transporte


2

Captulo 3: Camada de Transporte

Metas do captulo:

Compreender os

princpios dos servios da

camada de transporte:

Multiplexao/

desmultiplexao.

Transferncia confivel

de dados.

Controle de fluxo.

Controle de

congestionamento.

Instanciao e

implementao na

Internet.

O que veremos:

Servios da camada de transporte.

Multiplexao/desmultiplexao.

Transporte sem conexo: UDP.

Princpios de transferncia confivel de

dados.

Transporte orientado a conexo: TCP

Transferncia confivel

Controle de fluxo

Gerenciamento de conexes

Princpios de controle de

congestionamento.

Controle de congestionamento em TCP.


3

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!


4

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.


5

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).


6

Servios e protocolos de TRANSPORTE (1)

Prov comunicao lgicaentre processos de aplicao

executando em hosts

diferentes.

Protocolos de transporte

rodam em sistemas finais.

Camada de rede: dados

transferidos entre hosts.

Camada de transporte:

dados transferidos entre

processos.

aplicaotransporte

redeenlacefsica

redeenlacefsica

aplicaotransporte

redeenlacefsica

redeenlacefsica

redeenlacefsica

redeenlacefsica

redeenlacefsica


7

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.


8

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

4, superior camada de

rede.

aplicaotransporte

redeenlacefsica

redeenlacefsica

aplicaotransporte

redeenlacefsica

redeenlacefsica

redeenlacefsica

redeenlacefsica

redeenlacefsica


9

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).

Entrega no confivel, (melhor

esforo), no ordenada, ponto a

ponto ou multiponto: UDP.

aplicaotransporte

redeenlacefsica

redeenlacefsica

aplicaotransporte

redeenlacefsica

redeenlacefsica

redeenlacefsica

redeenlacefsica

redeenlacefsica


10

Multiplexao/desmultiplexao (1)

MULTIPLEXAO: Juntar dados de mltiplos

processos de aplicaes, encapsulando dados com

cabealho (usado depois para demultiplexao).

aplicaotransporte

rede

MP2

aplicaotransporte

rede

receptor

Ht

Hn segmento

segmento Maplicao

transporterede

P1M

M M

P3 P4

cabealhode segmento

dados da camada de aplicao


11


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.

aplicaotransporte

rede

MP2

aplicaotransporte

rede

receptor

Ht

Hn segmento

segmento Maplicao

transporterede

P1M

M M

P3 P4

cabealhode segmento



12

aplicaotransporte

rede

MP2

aplicaotransporte

rede


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.

receptor

Ht

Hn segmento

segmento Maplicao

transporterede

P1M

M M

P3 P4

cabealhode segmento



13


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.

porta emissor porta receptor

32 bits

dados daaplicao

(mensagem)

outros campos

do cabealho

formato genrico de segmento

TCP/UDP


14

estaoA

Multiplexao/desmultiplexao: exemplos

servidor B

porta orig.: xporta dest: 23

porta orig:23porta dest: x

uso de portas:

aplicao simples de telnet

Cliente WWWestao A

servidor WWW B

Web clienthost C

IP orig: CIP dest: B

porta orig: xporta dest: 80

IP orig : CIP dest: B

porta orig: yporta dest: 80

Uso de portas : servidor WWW

IP orig: AIP dest: B

porta orig: xporta dest: 80


15

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.


16

Mais sobre UDP

Muito utilizado para aplicaes de

meios contnuos (voz, vdeo)

So tolerantes a perdas.

So sensveis taxa de

transmisso.

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!

porta origem porta dest.

32 bits

Dados de aplicao

(mensagem)

Formato de um sgmento UDP

comprimento checksum

Comprimento embytes do

segmento UDP,incluindo cabealho


17

Checksum UDP

Emissor:

Trata contedo do segmento

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...

Receptor:

Computa checksum do segmento recebido

Verifica se checksumcomputado zero:

NO - erro detectado.

SIM - nenhum erro detectado. Mas ainda pode ter erros?(Veremos mais adiante .)

Meta: detectar falha no segmento transmitido.


18

Exemplo de clculo do checksum (1)

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.

Ver RFC-1071 !


19

Lembrete 1: mtodo PolinomialModo 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 ComputerNetworking: 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


Lembrete 2: carry

20


21


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 ??


22


Assim o complemento de 1's da soma 1100101011001010

0011010100110101

Este valor se torna o checksum.


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)

24

Pseudo header

IP (usado pelo UDP)

(16 bytes)

Header UDP

(8 bytes)

Violao da independncia das camadas


25

Princpios de Transferncia confivel de dados

Reliable Data Transfer

(RDT)


26

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).


27

Transferncia confivel de dados (RDT): como comear

emissor receptor

rdt_rcv(): chamada quando pacote

chega no lado receptor do canal.

deliver_data(): chamada por

rdt para entregar dados para

camada superior.

udt_send(): chamada por ambos

os lados para troca de pacotes de

controle. UDT representa um

unreliable data transfer.

rdt_send( ): chamada da camada superior, (Ex:

pela aplicao). Passa dados para entregar

camada superior receptora


28

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.

estado1

estado2

evento causando transio de estadosaes tomadas na transio de estado

ESTADO: quando o

sistema est num

estado, o prximo

estado determinado

unicamente pelo prximo

evento.

eventoaes


29

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


30

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.


31

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 )


32

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.


33

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


34

rdt2.0: especificao da FSM - EmissorPossui 2 estados: Em um estado

aguarda dados da camada superior.

Em outro estado, aguarda ACK ou

NACK do receptor Aguarda dados da

aplicao

Aguarda ACK ou

NACK do receptor

Se recebe um ACK confirmando que o

dado atual foi recebido, retorna ao

estado de aguardar um pacote da

camada superior

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)

1

2

3


35

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.


36

rdt2.0: em ao (sem erros)

FSM do remetente FSM do receptor


37

rdt2.0: em ao (cenrio de erro)

FSM do remetente FSM do receptor


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


40

rdt2.0 tem uma falha fatal!

O que acontece se ACK ou 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?

E se perder ACK/NAK do remetente?

Retransmitir?

Mas pode causar retransmisso de pacote recebido certo!

Lidando com duplicao:

Emissor inclui nmero de

seqncia para cada

pacote.

Emissor retransmite

pacote atual se ACK/NAK

recebido com erro.

Receptor descarta pacote

duplicado.

Remetente envia um pacote,e ento aguarda resposta do receptor.

Stop and wait


41

rdt2.1: EMISSOR, trata ACK/NAKs com erro

Insere No. de

seqncia 0 no pacote

Deve verificar

se ACK/NAK

recebido tinha

erro

Aguarda a chegada

do No. Seq. correto

1

2

3

4


42

rdt2.1: receptor, trata ACK/NAKs com erroDeve checar se pacote

recebido duplicado.

O estado indica se No. de

seqncia esperado 0 ou 1Pacote corrompido

No. Seq. errado


43

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.


44

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.


45

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 doEMISSOR

!


46

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.


47

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.


48

rdt3.0: remetente

Esgotou o timer:

reenvia o anterior

Inicia o timer e aguarda

o ack


49

rdt3.0 em ao


50

rdt3.0 em ao


51

Protocolos dutados (pipelined)


Problema com protocolo stop & wait

Em longas distncias: retardo fim-a-fim grande.

Pacote em trnsito, ainda no confirmado.

52


53

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, :

Ttransmisso

=8 kbits/pacote

10**9 b/seg= 8 microseg

Desempenho =8 microseg

30.016 mseg= 0,027 %

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


54

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).


55

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.


56

GBN - Go Back N (2)

[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.

send_base = Seq. # do pacote mais antigo no confirmado no duto.

nextseqnum = Menor Seq. # no usado (Seq.# do prximo a enviar).


57

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 ?


58

GBN: FSM estendida do emissor

Chamada superior:

verifica se a janela est

cheia. Se no est,

forma o pacote e envia.

Se est cheia, recusa.

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.

Temporizador

Timeout(n): retransmite pacote n e

todos os pacotes com No. de

seqncia maiores na janela.


59


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


60


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


61

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.

Pode gerar ACKs duplicados

S precisa se lembrar do expectedseqnum

Pacote fora de ordem: Descarta (no armazena) receptor no usa buffers !

Manda ACK de pacote com maior No. de seqncia em ordem.

expectedseqnum =

expectedseqnum + 1


62

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.


63

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).


64

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.


65

Repetio Seletiva


66

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.

Janela do emissor N nmeros de seqncia consecutivos.

Outra vez limita Nos. de seqncia de pacotes enviados, mas ainda no reconhecidos.


67

Repetio seletiva: janelas de remetente e receptor

O emissor j ter

recebido confirmao

para alguns pacotes

da janela.


68

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.


69

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.


70

Repetio seletiva no receptor (2)

Intervalo dentro da janela

[ rcv_base, rcv_base+N-1]

[ rcv_base-N, rcv_base-1 ]:

pacotes j confirmados anteriormente

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.


71

Repetio seletiva - resumo

Dados de cima:

Se prximo No. de seqncia na

janela, envia pacote.

Timeout(n):

Reenvia pacote n.

Reinicia o temporizador.

ACK(n) em [sendbase,sendbase+N]:

Marca pacote n como recebido.

Se N for menor pacote no

confirmado, avana base da

janela ao prximo No. de

seqncia no confirmado.

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.

Pacote n em [rcvbase-N,rcvbase-1]

ACK(n), mesmo que j tenha

enviado antes.

Seno:Ignora.

receptoremissor


72

Retransmisso seletiva em ao


73

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.


Repetio

seletiva: dilema

74


75

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 funcionar.


76

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

TCP

send buffer

TCP

receive buffer

socket

door

segment

application

writes data

application

reads data


77

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)

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.

1500 bytes, 536 bytes

ou 512 bytes


78

TCP: estrutura do segmento

No. porta origem No. porta dest

32 bits

dados da

aplicao

(tamanho varivel)

nmero de seqncia

nmero de confirmao (ACK)

janela receptor

ptr dados urg.checksum

FSRPAUtam.cab.

semuso

Opes (tamanho varivel)

URG: dados urgentes

(pouco usado)

ACK: No. ACK vlido

PSH = push: fora

envio de dados

imediatamente.

RST, SYN, FIN:

gesto de conexo

(comandos de

estabelecimento,

liberao)

No. bytes que o

receptor quer

aceitar: Controle

de Fluxo.

Contagem

de dados

por bytes

(no segmentos!)

checksum

Internet

(como UDP)

Tamanho do header

em palavras de 32 bits

20 bytes fixos

no header


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.


80

Gerenciamento de conexes no

TCP


81

TCP: Gerenciamento de Conexes (1)

Lembrete: Remetente e receptor TCP estabelecem conexo antesde 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.


82

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 SYN-ACK

Ajusta SYN=1 E ACK=1 (SYN=1; ACK=1)

Confirma SYN recebido.

Aloca buffers, especifica No. seq. inicial de servidor para o

receptor.

(3): Cliente recebe SYN=1; ACK=1, e responde com segmento de controle ACK e comea a enviar dados. (SYN=0; ACK=1)


83

TCP: Iniciando Conexo (2)

(SYN=1; ACK=0)

(SYN=1; ACK=1)

(SYN=0; ACK=1)

Cliente confirma o

No. seq. do server,

e comea a enviar

dados seguindo

seu No. de seq.

Servidor confirma o

No. seq. do cliente,

e envia seu prprio

No. de seq.


Estabelecimento da Conexo

Origem

A

Destino

BSYN 1415531521:1415531521 (0)

SYN 1823083482: 1823083482 (0)

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.


86

TCP: Fechando uma Conexo (1)

Encerrando uma conexo:

Passo 1: cliente envia segmento de controle FIN ao

servidor.

Passo 2: servidor recebe FIN, responde com ACK.

Tambm pede encerramento

da conexo, enviando FIN.

( Segue.... )

cliente servidor

fechar

fechar

fechada

esp

era

te

mpo

riza

da


87

TCP: Fechando uma Conexo (2)

Passo 3: cliente recebe FIN, responde com ACK.

Entre em espera

temporizada -

responder com ACK a

FINs recebidos

Step 4: servidor, recebe ACK. Conexo encerrada.

cliente servidor

fechando

fechando

fechada

esp

era

tem

pori

zada

fechada


Encerramento da Conexo

Origem

A

Destino

BFIN 1415531522:1415531522 (0) ACK 1823083522

ACK 1415531523

ACK 1823083523

FIN 1823083522: 1823083522 (0)

ACK 1415531523


89

TCP: Ciclo de vida do SERVIDOR

Ciclo de vida do servidor TCP


90

TCP: Ciclo de vida do CLIENTE

Ciclo de vida do cliente TCP


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.


94

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

O No. de sequncia do emissor incrementado pelo No. de bytes enviados


95

TCP: Nmeros de seqncia e ACKs

Nos. de sequncia:

nmero do primeiro

byte de dados do

segmento.

ACKs: No. de

sequncia do prximo

segmento esperado

(em bytes).

ACK cumulativo.

P: Como receptor trata segmentos fora da ordem?

Especificao do TCP

omissa - deixado ao

implementador.

Maioria das vezes:

buferiza.

Host AHost B

UsurioteclaC

A reconhecechegadado Cecoado

B reconhecechegada de C, ecoa

C de volta

tempo

cenrio simples de telnet


96

TCP: transferncia confivel de dados no

TRANSMISSOR (1/2)

waitfor

event

waitfor

event

event: data received

from application above

event: timer timeout for

segment with seq# y

event: ACK received,

with ACK# y

create, send segment

retransmit segment

ACK processing

Passagem dos dados da aplicao ao

TCP, e transmisso de um segmento.

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.

Chegada de um segmento

de reconhecimento (ACK)

vindo do receptor.


97

TCP: transferncia confivel de dados no

TRANSMISSOR (2/2) processamento do ack

waitfor

event

waitfor

event

event: data received

from application above

event: timer timeout for

segment with seq # y

event: ACK received,

with ACK # y

create, send segment

retransmit segment

ACK processing

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 re-

reconhea um segmento para

qual o remetente j tenha recebido

ACK anteriormente.

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.


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 re-

reconhea um segmento para qual o emissor j

tenha recebido ACK anteriormente.

Veremos em seguida como isso usado pelo

TCP...

98


99

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.


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

101

ACK xxxxxxx523

ACK xxxxxxx523

ACK xxxxxxx523

ACK xxxxxxx523Ain

da n

o

ocorr

eu t

imeout

1o. ACK duplicado

2o. ACK duplicado

3o. ACK duplicado

Tim

er

A chegada de 4 ACKs idnticos antes de vencer o timer

daquele ACK, resulta na retransmisso rpida.


RFC 2581 - TCP Congestion Control

102

" 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


103

Gerao de ACKs no TCP [RFCs 1122, 2581]

Evento Ao do receptor TCP

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.

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 com nmero de seqncia previsto. Um outro segmento em ordem aguardando transmisso de ACK. Nenhum buraco nos dados recebidos.

Emita imediatamente um nico ACK cumulativo. Confirmando ambos os segmentos em-ordem.

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 parcial ou completamente uma falha nos dados recebidos.

Emita imediatamente o ACK, contanto que o segmento comece no fim mais baixo da falha.


104

TCP: cenrios de retransmisso (1)

Estao A

perdatem

pori

za

o

tempo cenrio doACK perdido

Estao B

X


105


Timeout antes

da chegada do

ack do primeiro

segmento. Re-

envia

Recebe o ACK

do primeiro e host

A acha que do

re-enviadoEste ACK do re-

envio do 1o.

Segmento

desconsiderado

O ACK do

segundo

segmento chega

on-time


106


Indica que B

recebeu tudo

certo, at o 100

(aguarda o 120)

Recebe a indicao

que B recebeu tudo

certo, at o 100, e no

re-envia nada.

O ACK do

primeiro

segmento se

perde

Envia dois

segmentos de

uma vez e

aguarda


107

Controle de FLUXO no TCP


108

TCP: Controle de Fluxo (1)

buffering pelo receptor

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).

Para emissor no esgotar os buffers do receptor

transmitindo demais, ou muito rapidamente.


109

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)


110

Troca de informaes sobre controle de fluxo TCP

(0) 4 Kb = Tamanho

do buffer do receptor.

(1) Aplicao

envia 2 Kb

(2) Receptor

confirma e avisa que

pode enviar mais 2

Kb.

(4) Receptor

confirma e pede

para aguardar

(buffer cheio) win=0(...) Emissor

aguarda...

(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)

(6) Receptor agora

pode enviar at 2

Kb; envia o 1 Kb que

falta.

(3) Aplicao

envia 3 Kb, mas

emissor TCP s

pode enviar 2 Kb


111

Tempo de resposta (RTT) e ajustes da

temporizao de timeout

Retransmisso adaptativa


112

TCP: Tempo de Resposta (RTT) e timeout

P: Como escolher valor

do temporizador de

timeout do TCP?

Deve ser maior que o RTT.

Note que o RTT pode

variar.

Muito curto: temporizao

prematura.

Retransmisses so

desnecessrias.

Muito longo: reao

demorada perda de

segmentos.

P: Como estimar RTT?

RTTamostra: tempo medido entre

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.


113

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.


Algoritmo original

114

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


115

Proposta de Van Jacobson (1)

1988: Van Jacobson props tornar Bproporcional 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 |


116

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.


117

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


118

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)


119

Temporizador keep alive

Temporizador keep alive (mantenha vivo):

Para verificar conexes inativas por muito tempo.

Um lado verifica se o outro ainda est l.


120

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.


121

Controle de Congestionamento


122

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.


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


124

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.


125

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.


126

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


127

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}


128

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....


129

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.


130

Como funciona o controle:

Duas fases

1. Partida lenta.

2. Preveno de

congestionamento.

Variveis importantes:

Congwin

threshold:

define limiar entre fases

de partida lenta e controle

de congestionamento.

Tambm chamado de

patamar.

Tudo explicado a seguir...

Sondagem para banda a ser usada:

Transmitir o mais rpido possvel sem perder pacotes. (ou seja, Congwin ajustado ao mximo possvel)

Aumentar Congwin at perder pacotes isso causa congestionamento.

Quando houver perdas: diminuir Congwin.

Depois volta a sondagem (aumentando) novamente.


131

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...)


132

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.


133

TCP: Partida lenta

A cada RTT ocorre um aumento exponencialno tamanho da janela. Partida no to lenta!

Algoritmo de Partida Lenta

inicializa: Congwin = 1

for (cada segmento c/ ACK)

Congwin++

until (evento de perda OR

CongWin > threshold)

Estao A

RT

T

Estao B

tempo

Veremos o que isso a seguir...


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


135

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.


136

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.


137

TCP: Evitar Congestionamento (1)

(3) Quando h

timeout, congwin

volta para 1 MSS, e

threshold cai pela

metade

timeout

(2) Quando atinge

threshold, o

crescimento passa a

ser linear

(fase de preveno de

congestionamento)

(2.1) Quando atinge o threshold o aumento de um segmento mximo para

cada rajada em vez de um para cada segmento.

(1) Fase de

partida lenta


138

TCP: Evitar Congestionamento (2)

Evitar congestionamento

/* partida lenta acabou */

/* Congwin > threshold */

Until (event de perda) {

cada w segmentos

reconhecidos:

Congwin++

}

threshold = Congwin/2

Congwin = 1

faa partida lenta

timeout


139

Justeza do TCP

Meta de justeza: se N sesses

TCP compartilham o

mesmo enlace, cada uma

deve ganhar 1/N da

capacidade do enlace.

Desconsiderando a

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.

AADM / Additive-Increase, Multiplicative-Decrease (AIMD)

TCP conexo 1

Roteadorgargalo

capacidade R

TCP conexo 2


140

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.


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

unesp - IBILCE - SJRP Curso de Redes de Computadores...

Documents

Transcript of unesp - IBILCE - SJRP Curso de Redes de Computadores...