Captulo 3 Camada de Transporte Metas do captulo

Capítulo 3: Camada de Transporte Metas do capítulo: Resumo do Capítulo: Ø compreender os princípios Ø serviços da camada de transporte 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 protocolos de transporte ü ü UDP TCP Ø 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 3: Camada de Transporte 1

Serviços e protocolos de transporte Ø provê comunicação lógica aplicação transporte rede enlace física tr rede enlace física po s an rede enlace física e rt o ic g ló m fi a rede enlace física m fi 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 envia para a camada de rede; ü receptor: rearranja os segmentos em mesnagens e 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ção transporte rede enlace física 3: Camada de Transporte 2

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

Multiplexação/demultiplexação Multiplexação no emissor: juntar dados de múltiplos processos de apl, envelopando dados com cabeçalho (usado depois para demultiplexação) Demultiplexação no receptor: entrega de segmentos recebidos para os processos da camada de apl corretos = socket aplicação transporte rede = processo P 3 P 1 aplicação transporte P 2 P 4 aplicação transporte rede enlace física host 1 host 2 host 3 3: Camada de Transporte 4

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 origem e 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 para direcionar o segmento para o socket apropriado; ü 32 bits porta remetente porta receptor outros campos do cabeçalho dados da aplicação (mensagem) formato de segmento TCP/UDP 3: Camada de Transporte 5

Demultiplexação não orientada a conexão Ø Cria sockets com os números de porta Datagram. Socket my. Socket 1 = new Datagram. Socket(99111); Datagram. Socket my. Socket 2 = new Datagram. Socket(99222); Ø Socket UDP identificado pela 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úmero da porta; Ø Datagramas IP com diferentes endereços IP de origem e/ou números de porta de origem são direcionados para o mesmo socket 3: Camada de Transporte 6

Demultiplexação não orientada a conexão (cont) Datagram. Socket server. Socket = new Datagram. Socket(6428); P 3 SP: 6428 DP: 9157 SP: 6428 DP: 5775 SP: 9157 client IP: A P 1 P 3 DP: 6428 server IP: C SP: 5775 DP: 6428 Client IP: B SP provê “endereço de retorno” 3: Camada de Transporte 7

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últiplos sockets TCP simultaneamente: ü Cada socket é identificado por sua 4 -tupla Ø servidores Web tem diferentes sockets para cada cliente ü HTTP não persistente tem diferentes sockets para cada requisição 3: Camada de Transporte 8

Demultiplexação orientada a conexão (cont) P 3 SP: 80 DP: 9157 cliente IP: A SP: 9157 DP: 80 P 1 P 4 SP: 80 DP: 5775 servidor IP: C SP: 5775 DP: 80 cliente IP: B 3: Camada de Transporte 9

UDP: User Datagram Protocol Ø 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 [RFC 768] 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 3: Camada de Transporte 10

