Você está na página 1de 55

Capítulo 3: Camada de Transporte

Objectivos:

❒ Entender os princípios ❒ Aprender os protocolos

subjacentes ao serviço de transporte na

da camada de Internet:

transporte: ❍ UDP: transporte sem

ligação
❍ Multiplexagem/

desmultiplexagem ❍ TCP: transporte com

ligação
❍ Transferência de dados

fiável ❍ Controlo de congestão em

TCP
❍ Controlo de fluxo

❍ Controlo de congestão

Camada de Transporte 3-1

Capítulo 3: Sumário

❒ 3.1 Serviços da camada ❒ 3.5 Transporte com

de transporte ligação: TCP

❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos

desmultiplexagem ❍ transferência de dados

fiável
❒ 3.3 Transporte sem
❍ controlo de fluxo
ligação: UDP
❍ gestão de ligações

❒ 3.4 Princípios de
❒ 3.6 Princípios de
transmissão de dados
controlo de congestão
fiável
❒ 3.7 Controlo de

congestão em TCP

Camada de Transporte 3-2


Serviços de Transporte e Protocolos

❒ Fornece comunicação lógica

entre processos de aplicação a

funcionar em Sistemas   







Terminais diferentes 
   !"!$#%
,-.$-
❒ Os Protocolos de Transporte &' () *
+

