Cap3 Kurose

Captulo 3: Camada de Transporte
Metas do captulo:
entender os
aprender sobre os
princpios atrs dos protocolos da camada
servios da camada de transporte da
de transporte: Internet:
multiplexao/
UDP: transporte no
demultiplexao
orientado a conexes
transferncia
TCP: transporte
confivel de dados
orientado a conexes
controle de fluxo
Controle de
controle de congestionamento do
congestionamento TCP
3: Camada de Transporte 1
Contedo do Captulo 3
3.1 Introduo e 3.5 Transporte
servios de camada de orientado para
transporte conexo: TCP
3.2 Multiplexao e 3.6 Princpios de
demultiplexao controle de
3.3 Transporte no congestionamento
orientado para 3.7 Controle de
conexo: UDP congestionamento no
3.4 Princpios da TCP
transferncia
confivel de dados
Servios e protocolos de transporte
fornecem comunicao lgica aplicao

entre processos de aplicao transporte
rede
executando em diferentes enlace rede
hospedeiros fsica
rede enlace
fsica
enlace
os protocolos de transporte so fsica
executados nos sistemas finais: rede
enlace
lado transmissor: quebra as fsica
rede
mensagens da aplicao em enlace
fsica
segmentos, repassa-os para a rede
camada de rede enlace
fsica
lado receptor: remonta as
mensagens a partir dos aplicao
segmentos, repassa-as para a transporte
rede
camada de aplicao enlace
fsica
existe mais de um protocolo de
transporte disponvel para as
aplicaes
Internet: TCP e UDP
Camadas de Transporte x rede
camada de rede: Analogia domstica:
12 crianas na casa de Ana
comunicao lgica enviando cartas para 12
entre hospedeiros crianas na casa de Bill
camada de transporte: hospedeiros = casas
processos = crianas
comunicao lgica
mensagens da apl. = cartas nos
entre os processos envelopes
depende de, estende protocolo de transporte = Ana
servios da camada de e Bill que demultiplexam para
rede suas crianas
protocolo da camada de rede =
servio postal
Protocolos da camada de transporte Internet
entrega confivel, ordenada aplicao
(TCP)
transporte
rede
enlace rede
controle de fsica
rede enlace
fsica
congestionamento enlace
fsica
controle de fluxo rede
enlace
estabelecimento de conexo fsica
rede
(setup) enlace
fsica
rede
entrega no confivel, no enlace
fsica
ordenada: UDP
extenso sem gorduras do aplicao
melhor esforo do IP transporte

rede
enlace
servios no disponveis: fsica
garantias de atraso mximo

garantias de largura de
banda mnima
transferncia
confivel de dados
Multiplexao/demultiplexao
Multiplexao no transm.:
rene dados de muitos sockets,
adiciona o cabealho de transporte Demultiplexao no receptor:
(usado posteriormente para a Usa info do cabealho para
demultiplexao) entregar os segmentos
recebidos aos sockets corretos
aplicao
aplicao P1 P2 aplicao socket

P3 transporte P4 processo
transporte rede transporte
rede enlace rede
enlace fsica enlace
fsica fsica
Como funciona a demultiplexao
computador recebe os
datagramas IP 32 bits
cada datagrama possui porta origem porta destino
os endereos IP da
origem e do destino
outros campos
cada datagrama
transporta um segmento do cabealho
da camada de
transporte
cada segmento possui dados da
nmeros das portas
origem e destino aplicao
(mensagem/payload)
O hospedeiro usa os
endereos IP e os
nmeros das portas para
direcionar o segmento ao formato de segmento
socket apropriado TCP/UDP
Demultiplexao no orientada a
conexes
Lembrete: socket criado possui Lembrete: ao criar um
nmero de porta local ao host: datagrama para enviar para
DatagramSocket mySocket1 = new um socket UDP, deve
DatagramSocket(12534); especificar:
Endereo IP de destino
Nmero da porta de destino
Quando o hospedeiro recebe Datagramas IP com mesmo no.

o segmento UDP: de porta destino, mas
verifica no. da porta de diferentes endereos IP
destino no segmento origem e/ou nmeros de porta
encaminha o segmento UDP origem podem ser
para o socket com aquele no. encaminhados para o mesmo
de porta socket no destino
Demultiplexao no orientada a
conexes: exemplo
DatagramSocket
serverSocket = new
DatagramSocket DatagramSocket
mySocket2 = new DatagramSocket
mySocket1 = new
DatagramSocket (6428); DatagramSocket
(9157); application
(5775);
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical
source port: 6428 source port: ?

dest port: 9157 dest port: ?
source port: 9157 source port: ?

dest port: 6428 dest port: ?
Demultiplexao Orientada a
Conexes
Socket TCP identificado Servidor pode dar suporte a
pela qudrupla: muitos sockets TCP
endereo IP origem simultneos:
nmero da porta origem cada socket identificado
endereo IP destino pela sua prpria qudrupla
nmero da porta destino Servidores Web tm sockets
Demultiplexao: diferentes para cada conexo
receptor usa todos os de cliente
quatro valores para HTTP no persistente ter
direcionar o segmento sockets diferentes para cada
pedido
para o socket apropriado
Demultiplexao Orientada a
Conexes: exemplo
application
P4 P5 P6
P3 P2 P3
transport
transport transport
network
link physical link
physical server: IP physical
address B
host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
trs segmentos, todos destinados ao endereo IP: B,
dest port: 80 so demultiplexados para sockets distintos 3: Camada de Transporte 12
Demultiplexao Orientada a Conexes:
Servidor Web com Threads
Servidor com threads
application
P3 P4 P2 P3
transport
transport transport
network
link physical link
physical server: IP physical
address B
host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
transferncia
confivel de dados
UDP: User Datagram Protocol [RFC 768]
Protocolo de transporte da Uso do UDP:

Internet mnimo, sem aplicaes de streaming
gorduras, multimdia (tolerante a
Servio melhor esforo, perdas, sensvel a taxas)
segmentos UDP podem ser: DNS
perdidos SNMP
entregues aplicao fora transferncia confivel
de ordem sobre UDP:
sem conexo: adiciona confiabilidade na
camada de aplicao
no h saudao inicial
recuperao de erros
entre o remetente e o especfica da aplicao
receptor UDP
tratamento independente
para cada segmento UDP
UDP: Cabealho do segmento
Comprimento em bytes do
segmento UDP,
incluindo cabealho Por qu existe um UDP?
elimina estabelecimento de
32 bits conexo (que pode causar
porta origem porta dest. retardo)
simples: no mantm
comprimento checksum
estado da conexo nem no
remetente, nem no
receptor
cabealho de segmento
reduzido
Dados de
No h controle de
aplicao
congestionamento: UDP
(mensagem) pode transmitir to rpido
quanto desejado (e
possvel)
Formato do segmento UDP
Soma de Verificao (checksum)
UDP
Objetivo: detectar erros (ex.: bits trocados) no
segmento transmitido
Transmissor: Receptor:
trata contedo do
calcula checksum do
segmento como sequncia
segmento recebido
de inteiros de 16-bits
verifica se o checksum
checksum: soma (adio
calculado bate com o valor
usando complemento de 1)
recebido:
do contedo do segmento
NO - erro detectado
transmissor coloca
complemento do valor da SIM - nenhum erro
soma no campo checksum detectado. Mas ainda
do UDP pode ter erros? Veja
depois .
Exemplo do Checksum Internet
Note que:
Ao adicionar nmeros, o transbordo (vai um) do
bit mais significativo deve ser adicionado ao
resultado
Exemplo: adio de dois inteiros de 16-bits
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
transbordo 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
soma 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
soma de 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
verificao 3: Camada de Transporte 18
transferncia
confivel de dados
Princpios de Transferncia confivel de
dados (rdt)
importante nas
camadas de
transporte e de
enlace
na lista dos 10
tpicos mais
importantes em
redes!
caractersticas
do canal no
confivel
determinam a
complexidade de
um protocolo de
transferncia
confivel de
dados (rdt)
Transferncia confivel: o ponto de
partida
rdt_send(): chamada de cima, (ex.: deliver_data(): chamada pelo
pela apl.). Passa dados p/ serem rdt para entregar dados p/ camada
entregues camada sup. do receptor superior
lado lado
transmissor receptor
udt_send(): chamada pelo rdt para rdt_rcv(): chamada quando

transferir um pacotes para o pacote chega no lado receptor do
receptor sobre um canal no canal
confivel
Transferncia confivel: o ponto de
partida
Iremos:
desenvolver incrementalmente os lados transmissor e receptor
de um protocolo confivel de transferncia de dados (rdt)
considerar apenas fluxo unidirecional de dados
mas info de controle flui em ambos os sentidos!
Usar mquinas de estados finitos (FSM) p/ especificar os
protocolos transmissor e receptor
evento causador da transio de estado

aes executadas na transio de estado
estado: neste estado
o prximo estado estado estado
1 evento
determinado 2
unicamente pelo aes
prximo evento
rdt1.0: transferncia confivel sobre canais
confiveis
canal de transmisso
perfeitamente
confivel
no h erros de bits
no h perda de pacotes
FSMs separadas para
transmissor e
receptor:
transmissor envia dados
pelo canal subjacente
receptor l os dados do
canal subjacente
rdt2.0: canal com erros de bits
canal subjacente pode trocar valores dos bits num pacote
lembrete: checksum UDP pode detectar erros de bits
a questo: como recuperar esses erros?
Como as pessoas recuperam erros

durante uma conversa?
rdt2.0: canal com erros de bits
canal subjacente pode trocar valores dos bits num pacote
lembre-se: checksum UDP pode detectar erros de bits
a questo: como recuperar esses erros?
reconhecimentos (ACKs): receptor avisa explicitamente ao
transmissor que o pacote foi recebido corretamente
reconhecimentos negativos (NAKs): receptor avisa
explicitamente ao transmissor que o pacote tinha erros
transmissor reenvia o pacote ao receber um NAK
novos mecanismos no rdt2.0 (em relao ao rdt1.0):
deteco de erros
Realimentao (feefback): mensagens de controle (ACK,NAK) do
receptor para o transmissor
rdt2.0: especificao da FSM
Animao
no slide
seguinte!
rdt2.0: operao com ausncia de
erros
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
L call from
below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt2.0: cenrio de erro
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
L call from
below
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
deliver_data(data)
udt_send(ACK)
rdt2.0 tem uma falha fatal!
O que acontece se o Lidando c/ duplicatas:
ACK/NAK for transmissor retransmite o
corrompido? ltimo pacote se ACK/NAK
chegar com erro
Transmissor no sabe o que
transmissor inclui nmero
se passou no receptor!
de sequncia em cada
no pode apenas pacote
retransmitir: possibilidade receptor descarta (no
de pacotes duplicados entrega a aplicao)
pacotes duplicados
pare e espera
Transmissor envia um pacote,
e ento aguarda resposta
do receptor
rdt2.1: transmissor, trata ACK/NAKs
corrompidos
rdt2.1: receptor, trata ACK/NAKs
corrompidos
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
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)
Esperar Esperar
rdt_rcv(rcvpkt) && 0 de 1 de rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && baixo baixo 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)
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt2.1: discusso
Transmissor: Receptor:
no. de seq no pacote deve verificar se o
bastam dois nos. de pacote recebido uma
seq. (0,1). Por qu? duplicata
estado indica se no. de
deve verificar se

