Protocolos de Redes

Prévia do material em texto

3: Camada de Transporte 3-1
Capítulo 3: Camada de Transporte
Metas do capítulo:
r compreender os
princípios atrás dos
serviços da camada de
transporte:
m multiplexação/
desmultiplexação
m transferência confiável
de dados
m controle de fluxo
m controle de
congestionamento
r instanciação e
implementação na
Internet
Sumário do Capítulo:
r serviços da camada de transporte
r multiplexação/desmultiplexação
r transporte sem conexão: UDP
r princípios de transferência confiável
de dados
r transporte orientado a conexão: TCP
m transferência confiável
m controle de fluxo
m gerenciamento de conexões
r principles de controle de
congestionamento
r controle de congestionamento em TCP
3: Camada de Transporte 3-2
Serviços e protocolos de transporte
r provê comunicação lógica
entre processos de aplicação
executando em hospedeiros
diferentes
r protocolos de transporte
executam em sistemas
terminais
r serviços das camadas de
transporte X rede:
r camada de rede : dados
transferidos entre sistemas
r camada de transporte: dados
transferidos entre processos
m depende de, estende serviços
da camada de rede
aplicação
transporte
rede
enlace
física
rede
enlace
física
aplicação
transporte
rede
enlace
física
rede
enlace
física
rede
enlace
física
rede
enlace
física
rede
enlace
física
transporte lógico fim a fim
3: Camada de Transporte 3-3
Protocolos da camada de transporte
Serviços de transporte na
Internet:
r entrega confiável, ordenada,
ponto a ponto (TCP)
m congestionamento
m controle de fluxo
m estabelecimento de conexão
(setup)
r entrega não confiável,
(“melhor esforço”), não
ordenada, ponto a ponto ou
multiponto: UDP
r serviços não disponíveis:
m tempo-real
m garantias de banda
m multiponto confiável
aplicação
transporte
rede
enlace
física
rede
enlace
física
aplicação
transporte
rede
enlace
física
rede
enlace
física
rede
enlace
física
rede
enlace
física
rede
enlace
física
transporte lógico fim a fim
3: Camada de Transporte 3-4
aplicação
transporte
rede
M P2
aplicação
transporte
rede
Multiplexação/desmultiplexação
Lembrança: segmento -
unidade de dados trocada
entre entidades da camada
de transporte
m = TPDU: transport
protocol data unit
receptor
Ht
Hn
Desmultiplexação: entrega de 
segmentos recebidos para os 
processos da camada de apl 
corretos
segmento
segmento M
aplicação
transporte
rede
P1
M
M M
P3 P4
cabeçalho
de segmento
dados da camada
de aplicação
3: Camada de Transporte 3-5
Multiplexação/desmultiplexação
multiplexação/desmultiplexação:
r baseadas em números de porta
e endereços IP de remetente e
receptor
m números de porta de
remetente/receptor em
cada segmento
m lembrete: número de porta
bem conhecido para
aplicações específicas
juntar dados de múltiplos
processos de apl, envelopando
dados com cabeçalho (usado 
depois para desmultiplexação)
porta remetente porta receptor
32 bits
dados da
aplicação
(mensagem)
outros campos 
do cabeçalho
formato de segmento 
TCP/UDP
Multiplexação:
3: Camada de Transporte 3-6
Multiplexação/desmultiplexação: exemplos
estação
 A