T
/)0 1 3 . 2. +(

r
a
,- .$- &' ( ) *+

n
são executados nos Sistemas

s
/)0 1 3 . 2. +(

p
o
r
&' ( ) *
+

t
Terminais

e

,-.$-

g
/ ) 0 1 .32. +(

ic
lado que envia: parte a

o
❍ &' ( ) *+ ,- .$-

e
x
/)0 1  . 2. +(

t
mensagem da aplicação em

r
&' () *
+

e
m
o
-
segmentos, que passa à

a
,-.-

-
e
/)0 1 3 . 2. +(

x
camada de rede

t
& ' ( ) *
+

r
e
m
o
❍ lado que recebe: junta os 435$6 7 8439: ;
<
= 43>?
5 ; =<@
segmentos em mensagens, =@A$@
6 7 B C A 4 A ;?
passa à camada de aplicação D E ? 7 8;

❒ mais que um protocolo de

transporte disponível para as

aplicações
Camada de Transporte 3-3
❍ Internet: TCP e UDP

Camada de Transporte vs. Rede

❒ Camada de Rede:

comunicação lógica entre Sistemas Terminais

❒ Camada de Transporte:

comunicação lógica entre processos

❍ baseia-se, e melhora, os serviços da camada de Rede

Camada de Transporte 3-4


Serviços de Transporte e Protocolos

❒ Sistemas Terminais ?
❒ Ex: cartas entre
❒ Processos ?
“primos” de
❒ Mensagens de aplicação ?
Lisboa e Porto !!!
❒ Protocolo de transporte ?

❒ Protocolo de rede ?

Sistemas Terminais = casas

Processos = “primos”

Mensagens de aplicação = cartas nos envelopes

Protocolo de transporte = primos que tratam do

correio

Protocolo de rede = serviço postal

Camada de Transporte 3-5

Protocolos de Nível de Transporte na Internet

❒ entrega fiável, ordenada,

unicast (TCP)
FGH I JFK
L M
❍ controlo de congestão N
O FPQ
GM ON
R
ORSR
controlo de fluxo
❍ H I T U S F S MQ ORS$R
VW QI J
M
T

H I T U S F S MQ
r
a

estabelecimento da ligação
OR S$R VW Q I JM
n
s


p

H I T U S F S MQ
o
r

VW Q I J
M
t

entrega não fiável (melhor


e

❒ ORS$R

g

H I T U S F S MQ
ic
o

esforço, “best-effort”),
VW Q I JM OR S$R
e
x

H I T U S F S MQ
t
r

VW QI J
M
e

não ordenada, unicast ou


m
o
-
a

ORSR
-

multicast: UDP
e

H I T U S F S MQ
x
t

V W Q I J
M
r
e
m
o

❒ serviços não disponíveis: F3G$H I JF3KL M


N
O F3PQ
G M ONR
❍ tempo real ORS$R
H I T U S F S MQ
V W Q I JM
❍ garantias de largura de

banda

❍ multicast fiável

Camada de Transporte 3-6


Capítulo 3: Sumário

❒ 3.1 Serviços da camada ❒ 3.5 Transporte com

de transporte ligação: TCP

❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos

desmultiplexagem ❍ transferência de dados

fiável
❒ 3.3 Transporte sem
❍ controlo de fluxo
ligação: UDP
❍ gestão de ligações

❒ 3.4 Princípios de
❒ 3.6 Princípios de
transmissão de dados
controlo de congestão
fiável
❒ 3.7 Controlo de

congestão em TCP

Camada de Transporte 3-7

Multiplexagem/Desmultiplexagem
Multiplexagem no envio:
Demultiplexagem na recepção:

Recolher dados de diferentes


entregar os segmentos
sockets, delimitar dados com
recebidos ao socket correcto
cabeçalho (mais tarde usado

para desmultiplexar)

= socket = processo

aplicação P3 P1
P1 aplicação P2 P4 aplicação

transporte transporte transporte

rede rede rede

lig. de dados ligação de dados lig. de dados

físico físico físico

máquina 1 máquina 2 máquina 3

Camada de Transporte 3-8


Como funciona a desmultiplexagem

❒ máquina recebe datagrama IP

❍ cada datagrama tem 32 bits

endereço IP de origem,
#porto origem #porto destino
endereço IP de destino

❍ cada datagrama leva 1 outros campos

segmento da camada de do

transporte cabeçalho

❍ cada segmento tem números

de porto de origem, destino


Dados da aplicação
(relembre: números de portos
(mensagem)
bem conhecidos para

aplicações específicas)

❒ máquina usa endereços IP e

números de porto para enviar o


Formato do segmento TCP/UDP
segmento para o socket

apropriado

Camada de Transporte 3-9

Desmultiplexagem sem ligação

❒ Quando uma máquina


❒ Criam-se sockets com
recebe um segmento
números de portos:
UDP:
DatagramSocket mySocket1 = new
DatagramSocket(9157); ❍ verifica o número do porto

DatagramSocket mySocket2 = new de destino no segmento

DatagramSocket(9158); ❍ envia o segmento UDP para

o socket com esse número


❒ socket UDP identificado por
de porto
dois parâmetros:
❒ datagramas IP com
(endereço IP destino, nº porto destino)
diferentes endereços IP

e/ou portos de origem

enviados para o mesmo

socket

Camada de Transporte 3-10


Desmultiplexagem sem ligação (cont)

DatagramSocket serverSocket = new DatagramSocket(6428);

P2 P1
P1
P3

PO: 6428 PO: 6428

PD: 9157 PD: 5775

PO: 9157 PO: 5775

PD: 6428 PD: 6428


cliente cliente
servidor
IP: A IP: B
IP: C

PO: Porto Origem oferece “endereço de retorno”

Camada de Transporte 3-11

Desmultiplexagem com ligação

❒ socket TCP identificado ❒ A máquina servidora

por 4 parâmetros: pode suportar muitos

❍ endereço IP de origem sockets TCP simultâneos:

❍ número de porto de ❍ cada socket identificado

origem pelos seus próprios 4

❍ endereço IP de destino parâmetros

❍ número de porto de ❒ Servidores Web têm

destino sockets diferentes para

❒ máquina que recebe usa cada cliente que se liga

todos os quatro valores ❍ HTTP não persistente terá

para enviar o segmento sockets diferentes para

cada pedido
para o socket

apropriado

Camada de Transporte 3-12


Desmultiplexagem com ligação (cont)

P2 P3 P4 P1
P1

PO: 80 PO: 80

PD: 9157 PD: 5775

PO: 9157 PO: 5775

PD: 80 PD: 80
cliente cliente
servidor
IP: A IP: B
IP: C

Camada de Transporte 3-13

Capítulo 3: Sumário

❒ 3.1 Serviços da camada ❒ 3.5 Transporte com

de transporte ligação: TCP

❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos

desmultiplexagem ❍ transferência de dados

fiável
❒ 3.3 Transporte sem
❍ controlo de fluxo
ligação: UDP
❍ gestão de ligações

❒ 3.4 Princípios de
❒ 3.6 Princípios de
transmissão de dados
controlo de congestão
fiável
❒ 3.7 Controlo de

congestão em TCP

Camada de Transporte 3-14


UDP: User Datagram Protocol [RFC 768]

❒ Protocolo de transporte da

Internet cru, sem ornamentos


Porque existe UDP ?
❒ Serviço melhor esforço
❒ sem estabelecimento de
(“best effort”)
ligação (que adiciona atraso)

❒ Segmentos UDP podem ser:


❒ simples: não há estado da

❍ perdidos ligação no emissor, receptor

❍ entregues fora de ordem à ❒ cabeçalho pequeno do

aplicação segmento

❒ Sem ligação ❒ não há controlo de

❍ sem handshaking entre o congestão: UDP pode

emissor e o receptor UDP transmitir tão depressa

quanto se queira !!
❍ cada segmento UDP é

processado

independentemente dos

demais
Camada de Transporte 3-15

UDP: mais

❒ Usualmente utilizado para


32 bits
aplicações com fluxos

multimédia que são:


#porto origem #porto destino
Dimensão,
❍ tolerantes a perdas
em bytes do length checksum

❍ sensíveis ao ritmo segmento

UDP,
❒ Outras utilizações do
incluindo

UDP (Porquê ?): Cabeçalho

❍ DNS Dados da aplicação

❍ SNMP (mensagem)

❒ Transferência fiável sobre

UDP: adicionar a fiabilidade

ao nível da aplicação

Formato do segmento UDP


❍ Recuperação de erros

específica da aplicação!

Camada de Transporte 3-16


checksum UDP

Objectivo: detectar “erros” (e.g., bits trocados) no

segmento transmitido

Receptor:
Emissor:
❒ Calcula o checksum dos
❒ Trata o conteúdo do
segmentos recebidos
segmento como uma

sequência de inteiros de 16 ❒ Verifica se o checksum

bits calculado é igual ao do campo

de checksum
❒ checksum: soma do conteúdo

do segmento (complemento ❍ NÃO – erro detectado

para 1 da soma) ❍ SIM – não houve erro

❒ Emissor coloca o valor do detectado

checksum no campo de ❍ Mas podem haver erros?

checksum do segmento UDP Mais tarde …..

Camada de Transporte 3-17

Capítulo 3: Sumário

❒ 3.1 Serviços da camada ❒ 3.5 Transporte com

de transporte ligação: TCP

❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos

desmultiplexagem ❍ transferência de dados

fiável
❒ 3.3 Transporte sem
❍ controlo de fluxo
ligação: UDP
❍ gestão de ligações

❒ 3.4 Princípios de
❒ 3.6 Princípios de
transmissão de dados
controlo de congestão
fiável
❒ 3.7 Controlo de

congestão em TCP

Camada de Transporte 3-18


Princípios da transmissão de dados fiável

❒ Importante nas aplicações, transporte, ligação de dados

❒ Faz parte da lista top-10 de assuntos de redes!

serviço fornecido implementação do serviço

❒ As características do canal não fiável determinam a

complexidade do protocolo de transferência de dados fiável.

Camada de Transporte 3-19

Transferência de dados fiável: início

rdt_send(): chamado do nível de deliver_data(): chamado


cima, (e.g., aplicação.). Envia dados por rdt para entregar dados

para entrega no nível superior do ao nível superior

receptor

lado do lado do

emissor receptor

udt_send(): chamado por rdt, para rdt_rcv(): chamada quando os

transferir pacotes para o receptor pacotes chegam ao canal no lado

através de um canal não fiável do receptor

Camada de Transporte 3-20


Transferência de dados fiável: início

Vamos:

❒ Desenvolver incrementalmente os lados do emissor, receptor

do protocolo de transferência de dados fiável (rdt)

❒ Considerar apenas transferência de dados unidireccional

❍ Mas a informação de controlo flui nas duas direcções

❒ Usar máquinas de estado finitas (FSM) para especificar o

emissor e o receptor

Evento que causa a transição de estado


estado: quando se
Acções a tomar na transição de estado
esperam eventos.

estado
estado
1 eventos
quando neste estado, o 2

próximo estado é acções

unicamente

determinado pelo

próximo evento
Camada de Transporte 3-21

Rdt1.0: transferência de dados fiável sobre um canal fiável

❒ Canal que está por baixo é perfeitamente fiável

❍ Não há erros nos bits

❍ Não há perda de pacotes

❒ Máquinas de estados separadas para o emissor e o

receptor

❍ Emissor envia dados para o canal

❍ Receptor lê dados do canal

espera rdt_send(data) espera rdt_rcv(packet)


dados de dados de extract (packet,data)
cima packet = make_pkt(data) baixo deliver_data(data)
udt_send(packet)

emissor receptor

Camada de Transporte 3-22


Rdt2.0: canal introduz erros nos bits

❒ Canal que está por baixo pode trocar bits nos pacotes

❍ Relembrar: o checksum UDP detecta erros em bits

❒ Questão: como recuperar dos erros ?

❍ confirmações (acknowledgements, ACKs):

• receptor diz, explicitamente, ao emissor que recebeu um pacote

sem erros

❍ confirmações negativas (negative acknowledgements, NAKs):

• receptor diz, explicitamente, ao emissor que recebeu um pacote

com erros

❍ emissor retransmite o pacote quando recebe o NAK

❍ Exemplos humanos de utilização de ACKs e NAKs?

❒ Novos mecanismos em rdt2.0 (para além de rdt1.0):


❍ detecção de erros

❍ resposta (feed-back) do receptor:

mensagens de controlo (ACK,NAK) receptor → emissor


Camada de Transporte 3-23

rdt2.0: Especificação da Máquina de Estados

rdt_send(data)
Receptor
sndpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
espera espera rdt_rcv(rcvpkt) &&
dados de ACK ou udt_send(sndpkt) corrupt(rcvpkt)
cima NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)


espera
Λ
dados de
Emissor
baixo
predicado

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Camada de Transporte 3-24


rdt2.0: funcionamento sem erros

rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
espera espera rdt_rcv(rcvpkt) &&
dados de ACK ou udt_send(sndpkt) corrupt(rcvpkt)
cima NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)


espera
Λ dados de
baixo

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Camada de Transporte 3-25

rdt2.0: cenário de erros

rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
espera espera rdt_rcv(rcvpkt) &&
dados de ACK ou udt_send(sndpkt) corrupt(rcvpkt)
cima NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)


espera
Λ dados de
baixo

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Camada de Transporte 3-26


rdt2.0 tem uma falha fatal!

O que acontece se os ACKs