Mais sobre UDP Comprimento em bytes do segmento UDP, incluindo Ø muito utilizado para apls. de cabeçalho meios contínuos (voz, vídeo) ü ü tolerantes de perdas sensíveis à taxa de transmissão Ø outros usos de UDP (por 32 bits porta origem porta dest. comprimento checksum 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. ! ü Dados de aplicação (mensagem) UDP segment format 3: Camada de Transporte 11

Checksum UDP Meta: detecta “erro” (e. g. , bits invertidos) no segmento transmitido 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 checksum de UDP Receptor: Ø calcula checksum do segmento recebido Ø verifica se checksum computado é zero: ü NÃO - erro detectado ü SIM - nenhum erro detectado. Mas ainda pode ter erros? Veja depois …. 3: Camada de Transporte 12

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 complexidade de um protocolo de transferência confiável de dados (rdt) 3: Camada de Transporte 13

Transferência confiável de dados (rdt): como começar rdt_send(): chamada de cima, (p. ex. , pela apl. ). Dados recebidos p/ entregar à camada sup. do receptor send side udt_send(): chamada por rdt, p/ transferir pacote pelo canal ñ confiável ao receptor deliver_data(): chamada por rdt p/ entregar dados p/ camada superior receive side rdt_rcv(): chamada quando pacote chega no lado receptor do canal 3: Camada de Transporte 14

Transferência confiável de dados (rdt): como começar Etapas: Ø 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 evento causando transição de estados ações tomadas na transição de estado: neste “estado” o próximo estado é determinado unicamente pelo próximo evento estado 1 evento ações estado 2 3: Camada de Transporte 15

Rdt 1. 0: confiável transferência confiável usando um canal Ø 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 3: Camada de Transporte 16

Rdt 2. 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 rdt 2. 0 (em relação ao rdt 1. 0): ü ü deteção de erros realimentação pelo receptor: msgs de controle (ACK, NAK) receptor->remetente 3: Camada de Transporte 17

rdt 2. 0: especificação da FSM do remetente FSM do receptor 3: Camada de Transporte 18

rdt 2. 0: em ação (sem erros) FSM do remetente FSM do receptor 3: Camada de Transporte 19

rdt 2. 0: em ação (cenário de erro) FSM do remetente FSM do receptor 3: Camada de Transporte 20

rdt 2. 0 tem uma falha fatal! O que acontece se ACK/NAK com erro? Lidando c/ duplicação: Ø Remetente não sabe o que seqüência p/ cada pacote Ø remetente retransmite pacote atual se ACK/NAK recebido com erro Ø receptor descarta (não entrega) pacote duplicado passou no receptor! Ø não se pode apenas retransmitir: possibilidade de pacotes duplicados O que fazer? Ø remetente usa ACKs/NAKs p/ ACK/NAK do receptor? E se perder ACK/NAK do remetente? Ø retransmitir, mas pode causar retransmissão de pacote recebido certo! Ø remetente inclui número de para e espera Remetente envia um pacote, e então aguarda resposta do receptor 3: Camada de Transporte 21

rdt 2. 1: remetente, trata ACK/NAKs c/ erro 3: Camada de Transporte 22

rdt 2. 1: receptor, trata ACK/NAKs com erro 3: Camada de Transporte 23

rdt 2. 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 ü 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 estado deve “lembrar” se pacote “corrente” tem no. de seq. 0 ou 1 3: Camada de Transporte 24

rdt 2. 2: um protocolo sem NAKs FSM do remetente Ø mesma funcionalidade que rdt 2. 1, só com ACKs Ø ao invés de NAK, receptor envia ACK p/ último pacote recebido bem ü receptor deve incluir explicitamente no. de seq do pacote reconhecido ! Ø ACK duplicado no remetente resulta na mesma ação que o NAK: retransmite pacote atual 3: Camada de Transporte 25

rdt 3. 0: canais com erros e perdas Nova suposição: canal Abordagem: remetente subjacente também pode aguarda um tempo perder pacotes (dados “razoável” pelo ACK ou ACKs) Ø 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. como lidar com perdas? de seq. já cuida disto ü remetente espera até ter ü receptor deve especificar certeza que se perdeu no. de seq do pacote sendo pacote ou ACK, e então reconhecido retransmite Ø requer temporizador ü eca!: desvantagens? ü P: checksum, no. de seq. , ACKs, retransmissões podem ajudar, mas não serão suficientes 3: Camada de Transporte 26

rdt 3. 0: remetente 3: Camada de Transporte 27

rdt 3. 0 em ação 3: Camada de Transporte 28

rdt 3. 0 em ação 3: Camada de Transporte 29

Desempenho de rdt 3. 0 Ø rdt 3. 0 funciona, porém seu desempenho é muito ruim Ø exemplo: enlace de 1 Gbps, retardo fim a fim de 15 ms, pacote de 1 KB: Ttransmitir= L (tamanho do pacote - bits) = 8 kb/pkt = 8 microsec R (taxa de transmissão, bps) 10**9 b/sec U emissor= ü ü ü L/R . 008 = 30. 008 RTT + L / R = 0. 00027 microsegundos Utilização: fração do temporemetente ocupado pac. de 1 KB a cada 30 mseg -> vazão de 33 k. B/seg num enlace de 1 Gbps protocolo limita uso dos recursos físicos! 3: Camada de Transporte 30

rdt 3. 0: operação para e espera emissor receptor bit primeiro pacote transmitido, t = 0 último bit transmitido, t = L / R bit do primeiro pacote recebido último bit do pacote recebido, envia ACK RTT ACK recebido, envia próximo pacote, t = RTT + L/R U emissor= L/R . 008 = RTT + L / R 30. 008 = 0. 00027 microsegundos 3: Camada de Transporte 31

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

Pipelining: aumenta utilização emissor receptor bit primeiro pacote transmitido, t = 0 último bit transmitido, t = L / R primeiro bit do pacote recebido último bit recebido, envia ACK último bit do 2 o pacote recebido, envia ACK último bit do 3 o pacote recebido, envia ACK RTT ACK recebido, envia próximo pacote, t = RTT + L / R Aumenta a utilização de um fator de 3 U emissor= 3*L / R . 024 = 30. 008 RTT + L / R = 0. 0008 microsegundos 3: Camada de Transporte 33

Volta-N Remetente: Ø 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 3: Camada de Transporte 34

Volta-N: FSM estendida do remetente 3: Camada de Transporte 35

Volta-N: FSM estendida do 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 3: Camada de Transporte 36

Volta-N em ação 3: Camada de Transporte 37

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

Retransmissão seletiva: janelas de remetente, receptor 3: Camada de Transporte 39

Retransmissão seletiva remetente 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 receptor 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 3: Camada de Transporte 40

Retransmissão seletiva em ação 3: Camada de Transporte 41

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 seq e tamanho de janela? 3: Camada de Transporte 42

TCP: Visão geral RFCs: 793, 1122, 1323, 2018, 2581 Ø transmissão full duplex: ü fluxo de dados bidirecional na mesma Ø fluxo de bytes, ordenados, conexão confiável: ü MSS: tamanho máximo de segmento ü não estruturado em msgs Ø orientado a conexão: Ø dutado: ü handshaking (troca de ü tam. da janela ajustado por msgs de controle) inicia controle de fluxo e estado de remetente, congestionamento do TCP receptor antes de trocar dados Ø buffers de envio e recepção Ø fluxo controlado: ü receptor não será afogado Ø ponto a ponto: ü 1 remetente, 1 receptor 3: Camada de Transporte 43

TCP: estrutura do segmento 32 bits 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) checksum Internet (como UDP) no. porta origem no. porta dest número de seqüência número de reconhecimento tam. sem UA P R S F cab. uso checksum janela receptor ptr dados urg. Opções (tam. variável) contagem de dados por bytes (não segmentos!) no. bytes rcpt quer aceitar dados da aplicação (tam. variável) 3: Camada de Transporte 44

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 B Estação A Usuário tecla ‘C’ A reconhece chegada do ‘C’ ecoado Seq=4 2, ACK = 79, da ta = ‘C’ B reconhece chegada de ’ C ‘ ‘C’, ecoa ata = d , 3 4 = K ‘C’ de volta , AC 9 7 = q e S Seq=4 3, ACK =80 cenário simples de telnet 3: Camada de Transporte tempo 45

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) 3: Camada de Transporte 46

