tcp: visão geral - ufpe

3: Camada de Transporte 3b-1

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

transmissão full duplex: fluxo de dados bi-

direcional na mesma conexão

MSS: tamanho máximo de segmento

orientado a conexão: handshaking (troca de

msgs de controle) inicia estado de remetente, receptor antes de trocar dados

fluxo controlado: receptor não será afogado

ponto a ponto: 1 remetente, 1 receptor

fluxo de bytes, ordenados, confiável: não estruturado em msgs

dutado: tam. da janela ajustado por

controle de fluxo e congestionamento do TCP

buffers de envio e recepção

socket

door

TCP

send buffer

TCP

receive buffer

socket

door

segment

application

writes dataapplication

reads data


TCP: estrutura do segmento

no. porta origem no. porta dest

32 bits

dados da aplicação

(tam. variável)

número de seqüência

número de reconhecimento

janela receptor

ptr dados urg. checksum

F S R P A U tam. cab.

sem uso

Opções (tam. variável)

URG: dados urgentes (pouco usados)

ACK: no. ACK válido

PSH: envia dados já (pouco usado)

RST, SYN, FIN: gestão de conexão

(comandos de estabelecimento,

liberação)

no. bytes rcpt quer aceitar

contagem de dados por bytes (não segmentos!)

checksum Internet

(como UDP)


TCP: nos. de seq. e ACKs Nos. de seq.:

“número” dentro do fluxo de bytes do primeiro byte de dados do segmento

ACKs:

no. de seq do próx. byte esperado do outro lado

ACK cumulativo

P: como receptor trata segmentos fora da ordem?

R: espec do TCP omissa - deixado ao implementador

Estação A Estação B

Usuário tecla

„C‟

A reconhece chegada

do „C‟ ecoado

B reconhece chegada de

„C‟, ecoa „C‟ de volta

tempo

cenário simples de telnet


TCP: cenários de retransmissão

Estação A

perda tem

pori

zaçã

o

tempo cenário do ACK perdido

Estação B

X

Host A

Tem

p.p/

Seq=

92

temporização prematura,

Host B

tempo T

em

p.p/

Seq=

92


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

Host A

loss

tim

eou

t

ACKs cumulativos

Host B

X

time

SendBase = 120


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

Evento

chegada de segmento em ordem

sem lacunas,

anteriores já reconhecidos

chegada de segmento em ordem

sem lacunas,

um ACK retardado pendente

chegada de segmento fora de

ordem, com no. de seq. maior

que esperado -> lacuna

chegada de segmento que

preenche a lacuna parcial ou

completamente

Ação do receptor TCP

ACK retardado. Espera até 500ms

p/ próx. segmento. Se não chegar

segmento, envia ACK

envia imediatamente um único

ACK cumulativo

envia ACK duplicado, indicando no.

de seq.do próximo byte esperado

ACK imediato se segmento no

início da lacuna


TCP: Tempo de Resposta (RTT) e Temporização P: como escolher valor

do temporizador TCP?

maior que o RTT

note: RTT pode variar

muito curto: temporização prematura

retransmissões são desnecessárias

muito longo: reação demorada à perda de segmentos

P: como estimar RTT? RTTamostra: tempo medido

entre a transmissão do segmento e o recebimento do ACK correspondente

ignora retransmissões, segmentos com ACKs cumulativos

RTTamostra vai variar, queremos “amaciador” de RTT estimado

usa várias medições recentes, não apenas o valor corrente (RTTamostra)


TCP: Tempo de Resposta (RTT) e Temporização

RTT_estimado = (1-x)* RTT_estimado + x*RTT_amostra

média móvel

valor típico de x: 0.125


Exemplo de estimativa de RTT: RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

100

150

200

250

300

350

1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106

time (seconnds)

RT

T (

mil

lise

con

ds)

SampleRTT Estimated RTT


TCP: Tempo de Resposta (RTT) e Temporização

Escolhendo o intervalo de temporização

RTT_estimado mais uma “margem de segurança”

variação grande em RTT_estimado

-> margem de segurança maior

Temporização = RTT_estimado + 4*Desvio

Desvio = (1-y)* Desvio + y*|RTT_amostra - RTT_estimado|

(tipicamente, y = 0.25)

Logo o intervalo de temporização (timeout):


TCP cria serviços de rdt em cima do serviço não-confiável do IP

Pipelined segments

ACKs cumulativos

Retransmissões são disparadas por:

Eventos de tempo de confirmação

ACKs duplicados