ou os NAKs se
Tratamento de duplicados:
corromperem?
❒ Emissor acrescenta número
❒ O emissor não sabe o que
de sequência a cada pacote
aconteceu no receptor!

❒ Emissor retransmite o pacote


❒ A simples retransmissão pode

ocasionar pacotes duplicados corrente se o ACK/NAK se

corromper

O que fazer?
❒ Receptor descarta pacotes

❒ Emissor envia ACKs/NAKs duplicados (não os entrega ao


referentes aos ACK/NAK do
nível superior).
receptor ?

❍ O que acontece se os
parar e esperar

ACKs/NAKs do emissor se stop and wait

perderem ? Emissor envia um pacote e

❒ Retransmite-se! espera pela resposta do

❍ Podem ser retransmitidos receptor

pacotes correctamente
Camada de Transporte
recebidos
3-27

rdt2.1: emissor, trata ACK/NAKs corrompidos

rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
espera espera isNAK(rcvpkt) )
dados 0 ACK ou
de cima udt_send(sndpkt)
NAK 0
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)
Λ
Λ
espera espera
ACK ou dados 1
rdt_rcv(rcvpkt) && NAK 1 de cima
( corrupt(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(data)

udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)


udt_send(sndpkt)

Camada de Transporte 3-28


rdt2.1: receptor, trata ACK/NAKs corrompidos

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)


&& has_seq0(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && corrupt(rcvpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
espera espera
dados 0 dados 1
rdt_rcv(rcvpkt) && de baixo rdt_rcv(rcvpkt) &&
de baixo
not corrupt(rcvpkt) && not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

Camada de Transporte 3-29

rdt2.1: discussão

Emissor: Receptor:

❒ Nº de sequência adicionado ❒ Tem de verificar se


a cada pacote
recebeu pacotes
Dois nºs de sequência (0,1)
duplicados

são suficientes
❍ o estado indica se se
❍ Porquê ?
espera um pacote com o
❒ Tem de verificar se os
nº de sequência 0 ou 1.
ACKs/NAKs recebidos
❒ nota: receptor não
estão corrompidos

pode saber se o último


❒ O dobro do nº de estados

❍ O estado tem de se ACK/NAK chegou

“lembrar” se o pacote correctamente ao


“corrente” tem o nº de
emissor
sequência 0 ou 1.

Camada de Transporte 3-30


rdt2.2: um protocolo livre de NAKs

❒ a mesma funcionalidade de rdt2.1, usando apenas ACKs

❒ em vez de NAK, receptor envia ACK referente ao último

pacote correctamente recebido

❍ receptor tem de incluir, explicitamente, o nº de sequência do

pacote a ser confirmado, isto é, ACKed

❒ ACKs duplicados no emissor resultam na mesma acção

que um NAK: retransmissão do pacote corrente

Camada de Transporte 3-31

rdt2.2: fragmentos do emissor, receptor

rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
espera espera
dados 0 de ACK isACK(rcvpkt,1) )
cima 0 udt_send(sndpkt)
fragmento

do emissor rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || Λ
fragmento
has_seq1(rcvpkt)) espera
dados 0
udt_send(sndpkt) de baixo do receptor

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)


&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt) Camada de Transporte 3-32
rdt3.0: canais com erros e perdas

Novos pressupostos: Aproximação: emissor espera

canal que está por baixo uma quantidade de tempo

também pode perder “razoável” por um ACK

pacotes (dados ou ACKs) ❒ retransmite se o ACK não for

recebido nesse tempo


❍ checksum, nºseq., ACKs,
❒ Se o pacote de dados (ou o ACK)
retransmissões ajudam,
se tiver atrasado (mas não
mas não são suficientes
perdido):

Q: como lidar com as ❍ Retransmissão será duplicada,

mas a utilização de nº de seq.


perdas?
trata disso
❍ Emissor espera até ter a
❍ Receptor tem de especificar o
certeza que os dados ou o
nº de seq. do pacote que está a
ACK se perdeu, depois
ser confirmado (ACKed)
retransmite
❒ Necessário um temporizador
❍ desvantagens? descendente (countdown timer)

Camada de Transporte 3-33

rdt3.0: emissor
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer Λ
Λ espera espera timeout
dados 0 de ACK0 udt_send(sndpkt)
cima
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
espera espera
timeout dados 1 de
udt_send(sndpkt) ACK1
cima
start_timer rdt_rcv(rcvpkt)
rdt_send(data) Λ
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer
Λ

Camada de Transporte 3-34


rdt3.0: em acção

emissor receptor
emissor receptor

funcionamento sem perdas

pacote perdido

Camada de Transporte 3-35

rdt3.0: em acção

emissor receptor emissor receptor

ACK perdido temporizador expira


prematuramente

Camada de Transporte 3-36


Desempenho de rdt3.0

❒ rdt3.0 funciona, mas o desempenho…L

❒ exemplo:

❍ Ligação = 1 Gbps

❍ Tempo de propagação extremo-a-extremo = 15 ms

❍ Pacote = 1KB

L (tamanho pacote em bits) 8Kb/pkt


T = = = 8 µseg
transmissão 10**9 bit/sec
R (ritmo de transmissão, bps)

L / R . 008
U = = = 0.00027
emissor
30.008
RTT + L / R microsec

onds

❍ U emissor
: utilização ou eficiência – fracção do tempo que o emissor

está ocupado a enviar

❍ 1KB (pkt) cada 30 mseg -> débito de 33KB/seg numa ligação 1 Gbps

❍ o protocolo de comunicação limita o uso dos recursos físicos!


Camada de Transporte 3-37

rdt3.0: funcionamento do stop-and-wait

emissor receptor
primeiro bit do pacote transmitido, t = 0
último bit do pacote transmitido, t = L / R

primeiro bit do pacote chega


RTT último bit chega, envia ACK

duração do ACK e tempo


ACK chega, enviar o próximo
de processamento
pacote, t = RTT + L / R
desprezados

L / R . 008
U = = = 0.00027
emissor
30.008
RTT + L / R microsec

onds

Camada de Transporte 3-38


Protocolos em pipeline

Pipeline: o emissor permite múltiplos pacotes, ainda

não confirmados, “a-caminho”

❍ Intervalo dos números de sequência tem de aumentar

❍ Armazenamento no emissor e/ou receptor

um protocolo stop-and-wait em funcionamento um protocolo com pipeline em funcionamento

❒ Duas formas genéricas de protocolos em pipeline:

❍ voltar atrás N, (go-Back-N)

❍ repetição selectiva, (selective repeat)

Camada de Transporte 3-39

Pipelining: utilização melhorada

emissor receptor
primeiro bit transmitido, t = 0
último bit transmitido, t = L / R

primeiro bit do pacote chega


RTT último bit do pacote chega, envia ACK
último bit do 2º pacote chega, envia ACK
último bit do 3º pacote chega, envia ACK
ACK chega, enviar o próximo
pacote, t = RTT + L / R

Aumenta utilização por

um factor de 3!

3 * L / R .024
U = = = 0.0008
emissor
30.008
RTT + L / R microsecon

ds

Camada de Transporte 3-40


Voltar Atrás N (Go-Back-N)

Emissor:

❒ Cabeçalho do pacote com k bits para o nº de seq.

❒ “janela” de até N pacotes consecutivos, ainda não confirmados.

❒ ACK(n): confirma todos os pacotes até o nº de seq. n

❍ ACK cumulativo

❍ podem ser recebidos ACKs duplicados (ver receptor)

❒ temporizador único para o pacote mais antigo por confirmar

