Nível Transporte (Modelo Internet) {TCP.doc} UDP TCP

Transcrição

1 Prof V Vargas, IST Nível Transporte (Modelo Internet) 03/11/11, Page 1 of 9 Nível Transporte (Modelo Internet) {TCP.doc} 1. [07T1] Explique como são realizadas as funções de multiplexagem fornecidas pelo nível de transporte da Internet R: Através de Portos, i.e., números ocupando 16-bits no cabeçalho dos Segmentos (UDP e TCP); o Porto-destino de um Segmento chegando da Internet permite discernir a que "Aplicação"-local se destina; o Porto-fonte permite a esta última discernir de que "Aplicação"-remota ele provém. 2. Diga se a seguinte afirmação é verdadeira ou falsa: O mecanismo de controlo de fluxo num protocolo de transporte é usado para evitar que o emissor exceda o ritmo suportado pela rede. R: É falsa. O mecanismo de controlo de fluxo pretende evitar que o emissor exceda o ritmo tolerado pelo receptor. O controlo de congestão é que pretende evitar exceder o ritmo suportado pela rede. UDP 3. [98E3] Porquê a existência de UDP: UDP é mesmo necessário? Não teria sido suficiente deixar as aplicações que a ele recorrem limitar-se simplesmente a enviar datagramas-ip? 4. O protocolo UDP não é fiável, não tem controlo de fluxo nem controlo de congestão. Porque existe então este protocolo? Dê um exemplo de uma aplicação que beneficie do uso do protocolo UDP e identifique três vantagens do protocolo UDP face ao TCP R: O UDP é melhor para aplicações que usem fluxos multimédia (áudio/vídeo). Vantagens face ao TCP: o UDP não tem atrasos de estabelecimento de ligação; não tem atrasos para recuperar de pacotes errados; não tendo controlo de congestão, permite transmitir ao ritmo "que se quiser"; é mais simples que o TCP porque não exige manutenção do estado; e tem cabeçalhos mais pequenos que o TCP TCP 5. [08E2.3] Porque é que o cabeçalho de um segmento TCP tem um campo que especifica o comprimento do cabeçalho e o cabeçalho de um segmento UDP não tem? Por que motivo existirá essa diferença entre os protocolos UDP e TCP? R: Por mor de flexibilidade e eficiência, o cabeçalho de um Segmento-TCP comporta um campo Opções (por ex., MSS e SAck permitido ). Já o cabeçalho de um Segmento-UDP não o comporta já que o seu objectivo é sobretudo a rapidez na transferência. 6. [09T1.3] O formato de um segmento TCP não inclui nenhum campo que especifique o tamanho do segmento. Explique, claramente, porque foi considerada desnecessária a inclusão deste campo. R: Um segmento TCP ocupa a totalidade do campo Dados de um datagrama-ip. (Por curiosidade: um datagrama-ip inclui dois campos, IHL e TL - respectivamente Comprimento-do-Cabeçalho e Comprimento-Total - que delimitam esse campo Dados ) 7. [09E1.2] Qual a motivação para o mecanismo 3-way handshake, presente no estabelecimento de uma ligação TCP? Ilustre a sua resposta com pelo menos dois cenários que mostrem os méritos deste método de estabelecimento de ligação, em comparação com uma alternativa do tipo 2-way handshake. R: Motivação: descartar segmentos que de facto não dizem respeito à conexão em causa. Considere-se a transacção (simplificada) entre um Posto Multibanco (A) e um Banco (B). O diagrama TCP02.c1 representa-a sob a forma de 2-way : após o Cliente digitar a quantia a levantar, A envia um pedido de estabelecimento de Conexão (Conn0.0); B responde com Ack1; A prossegue indicando (em Data1,1) aquela quantia; B decrementa a conta do Cliente, e (em Data1,2) assinala Sucesso com o que A serve o Cliente e termina a conexão. TCP02.c2 esquematiza uma falha deste protocolo: Conn0,0 sofre um atraso considerável, levando ao expirar do relógio (em A) e subsequente retransmissão de Conn; mais adiante, Data1,1 sofre também um atraso, levando novamente ao expirar do relógio e subsequente retransmissão de Data1,1. Se, já fechada a conexão, esses Conn0,0 e Data1,1 chegarem a B, este aceita a conexão e decrementa a conta do Cliente: por cada euro que recebe, a conta é decrementada de dois

