Capítulo 3: Camada de Transporte - ic.unicamp.brnfonseca/arquivos/cap3.pdf · emissor: fragmentaa mensagem da aplicação em ... porta remetente portareceptor 32 bits dados da aplicação

3: Camada de Transporte 3a-1

Capítulo 3: Camada de TransporteMetas do capítulo:Ø compreender os princípios atrás dos serviços da camada de transporte:

ü multiplexação/demultiplexação

ü transferência confiável de dados

ü controle de fluxoü controle de congestionamento

Ø instanciação e implementação na Internet dos protocolosde transporte

ü UDPü TCP

Resumo do Capítulo:Ø serviços da camada de transporteØ multiplexação/demultiplexaçãoØ transporte sem conexão: UDPØ princípios de transferência confiável de dados

Ø transporte orientado a conexão: TCPü transferência confiávelü controle de fluxoü gerenciamento de conexões

Ø princípios de controle de congestionamento

Ø controle de congestionamento em TCP


Serviços e protocolos de transporteØ provê comunicação lógica entre processos de aplicação executando em hosts diferentes

Ø protocolos de transporte executam em sistemas terminais

ü emissor: fragmenta a mensagem da aplicação em segmentos e os envia paraa camada de rede;

ü receptor: rearranja os segmentos em mesnagense os transmite para a camada de aplicação;

Ø Mais de um protocolo de transporte disponível para as aplicações

ü Internet: TCP e UDP

aplicaçãotransporteredeenlacefísica

redeenlacefísica

aplicaçãotransporteredeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

transporte lógico fima fim


Camada de Rede versus Camada de TransporteØ camada de rede :comunicação lógica entre hosts ou sistemas;

Ø camada de transporte:comunicação lógica entre processosü depende dos serviços da camada de rede

ü extende os serviços da camada de rede

Analogia de Casas:12 crianças enviando cartas para 12 crianças

Ø processos = criançasØ Mensagens da aplicação= cartas no envelope

Ø hosts = casasØ Protolo de transporte = Ann e Bill

Ø Protocolo da camada de rede = serviço de correio


Multiplexação/demultiplexação

aplicação

transporte

rede

enlace

física

P1 aplicação

transporte

rede

enlace

física

aplicação

transporte

rede

enlace

física

P2P3 P4P1

host 1 host 2 host 3

= processo= socket

entrega de segmentos recebidos para os processos da camada de apl corretos

Demultiplexação no receptor:juntar dados de múltiplosprocessos de apl, envelopandodados com cabeçalho (usado depois para demultiplexação)

Multiplexação no emissor:


Como demultiplexação funcionaØ host recebe os datagramas IP

ü Cada datagrama tem um endereço IP de origem e de destino;

ü Cada datagrama carrega 1 segmento da camada de transporte;

ü Cada segemento tem um número de porta de origeme um de destino

ü lembrete: número de porta bem conhecido para aplicações específicas

Ø host usa o endereço IP e o número de porta paradirecionar o segmento para o socket apropriado;

porta remetente porta receptor

32 bits

dados daaplicação(mensagem)

outros campos do cabeçalho

formato de segmento TCP/UDP


Demultiplexação não orientadaa conexãoØ Cria sockets com os números de porta

DatagramSocket mySocket1 = new

DatagramSocket(99111);

DatagramSocket mySocket2 = new

DatagramSocket(99222);

Ø Socket UDP identificadopela 2-tupla:

(endereço IP destino, no porta destino)

Ø Quando o host recebe o segmetno UDP:

ü Verifica o número da porta de destino no segmento

ü Direciona o segmento UDP para o socket correspondente ao númeroda porta;

Ø Datagramas IP com diferentes endereços IP de origem e/ou números de porta de origem sãodirecionados para o mesmo socket


Demultiplexação não orientadaa conexão (cont)

DatagramSocket serverSocket = new DatagramSocket(6428);

ClientIP:B

P3

clientIP: A

P1P1P3

serverIP: C

SP: 6428DP: 9157

SP: 9157DP: 6428

SP: 6428DP: 5775

SP: 5775DP: 6428

SP provê “endereço de retorno”


Demultiplexação orientada a conexão

Ø Identificação do socket, 4-tupla:

ü endereço IP de origemü número da porta de origem

ü endereço IP de destinoü número da porta de destino

Ø Hosts receptor usa estes valores da tupla para direcionar os segmentos para o socket apropriado

Ø host servidor deve suportar múltiplossockets TCP simultaneamente:

ü Cada socket é identificadopor sua 4-tupla

Ø servidores Web tem diferentes sockets paracada cliente

ü HTTP não persistente tem diferentes sockets paracada requisição


Demultiplexação orientada a conexão (cont)

clienteIP:B

P3

clienteIP: A

P1P1P3

servidorIP: C

SP: 80DP: 9157

SP: 9157DP: 80

SP: 80DP: 5775

SP: 5775DP: 80

P4


UDP: User Datagram Protocol [RFC 768]

Ø Protocolo de transporte da Internet mínimo, “sem frescura”,