servidor 
B
porta orig.: x
porta dest: 23
porta orig:23
porta dest: x
uso de portas: 
apl. simples de telnet
cliente WWW
estação A
servidor 
WWW B
IP orig: C
IP dest: B
porta orig: x
porta dest: 80
IP orig : C
IP dest: B
porta orig: y
porta dest: 80
uso de portas : 
servidor WWW
IP orig: A
IP dest: B
porta orig: x
porta dest: 80
3: Camada de Transporte 3-7
UDP: User Datagram Protocol [RFC 768]
r Protocolo de transporte da
Internet mínimo, “sem
frescura”,
r Serviço “melhor esforço”,
segmentos UDP podem ser:
m perdidos
m entregues à aplicação fora
de ordem do remesso
r sem conexão:
m não há “setup” UDP entre
remetente, receptor
m tratamento independente
de cada segmento UDP
Por quê existe um UDP?
r elimina estabelecimento de
conexão (o que pode causar
retardo)
r simples: não se mantém
“estado” da conexão no
remetente/receptor
r pequeno cabeçalho de
segmento
r sem controle de
congestionamento: UDP
pode transmitir o mais
rápido possível
3: Camada de Transporte 3-8
Mais sobre UDP
r muito utilizado para apls. de
meios contínuos (voz, vídeo)
m tolerantes de perdas
m sensíveis à taxa de
transmissão
r outros usos de UDP (por
quê?):
m DNS (nomes)
m SNMP (gerenciamento)
r transferência confiável com
UDP: incluir confiabilidade na
camada de aplicação
m recuperação de erro
específica à apl.!
porta origem porta dest.
32 bits
Dados de 
aplicação 
(mensagem)
UDP segment format
comprimento checksum
Comprimento em
bytes do
segmento UDP,
incluindo 
cabeçalho
3: Camada de Transporte 3-9
Checksum UDP
Remetente:
r trata conteúdo do
segmento como sequência
de inteiros de 16-bits
r campo checksum zerado
r checksum: soma (adição
usando complemento de 1)
do conteúdo do segmento
r remetente coloca
complemento do valor da
soma no campo checksum
de UDP
Receiver:
r computa checksum do
segmento recebido
r verifica se checksum
computado é zero:
m NÃO - erro detectado
m SIM - nenhum erro
detectado. Mas ainda
pode ter erros? Veja
depois ….
Meta: detecta “erro” (e.g., bits invertidos) no
segmento transmitido
3: Camada de Transporte 3-10
Princípios de Transferência confiável de
dados (rdt)
r importante nas camadas de transporte, enlace
r na lista dos 10 tópicos mais importantes em redes!
r características do canal não confiável determinam a complexidade
de um protocolo de transferência confiável de dados (rdt)
3: Camada de Transporte 3-11
Transferência confiável de dados (rdt):
como começar
rdt_send(): chamada de cima,
(p.ex.,pela apl.). Dados recebidos p/
entregar à camada sup. do receptor
udt_send(): chamada por
rdt, p/ transferir pacote pelo
canal ñ confiável ao receptor
rdt_rcv(): chamada quando
pacote chega chega no lado
receptor do canal
deliver_data(): chamada
por rdt p/ entregar dados
p/ camada superior
3: Camada de Transporte 3-12
Transferência confiável de dados (rdt):
como começar
Iremos:
r desenvolver incrementalmente os lados
remetente, receptor do protocolo RDT
r considerar apenas fluxo unidirecional
m mas info de controle flui em ambos sentidos!
r Usar máquinas de estados finitos (FSM) p/
especificar remetente, receptor
state
1
state
2
event causing state transition
actions taken on state transition
: “ ”
o é
 
 
3: Camada de Transporte 3-13
Rdt1.0: transferência confiável usando um canal
confiável
r canal subjacente perfeitamente confiável
m não tem erros de bits
m não tem perda de pacotes
r FSMs separadas para remetente, receptor:
m remetente envia dados pelo canal subjacente
m receptor recebe dados do canal subjacente
3: Camada de Transporte 3-14
Rdt2.0: canal com erros de bits
r canal subjacente pode inverter bits no pacote
m lembre-se: checksum UDP pode detectar erros de bits
r a questão: como recuperar dos erros?
m reconhecimentos (ACKs): receptor avisa explicitamente ao
remetente que pacote chegou bem
m reconhecimentos negativos (NAKs): receptor avisa
explicitamente ao remetente que pacote 
m remetente retransmite pacote ao receber um NAK
m cenários humanos usando ACKs, NAKs?
r novos mecanismos em rdt2.0 (além do rdt1.0):
m deteção de erros
m realimentação pelo receptor: msgs de controle (ACK,NAK)
receptor->remetente
3: Camada de Transporte 3-15
rdt2.0: especificação da FSM
3: Camada de Transporte 3-16
rdt2.0: em ação (sem erros)
3: Camada de Transporte 3-17
rdt2.0: em ação (cenário de erro)
3: 3-18
rdt2.0 tem uma falha fatal!
O que acontece se
ACK/NAKcom erro?
r não o que
r se 
: 
de pacotes duplicados
O que fazer?
r /
p/ ACK/NAK do receptor?
?
r , mas 
 retransmissão de
 certo!