2 Prof V Vargas, IST Nível Transporte (Modelo Internet) 03/11/11, Page 2 of 9 TCP02.c4 representa a transacção sob a forma de 3-way : em vez de numerarem os segmentos a partir de 0, A e B escolhem, aleatoriamente e independentemente um do outro, os números (x e y) com que numeram os Conn que enviam; e cada um deles envia Data somente após o seu interlocutor confirmar o Conn que ele mesmo enviou! TCP03.c3 representa outro cenário onde 2-way falha, a saber: spoofing. Um aluno cábula (C) pretende alterar as notas das disciplinas (em B). C envia um segmento Conn0,0, assinalando, como endereço de origem, um endereço (A) que B considera seguro; B envia Ack1 a A; no entrementes, C envia as notas que deseja a B (Data1,1, Data2,1) todas elas sendo aceites por B Em ambos os cenários (atraso de Conn e Data1,1; e spoofing), e vigorando 3-way, B responderia a cada Conn recebido com outro Conn e esperaria que A lho confirmasse, antes de aceitar segmentos Data 8. No contexto do protocolo TCP, e com a ajuda de um diagrama temporal, explique o significado da flag "Push". 9. [98E2] Existe algum problema se uma aplicação estiver a escrever para um socket-tcp octeto-a-octeto? como poderá proceder o TCP para minorar o problema? 10. Na interface em C proporcionada pelos sockets Internet, para que serve a chamada bind()? É normalmente utilizada no cliente ou no servidor? 11. Quando um segmento TCP chega a um sistema terminal, que parâmetros do segmento são utilizados na desmultiplexagem para determinar a que socket deve ser entregue o segmento? 12. [08E2.2] Um dos problemas inerentes às redes que não garantem a ordem de entrega de pacotes ao destinatário é o facto de essa característica poder afectar o funcionamento dos protocolos de transporte. Em particular, se uma cópia de um pacote muito atrasada pela rede (isto é, uma cópia que pode pertencer a uma janela do emissor anterior à actual), for entregue ao destinatário do nível de rede e, por acaso, a sua numeração for aceite como válida pelo destinatário de transporte, ocorre um erro. Sendo este um problema potencial também na Internet, afectando o TCP, explique qual ou quais os mecanismos que evitam tais erros R: Mecanismos ao nível Rede : Iniciar um campo TTL em cada datagrama, decrescê-lo em cada router visitado, descartá-lo da rede quando atingir zero; Mecanismos suplementares a considerar ao nível do TCP dependem do contexto: 1. o pacote atrasado e a janela de recepção respeitam à mesma conexão-tcp - a medida em vigor é um módulo de numeração muito elevado, concretamente 2 32 ; 2. em contrário: - após terminada uma conexão, não re-utilizar o mesmo porto do receptor por algum tempo; - ao começar uma conexão-tcp, escolher aleatoriamente o numero de sequência inicial. 13. Considere a situação ilustrada na figura TCP11, onde o exército cinzento tem 2 divisões em cada um dos montes e o exército branco tem 3 divisões no vale. Se os dois grupos de divisões do exército cinzento conseguirem coordenar um ataque simultâneo ao exército branco, ficam em vantagem (4 divisões contra 3), e obtêm vitória. Se cada grupo de divisões do exército cinzento atacar separadamente o exército branco, ficam em desvantagem (2 divisões contra 3), e perdem. Admita que cada grupo de divisões do exército cinzento é comandado por um general que apenas pode comunicar com o outro general seu aliado pelo envio de mensageiros que, ao atravessar o território do inimigo, podem ser capturados, sendo a mensagem perdida. Admita que há um número infinito de mensageiros disponíveis em ambos os lados.

