Capítulo 3 Camada de transporte - ic.uff.brlsousa/redes_i/cap-3.pdf · 4 3.1 – Introdução e serviços da camada de transporte 3.2 – Multiplexação e Demultiplexação 3.3

Capítulo 3

Camada de transporte

2

Redes de computadores I

Prof.: Leandro Soares de Sousa

E-mail: [email protected]

Site: http://www.ic.uff.br/~lsousa

Não deixem a matéria acumular!!!

Datas das avaliações, exercícios propostos, transparências,... no site!

http://www.ic.uff.br/~lsousa

3

● Metas do capítulo:

● compreender os princípios atrás dos serviços da camada de transporte:

● multiplexação/demultiplexação● transferência confiável de dados● controle de fluxo● controle de congestionamento

● aprender os protocolos da camada de transporte da Internet:

● UDP: transporte sem conexão● TCP: transporte orientado a conexões● Controle de congestionamento do TCP

A camada de transporte

4

3.1 – Introdução e serviços da camada de transporte3.2 – Multiplexação e Demultiplexação3.3 – Transporte não orientado para conexão: UDP3.4 – Princípios da transferência confiável de dados3.5 – Transporte orientado para conexão: TCP3.6 – Princípios do controle de congestionamento3.7 – Controle de congestionamento no TCP

Sumário

5


Sumário

6

● protocolos de transporte executam em sistemas finais: ● lado transmissor: quebra

as mensagens das aplicações em segmentos, repassa-os para a camada de rede

● lado receptor: remonta as mensagens a partir dos segmentos, repassa-as para a camada de aplicação

Introdução e serviços de camada de transporte

7

● existem mais de um protocolo de transporte disponível para as aplicações (Internet: TCP e UDP)

● Um protocolo de camada de transporte fornece comunicação lógica entre processos que rodam em hospedeiros diferentes.

• Um protocolo de camada de rede fornece comunicação lógica entre hospedeiros.


8

● Os serviços que um protocolo de transporte pode fornecer são muitas vezes limitados pelo modelo de serviço do protocolo subjacente da camada de rede.


9

● A responsabilidade fundamental do UDP e do TCP é ampliar o serviço de entrega IP entre dois sistemas finais para um serviço de entrega entre dois processos que rodam nos sistemas finais.

• A ampliação da entrega hospedeiro a hospedeiro para entrega processo a processo é denominada multiplexação / demultiplexação de camada de transporte.

• O UDP e o TCP também fornecem verificação de integridade ao incluir campos de detecção de erros nos cabeçalhos de seus segmentos.


10

● A entrega confiável, ordenada (TCP)

● controle de congestionamento● controle de fluxo● estabelecimento de conexão

(“setup”)

● A entrega não confiável, não ordenada: UDP

● extensão sem “frescuras” do “melhor esforço” do IP

● Serviços não disponíveis: ● garantias de atraso● garantias de largura de banda● intervalo entre pacotes

Protocolos da camada de transporte da Internet

11


Sumário

12

• Multiplexação e demultiplexação na camada de transporte

Multiplexação e demultiplexação

13

• A tarefa de entregar os dados contidos em um segmento da camada de transporte ao socket correto é denominada demultiplexação.

• O trabalho de reunir, no hospedeiro de origem, partes de dados provenientes de diferentes sockets, encapsular cada parte de dados com informações de cabeçalho para criar segmentos, e passar esses segmentos para a camada de rede é denominada multiplexação.


14

• Campos de número de porta de origem e de destino em um segmento de camada de transporte:

● O host recebe os datagramas IP● cada datagrama possui os

endereços IP da origem e do destino

● cada datagrama transporta 1 segmento da camada de transporte

● cada segmento possui números das portas origem e destino (lembre: números de portas bem conhecidas para aplicações específicas)

● O host usa os endereços IP e os números das portas para direcionar o segmento ao socket apropriado


15

• Demultiplexação sem Conexões:

● Criando, por exemplo, sockets com números de porta:

● DatagramSocket mySocket1 = new DatagramSocket(99111);● DatagramSocket mySocket2 = new DatagramSocket(99222);