TCP: Tempo de Resposta (RTT) e Temporização RTT_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 maior Temporização = RTT_estimado + 4*Desvio = (1 - )* Desvio + *|RTT_amostra - RTT_estimado| valor típico de : 0. 25 3: Camada de Transporte 47

Exemplo estimativa RTT 3: Camada de Transporte 48

TCP: transferência confiável de dados Ø TCP cria serviço rdt sobre o serviço não confiável IP Ø Utiliza pipeline para enviar segmentos Ø ACKS cumulativos Ø TCP usa temporizador para retransmissão Ø Retransmissões são disparadas por: ü ü timeout Acks duplicados Ø Inicialmente considere um TCP emissor simplificado: ü ü ignore acks duplicados ignore controle de fluxo e controle de congestionamento; 3: Camada de Transporte 49

Eventos do. TCP emissor: Dados recebidos da aplic: Ø Cria o segmento com no de seq X Ø seq X é o número do primeiro byte do segmento Ø Inicia o temporizador se ele não foi iniciado anteriormente Ø Intervalo de expiração: Time. Out. Interval timeout: Ø Retransmite o segmento que causou o timeout Ø Reinicializa o temporizador Ack recebido: Ø Se reconhece segmentos não reconhecidos anteriormente ü ü Atualiza a informação sobre pacotes reconhedidos Inicia o temporizador se existem ainda segmentos não reconhecidos 3: Camada de Transporte 50

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 sendbase = número de seqüência inicial nextseqnum = número de seqüência inicial TCP: transfe -rência confiável de dados Remetente TCP simplificado loop (forever) { switch(event) event: dados recebidos da aplicação acima cria segmento TCP com número de seqüência nextseqnum inicia temporizador para segmento nextseqnum passa segmento para IP nextseqnum = nextseqnum + comprimento(dados) event: expirado temporizador de segmento c/ no. de seqüência y retransmite segmento com número de seqüência y calcula novo intervalo de temporização para segmento y reinicia temporizador para número de seqüência y event: ACK recebido, com valor de campo ACK de y se (y > sendbase) { /* ACK cumulativo de todos dados até y */ cancela temporizadores p/ segmentos c/ nos. de seqüência < y sendbase = y } senão { /* é ACK duplicado para segmento já reconhecido */ incrementa número de ACKs duplicados recebidos para y if (número de ACKs duplicados recebidos para y == 3) { /* TCP: retransmissão rápida */ reenvia segmento com número de seqüência y reinicia temporizador para número de seqüência y } } /* fim de loop forever */ 3: Camada de Transporte 51

TCP: cenários de retransmissão Host A Estação B Seq=9 temporização X ACK dados =100 perda Seq=9 2 , 8 byt es de dados Temp. p/ Seq=100 Temp. p/ Seq=92 Seq=9 2 , 8 byt es de Seq= tes de 100, 2 0 byte dados s de d ados 0 10 = K 120 = C K A AC Seq=9 2, 8 by tes de dados 20 100 cenário do ACK perdido 2, 8 by K=1 AC = ACK tempo Host B temporização prematura, ACKs cumulativos 3: Camada de Transporte 52

TCP: cenários de retransmissão (cont) Host A Host B Seq=9 timeout 2, 8 by Seq=1 tes da ta =100 K C A 00, 20 bytes data X loss 120 = ACK time Cenário de ACK cumulativo 3: Camada de Transporte 53

TCP geração de ACKs [RFCs 1122, 2581] Evento Ação do receptor TCP chegada de segmento em ordem sem lacunas, anteriores já reconhecidos ACK retardado. Espera até 500 ms p/ próx. segmento. Se não chegar segmento, envia ACK chegada de segmento em ordem sem lacunas, um ACK retardado pendente envia imediatamente um único ACK cumulativo chegada de segmento fora de ordem, com no. de seq. maior que esperado -> lacuna envia ACK duplicado, indicando no. de seq. do próximo byte esperado chegada de segmento que preenche a lacuna parcial ou completamente ACK imediato se segmento no início da lacuna 3: Camada de Transporte 54

Fast Retransmit Ø Período de timeout é geralmente longo: ü Longo atraso até a retransmissão do segmento perdido Ø Detectar segmentos perdidos via ACKs duplicados ü ü Emissores geralmente enviam vários segmentos Se um segmento é perdido, provavelmente vão ser recebidos ACKs duplicados Ø Se o emissor recebe 3 ACKs para o mesmo segmento, supõe que o segemtno subseqüente foi perdido: ü fast retransmit: retransmite o segmetno antes que o temporizador expire 3: Camada de Transporte 55

Algoritmo Fast retransmit: evento: ACK recebido, com valor de ACK igual a y if(y > Send. Base) { Send. Base = 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 } Um ACK duplicado para um segmento já reconhecido previamente fast retransmit 3: Camada de Transporte 56

TCP: Controle de Fluxo Ø Lado receptor de uma conexão TCP tem um buffer de recepção: controle de fluxo remetente não esgotaria buffers do receptor por transmitir muito, ou muito rápidamente Ø Serviço de compatibilização Ø Processo da aplicação pode ser lento para retirar os dados do buffer de velocidades: compatibilizar a taxa de envio do emissor com a taxa de recebimento dos da aplicação do receptor 3: Camada de Transporte 57

Controle de Fluxo TCP: como funciona ? Ø receptor: explicitamente (Suponha que o TCP receptor discarte pacotes fora de ordem) = Rcv. Window = Rcv. Buffer-[Last. Byte. Rcvd Last. Byte. Read] avisa o remetente da quantidade de espaço livre disponível (muda dinamicamente) ü campo Rcv. Window no segmento TCP Ø remetente: mantém a quantidade de dados transmitidos, porém ainda não reconhecidos, menor que o valor mais recente de Rcv. Window ü Garante que não tenha overflow no buffer do receptor 3: Camada de Transporte 58

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. Rcv. Window) Ø cliente: iniciador de conexão Socket client. Socket = new Socket("hostname", "port number"); Ø servidor: contactado por cliente Socket connection. Socket = welcome. Socket. 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 recebe SYNACK, responde com um segmento de ACK, que pode conter dados 3: Camada de Transporte 59