3 Prof V Vargas, IST Nível Transporte (Modelo Internet) 03/11/11, Page 3 of Existe um protocolo que permita a coordenação do ataque e a consequente vitória dos exércitos cinzentos? Caso exista, explique como funciona esse protocolo. Caso não exista, prove que tal protocolo não existe. R: Não existe tal protocolo. Demonstração por absurdo: suponha-se que existe um protocolo. Ou a última mensagem é essencial, ou não é. Se não é, retire-se essa mensagem (e todas as outras mensagens não essenciais) até se ficar com um protocolo em que todas as mensagens são essenciais. O que acontece se a mensagem final se perder? Como era essencial, se se perder, não pode haver ataque. Quem a enviou não pode ter a certeza que chegou, pelo que não ataca. O outro general sabe disso, pelo que também não ataca Controlo de Erro 14. Considere o protocolo TCP (nível de transporte). Descreva como se faz: o controlo de fluxo; o controlo de congestão. 15. Indique, justificando, se a seguinte afirmação é verdadeira, ou falsa: O TCP é um protocolo justo porque se se tiver uma aplicação TCP e uma aplicação UDP a partilhar uma linha, cada aplicação tenderá a obter metade da largura de banda da linha. R: É falsa. A divisão da largura de banda só funciona entre aplicações TCP, visto que o UDP não tem controlo de fluxo 16. [07E1] Considere uma ligação TCP entre dois computadores, W e E. Os números de sequência em W e E são, de momento, 300 e 800. Suponha que W envia um segmento de 100 octetos de dados. Após receber o respectivo ACK envia outro segmento, com 250 octetos de dados que é ecoado por E. Não há mais tráfego, nem há segmentos perdidos, corrompidos ou atrasados. Trace um diagrama temporal da troca de segmentos, explicitando os números de sequência e de ACK R: Cfr. fig TCP17.a 17. [10E1.2] Enunciado análogo a [07E1], mas: 1) os números de sequência em W e E iniciais são 400 e 650, respectivamente; 2) os segmentos que W envia têm 200 e 150 octetos de dados. R: Cfr. fig TCP17.c 18. [10T1.3] Considere e troca de segmentos representada na figura TCP27.b. Os números de sequência dos primeiros dois Segmentos (de estabelecimento da conexão-tcp) são 1234 e Admita que a Aplicação em W envia 1000 bytes de dados para E. Quais os números de Sequência e de Acknowledge, Y e Z, transportados no último Segmento apresentado na figura?

4 Prof V Vargas, IST Nível Transporte (Modelo Internet) 03/11/11, Page 4 of 9 R: Y=5679 (=5678+1) e Z=2235 (= ). (Repare-se: E necessita confirmar a recepção do segmento SeqNº=1234; fá-lo com um segmento cujo Ack é X=1235. O que implica que o primeiro byte de dados enviado por W é numerado SeqNº=1235; o 1000º byte de dados será numerado SeqNº=2234. E confirma a sua recepção devolvendo um segmento cujo Ack é Z=2235) 19. [08E3.11] Considere a troca de segmentos da fig TCP27.c: a Aplicação em W envia 50 bytes de dados para E, e este envia 200 bytes de dados para W. Os números de sequência e de Acknowledgement transportados no último segmento são, respectivamente, 4890 e Quais os números de sequência dos primeiros dois segmentos, X e Y (de estabelecimento da ligação TCP)? R: X=4839 e Y=5187. Selective Acknowledge 20. [09E1.5] Considere dois computadores, W e E, que comunicam através de uma ligação TCP, trocando segmentos de acordo com a figura TCP30.a. Suponha que W envia sete segmentos (cujos primeiros e últimos bytes têm os números indicados) e em que um dos segmentos se perde. Considere que ambos os interlocutores executam o protocolo TCP com a opção SACK Para cada um dos segmentos Ack devolvidos por E, especifique os respectivos números de Acknowledgement e a identificação dos blocos recebidos Relativamente ao segmento perdido, diga em que momento poderá o emissor decidir retransmiti-lo R1 A TCP30.c. apresenta a evolução do buffer do receptor, os Acks enviados e respectivos números. - inicialmente, E encontra-se aguardando o Segmento numerado 1000; - ao chegar o Segmento numerado 6000, devolve um Ack, declarando que continua a aguardar o Segmento 1000 porém utiliza SACK para notificar W que já recebeu o bloco ; - ao chegar o Segmento 1000, roda a Janela de Recepção (ficando a aguardar o Segmento numerado 2000) e notifica W (continando, com SACK, a referir que já recebeu o bloco ); - ao chegar o Segmento 3000, devolve um Ack, declarando que continua a aguardar o Segmento 2000 porém utiliza SACK para notificar W que já recebeu os blocos e ; - ao chegar o Segmento 7500, que é contíguo ao bloco , devolve um Ack, declarando que continua a aguardar o Segmento 2000 porém utiliza SACK para notificar W que já recebeu os blocos e (repare-se que começa por mencionar o bloco , pois foi o último onde houve mexidas ); - ao chegar o Segmento 2000, roda a Janela de Recepção (ficando a aguardar o Segmento numerado 4500) e notifica W (continando, com SACK, a referir que já recebeu o bloco ); - ao chegar o Segmento 5500, que é contíguo ao bloco , devolve um Ack, declarando que continua a aguardar o Segmento 4500 porém utiliza SACK para notificar W que já recebeu os blocos ; R2: Quando o temporizador expirar: re-envia-se o segmento Ademais, e admitindo que os Acks chegam todos ao emissor, sem perdas, e por ordem, respectivamente nos instantes t 1, t 2,, t 6, o emissor pode re-enviar, logo em t 1, os octetos { } repartidos nos mesmos cinco segmentos ou re-organizados de outra maneira, por ex. em quatro segmentos: { }, { }, { }, { }. Há outras respostas aceitáveis: pode conceber-se um emissor menos agressivo que se refreie um pouco; nomeadamente, e assumindo MSS=1500, - re-enviar quando muito MSS octetos por cada Ack: por ex., enviar { } em t 1, { } em t 2, { } em t 3