• O socket UDP será identificado pela dupla:>>>>>> end IP dest, no. da porta destino <<<<<<

• Quando host recebe segmento UDP:

● verifica no. da porta de destino no segmento● encaminha o segmento UDP para o socket com aquele no. de

porta● Datagramas IP com diferentes endereços IP origem e/ou números

de porta origem são encaminhados para o mesmo socket


16

• Demultiplexação sem Conexões (continuação):

DatagramSocket serverSocket = new DatagramSocket(6428);

SP (source port) provê “endereço de retorno”


17

• Demultiplexação orientada a Conexões:

● Socket TCP identificado pela 4-dupla: ● endereço IP origem● número da porta origem● endereço IP destino● número da porta destino

● receptor usa todos os quatro valores para direcionar o segmento para o socket apropriado

● Servidor pode dar suporte a muitos sockets TCP simultâneos: ● cada socket é identificado pela sua própria 4-dupla

● Servidores Web têm sockets diferentes para cada conexão cliente

● HTTP não persistente terá sockets diferentes para cada pedido


18

• Demultiplexação orientada a Conexões:


19

• Demultiplexação orientada a Conexões (com threads):


20


Sumário

21

• O UDP, definido no [RFC 768], faz apenas quase tão pouco quanto um protocolo de transporte pode fazer.

• À parte sua função de multiplexação/demultiplexação e de alguma verificação de erros simples, ele nada adiciona ao IP.

• Se o desenvolvedor de aplicação escolher o UDP, em vez do TCP, a aplicação estará “falando” quase diretamente com o IP.

• O UDP é não orientado para conexão.

Transporte não orientado para conexão: UDP

22

• Para que serve o UDP então?

● À elimina estabelecimento de conexão (o que pode causar retardo)

● simples: não se mantém “estado” da conexão no remetente/receptor

● pequeno cabeçalho de segmento

● sem controle de congestionamento: UDP pode transmitir o mais rápido possível


23

• Aplicações populares da Internet e seus protocolos de transporte subjacentes:


24

• Aplicações populares da Internet e seus protocolos de transporte subjacentes:

Estrutura do segmento UDP

25

• A soma de verificação UDP serve para detectar erros.

• Suponha que tenhamos as seguintes três palavras de 16 bits:

• A soma das duas primeiras é:

• Adicionando a terceira palavra à soma anterior, temos:

Soma de verificação UDP

26


Sumário

27

• Modelo do serviço e implementação do serviço:

Princípios da transferência confiável de dados

28

• rdt1.0 – Um protocolo para um canal completamente confiável● não tem erros de bits● não tem perda de

pacotes• FSMs separadas para

remetente e receptor:● remetente envia dados

pelo canal subjacente● receptor recebe dados do

canal subjacente

Transferência confiável de dados sobre um canal perfeitamente confiável: rdt1.0

29

• canal subjacente pode inverter bits no pacote● lembre-se: checksum UDP pode detectar erros de bits

• a questão: como recuperar dos erros?● reconhecimentos (ACKs): receptor avisa explicitamente

ao remetente que pacote chegou bem● reconhecimentos negativos (NAKs): receptor avisa

explicitamente ao remetente que pacote tinha erros● remetente retransmite pacote ao receber um NAK● cenários humanos usando ACKs, NAKs?

• novos mecanismos em rdt2.0 (em relação ao rdt1.0):● detecção de erros● realimentação pelo receptor: msgs de controle (ACK,NAK)

receptor->remetente

Transferência confiável de dados sobre um canal com erros de bits: rdt2.0

30Transferência confiável de dados sobre um canal com erros de bits: rdt2.0

31Transferência confiável de dados sobre um canal com erros de bits: rdt2.0

Qual é o erro?

32

• O que acontece se ACK/NAK com erro?● Remetente não sabe o que se passou no receptor!● não se pode apenas retransmitir: 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 retransmissão de pacote recebido

certo!

• Lidando c/ duplicação: ● remetente inclui número de sequência p/ cada pacote● remetente retransmite pacote atual se ACK/NAK recebido com erro● receptor descarta (não entrega) pacote duplicado