Ø Serviço “melhor esforço”, segmentos UDP podem ser:

ü perdidosü entregues à aplicação fora de ordem do remesso

Ø sem conexão:ü não há “setup” UDP entre remetente, receptor

ü tratamento independente para cada segmento UDP

Por quê existe um UDP?Ø elimina estabelecimento de conexão (o que pode causar retardo)

Ø simples: não se mantém “estado” da conexão no remetente/receptor

Ø pequeno cabeçalho de segmento

Ø sem controle de congestionamento: UDP pode transmitir o mais rápido possível


Mais sobre UDP

Ø muito utilizado para apls. de meios contínuos (voz, vídeo)

ü tolerantes de perdasü sensíveis à taxa de transmissão

Ø outros usos de UDP (por quê?):

ü DNS (nomes)ü SNMP (gerenciamento)

Ø transferência confiável com UDP: incluir confiabilidade na camada de aplicação

ü recuperação de erro específica à apl.!

porta origem porta dest.

32 bits

Dados de aplicação (mensagem)

UDP segment format

comprimento checksum

Comprimento embytes do

segmento UDP,incluindo cabeçalho


Checksum UDP

Remetente:Ø trata conteúdo do segmento como seqüência de inteiros de 16-bits

Ø campo checksum zeradoØ checksum: soma (adição usando complemento de 1) do conteúdo do segmento

Ø remetente coloca complemento do valor da soma no campo checksumde UDP

Receptor:Ø calcula checksum do segmento recebido

Ø verifica se checksumcomputado é zero:

ü NÃO - erro detectadoü SIM - nenhum erro detectado. Mas ainda pode ter erros? Veja depois ….

Meta: detecta “erro” (e.g., bits invertidos) no segmento transmitido


Princípios de Transferência confiável de dados (rdt)

Ø importante nas camadas de transporte, enlaceØ na lista dos 10 tópicos mais importantes em redes!

Ø características do canal não confiável determinam a complexidadede um protocolo de transferência confiável de dados (rdt)


Transferência confiável de dados (rdt): como começar

sendside

receiveside

rdt_rcv(): chamada quandopacote chega chega no lado

receptor do canal

deliver_data(): chamada por rdt p/ entregar dados

p/ camada superior



sendside

receiveside


receptor do canal


p/ camada superior

rdt_send(): chamada de cima, (p.ex.,pela apl.). Dados recebidos p/entregar à camada sup. do receptor



sendside

receiveside


receptor do canal


p/ camada superior

rdt_send(): chamada de cima, (p.ex.,pela apl.). Dados recebidos p/entregar à camada sup. do receptor

udt_send(): chamada porrdt, p/ transferir pacote pelocanal ñ confiável ao receptor


Transferência confiável de dados (rdt): como começarEtapas:Ø desenvolver incrementalmente os lados remetente, receptor do protocolo RDT

Ø considerar apenas fluxo unidirecional de dadosü mas info de controle flui em ambos os sentidos!

Ø Usar máquinas de estados finitos (FSM) p/ especificar remetente, receptor

estado: neste “estado” o próximo estado é

determinado unicamente pelopróximo evento

estado1

estado2

evento causando transição de estadosações tomadas na transição de estado

eventoações


Rdt1.0: transferência confiável usando um canal confiável

Ø canal subjacente perfeitamente confiávelü não tem erros de bitsü não tem perda de pacotes

Ø FSMs separadas para remetente, receptor:ü remetente envia dados pelo canal subjacenteü receptor recebe dados do canal subjacente


Rdt2.0: canal com erros de bits

Ø canal subjacente pode inverter bits no pacoteü lembre-se: checksum UDP pode detectar erros de bits

Ø a questão: como recuperar dos erros?ü reconhecimentos (ACKs): receptor avisa explicitamente ao remetente que pacote chegou bem

ü reconhecimentos negativos (NAKs): receptor avisa explicitamente ao remetente que pacote tinha erros

ü remetente retransmite pacote ao receber um NAKü cenários humanos usando ACKs, NAKs?

Ø novos mecanismos em rdt2.0 (em relação ao rdt1.0):

ü deteção de errosü realimentação pelo receptor: msgs de controle (ACK,NAK) receptor->remetente


rdt2.0: especificação da FSM

FSM do remetente FSM do receptor


rdt2.0: em ação (sem erros)



























rdt2.0: em ação (cenário de erro)







































rdt2.0 tem uma falha fatal!O que acontece se ACK/NAK com erro?

Ø Remetente não sabe o que passou no receptor!

Ø não se pode apenas retransmitir: possibilidade de pacotes duplicados

O que fazer?Ø remetente usa ACKs/NAKsp/ ACK/NAK do receptor? E se perder ACK/NAK do remetente?

Ø retransmitir, mas pode causar retransmissão de pacote recebido certo!

Lidando c/ duplicação: Ø remetente inclui número de seqüência p/ cada pacote

Ø remetente retransmite pacote atual se ACK/NAK recebido com erro