Lidando c/ duplicação:
r número de
sequência p/ cada pacote
r 
 
r (não
) 
,
e 
 e 
3: Camada de Transporte 3-19
rdt2.1: remetente, trata ACK/NAKs c/ erro
3: Camada de Transporte 3-20
rdt2.1: receptor, trata ACK/NAKs com erro
3: Camada de Transporte 3-21
rdt2.1: discussão
Remetente:
r no. de seq no pacote
r bastam dois nos. de
seq. (0,1). Por quê?
r deve checar se
ACK/NAK recebido
tinha erro
r duplicou o no. de
estados
m estado deve “lembrar”
se pacote “corrente”
tem no. de seq. 0 or 1
Receptor:
r deve checar se pacote
recebido é duplicado
m estado indica se no. de
seq. esperado é 0 or 1
r note: receptor não tem
como saber se último
ACK/NAK foi recebido
bem pelo remetente
3: Camada de Transporte 3-22
rdt2.2: um protocol sem NAKs
r mesma funcionalidade
que rdt2.1, só com ACKs
r ao invés de NAK,
receptor envia ACK p/
último pacote recebido
bem
m receptor deve incluir
explicitamente no. de seq
do pacote reconhecido
r ACK duplicado no
remetente resulta na
mesma ação que o NAK:
retransmite pacote atual
!
3: Camada de Transporte 3-23
rdt3.0: canais com erros e perdas
Nova suposição: canal
subjacente também
pode perder pacotes
(dados ou ACKs)
m checksum, no. de seq.,
ACKs, retransmissões
podem ajudar, mas não
serão suficientes
P: como lidar com perdas?
m remetente espera até ter
certeza que se perdeu
pacote ou ACK, e então
retransmite
m eca!: desvantagens?
Abordagem: remetente
aguarda um tempo
“razoável” pelo ACK
r retransmite e nenhum ACK
recebido neste intervalo
r se pacote (ou ACK) apenas
atrasado (e não perdido):
m retransmissão será
duplicada, mas uso de no.
de seq. já cuida disto
m receptor deve especificar
no. de seq do pacote sendo
reconhecido
r requer temporizador
3: Camada de Transporte 3-24
rdt3.0: remetente
3: Camada de Transporte 3-25
rdt3.0 em ação
3: 3-26
rdt3.0 em ação
3: Camada de Transporte 3-27
Desempenho de rdt3.0
r rdt3.0 funciona, porém seu desempenho é muito ruim
r exemplo: enlace de 1 Gbps, retardo fim a fim de 15 ms,
pacote de 1KB:
Ttransmitir=
8kb/pacote
10**9 b/seg = 8 microseg
Utilização = U = =
8 microseg
30.016 mseg
fração do tempo
remetente ocupado = 0,00015
m pac. de 1KB a cada 30 mseg -> vazão de 33kB/seg num enlace
de 1 Gbps
m protocolo limita uso dos recursos físicos!
3: Camada de Transporte 3-28
Protocolos “dutados” (pipelined)
Dutagem (pipelining): remetente admite múltiplos
pacotes “em trânsito”, ainda não reconhecidos
m faixa de números de seqüência deve ser aumentada
m buffers no remetente e/ou no receptor
r Duas formas genéricas de protocolos dutados:
volta-N, retransmissão seletiva
3: Camada de Transporte 3-29
Volta-N
Remetente:
r no. de seq. de k-bits no cabeçalho do pacote
r admite “janela” de até N pacotes consecutivos não reconhecidos
r ACK(n): reconhece todos pacotes, até e inclusive no. de seq n -
“ACK cumulativo”
m pode receber ACKs duplicados (veja receptor)
r temporizador para cada pacote em trânsito
r timeout(n): retransmite pacote n e todos os pacotes com no. de
seq maiores na janela
3: Camada de Transporte 3-30
Volta-N: FSM estendida do remetente
3: Camada de Transporte 3-31
Volta-N: FSM estendida do receptor
receptor simples:
r usa apenas ACK: sempre envia ACK para pacote
recebido bem com o maior no. de seq. em-ordem
m pode gerar ACKs duplicados
m só precisa se lembrar do expectedseqnum
r pacote fora de ordem:
m descarta (não armazena) -> receptor não usa buffers!
m manda ACK de pacote com maior no. de seq em-ordem
3: Camada de Transporte 3-32
Volta-N
em ação
3: Camada de Transporte 3-33
Retransmissão seletiva
r receptor reconhece individualmente todos os
pacotes recebidos corretamente
m armazena pacotes no buffer, conforme precisa, para
posterior entrega em-ordem à camada superior
r remetente apenas re-envia pacotes para os quais
ACK não recebido
m temporizador de remetente para cada pacote sem ACK
r janela do remetente
m N nos. de seq consecutivos
m outra vez limita nos. de seq de pacotes enviados, mas
ainda não reconhecidos
3: Camada de Transporte 3-34
Retransmissão seletiva: de
3: Camada de Transporte 3-35
Retransmissão seletiva
dados de cima:
r se próx. no. de seq na
janela, envia pacote
timeout(n):
r reenvia pacote n, reiniciar
temporizador
ACK(n) em
[sendbase,sendbase+N]:
r marca pacote n “recebido”
r 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]
r envia ACK(n)
r fora de ordem: buffer
r 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]
r ACK(n)
senão:
r ignora
receptorremetente
3: Camada de Transporte 3-36
Retransmissão seletiva em ação
3: Camada de Transporte 3-37
Retransmissão
seletiva: dilema
Exemplo:
r nos. de seq : 0, 1, 2, 3
r tam. de janela =3
r receptor não vê
diferença entre os
dois cenários!
r incorretamente passa
dados duplicados como
novos em (a)
Q: qual a relação entre
tamanho de no. de seq
e tamanho de janela?
3: Camada de Transporte 3-38
TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581
r transmissão full duplex:
m fluxo de dados bi-
direcional na mesma
conexão
m MSS: tamanho máximo de
segmento
r orientado a conexão:
m handshaking (troca de
msgs de controle) inicia
estado de remetente,
receptor antes de trocar
dados
r fluxo controlado:
m receptor não será afogado
r ponto a ponto:
m 1 remetente, 1 receptor
r fluxo de bytes, ordenados,
confiável:
m não estruturado em msgs
r dutado:
m tam. da janela ajustado por
controle de fluxo e
congestionamento do TCP
r buffers de envio e recepção
socket
door
TCP
send buffer
TCP
receive buffer
socket
door
segment
3: Camada de Transporte 3-39
TCP: estrutura do segmento
no. porta origem no. porta dest 
32 bits
dados da
aplicação
(tam. variável)
número de seqüência
número de reconhecimento
janela receptor
ptr dados urg.checksum
FSRPAUtam.cab.
sem
uso
Opções (tam. variável)
URG: dados urgentes 
(pouco usados)
ACK: no. ACK
válido
PSH: envia dados já
(pouco usado)
RST, SYN, FIN:
gestão de conexão
(comandos de
estabelecimento,
liberação)
de 
(não !)
(como UDP)
3: Camada de Transporte 3-40
TCP: nos. de seq. e ACKs
Nos. de seq.:
m “número”dentro do
fluxo de bytes do
primeiro byte de
dados do segmento
ACKs:
m no. de seq do próx.
byte esperado do
outro lado
m ACK cumulativo
P: como receptor trata
segmentos fora da
ordem?
m R: espec do TCP
omissa - deixado ao
implementador
Estação A Estação B
Seq=42, ACK=79, data = ‘C’
Seq=7
9, ACK
=43, d
ata = ‘
C’
Seq=43, ACK=80
Usuário
tecla
‘C’
A reconhece
chegada
do ‘C’
ecoado
B reconhece
chegada de 
‘C’, ecoa
‘C’ de volta
tempo
cenário simples de telnet
3: Camada de Transporte 3-41
TCP: transferência confiável de dados
remetente simplificado,
supondo:
wait
for 
event
wait
for 
event
event: data received 
from application above
 timer timeout for 