• Remetente envia um pacote, e então aguarda resposta do receptor


33

• rdt2.1 remetente


34

• rdt2.1 destinatário


35

• rdt2.1 → discussão!

• Remetente:● no. de seq no pacote● bastam dois nos. de seq. (0,1). Por quê?● deve checar se ACK/NAK recebido tinha erro● duplicou o no. de estados● estado deve “lembrar” se pacote “corrente” tem no. de

seq. 0 ou 1

• Receptor:● deve checar se pacote recebido é duplicado● estado indica se no. de seq. esperado é 0 ou 1● note: receptor não tem como saber se último ACK/NAK

foi recebido bem pelo remetente


36

• rdt2.2: um protocolo sem NAKs

● mesma funcionalidade que rdt2.1, só com ACKs● ao invés de NAK, receptor envia ACK p/ último pacote

recebido bem● receptor deve incluir explicitamente no. de seq do pacote

reconhecido● ACK duplicado no remetente resulta na mesma ação que

o NAK: retransmite pacote atual


37



38

• rdt2.2 destinatário


39

• Nova suposição: canal subjacente também pode perder pacotes (dados ou ACKs)

● checksum, no. de seq., ACKs, retransmissões podem ajudar, mas não serão suficientes

● P: como lidar com perdas?

● remetente espera até ter certeza que se perdeu pacote ou ACK, e então retransmite

● desvantagens?

Transferência confiável de dados sobre um canal com perda e com erros de bits: rdt3.0

40

• Abordagem:

● remetente aguarda um tempo “razoável” pelo ACK

● retransmite se nenhum ACK for recebido neste intervalo

● se pacote (ou ACK) apenas atrasado (e não perdido):

● retransmissão será duplicada, mas uso de no. de seq. já cuida disto

● receptor deve especificar no. de seq do pacote sendo reconhecido

● requer temporizador


41



42

• Operação do rdt3.0, o protocolo bit alternado


43

• Operação do rdt3.0, o protocolo bit alternante


44

• No coração do problema do desempenho do rdt3.0 está o fato de ele ser um protocolo do tipo pare e espere.

• Um protocolo pare e espere em operação

Protocolos de transferência confiável de dados com paralelismo

45

• rdt3.0 funciona, porém seu desempenho é muito ruim• exemplo: enlace de 1 Gbps, retardo fim a fim de 15 ms,

pacote de 1KB:

• pac. de 1KB a cada 30 mseg -> vazão de 33kB/seg num enlace de 1 Gbps

• protocolo limita uso dos recursos físicos!


T transmitir =

8kb/pacote

10**9 b/seg= 8 microseg

U envio =L / R

RTT + L / R

.008

30.0080.00027 = =

46

• Envio com pare e espere


47

• Um protocolo com paralelismo em operação● remetente admite múltiplos pacotes “em trânsito”, ainda

não reconhecidos● faixa de números de sequência deve ser aumentada● buffers no remetente e/ou no receptor


48

• Envio com paralelismo: Duas formas genéricas de protocolos com paralelismo: Go-back-N, retransmissão seletiva


49

• Em um protocolo Go-Back-N (GBN), o remetente é autorizado a transmitir múltiplos pacotes sem esperar por um reconhecimento.

• Porém, fica limitado a ter não mais do que algum número máximo permitido, N, de pacotes não reconhecidos na “tubulação”.

• Visão do remetente para os números de sequência no protocolo Go-Back-N:

Go-Back-N (GBN)

50

• ACK(n): reconhece todos pacotes, até e inclusive no. de seq n - “ACK cumulativo”

• pode receber ACKs duplicados (veja receptor)• temporizador para a base da janela de transmissão• timeout(n): retransmite pacote n e todos os pacotes com no. de

seq maiores na janela

Go-Back-N (GBN)

51

• Descrição da FSM estendida do remetente GBN

Go-Back-N (GBN)

52

• Descrição da FSM estendida do destinatário GBN:● usa apenas ACK: sempre envia ACK para pacote recebido bem com o maior

no. de seq. em-ordem● pode gerar ACKs duplicados● só precisa se lembrar do expectedseqnum

