Capítulo 3: Camada de Transporte - Início - …michael/RedeComp-grad/cap3.pdf3: Camada de Transporte 3-13 Rdt1.0: transferência confiável usando um canal confiável canal subjacente

3: Camada de Transporte 3-1

Capítulo 3: Camada de TransporteMetas do capítulo:❒ compreender os

princípios atrás dosserviços da camada detransporte:

❍ multiplexação/desmultiplexação

❍ transferência confiávelde dados

❍ controle de fluxo❍ controle de

congestionamento❒ instanciação e

implementação naInternet

Sumário do Capítulo:❒ serviços da camada de transporte❒ multiplexação/desmultiplexaçã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

❒ principles de controle decongestionamento

❒ controle de congestionamento em TCP


Serviços e protocolos de transporte

❒ provê comunicação lógicaentre processos de aplicaçãoexecutando em hospedeirosdiferentes

❒ protocolos de transporteexecutam em sistemasterminais

❒ serviços das camadas detransporte X rede:

❒ camada de rede : dadostransferidos entre sistemas

❒ camada de transporte: dadostransferidos entre processos

❍ depende de, estende serviçosda camada de rede

aplicaçãotransporte

redeenlacefísica

redeenlacefísica


redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

transporte lógico fim a fim


Protocolos da camada de transporte

Serviços de transporte naInternet:

❒ entrega confiável, ordenada,ponto a ponto (TCP)

❍ congestionamento❍ controle de fluxo❍ estabelecimento de conexão

(setup)❒ entrega não confiável,

(“melhor esforço”), nãoordenada, ponto a ponto oumultiponto: UDP

❒ serviços não disponíveis:❍ tempo-real❍ garantias de banda❍ multiponto confiável


redeenlacefísica

redeenlacefísica


redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

redeenlacefísica

transporte lógico fim a fim



rede

M P2aplicação

transporterede

Multiplexação/desmultiplexaçãoLembrança: segmento -

unidade de dados trocadaentre entidades da camadade transporte

❍ = TPDU: transportprotocol data unit

receptor

HtHn

Desmultiplexação: entrega de segmentos recebidos para os processos da camada de apl corretos

segmento

segmento Maplicação

transporterede

P1M

M MP3 P4

cabeçalhode segmento

dados da camadade aplicação


Multiplexação/desmultiplexação

multiplexação/desmultiplexação:❒ baseadas em números de porta

e endereços IP de remetente ereceptor

❍ números de porta deremetente/receptor emcada segmento

❍ lembrete: número de portabem conhecido paraaplicações específicas

juntar dados de múltiplosprocessos de apl, envelopandodados com cabeçalho (usado depois para desmultiplexação)

porta remetente porta receptor

32 bits

dados daaplicação

(mensagem)

outros campos do cabeçalho

formato de segmento TCP/UDP

Multiplexação:


Multiplexação/desmultiplexação: exemplos

estação A

servidor B

porta orig.: xporta dest: 23

porta orig:23porta dest: x

uso de portas: apl. simples de telnet

cliente WWWestação A

servidor WWW B

IP orig: CIP dest: B

porta orig: xporta dest: 80

IP orig : CIP dest: B

porta orig: yporta dest: 80

uso de portas : servidor WWW

IP orig: AIP dest: B

porta orig: xporta dest: 80


UDP: User Datagram Protocol [RFC 768]

❒ Protocolo de transporte daInternet mínimo, “semfrescura”,

❒ 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 entreremetente, receptor

❍ tratamento independentede cada segmento UDP

Por quê existe um UDP?❒ elimina estabelecimento de

conexão (o que pode causarretardo)

❒ simples: não se mantém“estado” da conexão noremetente/receptor

❒ pequeno cabeçalho desegmento

❒ sem controle decongestionamento: UDPpode transmitir o maisrá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 comUDP: incluir confiabilidade nacamada de aplicação

❍ recuperação de erroespecí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 sequênciade inteiros de 16-bits

❒ campo checksum zerado❒ checksum: soma (adição

usando complemento de 1)do conteúdo do segmento

❒ remetente colocacomplemento do valor dasoma no campo checksumde UDP

Receiver:❒ computa checksum do

segmento recebido❒ verifica se checksum