Ø receptor descarta (não entrega) pacote duplicado

Remetente envia um pacote,e então aguarda resposta do receptor

para e espera


rdt2.1: remetente, trata ACK/NAKs c/ erro


rdt2.1: receptor, trata ACK/NAKs com erro


rdt2.1: discussão

Remetente:Ø no. de seq no pacoteØ bastam dois nos. de seq. (0,1). Por quê?

Ø deve checar se ACK/NAK recebido tinha erro

Ø duplicou o no. de estados

ü estado deve “lembrar” se pacote “corrente” tem no. de seq. 0 ou 1

Receptor:Ø deve checar se pacote recebido é duplicado

ü estado indica se no. de seq. esperado é 0 ou 1

Ø note: receptor não tem como saber se último ACK/NAK foi recebido bem pelo remetente


rdt2.2: um protocolo sem NAKs

Ø mesma funcionalidade que rdt2.1, só com ACKs

Ø ao invés de NAK, receptor envia ACK p/ último pacote recebido bem

ü receptor deve incluir explicitamente no. de seqdo pacote reconhecido

Ø ACK duplicado no remetente resulta na mesma ação que o NAK: retransmite pacote atual

FSM doremetente

!


rdt3.0: canais com erros e perdas

Nova suposição: canal subjacente também pode perder pacotes (dados ou ACKs)

ü checksum, no. de seq., ACKs, retransmissões podem ajudar, mas não serão suficientes

P: como lidar com perdas?ü remetente espera até ter certeza que se perdeu pacote ou ACK, e então retransmite

ü eca!: desvantagens?

Abordagem: remetente aguarda um tempo “razoável” pelo ACK

Ø retransmite e nenhum ACK recebido neste intervalo

Ø se pacote (ou ACK) apenas atrasado (e não perdido):

ü retransmissão será duplicada, mas uso de no. de seq. já cuida disto

ü receptor deve especificar no. de seq do pacote sendo reconhecido

Ø requer temporizador


rdt3.0: remetente


rdt3.0 em ação


rdt3.0 em ação


Desempenho de rdt3.0Ø rdt3.0 funciona, porém seu desempenho é muito ruimØ exemplo: enlace de 1 Gbps, retardo fim a fim de 15 ms, pacote de 1KB:

ü Utilização: fração do temporemetente ocupadoü pac. de 1KB a cada 30 mseg -> vazão de 33kB/seg num enlace de 1 Gbps

ü protocolo limita uso dos recursos físicos!

Ttransmitir=8kb/pkt10**9 b/sec = 8 microsec

L (tamanho do pacote - bits)R (taxa de transmissão, bps)

=

Uemissor=

.008

30.008 = 0.00027 microsegundosL / R

RTT + L / R=


rdt3.0: operação para e espera

bit primeiro pacote transmitido, t = 0

emissor receptor

RTT

último bit transmitido, t = L / R

bit do primeiro pacote recebidoúltimo bit do pacote recebido,

envia ACK

ACK recebido, envia

próximo pacote, t = RTT + L / R

Uemissor=

.008

30.008 = 0.00027 microsegundosL / R

RTT + L / R=


Protocolos “dutados” (pipelined)Dutagem (pipelining): remetente admite múltiplos pacotes “em trânsito”, ainda não reconhecidos

ü faixa de números de seqüência deve ser aumentadaü buffers no remetente e/ou no receptor

Ø Duas formas genéricas de protocolos dutados: volta-N, retransmissão seletiva


Pipelining: aumenta utilização

bit primeiro pacote transmitido, t = 0

emissor receptor

RTT

último bit transmitido, t = L / R

primeiro bit do pacote recebido

último bit recebido, envia ACK

ACK recebido, envia próximo pacote, t = RTT + L / R

último bit do 2o pacote recebido, envia ACK

último bit do 3o pacote recebido, envia ACK

Aumenta a utilização de um fator de 3

Uemissor=

.024

30.008 = 0.0008 microsegundos3*L / R

RTT + L / R=


Volta-NRemetente:Ø no. de seq. de k-bits no cabeçalho do pacoteØ admite “janela” de até N pacotes consecutivos não reconhecidos

Ø ACK(n): reconhece todos pacotes, até e inclusive no. de seq n -“ACK cumulativo”

ü pode receber ACKs duplicados (veja receptor)Ø temporizador para cada pacote em trânsitoØ timeout(n): retransmite pacote n e todos os pacotes com no. de seq maiores na janela


Volta-N: FSM estendida do remetente


Volta-N: FSM estendida do receptor

receptor simples:Ø usa apenas ACK: sempre envia ACK para pacote recebido bem com o maior no. de seq. em-ordem

ü pode gerar ACKs duplicadosü só precisa se lembrar do expectedseqnum

Ø pacote fora de ordem: ü descarta (não armazena) -> receptor não usa buffers!ü manda ACK de pacote com maior no. de seq em-ordem


Volta-Nem ação


Retransmissão seletiva

Ø receptor reconhece individualmente todos os pacotes recebidos corretamente