seq. esperado 0 ou 1
ACK/NAK recebidos
nota: receptor no tem
esto corrompidos
como saber se ltimo
duplicou o no. de
ACK/NAK foi recebido
estados
bem pelo transmissor
estado deve lembrar
se pacote esperado
deve ter no. de seq. 0
ou 1
rdt2.2: um protocolo sem NAKs
mesma funcionalidade do rdt2.1, usando

apenas ACKs
ao invs de NAK, receptor envia ACK para
ltimo pacote recebido sem erro
receptor deve incluir explicitamente no. de seq
do pacote reconhecido
ACKs duplicados no transmissor resultam
na mesma ao do NAK: retransmisso do
pacote atual
rdt2.2: fragmentos do transmissor e
receptor rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
aguarda aguarda
ACK isACK(rcvpkt,1) )
chamada 0
de cima 0 udt_send(sndpkt)
fragmento FSM
do transmissor rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || L
has_seq1(rcvpkt)) aguarda fragmento FSM
0 de
udt_send(sndpkt) baixo do receptor
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
rdt3.0: canais com erros e perdas
Nova hiptese: canal de Abordagem: transmissor

transmisso tambm aguarda um tempo
pode perder pacotes razovel pelo ACK
(dados ou ACKs) retransmite se nenhum ACK
checksum, no. de seq., for recebido neste intervalo
ACKs, retransmisses se pacote (ou ACK) estiver
podem ajudar, mas no apenas atrasado (e no
so suficientes perdido):
retransmisso ser
duplicata, mas uso de no.
de seq. j cuida disto
receptor deve especificar
no. de seq do pacote sendo
reconhecido
requer temporizador
Transmissor rdt3.0
rdt3.0 em ao
rdt3.0 em ao
Remetente Destinatrio
send pkt0 pkt0
rcv pkt0
ack0 send ack0
rcv ack0
send pkt1 pkt1
rcv pkt1
send ack1
ack1
timeout
resend pkt1 pkt1
rcv pkt1
rcv ack1 pkt0 (detect duplicate)
send pkt0 send ack1
ack1
rcv ack1 rcv pkt0
ignora
ack0 send ack0
(d) retransmisso prematura
Desempenho do rdt3.0
rdt3.0 funciona, porm seu desempenho sofrvel

Exemplo: enlace de 1 Gbps, retardo fim a fim de 15
ms, pacote de 8000 bits:
L 8000bits
dtrans 9
8 microsegun dos
R 10 bps
U L/R 0,008
= = 8 = 0,00027
sender 30,008
RTT + L / R microsec
onds
pac. de 1KB a cada 30 mseg -> vazo de 33kB/seg num
enlace de 1 Gbps
protocolo limita uso dos recursos fsicos!
rdt3.0: operao pare e espere
L/ R 0,008
U tx 0,00027
RTT L / R 30,008
Protocolos com paralelismo (pipelining)
Paralelismo (pipelining): transmissor envia vrios
pacotes em sequncia, todos esperando para
serem reconhecidos
faixa de nmeros de sequncia deve ser aumentada
Armazenamento no transmissor e/ou no receptor
(a) operao do protocolo pare e espere (a) operao do protocolo com paralelismo
Duas formas genricas de protocolos com paralelismo:

Go-back-N, retransmisso seletiva 3: Camada de Transporte 41
Paralelismo: aumento da utilizao
Aumenta a utilizao
por um fator de 3!
3 L / R 0,024
U tx 0,00081
RTT L / R 30,008
Protocolos com Paralelismo
Go-back-N: Retransmisso seletiva:
O transmissor pode ter at N O transmissor pode ter at N
pacotes no reconhecidos no pacotes no reconhecidos no
tubo tubo
Receptor envia apenas acks Receptor envia acks
cumulativos individuais para cada pacote
No reconhece pacote se
houver falha de seq.
Transmissor possui um
Transmissor possui um
temporizador para o pacote
temporizador para cada
mais antigo ainda no
pacote ainda no reconhecido
reconhecido
Se o temporizador
Se o temporizador
estourar, retransmite
estourar, retransmite
apenas o pacote
todos os pacotes ainda no
correspondente.
reconhecidos.
Go-back-N (GBN)
Transmissor:
no. de seq. de k-bits no cabealho do pacote
admite janela de at N pacotes consecutivos no
reconhecidos
ACK(n): reconhece todos pacotes, at e inclusive no. de seq n -