❒ timeout(n): retransmite pacote n e todos os pacotes de nº de seq.

superior na janela. Camada de Transporte 3-41

GBN: máquina de estados estendida do emissor


rdt_send(data)
if (nextseqnum < base+N) {
sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum)
start_timer
nextseqnum++
}
Λ else
refuse_data(data)
base=1
nextseqnum=1
timeout
start_timer
Espera
udt_send(sndpkt[base])
rdt_rcv(rcvpkt) udt_send(sndpkt[base+1])
&& corrupt(rcvpkt) …
udt_send(sndpkt[nextseqnum-1])
Λ
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
assume-se que não há ACKs
If (base == nextseqnum)
fora de ordem.
stop_timer
start_timer cancela e volta
else
a armar.
start_timer Camada de Transporte 3-42
GBN: máquina de estados estendida do receptor

default
udt_send(sndpkt) rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
Λ && hasseqnum(rcvpkt,expectedseqnum)
expectedseqnum=1 Wait extract(rcvpkt,data)
sndpkt = deliver_data(data)
make_pkt(0,ACK,chksum) sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++

Receptor simples:

❒ ACK: envia sempre ACK com o nº de sequência mais elevado

para os pacotes correcta e ordenadamente recebidos

❍ pode gerar ACKs duplicados

❍ só tem de recordar o nº de seq. esperado: expectedseqnum


❒ Pacotes fora de ordem:

❍ descartar (não armazenar) -> não há armazenamento no receptor!

❍ reconfirma o último pacote que chegou na ordem

Camada de Transporte 3-43

GBN em
emissor receptor

acção

Camada de Transporte 3-44


Repetição Selectiva

❒ Receptor faz o ACK individual de todos os pacotes

correctamente recebidos

❍ armazena pacotes, quando necessário, para os poder entregar

por ordem ao nível superior

❒ Emissor apenas reenvia pacotes para os quais o ACK

não tenha sido recebido.

❍ temporizador no emissor para cada pacote por confirmar

❒ Janela do emissor

❍ N números de sequência consecutivos

❍ novamente limita os números de sequência dos pacotes

enviados, por confirmar

Camada de Transporte 3-45

Repetição selectiva: janela do emissor e receptor

visão dos números de sequência no emissor

visão dos números de sequência no receptor


Camada de Transporte 3-46
Repetição selectiva

Emissor Receptor

Dados para enviar : Pacote n ∈ [rcvbase, rcvbase+N-1]

❒ se o próximo nº de seq. ❒ envia ACK(n)


disponível cabe na janela,
❒ fora de ordem: armazena
envia o pacote
❒ Por ordem:
Temporizador(n) expirou:
❍ entrega (também entrega os
❒ reenvia pacote n, reinicia o
pacotes armazenados que
temporizador
tenha na ordem)

ACK(n) ∈ [sendbase,sendbase+N]: ❍ avança a janela para o

❒ marca pacote n como próximo pacote ainda não

confirmado recebido

❒ se n é o pacote mais antigo Pacote n ∈ [rcvbase-N, rcvbase-1]

por confirmar, avança a


❒ ACK(n)
base da janela para o

próximo pacote por Doutro modo:


confirmar
❒ ignora
Camada de Transporte 3-47

Repetição selectiva : em acção

Camada de Transporte 3-48


Repetição selectiva:

dilema

Exemplo:

❒ Nºs seq : 0, 1, 2, 3

❒ Dimensão da janela =3

❒ o receptor não vê

diferenças nos dois

cenários!

❒ Dados duplicados são

passados

incorrectamente como

novos em (a)

Q: qual a relação entre o

número de nºs de seq.

disponíveis e a

dimensão da janela ?
Camada de Transporte 3-49

Capítulo 3: Sumário

❒ 3.1 Serviços da camada ❒ 3.5 Transporte com

de transporte ligação: TCP

❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos

desmultiplexagem ❍ transferência de dados

fiável
❒ 3.3 Transporte sem
❍ controlo de fluxo
ligação: UDP
❍ gestão de ligações

❒ 3.4 Princípios de
❒ 3.6 Princípios de
transmissão de dados
controlo de congestão
fiável
❒ 3.7 Controlo de

congestão em TCP

Camada de Transporte 3-50


TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581

❒ Ponto-a-ponto: ❒ Transmissão “full duplex”:

Transmissão de dados
um emissor, um receptor
❍ ❍
bidireccional na mesma ligação

❒ Fluxo de bytes ordenado e fiável:


❍ MSS: maximum segment size

não há delimitação de
Orientado à ligação:
❍ ❒
mensagens
❍ handshaking (transferência de

❒ pipelined: mensagens de controlo) inicia o

estado do emissor e do
❍ dimensão da janela definida
receptor antes de transferir
pelo controlo de congestão e
dados
de fluxo do TCP
❒ Controlo de fluxo:
❒ Buffers no emissor e receptor
❍ Emissor não sobrecarrega o

receptor
Aplicação Aplicação
Escrita de dados Leitura de dados
interface interface
socket socket
TCP TCP
Buffer de envio Buffer de recepção

Camada de Transporte
segmento
3-51

TCP: estrutura do segmento

32 bits

# porto origem # porto destino


❒ Nº de sequência e Nº de ACKS:

❍ Contagem por bytes de dados Número sequência

Não segmentos !
Número acknowledgment

❒ Head Length em palavras de 32 bits head not


UA P R S F rcvr window size
len used
❍ Dimensão sem extensões 20 Bytes
checksum ptr urgent data
❒ RCVR Window Size:

Nº de Bytes que o receptor espera


❍ Opções (dimensão variável)
receber

❒ Opções:

❍ Negociação de parâmetros dados da

• MSS (usual 1500; 536; 512 Bytes) aplicação

• Factor de escala p/ janela em (dimensão variável)


ligações de alto débito

Camada de Transporte 3-52


TCP: estrutura do segmento

32 bits

# porto origem # porto destino


❒ Flags de sinalização de informação

urgente: Número sequência

U – URG: dados que o nível superior do


Número acknowledgment

emissor sinalizou como urgentes
head not
P – PSH: O receptor deve passar os
UA P R S F rcvr window size
❍ len used

dados para o nível superior imediata/


checksum ptr urgent data
❒ Flags de controlo

❍ A – ACK: valor válido no campo ACK Opções (dimensão variável)

❍ R- RST; S- SYN; F – FIN:

estabelecimento e terminação da

ligação
dados da
❒ Ptr Urgent data
aplicação
Apontador para o último byte de dados
(dimensão variável)

que contém dados urgentes

Camada de Transporte 3-53

TCP: nº de sequência e ACK

Números de Sequência:
máquina A máquina B
❍ Nº do primeiro byte

de dados no segmento Utilizador Seq=4


2, AC
digita
ACKs:
K=79,
data
‘C’
= ‘C’
❍ Nº de seq. do próximo

byte esperado do máquina


C ’
outro lado ta = ‘ recebe ‘C’ e
K=43, da
e ecoa de volta
C
❍ ACK cumulativo: 79, A
Seq=
o ‘C’
confirma a recepção

correcta dos bytes máquina

anteriores confirma (ACK)


Seq=4
o eco de ‘C’
3, ACK
Q: Como é que o receptor =80
processa segmentos fora

de ordem ?

❍ R: A especificação tempo
TCP não é clara, Cenário simples de Telnet

deixando esta questão

para a implementação
Camada de Transporte 3-54
TCP: Round Trip Time e Timeout

Q: como definir a Q: como estimar o RTT?