TCP: Gerenciamento de Conexões (cont. ) Encerrando uma conexão: cliente fechar cliente fecha soquete: client. Socket. close(); Passo 1: sistema cliente envia fechar FIN espera temporizada responde com ACK. Encerra a conexão, enviando FIN ACK segmento de controle FIN ao servidor Passo 2: servidor recebe FIN, servidor ACK fechada 3: Camada de Transporte 60

TCP: Gerenciamento de Conexões (cont. ) Passo 3: cliente recebe FIN, cliente responde com ACK. ü fechando Entre em “espera temporizada” responderá com ACK a FINs recebidos FIN ACK fechando FIN ACK. Conexão encerrada. modificação, consegue tratar de FINs simultâneos. espera temporizada Step 4: servidor, recebe Note: com pequena servidor ACK fechada 3: Camada de Transporte 61

TCP: Gerenciamento de Conexões (cont. ) Ciclo de vida de servidor TCP Ciclo de vida de cliente TCP 3: Camada de Transporte 62

Princípios de Controle de Congestionamento: Ø 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 em roteadores) ü longos atrasos (enfileiramento nos buffers dos roteadores) Ø um dos 10 problemas mais importantes em redes! 3: Camada de Transporte 63

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

Causas/custos de congestionamento: cenário 2 Ø Um roteador, buffers finitos Ø retransmissão pelo remetente de pacote perdido Host A lin : dados originais lout l'in : dados originais, mais dados retransmitidos Host B Buffer finito compatilhado 3: Camada de Transporte 65