ACK/reconhecimento cumulativo
pode receber ACKs duplicados (veja receptor)
temporizador para o pacote mais antigo ainda no confirmado
Estouro do temporizador: retransmite todos os pacotes
pendentes.
GBN: FSM estendida para o
transmissor
If getacknum(rcvpkt)>=base
GBN: FSM estendida para o
receptor
receptor simples:
usa apenas ACK: sempre envia
ACK para pacote recebido
corretamente com o maior no.
de seq. em-ordem
pode gerar ACKs duplicados
s precisa se lembrar do
expectedseqnum
pacotes fora de ordem:
descarta (no armazena) ->
receptor no usa buffers!
reconhece pacote com o
nmero de sequncia mais alto
em-ordem
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, discard,
012345678 rcv ack0, send pkt4 (re)send ack1
012345678 rcv ack1, send pkt5 receive pkt4, discard,
(re)send ack1
ignore duplicate ACK receive pkt5, discard,
(re)send ack1
timeout
012345678 send pkt2
012345678 send pkt3
012345678 send pkt4 rcv pkt2, deliver, send ack2
012345678 send pkt5 rcv pkt3, deliver, send ack3
rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5
Retransmisso seletiva
receptor reconhece individualmente todos os
pacotes recebidos corretamente
armazena pacotes no buffer, conforme necessrio, para
posterior entrega em-ordem camada superior
transmissor apenas reenvia pacotes para os quais
um ACK no foi recebido
temporizador de remetente para cada pacote sem ACK
janela do transmisso
N nmeros de sequncia consecutivos
outra vez limita nmeros de sequncia de pacotes
enviados, mas ainda no reconhecidos
Retransmisso seletiva: janelas do
transmissor e do receptor
reconhecido
Retransmisso seletiva
transmissor receptor
dados de cima: pacote n em
se prx. no. de seq (n) [rcvbase, rcvbase+N-1]
disponvel estiver na janela,
envia o pacote e liga envia ACK(n)
temporizador(n)
fora de ordem: armazena
estouro do temporizador(n):
reenvia pacote n, reinicia em ordem: entrega (tb.
temporizador(n) entrega pacotes
ACK(n) em [sendbase,sendbase+N]: armazenados em ordem),
marca pacote n como avana janela p/ prxima
recebido
pacote ainda no recebido
se n for menor pacote no
reconhecido, avana base da pacote n em
janela ao prx. no. de seq no [rcvbase-N,rcvbase-1]
reconhecido
ACK(n)
seno:
ignora
Retransmisso seletiva em ao
Retransmisso
seletiva: dilema
Exemplo:
nos. de seq : 0, 1, 2, 3
tam. de janela =3
receptor no v diferena
entre os dois cenrios!
incorretamente passa
dados duplicados como
novos em (a)
P: qual a relao entre

tamanho de no. de seq e
tamanho de janela?
3.2 Multiplexao e estrutura do segmento
transferncia confivel de
demultiplexao

dados
3.3 Transporte no controle de fluxo
gerenciamento da conexo
orientado para
conexo: UDP 3.6 Princpios de

controle de
3.4 Princpios da
congestionamento
transferncia
confivel de dados 3.7 Controle de
congestionamento no
TCP
TCP: Viso geral RFCs: 793, 1122, 1323, 2018, 2581
ponto a ponto: transmisso full duplex:

um transmissor, um receptor fluxo de dados bi-direcional
fluxo de bytes, ordenados, na mesma conexo
confivel: MSS: tamanho mximo de
no estruturado em msgs segmento
com paralelismo (pipelined): orientado a conexo:
tam. da janela ajustado por

handshaking (troca de msgs
controle de fluxo e
congestionamento do TCP
de controle) inicia estado do
transmissor e do receptor
antes da troca de dados
fluxo controlado:
receptor no ser afogado
pelo transmissor
Estrutura do segmento TCP
URG: dados urgentes contagem por

(pouco usado) bytes de dados
(no
ACK: campo de ACK
segmentos!)
vlido
PSH: produz envio de
dados (pouco usado) nmero de bytes
receptor est
RST, SYN, FIN: pronto para
estabelec. de conexo aceitar
(comandos de
criao e trmino)
Internet
checksum
(como no UDP)
TCP: nos. de seq. e ACKs
segmento de sada do transmissor
source port # dest port #
Nos. de seq.: sequence number

acknowledgement number
nmerodentro do rwnd
fluxo de bytes do checksum urg pointer
primeiro byte de dados window size

N
do segmento
ACKs:
no. de seq do prx. byte sender sequence number space
esperado do outro lado

sent sent, not- usable not
ACK cumulativo ACKed yet ACKed but not usable
(in- yet sent
P: como receptor trata flight)
segmentos fora da ordem? segmento que chega ao transmissor
source port # dest port #
R: espec do TCP omissa sequence number
- deixado ao acknowledgement number
A
implementador
rwnd
checksum urg pointer
TCP: nos. de seq. e ACKs
cenrio telnet simples
TCP: tempo de viagem de ida e volta (RTT
Round Trip Time) e Temporizao
P: como escolher o P: como estimar RTT?
valor do SampleRTT: tempo medido entre
temporizador TCP? a transmisso do segmento e o
recebimento do ACK
maior que o RTT
correspondente
mas o RTT varia
ignora retransmisses
muito curto:
SampleRTT varia de forma
temporizao prematura
rpida, desejvel um
retransmisses amortecedor para a estimativa
desnecessrias do RTT
muito longo: reao usa vrias medies recentes,
demorada perda de no apenas o ltimo
segmentos SampleRTT obtido
TCP: Tempo de Resposta (RTT) e
Temporizao
EstimatedRTT = (1-a)* EstimatedRTT + a*SampleRTT
mdia mvel exponencialmente ponderada
influncia de cada amostra diminui exponencialmente com o
tempo
valor tpico de a = 0,125
TCP: Tempo de Resposta (RTT) e
Temporizao
Escolhendo o intervalo de temporizao
EstimatedRTT mais uma margem de segurana
grandes variaes no EstimatedRTT
-> maior margem de segurana
primeiro estimar o quanto a SampleRTT se desvia do
EstimatedRTT:
DevRTT = (1-b)* DevRTT +

b*|SampleRTT - EstimatedRTT|
(valor tpico de b = 0,25)

Ento, ajusta o temporizador para:
TimeoutInterval = EstimatedRTT + 4*DevRTT
RTT estimado margem de segurana

demultiplexao

dados
orientado para