# y
create, send segment
retransmit segment
ACK processing
•fluxo de dados uni-direcional
•sem controle de fluxo,
congestionamento
3: Camada de Transporte 3-42
TCP:
transfer-
ência
confiável
de dados
00 sendbase = número de seqüência inicial
01 nextseqnum = número de seqüência inicial
02
03 loop (forever) { 
04 switch(event) 
05 event: dados recebidos da aplicação acimade seqüência nextseqnum 
inicia temporizador para segmento nextseqnum 
 IP 
 = + ( ) 
 expirado temporizador y 
retransmite segmento de y 
de temporização para segmento y 
reinicia temporizador para número de y 
15 se (y > até
16 nos 
18 } 
 para segmento já reconhecido
 para y 
21 if (número de ACKs duplicados recebidos para y == 3) { 
22 /* TCP: retransmissão */ 
23 de y 
24 reinicia temporizador para número de y 
25 } 
fim de loop forever */ 
Remetente
TCP
simplificado
3: Camada de Transporte 3-43
TCP geração de ACKs [RFCs 1122, 2581]
Evento
chegada de segmento em ordem
sem lacunas,
anteriores já reconhecidos
chegada de segmento em ordem
sem lacunas,
um ACK retardado pendente
chegada de segmento fora de 
ordem, com no. de seq. maior
que esperado -> lacuna
chegada de segmento que 
preenche a lacuna parcial ou
completamente
Ação do receptor TCP
ACK retardado. Espera até 500ms
p/ próx. segmento. Se não chegar
segmento, envia ACK
envia imediatamente um único
ACK cumulativo
envia ACK duplicado, indicando no. 
de seq.do próximo byte esperado
ACK imediato se segmento no
início da lacuna
3: Camada de Transporte 3-44
TCP: cenários de retransmissão
Estação A
Seq=92, 8 bytes de dados
ACK=
100
perdate
m
po
ri
za
çã
o
tempo cenário do
ACK perdido
Estação B
X
Seq=92, 8 bytes de dados
ACK=
100
Host A
Seq=100, 20 bytes de dados
AC
K=1
00
Te
m
p.
p/
 S
eq
=9
2
temporização prematura,
ACKs cumulativos
Host B
Seq=92, 8 bytes de dados
ACK
=12
0
Seq=92, 8 bytes de dados
Te
m
p.
 p
/ 
Se
q=
10
0
ACK
=12
0
tempo
3: Camada de Transporte 3-45
remetente não esgotaria 
buffers do receptor por
transmitir muito, ou
 muito rápidamente
controle de fluxo
TCP: Controle de Fluxo
receptor: explicitamente
avisa o remetente da
quantidade de espaço
livre disponível (muda
dinamicamente)
m campo RcvWindow
no 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 3-46
TCP: Tempo de Resposta (RTT) e
Temporização
P: como escolher valor
do temporizador
TCP?
r maior que o RTT
m note: RTT pode
variar
r muito curto:
temporização prematura
m retransmissões são
desnecessárias
r muito longo: reação
demorada à perda de
segmentos
P: como estimar RTT?
r RTTamostra: tempo medido
entre a transmissão do segmento
e o recebimento do ACK
m ignora retransmissões,
segmentos com ACKs
cumulativos
r RTTamostra vai variar, queremos
“amaciador” de RTT estimado
m usa várias medições recentes,
não apenas o valor corrente
(RTTamostra)
3: Camada de Transporte 3-47
TCP: Tempo de Resposta (RTT) e
Temporização
RTT_estimado = (1-x)* RTT_estimado + x*RTT_amostra
r média corrente exponencialmente ponderada
r influência de cada amostra diminui exponencialmente
com o tempo
r valor típico de x: 0.1
Escolhendo o intervalo de temporização
r RTT_estimado mais uma “margem de segurança”
r variação grande em RTT_estimado
-> margem de segurança maior
Temporização = RTT_estimado + 4*Desvio
Desvio = (1-x)* Desvio +
 x*|RTT_amostra - RTT_estimado|
3: Camada de Transporte 3-48
TCP: Gerenciamento de Conexões
Lembrete: Remetente,
receptor TCP estabelecem
“conexão” antes de trocar
segmentos de dados
r inicializam variáveis TCP:
m nos. de seq.
m buffers, info s/ controle
de fluxo (p.ex. RcvWindow)
r cliente: iniciador de conexão
 Socket clientSocket = new
Socket("hostname","port
number");
r servidor: contactado por
cliente
 Socket connectionSocket =
welcomeSocket.accept();
Inicialização em 3 tempos:
Passo 1: sistema cliente envia
segmento de controle SYN do TCP
m especifica no. inicial de seq
Passo 2: sistema servidor recebe
SYN, responde com segmento de
controle SYNACK
m reconhece SYN recebido
m aloca buffers
m especifica no. inicial de seq.
servidor-> receptor
3: Camada de Transporte 3-49
TCP: Gerenciamento de Conexões ( .)
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
es
pe
ra
 
te
m
po
ri
za
da
3: Camada de Transporte 3-50
TCP: Gerenciamento de Conexões ( .)
Passo 3: cliente recebe FIN,
responde com ACK.
m Entre em “espera
temporizada” -
responderá com ACK a
FINs recebidos
Step 4: servidor, recebe
ACK. Conexão encerrada.
Note: com pequena
modificação, consegue
tratar de FINs
simultâneos.
cliente
FIN
servidor
ACK
ACK
FIN
fechando
fechando
fechada
es
pe
ra
te
m
po
ri
za
da
fechada
3: Camada de Transporte 3-51
TCP Connection Management (cont)
Ciclo de vida
de cliente TCP
Ciclo de vida
de servidor TCP
3: Camada de Transporte 3-52
Princípios de Controle de
Congestionamento
Congestionamento:
r informalmente: “muitas fontes enviando muitos
dados muito rapidamente para a rede poder
tratar”
r differente de controle de fluxo!
r manifestações:
m perda de pacotes (esgotamento de buffers em
m longos atrasos (enfileiramento nos buffers dos
r um dos 10 problemas mais importantes em redes!
3: Camada de Transporte 3-53
Causas/custos de congestionamento:
r dois remetentes,
dois receptores
r um roteador,
buffers infinitos
r sem
retransmissão
r grandes
retardos qdo.
congestionada
r vazão máxima
alcançável
3: Camada de Transporte 3-54
Causas/custos de congestionamento:
cenário 2
r Um roteador, buffers finitos
r retransmissão pelo remetente de pacote
3: Camada de Transporte 3-55
Causas/custos de congestionamento:
r sempre: (“goodput”)
r retransmissão “perfeito” apenas quando perda:
r retransmissão de pacote atrasado (não perdido) faz maior
(que o caso perfeito) para o mesmo
l
in
l
out
=
l
in
l
out
>
l
in
lout
“custos” de congestionamento:
r mais (retransmissão) “ ”
r retransmissões desnecessárias: enviadas múltiplas cópias do pacote
3: Camada de Transporte 3-56
Causas/custos de congestionamento:
r quatro remetentes
r caminhos com múltiplos enlaces
r temporização/retransmissão
l
in
Q: what happens as
and increase ?l
in
3: Camada de Transporte 3-57
Causas/custos de congestionamento:
Outro “custo” de congestionamento:
r quando pacote descartado, qq. capacidade de
transmissão já usada (antes do descarte) para esse
pacote foi desperdiçado!
3: Camada de Transporte 3-58
Abordagens de controle de congestionamento
Controle de
congestionamento
fim a fim :
r não tem realimentação
explícita pela rede
r congestionamento inferido
das perdas, retardo
observados pelo sistema
terminal
r abordagem usada por TCP
Controle de
congestionamento
com apoio da rede:
r roteadores realimentam os
nais
m bit único indicando
congestionamento
(SNA, DECbit, TCP/IP
ECN, ATM)
m taxa explícita p/ envio
pelo remetente
Duas abordagens amplas para controle de
congestionamento:
3: Camada de Transporte 3-59
Estudo de caso: controle de
congestionamento em ABR da ATM
ABR: available bit rate:
r “serviço elástico”
r se caminho do remetente
“sub-carregado”:
m remetente deveria
usar banda disponível
r se caminho do remetente
congestionado:
m remetente reduzidoà
taxa mínima garantida
células RM (resource
management):
r enviadas pelo remetente,
intercaladas com células de dados
r bits na célula RM iniciados por
apoio da rede”)
m bit NI: não aumente a taxa
(congestionamento moderado)
m bit CI: indicação de
congestionamento
r células RM devolvidos ao
remetente pelo receptor, sem
alteração dos bits
3: Camada de Transporte 3-60
Estudo de caso: controle de
congestionamento em ABR da ATM
r Campo ER (explicit rate) de 2 bytes na célula RM
m comutador congestionado pode diminuir valor ER na célula
m taxa do remetente assim ajustada p/ menor valor possível entre
os comutadores do caminho
r bit EFCI em células de dados ligado por comutador
m 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 3-61
TCP: Controle de Congestionamento
r controle fim a fim (sem apoio da rede)
r taxa de transmissão limitada pela tamanho da janela
de congestionamento, Congwin:
r w segmentos, cada um c/ MSS bytes, enviados por RTT:
throughput = w * MSS 
RTT Bytes/sec
Congwin
3: Camada de Transporte 3-62
TCP: Controle de Congestionamento
r duas “fases”
m partida lenta
m evitar
congestionamento
r variáveis importantes:
m Congwin
m threshold: define
limiar entre fases de
partida lenta, controle
de congestionamento
r “sondagem” para banda
utilizável:
m idealmente: transmitir o
mais rápido possível
(Congwin o máximo
possível) sem perder
pacotes
m aumentar Congwin até
perder pacotes
(congestionamento)
m perdas: diminui
Congwin, depois volta a
à sondagem (aumento)
novamente
3: Camada de Transporte 3-63
TCP: Partida lenta
r aumento exponencial (por
RTT) no tamanho da janela
(não muito lenta!)
r evento de perda:
temporizador (Tahoe TCP)
e/ou três ACKs duplicados
(Reno TCP)
initializa: Congwin = 1
for (cada segmento c/ ACK)
 Congwin++
until (evento de perda OR
 CongWin > threshold)
Estação A
um segmento
RT
T
Estação B
tempo
dois segmentos
quqtro segmentos
Algoritmo Partida Lenta
3: Camada de Transporte 3-64
TCP: Evitar Congestionamento
/* partida lenta acabou */
/* Congwin > threshold */
Until (event de perda) {
 cada w segmentos
reconhecidos:
 Congwin++
 }
threshold = Congwin/2
Congwin = 1
faça partida lenta
1
1: TCP Reno pula partida lenta (recuperação
rápida) depois de três ACKs duplicados
Evitar congestionamento
3: Camada de Transporte 3-65
Justeza do TCP
Meta de justeza: se N sessões
TCP compartilham o mesmo
enlace de gargalo, cada uma
deve ganhar 1/N da
capacidade do enlace
TCP congestion
avoidance:
r AADM: aumento
aditivo, decremento
multiplicativo
m aumenta janela em 1
por cada RTT
m diminui janela por
fator de 2 num
evento de perda
AADM
TCP conexão 1
Roteador
gargalo
capacidade R
TCP 
conexão 2
3: Camada de Transporte 3-66
Por quê TCP é justo?
Duas sessões concorrentes:
r Aumento aditivo dá gradiente de 1, enquanto vazão aumenta
r decrementa multiplicativa diminui vazão proporcionalmente
R
R
compartilhamento igual da banda
 1
V
a
z
ã
o
 d
a
 c
o
n
e
x
ã
o
 
2
evitar congestionamento: aumento aditivo
perda: diminui janela por fator de 2
evitar congestionamento: aumento aditivo
perda: diminui janela por fator de 2
3: Camada de Transporte 3-67
TCP: modelagem de latência
P: Quanto tempo custa para
receber um objeto de um
servidor WWW depois de
enviar o pedido?
r Estabelecimento de conexão
TCP
r retardo de transferência de
dados
Notação, suposições:
r Supomos um enlace entre cliente e
servidor de taxa R
r Supomos: janela de
congestionamento fixo, W
segmentos
r S: MSS (bits)
r O: tamanho do objeto (bits)
r sem retransmissões (sem perdas,
sem erros)
Dois casos a considerar:
r WS/R > RTT + S/R: ACK do primeiro segmento na janela
chega antes de enviar todos dados na janela
r WS/R < RTT + S/R: aguarda ACK depois de enviar todos
os dados na janela
3: Camada de Transporte 3-68
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 3-69
TCP: modelagem de latência: partida lenta
r Agora supomos que a janela cresce à la
r Mostramos que a latência de um objeto de tamanho O é:
R
S
R
S
RTTP
R
O
RTTLatency 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 pararia
 se o objeto for de tamanho infinito.
- e K é o número de janelas que cobrem o objeto.
3: Camada de Transporte 3-70
TCP: modelagem de latência: partida lenta (cont.)
RTT
initiate TCP
connection
request
object
first window
= S/R
second window
= 2S/R
third window
= 4S/R
fourth window
= 8S/R
complete
transmissionobject
delivered
time at
client
time at
server
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 3-71
TCP: modelagem de latência: partida lenta (cont.)
R
S
R
S
RTTPRTT
R
O
R
SRTT
R
SRTT
R
O
stallTimeRTT
R
O
P
k
P
k
P
p
p
)12(][2
]2[2
2latency
1
1
1
--+++=
-+++=
++=
-
=
=
å
å
 windowth after the timestall 2
1
k
R
S
RTT
R
S k
=úû
ù
êë
é -+
+
-
ementacknowledg receivesserver until 
segment send tostartsserver whenfrom time=+ RTT
R
S
 window kth the transmit totime2
1
=
-
R
Sk
RTT
initiate TCP
connection
request
object
first window
= S/R
second window
= 2S/R
third window
= 4S/R
fourth window
= 8S/R
complete
transmissionobject
delivered
time at
client
time at
server
3: Camada de Transporte 3-72
Capítulo 3: Sumário
r Princípios atrás dos
serviços da camada de
transporte:
m multiplexação/
desmultiplexação
m transferência confiável de
dados
m controle de fluxo
m controle de congestionamento
r instanciação e implementação na
m UDP
m TCP
Próximo capítulo:
r saímos da “borda” da
rede (camadas de
aplicação e transporte)
r entramos no “núcleo”da
rede