Capítulo 3: Camada de Transporte Metas 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 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 Protocolos de transporte podem oferecer serviço de entrega confiável em redes cujo serviço de entrega não é confiável (best effort). Exemplo: TCP sobre IP No entanto protocolos de transporte não podem oferecer certos serviçs que não são oferecidos pela rede. Exemplo : Protocolos de transporte não podem oferecer garantia de retardo em redes que não oferecem este serviço. Multiplexação / Demultiplexação  extende entrega host-to-host a entrega processo-a-processo 3: Camada de Transporte

Serviços e protocolos de transporte aplicação transporte rede enlace física transporte lógico fim a fim provê comunicação lógica entre processos de aplicação executando em hospedeiros diferentes protocolos de transporte executam em sistemas terminais serviços das camadas de transporte X rede: camada de rede : dados transferidos entre sistemas camada de transporte: dados transferidos entre processos depende de, estende serviços da camada de rede 3: Camada de Transporte

Protocolos da camada de transporte aplicação transporte rede enlace física transporte lógico fim a fim Serviços de transporte na Internet: 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ão ordenada, ponto a ponto ou multiponto: UDP serviços não disponíveis: tempo-real garantias de banda multiponto confiável 3: Camada de Transporte

Multiplexação/demultiplexação Lembrança: segmento - unidade de dados trocada entre entidades da camada de transporte = TPDU: transport protocol data unit Demultiplexação: entrega de segmentos recebidos para os processos da camada de apl corretos receptor P3 P4 dados da camada de aplicação M M aplicação transporte rede cabeçalho de segmento P1 P2 M M aplicação transporte rede aplicação transporte rede segmento H t M H n segmento 3: Camada de Transporte

Multiplexação/demultiplexação juntar dados de múltiplos processos de apl, envelopando dados com cabeçalho (usado depois para demultiplexação) porta remetente porta receptor 32 bits dados da aplicação (mensagem) outros campos do cabeçalho multiplexação/demultiplexação: baseadas em números de porta e endereços IP de remetente e receptor números de porta de remetente/receptor em cada segmento lembrete: número de porta bem conhecido para aplicações específicas formato de segmento TCP/UDP 3: Camada de Transporte

Multiplexação/demultiplexação: exemplos estação A porta orig.: x porta dest: 23 servidor B Web client host C porta orig:23 porta dest: x IP orig : C IP dest: B porta orig: y porta dest: 80 IP orig: C IP dest: B porta orig: x porta dest: 80 uso de portas: apl. simples de telnet IP orig: A IP dest: B porta orig: x porta dest: 80 servidor WWW B cliente WWW estação A uso de portas : servidor WWW 3: Camada de Transporte

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

Mais sobre UDP outros usos de UDP (por quê?): Comprimento em bytes do segmento UDP, incluindo cabeçalho 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.! 32 bits porta origem porta dest. comprimento checksum Além de multiplexação / demultiplexação e controle de erro simplista, UDP não oferece nenhuma serviço além dos serviços oferecidos pelo IP. Aplicações que não podem pagar overhead de estabelecimento de conexão, como por exemplo DNS, a aplicação que estão sujeitas a uma taxa mínima de transmissão. Aplicações baseadas em multicast não podem utilizar TCP. Tráfego UDP tem que respeitar tráfego TCP. Caso contrário, tráfego TCP não recebe banda passante. TCP friendly Dados de aplicação (mensagem) UDP segment format 3: Camada de Transporte

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

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

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 deliver_data(): chamada por rdt p/ entregar dados p/ camada superior send side receive side udt_send(): chamada por rdt, p/ transferir pacote pelo canal ñ confiável ao receptor rdt_rcv(): chamada quando pacote chega chega no lado receptor do canal 3: Camada de Transporte

Transferência confiável de dados (rdt): como começar Iremos: 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 event causing state transition actions taken on state transition state 1 estado: neste “estado” o próximo estado é determinado unicamente pelo próximo evento state 2 event actions 3: Camada de Transporte

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

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

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