computado é zero:❍ NÃO - erro detectado❍ SIM - nenhum erro

detectado. Mas aindapode ter erros? Vejadepois ….

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


Princípios de Transferência confiável dedados (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çarrdt_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

rdt_rcv(): chamada quandopacote chega chega no lado

receptor do canal

deliver_data(): chamadapor rdt p/ entregar dados

p/ camada superior


Transferência confiável de dados (rdt):como começarIremos:❒ desenvolver incrementalmente os lados

remetente, receptor do protocolo RDT❒ considerar apenas fluxo unidirecional

❍ mas info de controle flui em ambos sentidos!❒ Usar máquinas de estados finitos (FSM) p/

especificar remetente, receptor

state1

state2

event causing state transitionactions taken on state transition

: “ ”o é


Rdt1.0: transferência confiável usando um canalconfiá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 ❍ remetente retransmite pacote ao receber um NAK❍ cenários humanos usando ACKs, NAKs?

❒ novos mecanismos em rdt2.0 (além do rdt1.0):❍ deteção de erros❍ realimentação pelo receptor: msgs de controle (ACK,NAK)

receptor->remetente


rdt2.0: especificação da FSM


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


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

3: 3-18

rdt2.0 tem uma falha fatal!O que acontece se

ACK/NAK com erro?❒ não o que

❒ se :

de pacotes duplicados

O que fazer?❒ /

p/ ACK/NAK do receptor?

?❒ , mas

retransmissão de certo!

Lidando c/ duplicação:❒ número de

sequência p/ cada pacote❒

❒ (não)

,e

e


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 recebidotinha erro

❒ duplicou o no. deestados

❍ estado deve “lembrar”se pacote “corrente”tem no. de seq. 0 or 1

Receptor:❒ deve checar se pacote

recebido é duplicado❍ estado indica se no. de

seq. esperado é 0 or 1❒ note: receptor não tem

como saber se últimoACK/NAK foi recebidobem pelo remetente


rdt2.2: um protocol sem NAKs

❒ mesma funcionalidadeque rdt2.1, só com ACKs

❒ ao invés de NAK,receptor envia ACK p/último pacote recebidobem

❍ receptor deve incluirexplicitamente no. de seqdo pacote reconhecido

❒ ACK duplicado noremetente resulta namesma ação que o NAK:retransmite pacote atual

!


rdt3.0: canais com erros e perdas

Nova suposição: canalsubjacente tambémpode perder pacotes(dados ou ACKs)

❍ checksum, no. de seq.,ACKs, retransmissõespodem ajudar, mas nãoserão suficientes

P: como lidar com perdas?❍ remetente espera até ter

certeza que se perdeupacote ou ACK, e entãoretransmite

❍ eca!: desvantagens?

Abordagem: remetenteaguarda um tempo“razoável” pelo ACK

❒ retransmite e nenhum ACKrecebido neste intervalo

❒ se pacote (ou ACK) apenasatrasado (e não perdido):

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

❍ receptor deve especificarno. de seq do pacote sendoreconhecido

❒ requer temporizador3: Camada de Transporte 3-24

rdt3.0: remetente


rdt3.0 em ação

3: 3-26

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:

Ttransmitir=8kb/pacote10**9 b/seg = 8 microseg

Utilização = U = = 8 microseg30.016 mseg

fração do temporemetente ocupado = 0,00015

❍ pac. de 1KB a cada 30 mseg -> vazão de 33kB/seg num enlacede 1 Gbps

❍ protocolo limita uso dos recursos físicos!


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


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 janela3: Camada de Transporte 3-30

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 ospacotes recebidos corretamente

❍ armazena pacotes no buffer, conforme precisa, paraposterior entrega em-ordem à camada superior

❒ remetente apenas re-envia pacotes para os quaisACK 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: de


Retransmissão seletiva

dados de cima:❒ se próx. no. de seq na

janela, envia pacotetimeout(n):❒ reenvia pacote n, reiniciar

temporizadorACK(n) em

[sendbase,sendbase+N]:

❒ marca pacote n “recebido”❒ se n for menor pacote não

reconhecido, avança baseda janela ao próx. no. deseq não reconhecido

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

❒ envia ACK(n)❒ fora de ordem: buffer❒ em ordem: entrega (tb.

entrega pacotes em ordemno buffer), avança janelap/ próxima pacote aindanão recebido

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

❒ ACK(n)senão:❒ ignora

receptorremetente


Retransmissão seletiva em ação


Retransmissãoseletiva: dilemaExemplo:❒ nos. de seq : 0, 1, 2, 3❒ tam. de janela =3

❒ receptor não vêdiferença entre osdois cenários!

❒ incorretamente passadados duplicados comonovos em (a)

Q: qual a relação entretamanho 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 mesmaconexão

❍ MSS: tamanho máximo desegmento

❒ orientado a conexão:❍ handshaking (troca de

msgs de controle) iniciaestado de remetente,receptor antes de trocardados

❒ 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 porcontrole de fluxo econgestionamento do TCP

❒ buffers de envio e recepçãosocketdoor

TCPsend buffer

TCPreceive buffer

socketdoor

segment


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 receptorptr dados urg.checksum

FSRPAUtam.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)