ü armazena pacotes no buffer, conforme precisa, para posterior entrega em-ordem à camada superior

Ø remetente apenas re-envia pacotes para os quais ACK não recebido

ü temporizador de remetente para cada pacote sem ACK

Ø janela do remetenteü N nos. de seq consecutivos ü outra vez limita nos. de seq de pacotes enviados, mas ainda não reconhecidos


Retransmissão seletiva: janelas de remetente, receptor


Retransmissão seletiva

dados de cima:Ø se próx. no. de seq na janela, envia pacote

timeout(n):Ø reenvia pacote n, reiniciar temporizador

ACK(n) em [sendbase,sendbase+N]:

Ø marca pacote n “recebido”Ø se n for menor pacote não reconhecido, avança base da janela ao próx. no. de seq não reconhecido

pacote n em [rcvbase, rcvbase+N-1]

Ø envia ACK(n)Ø fora de ordem: bufferØ em ordem: entrega (tb. entrega pacotes em ordem no buffer), avança janela p/ próxima pacote ainda não recebido

pacote n em [rcvbase-N,rcvbase-1]

Ø ACK(n)

senão:Ø ignora

receptorremetente


Retransmissão seletiva em ação


Retransmissão seletiva: dilema

Exemplo: Ø nos. de seq : 0, 1, 2, 3Ø tam. de janela =3

Ø receptor não vê diferença entre os dois cenários!

Ø incorretamente passa dados duplicados como novos em (a)

Q: qual a relação entre tamanho de no. de seqe tamanho de janela?


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çãosocket

doorTCP

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 daaplicação

(tam. variável)

número de seqüêncianúmero de reconhecimento

janela receptor

ptr dados urg.checksumFSRPAUtam.

cab.semuso

Opções (tam. variável)

URG: dados urgentes (pouco usados)

ACK: no. ACKválido

PSH: envia dados já(pouco usado)

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

(comandos deestabelecimento,

liberação)

no. bytes rcpt queraceitar

contagem de dadospor bytes (não segmentos!)

checksum Internet

(como UDP)


TCP: nos. de seq. e ACKsNos. 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 cumulativoP: como receptor trata

segmentos fora da ordem?

ü R: espec do TCP omissa - deixado ao implementador

Estação A Estação B

Seq=42, ACK=79, data = ‘C’

Seq=79, ACK=43, data = ‘C’

Seq=43, ACK=80

Usuáriotecla‘C’

A reconhecechegadado ‘C’ecoado

B reconhecechegada de ‘C’, ecoa‘C’ de volta

tempocenário simples de telnet


TCP: Tempo de Resposta (RTT) e TemporizaçãoP: como escolher valor do temporizadorTCP?

Ø 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 ACKscumulativos

Ø 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çãoRTT_estimado = (1-αααα)* RTT_estimado + x*RTT_amostra

Ø média corrente exponencialmente ponderadaØ influência de cada amostra diminui exponencialmente com o tempo

Ø valor típico de α : 0.125

Escolhendo o intervalo de temporizaçãoØ RTT_estimado mais uma “margem de segurança”Ø variação grande em RTT_estimado

-> margem de segurança maiorTemporização = RTT_estimado + 4*Desvio

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

valor típico de β : 0.25


Exemplo estimativa RTTRTT: 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: transferência confiável de dadosØ TCP cria serviço rdtsobre o serviço nãoconfiável IP

Ø Utiliza pipeline para enviar segmentos

Ø ACKS cumulativosØ TCP usa temporizadorpara retransmissão

Ø Retransmissões sãodisparadas por:

ü timeoutü Acks duplicados

Ø Inicialmente considere um TCP emissor simplificado:

ü ignore acks duplicadosü ignore controle de fluxoe controle de congestionamento;


Eventos doTCP emissor:Dados recebidos da aplic:Ø Cria o segmento com node seq X

Ø seq X é o número do primeiro byte do segmento

Ø Inicia o temporizadorse ele não foi iniciadoanteriormente

Ø Intervalo de expiração: TimeOutInterval

timeout:Ø Retransmite o segmento quecausou o timeout

Ø Reinicializa o temporizadorAck recebido:

Ø Se reconhece segmentos não reconhecidos anteriormente

ü Atualiza a informação sobrepacotes reconhedidos

ü Inicia o temporizador se existem ainda segmentosnão reconhecidos


TCP: transfe-rênciaconfiável de dados

00 sendbase = número de seqüência inicial01 nextseqnum = número de seqüência inicial