Inicialmente considere um transmissor TCP simplificado:

Ignore ACKs duplicados

Ignore controle de fluxo, controle de congestionamento

TCP: transferência de dados confiável


Dado recebido da app:

Crie um segmento com número de seqüência

# seq é o número do byte-stream do 1o byte de dados no

segmento

Inicie o temporizador se ele ainda não estiver em execução

(pense no temporizador para o mais antigo segmento não-

confirmado) Tempo de expiração: TimeOutInterval

Tempo de confirmação:

Retransmite o segmento que provocou o tempo de confirmação

Reinicia o temporizador

ACK recebido:

Quando houver o ACK de segmentos anteriormente não

confirmados

Atualizar o que foi confirmado

Iniciar o temporizador se houver segmentos pendentes

Eventos do transmissor TCP


NextSeqNum = InitialSeqNum SendBase = InitialSeqNum

loop (forever) { switch(event)

event: dado recebido da aplicação acima cria segmento TCP com no de seqúência NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data)

event: tempo de confirmação do temporizador retransmit not-yet-acknowledged segment with smallest sequence number start timer

event: ACK recebido, com valor do campo de ACK y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer }

} /* end of loop forever */

Transmissor TCP (simplificado)


Com freqüência, o tempo de expiração é relativamente longo:

Longo atraso antes de reenviar um pacote perdido Detecta segmentos perdidos por meio de ACKs duplicados Transmissor freqüentemente envia muitos segmentos Se o segmento é perdido, haverá muitos ACKs

duplicados. Se o transmissor recebe 3 ACKs para o mesmo dado, ele

supõe que o segmento após o dado confirmado foi perdido:

Retransmissão rápida: reenvia o segmento antes de o temporizador expirar

Retransmissão rápida


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

}

ACK duplicado para um

segmento já confirmado retransmissão rápida

Algoritmo de retransmissão rápida


remetente não esgotaria buffers do receptor por

transmitir muito, ou muito rapidamente

controle de fluxo

TCP: Controle de Fluxo

receptor: explicitamente avisa o remetente da quantidade de espaço livre disponível (muda dinamicamente)

campo RcvWindow

no segmento TCP

remetente: mantém a quantidade de dados transmitidos, porém ainda não reconhecidos, menor que o valor mais recente de RcvWindow

buffering pelo receptor

RcvBuffer = tamanho do Buffer de recepção RcvWindow = espaço vazio no Buffer


TCP transmissor estabelece conexão com o receptor antes de trocar segmentos de dados

Inicializar variáveis: Números de seqüência Buffers, controle de fluxo (ex. RcvWindow)