duração do ❒ SampleRTT: tempo medido desde

a transmissão de um segmento
temporizador do
até à recepção do seu ACK
TCP?
❍ não considera retransmissões
❒ maior que o RTT
❒ SampleRTT vai variar, quer-se
❍ mas o RTT varia
uma estimativa do RTT com
❒ demasiado curto: expira
variações “suaves”
prematuramente
❍ fazer a média de várias
❍ retransmissões
medidas recentes, não apenas
desnecessárias
o SampleRTT actual
❒ demasiado longo:

reacção lenta a perdas

de segmentos

Camada de Transporte 3-55

TCP: Round Trip Time e Timeout

EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT

❒ média móvel de peso exponencial (exponential weighted

moving average)

❒ influência de uma amostra passada decresce com

rapidez exponencial

❒ valor típico: α = 0.125

Camada de Transporte 3-56


Exemplo de estimativa do RTT:

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

300

250
RTT (milliseconds)

200

150

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)

SampleRTT Estimated RTT

Camada de Transporte 3-57

TCP: Round Trip Time e Timeout

Definir a duração do temporizador ( timeout)

❒ EstimatedRTT mais “margem de segurança”

❍ grande variação no EstimatedRTT -> maior margem de segurança

❒ primeiro estimar quanto é que as amostras SampleRTT se desviam

do EstimatedRTT:

β)*DevRTT +
DevRTT = (1-β
β*|SampleRTT-EstimatedRTT|

(tipicamente, β = 0.25)

Definir a duração do temporizador como:

TimeoutInterval = EstimatedRTT + 4*DevRTT

Camada de Transporte 3-58


Capítulo 3: Sumário

❒ 3.1 Serviços da camada ❒ 3.5 Transporte com

de transporte ligação: TCP

❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos

desmultiplexagem ❍ transferência de dados

fiável
❒ 3.3 Transporte sem
❍ controlo de fluxo
ligação: UDP
❍ gestão de ligações

❒ 3.4 Princípios de
❒ 3.6 Princípios de
transmissão de dados
controlo de congestão
fiável
❒ 3.7 Controlo de

congestão em TCP

Camada de Transporte 3-59

TCP: transferência de dados fiável

❒ O TCP cria um serviço ❒ Retransmissões

de transmissão de desencadeadas por:

dados fiável (rdt) por ❍ eventos de temporizador

cima do serviço não expirar

fiável do IP ❍ ACKs duplicados

❒ Transmissão de ❒ Considere-se inicialmente

segmentos com um emissor TCP

pipeline simplificado:

ignora ACKs duplicados


ACKs cumulativos


❍ ignora controlo de fluxo,
❒ O TCP usa um único
controlo de congestão

temporizador de

retransmissão

Camada de Transporte 3-60


TCP: eventos do emissor

dados recebidos da aplicação: temporizador expira:

❒ Cria segmento com nº de ❒ retransmitir o segmento

sequência cujo tempo expirou

❒ Nº seq. é o nº do primeiro ❒ rearmar o temporizador

byte de dados no segmento ACK recebido:

❒ Arma o temporizador, se Se confirma segmentos



não estiver já armado (o por confirmar
temporizador é para o mais
❍ actualizar o que foi

antigo segmento por confirmado

confirmar) ❍ armar temporizador se

houver segmentos por


❒ duração do temporizador:
confirmar
TimeOutInterval

Camada de Transporte 3-61

NextSeqNum = InitialSeqNum

emissor
SendBase = InitialSeqNum

loop (forever) {

TCP
switch(event)

(simplificado)
event: data received from application above
create TCP segment with sequence number NextSeqNum
if (timer currently not running)
start timer
Comentário:
pass segment to IP
NextSeqNum = NextSeqNum + length(data)
• SendBase-1:

último byte
event: timer timeout
confirmado
retransmit not-yet-acknowledged segment with
smallest sequence number cumulativamente

start timer Exemplo:

• SendBase-1 = 71;

event: ACK received, with ACK field value of y y= 73, pelo que o

receptor quer 73+ ;


if (y > SendBase) {
SendBase = y
y > SendBase, pelo
if (there are currently not-yet-acknowledged segments)
que houve
start timer
confirmação de
}
alguns dados

} /* end of loop forever */


Camada de Transporte 3-62
TCP: cenários de retransmissão

Máquina A Máquina B Máquina A Máquina B

Seq=9 Seq=9
2, 8 b 2, 8 b
ytes d ytes d
ata Seq= ata

Seq=92 timeout
100,
20 by
tes d
timeout

ata
=100
ACK
00
X K=1 120
AC ACK=
perda

Seq=9 Seq=9
2, 8 b
2, 8 b
ytes d Sendbase ytes d
ata ata
= 100

Seq=92 timeout
SendBase

= 120 20
K=1
=100 AC
ACK

SendBase
SendBase
= 100
= 120
timeout prematuro

tempo
tempo
cenário de ACK perdido
Camada de Transporte 3-63

TCP: cenários de retransmissão (mais)

Máquina A Máquina B

Seq=9
2, 8 b
ytes d
ata

=100
timeout

Seq=1 ACK
00, 20
bytes
data
X
perda

SendBase =120
ACK
= 120

tempo

cenário de ACK cumulativo

Camada de Transporte 3-64


TCP: geração de ACKs [RFC 1122, RFC 2581]

Evento Acção no receptor TCP


Chegada de segmento na ordem, ACK atrasado. Espera máxima de
com nº sequência esperado. 500 ms pelo próximo segmento. Se não
Tudo para trás já confirmado chega o próximo segmento, envia ACK

Chegada de segmento na ordem, Envia imediatamente um único ACK


com nº sequência esperado. cumulativo, referente a todos os
Um segmento por confirmar. segmentos que chegaram na ordem

Chegada de segmento fora de Envia ACK duplicado, indicando o nº de


ordem com nº de seq. superior ao seq. do próximo byte esperado
esperado. Buraco detectado

Chegada de segmento que Envia ACK imediato se o segmento


preenche completa ou começa no limite inferior do “buraco”
incompletamente o buraco
Camada de Transporte 3-65

Retransmissão Rápida (Fast Retransmit)

❒ Duração do temporizador ❒ Se o emissor recebe 3

(timeout) normalmente ACKs para os mesmos

longa: dados, supõe que o

❍ atraso longo antes de segmento depois dos

reenviar o pacote perdido dados confirmados foi

❒ Detectar segmentos perdido:

perdidos via ACKs ❍ fast retransmit: reenvia

duplicados. o segmento antes que o

temporizador expire
❍ Emissor frequentemente

envia muitos segmentos

seguidos

❍ Se um segmento é perdido,

provavelmente haverá

muitos ACKs duplicados.


Camada de Transporte 3-66
Algoritmo Fast Retransmit

event: ACK received, with ACK field value of y


if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
}
else {
increment count of dup ACKs received for y
if (count of dup ACKs received for y = 3) {
resend segment with sequence number y
}

um ACK duplicado para


fast retransmit
um segmento já confirmado

Camada de Transporte 3-67

Capítulo 3: Sumário

❒ 3.1 Serviços da camada ❒ 3.5 Transporte com

de transporte ligação: TCP

❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos

desmultiplexagem ❍ transferência de dados

fiável
❒ 3.3 Transporte sem
❍ controlo de fluxo
ligação: UDP
❍ gestão de ligações

❒ 3.4 Princípios de
❒ 3.6 Princípios de
transmissão de dados
controlo de congestão
fiável
❒ 3.7 Controlo de

congestão em TCP

Camada de Transporte 3-68


TCP: Controlo de fluxo

Controlo de fluxo

emissor não
❒ o lado receptor da
sobrecarrega o receptor
ligação TCP tem um
por transmitir
buffer de recepção: demasiado depressa

❒ serviço de adaptação

de velocidade: adapta

o ritmo de envio à taxa

de processamento de

dados da aplicação
❒ o processo de aplicação

pode ser lento a ler

dados do buffer

Camada de Transporte 3-69

Controlo de fluxo: como funciona

❒ O receptor anuncia o

espaço livre incluindo o

valor de RcvWindow
nos segmentos

❒ O emissor limita os
(Suponha que o receptor TCP dados por confirmar a
descarta segmentos fora RcvWindow
de ordem)
❍ garante que o buffer de

❒ espaço livre no buffer recepção não transborda

= RcvWindow ❒ Quando RcvWindow = 0,


o emissor envia segmentos
= RcvBuffer-[LastByteRcvd -
de 1 byte para obrigar o
LastByteRead]
receptor a responder

Camada de Transporte 3-70


Capítulo 3: Sumário

❒ 3.1 Serviços da camada ❒ 3.5 Transporte com

de transporte ligação: TCP

❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos

desmultiplexagem ❍ transferência de dados

fiável
❒ 3.3 Transporte sem
❍ controlo de fluxo
ligação: UDP
❍ gestão de ligações

❒ 3.4 Princípios de
❒ 3.6 Princípios de
transmissão de dados
controlo de congestão
fiável
❒ 3.7 Controlo de

congestão em TCP

Camada de Transporte 3-71

TCP: Gestão das ligações

❒ Cliente: Inicia a ligação

Recordar: O emissor TCP socket_fd=socket(Domínio, Tipo, 0)


estabelece uma ligação
connect(socket_fd,estr_ender,dim_estr_ender)

antes de iniciar a troca de


Domínio =PF_INET(comunicação entre STs IPv4)
segmentos de dados Tipo = SOCK_STREAM (TCP) ou SOCK_DGRAM (UDP)
❒ Iniciação das variáveis estr_ender = domínio; porto; end IP destino

TCP:

Nº de sequência
Servidor: contactado pelo cliente
❍ ❒
❍ Buffers socket_fd=socket(Domínio, Tipo, 0)

Informação de janela
bind(socket_fd,estr_endereços,dim_estr_ender)

listen (socket_fd, num_lig_em_espera)
de controlo de fluxo
new_fd=accept(socket_fd, estr_endereços, dim)
( RcvWindow)
estr_endereços = domínio; porto; end IP origem

Camada de Transporte 3-72


Gestão das ligações: Estabelecimento

Passo 1: Ligação pedida


Passo 2: Ligação concedida

❒ cliente envia segmento SYN =1


❒ servidor recebe o segmento
para o servidor
de controlo SYN, responde
Define o nº de seq. original
com o segmento de controlo

• client_isn
SYNACK
❍ Não tem campo de dados ❍ Não tem campo de dados

❍ Servidor reserva buffers

Passo 3: Ligação confirmada ❍ Confirma a recepção do seg.

• Ack = client_isn+1

❒ cliente recebe SYNACK, ❍ Define o nº de seq. inicial do

responde com segmento ACK, servidor

que pode conter dados • Server_isn

❍ Reserva buffers e variáveis

❍ Confirma a recepção do seg.

• Ack = server_isn+1

Camada de Transporte 3-73

Gestão das ligações: Estabelecimento

cliente servidor

pedido
Lig
(SYN= ação pedid
1, seq a
Reserva
=clien
t_ isn)
buffers e

variáveis

dida
ã o conce r_isn,
e
Reserva Ligaç seq=serv 1)
buffers e
=1, isn+
(SYN k_client_
variáveis
ac
estabelecimento
Liga
(SYN= ção confirm
0, se ada
ack=s q=client_isn
erver_ +
isn+1) 1,

tempo

Camada de Transporte 3-74


Gestão das ligações: Fecho

Fechando uma ligação: cliente servidor

close
o cliente fecha o socket:
FIN
close(socket);

Passo 1: cliente envia


ACK
close
segmento de controlo TCP
FIN
FIN para o servidor

Passo 2: servidor recebe

timed wait
ACK
FIN, responde com ACK.

Fecha ligação, envia FIN.

fechado

Camada de Transporte 3-75

Gestão das ligações: Fecho

Passo 3: cliente recebe FIN, cliente servidor

responde com ACK.


closing
FIN
❍ Entra em “timed wait” -

responderá com ACK a

FINs recebidos ACK


closing

Passo 4: servidor, recebe


FIN

ACK. Ligação fechada.


timed wait

ACK
Nota: com pequenas
fechado
modificações, pode tratar

FINs simultâneos.

fechado

Camada de Transporte 3-76


TCP Gestão das ligações: ciclo de vida

Ciclo de vida do

servidor TCP

Ciclo de vida do cliente TCP

Camada de Transporte 3-77

Capítulo 3: Sumário

❒ 3.1 Serviços da camada ❒ 3.5 Transporte com

de transporte ligação: TCP

❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos

desmultiplexagem ❍ transferência de dados

fiável
❒ 3.3 Transporte sem
❍ controlo de fluxo
ligação: UDP
❍ gestão de ligações

❒ 3.4 Princípios de
❒ 3.6 Princípios de
transmissão de dados
controlo de congestão
fiável
❒ 3.7 Controlo de

congestão em TCP

Camada de Transporte 3-78


Princípios de Controlo de Congestão

Congestão:

❒ Informalmente: “demasiadas fontes enviam

demasiada informação a um ritmo muito superior

ao que a rede é capaz de processar”

❒ Diferente do controlo de fluxo!

❒ Sintomas:

❍ Perda de pacotes ( buffer overflow nos routers)

❍ Atrasos elevados (espera em fila nos buffers

dos routers)

❒ Problema da lista dos TOP 10!

Camada de Transporte 3-79

Causas e custos do controlo de congestão: cenário 1

Emissor A λout
λin : dados originais
❒ dois emissores,

dois receptores
buffers partilhados na
um router, buffers
Emissor B linha de saída infinitos

infinitos

❒ sem retransmissões

❒ atraso elevado

em situação de

congestão

❒ débito máximo

atingível

Camada de Transporte 3-80


Causas e custos do controlo de congestão: cenário 2

❒ um router, buffers finitos

❒ emissor retransmite pacotes perdidos

Emissor A λin : dados originais λout

λ'in : dados originais, mais


dados retransmitidos

Emissor B buffers partilhados na


linha de saída finitos

Camada de Transporte 3-81

Causas e custos do controlo de congestão: cenário 2

❒ 1 - Situação ideal : λ = λout (goodput)


in
❒ 2 - Retransmissões ocorrem quando há perdas: λ > λout
in
❒ 3 - Retransmissões de pacotes atrasados (não perdidos) faz λ
in
maior para o mesmo λout
1

1 3
2

“custos” da congestão:

❒ Mais trabalho (retransmissões) para um dado “goodput”

❒ Retransmissões desnecessárias: linha transporta múltiplas cópias

do pacote Camada de Transporte 3-82


Causas e custos do controlo de congestão: cenário 3

4 emissores
Q: O que acontece

❒ caminho com vários nós
quando λ e λ
timeout/retransmissões
in in
aumentam ?

Emissor A λout
λin : dados originais
λ'in : dados originais, mais
dados retransmitidos
buffers partilhados na
linha de saída finitos

Emissor B

Camada de Transporte 3-83

Causas e custos do controlo de congestão: cenário 3

H λ
o
o
s
u
t t
A

H
o
s
t
B

Outro “custo” da congestão:

❒ Quando um pacote se perde, qualquer capacidade de

transmissão que já tenha sido usada para o

transmitir é perdida!

Camada de Transporte 3-84


Abordagens ao controlo de congestão

Dois tipos de abordagens ao controlo de congestão:

Controlo de congestão Controlo de congestão

extremo a extremo: assistido pela rede:

❒ não há feedback explícito ❒ routers fornecem feedback

da rede aos sistemas terminais

❒ congestão inferida pelas ❍ um único bit indica a

perdas e atrasos congestão (SNA,

observadas pelos sistemas DECbit, TCP/IP ECN,

terminais ATM)

❒ aproximação do TCP ❍ envio explícito do ritmo

a que o emissor pode

enviar

Camada de Transporte 3-85

Estudo de um caso: Controlo de congestão ATM ABR

ABR: available bit rate: células/pacotes RM ( resource

❒ “Serviço elástico” management):

❒ Se o caminho do emissor ❒ Enviadas pelo emissor,

não está sobrecarregado: intercaladas com as células de

❍ emissor deve usar a dados

largura de banda ❒ Bits nas células RM activadas

disponível pelos switches (“assistido pela

❒ Se o caminho do emissor rede”)

está congestionado : ❍ NI bit: No Increase - não

❍ emissor envia apenas aumentar o ritmo (congestão

ao ritmo mínimo moderada)

garantido ❍ CI bit: Congestion Indication -

indicador de congestão

❒ Células RM devolvidas ao emissor

pelo receptor com os bits intactos

Camada de Transporte 3-86


Estudo de um caso: Controlo de congestão ATM ABR

❒ campo ER (explicit rate) de 2 bytes numa célula RM

❍ comutador (switch) congestionado pode diminuir o valor de ER da célula

❍ emissor envia ao ritmo mínimo suportado pelo caminho

❒ bit EFCI nas células de dados:

❍ EFCI = 1 indica congestão no switch

❍ se uma célula de dados que precede a célula RM tem o EFCI activo, o

receptor activa o bit CI na célula RM devolvida

❒ Bits CI e NI

❍ Um switch pode activar o bit NI/CI, o qual deverá ser devolvido ao

emissor na próxima célula RM Camada de Transporte 3-87

Capítulo 3: Sumário

❒ 3.1 Serviços da camada ❒ 3.5 Transporte com

de transporte ligação: TCP

❒ 3.2 Multiplexagem e ❍ estrutura dos segmentos

desmultiplexagem ❍ transferência de dados

fiável
❒ 3.3 Transporte sem
❍ controlo de fluxo
ligação: UDP
❍ gestão de ligações

❒ 3.4 Princípios de
❒ 3.6 Princípios de
transmissão de dados
controlo de congestão
fiável
❒ 3.7 Controlo de

congestão em TCP

Camada de Transporte 3-88


Controlo de Congestão no TCP

❒ Controlo extremo-a-extremo Como o emissor detecta a

(não assistido pela rede) congestão?

❒ emissor limita a transmissão: ❒ evento de perda =

LastByteSent-LastByteAcked timeout ou 3 ACKs

≤ CongWin duplicados

❒ Resumidamente, ❒ emissor TCP reduz ritmo

( CongWin) após evento


CongWin
ritmo = Bytes/seg de perda
RTT

três mecanismos:
❒ CongWin é dinâmico, função
❍ AIMD
da congestão da rede
❍ arranque lento (slow start)
detectada
❍ conservativo após eventos

de timeout

Camada de Transporte 3-89

AIMD: Additive-Increase, Multiplicative Decrease

decrescimento multiplicativo: aumento aditivo: aumenta

dividir CongWin a meio após CongWin de 1 MSS cada


evento de perda RTT na ausência de

eventos de perda:

janela de sondagem
congestão

24 Kbytes

16 Kbytes

8 Kbytes

tempo

ligação TCP de longa duração

Camada de Transporte 3-90


TCP: Arranque lento (Slow Start)

❒ Quando a ligação começa, ❒ Quando a ligação

CongWin = 1 MSS começa, aumenta o ritmo

❍ Exemplo: MSS = 500 bytes com rapidez exponencial

e RTT = 200 mseg até ao primeiro evento

❍ ritmo inicial = 20 kbps de perda

❒ o ritmo possível pode ser

>> MSS/RTT

❍ vantajoso aumentar

rapidamente o ritmo para

um valor respeitável

Camada de Transporte 3-91

TCP: Arranque lento (mais)

❒ Quando a ligação Máquina A Máquina B

começa, aumenta o

ritmo exponencialmente
um segme
nto
RTT

até ao primeiro evento

de perda:
dois segm
entos

❍ duplica CongWin a cada


RTT
quatro seg
❍ feito incrementando mentos

CongWin por cada ACK


recebido

❒ Sumário: o ritmo inicial

é lento, cresce tempo

exponencialmente

Camada de Transporte 3-92


Refinamento
Filosofia:

❒ Após 3 ACKs duplicados:

❍ CongWin é reduzida a • 3 ACKs duplicados indica

que a rede é capaz de


metade
entregar alguns segmentos
❍ a janela passa a crescer
• timeout antes de 3 ACKs
linearmente
duplicados é “mais
❒ Mas após timeout:
alarmante”

❍ agora CongWin colocado


a 1 MSS;

❍ a janela passa a crescer

exponencialmente

❍ até um limiar (threshold),

depois cresce

linearmente Camada de Transporte 3-93

Refinamento (mais)

Q: Quando deve o

crescimento
tamanho da janela de congestão

exponencial mudar 14
TCP
para linear? 12 Reno
R: Quando
(segmentos)

10
CongWin
chegar a 1/2 do
8

seu valor antes do


6
4 limiar
timeout.
TCP
2 Tahoe

Implementação:
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

❒ Limiar variável ronda de transmissão

❒ Num evento de perda, o

limiar é colocado a 1/2 de

CongWin antes do evento


❒ TCP Tahoe (antigo): recomeça de 1
de perda após qualquer evento de perda

Camada de Transporte 3-94


Sumário: Controlo de Congestão TCP

❒ QuandoCongWin está abaixo do Threshold


(limiar), o emissor está na fase slow-start, a
janela cresce exponencialmente.

❒ Quando CongWin está acima do Threshold, o


emissor está na fase congestion-avoidance, a

janela cresce linearmente.

❒ Quando ocorre um triplo ACK duplicado , o

Threshold é colocado a CongWin/2 e CongWin é


colocado a Threshold.

❒ Quando ocorre um timeout, o Threshold é


colocado a CongWin/2 e CongWin é colocado a 1
MSS.
Camada de Transporte 3-95

TCP: Justiça

Objectivo de justiça: se K sessões TCP partilham um

estrangulamento por uma mesma linha de ritmo R,

cada uma deve obter um ritmo médio de R/K

ligação 1 TCP

estrangulamento
TCP
router
ligação 2
capacidade R

Camada de Transporte 3-96


Porque é que o TCP é justo ?

Duas sessões em competição:

❒ aumento aditivo origina um declive de 1, quando o débito aumenta

❒ decréscimo multiplicativo decresce débito proporcionalmente

R divisão igual de largura de banda


Débito da ligação 2

perda: decresce janela por um factor de 2

evitar a congestão: aumento aditivo

perda: decresce janela por um factor de 2

evitar a congestão: aumento aditivo

Débito da ligação 1 R

Camada de Transporte 3-97

TCP: Justiça (mais)

Justiça e ligações TCP


Justiça e UDP
paralelas
❒ As aplicações multimédia
nada impede as aplicações
normalmente não usam o ❒
de abrir ligações paralelas
TCP
para o mesmo destino.
❍ não querem o ritmo

estrangulado pelo controlo ❒ browsers Web fazem isto


de congestão
❒ Exemplo: linha de ritmo R
❒ Usam UDP:
suportando 9 ligações;
❍ enviam áudio/vídeo a um
❍ nova aplicação pede 1 ligação
ritmo constante, toleram
TCP, obtém ritmo R/10
perdas de pacotes
❍ nova aplicação pede 11
❒ Área de investigação: ligações TCP, obtém mais de

amigo do TCP R/2 !

Camada de Transporte 3-98


Modelo da latência do TCP

Notação, pressupostos:
Q: Quanto tempo demora a
❒ Assumindo uma linha entre o
receber um objecto de um cliente e o servidor de ritmo R

servidor Web depois de [bit/seg]

enviar um pedido? ❒ S: MSS tamanho máximo do

segmento [bits]
Ignorando a congestão, a
O: tamanho do objecto [bits]
latência depende de:

❒ cabeçalhos desprezáveis
❒ estabelecimento de ligação TCP
❒ sem retransmissões (sem
❒ tempo de transmissão de dados
perdas, sem corrupção)
❒ arranque lento
Dimensão da janela:

❒ 1º assumir: janela de

congestão fixa, W segmentos

❒ Depois janela dinâmica,

modelando o arranque lento


Camada de Transporte 3-99

Janela de congestão fixa (1)

1º caso:

WS/R > RTT + S/R: ACK do

1º segmento da janela

recebido antes de se

esgotar a janela

latência = 2RTT + O/R

W = 4

Camada de Transporte 3-100


Janela de congestão fixa (2)

2º caso:

❒ WS/R < RTT + S/R:

espera pelo ACK depois

de esgotar a janela

latência = 2RTT + O/R

+ (K-1)[S/R + RTT - WS/R]

❒ K = nº de janelas de

dados (cada com W

segmentos) que cobrem o


W = 2
objecto completo

Camada de Transporte 3-101

Modelo de latência TCP: Arranque Lento (1)

❒ Supondo que a janela cresce de acordo com o Slow-Start.

❒ A latência de um objecto de dimensão O é:

O  S S
Latência = 2 RTT + + P  RTT +  − (2 P − 1)
R  R R

em que P é o nº de vezes que o TCP no servidor pára:

P = min{Q, K − 1}

-em que Q é o nº de vezes que o servidor pára se o objecto tivesse uma

dimensão infinita

-Ké o nº de janelas que cobrem o objecto

Camada de Transporte 3-102


Modelo de latência TCP: Arranque Lento (2)

Componentes:
inicia ligação
TCP
• 2 RTT para ligar e

pedido pede
• O/R para transmitir
objecto
primeira janela
objecto
= S/R

• tempo que o servidor RTT


segunda janela
pára devido ao arranque
= 2S/R

lento
terceira janela
= 4S/R
Servidor pára:

P = min{K-1,Q} vezes

Exemplo:
quarta janela
= 8S/R
• O/S = 15 segmentos

• K = 4 janelas

• Q = 2

• P = min{K-1,Q} = 2 transmissão
objecto completa
entregue

Servidor pára P=2 vezes


tempo no
tempo no servidor
cliente

Camada de Transporte 3-103

Modelo de latência TCP: Arranque Lento (3)

S
+ RTT = Tempo desde que o servidor inicia a transmiss ão do objecto até que recebe o ACK
R inicia ligação
TCP

S
2 k −1 = Tempo para transmitir a janela K
pede
objecto primeira janela
R = S/R

RTT segunda janela


+
S k −1 S 
= 2S/R
 R + RTT − 2 R  = Tempo de
terceira janela
espera após a transmissão da janela K = 4S/R

P quarta janela
O
Latência = + 2 RTT + ∑ TempoParagem p
= 8S/R

R p =1
P
O S S
= + 2 RTT + ∑ [ + RTT − 2 k −1 ] objecto transmissão
R k =1 R R entregue completa

O S S tempo no
= + 2 RTT + P[ RTT + ] − (2 P − 1) tempo no
cliente
servidor
R R R
Camada de Transporte 3-104
Modelo de latência TCP (4)

Relembre que K = número de janelas que cobrem o objecto

Como se calcula K ?

K = min{k : 2 0 S + 21 S + L + 2 k −1 S ≥ O}
= min{k : 2 0 + 21 + L + 2 k −1 ≥ O / S }
O
= min{k : 2 k − 1 ≥ }
S
O
= min{k : k ≥ log 2 ( + 1)}
S
 O 
= log 2 ( + 1)
 S 
O cálculo de Q, número de paragens para um objecto de tamanho

infinito, é similar (veja Problemas TPC).

Camada de Transporte 3-105

Modelo do HTTP

❒ Assuma que uma página Web consiste de:

❍ 1 página base HTML (de tamanho O bits)

❍ M imagens (cada de tamanho O bits)

❒ HTTP não persistente:

❍ M+1 ligações TCP em série

❍ Tempo de resposta = (M+1)O/R + (M+1)2RTT + soma das paragens

❒ HTTP persistente (com pipelining):

❍ 2 RTT para pedir e receber o ficheiro base HTML

❍ 1 RTT para pedir e receber M imagens

❍ Tempo de resposta = (M+1)O/R + 3RTT + soma das paragens

❒ HTTP não persistente com X ligações paralelas

❍ Suponha M/X inteiro.

❍ 1 ligação TCP para o ficheiro base

❍ M/X conjuntos de ligações paralelas para imagens.

❍ Tempo de resposta = (M+1)O/R + (M/X + 1)2RTT + soma das

paragens

Camada de Transporte 3-106


Tempos de resposta HTTP (em segundos)

RTT = 100 mseg, O = 5 Kbytes, M=10 e X=5

20

15
non-persistent

10

persistent

parallel non-
0
28 Kbps

10 Mbps
100 Kbps

1 Mbps
persistent

Para ritmos baixos, o tempo da ligação e o tempo de resposta são

dominados pelo tempo de transmissão

Ligações persistentes dão apenas uma ligeira melhoria relativamente ao caso

de ligações paralelas.

Camada de Transporte 3-107

Tempos de resposta HTTP (em segundos)

RTT =1 seg, O = 5 Kbytes, M=10 e X=5

70

60

50
non-persistent

40

30
persistent
20

10
parallel non-
0
28 Kbps

10 Mbps
100 Kbps

1 Mbps

persistent

Para RTTs elevados, o tempo de resposta é dominado pelos atrasos no

estabelecimento de ligação e arranque lento de TCP.

As ligações persistentes agora dão uma melhoria importante: especialmente em

redes com elevado atraso ritmo. •


Camada de Transporte 3-108
Capítulo 3: Sumário

❒ Princípios do serviço da

camada de transporte:

❍ multiplexagem,

desmultiplexagem

❍ transferência de dados

fiável A seguir:

❍ controlo de fluxo ❒ Deixar a “periferia”

da rede (aplicações,
❍ controlo de congestão
camada de
Instanciação e implementação
transporte)

na Internet
❒ Entrar no “núcleo”

❍ UDP da rede

❍ TCP

Camada de Transporte 3-109