0203 loop (forever) {04 switch(event)

05 event: dados recebidos da aplicação acima06 cria segmento TCP com número de seqüência nextseqnum 07 inicia temporizador para segmento nextseqnum

08 passa segmento para IP 09 nextseqnum = nextseqnum + comprimento(dados) 10 event: expirado temporizador de segmento c/ no. de seqüência y

11 retransmite segmento com número de seqüência y 12 calcula novo intervalo de temporização para segmento y 13 reinicia temporizador para número de seqüência y 14 event: ACK recebido, com valor de campo ACK de y

15 se (y > sendbase) { /* ACK cumulativo de todos dados até y */ 16 cancela temporizadores p/ segmentos c/ nos. de seqüência < y 17 sendbase = y

18 } 19 senão { /* é ACK duplicado para segmento já reconhecido */ 20 incrementa número de ACKs duplicados recebidos para y

21 if (número de ACKs duplicados recebidos para y == 3) { 22 /* TCP: retransmissão rápida */ 23 reenvia segmento com número de seqüência y

24 reinicia temporizador para número de seqüência y 25 } 26 } /* fim de loop forever */

RemetenteTCPsimplificado


TCP: cenários de retransmissão

Estação A

Seq=92, 8 bytes de dados

ACK=100

perdatemporização

tempo cenário doACK perdido

Estação B

X


ACK=100

Host A


ACK=100

Temp.p/Seq=92

temporização prematura,ACKs cumulativos

Host B


ACK=120


Temp. p/Seq=100

ACK=120

tempo


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

Seq=92, 8 bytes data

ACK=100

loss

timeout

Cenário de ACK cumulativo

Host B

X

Seq=100, 20 bytes data

ACK=120

time


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


Fast Retransmit

Ø Período de timeout é geralmente longo:

ü Longo atraso até a retransmissão do segmento perdido

Ø Detectar segmentosperdidos via ACKsduplicados

ü Emissores geralmenteenviam váriossegmentos

ü Se um segmento é perdido, provavelmente vão ser recebidos ACKs duplicados

Ø Se o emissor recebe 3 ACKs para o mesmosegmento, supõe que o segemtno subseqüente foi perdido:

ü fast retransmit:retransmite o segmetno antes que o temporizador expire


evento: ACK recebido, com valor de ACK igual a y

if(y > SendBase) {

SendBase = y

if (existem segemtnos ainda não reconhecidos)

inicializa o temporizador

}

else {

incrementa o contador de ACKs duplicados para y

if (contador de ACKs duplicados para y = 3) {

retransmite o segmento com no seq y

}

Algoritmo Fast retransmit:

Um ACK duplicado para um segmento já reconhecido previamente

fast retransmit


remetente não esgotaria buffers do receptor portransmitir muito, oumuito rápidamente

controle de fluxo

TCP: Controle de Fluxo

Ø Lado receptor de umaconexão TCP tem um buffer de recepção:

Ø Processo da aplicaçãopode ser lento pararetirar os dados do buffer

Ø Serviço decompatibilização de velocidades: compatibilizara taxa de envio do emissorcom a taxa de recebimentodos dados da aplicação do receptor


Controle de Fluxo TCP: como funciona ?

(Suponha que o TCP receptor discarte pacotes fora de ordem)

= RcvWindow

= RcvBuffer-[LastByteRcvd -

LastByteRead]

Ø 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

ü Garante que não tenhaoverflow no buffer do receptor


TCP: Gerenciamento de Conexões

Lembrete: Remetente, receptor TCP estabelecem “conexão” antes de trocar segmentos de dados

Ø inicializam variáveis TCP:ü nos. de seq.ü buffers, info s/ controle de fluxo (p.ex. RcvWindow)

Ø cliente: iniciador de conexãoSocket clientSocket = new Socket("hostname","port

number");

Ø servidor: contactado por clienteSocket connectionSocket = welcomeSocket.accept();

Inicialização em 3 tempos:Passo 1: sistema cliente envia segmento de controle SYN do TCP ao servidor

ü especifica no. inicial de seqü sem dados

Passo 2: sistema servidor recebe SYN, responde com segmento de controle SYNACK

ü aloca buffersü especifica no. inicial de seq.

Passo 3: sistema cliente recebeSYNACK, responde com um segmento de ACK, que pode conter dados


TCP: Gerenciamento de Conexões (cont.)

Encerrando uma conexão:

cliente fecha soquete:clientSocket.close();

Passo 1: sistema cliente envia segmento de controle FIN ao servidor

Passo 2: servidor recebe FIN, responde com ACK. Encerra a conexão, enviando FIN.

cliente

FIN

servidor

ACK

ACK

FIN

fechar

fechar

fechada

espera

temporizada



Passo 3: cliente recebe FIN, responde com ACK.

ü Entre em “espera temporizada” -responderá com ACK a FINs recebidos

Step 4: servidor, recebe ACK. Conexão encerrada.

Note: com pequena modificação, consegue tratar de FINs simultâneos.

cliente

FIN

servidor

ACK

ACK

FIN

fechando

fechando

fechada

espera

temporizada

fechada



Ciclo de vidade cliente TCP

Ciclo de vidade servidor TCP


Princípios de Controle de CongestionamentoCongestionamento:Ø informalmente: “muitas fontes enviando muitos dados muito rapidamente para a rede poder tratar”

Ø diferente de controle de fluxo!Ø manifestações:

ü perda de pacotes (esgotamento de buffers emroteadores)

ü longos atrasos (enfileiramento nos buffers dosroteadores)

Ø um dos 10 problemas mais importantes em redes!


Causas/custos de congestionamento: cenário 1

Ø dois remetentes, dois receptores

Ø um roteador, buffers infinitos

Ø sem retransmissão

Ø grandes retardos qdo. congestionada

Ø vazão máxima alcançável



Ø Um roteador, buffers finitosØ retransmissão pelo remetente de pacote perdido

Buffer finito compatilhado

Host A λin : dados originais

Host B

λout

λ'in : dados originais, maisdados retransmitidos


Causas/custos de congestionamento: cenário 2Ø sempre: (“goodput”)

Ø retransmissão “perfeito” apenas quando perda:

Ø retransmissão de pacote atrasado (não perdido) faz maior(que o caso perfeito) para o mesmo

λin

λout

=

λin

λout

>

λin

λout

“custos” de congestionamento:Ø mais trabalho (retransmissão) para dado “goodput”Ø retransmissões desnecessárias: enviadas múltiplas cópias do pacote


Causas/custos de congestionamento: cenário 3Ø quatro remetentesØ caminhos com múltiplos enlacesØ temporização/retransmissão

λin

P: o que acontece à medida que e crescem ?

λin

Buffer finitocompartilhado

Host Aλin : dados originais

Host B

λout

λ'in : dados originais, maisdados retransmitidos



Outro “custo” de congestionamento:Ø quando pacote é descartado, qq. capacidade de transmissão já usada (antes do descarte) para esse pacote foi desperdiçado!

Ho

st A

Ho

st B

λou

t


Abordagens de controle de congestionamento

Controle de congestionamento fim a fim :

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

Ø congestionamento inferido das perdas, retardo observados pelo sistema terminal

Ø abordagem usada pelo TCP

Controle de congestionamento com apoio da rede:

Ø roteadores realimentam os sistemas terminais

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

ü taxa explícita p/ envio pelo remetente

Duas abordagens amplas para controle de congestionamento:


Estudo de caso: controle de congestionamento no ABR da ATM

ABR: available bit rate:Ø “serviço elástico” Ø se caminho do remetente “sub-carregado”:

ü remetente deveria usar banda disponível

Ø se caminho do remetente congestionado:

ü remetente reduzido à taxa mínima garantida

células RM (resource management):

Ø enviadas pelo remetente, intercaladas com células de dados

Ø bits na célula RM iniciados por comutadores (“apoio da rede”)

ü bit NI: não aumente a taxa (congestionamento moderado)

ü bit CI: indicação de congestionamento

Ø células RM devolvidos ao remetente pelo receptor, sem alteração dos bits


Estudo de caso: controle de congestionamento em ABR da ATM

Ø Campo ER (explicit rate) de 2 bytes na célula RMü comutador congestionado pode diminuir valor ER na célulaü taxa do remetente assim ajustada p/ menor valor possível entre os comutadores do caminho

Ø bit EFCI em células de dados ligado por comutador congestionadoü se EFCI ligado na célula de dados antes da célula RM, receptor liga bit CI na célula RM devolvida


TCP: Controle de Congestionamento

Ø controle fim a fim (sem apoio da rede)

Ø taxa de transmissão limitada pela tamanho da janela de congestionamento:LastByteSent-LastByteAcked

≤≤≤≤ CongWin

Ø CongWin é dinâmica, e é funçãodo congestionamento na rede;

Como TCP detectacongestionamento?

Ø Evento de perda = timeout ou 3 acks duplicados

Ø TCP emissor reduz taxa de transmissão (CongWin)depois de um evento de perda

Três mecanismos:ü AIMDü slow startü conservative after timeout events



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

throughput = w * MSSRTT Bytes/sec

Congwin



Ø 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é perder pacotes (congestionamento)

ü perdas: diminui Congwin, depois volta a à sondagem (aumento) novamente


TCP AIMD

8 Kbytes

16 Kbytes

24 Kbytes

time

congestion

window

multiplicative decrease (decréscimo multiplicativo:reduz CongWin pela metadedepois de um evento de perda

additive increase (crescimento aditivo):aumenta CongWin de 1 MSS a cada RTT naausência de um eventode perda: probing

Conexão TCP de longa duração


TCP: Partida lenta (Slow Start)

Ø Quando a conexãocomeça, CongWin = 1 MSS

ü Exemplo: MSS = 500 bytes & RTT = 200 msec

ü Taxa inicial = 20 kbps

Ø A banda disponível deveser >> MSS/RTT

Ø Quando a conexãocomeça, aumenta a taxaexponencialmente até o primeiro evento de perda

Ø Resumo: taxa inicial baixa, mais cresce rapidamente(crescimento exponencial)


TCP: Partida lenta (slow start)

Ø Quando a conexão começa, aumenta a taxaexponencialmente até que ococra uma perda

ü Dobra CongWin a cadaRTT, através do incremento de CongWin, a cada ACK recebido

inicializa: Congwin = 1for (cada segmento c/ ACK)

Congwin++until (evento de perda OR

CongWin > threshold)

Estação A

um segmento

RTT

Estação B

tempo

dois segmentos

quqtro segmentos

Algoritmo Partida Lenta


Refinamento

Ø Depois de 3 DupACKs:ü CongWin é reduzida a metade

ü Janela cresce linearmenteØ Mas depois de um evento de timeout:ü CongWin é reduzida a 1 MSS;

ü Janela cresce exponencialmente até o valor do threshold, e depois cresce linearmente

� o recebimento de 3 ACKs duplicados indica que a rede tem condição de transmitir algunssegmentos�Ocorrência de timeout antes de 3 ACKs duplicados é “mais alarmante”

Filosofia:


Refinamento (mais)Q: Quando o crescimento devemudar de exponencial paralinear ?

A: Quando CongWinatinge 1/2 do seuvalor antes do timeout.

Implementação:Ø Threshold variávelØ Quando ocorre uma perda, faz-se Threshold = CongWin/2

0

2

4

6

8

10

12

14

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

Transmission round

co

ng

est

ion

win

do

w s

ize

(se

gm

en

ts)

Series1 Series2

threshold

TCP Tahoe

TCP Reno


TCP: Prevenção do Congestionamento(congestion Avoidance

/* partida lenta acabou */ /* Congwin > threshold */

Until (event de perda) {cada w segmentos

reconhecidos:Congwin++

}

threshold = Congwin/2Congwin = 1

faça partida lenta 1

1: TCP Reno pula partida lenta (recuperaçãorápida) depois de três ACKs duplicados

prevenção congestionamento


Resumo: Controle de CongestionamentoØ Quando CongWin está abaixo do Threshold, o emissor está na fase de slow-start, e a janelacresce exponencialmente

Ø Quando CongWin está acima do Threshold, o emissor está na fase de congestion-avoidance, e a janela cresce linearmente

Ø Quando são recebidos três ACK duplicados, faz-se Threshold = CongWin/2 e CongWin = Threshold.

Ø Quando ocorre um timeout, faz-se Threshold =CongWin/2 e CongWin = 1 MSS.


Meta de eqüidade: se N sessões TCP compartilham o mesmo enlace de gargalo, cada uma deve ganhar 1/N da capacidade do enlace

Eqüidade TCP

TCP conexão 1

Roteadorgargalo

capacidade R

TCP conexão 2


Por quê TCP é justo?Duas sessões concorrentes:Ø Aumento aditivo dá gradiente de 1, enquanto vazão aumentaØ decrementa multiplicativa diminui vazão proporcionalmente

R

R

compartilhamento igual da banda

Vazão da conexão 1

Vaz ãodaconexão 2

evitar congestionamento: aumento aditivoperda: diminui janela por fator de 2




R

R



Vaz ãodaconexão 2





R

R



Vaz ãodaconexão 2





R

R



Vaz ãodaconexão 2





R

R



Vaz ãodaconexão 2





R

R



Vaz ãodaconexão 2





R

R



Vaz ãodaconexão 2





R

R



Vaz ãodaconexão 2




Eqüidade (mais)Eqüidade e UDPØ Aplic. Multimídiageralmente não usamTCP

ü Não desejam que a taxaseja reduzida pelocontrole de congestionamento

Ø Geralmente usam UDP:ü audio/video a taxaconstante, toleramperdas de pacotes

Ø Área de pesquisa: TCP friendly

Eqüidade e conexões TCP paralelas

Ø Nada previne que aplic. abram várias conexõessimultânceas entre os 2 hosts;

Ø Wrowsers fazem isto Ø Exemplo: enlace com taxa igual a R, com 9 conexões;

ü Nova aplic. requer umaconexão TCP, recebe R/10 da taxa

ü Nova aplic. requer 11 conexões TCP, recebe R/2 da taxa


TCP: modelagem de latência

P: Quanto tempo custa para receber um objeto de um servidor WWW depois de enviar o pedido?

Ignorando o congestionamento, a latência é influenciada por:

Ø Estabelecimento de conexão TCPØ retardo de transferência de dadosØ Slow start

Notação, suposições:Ø Supomos um enlace entre cliente e

servidor de taxa RØ Supomos: janela de congestionamento

fixo, W segmentosØ S: MSS (bits)Ø O: tamanho do objeto (bits)Ø sem retransmissões (sem perdas, sem

erros)

Tamanho da janela:Ø Assume-se: janela de transmissão fixa, igual a w segmentos;

Ø Depois janelas dinâmicas,modelando slow start


Janela de congestionamento de tamanho fixo (1)

Primeiro caso:WS/R > RTT + S/R: ACK doprimeiro segmento na janela chega antes deenviar todos dados na janela

latência = 2RTT + O/R


Janela de congestionamento de tamanho fixo (2)

Segundo caso:Ø WS/R < RTT + S/R: aguarda ACK depois deenviar todos os dados na janela

latência = 2RTT + O/R+ (K-1)[S/R + RTT - WS/R]


TCP: modelagem de latência: Slow Start(1)Ø Agora supomos que a janela cresce de acordo com o algoritmo de Slow Start.

Ø Mostramos que a latência de um objeto de tamanho O é:

Onde:- P é o número de vezes TCP para no servidor:

}1,{min −= KQP

- onde Q é o número de vezes que o servidor parariase o objeto fosse de tamanho infinito.

- e K é o número de janelas que cobrem o objeto.

R

S

R

SRTTP

R

ORTTLatência

P )12(2 −−

+++=


TCP: modelagem de latência: Slow Start(2)

RTT

initiate TCPconnection

request

objectfirst window

= S/R

second window

= 2S/R

third window

= 4S/R

fourth window= 8S/R

complete

transmissionobjectdelivered

time at

client

time atserver

Exemplo:• O/S = 15 segmentos• K = 4 janelas• Q = 2• P = min{K-1,Q} = 2

Servidor para P=2 vezes

Componentes da Latência:

• 2 RTT for connection estab and request

• O/R to transmit object

• time server idles due to slow start

Servidor para: P = min{K-1,Q} vezes


TCP: modelagem de latência: (3)

R

S

R

SRTTPRTT

R

O

R

SRTT

R

SRTT

R

O

TempoBloqueioRTTR

O

P

kP

k

P

p

p

)12(][2

]2[2

2latencia

1

1

1

−−+++=

−+++=

++=

−

=

=

∑

∑

tempo de bloqueio após a

k-ésima janela2

1

R

SRTT

R

S k =

−+

+

−

até quando o servidor recebe reconhecimento

tempo quando o servidor inicia o envio do segmento=+ RTTR

S

tempo para enviar a k-ésima janela21 =−

R

Sk

RTT

iniciaconexão TCP

pedeobjeto

primeira janela= S/R

segunda janela= 2S/R

terceira janela= 4S/R

quarta janela= 8S/R

transmissão

completaobjetoentregue

tempo no

cliente

tempo no

servidor


+=

+≥=

≥−=

≥+++=

≥+++=−

−

)1(log

)}1(log:{min

}12:{min

}/222:{min

}222:{min

2

2

110

110

S

O

S

Okk

S

Ok

SOk

OSSSkK

k

k

k

L

L

O cálculo do número Q, de inatividade por objeto de tamanho infinito,é similar (veja HW).

Lembre que K = número de janelas que cobrem um objetoComo calculamos o valor de K?

TCP modelagem de latência: partida lenta (4)


Modelagem HTTPØ Assuma que páginas Web consistem de:

ü 1 página HTML base (com tamanho igual a O bits)ü M imagens (cada uma com O bits)

Ø HTTP não-persistente : ü M+1 conexões TCP em sérieü Tempo de resposta = (M+1)O/R + (M+1)2RTT + soma dosperíodos de inatividade

Ø HTTP persistente :ü 2 RTT para requisitar e receber o arquivo base HTMLü 1 RTT para requisitar e receber M imagensü Tempo de resposta = (M+1)O/R + 3RTT + soma dos períodos deinatividade

Ø HTTP não-persistente com X conexões paralelasü 1 TCP conexão para o arquivo baseü M/X conjuntos de conexões paralelas para as imagensü Tempo de resposta = (M+1)O/R + (M/X + 1)2RTT + soma dos períodos de inatividade


0

2

4

6

8

10

12

14

16

18

20

28

Kbps

100

Kbps

1

Mbps

10

Mbps

HTTP: tempo de resposta (em segundos)RTT = 100 msec, O = 5 Kbytes, M=10 e X=5

Para redes com valores de banda baixos, o tempo de conexão e resposta e domindado pelo tempo de transmissão

Conexões persistentes não apresentam melhora significativa em relação a conexões paralelas

não-persistente

persistente

paralela não-

persistente


0

10

20

30

40

50

60

70

28

Kbps

100

Kbps

1

Mbps

10

Mbps

não-persistente

persistente

paralela não-

persistente

HTTP: tempo de resposta (em segundos)RTT =1 seg, O = 5 Kbytes, M=10 e X=5

Para valores grandes de RTT, o tempo de resposta é dominado pelo atraso do estabelecimento da conexão e slow start. Conexões persistentes possibilita uma melhora importante para a redução do atraso: particularmente em redes com grandes valores de atrasoXbanda (delay•bandwidth)


Capítulo 3: Resumo

Ø Princípios atrás dos serviços da camada de transporte:

ü multiplexação/demultiplexação

ü transferência confiável de dadosü controle de fluxoü controle de congestionamento

Ø instanciação e implementação na Internet

ü UDPü TCP

Próximo capítulo:Ø saímos da “borda” da rede (camadas de aplicação e transporte)

Ø entramos no “núcleo”da rede

Documents

Capítulo 3: Camada de Transporte - ic.unicamp.brnfonseca/arquivos/cap3.pdf · emissor: fragmentaa mensagem da aplicação em ... porta remetente portareceptor 32 bits dados da aplicação