de

(não !)

(como UDP)


TCP: nos. de seq. e ACKsNos. de seq.:

❍ “número”dentro dofluxo de bytes doprimeiro byte dedados do segmento

ACKs:❍ no. de seq do próx.

byte esperado dooutro lado

❍ ACK cumulativoP: como receptor trata

segmentos fora daordem?

❍ R: espec do TCPomissa - deixado aoimplementador

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 reconhecechegada

do ‘C’ecoado

B reconhecechegada de

‘C’, ecoa‘C’ de volta

tempocenário simples de telnet


TCP: transferência confiável de dados

remetente simplificado,supondo:

waitfor

event

waitfor

event

event: data received from application above

timer timeout for # y

create, send segment

retransmit segment

ACK processing

•fluxo de dados uni-direcional•sem controle de fluxo,congestionamento


TCP:transfer-ênciaconfiávelde dados

00 sendbase = número de seqüência inicial01 nextseqnum = número de seqüência inicial0203 loop (forever) { 04 switch(event) 05 event: dados recebidos da aplicação acima

de seqüência nextseqnum inicia temporizador para segmento nextseqnum

IP = + ( )

expirado temporizador y retransmite segmento de y

de temporização para segmento y reinicia temporizador para número de y

15 se (y > até16 nos

18 } para segmento já reconhecido

para y 21 if (número de ACKs duplicados recebidos para y == 3) { 22 /* TCP: retransmissão */ 23 de y 24 reinicia temporizador para número de y 25 }

fim de loop forever */

RemetenteTCPsimplificado


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

Evento

chegada de segmento em ordemsem lacunas,anteriores já reconhecidos

chegada de segmento em ordemsem lacunas,um ACK retardado pendente

chegada de segmento fora de ordem, com no. de seq. maiorque esperado -> lacuna

chegada de segmento que preenche a lacuna parcial oucompletamente

Ação do receptor TCP

ACK retardado. Espera até 500msp/ próx. segmento. Se não chegarsegmento, envia ACK

envia imediatamente um únicoACK cumulativo

envia ACK duplicado, indicando no. de seq.do próximo byte esperado

ACK imediato se segmento noinício da lacuna


TCP: cenários de retransmissão

Estação A

Seq=92, 8 bytes de dados

ACK=100

perdatem

pori

zaçã

o

tempo cenário doACK perdido

Estação B

X


ACK=100

Host A


ACK=100

Tem

p.p/

Seq

=92

temporização prematura,ACKs cumulativos

Host B


ACK=120


Tem

p. p

/ Se

q=10

0

ACK=120

tempo


remetente não esgotaria buffers do receptor por

transmitir muito, ou muito rápidamente

controle de fluxo

TCP: Controle de Fluxoreceptor: explicitamente

avisa o remetente daquantidade de espaçolivre disponível (mudadinamicamente)

❍ campo RcvWindowno segmento TCP

remetente: mantém aquantidade de dadostransmitidos, porémainda não reconhecidos,menor que o valor maisrecente de RcvWindow

buffering pelo receptor

RcvBuffer = tamanho do Buffer de recepção

RcvWindow = espaço vazio no Buffer


TCP: Tempo de Resposta (RTT) eTemporizaçã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 desegmentos

P: como estimar RTT?❒ RTTamostra: tempo medido

entre a transmissão do segmentoe o recebimento do ACK

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

❒ média corrente exponencialmente ponderada❒ influência de cada amostra diminui exponencialmente

com o tempo❒ valor típico de x: 0.1

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-x)* Desvio + x*|RTT_amostra - RTT_estimado|