5 Prof V Vargas, IST Nível Transporte (Modelo Internet) 03/11/11, Page 5 of 9 - re-enviar um octeto apenas depois de ter sido SAcked um certo montante (como seja 2*MSS) de octetos subsequentes; por ex., esperar até t 3 para enviar { } pois então 3000 octetos mais recentes foram já SAcked (os octetos { } e { }). - re-enviar um octeto apenas depois de ter sido SAcked um certo montante (como seja 2) de segmentos subsequentes; por ex., esperar até t 3 para enviar { } pois então 2 segmentos mais recentes foram já SAcked (os segmentos 3000 e 6000; e em t4 re-enviar { } pois então 2 segmentos mais recentes foram já SAcked (os segmentos 6000 e 7500 Deixa-se à imaginação do leitor a congeminação de outros algoritmos para decidir quando retransmitir 21. [09E3.4] Considere a troca de segmentos na fig. TCP30.b, em que W envia seis segmentos cujos primeiros e últimos bytes têm os números indicados. Um deles perde-se. Considere que ambos os interlocutores executam a opção SACK Para cada um dos segmentos Ack devolvidos por E, especifique os respectivos números de Acknowledge e a identificação dos blocos recebidos Relativamente ao segmento perdido, diga em que instante irá o emissor retransmiti-lo. Admita que ele segue a política de reenviar, por cada Ack, um segmento o mais cheio possível até um máximo de MSS octetos, com MSS=1500 octetos. R1 (cfr fig. TCP30.d. com evolução do buffer do receptor): R2: No instante t2: em t1, o emissor reenvia os octetos { }, em t2 reenvia os octetos { } - que incluem aqueles que se perderam. Fast Retransmit 22. Indique em que situação é utilizado, e qual o objectivo do mecanismo de Retransmissão Rápida (Fast Retransmit) do protocolo TCP 23. [06E3] Explique sucintamente como actua o mecanismo fast retransmit do protocolo TCP. Qual é, do seu ponto de vista, a justificação para que este mecanismo faça sentido? R: Retransmitir o Segmento mais antigo por confirmar após receber três Acks duplicados (por ex., retransmitir S 10 após receber Ack 9, Ack 10, Ack 10, Ack 10, Ack 10). O objectivo é apressar a retransmissão do pacote, em vez de continuar à espera que expire o timeout associado àquele Segmento. 24. [07E3.3] Explique qual a motivação para a inclusão do mecanismo Fast Retransmit no TCP. Descreva uma situação (ou, simplesmente, explique um cenário) em que este mecanismo não funcione de forma eficiente. R: Motivação: diminuir o tempo de espera antes do re-envio de um Segmento. Fast Retransmit é viável quando a fonte transmite múltiplos Segmentos. Ocorre quando ela repara que um Ack recebido é o terceiro duplicado de um Ack que já havia recebido antes: procede de imediato à retransmissão do Segmento que transportou o octeto assinalado nesse Ack - por conseguinte sem esperar que acabe por expirar o relógio associado à retransmissão desse Segmento. Isto não é eficiente (quer dizer, desperdiça recursos) se a causa desses Acks duplicados não é a perda desse Segmento mas sim o

6 Prof V Vargas, IST Nível Transporte (Modelo Internet) 03/11/11, Page 6 of 9 seu atraso na Rede até ao destino: o respectivo Ack irá chegar à fonte - porém então já ela terá (inultimente) re-enviado o Segmento em causa 25. [08E3.3] Explique, sucintamente, como funciona o mecanismo Fast Retransmit no TCP. Sabe-se que este mecanismo não funciona bem quando existem múltiplas perdas num curto espaço de tempo (por exemplo, num RTT). Apresente um exemplo ilustrativo (num diagrama temporal) deste mau funcionamento. Ra: Considere-se que E, tendo já recebido Ack1, envia a W uma rajada de Segmentos, e que, sem perda de generalidade, se perde o primeiro deles. Ao receber o segundo, terceiro, quarto, etc., segmentos, W devolve Acks reportando que ainda permanece aguardando pelo primeiro. Na recepção do terceiro desses Acks, E retransmite de imediato esse primeiro segmento i.e., sem esperar que expire o timeout associado à sua retransmissão. Rb. A fig TCP29.a ilustra a perda de mais que um Segmento da mesma Janela. Inicialmente, a Janela de Congestão de E é w=6 habilitando a enviar 6 Segmentos, S1-S6. Que acontecerá se se perderem dois deles, sejam por ex., o 1º e o 3º? W irá devolver 4 Acks, todos eles Ack1. Ao receber o terceiro, E executa Fast Retransmit: envia S1, fixa Threshold=3 e ingressa em SlowStart. W irá devolver Ack3. A continuação depende da filosofia em vigor: Tahoe: após Fast Retransmit, w=1. Na recepção de Ack3, w muda para w=2 mas E não pode enviar mais Segmentos, pois encontram-se em voo um total de 4 segmentos (S3-S6) Reno: após Fast Retransmit, w=6(=3+3); com o último Ack1, w=7, com o que E pode enviar S7. Na recepção de Ack3, w muda para w=3 - mas E não pode enviar mais Segmentos, pois encontram-se se em voo um total de 5 segmentos (S3-S7) Em qualquer caso, E não envia mais Segmentos, e W não envia mais Acks - não dando ensejo a um terceiro duplicado. A situação vai resolver-se pelo mecanismo do timeout de retransmissão de S3 isto é, após um longo período de silêncio. Time Out 26. [10E2.3] O TCP fixa o timeout em função das medidas do RTT Quais as consequências de um timeout reduzido? E de um timeout excessivo? Como é que o TCP fixa o valor do timeout? R1: A eventual retransmissão de segmentos aceites no destino, mas cujos Acks demoram a chegar à fonte. Se um segmento chegou bem, a sua retransmissão apressada (isto é, sem dar tempo a que os Acks cheguem) é tráfego inútil, a carregar a rede... R2: Demora na retransmissão de um segmento que não chegou bem ao destino (porque se perdeu ou chegou corrompido por erro) Se um segmento não chegou bem, a sua retransmissão é inevitável e adiar a sua retransmissão leva a que o receptor virá a dispor dos dados bem mais tarde do que seria porventura desejável R3: TCP vai ajustando dinamicamente o valor do timeout (RTO) às condições da rede: faz uma estimativa para o RTT, designemo-la de RTT Médio, e a partir dela (média e dispersão) estabelece o valor do timeout. (Em termos práticos, essa estimativa é uma média ponderada entre a última estimativa e o último RTT, designemo-lo de M: RTT Médio = (1-g) RTT Médio + g M, com g=1/8 D Médio = (1-h) D Médio + h RTT Médio -M, com h=1/4 O valor do timeout será algo maior que esse RTT Médio: RTO = RTT Médio+ 4 D Médio)

7 Prof V Vargas, IST Nível Transporte (Modelo Internet) 03/11/11, Page 7 of [98E1] Considere que, em dado momento, o Round-Trip-Delay de uma conexão TCP (RTT) é 30 milisegundos; os acknowledges seguintes chegam após 20, 39 e 40 milisegundos, respectivamente. Assuma que o timeout para a retransmissão de um segmento é o dobro do RTT estimado. Se se usar x=0,1, qual o valor final para o timeout? R: RTT 1=0,9*30+0,1*20=29; RTT 2=30; RTT Final=31 timeout=62 milisegs 28. Suponha que uma sessão tipo-tcp entre as estações A e B tem janela anunciada sempre igual a um segmento. O RTT é estimado tal como em TCP, com parâmetro x=0,1. No entanto, ao contrário do que acontece numa sessão TCP real, assuma que o intervalo de tempo até à retransmissão de um segmento (timeout) é simplesmente igual a y vezes o RTT estimado. Se as amostras de RTT forem alternadamente iguais a 1 e 5 segundos, qual o valor mínimo de y que não causa retransmissões? Resolução: Em TCP, o RTT Estimado é um período de tempo dinâmicamente adaptado às condições de tráfego de momento. É uma ponderação entre o "historial" precedente de RTT e o valor de facto medido; vem a ser dado por RTT i+1 = (1-x) RTT i + x * RTT Real. No caso presente, os valores reais são alternadamente 1 e 5; intui-se que RTT tenderá também a assumir, alternadamente, dois valores, seja RTT 1 e RTT 5. Esses dois valores deverão satisfazer, cfr TCP08: Amostra: 1 RTT 1 = 0,9 RTT 5 + 0,1 Amostra: 5 RTT 5 = 0,9 RTT 1 + 0,5 A resolução deste sistema conduz a RTT 1 = 0,55 / 0,19 2,895 RTT 5 = 0,59 / 0,19 3,105 O timeout deverá fixar-se em RTT*y. Para que não haja retransmissões, é necessário que ele exceda o maior valor de RTT de facto experimentado, isto é, deve ser 1 < 3,105y e 5 < 2,895y que conduz a 0,19/0,59 < y ( 0,322<y) e 5*0,19/0,55 y ( 1,7272<y), de que se deduz: 1,7272<y TCP - Controlo de fluxo 29. [09T1.4] Dois computadores, W e E, comunicam através de uma ligação TCP que se encontra na fase congestion avoidance, com atraso ida-e-volta (RTT) de 100 ms. Suponha que a dado instante, digamos t 1, CongWnd=RecvWnd=20 segmentos (em que CongWnd é a janela de congestionamento e RecvWnd a janela anunciada pelo receptor nos pacotes ACK). O emissor é W e tem sempre dados para transmitir. O tamanho dos segmentos é 1000 bytes. Neste cenário, não há qualquer perda devida a congestionamento. Suponha também que, em t 1, o ritmo máximo a que o receptor consegue entregar dados à aplicação altera-se subitamente para 1.5 Mbps. Quanto tempo decorre (desde t 1 ) até que o receptor anuncie uma janela RecvWnd de 10 segmentos? [Nota: para simplificar, considere que o receptor anuncia apenas um novo valor de janela, no momento em que esta atinge o valor de 10 segmentos] R: (Número de rajadas necessárias * RTT) = 800 ms, pois: Défice Acumulado = RecvWnd Inicial - RecvWnd Final = = 10, Número de rajadas necessárias = (Défice Acumulado / Défice PorRajada), Défice PorRajada=(R Chegadas-R Entregas)*RTT==(R Chegadas-1,5)*10 6 * 100*10-3 R Chegadas =20*8*10 3 /(100*10-3 )=1,6 Mbps Défice PorRajada=10 4 bit ou 10 4 /(1000*8) =1,25 pacotes por RTT Número de rajadas necessárias = 8 Tempo necessário = 8 * 100 = 800 ms

8 Prof V Vargas, IST Nível Transporte (Modelo Internet) 03/11/11, Page 8 of 9 (ou, de maneira mais rápida, 8000*Défice Acumulado bit/[(r Chegadas-R Entregas) bps]=800 ms) Repare-se: TCP27.f representa a situação. O importante a reter é: se, com CongWnd=20, não há qualquer perda, então o Ack do primeiro segmento de uma janela chega após se ter esgotado a janela de congestionamento. Deduzse: W está enviando informação ao ritmo de R Chegadas = 1,6 Mbps. E estará entregando à Aplicação a esse mesmo ritmo de 1,6 Mbps. Intui-se que dispõe de buffer para 21 segmentos. Imediatamente antes de chegar outro segmento, cfr TCP27.g, liberta o espaço ocupado pelo mais antigo (que, na ausência de erros, será o último que foi recebido); recebe esse novo segmento, e devolve Ack com RecvWnd=20. O período entre chegadas é o mesmo que o período entre entregas: 5 ms (=100/20). Em t1, o período entre entregas à Aplicação aumenta, excede o período entre chegadas, cfr TCP27h. Num intervalo RTT, continuam a chegar 20 segmentos, mas o número de entregas diminui para 18,75 (=100*10-3 /[8000/(1,5*10 6 )]), ou seja: por cada RTT, a Janela de Recepção diminui de Défice=1,25 segmentos. Ao fim de quantos RTTs diminui de 10? Claramente, ao fim de 10/1,25=8, que cobre 800 ms. Por mor de rigor: após t1, cfr TCP27.h, quando o segundo segmento chega, ainda o anterior não foi entregue à Aplicação, pelo que o subsequente Ack deveria logo anunciar RecvWnd=19. A seu devido tempo, mais tarde, E deveria anunciar RecvWnd=18, e assim sucessivamente, i.e., W deveria ir regulando o seu ritmo, por forma a adaptar-se ao novo ritmo de entrega em E. A análise ficaria algo mais complicada - a janela iria oscilar entre 18 e 19 - e daí a simplificação feita: a actualização da janela é feita somente quando ela atinge o valor 10). 30. [09E2.4] Dois computadores, W e E, estão interligados a um nó de comutação de pacotes por linhas de capacidade 3 Mbps e 1 Mbps, respectivamente. O tempo de propagação em cada linha é de 1,5 msg. Considere que W e E executam o protocolo TCP sem quaisquer restrições devidas a congestionamento (i.e., somente com restrições devidas à memória do receptor). Considerando segmentos em trânsito no sentido W E, admita que E lhes reservou 9 kbit de memória. Desprezam-se o tempo de processamento e de espera em filas no nó e o tempo de transmissão dos cabeçalhos dos segmentos e dos Acks. Admita que é enviado um ACK por cada segmento recebido e que um segmento recebido é entregue à Aplicação somente depois de decorridos 4 ms contados a partir da recepção do seu último bit. Considere o envio de uma mensagem de 18 kbit repartida em segmentos de 3 kbit cada (numerados S0, S1, ) Qual é o valor máximo da janela de transmissão de W, em número de segmentos? Trace um diagrama temporal do envio da mensagem Qual a duração do primeiro intervalo de tempo em que W não transmite por esgotamento da Janela? Indique no diagrama temporal a dimensão da janela de recepção anunciada por E, nos Acks que W recebe durante esse intervalo No instante em que W inicia a transmissão do último segmento, qual a aresta inferior da sua Janela? Quanto tempo demora desde o início da transmissão até ter sido recebido pela aplicação o último bit da mensagem? Diga, em geral, se existe algum interesse em enviar um Acknowledge imediatamente após a recepção de um segmento no nível transporte, isto é, antes de ele ter sido entregue à Aplicação? R1: W=3 (=9/3) segmentos; R2: cfr fig TCP02.b; R3: 13 ms (= 3 * T E Xmt - 2 * T W Xmt +RTT) ms; T W Xmt=1 ms, T E Xmt=3 ms, RTT=4*1,5=6 ms R4: w=2; w=1; w=1, cfr fig TCP02.b R5: Winf=4; R6: 40 (=[1+3+RTT]+2*3+[1+3+RTT]+1+3+RTT/2+3+4) ms;

9 Prof V Vargas, IST Nível Transporte (Modelo Internet) 03/11/11, Page 9 of 9 R7: sim: se ele chegar correctamente ao transmissor, liberta a área de memória ocupada pelo segmento em causa e evita a sua retransmissão.