Causas/custos de congestionamento: cenário 2 = l (“goodput”) out in Ø retransmissão “perfeito” apenas quando perda: Ø sempre: Ø l l > lout in retransmissão de pacote atrasado (não perdido) faz l maior in (que o caso perfeito) para o mesmo l out “custos” de congestionamento: Ø mais trabalho (retransmissão) para dado “goodput” Ø retransmissões desnecessárias: enviadas múltiplas cópias do pacote 3: Camada de Transporte 66

Causas/custos de congestionamento: cenário 3 Ø quatro remetentes Ø Ø P: o que acontece à caminhos com múltiplos enlaces medida que l in in temporização/retransmissão crescem ? Host A lout lin : dados originais l'in : dados originais, mais dados retransmitidos Buffer finito compartilhado Host B 3: Camada de Transporte 67

Causas/custos de congestionamento: cenário 3 H o st A l o u t H o st B Outro “custo” de congestionamento: Ø quando pacote é descartado, qq. capacidade de transmissão já usada (antes do descarte) para esse pacote foi desperdiçado! 3: Camada de Transporte 68

Abordagens de controle de congestionamento Duas abordagens amplas para controle de congestionamento: Controle de congestionamento com apoio da rede: 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 Ø roteadores realimentam os sistemas terminais ü bit único indicando congestionamento (SNA, DECbit, TCP/IP ECN, ATM) ü taxa explícita p/ envio pelo remetente 3: Camada de Transporte 69

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

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