● pacote fora de ordem: ● descarta (não armazena) -> receptor não usa buffers!● manda ACK de pacote com maior no. de seq em-ordem

Go-Back-N (GBN)

53

em operação

Go-Back-N (GBN)

54

• Protocolos de repetição seletiva (SR) evitam retransmissões desnecessárias.

• Eles fazem o remetente retransmitir apenas os pacotes suspeitos de terem sido recebidos com erro no destinatário.

• Essa retransmissão individual, só quando necessária, exige que o destinatário reconheça individualmente os pacotes recebidos de modo correto.

Repetição seletiva (SR)

55


56

• Remetente:● dados de cima:

● se próx. no. de seq na janela, envia pacote● timeout(n):

● reenvia pacote n, reiniciar temporizador● ACK(n) em [sendbase,sendbase+N]:

● marca pacote n “recebido”● se n for menor pacote não reconhecido, avança base da janela ao

próx. no. de seq não reconhecido

• Receptor:● pacote n em [rcvbase, rcvbase+N-1]

● envia ACK(n)● fora de ordem: buffer● em ordem: entrega (tb. entrega pacotes em ordem no buffer), avança

janela p/ próxima pacote ainda não recebido● pacote n em [rcvbase-N,rcvbase-1]

● ACK(n)● senão:

● ignora


57

Operação SR


58

• Dilema:● Exemplo:

● nos. de seq : 0, 1, 2, 3● tam. de janela =3

● receptor não vê diferença entre os dois cenários!

● incorretamente passa dados duplicados como novos em (a)

• Questão: qual a relação entre tamanho de no. de seq e tamanho de janela na repetição seletiva e no retorne a N?


59


Sumário

60

Resumo de mecanismos de transferência confiável de dados e sua utilização:

• Soma de verificação - Usada para detectar erros de bits em um pacote transmitido.

• Temporizador - Usado para controlar a temporização/retransmissão de um pacote, possivelmente porque o pacote (ou seu ACK) foi perdido dentro do canal.

• Número de sequência - Usado para numeração sequencial de pacotes de dados que transitam do remetente ao destinatário.

Transporte orientado para conexão: TCP

61

• Reconhecimento - Usado pelo destinatário para avisar o remetente que um pacote ou conjunto de pacotes foi recebido corretamente.

• Reconhecimento negativo - Usado pelo destinatário para avisar o remetente que um pacote não foi recebido corretamente (envia um reconhecimento para para o próximo byte esperado em ordem – ack duplicado).

• Janela, paralelismo - O remetente pode ficar restrito a enviar somente pacotes com números de sequência que caiam dentro de uma determinada faixa.

Transporte orientado para conexão: TCP

62

• Uma conexão TCP provê um serviço full-duplex

• A conexão TCP é sempre ponto a ponto

• Uma vez estabelecida uma conexão TCP, dois processos de aplicação podem enviar dados um para o outro● handshaking (troca de msgs de controle) inicia estado de

remetente, receptor antes de trocar dados

A conexão TCP

63

• Fluxo de bytes, ordenados, confiável:● não estruturado em msgs

• Com paralelismo (pipelined):● tam. da janela ajustado por controle de fluxo e congestionamento do

TCP● buffers de envio e recepção

• O TCP combina cada porção de dados do cliente com um cabeçalho TCP, formando, assim, segmentos TCP.

A conexão TCP

64Estrutura do segmento TCP

65

• O número de sequência para um segmento é o número do primeiro byte do segmento.

• O número de reconhecimento que o hospedeiro A atribui a seu segmento é o número de sequência do próximo byte que ele estiver aguardando do hospedeiro B.

• Como o TCP somente reconhece bytes até o primeiro byte que estiver faltando na cadeia, dizemos que o TCP provê reconhecimentos cumulativos.

Números de sequência e números de reconhecimento

66

• Pergunta: como escolher valor do temporizador TCP?• maior que o RTT

● note: RTT pode variar• muito curto: temporização prematura

● retransmissões são desnecessárias• muito longo: reação demorada à perda de segmentos

• Pergunta: como estimar RTT?• RTTamostra: tempo medido entre a transmissão do