rdt2.0: em ação (sem erros) Quando transmissor está a espera de ACK/NACK não pode receber mais dado da aplicação Stop and Wait ARQ (Automatic Repeat Request) Envio da ACK/NACK FSM do remetente FSM do receptor 3: Camada de Transporte

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

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/NAKs p/ 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 para e espera Remetente envia um pacote, e então aguarda resposta do receptor 3: Camada de Transporte

rdt2.1: remetente, trata ACK/NAKs c/ erro 3: Camada de Transporte

rdt2.1: receptor, trata ACK/NAKs com erro 3: Camada de Transporte

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

rdt2.2: um protocolo sem NAKs FSM do remetente 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 seq do pacote reconhecido ACK duplicado no remetente resulta na mesma ação que o NAK: retransmite pacote atual ! 3: Camada de Transporte

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

rdt3.0: remetente 3: Camada de Transporte

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

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

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: T transmitir = 8kb/pacote 10**9 b/seg = 8 microseg Utilização = U = = 8 microseg 30.016 mseg fração do tempo remetente ocupado = 0,00015 pac. de 1KB a cada 30 mseg -> vazão de 33kB/seg num enlace de 1 Gbps protocolo limita uso dos recursos físicos! 3: Camada de Transporte

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 Retardo de propagação tem grande impacto em protocolos stop-and-wait, tornando-os muito ineficientes. Duas formas genéricas de protocolos dutados: volta-N, retransmissão seletiva 3: Camada de Transporte

Volta-N Remetente: no. de seq. de k-bits no cabeçalho do pacote admite “janela” de até N pacotes consecutivos não reconhecidos Número de seqüência  reutilizados, aritmética de módulo Caso janela esteja cheia, não aceita pacotes da aplicação. Quando um ACK é recebido e ainda existem confirmações pendentes, o temporizador é reiniciado 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

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

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 Não faz sentido guardar pacotes que chegam fora de ordem dado que o transmissor irá retransmitir de qualquer forma Receptor só é necessário armazenar o próximo número de sequência 3: Camada de Transporte

Volta-N em ação 3: Camada de Transporte Go-Back-N é vantajoso quando se tem perdas em rajada  evita notificação de perda move ?de imediato segmentos perdidos. Go-Back-N não é apropriado para redes que tenham um alto produto (banda passante x retardo) pois muitos pacotes podem estar no pipe e pode haver necessidade de retransmissão de vários pacotes em caso de erro. Eficiência Go-Back-N = [(1 - P)/(1- P) + P*W)], onde: P  Probabilidade de perda W  Tamanho da janela Para W = 250 pacotes , P = 0,001  eficiência = 0,283 P = 10 -5  eficiência = 0,997 3: Camada de Transporte

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

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

Retransmissão seletiva remetente receptor 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 Go-Back-N x Retransmissão seletiva compromisso entra banda passante e espaço em buffer. Receptor reconfirma pacote com número de sequência abaixo do número base da janela, pois caso contrário, o transmissor não teria como sabe-lo e não avançaria a sua janela. Confirmação pode ter se perdido Só se avança a janela do transmissor quando um grupo de pacotes consecutivos foram confirmados. O receptor passa para a aplicação grupos de pacotes com número de sequência consecutivos quando todos estes pacotes tiverem chegado Um conjunto de relógios pode ser simulado por s/w mantendo-se uma lista encadeada onde cada elemento da lista representa a diferença do tempo de expiração do temporizador do elemento da lista e do seu antecessor 3: Camada de Transporte

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

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? Tamanho da janela tem que ser no máximo a metade do número de sequência máximo, pois mesmo que o receptor avance o tamanho máximo da janela, os números de sequência esperados não coincidem com os números de sequência dos segmentos (ou datagramas) transmitidos com sucesso mas ainda não confirmados. A rede pode “acumular”datagramas que chegam ao receptor com alto atraso. Isto ocorre devido à operação de redes de datagramas nas quais datagramas de uma mesma conexão de transporte seguem rotas diferentes e podem sofrer retardos diferentes nestas rotas. Em rotas congestionadas, o retardo pode ser elevadíssimo. Um tempo de vida para o datagrama deve ser estabelecido. Na extensão TCP para redes de alta velocidade, é sugerido 3 minutos para tempo de vida. 3: Camada de Transporte