Cliente: iniciador da conexão Socket clientSocket = new Socket(“hostname","port

number");

Servidor: chamado pelo cliente Socket connectionSocket = welcomeSocket.accept();

Three way handshake: Passo 1: sistema final cliente envia TCP SYN ao servidor Especifica número de seqüência inicial Passo 2: sistema final servidor que recebe o SYN, responde com segmento SYNACK

Reconhece o SYN recebido Aloca buffers Especifica o número de seqüência inicial do servidor Passo 3: o sistema final cliente reconhece o SYNACK

Gerenciamento de conexão TCP


Fechando uma conexão:

cliente fecha o socket:

clientSocket.close();

Passo 1: o cliente envia o segmento

TCP FIN ao servidor

Passo 2: servidor recebe FIN,

responde com ACK. Fecha a

conexão, envia FIN



Passo 3: cliente recebe FIN,

responde com ACK.

Entra “espera temporizada” -

vai responder com ACK a FINs

recebidos

Passo 4: servidor, recebe ACK.

Conexão fechada



Princípios de Controle de Congestionamento

Congestionamento: informalmente: “muitas fontes enviando muitos

dados muito rapidamente para a rede poder tratar”

diferente de controle de fluxo!

sintomas:

perda de pacotes (esgotamento de buffers em roteadores)

longos atrasos (enfileiramento nos buffers dos roteadores)

um dos 10 problemas mais importantes em redes!


Dois transmissores, dois receptores

Um roteador, buffers infinitos

Não há retransmissão

Grandes atrasos quando congestionado

Máxima vazão alcançável

Causas/custos do congestionamento: cenário 1


Um roteador, buffers finitos

Transmissor reenvia pacotes perdidos



Sempre vale : (tráfego bom – sem retransmissão)

“perfeita” retransmissão somente quando há perdas:

Retransmissão de pacotes atrasados (não perdidos) torna maior (que o caso

perfeito ) para o mesmo

Causas/custos do congestionamento: cenário 2 l

in l

out =

l in

l out

>

l in l

out

“custos” do congestionamento:

Mais trabalho (retransmissões) para um dado “tráfego bom”

Retransmissões desnecessárias: enlace transporta várias cópias do mesmo

pacote


Quatro transmissores

Caminhos com múltiplos saltos

Temporizações/retransmissões

l in

P.: que acontece quando e

aumentam?

l in




Outro “custo” do congestionamento:

Quando o pacote é descartado, qualquer capacidade de transmissão que

tenha sido anteriormente usada para aquele pacote é desperdiçada!


Abordagens de controle de congestionamento

Controle de congestionamento fim a fim :

não tem realimentação explícita pela rede

congestionamento inferido das perdas, retardo observados pelo sistema terminal

abordagem usada por TCP

Controle de congestionamento com apoio da rede:

roteadores realimentam as estações

bit único indicando congestionamento (SNA, DECbit, TCP/IP ECN, ATM)

taxa explícita p/ envio pelo remetente

Duas abordagens amplas para controle de congestionamento:


Abordagem (assistida pela rede) para o controle de

congestionamento


TCP: Controle de Congestionamento

controle fim a fim (sem apoio da rede)

taxa de transmissão limitada pela tamanho da janela de congestionamento, Congwin:

w segmentos, cada um c/ MSS bytes, enviados por RTT:

throughput =

w * MSS

RTT

Bytes/sec

Congwin

LastByteSent-LastByteAcked min{CongWin, RcvWindow}


TCP: Controle de Congestionamento

duas “fases”

partida lenta

evitar

congestionamento

variáveis importantes:

Congwin

threshold: define

limiar entre fases de

partida lenta, controle

de congestionamento

“sondagem” para banda utilizável: idealmente: transmitir o

mais rápido possível (Congwin o máximo possível) sem perder pacotes.

aumentar Congwin até sinais de congestionamento.

Qdo TCP detecta congestionamento diminui Congwin, depois volta à sondagem (aumento) novamente.


TCP: Partida lenta

Resumo: Taxa inicial é lenta, mas cresce exponencialmente.

inicializa: Congwin = 1

for (cada segmento c/ ACK)

Congwin++

until (evento de perda OR

CongWin > threshold)

Estação A

RT

T

Estação B

tempo

Algoritmo Partida Lenta


TCP: Partida lenta

Quando a conexão começa, CongWin = 1 MSS

Exemplo: MSS = 500 bytes & RTT = 200 msec

Taxa inicial = 20 kbps

Banda disponível deve ser >> MSS/RTT

Desejável aumentar essa taxa rapidamente.

Aumenta exponencialmente o tamanho da

janela a cada RTT sem perda.


Refinamento

Após 3 ACKs repetidos: CongWin é cortada

pela metade Em seguida, a janela

cresce linearmente. Porém após evento de

timeout: CongWin é ajustada

para 1 MSS; A janela então cresce

exponencialmente Até um valor limite

(“threshold”), depois cresce linearmente.

• 3 ACKs repetidos indicam

capacidade da rede em

entregar segmentos

• timeout antes de 3

ACKs repetidos é “mais

alarmante”

Filosofia:


Refinamento (mais)

0

2

4

6

8

10

12

14

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Rounds deTransmissão

co

ng

esti

on

win

do

w s

ize

(seg

men

ts)

Series1 Series2

threshold

TCP

Tahoe

TCP

Reno


Resumo: Controle Congestionamento TCP

Quando CongWin está abaixo do Threshold, o emissor se encontra na fase de slow-start, janela cresce exponenciamente.

Quando CongWin está acima do Threshold, o emissor se encontra na fase de evitar congestionamento, janela cresce linearmente.

Quando um triplo ACK repetido ocorre, Threshold é ajustada para CongWin/2 and CongWin ajustada para Threshold.

Quando ocorre timeout, Threshold é ajustada para CongWin/2 and CongWin é configurada com 1 MSS.


Justiça do TCP

Meta de justiça: se N sessões TCP

compartilham o mesmo enlace de gargalo,

cada uma deve ganhar 1/N da capacidade

do enlace

TCP conexão 1

Roteador gargalo

capacidade R

TCP conexão 2


Por quê TCP é justo?

Duas sessões concorrentes:

R

R

compartilhamento igual da banda

Vazão da conexão 1

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

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

tcp: visão geral - ufpe

Documents