segmento e o recebimento do ACK correspondente● ignora retransmissões

• RTT_amostra vai variar, queremos “amaciador” de RTT estimado● usa várias medições recentes, não apenas o valor

corrente (RTT_amostra)

TCP: RTT (Round Trip Time) e Temporização

67

• RTT_estimado = (1 - α)* RTT_estimado + α * RTT_amostra

• média exponencialmente ponderada• influência de cada amostra diminui exponencialmente com

o tempo• valor típico de α = 0,125


68TCP: RTT (Round Trip Time) e Temporização

69

• Escolhendo o intervalo de temporização:● RTT_estimado mais uma “margem de segurança”● grande variação no RTT_estimado -> maior margem de

segurança● primeiro estima o quanto a RTTamostra desvia do

RTT_estimado (β → 0,25):

Desvio_RTT = (1-β)* Desvio_RTT + β*|RTT_amostra - RTT_estimado|

• Então, seta o temporizador para:

Temporização = RTT_estimado + 4*Desvio_RTT


70

• O TCP cria um serviço de transferência confiável de dados sobre o serviço de melhor esforço do IP.

• O serviço de transferência garante que a cadeia de bytes é idêntica à cadeia de bytes enviada pelo sistema final que está do outro lado da conexão.

• Os procedimentos recomendados no [RFC 6298] para gerenciamento de temporizadores TCP utilizam apenas um único temporizador de retransmissão.

Transferência confiável de dados

71

• Segmentos em série (pipelined)

• Acks cumulativos

• O TCP usa um único temporizador para retransmissões

• As retransmissões são disparadas por:● estouros de temporização● acks duplicados

• Considere inicialmente um transmissor TCP simplificado:● ignora acks duplicados● ignora controles de fluxo e de congestionamento

Transferência confiável de dados

72

SeNextSeqNum = número de seqüência inicialSendBase = número de sequência inicial

repita (sempre) { switch(event)

event: dados recebidos da aplicação acima cria segmento TCP com número de sequência NextSeqNum se (temporizador estiver desligado) liga o temporizador passa segmento para IP NextSeqNum = NextSeqNum + comprimento(dados)

event: estouro do temporizador retransmite segmento ainda não reconhecido com o menor número de sequência reinicia o temporizador

event: ACK recebido, com valor de campo ACK de y se (y > SendBase) { /* ACK cumulativo de todos dados até

y */ SendBase = y se (houver segmentos ainda não reconhecidos) liga o temporizador } senão desliga o temporizador } /* fim do repita sempre */

Transmissor TCP (simplificado)

73

• Reconhecimento perdido:

TCP: Cenários de retransmissão

74

• Estouro prematuro do temporizador:


75

• Cenário de ACK cumulativo temporizador:


76TCP geração de ACKs [RFCs 1122, 2581]

Evento no Receptor Ação do Receptor TCP

chegada de segmento em ordemsem lacunas,

anteriores já reconhecidos

ACK retardado. Espera até 500msp/ próximo segmento. Se não chegarsegmento, envia ACK

chegada de segmento em ordemsem lacunas,

um ACK retardado pendente

envia imediatamente um únicoACK cumulativo

chegada de segmento fora de ordem, com no. de seq. maior

que esperado -> lacuna

envia ACK duplicado, indicando no. de seq. do próximo byte esperado

chegada de segmento que preenche a lacuna parcial oucompletamente

ACK imediato se segmento noinício da lacuna

77

• O intervalo do temporizador é frequentemente bastante longo:

● longo atraso antes de retransmitir um pacote perdido

• Detecta segmentos perdidos através de ACKs duplicados.

● O transmissor normalmente envia diversos segmentos● Se um segmento se perder, provavelmente haverá muitos

ACKs duplicados.

• Se o transmissor receber 3 ACKs para os mesmos dados, ele supõe que o segmento após os dados reconhecidos se perdeu:

● Retransmissão rápida: retransmite o segmento antes que estoure o temporizador

TCP: Retransmissão rápida

78

