3: Camada de Transporte 1
Camada de Transporte
transparências baseadas no livro“Computer Networking: A Top-Down Approach Featuring the Internet”
James Kurose e Keith Rosshttp://occawlonline.pearsoned.com/bookbind/pubbooks/kurose-ross1/
3: Camada de Transporte 2
Metas do capítulo:• compreender os
princípios atrás dos serviços da camada de transporte:
o multiplexação/demultiplexação
o transferência confiável de dados
o controle de fluxoo controle de
congestionamento • instanciação e
implementação na Internet
Resumo do Capítulo:• serviços da camada de transporte• multiplexação/demultiplexação• transporte sem conexão: UDP• princípios de transferência confiável
de dados• transporte orientado a conexão: TCP
o transferência confiávelo controle de fluxoo gerenciamento de conexões
• princípios de controle de congestionamento
• controle de congestionamento em TCP
Parte III: Camada de Transporte
3: Camada de Transporte 3
Serviços e protocolos de transporte
• provê comunicação lógica entre processos de aplicação executando em hospedeiros diferentes
• protocolos de transporte executam em sistemas terminais
• serviços das camadas de transporte X rede:
• camada de rede : dados transferidos entre sistemas
• camada de transporte: dados transferidos entre processos
o depende de, estende serviços da camada de rede
aplicaçãotransporte
redeenlacefísica
redeenlacefísica
aplicaçãotransporte
redeenlacefísica
redeenlacefísica
redeenlacefísica
redeenlacefísica
redeenlacefísica
transporte lógico fima fim
3: Camada de Transporte 4
Protocolos da camada de transporte
Serviços de transporte na Internet:
• entrega confiável, ordenada, ponto a ponto (TCP)
o congestionamentoo controle de fluxoo estabelecimento de conexão
(“setup”)• entrega não confiável,
(“melhor esforço”), não ordenada, ponto a ponto ou multiponto: UDP
• serviços não disponíveis: o tempo realo garantias de bandao multiponto confiável
aplicaçãotransporte
redeenlacefísica
redeenlacefísica
aplicaçãotransporte
redeenlacefísica
redeenlacefísica
redeenlacefísica
redeenlacefísica
redeenlacefísica
transporte lógico fima fim
3: Camada de Transporte 5
aplicaçãotransporte
rede
M P2aplicação
transporterede
Multiplexação/demultiplexaçãoLembrança: segmento -
unidade de dados trocada entre entidades da camada de transporte
o = TPDU: transport protocol data unit
receptor
HtHn
Demultiplexação: entrega de segmentos recebidos para os processos da camada de apl corretos
segmento
segmento Maplicação
transporterede
P1M
M MP3 P4
cabeçalhode segmento
dados da camadade aplicação
3: Camada de Transporte 6
Multiplexação/demultiplexação
multiplexação/demultiplexação:• baseadas em números de porta e
endereços IP do remetente e do receptor
o números de porta do remetente/receptor em cada segmento
o lembrete: número de porta bem conhecido para aplicações específicas
juntar dados de múltiplosprocessos de apl, envelopandodados com cabeçalho (usado depois para demultiplexação)
porta remetente porta receptor
32 bits
dados daaplicação
(mensagem)
outros campos do cabeçalho
formato de segmento TCP/UDP
Multiplexação:
3: Camada de Transporte 7
Multiplexação/demultiplexação: exemplos
estaçãoA
servidor B
porta orig.: xporta dest: 23
porta orig:23porta dest: x
uso de portas: apl. simples de telnet
cliente WWWestação 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
3: Camada de Transporte 8
UDP: User Datagram Protocol [RFC 768]
• Protocolo de transporte da Internet mínimo, “sem frescura”,
• Serviço “melhor esforço”, segmentos UDP podem ser:
o perdidoso entregues à aplicação fora
de ordem do remesso• sem conexão:
o não há “setup” UDP entre remetente, receptor
o tratamento independente de cada segmento UDP
Por quê existe um UDP?• 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
3: Camada de Transporte 9
Mais sobre UDP• muito utilizado para apls. de
meios contínuos (voz, vídeo)o tolerantes de perdaso sensíveis à taxa de
transmissão• outros usos de UDP (por
quê?):o DNS (nomes)o SNMP (gerenciamento)
• transferência confiável com UDP: incluir confiabilidade na camada de aplicação
o recuperação de erro específica à apl.!
porta origem porta dest.
32 bits
Dados de aplicação
(mensagem)
Formato do segmento UDP
comprimento checksum
Comprimento embytes do
segmento UDP,incluindo cabeçalho
3: Camada de Transporte 10
Checksum UDP
Remetente:• trata conteúdo do
segmento como seqüência de inteiros de 16-bits
• campo checksum zerado• checksum: soma (adição
usando complemento a 1) do conteúdo do segmento
• remetente coloca complemento do valor da soma no campo checksumde UDP
Receptor:• calcula checksum do
segmento recebido• verifica se checksum
computado é zero:o NÃO - erro detectadoo SIM - nenhum erro
detectado. Mas ainda pode ter erros? Veja depois ….
Meta: detectar “erro” (e.g., bits invertidos) no segmento transmitido
3: Camada de Transporte 11
Checksum do UDP
• Pode ser redundante pois muitos protocolos de enlace já o fazem;
• Contudo, Camada de Transporte deve funcionar independente da tecnologia de enlace
• Apesar de detectar erro, UDP nada faz para corrigir (algumas implementações simplesmente descartam o segmento)
3: Camada de Transporte 12
Princípios de Transferência confiável de dados (rdt)
• importante nas camadas de transporte, enlace• na lista dos 10 tópicos mais importantes em redes!
• características do canal não confiável determinam a complexidadede um protocolo de transferência confiável de dados (rdt)
3: Camada de Transporte 13
Transferência confiável de dados (rdt): como começar
sendside
receiveside
rdt_send(): chamada de cima, (p.ex.,pela apl.). Dados recebidos p/entregar à camada sup. do receptor
udt_send(): chamada porrdt, p/ transferir pacote pelocanal ñ confiável ao receptor
rdt_rcv(): chamada quandopacote chega no lado receptor do
canal
deliver_data(): chamada por rdt p/ entregar dados
p/ camada superior
3: Camada de Transporte 14
Transferência confiável de dados (rdt): como começarIremos:• desenvolver incrementalmente os lados
remetente, receptor do protocolo RDT• considerar apenas fluxo unidirecional de dados
o mas info de controle flui em ambos os sentidos!• Usar máquinas de estados finitos (FSM) p/
especificar remetente, receptor
estado1
estado2
evento causador da transição de estadoações executadas ao mudar de estado
estado: neste “estado” o próximo estado é
determinado unicamente pelo próximo evento
eventoações
3: Camada de Transporte 15
Rdt1.0: transferência confiável usando um canal confiável
• canal subjacente perfeitamente confiávelo não tem erros de bitso não tem perda de pacotes
• FSM (máq est) separadas p/ remetente e receptor:o remetente envia dados pelo canal subjacenteo receptor recebe dados do canal subjacente
3: Camada de Transporte 16
Rdt2.0: canal com erros de bits• canal subjacente pode inverter bits no pacote
o lembre-se: checksum UDP pode detectar erros de bits• a questão: como recuperar dos erros?
o reconhecimentos (ACKs): receptor avisa explicitamente ao remetente que pacote chegou bem
o reconhecimentos negativos (NAKs): receptor avisa explicitamente ao remetente que pacote tinha erros
o remetente retransmite pacote ao receber um NAKo cenários humanos usando ACKs, NAKs?
• novos mecanismos em rdt2.0 (em relação ao rdt1.0):o detecção de erroso realimentação pelo receptor: msgs de controle (ACK,NAK)
receptor->remetente
3: Camada de Transporte 20
rdt2.0 tem uma falha fatal!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
seqüê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
pára e espera
3: Camada de Transporte 23
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
o estado deve “lembrar” se pacote “corrente” tem no. de seq. 0 ou 1
Receptor:• deve checar se pacote
recebido é duplicadoo 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
3: Camada de Transporte 24
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
o receptor deve incluir explicitamente no. de seqdo pacote reconhecido
• ACK duplicado no remetente resulta na mesma ação que o NAK: retransmite pacote atual
FSM doremetente
!
3: Camada de Transporte 25
rdt3.0: canais com erros e perdas
Nova suposição: canal subjacente também pode perder pacotes (dados ou ACKs)
o checksum, no. de seq., ACKs, retransmissões podem ajudar, mas não serão suficientes
P: como lidar com perdas?o remetente espera até ter
certeza que se perdeu pacote ou ACK, e então retransmite
o eca!: desvantagens?
Abordagem: remetente aguarda um tempo “razoável” pelo ACK
• retransmite e nenhum ACK recebido neste intervalo
• se pacote (ou ACK) apenas atrasado (e não perdido):
o retransmissão será duplicada, mas uso de no. de seq. já cuida disto
o receptor deve especificar no. de seq do pacote sendo reconhecido
• requer temporizador
3: Camada de Transporte 29
Desempenho de rdt3.0
• rdt3.0 funciona, porém seu desempenho é muito ruim• exemplo: enlace de 1 Gbps, retardo fim a fim de 15 ms, pacote de
1KB:
Ttransmitir=8kb/pacote10**9 b/seg = 8 microseg
Utilização = U = = 8 microseg30.016 mseg
fração do temporemetente ocupado = 0,00015
o pac. de 1KB a cada 30 mseg -> vazão de 33kB/seg num enlace de 1 Gbps
o protocolo limita uso dos recursos físicos!
3: Camada de Transporte 30
Protocolos “dutados” (pipelined)Dutagem (pipelining): remetente admite múltiplos
pacotes “em trânsito”, ainda não reconhecidoso faixa de números de seqüência deve ser aumentadao buffers no remetente e/ou no receptor
• Duas formas genéricas de protocolos dutados: volta-N, retransmissão seletiva
3: Camada de Transporte 31
Volta-NRemetente:• no. de seq. de k-bits no cabeçalho do pacote• admite “janela” de até N pacotes consecutivos não reconhecidos
• ACK(n): reconhece todos pacotes, até e inclusive no. de seq n -“ACK cumulativo”
o pode receber ACKs duplicados (veja receptor)• temporizador para todos pacotes em trânsito• timeout(n): retransmite pacote n e todos os pacotes com no. de
seq maiores na janela
3: Camada de Transporte 32
Obs.
• Protocolo de janelas deslizantes(sliding-window protocol)
• Mais simples: emissor com apenas um temporizador
3: Camada de Transporte 34
Volta-N: receptor
receptor simples:• usa apenas ACK: sempre envia ACK para pacote
recebido bem com o maior no. de seq. em-ordemo pode gerar ACKs duplicadoso só precisa se lembrar do expectedseqnum
• pacote fora de ordem: o descarta (não armazena) -> receptor não usa buffers!o manda ACK de pacote com maior no. de seq em-ordem
expectedseqnum=expectedseqnum+1
3: Camada de Transporte 36
Retransmissão seletiva
• receptor reconhece individualmente todos os pacotes recebidos corretamente
o armazena pacotes no buffer, conforme precisa, para posterior entrega em-ordem à camada superior
• remetente apenas re-envia pacotes para os quais ACK não recebido
o temporizador de remetente para cada pacote sem ACK• janela do remetente
o N nos. de seq consecutivos o outra vez limita nos. de seq de pacotes enviados, mas
ainda não reconhecidos
3: Camada de Transporte 38
Retransmissão seletiva
dados de cima:• se próx. no. de seq na
janela, envia pacotetimeout(n):• reenvia pacote n, reiniciar
temporizadorACK(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
pacote n em [rcvbase, rcvbase+N-1]
• envia ACK(n)• fora de ordem: bufferiza• 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
receptorremetente
3: Camada de Transporte 39
Retransmissão seletiva em ação
Figura com erro: o temporizadordo pkt1 teria estourado antes!
3: Camada de Transporte 40
Retransmissão seletiva: dilemaExemplo: • 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)
Q: qual a relação entre tamanho de no. de seq e tamanho de janela?
R. Tam. Jan. <= ½ no seq.
3: Camada de Transporte 41
TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581
• transmissão full duplex:o fluxo de dados bi-
direcional na mesma conexão
o MSS: tamanho máximo de segmento
• orientado a conexão:o handshaking (troca de
msgs de controle) inicia estado de remetente, receptor antes de trocar dados
• fluxo controlado:o receptor não será afogado
• ponto a ponto:o 1 remetente, 1 receptor
• fluxo de bytes, ordenados, confiável:
o não estruturado em msgs• dutado:
o tam. da janela ajustado por controle de fluxo e congestionamento do TCP
• buffers de envio e recepçãosocketdoor
TCPsend buffer
TCPreceive buffer
socketdoor
segment
applicationwrites data
applicationreads data
3: Camada de Transporte 42
TCP: estrutura do segmento
no. porta origem no. porta dest
32 bits
dados daaplicação
(tam. variável)
número de seqüêncianúmero de reconhecimento
janela receptorptr dados urg.checksum
FSRPAUtam.cab.
semuso
Opções (tam. variável)
URG: dados urgentes (pouco usados)
ACK: no. ACKválido
PSH: envia dados já(pouco usado)
RST, SYN, FIN:gestão de conexão
(comandos deestabelecimento,
liberação)
no. bytes rcpt queraceitar
contagem de dadospor bytes (não segmentos!)
checksum Internet
(como UDP)
3: Camada de Transporte 43
TCP: nos. de seq. e ACKsNos. de seq.:
o “número”dentro do fluxo de bytes do primeiro byte de dados do segmento
ACKs:o no. de seq do próx.
byte esperado do outro lado
o ACK cumulativoP: como receptor trata
segmentos fora da ordem?
o R: espec do TCP omissa - deixado ao implementador
Estação A Estação B
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
Usuáriotecla
‘C’
A reconhecechegada
do ‘C’ecoado
B reconhecechegada de
‘C’, ecoa‘C’ de volta
tempocenário simples de telnet
3: Camada de Transporte 44
TCP: transferência confiável de dados
remetente simplificado, supondo:
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
•fluxo de dados uni-direcional•sem controle de fluxo, congestionamento
3: Camada de Transporte 45
TCP: transfe-rênciaconfiável de dados
00 sendbase = número de seqüência inicial01 nextseqnum = número de seqüência inicial0203 loop (forever) {04 switch(event)05 event: dados recebidos da aplicação acima06 cria segmento TCP com número de seqüência nextseqnum 07 inicia temporizador para segmento nextseqnum 08 passa segmento para IP 09 nextseqnum = nextseqnum + comprimento(dados) 10 event: expirado temporizador de segmento c/ no. de seqüência y 11 retransmite segmento com número de seqüência y 12 calcula novo intervalo de temporização para segmento y 13 reinicia temporizador para número de seqüência y 14 event: ACK recebido, com valor de campo ACK de y 15 se (y > sendbase) { /* ACK cumulativo de todos dados até y */ 16 cancela temporizadores p/ segmentos c/ nos. de seqüência < y 17 sendbase = y 18 } 19 senão { /* é ACK duplicado para segmento já reconhecido */ 20 incrementa número de ACKs duplicados recebidos para y 21 if (número de ACKs duplicados recebidos para y == 3) { 22 /* TCP: retransmissão rápida */ 23 reenvia segmento com número de seqüência y 24 reinicia temporizador para número de seqüência y 25 } 26 } /* fim de loop forever */
RemetenteTCPsimplificado
3: Camada de Transporte 46
TCP geração de ACKs [RFCs 1122, 2581]
Evento
chegada de segmento em ordemsem lacunas,anteriores já reconhecidos
chegada de segmento em ordemsem lacunas,um ACK retardado pendente
chegada de segmento fora de ordem, com no. de seq. maiorque esperado -> lacuna
chegada de segmento que preenche a lacuna parcial oucompletamente
Ação do receptor TCP
ACK retardado. Espera até 500msp/ próx. segmento. Se não chegarsegmento, envia ACK
envia imediatamente um únicoACK cumulativo
envia ACK duplicado, indicando no. de seq.do próximo byte esperado
ACK imediato se segmento noinício da lacuna
3: Camada de Transporte 47
TCP: cenários de retransmissãoEstação A
Seq=92, 8 bytes de dados
ACK=100
perdatem
pori
zaçã
o
tempo cenário doACK perdido
Estação B
XSeq=92, 8 bytes de dados
ACK=100
Host A
Seq=100, 20 bytes de dados
ACK=100
Tem
p.p/
Seq=
92temporização prematura,
ACKs cumulativos
Host B
Seq=92, 8 bytes de dados
ACK=120
Seq=92, 8 bytes de dados
Tem
p. p
/Se
q=10
0
ACK=120
tempo
3: Camada de Transporte 48
remetente não esgotaria buffers do receptor por
transmitir muito, oumuito rápidamente
controle de fluxo
TCP: Controle de Fluxoreceptor: explicitamente
avisa o remetente da quantidade de espaço livre disponível (muda dinamicamente)
o campo RcvWindowno segmento TCP
remetente: mantém a quantidade de dados transmitidos, porém ainda não reconhecidos, menor que o valor mais recente de RcvWindow
buffering pelo receptor
RcvBuffer = tamanho do Buffer de recepção
RcvWindow = espaço vazio no Buffer
3: Camada de Transporte 49
TCP: Tempo de Resposta (RTT) e TemporizaçãoP: como escolher valor
do temporizadorTCP?
• maior que o RTTo note: RTT pode
variar• muito curto:
temporização prematurao retransmissões são
desnecessárias• muito longo: reação
demorada à perda de segmentos
P: como estimar RTT?• RTTamostra: tempo medido
entre a transmissão do segmento e o recebimento do ACK correspondente
o ignora retransmissões, segmentos com ACKscumulativos
• RTTamostra vai variar, queremos “amaciador” de RTT estimado
o usa várias medições recentes, não apenas o valor corrente (RTTamostra)
3: Camada de Transporte 50
TCP: Tempo de Resposta (RTT) e TemporizaçãoRTT_estimado = (1-x)* RTT_estimado + x*RTT_amostra
• média corrente exponencialmente ponderada• influência de cada amostra diminui exponencialmente
com o tempo• valor típico de x: 0.1
x = 1/8
3: Camada de Transporte 51
TCP: Tempo de Resposta (RTT) e Temporização
Escolhendo o intervalo de temporização• RTT_estimado mais uma “margem de segurança”• variação grande em RTT_estimado
-> margem de segurança maiorTemporização = RTT_estimado + 4*Desvio
Desvio = (1-x)* Desvio +x*|RTT_amostra - RTT_estimado|
3: Camada de Transporte 52
TCP: Gerenciamento de Conexões
Lembrete: Remetente, receptor TCP estabelecem “conexão” antes de trocar segmentos de dados
• inicializam variáveis TCP:o nos. de seq.o buffers, info s/ controle
de fluxo (p.ex. RcvWindow)• cliente: iniciador de conexão
Socket clientSocket = new Socket("hostname","port
number");
• servidor: contactado por clienteSocket connectionSocket = welcomeSocket.accept();
Inicialização em 3 tempos:
Passo 1: sistema cliente envia segmento de controle SYN do TCP ao servidor
o especifica no. inicial de seq
Passo 2: sistema servidor recebe SYN, responde com segmento de controle SYNACK
o reconhece SYN recebidoo aloca bufferso especifica no. inicial de seq. servidor->
receptor
Passo 3: sistema cliente recebe SYNACK, e envia ACK para o servidor (controle SYN desligado pois conexão já foi estabelecida)
3: Camada de Transporte 53
TCP: Gerenciamento de Conexões (cont.)
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.
cliente
FIN
servidor
ACK
ACK
FIN
fechar
fechar
fechada
espe
ra
tem
pori
zada
3: Camada de Transporte 54
TCP: Gerenciamento de Conexões (cont.)
Passo 3: cliente recebe FIN, responde com ACK.
o Entre em “espera temporizada” -responderá com ACK a FINs recebidos
Passo 4: servidor, recebe ACK. Conexão encerrada.
cliente
FIN
servidor
ACK
ACK
FIN
fechando
fechando
fechada
espe
rate
mpo
riza
da
fechada
3: Camada de Transporte 55
TCP: Gerenciamento de Conexões (cont)
Ciclo de vidade cliente TCP
Ciclo de vidade servidor TCP
3: Camada de Transporte 56
Princípios de Controle de CongestionamentoCongestionamento:• informalmente: “muitas fontes enviando muitos
dados muito rapidamente para a rede poder tratar”
• diferente de controle de fluxo!• manifestações:
o perda de pacotes (esgotamento de buffers em roteadores)
o longos atrasos (enfileiramento nos buffers dos roteadores)
• um dos 10 problemas mais importantes em redes!
3: Camada de Transporte 57
Causas/custos de congestionamento:• Mesmo se roteadores com fila infinita:• grandes retardos qdo. congestionada• vazão máxima do enlace alcançável
• Um roteador, buffers finitos• Retransmissões desnecessárias pelo remetente de pacote atrasados
• Emissores “mágicos” que só retransmitem qdo pacotes perdidos?
• Um roteador, buffers finitos• retransmissão pelo remetente de pacote perdido
Outro “custo” de congestionamento:• quando pacote é descartado, qq. capacidade de transmissão já
usada (antes do descarte) para esse pacote foi desperdiçada!
3: Camada de Transporte 58
Causas/custos de congestionamento: cenário 1
• dois remetentes, dois receptores
• um roteador, buffers infinitos
• sem retransmissão
• grandes retardos qdo. congestionada
• vazão máxima alcançável
3: Camada de Transporte 59
Causas/custos de congestionamento: cenário 2
• Um roteador, buffers finitos• retransmissão pelo remetente de pacote
perdido
3: Camada de Transporte 60
Causas/custos de congestionamento: cenário 2• sempre: (“goodput”)• retransmissão “perfeito” apenas quando perda:
• retransmissão de pacote atrasado (não perdido) faz maior(que o caso perfeito) para o mesmo
λin
λout=
λin
λout>λ
inλout
“custos” de congestionamento:• mais trabalho (retransmissão) para dado “goodput”• retransmissões desnecessárias: enviadas múltiplas cópias do pacote
3: Camada de Transporte 61
Causas/custos de congestionamento: cenário 3• quatro remetentes• caminhos com múltiplos enlaces• temporização/retransmissão
λin
Q: what happens as and increase ?λ
in
3: Camada de Transporte 62
Causas/custos de congestionamento: cenário 3
Outro “custo” de congestionamento:• quando pacote descartado, qq. capacidade de
transmissão já usada (antes do descarte) para essepacote foi desperdiçado!
3: Camada de Transporte 63
Abordagens de controle de congestionamento
Controle de congestionamento fim a fim :
• não tem realimentação explícita pela rede
• congestionamento inferido das perdas, retardo observados pelo sistema terminal
• abordagem usada pelo TCP
Controle de congestionamento com apoio da rede:
• roteadores realimentam os sistemas terminais
o bit único indicando congestionamento (SNA, DECbit, ATM)
o taxa explícita p/ envio pelo remetente
Duas abordagens amplas para controle de congestionamento:
3: Camada de Transporte 64
Estudo de caso: controle de congestionamento no ABR da ATM
ABR: available bit rate:• “serviço elástico” • se caminho do remetente
“sub-carregado”: o remetente deveria
usar banda disponível• se caminho do remetente
congestionado: o remetente reduzido à
taxa mínima garantida
células RM (resource management):
• enviadas pelo remetente, intercaladas com células de dados
• bits na célula RM iniciados por comutadores (“apoio da rede”)
o bit NI: não aumente a taxa (congestionamento moderado)
o bit CI: indicação de congestionamento
3: Camada de Transporte 65
Estudo de caso: controle de congestionamento em ABR da ATM
• Campo ER (explicit rate) de 2 bytes na célula RMo comutador congestionado pode diminuir valor ER na célulao taxa do remetente assim ajustada p/ menor valor possível entre os
comutadores do caminho• bit EFCI em células de dados ligado por comutador congestionado
o se EFCI ligado na célula de dados antes da célula RM, receptor liga bit CI na célula RM devolvida
3: Camada de Transporte 66
TCP: Controle de Congestionamento• controle fim a fim (sem apoio da rede)• taxa de transmissão limitada pela tamanho da janela de
congestionamento, Congwin:
• w segmentos, cada um c/ MSS bytes, enviados por RTT:
Vazão (throughput) = w * MSSRTT Bytes/sec
Congwin
3: Camada de Transporte 67
TCP: Controle de Congestionamento
• duas “fases”o partida lentao evitar
congestionamento• variáveis importantes:
o Congwin
o threshold: define limiar entre fases de partida lenta, controle de congestionamento
• “sondagem” para banda utilizável:
o idealmente: transmitir o mais rápido possível (Congwin o máximo possível) sem perder pacotes
o aumentar Congwin até perder pacotes (congestionamento)
o perdas: diminui Congwin, depois volta a à sondagem (aumento) novamente
3: Camada de Transporte 68
TCP: Partida lenta
• aumento exponencial (por RTT) no tamanho da janela (não muito lenta!)
• evento de perda: temporizador
inicializa: Congwin = 1for (cada segmento c/ ACK)
Congwin++until (evento de perda OR
CongWin > threshold)
Estação A
um segmento
RTT
Estação B
tempo
dois segmentos
quqtro segmentos
Algoritmo Partida Lenta
3: Camada de Transporte 69
TCP: Evitar Congestionamento
/* partida lenta acabou */ /* Congwin > threshold */Until (event de perda) {cada w segmentos
reconhecidos:Congwin++
}threshold = Congwin/2Congwin = 1faça partida lenta
1
Evitar congestionamento
3: Camada de Transporte 70
Justiça do TCPMeta: se N sessões TCP
compartilham o mesmo enlace de gargalo, cada uma deve ganhar 1/N da capacidade do enlace
TCP evitando congestionamento:
• AADM: aumento aditivo, decremento multiplicativo
o aumenta janela em 1 por cada RTT
o diminui janela por fator de 2 num evento de perda
AADM (AIMD)
TCP conexão 1
Roteadorgargalo
capacidade R
TCP conexão 2
3: Camada de Transporte 71
Por quê TCP é justo?Duas sessões concorrentes:• Aumento aditivo dá gradiente de 1, enquanto vazão aumenta• decrementa multiplicativa diminui vazão proporcionalmente
R
R
compartilhamento igual da banda
Vazão da conexão 1
Vazã
oda
cone
xão
2
evitar congestionamento: aumento aditivoperda: diminui janela por fator de 2
evitar congestionamento: aumento aditivoperda: diminui janela por fator de 2
3: Camada de Transporte 72
TCP: modelagem de latência
P: Quanto tempo custa para receber um objeto de um servidor WWW depois de enviar o pedido?
• Estabelecimento de conexão TCP
• retardo de transferência de dados
Notação, suposições:• Supomos um enlace entre cliente e
servidor de taxa R• Supomos: janela de
congestionamento fixo, W segmentos
• S: MSS (bits)• O: tamanho do objeto (bits)• sem retransmissões (sem perdas,
sem erros)Dois casos a considerar:• WS/R > RTT + S/R: ACK do primeiro segmento na janela
chega antes de enviar todos dados na janela• WS/R < RTT + S/R: aguarda ACK depois de enviar todos
os dados na janela
3: Camada de Transporte 73
TCP: modelagem de latência
Caso 1: latência = 2RTT + O/R Caso 2: latência = 2RTT + O/R+ (K-1)[S/R + RTT - WS/R]
K:= O/WS
3: Camada de Transporte 74
TCP: modelagem de latência: partida lenta• Agora supomos que a janela cresce à la partida lenta.• Mostramos que a latência de um objeto de tamanho O é:
RS
RSRTTP
RORTTLatency P )12(2 −−
+++=
onde P é o número de vezes TCP para no servidor:
}1,{min −= KQP
- onde Q é o número de vezes que o servidor parariase o objeto for de tamanho infinito.
- e K é o número de janelas que cobrem o objeto.
3: Camada de Transporte 75
TCP: modelagem de latência: partida lenta (cont.)
RTT
initiate TCPconnection
requestobject
first window= S/R
second window= 2S/R
third window= 4S/R
fourth window= 8S/R
completetransmissionobject
delivered
time atclient
time atserver
Exemplo:
O/S = 15 segmentos
K = 4 janelas
Q = 2
P = mín{K-1,Q} = 2
Servidor para P=2 vezes.
3: Camada de Transporte 76
TCP: modelagem de latência: partida lenta (cont.)
RS
RSRTTPRTT
RO
RSRTT
RSRTT
RO
stallTimeRTTRO
P
kP
k
P
pp
)12(][2
]2[2
2latency
1
1
1
−−+++=
−+++=
++=
−
=
=
∑
∑
windowth after the timestall 2 1 kRSRTT
RS k =
−+
+−
ementacknowledg receivesserver until
segment send tostartsserver whenfrom time=+ RTTRS
window kth the transmit totime2 1 =−
RSk
RTT
initiate TCPconnection
requestobject
first window= S/R
second window= 2S/R
third window= 4S/R
fourth window= 8S/R
completetransmissionobject
delivered
time atclient
time atserver
3: Camada de Transporte 77
Capítulo 3: Sumário
• Princípios atrás dos serviços da camada de transporte:
o multiplexação/desmultiplexação
o transferência confiável de dadoso controle de fluxoo controle de congestionamento
• instanciação e implementação na Internet
o UDPo TCP
Próximo capítulo:• saímos da “borda” da
rede (camadas de aplicação e transporte)
• entramos no “núcleo”da rede