TCP: Gerenciamento de Conexões

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

❒ inicializam variáveis TCP:❍ nos. de seq.❍ buffers, info s/ controle

de fluxo (p.ex. RcvWindow)❒ cliente: iniciador de conexão Socket clientSocket = new

Socket("hostname","portnumber");

❒ servidor: contactado porcliente

Socket connectionSocket =welcomeSocket.accept();

Inicialização em 3 tempos:Passo 1: sistema cliente envia

segmento de controle SYN do TCP

❍ especifica no. inicial de seq

Passo 2: sistema servidor recebeSYN, responde com segmento decontrole SYNACK

❍ reconhece SYN recebido❍ aloca buffers❍ especifica no. inicial de seq.

servidor-> receptor


TCP: Gerenciamento de Conexões ( .)

Encerrando uma conexão:cliente fecha soquete:

clientSocket.close();

Passo 1: sistema cliente enviasegmento de controle FIN aoservidor

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

cliente

FIN

servidor

ACK

ACK

FIN

fechar

fechar

fechada

espe

ra

tem

pori

zada


TCP: Gerenciamento de Conexões ( .)

Passo 3: cliente recebe FIN,responde com ACK.

❍ Entre em “esperatemporizada” -responderá com ACK aFINs recebidos

Step 4: servidor, recebeACK. Conexão encerrada.

Note: com pequenamodificação, conseguetratar de FINssimultâneos.

cliente

FIN

servidor

ACK

ACK

FIN

fechando

fechando

fechada

espe

rate

mpo

riza

da

fechada


TCP Connection Management (cont)

Ciclo de vidade cliente TCP

Ciclo de vidade servidor TCP


Princípios de Controle deCongestionamentoCongestionamento:❒ informalmente: “muitas fontes enviando muitos

dados muito rapidamente para a rede podertratar”

❒ differente de controle de fluxo!❒ manifestações:

❍ perda de pacotes (esgotamento de buffers em

❍ longos atrasos (enfileiramento nos buffers dos

❒ um dos 10 problemas mais importantes em redes!


Causas/custos de congestionamento:

❒ dois remetentes,dois receptores

❒ um roteador,buffers infinitos

❒ semretransmissão

❒ grandesretardos qdo.congestionada

❒ vazão máximaalcançável


Causas/custos de congestionamento:cenário 2

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



❒ 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 (retransmissão) “ ”❒ retransmissões desnecessárias: enviadas múltiplas cópias do pacote



❒ quatro remetentes❒ caminhos com múltiplos enlaces❒ temporização/retransmissão

λin

Q: what happens asand increase ?λ

in



Outro “custo” de congestionamento:❒ quando pacote descartado, qq. capacidade de

transmissão já usada (antes do descarte) para essepacote foi desperdiçado!


Abordagens de controle de congestionamento

Controle decongestionamentofim a fim :

❒ não tem realimentaçãoexplícita pela rede

❒ congestionamento inferidodas perdas, retardoobservados pelo sistematerminal

❒ abordagem usada por TCP

Controle decongestionamentocom apoio da rede:

❒ roteadores realimentam osnais

❍ bit único indicandocongestionamento(SNA, DECbit, TCP/IPECN, ATM)

❍ taxa explícita p/ enviopelo remetente

Duas abordagens amplas para controle decongestionamento:


Estudo de caso: controle decongestionamento em 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 (resourcemanagement):

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

❒ bits na célula RM iniciados porapoio da rede”)

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

❍ bit CI: indicação decongestionamento

❒ células RM devolvidos aoremetente pelo receptor, semalteração dos bits


Estudo de caso: controle decongestionamento 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

❍ se EFCI ligado na célula de dados antes da célula RM, receptorliga 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, Congwin:

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

throughput = w * MSS

RTT Bytes/sec

Congwin


TCP: Controle de Congestionamento

❒ duas “fases”❍ partida lenta❍ evitar

congestionamento❒ variáveis importantes:

❍ Congwin

❍ threshold: definelimiar entre fases departida lenta, controlede congestionamento

❒ “sondagem” para bandautilizável:

❍ idealmente: transmitir omais rápido possível(Congwin o máximopossível) sem perderpacotes

❍ aumentar Congwin atéperder pacotes(congestionamento)

❍ perdas: diminuiCongwin, depois volta aà sondagem (aumento)novamente


TCP: Partida lenta

❒ aumento exponencial (porRTT) no tamanho da janela(não muito lenta!)

❒ evento de perda:temporizador (Tahoe TCP)e/ou três ACKs duplicados(Reno TCP)

initializa: 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


TCP: Evitar Congestionamento

/* partida lenta acabou *//* Congwin > threshold */Until (event de perda) { cada w segmentosreconhecidos: Congwin++ }threshold = Congwin/2Congwin = 1faça partida lenta

1

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

Evitar congestionamento


Justeza do TCPMeta de justeza: se N sessões

TCP compartilham o mesmoenlace de gargalo, cada umadeve ganhar 1/N dacapacidade do enlace

TCP congestionavoidance:

❒ AADM: aumentoaditivo, decrementomultiplicativo

❍ aumenta janela em 1por cada RTT

❍ diminui janela porfator de 2 numevento de perda

AADM

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

1

Va

zã

o d

a c

on

ex

ão

2

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

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


TCP: modelagem de latência

P: Quanto tempo custa parareceber um objeto de umservidor WWW depois deenviar o pedido?

❒ Estabelecimento de conexãoTCP

❒ retardo de transferência dedados

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

servidor de taxa R❒ Supomos: janela de

congestionamento fixo, Wsegmentos

❒ S: MSS (bits)❒ O: tamanho do objeto (bits)❒ sem retransmissões (sem perdas,

sem erros)Dois casos a considerar:❒ WS/R > RTT + S/R: ACK do primeiro segmento na janela

chega antes de enviar todos dados na janela❒ WS/R < RTT + S/R: aguarda ACK depois de enviar todos

os dados na janela3: Camada de Transporte 3-68

TCP: modelagem de latência

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

K:= O/WS


TCP: modelagem de latência: partida lenta❒ Agora supomos que a janela cresce à la❒ Mostramos que a latência de um objeto de tamanho O é:

RS

RS

RTTPRO

RTTLatency P )12(2 −−

+++=

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

}1,{min −= KQP

- onde Q é o número de vezes que o servidor pararia se o objeto for de tamanho infinito.

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


TCP: modelagem de latência: partida lenta (cont.)

RTT

initiate TCPconnection

requestobject

first window= S/R

second window= 2S/R

third window= 4S/R

fourth window= 8S/R

completetransmissionobject

delivered

time atclient

time atserver

Exemplo:

O/S = 15 segmentos

K = 4 janelas

Q = 2

P = mín{K-1,Q} = 2

Servidor para P=2 vezes.


TCP: modelagem de latência: partida lenta (cont.)

RS

RS

RTTPRTTRO

RSRTT

RSRTT

RO

stallTimeRTTRO

P

kP

k

P

pp

)12(][2

]2[2

2latency

1

1

1

−−+++=

−+++=

++=

−

=

=

∑

∑

windowth after the timestall 21

kRS

RTTRS k

=

−+

+−

ementacknowledg receivesserver until

segment send tostartsserver whenfrom time=+ RTTRS

window kth the transmit totime21

=−

RSk

RTT

initiate TCPconnection

requestobject

first window= S/R

second window= 2S/R

third window= 4S/R

fourth window= 8S/R

completetransmissionobject

delivered

time atclient

time atserver


Capítulo 3: Sumário

❒ Princípios atrás dosserviços da camada detransporte:

❍ multiplexação/desmultiplexação

❍ transferência confiável dedados

❍ controle de fluxo❍ controle de congestionamento

❒ instanciação e implementação na

❍ UDP❍ TCP

Próximo capítulo:❒ saímos da “borda” da

rede (camadas deaplicação e transporte)

❒ entramos no “núcleo”darede

Documents

Capítulo 3: Camada de Transporte - Início - …michael/RedeComp-grad/cap3.pdf3: Camada de Transporte 3-13 Rdt1.0: transferência confiável usando um canal confiável canal subjacente