evento: recebido ACK, com valor do campo ACK de y if (y > SendBase) { SendBase = y if (houver segmentos ainda não reconhecidos) liga temporizador

else desliga temporizador } else { incrementa contador de ACKs duplicados recebidos para y if (contador de ACKs duplicados recebidos para y = 3) { retransmita segmento com número de sequência y } }

TCP: Retransmissão rápida

um ACK duplicado para umsegmento já reconhecido

Retransmissão rápida

79TCP: Retransmissão rápida

80

• O TCP provê um serviço de controle de fluxo às suas aplicações, para eliminar a possibilidade de o remetente estourar o buffer do destinatário.

• Controle de fluxo é um serviço de compatibilização de velocidades.

• O TCP oferece serviço de controle de fluxo fazendo que o remetente mantenha uma variável denominada janela de recepção.

• Processo da aplicação pode demorar a ler do receptor

Controle de fluxo

81

• A janela de recepção (rwnd) e o buffer de recepção (RcvBuffer)

Controle de fluxo

Tradução ruim:Espaço não utilizado

(Receive Window)

82

• O TCP no cliente estabelece uma conexão TCP com o TCP no servidor da seguinte maneira:

1. O lado cliente do TCP primeiro envia um segmento TCP especial ao lado servidor do TCP (Flag SYN em 1).

2. Assim que o datagrama IP contendo o segmento TCP SYN chega ao hospedeiro servidor, o servidor extrai o segmento TCP SYN do datagrama, aloca buffers e variáveis TCP à conexão e envia um segmento de aceitação de conexão ao TCP cliente.

Gerenciamento da conexão TCP

83

3. Ao receber o segmento SYNACK, o cliente também reserva buffers e variáveis para a conexão.

•. Completadas as três etapas, os hospedeiros cliente e servidor podem enviar segmentos contendo dados um ao outro.

•. Durante a vida de uma conexão TCP, o protocolo TCP que roda em cada hospedeiro faz transições pelos vários estados do TCP.

•. A figura a seguir ilustra uma sequência típica de estados do TCP visitados pelo TCP cliente.


84Gerenciamento da conexão TCP

85

● Encerrando uma conexão:

● cliente fecha soquete: clientSocket.close();

● Passo 1: sistema cliente envia segmento de controle FIN ao servidor

● Passo 2: servidor recebe FIN, responde com ACK. Encerra a conexão, enviando FIN.


86

• Uma sequência típica de estados do TCP visitados por um TCP cliente:


87

• Uma sequência típica de estados do TCP visitados por um TCP servidor:


88


Sumário

89

• Informalmente: “muitas fontes enviando muitos dados muito rapidamente para a rede poder tratar”

• Diferente de controle de fluxo!

• Manifestações:

● perda de pacotes (esgotamento de buffers em roteadores)

● longos atrasos (enfileiramento nos buffers dos roteadores)

• Um dos 10 problemas mais importantes em redes!

Princípios de controle de congestionamento

90

• As causas e os custos do congestionamento:

Cenário de congestionamento 1: duas conexões compartilhando um único roteador com número infinito de buffers (sem retransmissão).


91


Cenário de congestionamento 1: vazão e atraso em função da taxa de envio do hospedeiro (pode atingir a vazão total → na “boa transmissão”).


92


Cenário 2: dois hospedeiros (com retransmissões) e um roteador com buffers finitos.


93


Desempenho no cenário 2 com buffers finitos (não alcança a vazão total).


94


Cenário 3: quatro remetentes,roteadores com buffers finitos e trajetos com múltiplos roteadores.


95


Desempenho obtido no cenário 3, com buffers finitos e trajetos com múltiplos roteadores.


96

Controle de congestionamento fim a fim:

• A camada de rede não fornece nenhum suporte explícito à camada de transporte com a finalidade de controle de congestionamento.

Controle de congestionamento assistido pela rede:

• Os componentes da camada de rede (isto é, roteadores) fornecem retroalimentação específica de informações ao remetente a respeito do estado de congestionamento na rede.

Prós e Contras?

Mecanismos de controle de congestionamento

97


Sumário

98

• A abordagem adotada pelo TCP é obrigar cada remetente a limitar a taxa à qual enviam tráfego para sua conexão como uma função do congestionamento de rede percebido.