TCP: Controle de Congestionamento Ø controle fim a fim (sem apoio da rede) Ø taxa de transmissão limitada pela tamanho da janela de congestionamento: Last. Byte. Sent-Last. Byte. Acked Cong. Win Ø Cong. Win é dinâmica, e é função do congestionamento na rede; Como TCP detecta congestionamento? Ø Evento de perda = timeout ou 3 acks duplicados Ø TCP emissor reduz taxa de transmissão (Cong. Win) depois de um evento de perda Três mecanismos: ü ü ü AIMD slow start conservative after timeout events 3: Camada de Transporte 72

TCP: Controle de Congestionamento Congwin Ø w segmentos, cada um c/ MSS bytes, enviados por RTT: throughput = w * MSS Bytes/sec RTT 3: Camada de Transporte 73

TCP: 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 Ø duas “fases” ü partida lenta ü evitar congestionamento Ø variáveis importantes: ü Congwin ü threshold: define limiar entre fases de partida lenta, controle de congestionamento 3: Camada de Transporte 74

TCP AIMD multiplicative decrease (decréscimo multiplicativo: reduz Cong. Win pela metade depois de um evento de perda additive increase (crescimento aditivo): aumenta Cong. Win de 1 MSS a cada RTT na ausência de um evento de perda: probing Conexão TCP de longa duração 3: Camada de Transporte 75

TCP: Partida lenta (Slow Start) Ø Quando a conexão começa, Cong. Win = 1 MSS ü ü Exemplo: MSS = 500 bytes & RTT = 200 msec Taxa inicial = 20 kbps Ø A banda disponível deve ser >> MSS/RTT Ø Quando a conexão começa, aumenta a taxa exponencialmente até o primeiro evento de perda Ø Resumo: taxa inicial baixa, mais cresce rapidamente (crescimento exponencial) 3: Camada de Transporte 76

TCP: Partida lenta (slow start) Ø Quando a conexão começa, aumenta a taxa exponencialmente até que ococra uma perda ü Dobra Cong. Win a cada RTT, através do incremento de Cong. Win, a cada ACK recebido RTT Algoritmo Partida Lenta inicializa: Congwin = 1 for (cada segmento c/ ACK) Congwin++ until (evento de perda OR Cong. Win > threshold) Estação A Estação B um segmen to dois segme ntos quqtro segm entos tempo 3: Camada de Transporte 77

Refinamento Ø Depois de 3 Dup. ACKs: Cong. Win é reduzida a metade ü Janela cresce linearmente Ø Mas depois de um evento de timeout: ü Cong. Win é reduzida a 1 MSS; ü Janela cresce exponencialmente até o valor do threshold, e depois cresce linearmente ü Filosofia: ü o recebimento de 3 ACKs duplicados indica que a rede tem condição de transmitir alguns segmentos üOcorrência de timeout antes de 3 ACKs duplicados é “mais alarmante” 3: Camada de Transporte 78

Refinamento (mais) Q: Quando o crescimento deve mudar de exponencial para linear ? A: Quando Cong. Win atinge 1/2 do seu valor antes do timeout. Implementação: Ø Threshold variável Ø Quando ocorre uma perda, faz-se Threshold = Cong. Win/2 3: Camada de Transporte 79

TCP: Prevenção do Congestionamento (congestion Avoidance prevenção congestionamento /* partida lenta acabou */ /* Congwin > threshold */ Until (event de perda) { cada w segmentos reconhecidos: Congwin++ } threshold = Congwin/2 Congwin = 1 faça partida lenta 1 1: TCP Reno pula partida lenta (recuperação rápida) depois de três ACKs duplicados 3: Camada de Transporte 80

Resumo: Controle de Congestionamento Ø Quando Cong. Win está abaixo do Threshold, o emissor está na fase de slow-start, e a janela cresce exponencialmente Ø Quando Cong. Win 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 = Cong. Win/2 e Cong. Win = Threshold. Ø Quando ocorre um timeout, faz-se Threshold = Cong. Win/2 e Cong. Win = 1 MSS. 3: Camada de Transporte 81

Eqüidade TCP 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 TCP conexão 1 TCP conexão 2 Roteador gargalo capacidade R 3: Camada de Transporte 82

Por quê TCP é justo? Duas sessões concorrentes: Ø Aumento aditivo dá gradiente de 1, enquanto vazão aumenta Ø decrementa multiplicativa diminui vazão proporcionalmente Vazão da conexão 2 R compartilhamento igual da banda perda: diminui janela por fator de 2 evitar congestionamento: aumento aditivo Vazão da conexão 1 R 3: Camada de Transporte 83

Eqüidade (mais) Eqüidade e UDP Ø Aplic. Multimídia geralmente não usam TCP ü Não desejam que a taxa seja reduzida pelo controle de congestionamento Ø Geralmente usam UDP: ü audio/video a taxa constante, toleram perdas de pacotes Ø Área de pesquisa: TCP friendly Eqüidade e conexões TCP paralelas Ø Nada previne que aplic. abram várias conexões simultânceas entre os 2 hosts; Ø Wrowsers fazem isto Ø Exemplo: enlace com taxa igual a R, com 9 conexões; ü ü Nova aplic. requer uma conexão TCP, recebe R/10 da taxa Nova aplic. requer 11 conexões TCP, recebe R/2 da taxa 3: Camada de Transporte 84

TCP: modelagem de latência P: Quanto tempo custa para receber um objeto de um servidor WWW depois de enviar o pedido? Notação, suposições: Ø Supomos um enlace entre cliente e Ø Ø Ignorando o congestionamento, a latência é influenciada por: Ø Estabelecimento de conexão TCP Ø retardo de transferência de dados Ø Slow start Ø Ø 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 3: Camada de Transporte 85

Janela de congestionamento de tamanho fixo (1) Primeiro caso: WS/R > RTT + S/R: ACK do primeiro segmento na janela chega antes de enviar todos dados na janela latência = 2 RTT + O/R 3: Camada de Transporte 86

Janela de congestionamento de tamanho fixo (2) Segundo caso: Ø WS/R < RTT + S/R: aguarda ACK depois de enviar todos os dados na janela latência = 2 RTT + O/R + (K-1)[S/R + RTT - WS/R] 3: Camada de Transporte 87

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: - onde Q é o número de vezes que o servidor pararia se o objeto fosse de tamanho infinito. - e K é o número de janelas que cobrem o objeto. 3: Camada de Transporte 88

TCP: modelagem de latência: Slow Start(2) 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 3: Camada de Transporte 89

TCP: modelagem de latência: (3) S + RTT = tempo quando o servidor inicia o envio do segmento R até quando o servidor recebe reconhecimento 2 k -1 S = tempo para enviar a k-ésima janela R inicia conexão TCP pede objeto + tempo de bloqueio após a éS k -1 S ù + = RTT 2 êë R k-ésima janela R úû RTT primeira janela = S/R segunda janela = 2 S/R terceira janela = 4 S/R P O latencia= + 2 RTT + å Tempo. Bloqueio p R p =1 P O S S = + 2 RTT + å [ + RTT - 2 k -1 ] R R k =1 R O S S = + 2 RTT + P[ RTT + ] - (2 P - 1) R R R quarta janela = 8 S/R objeto entregue tempo no cliente transmissão completa tempo no servidor 3: Camada de Transporte 90

TCP modelagem de latência: partida lenta (4) Lembre que K = número de janelas que cobrem um objeto Como calculamos o valor de K? O cálculo do número Q, de inatividade por objeto de tamanho infinito, é similar (veja HW). 3: Camada de Transporte 91

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)2 RTT + soma dos perí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 + 3 RTT + soma dos períodos de inatividade Ø 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)2 RTT + soma dos períodos de inatividade ü 3: Camada de Transporte 92

HTTP: tempo de resposta (em segundos) RTT = 100 msec, O = 5 Kbytes, M=10 e X=5 20 18 16 14 12 10 8 6 4 2 0 não-persistente paralela nãopersistente 28 100 1 10 Kbps Mbps 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 3: Camada de Transporte 93

HTTP: tempo de resposta (em segundos) RTT =1 seg, O = 5 Kbytes, M=10 e X=5 70 60 50 40 30 20 10 não-persistente paralela nãopersistente 0 28 100 1 10 Kbps Mbps 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 atraso. Xbanda (delay bandwidth) 3: Camada de Transporte 94

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