controle de
3.4 Princpios da
congestionamento
transferncia
congestionamento no
TCP
Transferncia de dados confivel
do TCP
O TCP cria um servio As retransmisses so
rdt sobre o servio no disparadas por:
confivel do IP estouros de
Segmentos transmitidos temporizao
em paralelo (pipelined) acks duplicados
Acks cumulativos Considere inicialmente
O TCP usa um nico um transmissor TCP
temporizador para simplificado:
retransmisses
ignore acks duplicados
ignore controles de
fluxo e de
congestionamento
Eventos do transmissor TCP
Dados recebidos da aplicao: Estouro do temporizador:
Cria segmento com no. de Retransmite o segmento
sequncia (nseq) que causou o estouro do
nseq o nmero de temporizador
sequncia do primeiro byte Reinicia o temporizador
de dados do segmento Recepo de Ack:
Liga o temporizador se j Se reconhecer segmentos
no estiver ligado ainda no reconhecidos
(temporizao do segmento atualizar informao sobre
mais antigo ainda no o que foi reconhecido
reconhecido) religa o temporizador se
Valor do temporizador: ainda houver segmentos
calculado anteriormente pendentes (no
reconhecidos)
Transmissor TCP (simplificado)
data received from application above
create segment, seq. #: NextSeqNum
pass segment to IP (i.e., send)
NextSeqNum = NextSeqNum + length(data)
if (timer currently not running)
L start timer
NextSeqNum = InitialSeqNum wait
SendBase = InitialSeqNum for
event timeout
retransmit not-yet-acked segment
with smallest seq. #
start timer
ACK received, with ACK field value y
if (y > SendBase) {
SendBase = y
/* SendBase1: last cumulatively ACKed byte */
if (there are currently not-yet-acked segments)
start timer
else stop timer
} 3: Camada de Transporte 64
TCP: cenrios de retransmisso
Religa
Religa temporizao
temporizao
Religa
temporizao
Desliga
temporizao
Desliga
temporizao
Cenrio com perda Temporizao prematura,

do ACK ACKs cumulativos
TCP: cenrios de retransmisso
(mais)
Desliga
temporizao
Seq=120, 15 bytes of data
Cenrio de ACK cumulativo
TCP gerao de ACKs [RFCs 1122, 2581]
Evento no Receptor Ao do Receptor TCP

chegada de segmento em ordem ACK retardado. Espera at 500ms
sem lacunas, pelo prx. segmento. Se no chegar
anteriores j reconhecidos segmento, envia ACK
chegada de segmento em ordem envia imediatamente um nico

sem lacunas, ACK cumulativo
um ACK retardado pendente
chegada de segmento fora de envia ACK duplicado, indicando no.

ordem, com no. de seq. maior de seq.do prximo byte esperado
que esperado -> lacuna
chegada de segmento que ACK imediato se segmento comea

preenche a lacuna parcial ou no incio da lacuna
completamente
Retransmisso rpida do TCP
O intervalo do
temporizador retx rpida do TCP
frequentemente bastante se o transmissor receber 3
longo: ACKs para os mesmos dados
longo atraso antes de
retransmitir um pacote (trs ACKs duplicados),
perdido retransmite segmentos no
Detecta segmentos reconhecidos com menores
perdidos atravs de ACKs nos. de seq.
duplicados. provavelmente o
O transmissor segmento no
normalmente envia reconhecido se perdeu,
diversos segmentos
no preciso esperar o
Se um segmento se temporizador.
perder, provavelmente
haver muitos ACKs
duplicados.
Host A Host B

X
ACK=100
ACK=100
ACK=100
timeout
ACK=100
Retransmisso de um segmento aps trs ACKs duplicados

demultiplexao

dados
orientado para

controle de
3.4 Princpios da
congestionamento
transferncia
congestionamento no
TCP
Controle de Fluxo
do TCP processo
a aplicao pode remover dados de aplicao
dos buffers do socket TCP . aplicao
Buffers de recepo SO
do socket TCP
mais devagar do
que o receptor TCP
est entregando TCP
(transmissor est code
enviando)
IP
Controle de fluxo code
o receptor controla o
transmissor, de modo que
este no inunde o buffer do do transmissor
receptor transmitindo muito pilha de protocolos no receptor

e rapidamente
Controle de Fluxo do TCP:
como funciona
O receptor anuncia o espao livre
do buffer incluindo o valor da rwnd
nos cabealhos TCP dos segmentos para processo de aplicao
que saem do receptor para o
transmissor
RcvBuffer dados armazenados
Tamanho do RcvBuffer
configurado atravs das opes do
socket (o valor default de 4096 rwnd espao livre
bytes)
muitos sistemas operacionais ajustam
RcvBuffer automaticamente.
carga dos segmentos TCP
O transmissor limita a quantidade
os dados no reconhecidos ao
tamanho do rwnd recebido. armazenamento no
lado do receptor
Garante que o buffer do receptor
no transbordar
demultiplexao

dados
orientado para

controle de
3.4 Princpios da
congestionamento
transferncia
congestionamento no
TCP
TCP: Gerenciamento de Conexes
antes de trocar dados, transmissor e receptor TCP dialogam:
concordam em estabelecer uma conexo (cada um sabendo
que o outro quer estabelecer a conexo)
concordam com os parmetros da conexo.
aplicao aplicao
estado conexo: ESTAB estado conexo: ESTAB

variveis conexo: variveis conexo:
No.seq cliente-p/-servidor No.seq cliente-p/-servidor
servidor-p/-cliente servidor-p/-cliente
tamanho rcvBuffer tamanho rcvBuffer
no servidor,cliente no servidor,cliente
network network
Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port welcomeSocket.accept();
number");
Concordando em estabelecer uma conexo
Apresentao de duas vias