• Se um remetente TCP perceber que há pouco congestionamento no caminho entre ele e o destinatário, aumentará sua taxa de envio.

• Se perceber que há congestionamento, reduzirá sua taxa de envio.

Controle de congestionamento no TCP

99

• Mas essa abordagem levanta três questões:

1. Como um remetente TCP limita a taxa pela qual envia tráfego para sua conexão?

2. Como um remetente TCP percebe que há congestionamento entre ele e o destinatário?

3. Que algoritmo o remetente deve utilizar para modificar sua taxa de envio como uma função do congestionamento fim a fim percebido?


100

• Controle fim-a-fim (sem assistência da rede)• Transmissor limita a transmissão:

LastByteSent - LastByteAcked ≤ CongWin• Praticamente,

Taxa ≈ CongWin/RTT bytes/segundo

• CongWin é dinâmica, em função do congestionamento percebido da rede

• Como o transmissor percebe o congestionamento?● evento de perda = estouro do temporizador ou 3 acks

duplicados ● transmissor TCP reduz a taxa (CongWin) após evento de perda

• Três mecanismos:● AIMD● partida lenta● conservador após eventos de estouro de temporização


101

• No início da conexão, CongWin = 1 MSS

• Exemplo:

● MSS = 500 bytes & RTT = 200 mseg● taxa inicial = 20 kbps

• Largura de banda disponível pode ser >> MSS/RTT

● é desejável um crescimento rápido até uma taxa considerável

• No início da conexão, aumenta a taxa exponencialmente até o primeiro evento de perda

Partida lenta

102

• Partida lenta TCP• “Descobrindo a banda

disponível”• Força uma perda → a

banda não é infinita!

Partida lenta

103

• Após 3 ACKs duplicados:● corta CongWin pela metade● a janela depois cresce linearmente

• Mas após estouro de temporizador:● CongWin é reduzida a 1 MSS● janela cresce exponencialmente ● até um limiar, depois cresce linearmente

• Filosofia:● 3 ACKs duplicados indica que a rede é capaz de entregar

alguns segmentos ● estouro de temporizador antes de 3 ACKs duplicados é

mais “alarmante”.

Eventos de perda de pacote

104

• Evolução da janela de congestionamento do TCP (Tahoe e Reno)● P: Quando o crescimento exponencial deve mudar para

linear?● R: Quando CongWin atinge 1/2 do seu valor antes do

estouro do temporizador.

Eventos de perda de pacote

● Implementação:

● Limiar (Threshold) variável

● Com uma perda o limiar passa a ser 1/2 da CongWin imediatamente anterior à perda.

Recuperação Rápida

105

• Descrição FSM do controle de congestionamento no TCP

Prevenção de congestionamento

106

• O controle de congestionamento AIMD faz surgir o comportamento semelhante a “dentes de serra”:

Controle de congestionamento no TCP: retrospectiva

107

• Qual é a vazão média do TCP em função do tamanho da janela e do RTT?● Ignore a partida lenta

• Seja W o tamanho da janela quando ocorre a perda

• Quando a janela é W a vazão é W/RTT

• Imediatamente após a perda, janela cai a W/2, vazão cai para W/2RTT.

• Vazão média = 0,75 W/RTT

TCP: Vazão

108

• Duas conexões TCP compartilhando um único enlace congestionado

• Meta de equidade: se K sessões TCP compartilham o mesmo enlace de gargalo com largura de banda R, cada uma deve obter uma taxa média de R/K

Equidade

109

• Vazão alcançada pelas conexões TCP 1 e TCP 2• Duas sessões concorrentes:

● Aumento aditivo dá gradiente de 1, enquanto vazão aumenta

● decremento multiplicativo diminui vazão proporcionalmente

Equidade

perda: diminui janela por fator de 2evitar congestionamento: aumento aditivo

110

Capítulo 3 - FIM

Documents

Capítulo 3 Camada de transporte - ic.uff.brlsousa/redes_i/cap-3.pdf · 4 3.1 – Introdução e serviços da camada de transporte 3.2 – Multiplexação e Demultiplexação 3.3