(2-way handshake):
P: a apresentao em duas
vias sempre funciona em
redes?
Lets talk
ESTAB atrasos variveis
OK
ESTAB mensagens retransmitidas
(ex: req_conn(x)) devido
perda de mensagem
reordenao de mensagens
choose x no consegue ver o outro lado
req_conn(x)
ESTAB
acc_conn(x)
ESTAB
Concordando em estabelecer uma conexo
cenrios de falha da apresentao de duas vias:
escolhe x escolhe x
req_conn(x) req_conn(x)
ESTAB ESTAB
retransmite acc_conn(x) retransmite acc_conn(x)
req_conn(x) req_conn(x)
ESTAB ESTAB
data(x+1) aceita
req_conn(x)
retransmite dados(x+1)
dados(x+1)
trmino da trmino da
cliente conexo x servidor conexo x servidor
cliente
termina esquece x termina esquece x
req_conn(x)
ESTAB ESTAB
data(x+1) aceita
conexo aberta pela metade! dados(x+1)
(sem cliente!)
Apresentao de trs vias do TCP
estado do cliente estado do servidor

LISTEN LISTEN
escolhe no seq inicial, x
envia msg TCP SYN
SYNSENT SYNbit=1, Seq=x
escolhe no seq inicial, y
envia msg SYNACK,
reconhecendo o SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
SYNACK(x) recebido
ESTAB Indica que o servidor est
ativo;
envia ACK para SYNACK; ACKbit=1, ACKnum=y+1
este segmento pode conter
dados do cliente para ACK(y) recebido
servidor indica que o cliente est
ativo ESTAB
Apresentao de trs vias do TCP
closed
Socket connectionSocket =
welcomeSocket.accept();
L Socket clientSocket =
SYN(x) newSocket("hostname","port
number");
SYNACK(seq=y,ACKnum=x+1)
cria novo socket para SYN(seq=x)
comunicao com o cliente listen
SYN SYN
rcvd sent
SYNACK(seq=y,ACKnum=x+1)
ESTAB ACK(ACKnum=y+1)
ACK(ACKnum=y+1)
L
TCP: Encerrando uma conexo
seja o cliente que o servidor fecham cada
um o seu lado da conexo
enviam segmento TCP com bit FIN = 1
respondem ao FIN recebido com um ACK
ao receber um FIN, ACK pode ser combinado
com o prprio FIN
lida com trocas de FIN simultneos
TCP: Encerrando uma conexo
estado do cliente estado do servidor
ESTAB ESTAB
clientSocket.close()
FIN_WAIT_1 no pode mais FINbit=1, seq=x
enviar, mas pode
receber dados CLOSE_WAIT
ACKbit=1; ACKnum=x+1
ainda pode
FIN_WAIT_2 espera o trmino enviar dados
pelo servidor
LAST_ACK
FINbit=1, seq=y
TIMED_WAIT no pode mais
enviar dados
ACKbit=1; ACKnum=y+1
espera temporizada
por 2*tempo mximo CLOSED
de vida do segmento
CLOSED
transferncia
confivel de dados
Princpios de Controle de
Congestionamento
Congestionamento:
informalmente: muitas fontes enviando dados
acima da capacidade da rede de trat-los
diferente de controle de fluxo!
Sintomas:
perda de pacotes (saturao de buffers nos
roteadores)
longos atrasos (enfileiramento nos buffers dos
roteadores)
um dos 10 problemas mais importantes em redes!
Causas/custos de congestionamento:
cenrio 1
dois remetentes,
dois receptores
um roteador,
buffers infinitos
sem retransmisso
capacidade do link
de sada: R
Vazo mxima por Grandes atrasos qdo. taxa

conexo: R/2 de chegada se aproxima da
capacidade 3: Camada de Transporte 83
Causas/custos de congest.: cenrio 2
Um roteador, buffers finitos
retransmisso pelo remetente de pacote perdido
entrada camada apl. = sada camada apl.: in = out
entrada camada transp. inclui retransmisses.: in out
Hospedeiro A : dados originais out

in Hospedeiro C
'in : dados originais mais
dados retransmitidos
Hospedeiro B Buffers de enlace de sada

finitos compartilhados
Hospedeiro D
Idealizao: conhecimento R/2
perfeito
out
transmissor envia apenas
quando houver buffer
disponvel no roteador in R/2
Hospedeiro A : dados originais out

in Hospedeiro C
cpia 'in : dados originais mais

Hospedeiro B
espao livre em buffer!
Buffers de enlace de Hospedeiro D

sada finitos
compartilhados
Idealizao: perda conhecida.
pacotes podem ser perdidos,
descartados no roteador devido a
buffers cheios
transmissor apenas retransmite
se o pacote sabidamente se
perdeu.
in : dados originais
cpia 'in : dados originais mais out

Hospedeiro B
sem espao em buffer!

A
Hospedeiro D
Idealizao: perda conhecida. R/2
descartados no roteador devido a ao transmitir a R/2,
buffers cheios
alguns pacotes so
out
retransmisses, mas
transmissor apenas retransmite assintoticamente a
goodput ainda seria
se o pacote sabidamente se R/2 (por que?)
perdeu. in R/2
'in : dados originais mais out

Hospedeiro B

A
Hospedeiro D
Realidade: duplicatas R/2
descartados no roteador devido ao transmitir a R/2,
alguns pacotes so
out
a buffers cheios retransmisses
retransmisso prematura, envio

incluindo duplicatas
que so entregues!
de duas cpias, ambas entregues.
in R/2
timeout 'in : dados originais mais out

Hospedeiro B

A
Hospedeiro D
Realidade: duplicatas R/2
descartados no roteador devido ao transmitir a R/2,
alguns pacotes so
out
a buffers cheios retransmisses
retransmisso prematura, envio

incluindo duplicatas
que so entregues!
de duas cpias, ambas entregues.
in R/2
custos do congestionamento:
mais trabalho (retransmisses) para uma dada goodput
Retransmisses desnecessrias: link transporta mltiplas cpias
do pacote
diminuindo a goodput
cenrio 3 P: o que acontece medida que in e
quatro remetentes in crescem ?
caminhos com mltiplos R: medida que in vermelho
enlaces cresce, todos os pacotes azuis
temporizao/ que chegam fila superior so
retransmisso descartados, vazo azul -> 0
out
'in : dados originais mais
Buffers de enlace de sada
finitos compartilhados
cenrio 3
R/2
Outro custo de congestionamento:

quando pacote descartado, qq. capacidade de transmisso
j usada (antes do descarte) para esse pacote foi
desperdiada!
Abordagens de controle de congestionamento
Duas abordagens gerais para controle de
congestionamento:
Controle de congestionamento Controle de congestionamento
fim a fim: assistido pela rede:
no usa realimentao roteadores enviam
explcita da rede informaes para os sistemas
finais
congestionamento
bit indicando
inferido a partir das congestionamento (SNA,
perdas, e dos atrasos DECbit, TCP/IP ECN,
observados nos sistemas ATM)
finais taxa explcita para envio
abordagem usada pelo TCP pelo transmissor
Estudo de caso: controle de
congestionamento do servio ATM ABR
ABR (available bit rate): clulas RM (resource
servio elstico management):
se caminho do transmissor
enviadas pelo transmissor,
est pouco usado:
entremeadas com clulas de dados
transmissor pode usar
banda disponvel bits na clula RM iniciados por
se caminho do transmissor
comutadores (assistido pela
estiver congestionado: rede)
transmissor limitado bit NI: no aumente a taxa
taxa mnima garantida (congestionamento moderado)
bit CI: indicao de
congestionamento
clulas RM devolvidas ao
transmissor pelo receptor, sem
alterao dos bits
Estudo de caso: controle de
congestionamento do servio ATM ABR
Campo ER (explicit rate) de 2 bytes nas clulas RM

comutador congestionado pode reduzir valor de ER nas clulas
taxa do transmissor assim ajustada p/ menor valor possvel entre os
comutadores do caminho
bit EFCI em clulas de dados ligado pelos comutadores
congestionados
se EFCI ligado em clulas de dados que precedem a clula RM,
receptor liga bit CI na clula RM devolvida 3: Camada de Transporte 94
transferncia
confivel de dados
Controle de Congestionamento do
TCP: aumento aditivo, diminuio multiplicativa
Abordagem: aumentar a taxa de transmisso
(tamanho da janela), testando a largura de banda
utilizvel, at que ocorra uma perda
aumento aditivo: incrementa cwnd de 1 MSS a cada RTT
at detectar uma perda
diminuio multiplicativa: corta cwnd pela metade aps
evento de perda
Comportamento de
dente de serra:
testando a largura
de banda
96
Controle de Congestionamento do
TCP: detalhes
transmissor limita a Como o transmissor detecta o
transmisso: congestionamento?
LastByteSent-LastByteAcked evento de perda = estouro
do temporizador ou 3 acks
cwnd
duplicados
Aproximadamente, transmissor TCP reduz a
taxa (cwnd) aps evento de
cwnd
taxa = Bytes/seg perda
RTT
trs mecanismos:
cwnd dinmica, em funo do AIMD
congestionamento detectado na partida lenta
rede conservador aps eventos
de estouro de
temporizao (preveno
de congestionamento)
TCP: Partida lenta
A B
No incio da conexo,
aumenta a taxa
exponencialmente at o
RTT
primeiro evento de perda:
inicialmente cwnd = 1 MSS
duplica cwnd a cada RTT
atravs do incremento da
cwnd para cada ACK
recebido
Resumo: taxa inicial
baixa mas cresce
rapidamente de forma tempo
exponencial
TCP: detectando, reagindo a perdas
perda indicada pelo estouro de temporizador:

cwnd reduzida a 1 MSS;
janela cresce exponencialmente (como na partida
lenta) at um limiar, depois cresce linearmente
perda indicada por ACKs duplicados: TCP RENO
ACKs duplicados indicam que a rede capaz de
entregar alguns segmentos
corta cwnd pela metade depois cresce
linearmente
O TCP Tahoe sempre reduz a cwnd para 1 (seja por
estouro de temporizador que trs ACKS duplicados)
TCP: mudando da partida lenta para a CA
P: Quando o crescimento
exponencial deve
mudar para linear?
R: Quando cwnd atingir
1/2 do seu valor antes
da deteco de perda.
Implementao:
Limiar (Threshold) varivel
(ssthresh)
Com uma perda o limiar
(ssthresh) ajustado para
1/2 da cwnd imediatamente
antes do evento de perda.

Controle de congestionamento do
transmissor TCP
Novo
Novo ACK!
ACK! novo ACK
ACK duplicado
dupACKcount++ novo ACK
.
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
cwnd = cwnd+MSS transmite novos segmentos, como permitido
dupACKcount = 0
L transmite novos segmentos, como permitido
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0 partida L preveno
lenta de
timeout
ssthresh = cwnd/2 congest.
cwnd = 1 MSS ACK duplicado
timeout dupACKcount = 0 dupACKcount++
ssthresh = cwnd/2 retransmite os segmentos que faltam
cwnd = 1 MSS
dupACKcount = 0
retransmite os segmentos que faltam Novo
timeout
ACK!
ssthresh = cwnd/2
cwnd = 1 Novo ACK
dupACKcount = 0
cwnd = ssthresh dupACKcount == 3
dupACKcount == 3 retransmite os segmentos que faltam dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
retransmite os segmentos que faltam retransmite os segmentos que faltam
recuperao
rpida
ACK duplicado
cwnd = cwnd + MSS
transmite novos segmentos, como permitido

Vazo (throughput) do TCP
Qual a vazo mdia do TCP em funo do tamanho da janela
e do RTT?
Ignore a partida lenta, assuma que sempre haja dados a serem
transmitidos
Seja W o tamanho da janela (medida em bytes) quando ocorre uma
perda
Tamanho mdio da janela W
Vazo mdia de W por RTT
W
W/2

Futuro do TCP
Exemplo: segmentos de 1500 bytes, RTT de
100ms, deseja vazo de 10 Gbps
Requer janela de W = 83.333 segmentos em
trnsito
Vazo em termos de taxa de perdas (L) [Mathis 1997]:
1,22 MSS
vazo do TCP
RTT L
L = 210-10 Taxa de perdas demasiado baixa!!!
So necessrias novas verses do TCP para altas
velocidades!

Equidade (Fairness) do TCP
Objetivo de equidade: se K sesses TCP

compartilham o mesmo enlace de gargalo com
largura de banda R, cada uma deve obter uma taxa
mdia de R/K
Conexo TCP 1
Roteador
com gargalo, de
Conexo capacidade R
TCP 2

Por que o TCP justo?
Duas sesses competindo pela banda:
Aumento aditivo d gradiente de 1, enquanto vazo aumenta
Reduo multiplicativa diminui vazo proporcionalmente
R compartilhamento igual da banda
perda: diminui janela por fator de 2

preveno de congest.: aumento aditivo
perda: diminui janela por fator de 2
preveno de congest.: aumento aditivo
Vazo da conexo 1 R
Equidade (mais)
Equidade e UDP Equidade e conexes TCP em
paralelo
Aplicaes multimdia
frequentemente no usam nada impede que as apls. abram
TCP conexes paralelas entre 2
no querem a taxa hosts
estrangulada pelo controle Os browsers Web fazem isto
de congestionamento Exemplo: canal com taxa R
Preferem usar o UDP: compartilhado por 9 conexes;
Injeta udio/vdeo a taxas novas aplicaes pedem 1 TCP,
constantes, toleram obtm taxa de R/10
perdas de pacotes novas aplicaes pedem 11 TCPs,
obtm taxa R/2 !

Captulo 3: Resumo
Princpios por trs dos

servios da camada de
transporte: Prximo captulo:
multiplexao/ samos da borda da
demultiplexao rede (camadas de
aplicao e transporte)
dados entramos no ncleoda
controle de fluxo
rede
controle de congestionamento
instanciao e implementao na
Internet
UDP
TCP

Cap3 Kurose

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Cap3 Kurose

Enviado por

Direitos autorais:

Formatos disponíveis

Captulo 3: Camada de Transporte

fornecem comunicao lgica aplicao

entrega confivel, ordenada aplicao

melhor esforo do IP transporte

garantias de atraso mximo

aplicao P1 P2 aplicao socket

Quando o hospedeiro recebe Datagramas IP com mesmo no.

source port: 6428 source port: ?

source port: 9157 source port: ?

host: IP source IP,port: B,80 host: IP

host: IP source IP,port: B,80 host: IP

Protocolo de transporte da Uso do UDP:

udt_send(): chamada pelo rdt para rdt_rcv(): chamada quando

evento causador da transio de estado

Como as pessoas recuperam erros

rdt_rcv(rcvpkt) && isACK(rcvpkt)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

mesma funcionalidade do rdt2.1, usando

Nova hiptese: canal de Abordagem: transmissor

(d) retransmisso prematura

rdt3.0 funciona, porm seu desempenho sofrvel

Duas formas genricas de protocolos com paralelismo:

ACK(n): reconhece todos pacotes, at e inclusive no. de seq n -

P: qual a relao entre

conexo: UDP 3.6 Princpios de

ponto a ponto: transmisso full duplex:

URG: dados urgentes contagem por

Nos. de seq.: sequence number

fluxo de bytes do checksum urg pointer

primeiro byte de dados window size

esperado do outro lado

cenrio telnet simples

DevRTT = (1-b)* DevRTT +

(valor tpico de b = 0,25)

TimeoutInterval = EstimatedRTT + 4*DevRTT

RTT estimado margem de segurana

conexo: UDP 3.6 Princpios de

Cenrio com perda Temporizao prematura,

Cenrio de ACK cumulativo

Evento no Receptor Ao do Receptor TCP

chegada de segmento em ordem envia imediatamente um nico

chegada de segmento fora de envia ACK duplicado, indicando no.

chegada de segmento que ACK imediato se segmento comea

Seq=92, 8 bytes of data

Retransmisso de um segmento aps trs ACKs duplicados

conexo: UDP 3.6 Princpios de

receptor transmitindo muito pilha de protocolos no receptor

conexo: UDP 3.6 Princpios de

estado conexo: ESTAB estado conexo: ESTAB

Socket clientSocket = Socket connectionSocket =

Apresentao de duas vias

cenrios de falha da apresentao de duas vias:

estado do cliente estado do servidor

Vazo mxima por Grandes atrasos qdo. taxa

Hospedeiro A : dados originais out

Hospedeiro B Buffers de enlace de sada

Hospedeiro A : dados originais out

cpia 'in : dados originais mais

espao livre em buffer!

Buffers de enlace de Hospedeiro D

cpia 'in : dados originais mais out

sem espao em buffer!

'in : dados originais mais out