controlo de congestão em tcpweb.ist.utl.pt/d898/public/rc-i/problems/tcpcongestion.pdf · como se...

Prof V Vargas, IST Controlo de Congestão em TCP 03/11/11, of 27

Controlo de Congestão em TCP

{TCPCongestion.doc}

TCP - Controlo de congestão

1. Indique, justificando, se a seguinte afirmação é verdadeira, ou falsa: “O mecanismo de controlo de

congestionamento de um protocolo de transporte é usado para evitar que haja segmentos perdidos na rede.”.

2. [07E2.16] Indique dois modos possíveis de um emissor tomar conhecimento de congestionamento, mesmo não

havendo perda de pacotes

R: i) Notificação explícita pelo nível Rede (ex.:ATM-ABR) ; ii) detectar aumento do RTT (ex.: TCP).

3. [07E1] Explique, sucintamente, as diferenças entre os mecanismos de controlo de congestionamento previstos

no protocolo ABR (Available Bit Rate), para as redes ATM, e os mecanismos de controlo de congestionamento

presentes no protocolo TCP, na Internet

R: ABR: o emissor é notificado do estado de congestionamento da rede por células RM (Resource Management) - a que reaje regulando o ritmo de transmissão. Essas células são enviadas por ele mesmo, entrelaçadas com as células de dados - sendo-lhe depois "ecoadas" pelo receptor (mas também é possível um nó gerar uma célula RM e enviar-lha directamente). Na rota até ao receptor, os nós intermédios podem "decrescer" o campo ER (Explicit Rate) - que assim acabará por indicar o mínimo dos ritmos por eles suportados; ademais, podem marcar os bits NI (No Increase) ou CI (Congestion Indication), para indicarem Congestão (respectivamente moderada ou severa). O próprio receptor poderá marcar o bit CI se na última célula de dados por ele recebida o bit EFCI (Explicit Forward Congestion Indication) tiver sido marcado (por algum desses nós).

TCP: o emissor infere o estado de congestionamento da rede pela observação das perdas e atrasos; estes provocam variação no RTT, timeouts e/ou Acks duplicados - a que o emissor (nas versões Tahoe e Reno) reaje diminuindo subitamente a Janela de congestão e voltando a aumentá-la progressivamente (mecanismos Slow Start seguido de Congestion Avoidance).

4. Indique, justificando, se a seguinte afirmação é verdadeira, ou falsa: “O mecanismo de arranque lento (Slow-

Start) do TCP tem como objectivo ajustar o ritmo do emissor TCP ao ritmo do receptor TCP.”

5. [07E2.1] Um emissor TCP usa exclusivamente segmentos de 1000 octetos. Suponha que, de momento, este

emissor tem uma janela de congestionamento de 4000 octetos. De quantos octetos aumenta a janela se receber

um ACK não-duplicado e se o modo corrente fôr: i) Slow-start; ii) Congestion Avoidance.

R: I) 1000: ii) 250 octetos (Reparo: Uma Janela de Congestionamento de 4000 octetos habilita ao envio de 4 Segmentos de 1000 octetos;

quando acabarem de chegar os correspondentes 4 Acks, a Janela terá aumentado de: 4000 octetos em Slow-Start; 1000 octetos em Congestion Avoidance. Por Ack, aumentará, então, respectivamente, de 4000/4 e 1000/4 octetos)

6. [07E3.11] Considere uma ligação TCP entre W e E em que: MSS (Maximum Segment Size) está fixado em

1000 bytes, não ocorrem perdas nem os segmentos chegam fora de ordem e E devolve um Ack por cada 1000

bytes de dados recebidos. Considere a troca de segmentos representada em

TCP20.a em que, inicialmente, a janela de congestionamento de W é 2000

bytes. Como se observa na figura, W envia sucessivamente dois segmentos

com 500 bytes de dados, e mais outros dois Segmentos com 1000 bytes de

dados cada um.

Diga qual o número máximo, N, de segmentos com MSS Bytes de dados

que W pode enviar após receber o segundo Ack, nos casos seguintes:

1) Para o caso de W se encontrar na fase Slow-Start.

2) Para o caso W se encontrar na fase Congestion-Avoidance.

R1: 2000+2*1000-1000=3000 bytes=3 SegsMSS; R2: aproximadamente, 2000+2*500-1000=2000 bytes = 2 SegsMSS. Nota: Mais em rigor, a evolução da janela de congestionamento é:


Após a recepção do Inicial 1º Ack 2º Ack

Slow-Start 2000 2000+1000=3000 3000+1000=4000 Congestion-Avoidance 2000 2000+1000*(1000/2000)=2500 2500+1000*(1000/2500)=2900

Pelo que, para Congestion-Avoidance, seria, com mais rigor, N =(2900-1000)/1000 = 1 SegMSS

7. [08T1.7] Considere uma ligação TCP entre W e E em que o MSS (Maximum Segment Size) está fixado em

4000 Bytes, não ocorrem perdas nem os segmentos chegam fora de ordem. Além disso, E devolve um Ack por

cada par de segmentos recebidos ainda não confirmados. Considere a troca de segmentos mostrada em

TCP20.b. A dada altura, em W, a janela de congestionamento é 8000 Bytes. Sucessivamente, W envia três

segmentos com 3000, 1000 e 4000 Bytes de dados, como mostra a figura. Após receber o primeiro Ack, envia

mais três segmentos, com 1000, 3000 e 2000 Bytes de dados. Após receber o

segundo Ack, envia mais alguns segmentos, o primeiro deles com 4000 Bytes

de dados.

7.1. Para o caso de W se encontrar na fase Slow-Start;

a-1) Qual o número máximo, N, de Bytes de dados que W pode ainda

enviar ?

a-2) Quantos segmentos necessitará, no mínimo, para o fazer?

7.2. Para o caso W se encontrar na fase Congestion-Avoidance;

b-1) Qual o número máximo, N, de Bytes de dados que W pode ainda

enviar ?

b-2) Quantos segmentos necessitará, no mínimo, para o fazer ?

R: A: Em Slow-Start, a Janela de Congestão aumenta, por cada MSS confirmado, 1*MSS. No instante N, estão confirmados (3000+1000+4000+1000=) 9000 bytes = 2,25 MSS. Pelo que a Janela aumentou de 2*MSS: ficou em (8000+2*4000=) 16000. Como, após aqueles 9000 bytes, W enviou (3000+2000+4000=) 9000 bytes, W pode ainda enviar (16000-9000=) 7000 bytes, em 2 Segmentos, de 4000 e 3000 bytes.

B. Em Congestion Avoidance, a Janela de Congestão aumenta, por cada MSS confirmado, x% de MSS, em que % é a porção da Janela já confirmada. O 1º Ack confirma 4000 bytes (=1*MSS - que é 50% da Janela inicial); então, a Janela aumenta 50% de MSS, ficando (8000+4000*0,5=) 10000. O 2º Ack confirma 5000 bytes (isto é, 1,25 MSS; repare-se que 1*MSS é 40% da Janela actual); então, a Janela aumenta 40% de MSS, passando a ser (10000+4000*0,4=) 11600 bytes. Como após aqueles 9000 bytes W enviou entretanto (3000+2000+4000=) 9000 bytes, W pode ainda enviar (11600-9000=) 2600 bytes, em 1 Segmento.

8. [08E1.13] Considere uma ligação TCP entre W

e E, através da Internet. Os segmentos TCP têm

comprimento MSS=125 bytes, e RTT=10 mseg.

Sabe-se ainda que o bottleneck entre ambos (isto

é, a capacidade máxima disponível no caminho

entre ambos) é de 1 Mbps.

8.1. Qual é o tamanho máximo da janela de congestionamento?

8.2. Quanto tempo demora ela a atingir esse tamanho (admitindo-se que

até isso acontecer o transmissor permanece na fase SlowStart)? (Se não

fez a alínea anterior, considere que a resposta tenha sido 13)

R1: 11, pois, idealmente (cfr TCP27.d), (W-1)*TXmt=RTT, com TXmt= MSS/C → W=RTT*C/MSS+1=0,01*106/(125*8)+1=11. TXmt = 1ms R2: 46 ms, que se obtém de (cfr TCP27.e) T=(TXmt+RTT)*4+2 * TXmt =

(1+10)*4+2*1 ms

9. [07E2.3] Considere os dois métodos seguintes de resposta de um nó (router) ao congestionamento:

9.1. o nó descarta aleatoriamente pacotes antes da fila estar cheia;

9.2. o nó espera até a fila estar cheia e descarta todos os pacotes seguintes.

Explique porque é que, para uma fonte, é provavelmente mais rápido detectar as perdas provocadas pelo

primeiro método do que aquelas provocadas pelo segundo.

R: Para TCP, os eventos interpretados como perdas são: timeout e Acks duplicados; aqueles que conduzem a uma reacção menos rápida são os timeout. Comparando os dois métodos acima de resposta do "router",


- em 1), o nó descarta um pacote, seja Pdesc - mas aleatoriamente, isto é, um ou mais dos pacotes seguintes podem não vir a ser descartados; então, é algo provável chegarem ao destino alguns dos pacotes que a fonte transmitiu após Pdesc; irão ser "confirmados" por Ack duplicados - cuja recepção pela fonte a levará a concluir que Pdesc se perdeu…

- em 2), o nó descarta um pacote, seja Pdesc - e continua descartando os seguintes; então, é provável não chegarem ao destino os pacotes transmitidos após Pdesc; só quando o timeout expirar é que a fonte concluirá que ele se perdeu…

10. Suponha que uma aplicação no computador W estabelece uma conexão-TCP com uma aplicação no

computador E para receber o conteúdo de um ficheiro. O ficheiro tem 20 000 bytes; os segmentos de dados têm

1000 bytes de dados. Os computadores estão ligados por um canal full-duplex com débito 8 Mbps e um atraso

de ida e volta de RTT = 7 mseg. Pretende-se estimar a latência na recepção do ficheiro (intervalo de tempo

desde que o cliente inicia o pedido até que recebe o ficheiro na sua totalidade). Considere o seguinte modelo

simplificado (excepto quando fôr explicitamente indicado um outro comportamento):

- o pedido de transferência feito pelo cliente segue juntamente com o terceiro segmento do estabelecimento

da conexão;

- é enviado um segmento de confirmação (Acknowledge, abreviadamernte: Ack) por segmento bem recebido;

- a janela de emissão é apenas limitada pelos mecanismos de controlo de congestionamento, isto é, o

mecanismo de controlo de fluxo não intervém (os buffers na recepção são ilimitados);

- o protocolo TCP usa o mecanismo de controlo de congestionamento estudado nas aulas;

- não ocorrem erros nem perdas;

- o receptor não descarta segmentos recebidos fora de ordem;

- os cabeçalhos têm dimensão desprezável;

- o tempo de transmissão dos segmentos que não contêm dados (estabelecimento, pedido do ficheiro e Ack’s)

é desprezável

10.1. Admita que todos os segmentos são transmitidos durante a fase de arranque lento (“slow start”), isto é, o

limiar a partir do qual se inicia a fase de “congestion avoidance” nunca é atingido;

10.2. Admita que se perdem: o Segmento 6 e os Ack's dos Segmentos 8 a 11; o timeout utilizado é de 13 mseg.

10.3. Admita que se perde o Segmento 6; utiliza-se a versão TCP-Tahoe;

10.4. Admita que se perde o Segmento 6; utiliza-se a versão TCP-Reno;

Resolução (1): Conforme ao método seguido na resolução de problemas similares, a primeira etapa é: desenhar um diagrama temporal que esquematize fielmente a situação descrita. O diagrama temporal apresenta-se em TCP21.a.

W começa por estabelecer uma conexão com E; isso envolve a troca de dois segmentos, SYN (connect) e SYNAck (accept). Logo após, envia um segmento (simbolicamente, Get), referindo o ficheiro que pretende. E devolve esse ficheiro num total de 20 (=20000/1000) segmentos; cada um deles demora TXmt=1000*8/(8*106) seg=1 mseg a ser transmitido.

- De início, E encontra-se na fase Slow-Start - pelo que o tamanho da sua janela (entenda-se: janela de congestão) é de, apenas, w=1: envia o 1º segmento, {S1} - e aguarda…

(Nota: no presente contexto, em que o tamanho dos segmentos é fixo (1000 bytes), subentende-se: w é dado em "segmentos").

- Quando S1 chega a W, a entidade TCP devolve Ack2 - que adverte: W já está esperando o 2º Segmento, os anteriores-a-S2 já foram todos bem recebidos!

- Quando Ack2 chega a E, este (descarta-se de S1 e), incrementa (de 1) o tamanho da janela - ficando w=2: envia os segmentos {S2 e S3} - e aguarda…

(Recorde-se: na fase Slow-Start, o tamanho da janela de congestão é incrementado de 1 por cada Ack fresco recebido - com esta consequência: se, em dado momento, ele é w - permitindo o envio de w segmentos -, então, quando forem recebidos os Ack's de todos esses segmentos, ele duplica, passará a ser 2*w).

- Quando S2 e S3 chegam a W, este devolve Ack3 e Ack4. - Quando Ack3 chega a E, este incrementa (de 1) o


tamanho da janela, ficando w=3: envia {S4 e S5} (Note-se: w=3 significa que podem ficar por confirmar um máximo de 3 segmentos; como está ainda por confirmar a recepção do segmento S3, podem ser enviados apenas mais dois segmentos).

- Quando S4 e S5 chegam a W, este devolve Ack5 e Ack6. - Quando Ack4 chegar a E, este incrementa (de 1) o tamanho da janela, ficando w=4: envia {S6 e S7}. - Quando S6 e S7 chegam a W, este devolve Ack7 e Ack8. - Quando {Ack5, Ack6, Ack7 e Ack8} chegam a E, este incrementa o tamanho da janela, ficando sucessivamente w={5, 6,

7 e 8}: E envia, sucessivamente, {S8 e S9}, {S10 e S11}, {S12 e S13} e {S14 e S15}. - Quando {S8 , …, S15} chegam a W, este devolve {Ack9 , … , Ack16}. - O resto adivinha-se: à medida que os Ack's chegam a E, este incrementa o tamanho da janela e envia

sucessivamente {S16 a S20}.

A janela de E evolui (roda e o seu tamanho altera-se) pari passu com a chegada de Ack's a E, cfr TCP21.b: [1] → [2 3] → [3 4 5] → [4-5 6 7] → [5-7 8 9] → … → [11-19 20]

Na prática, E despacha uma janela com 1 segmento, {1}; depois, despacha uma janela com 2 segmentos {2-3}; depois, uma janela de 4 segmentos {4-7}; e, no fim, os 13 segmentos {8-20} que restam para perfazer os 20 segmentos em que se volve o ficheiro.

Entre duas janelas consecutivas, E fica bloqueado (isto é, sem transmitir) algum tempo: - entre o termo do envio de S1 e o começo do envio de S2, E fica bloqueado wait=RTT=7; - entre o termo do envio de {S2-S3} e o começo do envio de S4, E fica bloqueado wait=RTT-TXmt=6; - entre o termo do envio de {S4-S7} e o começo do envio de S8, E fica bloqueado wait=RTT-3*TXmt=4… E vai ficando bloqueado um período de tempo cada vez menor. Mais genericamente, fica bloqueado RTT-(w-1)* TXmt. Existe um valor w que torna nulo esta expressão: a partir desse valor, E deixa de ficar bloqueado! Esse valor é

w=RTT/TXmt+1=8: entre o termo do envio de {S8-S15} e o começo do envio de S16, E fica bloqueado wait=0 (=RTT-7*TXmt) mseg. O significado físico é o seguinte: Ack9 chega a E exactamente no instante em que E esgota a sua janela; como essa chegada re-abre essa janela, E, após o envio de S15, não chega a ficar bloqueado: prossegue de imediato com a transmissão de {S16 e S17} - e, continuamente, com a transmissão de todos os segmentos restantes, {S18 a S20}, sem qualquer paragem.

A partir do diagrama temporal TCP21.a, a resposta à questão proposta (qual o tempo de latência?), volve-se em simples geometria euclideana: trata-se de determinar quanto tempo medeia entre T0 e T6. Ele será o somatório dos tempos parciais {T0 a T1}, {T1 a T2}, {T2 a T3}, {T3 a T4}, {T4 a T5} e {T5 a T6}. Repare-se:

- {T0 a T1} e {T1 a T2} são, ambos, RTT; - entre T2 e T3, i.e., a chegada do primeiro bit da primeira janela ({S1}) e a chegada do primeiro bit da janela

seguinte({S2-S3}), decorreTXmt+RTT; asserções idênticas podem fazer-se a respeito dos tempos parciais {T3 a T4}, {T4 a T5}; - entre T5 e T6, i.e., entre a chegada do primeiro bit da última janela e a chegada do seu último bit, decorre 13*TXmt. O tempo de latência vem então a ser: ∆T = 2 * RTT + ( TXmt + RTT ) * 3 + ( 13 * TXmt ) = 51 mseg.

Nota: num cenário real, 1) o receptor pode escusar-se a replicar com um Ack por cada Segmento recebido e 2) o Ack pode perder-se ou corromper-se. Então, à chegada de um Ack, w poderá ser incrementado - não de 1 -, mas do número de Segmentos que ele confirma; em particular, isso previne:

- a possibilidade de o receptor utilizar um Ack para confirmar dois Segmentos, que não um só; - a eventualidade de o Ack se perder/corromper no caminho de regresso até à fonte dos Segmentos. Por ex., tendo E enviado a janela {S4-S7}, W poderá replicar com apenas dois Ack's {Ack6 e Ack8} - e o primeiro deles

perder-se, por conseguinte chegando a W apenas o Ack8; ele confirma, sozinho, a chegada de 4 Segmentos - por conseguinte habilitando à mudança do tamanho da janela, num ápice, de 4 para 8.

Também num cenário real, os Segmentos não têm necessariamente um tamanho fixo; então, w poderá ser incrementado (de 1) apenas quando o número de bytes confirmados pelos Ack's precedentes atingir MSS.

Também num cenário real, a confirmação é de bytes e, não, de segmentos.



O diagrama é semelhante a TCP21.a até ao momento em que E envia a janela {S4-S7}: acontece que, agora, S6 se perde - e, por conseguinte,

- não apenas a entidade TCP em W não pode confirmar (com {Ack7}), a recepção de S6… - como, ao receber S7, ela permanece devolvendo Ack6 - não caindo na asneira de devolver Ack8 - que para E

significaria que W já recebeu todos os segmentos até S8, exclusivé - o que não é verdade… - Resumindo: quando {S4, S5 e S7} chegam a W, este devolve Ack5, Ack6 e Ack6. - Quando {Ack5 e Ack6} chegam a E, este incrementa a janela, ficando sucessivamente w={5, 6}: E envia {S8 e S9} e

{S10 e S11}; quando o segundo Ack6 chega a E, o tamanho da janela não se altera, nem se enviam outros segmentos. - Quando {S8 - S11} chegam a W, este devolve quatro Ack6s, que, de acordo com o enunciado, se perdem. Não recebendo Ack's frescos, o relógio em E expira.

Abra-se um parêntesis para rever a política de relógio de retransmissão do TCP: - quando, nomeadamente, E recebe Ack5, que confirma a chegada a W de S4, E cancela o relógio - mas, recordando

que tem pendente de confirmação outros segmentos (concretamente {S5-S7}), re-arma-o; - quando E recebe Ack6, que

confirma a chegada a W de S5, E volta a cancelar o relógio - mas, recordando que ainda tem pendente de confirmação os segmentos {S6-S7}, arma-o de novo;

- quando E recebe o segundo Ack6, E repara que ele confirma a recepção de um segmento cuja

recepção já havia sido confirmada - pelo que não mexe no relógio.

Resumindo: o relógio vem a expirar Timeout =13 mseg após o último Ack fresco (i.e., não duplicado) recebido.

- Quando o relógio expira, E leva a efeito o seguinte: memoriza em SSThreshold o valor que resulta de dividir por 2 o tamanho da janela actual (i.e., memoriza SSThreshold = 3); fixa w=1; envia o Segmento mais antigo ainda por confirmar - no caso, S6. Entra na fase Slow-Start,

- Quando S6 chega a W, a entidade TCP devolve Ack12 - querendo com isso advertir: W já está esperando o Segmento S12, os anteriores-a-S12 já foram todos bem recebidos!

- Quando Ack12 chega a E, este, conforme à política Slow-Start, incrementa (de 1) o tamanho da janela - ficando w=2: envia {S12 e S13} - e aguarda…

- Quando S12 e S13 chegam a W, este devolve Ack13 e Ack14. - Quando Ack13 chega a E, este incrementa (de 1) o tamanho da janela - ficando w=3: envia {S14 e S15} - e aguarda… - Acentue-se: o tamanho da janela de E passou a ser w=3 - que é o valor memorizado em SSThreshold. Então, quando

Ack14 chega a E, este abandona a fase Slow-Start - ingressando na fase Congestion-Avoidance. O tamanho da janela é incrementado de, apenas, 1/3 - ficando w=3+1/3 - que não permite enviar senão um segmento mais, S16…

(Recorde-se: na fase Congestion-Avoidance, se, em dado momento, o tamanho da janela de congestão vale w - permitindo enviar w segmentos -, ela é incrementada de 1/w por cada Ack fresco recebido; quando forem recebidos os Ack's de todos esses w segmentos, a janela incrementou de 1).

- Quando {S14 - S16} chegam a W, este devolve Ack15 - Ack17. - Quando Ack15 e Ack16 chegam a E, este, por cada um, incrementa o tamanho da janela de 1/3 - ficando w=4;

sucessivamente, envia {S17} e {S18 - S19}. - Quando Ack17 chega a E, este incrementa o tamanho da janela de 1/4 - ficando w=4+1/4 - que não permite enviar

senão um segmento mais, S20…

A janela de E evolui pari passu com a chegada de Ack's a E - e o expirar do relógio, cfr TCP22.b.


A partir do diagrama temporal TCP22.a, a resposta à questão proposta (qual o tempo de latência?), volve-se em simples geometria euclideana: será o somatório de um conjunto de tempos parciais… Seguindo um raciocínio análogo àquele que acompanhou a resolução da alínea anterior, o tempo de latência vem então a ser:

∆T = 2 * RTT + ( TXmt + RTT ) * 3 + ( TXmt + Timeout ) + ( TXmt + RTT ) * 3 + ( 4 * TXmt ) = 80 mseg.

Nota 1: quando w atinge SSThreshold (no caso, aquando da chegada de Ack13), a entidade-TCP é livre de escolher entre: ingressar de imediato na fase Congestion-Avoidance (como se optou acima) ou manter-se na fase Slow-Start (por conseguinte fixando w=4, e não w=3+1/3, à chegada de Ack14); mas, desde que w se torne superior a SSThreshold, é obrigatório o ingresso na fase Congestion-Avoidance.

Nota 2: num cenário real, w é dado em bytes; quando o timeout ocorre, o SSThreshold é fixado em metade do número de bytes ainda por confirmar (e não em metade do valor actual de w).

Nota 3: em rigor, se, na fase Congestion-Avoidance, a regra em vigor fôr incrementar w de 1/w por cada Segmento confirmado, então a evolução de w será algo diferente da

apresentada: esta deve ser vista somente como uma aproximação; em particular, quando se receberem os Ack's de todos os segmentos de uma janela, aquela regra não resulta num incremento total de 1! Considere-se por ex., que, sendo w=3, se enviaram 3 segmentos; quando chegar o Ack do primeiro deles, passará a ser w=3+(1/3)=10/3; quando chegar o Ack do segundo, passará a ser 10/3+3/10=109/30 - e, não, 3+(2/3); e, quando chegar o Ack do terceiro, passará a ser 109/30+30/109=12781/3270≈3,9 que é menor que 3+(3/3)=4!

Resolução (3): Conforme ao método seguido na resolução de problemas similares, a primeira etapa é: desenhar um diagrama temporal que esquematize fielmente a situação

descrita. O diagrama temporal apresenta-se em TCP23.a.

O diagrama é semelhante a TCP22.a até ao momento em que E recebe os Ack's dos Segmentos 8 a 11: E recebe um total de seis Ack6: um fresco e cinco duplicados - pelo que, vigorando a versão TCP-Tahoe, o timeout não chega a expirar. Ao receber o terceiro duplicado, a entidade-TCP em E procede como se o timeout tivera expirado nesse momento: memoriza em SSThreshold o valor que resulta de dividir por 2 o tamanho da janela actual (i.e., memoriza SSThreshold =3); fixa w=1;


envia o Segmento mais antigo ainda por confirmar - no caso, S6. Entra na fase Slow-Start… O resto adivinha-se, cfr fig TCP23.a.

A janela de E evolui pari passu com a chegada de Ack's a E - e a chegada do 3º duplicado, cfr TCP23.b. A partir do diagrama temporal TCP23.a, a resposta à questão proposta (qual o tempo de latência?), volve-se em

simples geometria euclideana: será o somatório de um conjunto de tempos parciais… Seguindo um raciocínio análogo àquele que acompanhou a resolução das alíneas anteriores, o tempo de latência vem então a ser:

∆T = 2 * RTT + ( TXmt + RTT ) * 3 + ( 2 TXmt + RTT ) + ( TXmt + RTT ) * 3 + ( 4 * TXmt ) = 75 mseg.


O diagrama é semelhante a TCP23.a até ao momento em que E recebe o terceiro duplicado de Ack6: a entidade-TCP em E continua a memorizar em SSThreshold o valor que resulta de dividir por 2 a janela actual (i.e., memoriza SSThreshold =3); mas fixa w=SSThreshold+3=6. Entra na fase Slow-Start…

Quando chega o quarto duplicado de Ack6, w incrementa (de 1), para 7 - o que permite o envio de um Segmento mais, S12; e quando chega o quinto duplicado, w incrementa de novo, permitindo o envio de S13.

- Quando S6 e {S12 e S13} chegam a W, este devolve Ack12 e {Ack13 e Ack14}. - Quando Ack12 chega a E, este repara que se trata do primeiro Ack fresco após o 3º duplicado, pelo que: fixa

w=SSThreshold=3 e envia o segmento {S14} - e ingressa na fase Congestion-Avoidance; - Quando {Ack13 e Ack14} chegam a E, a janela é incrementada, de cada vez, de, apenas, 1/3 - ficando sucessivamente

w={3+1/3 e w=3+2/3} - que não permite enviar senão dois segmento mais, {S15 e S16} … O resto adivinha-se, cfr fig TCP24.a.

A janela de E evolui pari passu com a chegada de Ack's a E - incluindo o 3º duplicado e seguintes, cfr TCP24.b. A partir do diagrama temporal TCP24.a, a resposta à questão proposta (qual o tempo de latência?), volve-se em

simples geometria euclideana: será o somatório de um conjunto de tempos parciais… Seguindo um raciocínio análogo àquele que acompanhou a resolução das alíneas anteriores, o tempo de latência vem então a ser:

∆T = 2 * RTT + ( TXmt + RTT ) * 3 + ( 2 TXmt + RTT ) + ( TXmt + RTT ) * 2 + ( 4 * TXmt ) = 67 mseg.

11. [08T1.8] Um cliente pretende fazer o download de um ficheiro de tamanho 25.000 bytes, usando o protocolo

TCP-Reno através de uma única ligação. Assuma que o pedido de transferência feito pelo cliente segue

juntamente com o terceiro segmento da fase de estabelecimento da sessão TCP. Desprezam-se quaisquer

tempos de processamento no cliente e no servidor. Considere que:

(i) os segmentos TCP com dados são de dimensão L=1000 bytes e o comprimento dos cabeçalhos (de todos os

protocolos da pilha) é desprezável;

(ii) a ligação tem um débito R=8 Mbit/s e o atraso de ida-e-volta é RTT = 20 ms (o RTT está exactamente

repartido, isto é, o tempo de ida é 10 ms e o tempo de volta é 10 ms);

(iii) sómente os pacotes com dados não têm tempos de transmissão desprezáveis;

(iv) é enviado um segmento de confirmação (ACK) por cada segmento bem recebido;

(v) a janela TCP de emissão no servidor é apenas limitada pelos mecanismos de controlo de congestionamento

(isto é, os buffers na recepção do cliente são ilimitados);

(vi) nesta implementação, os segmentos que forem recebidos fora de ordem são aceites pelo receptor;

(vii) o limiar (threshold) entre a fase slow-start e a fase congestion avoidance é 8;

(viii) o valor do timeout é de 45 ms.

Suponha que durante a transmissão não há perdas nem erros nos segmentos TCP, mas ocorre um atraso

adicional de 22 ms no segmento 15 (portanto, decorre um tempo total de 22+10=32 ms, desde que termina o

envio do segmento 15 pelo emissor até este ser totalmente recebido pelo receptor).

Apresente um diagrama temporal que ilustre a sequência de segmentos trocados (e respectivos ACKs) até que o

ficheiro seja totalmente recebido pelo cliente. Calcule o tempo necessário até à completa recepção do ficheiro

pelo cliente, medido desde o instante em que o cliente inicia o estabelecimento da ligação. No diagrama,

indique os valores para a janela de congestionamento do servidor.

R: O Tempo de transmissão de cada segmento é: TXmt=1000*8/(8*106) seg= 1 mseg. Há que transmitir 25000/1000=25 segmentos.


Em TCP27.a, esquematiza-se a evolução da transferência. Pelo que o tempo necessário é: T=7*RTT+12*TXmt=7*20+12*1=152 mseg.

O valores de w pautam a evolução (aproximada) da janela de congestionamento do servidor.

12. Considere um comportamento dinâmico idealizado para uma sessão TCP, no qual um, e um só, segmento é

perdido quando a janela de congestão atinge o valor W segmentos.

12.1. Mostre que a fracção de segmentos perdidos vem dada por L=1/[3/8 W2+ 3/4 W]

12.2. Use o resultado anterior para mostrar que, se a fracção de perda de segmentos é L, então o débito da

sessão é aproximadamente igual a R =1.22 MSS / RTT

1/√L

Resolução: Em TCP09.a, encontra-se um diagrama temporal que

esquematiza a evolução da janela de congestão. Nele, foi tido em consideração o seguinte:

- no instante T0, a janela de congestão atinge o valor W; um segmento é perdido… pelo que,

- no instante T1, a janela de congestão é reduzida para metade, W/2;

- em T2, a janela de congestão é incrementada de 1, para W/2+1; - sucessivamente, a janela vai sendo incrementada de 1, para

W/2+2, W/2+3,… - até que, em T5, a janela de congestão volta a atingir o valor W, de novo se perdendo um segmento… e de novo se

reduzindo a janela a W/2… e de novo se reproduzindo o "ciclo" acima… Entre T1 e T5, inclusivé, o número de segmentos perdidos foi apenas de 1 (aconteceu precisamente em T5). Em

ordem a determinar que fracção é que isso representa, há que determinar o número total de segmentos enviados entre T1 e T5. Por conferência do diagrama, deduz-se que ele é de

NTotalDeSegmentos = W/2 + (W/2+1) + (W/2+2) + … + (W-1) + W. Esta é uma expressão bem conhecida: é a soma dos primeiros W/2+1 termos de uma sucessão aritmética, de

expressão geral u(n): W/2+n-1 (repare-se que o número de termos envolvidos, que é aliás o número total de janelas enviadas, é de NJanelas =W-(W/2)+1, que se volve em W/2+1); por manipulações aritméticas triviais, chega-se a NTotalDeSegmentos=[(u1+un)/2]*n=(W/2+W)*(W/2+1)/2=3W2/8+3W/4. A fracção de segmentos perdidos, L, é, pois, de 1/NTotalDeSegmentos=1/[3W2/8+3W/4].

Quanto à avaliação do débito da sessão, uma olhadela ao diagrama temporal patenteia um "ciclo", entre T0 e T5, que se repete indefinidamente… Entre T1 e T2, foram enviados W/2 segmentos, cada um com MSS (MessageSegmentSize) bits; o débito nesse intervalo de tempo é então de W/2*MSS/(T2-T1) bps. Já entre T2 e T3, foram enviados W/2+1 segmentos; o débito nesse intervalo de tempo será então de (W/2+1)*MSS/(T3-T2) bps. Claramente, o débito está variando ao longo da sessão… Ainda assim, poder-se-á avaliar o débito médio: bastará determinar quantos bits foram enviados durante aquele ciclo, T0 a T5, e qual a duração deste - e proceder à respectiva razão:

DébitoMédio=NúmeroDeBitsTransmitidos/(T5-T0). - conhecido o número total de segmentos transmitidos e o tamanho em bits de cada um, o numerador da fracção

acima volve-se em NTotalDeSegmentos * MSS;


- já quanto ao denominador, repare-se que o período de tempo entre T0 e T1 (ou T1 e T2, etc) é aproximadamente RTT; pelo que o período de tempo entre T0 e T5 é de RTT* (W/2+1).

O débito da sessão é então de NTotalDeSegmentos * MSS/[ RTT* (W/2+1)]. Da expressão acima deduzida, L=1/[3W2/8+3W/4], retira-se W2+2W=8/(3L), e, por conseguinte, W=−1+√[1+8/(3L)]. O débito médio da sessão será, então, e recordando que NTotalDeSegmentos=(W/2+W)*(W/2+1)/2=(3W/4)*(W/2+1),

Comentário a propósito: A resolução acima baseou-se num modelo ultra-simplificado. Por mor de uma maior aproximação à realidade, é

hora de apresentar um diagrama temporal do fluxo de segmentos trocados; ele encontra-se na figura TCP09.b. Nele, foi tido em consideração o seguinte:

- está-se recorrendo à filosofia Selective-Repeat; - quando chega a B o Segmento que se aguarda, B espera algum tempo pelo segmento seguinte, para, com um

único Ack, confirmar a chegada de dois segmentos… Designe-se por Cw a Janela de Congestão; e admita-se que A se

encontra no estado Congestion Avoidance. A evolução no tempo, a partir do momento em que se verifica Cw=7, é como segue:

- A envia 7 (sete) segmentos {S0 - S6} a B; - à chegada de S0, B aguarda; quando chegar S1, B devolve Ack2… - de uma maneira análoga, B devolve Ack4, Ack6, Ack7… - à chegada de Ack2 - que confirma a boa recepção de dois

segmentos -, A envia {S7 - S8}; sucessivamente, A envia {S9 - S10} e {S11 - S12}; mas, quando chega Ack7, a Janela de Congestão aumenta para Cw=8, e A envia {S13 - S14}…

- admita-se que S14 se perde (devido a mecanismos de controlo de congestão, a rede "apaga-o")…

- em virtude da chegada de S7 e S8,… S13, B devolve Ack9, Ack11, Ack13 e Ack14…

- à chegada de Ack9, A envia {S15 - S16}; sucessivamente, A envia {S17 - S18} e {S19 - S20}; e, quando chega Ack14 A envia { S21}…

- à chegada de qualquer destes sete segmentos, B ainda continua aguardando S14 - pelo que replica, a cada um deles, com Ack14…

- quer dizer: A, irá receber sete Ack14…: todos eles são duplicados do primeiro Ack14 recebido! Quando A receber o terceiro desses duplicados, executa o procedimento "fast retransmit": retransmite de imediato o segmento S14; adicionalmente, fixa Threshold=CW/2 e CW=Threshold=4. O procedimento será similar quando A receber mais três desses duplicados: retransmite de novo S14; ademais, fixa Threshold=CW/2 e CW=Threshold=2.

- à chegada do primeiro destes segmentos S14, B está-o aguardando… Pelo que o aceita… e, verificando que já recebeu até S21, devolve Ack22… Quando chegar o segundo desses segmentos S14, B descarta-o, mas devolve de novo Ack22…

- à chegada do primeiro destes Ack22, A actualiza a sua Janela de Congestão: fica sendo Cw=3… Pelo que envia três segmentos {S22-S24}… À chegada do segundo Ack22, A limita-se a registar que foi recebido um duplicado…

Nota: o leitor não deverá estranhar que a Janela de Congestão aumente de Cw=2 para Cw=3… Há que reparar, em primeiro lugar, que o número de segmentos confirmados por Ack22 é de 22-14=8… Ora, a janela Cw=2 cobria os segmentos {S14 - S15}; bastaria a recepção de um Ack confirmando 2 segmentos para ela aumentar para Cw=3.

Na figura, é patente que, entre o momento em que Cw atinge o seu valor máximo, W=8, e o momento em que Cw=W/2, existe um período transitório - que não foi considerado na determinação do valor L acima. Pelo que, ao valor L acima deverá então adicionar-se o seguinte:

- W-1 segmentos (aqueles que correspondem em TCP09.b à sequência {S15-S21}); - d = Int [(W-1)/3] segmentos (aqueles que correspondem em TCP09.b à sequência {S14-S14}); - j segmentos (aqueles que correspondem em TCP09.b à sequência {S22-S24}). (Para o cálculo de j, convém determinar qual o menor valor atingido por Cw no período de transição; genericamente,

será Cw =W/2d… Postulando que 1≤ Cw, deduz-se que, para 9<W, o mínimo de Cw é de 1; então, para 9<W, j deverá ser 2+3+…+W/2-1, que se volve em j=(W/2+1)*(W/2-2)/2…)


O leitor poderá verificar qual a dimensão do período transitório em outras situações, como sejam: aplicação de GoBack-N, que não SelectiveRepeat; perda de Ack do último segmento de uma janela, em vez do próprio segmento… detecção de perda por timeout, e não por detecção de três duplicados de um Ack…

13. Pretende transmitir-se um ficheiro de tamanho 50 Mbit usando segmentos de dimensão 500 kbit através de uma

única ligação de capacidade 50 Mbps. O tempo de ida e volta da ligação, RTT, é de 100 ms...

13.1. Determine o tempo que decorre entre o pedido e a recepção de todo o ficheiro se a aplicação de

transferência de ficheiros usar o protocolo de transporte UDP.

13.2. Suponha agora que a aplicação de transferência usa como protocolo de transporte uma versão

modificada do TCP que executa apenas uma fase de “congestion-avoidance” com janela inicial de 8

segmentos. Esboce um diagrama temporal da troca de segmentos e determine o tempo que decorre desde o

instante em que a aplicação faz o pedido até que recebe todo o ficheiro.

13.3. Suponha agora que a aplicação de transferência de ficheiros pode pedir a abertura de 2 ligações TCP

independentes transferindo metade do ficheiro em cada uma delas. Considere o TCP modificado descrito na

alínea anterior. Determine, tal como atrás, o tempo que decorre desde o instante em que a aplicação faz o

pedido até que recebe todo o ficheiro. Note que a capacidade disponível para cada ligação TCP é reduzida a

metade relativamente à alínea anterior.

14. [06E3] Um cliente pretende fazer o download de um ficheiro de tamanho 45.000 bytes, usando o protocolo

TCP através de uma única ligação. Considere que: (i) os segmentos TCP com dados são de dimensão L=1000

bytes; (ii) a ligação tem um débito R=8 Mbit/s e o atraso de ida e volta é RTT=20 ms.

14.1. Considere que o limiar entre a fase de “slow-start” e a fase de “congestion avoidance” da sessão TCP é

8. Suponha que durante a transmissão, o segmento 29 se perde e que essa perda é detectada por timeout

(considere um intervalo de expiração de 20 ms). Assuma também que todos os segmentos que forem

recebidos fora de ordem

são descartados pelo

receptor e que não se

verificam mais perdas

até ao final da

transmissão. Apresente

um diagrama temporal

que ilustre a sequência

de segmentos trocados

até que o ficheiro seja

totalmente recebido pelo

cliente. Calcule o tempo

necessário até à

completa recepção do

ficheiro pelo cliente

(medido desde o instante

em que o cliente inicia o

estabelecimento da

ligação).

R: T=2 * RTT + (TXmt+RTT)*6+4 TXmt +(TXmt +RTT)*4+5 TXmt =40+210+9=259 mseg (cfr TCP15.a) 14.2. Suponha agora que a janela do cliente está limitada a 15 segmentos e que

o ficheiro a transmitir tem um tamanho infinito. Diga, justificando, qual o

valor máximo de atraso de ida e volta (RTT) que a ligação deveria ter para se

conseguir, a longo termo, uma eficiência de utilização do caminho de 100 %.

R: RTT =(15-1)*TXmt → W=14 (cfr TCP15.b)

15. Suponha que uma aplicação no computador A pretende enviar o conteúdo de um ficheiro para uma aplicação

no computador B. O ficheiro tem 12 000 bytes. Os computadores estão ligados por uma linha com débito R = 4

Mbps, com um atraso de ida e volta de RTT = 5 ms, tendo os segmentos TCP uma dimensão máxima de S = 500

bytes. Admita que já são enviados dados no terceiro segmento do estabelecimento da ligação TCP. Ilustrando


cada situação com um diagrama temporal, qual o tempo mínimo para o ficheiro ser totalmente recebido em B,

incluindo o estabelecimento de ligação, nas seguintes condições:

15.1. O TCP não utiliza mecanismos de controlo de congestionamento (nem fase de arranque lento, "slow-

start", nem fase de "congestion avoidance").

15.2. O TCP utiliza o mecanismo de arranque lento ("slow-start"), mas não usa o mecanismo de "congestion

avoidance".

15.3. O TCP utiliza o mecanismo de arranque lento ("slow-start"), mudando para a fase de "congestion

avoidance" quando a janela atinge os 4 segmentos.

16. [05T1] Uma aplicação de transferência de ficheiros funciona no modo cliente servidor e usa o protocolo

TCP no nível de transporte. A parte cliente da aplicação pretende copiar, do servidor, um ficheiro. Na

comunicação dos dados usam-se segmentos de dimensão 500kbit através de uma única ligação de capacidade

50Mbps. O tempo de ida e volta da ligação, RTT, é de 50ms. Para cada um dos seguintes casos, apresente um

diagrama temporal, aproximadamente à escala, que ilustre a sequência de segmentos trocados até que todo o

ficheiro é recebido, e determine a latência desta transferência.

16.1. Suponha que o TCP está, durante toda a comunicação de dados, na fase de arranque lento (“slow-start”),

e que o ficheiro a transmitir tem 7 Mbit.

16.2. Admita agora que o TCP inicia o seu funcionamento na fase de arranque lento (“slow-start”) mas que,

quando a janela de congestionamento atinge o valor de 4 segmentos, passa à fase de “congestion

avoidance”.

16.3. Repita as duas alíneas anteriores, mas admitindo que o ficheiro a transmitir tem 10 Mbit.

TXmt =500k/50M=10 mseg R1,2: Número de Segmentos: 7M/500k=14 Segmentos R1: Dimensões das (4) Janelas transmitidas: 1+2+4+7 Segmentos cada Latência: RTT + 4*(RTT+TXmt)+6*TXmt, = 350 mseg. R2: Dimensões das (5) Janelas transmitidas: 1+2+4+5+2 Segmentos cada Latência: RTT + 5*(RTT+TXmt)+1*TXmt, = 360 mseg. R3: Número de Segmentos: 10M/500k=20 Segmentos R31: Dimensões das (4) Janelas transmitidas: 1+2+4+13 Segmentos cada Latência: RTT + 4*(RTT+TXmt)+12*TXmt, = 410 mseg. R32: Dimensões das (5) Janelas transmitidas: 1+2+4+5+8 Segmentos cada Latência: RTT + 5*(RTT+TXmt)+7*TXmt, = 420 mseg.

17. [05E1] Um cliente HTTP pretende fazer o download de 1 página constituída por 2 objectos: o objecto base

com 1000 bytes e outro referenciado no objecto base com 2500 bytes. Pretende-se estimar a latência na

recepção da página. Para isso há que estabelecer ligações TCP entre cliente e servidor. Considere que: (i) os

segmentos TCP com dados são de dimensão S= 100 bytes; (ii) o canal entre emissor e receptor é “full-duplex”

com débito R= 800000 bps e introduz um atraso de ida e volta RTT= 9 ms.

17.1. Admita que usa a versão 1.0 do protocolo HTTP. Qual é a latência na recepção da página obtida para o

caso em que usa uma versão modificada do protocolo TCP com janela de emissão fixa de 25 segmentos?

17.2. Continuando a supor utilização de HTTP1.0, admita agora que o protocolo TCP usa o mecanismo de

controlo de congestionamento e todos os segmentos são transmitidos durante a fase de arranque lento

(“slow-start”), isto é, o limiar a partir do qual se inicia a fase de “congestion avoidance” nunca é atingido.

Apresente um diagrama temporal, aproximadamente à escala, que ilustre a sequência de segmentos trocados

até que o objecto base seja recebido pelo cliente. Qual a latência na recepção da página (conjunto de 2

objectos) ?

17.3. Considere agora que usa a versão 1.1 do protocolo HTTP com possibilidade de pedidos em sequência

(“pipelining”) nas condições definidas para o TCP na alínea anterior. Calcule a latência no download da

página (conjunto de 2 objectos)

Resolução (1): O diagrama temporal apresentado em TCP01.a descreve a situação considerada. O cliente-HTTP começa por estabelecer uma conexão-TCP com o servidor-HTTP; isso envolve a troca de dois

segmentos, SYN (connect) e SYNACK (accept). Logo após, envia um request-HTTP, referindo o primeiro Objecto; isso envolve um segmento-TCP. O servidor localiza o objecto referenciado, de 1000 bytes, e devolve-o numa response-HTTP. A entidade TCP do servidor divide-a em segmentos com 100 bytes de dados cada, resultando um total de 1000/100=10


segmentos. Como dispõe de uma janela fixa de 25 segmentos, envia-os a todos de imediato. Quando o 10º segmento chegar ao Cliente, a entidade TCP local dá por terminada a construção da response-HTTP, e passa-a ao programa de navegação. Este requere de imediato o segundo Objecto. O procedimento subsequente é análogo ao que se enuncia acima: estabelecimento de uma nova conexão-TCP, envio de request-HTTP, referindo agora o segundo Objecto, devolução da pertinente response-HTTP, através de 2500/100=25 segmentos. Quando o 25º segmento chegar ao Cliente, a entidade TCP local dá por terminada a construção da response-HTTP, e passa-a ao programa de navegação. O tempo de latência vem então a ser (cfr o diagrama temporal):

∆∆∆∆T = 2 RTT + T1000Bytes+ 2 RTT + T2500Bytes, em que RTT = 9 mseg e TNBytes = TTransmissãoDeNBytes = TRecepçãoDeNBytes = N*8/800000 seg=N/100 mseg, e por conseguinte ∆∆∆∆T = 4 * 9 + (1000+2500)/100 = 36+35=71 mseg. Resolução (2): O diagrama temporal

TCP01.b apresentado descreve a situação considerada.

O cliente-HTTP começa por estabelecer uma conexão-TCP com o servidor-HTTP; isso envolve a troca de dois segmentos, SYN (connect) e SYNACK (accept). Logo após, envia um request-HTTP, referindo o primeiro Objecto; isso envolve um segmento-TCP. O servidor localiza o objecto referenciado, de 1000 bytes, e devolve-o numa response-HTTP. A entidade TCP do servidor divide-a em segmentos com 100 bytes de dados cada, resultando um total de 1000/100=10 segmentos. De início, dispõe de uma janela de w=1 segmento; pelo que envia apenas o 1º segmento. Quando este chegar ao Cliente, a entidade TCP devolve ACK. Quando este chegar ao Servidor, este incrementa (de 1) a janela, ficando w=2 segmentos; pelo que envia o 2º e 3º segmentos. Quando o 2º segmento chegar ao Cliente, é devolvido ACK. Quando este chegar ao Servidor, este incrementa (de 1) a janela, ficando w=3 segmentos; pelo que envia o 4º e 5º segmentos (Note-se: w=3 significa que podem ficar por confirmar um máximo de 3 segmentos; como está ainda por confirmar o 3º segmento, podem ser enviados apenas mais dois segmentos, concretamente o 4º e o 5º). Quando o 3º segmento chegar ao Cliente, é devolvido ACK. Quando este chegar ao Servidor, este incrementa (de 1) a janela, ficando w=4 segmentos; pelo que envia o 6º e 7º segmentos. Quando o 4º segmento chegar ao Cliente, é devolvido ACK. Quando este chegar ao Servidor, este incrementa (de 1) a janela, ficando w=5 segmentos; pelo que envia o 8º e 9º segmentos. Quando o 5º segmento chegar ao Cliente, é devolvido ACK. Quando este chegar ao Servidor, este incrementa (de 1) a janela, ficando w=6 segmentos; pelo que envia o 10º segmento.

A evolução da janela de transmissão do Servidor é, pois, a seguinte: [1] → [2 3] → [3 4 5] → [4 5 6 7] → [5 6 7 8 9] → [6 7 8 9 10] Na prática, o Servidor despacha uma janela com 1 segmento, {1}; depois, despacha uma janela com 2 segmentos {2-

3}; depois, uma janela de 4 segmentos {4-7}; e, no fim, os 3 segmentos {8-10} que restam para perfazer os 10 segmentos em que se volve o primeiro Objecto. Entre duas janelas consecutivas, o Servidor ficou bloqueado algum tempo: depois de enviar o último bit de {1}, ficou bloqueado RTT=9; após enviar o último bit de {2-3}, ficou bloqueado RTT- T100Bytes=8; após enviar o último bit de {4-7}, ficou bloqueado RTT- 3*T100Bytes=6…

O tempo de latência para o primeiro Objecto vem então a ser: ∆T = 2 RTT + (RTT + T100Bytes)*3+ T300Bytes, em que RTT = 9, T100Bytes = 100/100 =1, T300Bytes = 300/100 =3, e por conseguinte ∆T = 5 * 9 + (1*3 + 3) = 51 mseg. O tempo de latência para o segundo Objecto calcula-se de uma forma análoga: Agora, o Servidor despacha uma janela

com 1 segmento, {1}; depois, despacha uma janela com 2 segmentos {2-3}; depois, uma janela de 4 segmentos {4-7}; depois, uma janela de 8 segmentos {8-15}; e, no fim, os dez segmentos {16-25} que restam para perfazer os 25 segmentos em que se volve o segundo Objecto.

O tempo de latência para o segundo Objecto vem então a ser: ∆T = 2 RTT + (RTT + T100Bytes)*4+ T1000Bytes = 68 mseg O tempo de latência para os dois Objectos vem então a ser: 51+68=119 mseg.


Resolução (3): O diagrama temporal para a obtenção do primeiro Objecto não se altera. Já para o segundo Objecto, o

diagrama temporal apropriado é aquele que se apresenta na fig TCP01.c. Concretamente: não é necessário estabelecer uma segunda conexão-TCP (pois se utiliza a versão 1.1 de HTTP); e, quando o Servidor começa a transmitir o segundo Objecto, a janela de transmissão do Servidor está a w=11 (Note-se que, na fase slow-start, a Janela de transmissão é sempre igual a 1 mais o número de segmentos confirmados - e, nesse momento, já foram recebidos 10 Acks).

Este tamanho de janela, w=11, tem uma consequência importante: reparou-se já que, entre duas janelas consecutivas, o Servidor fica bloqueado um tempo sucessivamente menor, de 9, 8, 6 mseg… Mais genericamente, fica bloqueado RTT-(w-1)*T1000Bytes. Existe um valor w que torna nulo esta expressão: a partir desse valor, o Servidor deixa de ficar bloqueado! Esse valor é w=RTT/T1000Bytes+1=10. Ora, w=11 é superior a 10; por conseguinte, aquando da transmissão do segundo Objecto, o Servidor não chega a ficar bloqueado: transmite os correspondentes segmentos sem qualquer paragem!

Resumindo: agora, o Servidor despacha uma janela com 11 segmentos, {11-21}; e, logo após, sem qualquer interrupção, os 14 segmentos {22-35} que restam para perfazer os 25 segmentos em que se volve o segundo Objecto.

O tempo de latência para o segundo Objecto vem então a ser: ∆T = RTT + T2500Bytes = 9+25 mseg O tempo de latência para os dois Objectos vem então a ser: 51+34=85

mseg.

18. Suponha que uma aplicação no computador A estabelece uma ligação TCP com uma aplicação no computador

B para receber o conteúdo de um ficheiro. O ficheiro tem 8000 bytes, tendo os segmentos TCP uma dimensão

máxima de S = 500 bytes. Os computadores estão ligados por uma linha com débito R = 4 Mbps, com um atraso

de ida e volta de RTT = 4 ms. Admita que o TCP utilizado é uma versão experimental, em que apenas existe

uma fase de arranque lento ("slow-start") que se inicia com uma janela de 1 segmento, mas que foi modificada

por forma a que o factor de crescimento da janela de congestionamento por cada janela bem recebida seja 3 (e

não 2 como nas versões habituais).

18.1. Qual a dimensão mínima da janela do emissor, em número de segmentos, para que a transmissão seja

contínua?

18.2. Ilustrando a comunicação entre o computador A e o computador B com um diagrama temporal,

determine o tempo necessário para o computador A receber o ficheiro (intervalo de tempo desde que a

ligação é estabelecida até que recebe completamente todos os bytes do ficheiro).

R: W ≥ 1 + RTT / Txmt, com Txmt= 500 * 8 / (4 * 106)⇒ Txmt = 1mseg, Wmin=5 T= [2 * RTT] + 2*[ Txmt + RTT] + 12 * Txmt = 30 mseg

19. [05E2] Um cliente HTTP pretende fazer o download de 1 página constituída por 5 objectos: o objecto base

com 4500 bytes e quatro outros referenciados no objecto base com 3000 bytes cada um. Suponha em todos os

casos que o cliente gasta 3 ms no processamento do objecto base (contados a partir da recepção completa deste

objecto), só então ficando apto a pedir objectos aí referenciados. Pretende-se estimar a latência na recepção da

página. Para isso, há que estabelecer uma ou mais ligações TCP entre cliente e servidor. Considere que: (i) os

segmentos TCP com dados são de dimensão S= 500 bytes; (ii) existe apenas uma ligação “full-duplex” entre

emissor e receptor com débito R= 2x106 bps e que introduz um atraso de ida e volta RTT=18 ms.

19.1. Admita que usa a versão 1.0 do protocolo HTTP sem utilização de ligações em paralelo. Qual é a

latência na recepção da página obtida para o caso em que, ao nível TCP, não existe mecanismo de controlo

de congestionamento (nem fase de “slow-start” nem fase de “congestion avoidance”) e se usa uma janela

fixa de 15 segmentos?

19.2. Continue a supor que usa HTTP 1.0 sem utilização de ligações em paralelo. Suponha que utiliza uma

versão experimental do protocolo TCP em que a fase de arranque lento (“slow-start”) foi modificada por

forma a que a janela de transmissão cresce 2 segmentos por cada ACK recebido. Admita ainda que nesta

versão não existe fase de “congestion avoidance”. Apresente um diagrama temporal, aproximadamente à

escala, que ilustre a sequência de segmentos trocados até que o objecto base seja recebido pelo cliente. Qual

a latência na recepção da página (conjunto de 5 objectos) ?



(“pipelining”). Suponha que a janela de transmissão cresce como descrito na alínea anterior. Calcule a

latência na recepção da página (conjunto de 5 objectos)

R: T1=2 RTT + NObjTxmt + 3 + 4 * (2 RTT + NImgTxmt) = 10 RTT + (NObj+4 NImg) Txmt com NObj=4500/500 e NImg=3000/500 e Txmt=500*8/(2 * 106) ⇒ T1==249 mseg T2= 2RTT+2(Txmt+RTT)+5Txmt+3+4[2RTT+2(Txmt+RTT)+2Txmt]=20RTT+23Txmt+3=409 mseg T3=2RTT+2(Txmt+RTT)+5Txmt+3+RTT++24Txmt=5 RTT+31Txmt+3=155 mseg.

20. Um cliente HTTP pretende fazer o download de 1 página constituída por 11 objectos: o objecto base com 6000

bytes e dez outros referenciados no objecto base com 5000 bytes cada um. Suponha em todos os casos que o

cliente gasta 5ms no processamento do objecto base (contados a partir da recepção completa deste objecto), só

então ficando apto a pedir os objectos aí referenciados. Pretende-se estimar a latência na recepção da página.

Para isso há que estabelecer uma ligação TCP entre cliente e servidor. Considere que: (i) os segmentos TCP

com dados são de dimensão S= 500; (ii) existe apenas uma ligação “full-duplex” entre emissor e receptor com

débito R= 1x106 bps e que introduz um atraso de ida e volta RTT= 16ms.

20.1. Admita que usa a versão 1.0 do protocolo HTTP com um máximo de 5 ligações em paralelo. Qual é a

latência na recepção da página obtida para o caso em que, ao nível TCP, não existe mecanismo de controlo

de congestionamento (nem fase de “slow-start” nem fase de “congestion avoidance”)?

20.2. Continue a supor que usa HTTP 1.0 com um máximo de 5 ligações em paralelo. Suponha que utiliza

uma versão experimental do protocolo TCP em que existe apenas uma fase do tipo “congestion avoidance”

em que a janela cresce linearmente 2 segmentos por cada janela bem recebida. Apresente um diagrama

temporal, aproximadamente à escala, que ilustre a sequência de segmentos trocados até que o objecto base

seja recebido pelo cliente. Qual a latência na recepção da página (conjunto de 11 objectos)?


(“pipelining”) e sem ligações paralelas. Suponha que usa a versão experimental do TCP descrito na alínea

anterior. Calcule a latência no download da página (conjunto de 11 componentes)

21. [06T1.2] Um cliente HTTP pretende fazer o download de 1 página constituída por 3 objectos: o objecto base

com 12000 bytes e dois outros referenciados no objecto base com 6000 bytes cada um. Suponha em todos os



página. Para isso há que estabelecer uma ligação TCP entre cliente e servidor. Considere que: (i) os segmentos

TCP com dados são de dimensão S= 500 bytes; (ii) existe apenas uma ligação “full-duplex” entre emissor e

receptor com débito R= 4x106 bps e que introduz um atraso de ida e volta RTT= 10 ms.

21.1. Admita que usa a versão 1.0 do protocolo HTTP sem ligações em paralelo. Qual é a latência na recepção

da página obtida (conjunto dos 3 objectos) para o caso em que, ao nível de transporte se usa uma versão do

TCP com janela fixa de 6 segmentos. Apresente um diagrama temporal do envio do objecto base indicando

os instantes de tempo relevantes.

21.2. Continue a supor que usa HTTP 1.0 sem ligações em paralelo. Suponha que utiliza uma versão

experimental do protocolo TCP em que a fase de arranque lento (“slow-start”) se inicia com uma janela de 1

segmento e foi modificada por forma a que o factor de crescimento da janela de congestionamento por RTT

é 5 (e não 2 como nas versões habituais). Admita ainda que nesta versão não existe fase de “congestion

avoidance”. Qual a latência na recepção da página (conjunto dos 3 objectos) ?


(“pipelining”). Suponha que usa a versão do TCP Tahoe: na fase de “slow-start” a janela inicial tem

dimensão 1 e duplica por cada janela bem recebida; na fase de “congestion-avoidance” a janela aumenta de

1 segmento por janela bem recebida. A transição entre as duas fases ocorre quando a janela atinje os 8

segmentos. Calcule a latência no download da página (conjunto dos 3 objectos)

22. [06T1.2] Um cliente HTTP pretende fazer o download de 1 página constituída por 3 objectos: o objecto base




página. Para isso, há que estabelecer uma ligação TCP entre cliente e servidor. Considere que: (i) os segmentos



receptor com débito R= 4x106 bps e que introduz um atraso de ida e volta RTT= 10 ms.

22.1. Admita que usa a versão 1.0 do protocolo HTTP sem ligações em paralelo. Suponha que utiliza uma

versão experimental do protocolo TCP em que a fase de arranque lento (“slow-start”) se inicia com uma

janela de 1 segmento e foi modificada por forma a que o factor de crescimento da janela de

congestionamento por cada janela bem recebida é 4 (e não 2 como nas versões habituais). Admita ainda que

nesta versão não existe fase de “congestion avoidance”. Apresente um diagrama temporal, aproximadamente

à escala, que ilustre a sequência de segmentos trocados até que o objecto base seja recebido pelo cliente.

Qual a latência na recepção da página (conjunto dos 3 objectos)?


(“pipelining”). Suponha que usa a versão do TCP Tahoe: na fase de “slow-start” a janela inicial tem

dimensão 1 e duplica por cada janela

bem recebida; na fase de “congestion-

avoidance” a janela aumenta de 1

segmento por janela bem recebida. A

transição entre as duas fases ocorre

quando a janela atinge os 8 segmentos.

Calcule a latência na recepção da página

(conjunto dos 3 objectos).

R1: TCP26.a ilustra a situação. O Tempo de Transmissão de cada Segmento é TXmt=500*8/(4*106)= 1 mseg. O factor de crescimento (4) apontaria a que a dimensão máxima das sucessivas janelas fosse {1, 4, 16, 64…}; porém, a partir da janela W=1+RTT/TXmt=11, a transmissão dos Segmentos é contínua (sem tempos de espera entre eles). O Objecto Base ocupa 12000/500=24 Segmentos, distribuídos pelas janelas: 1+4+19; cada Objecto Referenciado ocupa 6000/500=12 Segmentos, distribuídos pelas janelas: 1+4+7.

Vem TObjB = 2 RTT+(TXmt + RTT)*2+(19)TXmt= 61 e TObjR = 2 RTT+(RTT+TXmt)*2+7* TXmt= 49. pelo que o tempo de latência é TObjB + 3 + 2 * TObjR=162 mseg.

R2: TCP26.b ilustra a situação. A dimensão máxima das sucessivas janelas seria {1, 2, 4, 8, 9, 10, 11, 12,…}; porém, a partir da janela W=1+RTT/TXmt=11, a transmissão dos Segmentos é contínua. O Objecto Base distribui-se pelas janelas: 1+2+4+8+9; os Objectos Referenciados distribuem-se pelas janelas: 10+14.

Vem TObjB = 2 RTT+(TXmt +RTT)*4+9 * TXmt= 73 e TObjR = RTT + (TXmt +RTT)+14* TXmt= 35, pelo que o tempo de latência é TObjB + 3 + TObjR=111 mseg.

23. [06E2.1] Um cliente HTTP pretende fazer o download de 1 página constituída por 3 objectos: o objecto base




página. Para isso há que estabelecer uma ligação TCP entre cliente e servidor. Considere que: (i) os segmentos


receptor com débito R= 0,8x106 bps e que introduz um atraso de ida e volta RTT= 90 ms.



versão simplificada do protocolo TCP em que a janela de emissão tem um tamanho fixo de 6 segmentos.

Apresente um diagrama temporal, aproximadamente à escala, que ilustre a sequência de segmentos trocados

até que o objecto base seja recebido pelo cliente. Qual a latência na recepção da página (conjunto dos 3

objectos) ?


(“pipelining”). Suponha que usa uma versão modificada do TCP: na fase de “slow-start” a janela inicial tem

dimensão 2 e duplica (como nas versões tradicionais) por cada janela bem recebida; na fase de “congestion-

avoidance” a janela aumenta de 1 segmento por janela bem recebida. A transição entre as duas fases ocorre

quando a janela atinge os 8 segmentos. Apresente um diagrama temporal, aproximadamente à escala, que

ilustre a sequência de segmentos trocados até que o objecto base seja recebido pelo cliente. Calcule a

latência na recepção da página (conjunto dos 3 objectos).

R1: TCP13.a ilustra a situação. O Tempo de Transmissão de cada Segmento é TXmt=1000*8/(0,8*106)= 10 mseg. O Objecto Base ocupa 15000/1000=15 Segmentos, distribuídos pelas janelas: 6+6+3; cada Objecto Referenciado ocupa 11000/1000=11 Segmentos, distribuídos pelas janelas: 6+5.

Vem TObjB = 2 RTT+(RTT+TXmt)*2+3* TXmt= 410 e TObjR = 2RTT+(RTT+TXmt)+5-* TXmt= 330. pelo que o tempo de latência é TObjB + 8 + 2* TObjR=1078 mseg.

R2: TCP13.b ilustra a situação. A dimensão máxima das sucessivas janelas seria {2, 4, 8, 9, 10, 11, 12,…}; porém, a partir da janela w=1+RTT/TXmt=10, a transmissão dos Segmentos é contínua. O Objecto Base distribui-se pelas janelas: 2+4+8+1; os Objectos Referenciados distribuem-se pelas janelas: 9+13.

Vem TObjB = 2 RTT+(RTT+TXmt)*3+TXmt= 490 e TObjR = RTT+(RTT+TXmt)+13* TXmt= 320, pelo que o tempo de latência é TObjB + 8 + TObjR=818 mseg.

24. [06T1,06E1.1] Um cliente HTTP pretende fazer o download de 1 página constituída por 4 objectos: o objecto

base com 4000 bytes e três outros referenciados no objecto base com 2000 bytes cada um. Pretende-se estimar a

latência na recepção da página. Para isso há que estabelecer uma ligação TCP entre cliente e servidor.

Considere que: (i) os segmentos TCP com dados são de dimensão S= 200 bytes; (ii) existe apenas uma ligação

“full-duplex” entre emissor e receptor com débito R= 1,6x106 bps e que introduz um atraso de ida e volta RTT=

10 ms.



versão experimental do protocolo TCP em que a fase de arranque lento (“slow-start”) se inicia com uma

janela de 1 segmento e foi modificada por forma a que o factor de crescimento da janela de

congestionamento por cada janela bem recebida é 3 (e não 2 como nas versões habituais). Admita ainda que

nesta versão não existe fase de “congestion avoidance”. Apresente um diagrama temporal, aproximadamente

à escala, que ilustre a sequência de segmentos trocados até que o objecto base seja recebido pelo cliente.

Qual a latência na recepção da página (conjunto dos 4 objectos) ?


(“pipelining”). Suponha que usa uma versão do TCP tal que a fase de “slow-start” é a descrita na alínea

anterior; na fase de “congestion-avoidance” a janela aumenta de 1 segmento por janela bem recebida. A

transição entre as duas fases ocorre quando a janela atinge os 9 segmentos. Calcule a latência na recepção da

página (conjunto dos 4 objectos)

R1: A fig TCP25.a esquematiza a situação descrita em (1). A latência será: - para o Objecto Base, 2 RTT + ( TXmt + RTT ) * 3 + 7 TXmt, em que TXmt = 200*8/(1,6*106) seg = 1 mseg - para cada Objecto referenciado, 2 RTT + (TXmt + RTT ) * 2 + 6 TXmt;

A latência da página será então de (2 + 3 * 2 ) RTT + ( RTT + TXmt ) * (3 + 3 * 2 ) + (7 + 3 * 6 ) TXmt = 204 mseg R1: A fig TCP25.b esquematiza a situação descrita em (2). A latência será:

- para o Objecto Base, 2 RTT + ( TXmt + RTT ) * 3 + 7 TXmt, em que TXmt = 200*8/(1,6*106) seg = 1 mseg - para o conjunto dosObjectos referenciados, RTT + (TXmt + RTT ) + 20 TXmt;

A latência da página será então de (2 + 1 ) RTT + ( RTT + TXmt ) * (3 + 1 ) + (7 + 20 ) TXmt = 101 mseg

25. [06E3] Considere uma sessão TCP (Reno), única na rede, com valor de Round-Trip Time de 1 ms (constante),

que inicia a transmissão de segmentos em t=0. Assuma que o limiar entre a fase slow-start e a fase congestion

avoidance é 16 segmentos. Suponha que o segmento 66 se perde e que a perda é detectada através da recepção

de Acks duplicados. Represente (com clareza) um gráfico que ilustre a evolução da janela do emissor até 5 ms

após a detecção da perda pela fonte. Em particular, indique claramente no gráfico em que intervalo de tempo é

detectada a perda. [Assuma que a fonte tem uma quantidade infinita de segmentos para enviar]

R: Em t=0, CWnd=1, envia-se S1. Em t=1, recebe-se Ack2, CWnd duplica (passa a ser 2), e envia-se S2 e S3. Em t=2, recebe-se Ack3 e Ack4, CWnd duplica (passa a ser 4), e envia-se S4 até S7. E assim sucessivamente: a figura TCP14.a enumera os Segmentos que são enviados nos instantes t=3, t=4, etc..Em t=5, entra-se na fase congestion avoidance: o crescimento de CWnd passa a ser linear: 17, 18.. Em t=6, envia-se S49 até S66. À medida que vão chegando os Acks (concretamente, Ack50, Ack51, etc.), envia-se S67, S68, S69… Todavia, o S66 perde-se - pelo que o último a ser recebido é Ack66, e por conseguinte o último a ser enviado é S83. À medida que S67, S68, S69, chegam ao destino, são repetidamente devolvidos Ack66, Ack66,… Quando fôr recebido o terceiro, o S66 é re-enviado (Fast-retransmit); após o que CWnd é fixado em 18/2=9, e incrementado de 3, isto é, passa a ser 12. E voltará a incrementar por cada Ack recebido a seguir (mecanismo inflating); como foram enviados 17 Segmentos, irão ser recebidos mais 14 Acks duplicados: no final, será CWnd =25. Repare-se que, no momento, estão por confirmar 18 segmentos (S66 até S83); quando CWnd chegar a 19, envia-se S84; e, à medida que forem chegando mais Acks duplicados, serão sucessivamente enviados S85 até S90 (Fast Recovery). Quando chegar o primeiro Ack fresco, no caso Ack84, CWnd é fixada em 9 (mecanismo deflating), e a partir daí recomeçará


a crescer linearmente… Como no momento estão por confirmar 7 segmentos (S84 até S90), pode enviar-se 2 segmentos (S91 até S92).

Nota: é aceitável uma resposta que adopte a simplificação: ignorar FastRecovery e transmitir os Segmentos S84 até S90 após ter sido recebido Ack84.

26. [07T1] Um cliente pretende fazer o

download de um ficheiro de tamanho

50.000 bytes, usando o protocolo TCP-

Reno através de uma única ligação.

Considere que: (i) os segmentos TCP com

dados são de dimensão L=1000 bytes; (ii)

a ligação tem um débito R=8 Mbit/s e o

atraso de ida e volta é RTT = 10 ms.

26.1. Considere que o limiar (threshold)

entre a fase “slow-start” e a fase

“congestion avoidance” da sessão TCP

é 16. Suponha que durante a

transmissão não há perdas nem erros nos segmentos TCP. Apresente um diagrama temporal que ilustre a

sequência de segmentos trocados até que o ficheiro seja totalmente recebido pelo cliente. Calcule o tempo

necessário até à completa recepção do ficheiro pelo cliente (medido desde o instante em que o cliente inicia

o estabelecimento da ligação). Indique claramente a evolução dos valores para a janela de congestionamento

do servidor e, em particular, o seu valor final

26.2. Admita agora que o ficheiro requerido pelo cliente é mais pequeno - ocupando 20.000 bytes - e que,

durante a transmissão, o

segmento 8 se perde. Assuma

que essa perda é detectada por

ACKs duplicados. Assuma

também que, nesta realização do

receptor TCP, todos os

segmentos que forem recebidos

fora de ordem são aceites pelo

receptor. Não se verificam mais

perdas até ao final da

transmissão e o limiar

(threshold) entre a fase “slow-

start” e fase “congestion

avoidance” é agora 8. Com o

auxílio de um diagrama temporal

que ilustre a sequência de

segmentos trocados até que o

ficheiro seja totalmente recebido

pelo cliente, calcule o tempo

necessário até à completa

recepção do ficheiro pelo cliente. Indique no diagrama a evolução dos valores para a janela de

congestionamento e também do parâmetro threshold do servidor.

R1: O diagrama temporal [TCP16.a] esquematiza a situação. T=RTT+5*(RTT+TXmt)+34*TXmt=6*RTT+39TXmt=99 mseg, Wfinal≈18, TXmt=1000*8/(8*106)=1 mseg

R2: O diagrama temporal [TCP16.b] esquematiza a situação.. T=RTT+4*(RTT+TXmt)+3*TXmt+2*(RTT+TXmt)+2*TXmt=7*RTT+11TXmt=81mseg


27. [07E1] Um cliente pretende fazer

o download de um ficheiro de

tamanho 60.000 bytes, usando o

protocolo TCP-Reno através de

uma única ligação. Suponha que:

(i) os segmentos TCP com

dados são de dimensão L=1000

bytes;

(ii) a ligação tem um débito

R=8 Mbit/s e o atraso de ida e

volta é RTT = 15 ms;

(iii) o limiar (threshold) entre

a fase slow-start e a fase

congestion avoidance da sessão

TCP é 16.

(iv) o intervalo do

temporizador (para o evento de

timeout) é de 20 ms.

Durante a transmissão ocorrem

as perdas dos segmentos 16 e 45.

A primeira perda é detectada por

timeout e a segunda é detectada por

ACKs duplicados. Apresente um

diagrama temporal que ilustre a

sequência de segmentos trocados até

que o ficheiro seja totalmente

recebido pelo cliente e até que todos

os Acks respectivos cheguem ao

emissor. Com base nesse diagrama,

determine o tempo necessário até à

completa recepção do ficheiro pelo

cliente (medido desde o instante em

que o cliente inicia o

estabelecimento da ligação). No

diagrama, indique claramente a

evolução dos valores para a janela

de congestionamento do servidor

(incluindo o seu valor final).

R: TXmt=1000*8/(8*106)=10-3 seg = 1 mseg; Nsegmentos=60 000/1000=60. Cfr fig TCP18.a

T=2*RTT+4(TXmt+RTT)+(TXmt+Timeout)+5(TXmt+RTT)+2 TXmt+2 (TXmt+RTT)+ TXmt=13 RTT+15 TXmt + Timeout = 230 mseg.

[10E1.5] Enunciado semelhante a [07E1], mas: 1) o atraso de ida e volta é RTT = 10 ms; 2) o intervalo do

temporizador (timeout) é de 15 ms.

R: TXmt=1000*8/(8*106)=10-3 s = 1 ms; Nsegmentos=60 000/1000=60. Cfr fig TCP18.b T=2*RTT+4 (TXmt+RTT)+(TXmt+Timeout)+5(TXmt+RTT)+ 2 TXmt+2 (TXmt+RTT)+ TXmt= 13 RTT+15 TXmt + Timeout = 160 ms


28. [07E2.12] Um cliente pretende fazer o download de um ficheiro com 40.000 bytes, usando o protocolo TCP-

Reno através de uma única ligação. Suponha que:

28.1. (i) os segmentos TCP com dados são de dimensão L=1000 bytes;

28.2. (ii) o atraso de ida e volta é RTT = 15 ms;

28.3. (iii) o limiar (threshold) entre a fase slow-start e a fase congestion avoidance da sessão TCP é 8.

28.4. (iv) o intervalo de temporização para eventuais ocorrências de timeout é de 20 ms.

28.5. (v) o receptor não descarta segmentos fora de ordem (i.e. segmentos recebidos com números de

sequência superiores ao esperado).

Suponha também que a capacidade da ligação (i.e. o débito) entre o cliente e o servidor é de R=8 Mbit/s até

ao envio do segmento 30 (inclusivé) e depois disso, devido a alterações na rede, é de R=4 Mbit/s.

Durante a transmissão ocorre a perda dos segmentos 16 e 17. Além disso, devido a circunstâncias

excepcionais, todos os ACKs dos segmentos 18 a 24 (portanto um total de 7 ACKs) são perdidos.

Depois disso, nenhum outro

segmento se perde ou se atrasa

mais do que o previsto pelo atraso

de propagação, assim como

nenhum outro ACK se perde ou

atrasa mais do que previsto.

Apresente um diagrama

temporal que ilustre a sequência

de segmentos trocados até que o

ficheiro seja totalmente recebido

pelo cliente. Em particular, o

diagrama deve indicar claramente

como é recuperada a perda dos

dois segmentos referidos acima.

Calcule o tempo necessário até à

completa recepção do ficheiro

pelo cliente (medido desde o

instante em que o cliente inicia o

estabelecimento da ligação).

Apresente também um

pequeno gráfico que indique a

evolução dos valores para a janela

de congestionamento do servidor

(i.e. um gráfico CongWin vs. Tempo).

R: TXmt=1000*8/(8*106)=1 ms, T'Xmt=1000*8/4*10

6=2ms. Cfr TCP19.a

Ttot=2RTT+4(TXmt+RTT)+ (TXmt+TOut)+ (TXmt+RTT+TOut)+4(TXmt+RTT)+ (T'Xm+RTT)+2T'Xm=236 ms

29. [08E1.12] Um cliente pretende fazer o download de um ficheiro de tamanho 25.000 bytes, usando o protocolo






(ii) a ligação tem um débito R=8 Mbit/s e o atraso de ida-e-volta é RTT = 20 ms;


(iv) é enviado um segmento de confirmação (ACK) por cada segmento bem recebido;



(vi) nesta implementação, os segmentos que forem recebidos fora de ordem são aceites pelo receptor;

(vii) o limiar (threshold) entre a fase slow-start e a fase congestion avoidance é 8;


Suponha que durante a transmissão ocorre a perda do segmento 16.


Apresente um diagrama temporal que

ilustre a sequência de segmentos

trocados (e respectivos ACKs) até que

o ficheiro seja totalmente recebido

pelo cliente. Calcule o tempo

necessário até à completa recepção do

ficheiro pelo cliente, medido desde o

instante em que o cliente inicia o

estabelecimento da ligação. No

diagrama, indique os valores para a

janela de congestionamento do

servidor.

R: O Tempo de transmissão de cada segmento é: TXmt=1000*8/(8*106) seg= 1 ms.

Há que transmitir 25000/1000=25 segmentos. Em TCP28.a, esquematiza-se a evolução da transferência. Pelo que o tempo necessário é: T=7*RTT+12*TXmt=7*20+12*1=152 mseg.





(i) os segmentos TCP com dados são de dimensão L=1000 bytes e o

comprimento dos cabeçalhos (de todos os protocolos da pilha) é

desprezável;

(ii) a ligação tem um débito R=8 Mbit/s e o atraso de ida-e-volta é

RTT = 20 ms;

(iii) sómente os pacotes com dados não têm tempos de transmissão

desprezáveis;

(iv) a janela TCP de emissão no servidor é apenas limitada pelos

mecanismos de controlo de congestionamento;

(v) o receptor, relativamente a segmentos recebidos fora de ordem,

aceita-os até um limite de N (mais precisamente, a memória

disponível tem espaço só para o segmento mais antigo em falta e

para os N-1 seguintes);

(vi) o receptor, relativamente à confirmação (Acknowledgemt) de

segmentos, segue a seguinte filosofia:

- se o segmento vier fora de ordem (isto é, o seu numero de

sequência não coincide com o valor da aresta inferior da janela de

recepção), devolve de imediato o pertinente Ack;

- segmentos que cheguem na ordem são de imediato entregues à

Aplicação. Além disso:

- se já recebeu algum outro segmento que esteja ainda por

confirmar, devolve o pertinente Ack;

- caso contrário, arma um relógio, por um período T=2 ms; se o relógio vier a expirar antes de receber

outro segmento, devolve o Ack.

(vii) o transmissor, na fase SlowStart, quando recebe um Ack, incrementa a sua Janela de 2 por cada

segmento que ele confirme e que estava por confirmar.

Suponha ainda que, na transmissão, o terceiro segmento sofre um atraso adicional de 25 ms e que a sua

recuperação se faz por FastRetransmission. Admita que N (o limite referido no ponto (v) acima) é tal que

nunca é preciso retransmitir segmentos bem recebidos fora de ordem.


30.1. Apresente um diagrama temporal que ilustre a sequência de segmentos trocados (e respectivos Acks) até

que o ficheiro seja totalmente recebido pelo cliente.

30.2. Calcule o tempo necessário até à completa recepção do ficheiro pelo cliente, medido desde o instante em

que o cliente inicia o estabelecimento da ligação. No diagrama, indique os valores para a janela de

congestionamento do servidor.

30.3. Qual o valor do Timeout de retransmissão mínimo para que a recuperação do segmento atrasado se faça

por FastRetransmission?

30.4. Qual deve ser o tamanho mínimo de N, para que não tenham de ser transmitidos segmentos bem

recebidos?

R1: Cfr fig TCP28.b R2: 6*RTT+TOut+11TXmt=120+2+11=133 ms, pois TXmt=1000*8/8*106=1 ms R3: TimeOutMin>TXmt+RTT+ TXmt+RTT+2 TXmt=4+2*20=44 ms R4: NMin=5 (para comportar os pacotes {3,4,5,6,7})


TCP através de uma única ligação. Assuma que o pedido de transferência feito pelo cliente segue juntamente

com o terceiro segmento da fase de estabelecimento da sessão TCP. Desprezam-se quaisquer tempos de

processamento no cliente e no servidor. Considere que:




(iii) somente os segmentos com dados não têm tempos de transmissão desprezáveis;

(iv) é enviado um segmento de confirmação (Ack) por cada segmento bem recebido;



(vii) o limiar (threshold) entre a fase slow-start e a fase congestion

avoidance é 16;


Suponha que, durante a transmissão, ocorre um atraso adicional de 4 ms

no Ack do 3º segmento (i.e., decorre um tempo total de 1+4=5 ms, desde que

termina o envio desse Ack até ele ser totalmente recebido).

31.1. Apresente um diagrama temporal que ilustre a sequência de

segmentos trocados (e respectivos Acks) até que o ficheiro seja totalmente

recebido pelo cliente.

31.2. Calcule o tempo necessário até à completa recepção do ficheiro pelo

cliente, medido desde o instante em que o cliente inicia o estabelecimento da

ligação.

31.3. Qual o tamanho da janela de congestionamento, logo após se receber

o Ack do 3º segmento?

31.4. Qual o maior valor que o timeout poderia ter – que levasse à

retransmissão do 3º segmento?

R: 1) cfr TCP21.d. 2) 2 RTT + 3 * (TXmt+RTT) + 3 TXmt = 16 ms. 3) WCong= 6. 4) 4 ms (na filosofia “1 relógio dedicado por segmento’) ou 3 ms (na filosofia ‘1 relógio único partilhado, rearmá-lo após receber Ack3’)

32. [06E3] Suponha que se pretende utilizar o protocolo TCP sobre ligações

com elevada capacidade (da ordem das dezenas de Gbit/s) e atrasos significativos (entre 200 e 300 ms). Que

problemas antevê na utilização do TCP sobre este tipo de ligações ? Dê um ou mais exemplos que ilustrem

esses problemas.

R: cfr resolução de [08E3.1]

33. [08E3.1] Suponha que duas empresas decidiram interligar-se através de um link alugado (e dedicado) de 10

Gbps. Suponha também que essas empresas pretendem utilizar o TCP (Reno ou NewReno) para transferência de

grandes quantidades de informação. Sabe-se que o RTT dessa ligação é de cerca de 300 ms. Do seu ponto de


vista, que problemas poderão surgir com este cenário de utilização do TCP, em particular no que se refere à

eficiência de utilização do link? Suporte a sua resposta com um exemplo ilustrativo.

R: Existem pelo menos dois problemas: - Para se lograr uma eficiência de 100%, deve fixar-se Window= (TXmt+RTT)/ TXmt= 1+RTT*C/pcktSize. Nas condições

referidas (ligações de elevada capacidade C e atraso RTT significativo), Window volve-se num valor muito elevado: para RTT=300 mseg e C=10 Gbps, Window excederá 375 Mbyte; ora acontece que nos segmentos-TCP o campo Crédito está limitado a 2 octetos, o que significa que não poderá exceder 65.535 bytes!

Pelo que a eficiência irá ficar muito aquém dos 100%: após enviar uma janela de 65.535 bytes, o transmissor necessita ficar muito tempo aguardando que possa enviar mais outra janela, cfr fig TCP07.d: demora-se um tempão a enviar toda a informação… (Para obviar a este problema, a RFC-1323 introduziu a Opção Window Scale: no estabelecimento da conexão, cada uma das Entidades comunica à outra um ShifCount (até 14), que permite aumentar a Janela até quase 1 Gbyte).

- Um outro problema é o facto de, aquando da perda de Acks, os algoritmos de controlo de congestão (Tahoe e Reno, por ex.) levam a que a Janela diminua para metade do seu valor antes da perda - e, depois, tendo ingressado na fase de Congestion Avoidance, a um crescimento linear: se a Window inicial fosse 375 Mbyte, ela iria decrescer para 187 Mbyte - e levaria um tempão até voltar a atingir 375 Mbyte...

34. [08E3.12] Um cliente pretende fazer o download de um ficheiro com 25.000 bytes, usando o protocolo TCP-

Reno através de uma única ligação. Assuma que o cliente e servidor estão ligados por um canal full-duplex e

que o pedido de transferência feito pelo cliente segue juntamente com o terceiro segmento da fase de

estabelecimento da sessão TCP. Desprezam-se quaisquer tempos de processamento no cliente e no servidor.

Suponha ainda que:

(i) os segmentos TCP com dados são de dimensão L=1000 bytes e o comprimento dos cabeçalhos (de todos

os protocolos da pilha) é desprezável;

(ii) o atraso de ida e volta é RTT = 10 ms;


(iv) é enviado um segmento de confirmação (ACK) por cada segmento bem recebido, logo após a

recepção de um segmento;

(v) a janela TCP de emissão

no servidor é apenas limitada

pelos mecanismos de controlo de

congestionamento (isto é, os

buffers na recepção do cliente são

ilimitados).

(vi) o limiar (threshold) entre a

fase slow-start e a fase congestion

avoidance da sessão TCP é 16.

(vii) o intervalo de temporização

para eventuais ocorrências de timeout

é de 15 ms.

(viii) o receptor não descarta

segmentos fora de ordem (i.e.

segmentos recebidos com números de

sequência superiores ao esperado).

(ix) a capacidade da ligação

entre o cliente e o servidor é de R=8

Mbit/s.

Suponha que, durante a transmissão ocorre a perda do segmento 4 e também dos ACKs dos segmentos 5 a 7.

De seguida, devido a circunstâncias invulgares, quando o segmento 4 é retransmitido, este volta a perder-se.

Não existem mais perdas até ao final da transmissão.


Apresente um diagrama temporal que ilustre a sequência de segmentos trocados até que o ficheiro seja

totalmente recebido pelo cliente, assim como a evolução da janela de congestionamento do servidor. Calcule o

tempo necessário até à completa recepção do ficheiro pelo cliente (medido desde o instante em que o cliente

inicia o estabelecimento da ligação).

R: O Tempo de transmissão de cada segmento é: TXmt=1000*8/(8*106) seg= 1 ms. Há que transmitir 25000/1000=25 segmentos. Em TCP28.c, esquematiza-se a evolução da transferência. Pelo que o tempo necessário é:

T = 9 * RTT + 13 * TXmt + 2 TOut = 9 * 10 + 13 * 1 + 2 * 15 = 133 mseg.

35. [09E2.5] Um cliente pretende fazer o download de um ficheiro de tamanho

10.000 bytes, usando o protocolo TCP (Reno) através de uma única

ligação. Assuma que o pedido de transferência feito pelo cliente segue

juntamente com o terceiro segmento da fase de estabelecimento da sessão

TCP. Desprezam-se quaisquer tempos de processamento no cliente e no

servidor. Considere que:

(i) os segmentos TCP com dados são de dimensão L=1000 bytes e o

comprimento dos cabeçalhos (de todos os protocolos da pilha) é

desprezável;

(ii) a ligação tem um débito R=8 Mbit/s e o atraso de ida-e-volta é RTT = 4

ms;

(iii) somente os segmentos com dados não têm tempos de transmissão

desprezáveis;

(iv) é enviado um segmento de confirmação (Ack) por cada segmento bem

recebido;

(v) a janela TCP de emissão no servidor é apenas limitada pelos

mecanismos de controlo de congestionamento (isto é, os buffers na

recepção do cliente são ilimitados);

(vii) o limiar (threshold) entre a fase slow-start e a fase congestion

avoidance é 3;


Suponha que, durante a transmissão, ocorre um atraso adicional de 4,5 ms no Ack do 3º segmento (i.e.,

decorre um tempo total de 2+4,5=6,5 ms, desde que termina o envio desse Ack até ele ser totalmente recebido).

35.1. Apresente um diagrama temporal que ilustre a sequência de segmentos trocados (e respectivos Acks) até

que o ficheiro seja totalmente recebido.

35.2. Calcule o tempo necessário até à completa recepção do ficheiro, medido desde o instante em que o

cliente inicia o estabelecimento da ligação.

35.3. Qual o tamanho da janela de congestionamento que é calculado pelo servidor na sequência da recepção

do Ack do 3º segmento?

35.4. Desde que inicia a transmissão do 1º segmento, quanto tempo decorre até que a janela de

congestionamento seja 5?

R1) cfr fig TCP01.d; R2: 2 RTT + 4 * (TXmt+RTT) + TXmt = 29 ms [TXmt =1000*8/(8*106)=1ms]; R3: WCong=3+2/3; R4: 4(TXmt+RTT)+3TXmt=23 ms. CongWin=5 após E receber Ack10, a evolução é:

CongWin Inicial Após 1 Ack Após mais 1 Ack Após mais 3 Ack Após mais 4 Ack 1 2 3 ( l i m i a r ) 4 5





- (i) os segmentos TCP com dados são de dimensão L=1000 bytes e o comprimento dos cabeçalhos (de todos os


- (ii) a ligação tem um débito R=8 Mbit/s e o atraso de ida-e-volta é RTT = 8 ms;


- (iii) somente os segmentos com dados não têm tempos de transmissão desprezáveis;

- (iv) é enviado um segmento de confirmação (Ack) por cada segmento bem recebido;

- (v) a janela TCP de emissão no

servidor é apenas limitada pelos

mecanismos de controlo de

congestionamento (isto é, os buffers

na recepção do cliente são ilimitados);

- (vii) o limiar (threshold) entre a

fase slow-start e a fase congestion

avoidance é 8;

- (viii) o valor do timeout é de 25

ms.

Suponha que, durante a

transmissão, se perdem os segmentos

S8 e S9 (com numeração começando

em S1). Através de um diagrama

temporal que ilustre a sequência de segmentos trocados, determine o tempo necessário até à completa recepção

do ficheiro pelo cliente, medido desde o instante em que o cliente inicia o estabelecimento da ligação.

Represente no diagrama os valores da janela do emissor. [6.0]

R: TXmt=1000*8/(8*106)=1 ms, Nº de pacotes=20000/1000=20; cfr TCP19.b Ttot=2 RTT + 3 (TXmt+RTT) + 4TXmt + (TXmt+RTT) + (TXmt+RTT + 25) + 2(TXmt+RTT)+ TXmt= 109 ms

37. [08T1.3] A propósito do algoritmo de ajuste do tamanho de janela de congestionamento designado Additive

Increase, Multiplicative Decrease (AIMD), que é utilizado no TCP para controlo de congestionamento, foi

demonstrado (através de um modelo simples) que este algoritmo é justo no que diz respeito à alocação de

débitos médios e também é eficiente na alocação de recursos. Como sabe o algoritmo AIMD altera a janela para

W=W+α quando esta aumenta e altera-a para W=W*β quando esta diminui, com α>0 e 0<β<1. Usando o

mesmo tipo de argumentos, discuta (ou demonstre) se um algoritmo do tipo Additive Increase, Additive

Decrease (AIAD) também seria justo e eficiente na alocação de recursos. [Nota: um algoritmo do tipo AIAD

altera a janela para W=W+α quando esta aumenta e para W=W-β quando esta diminui, com α>0 e β>0].

R: Considere-se uma Rede com duas conexões, uma ancorada em W e a outra ancorada em E. As Janelas de congestão são, respectivamente, CongW=8 e CongE=4. Admita-se que a Rede não suporta mais que um total de '11'. O próximo Segmento enviado por W e E perde-se, pois 8+4=12; os timeouts de W e E expiram.

1. se se usar Additive Decrease, com α=1 e β=1, - as Janelas passam a ser CongW=8-1=7 e CongE=4-1=3;

- a evolução (Additive) será: CongW=8 e CongE=4; - o próximo Segmento enviado perde-se, pois 8+4=12; as Janelas passam a ser CongW=7, CongE=3

Repare-se na evolução das Janelas no momento da congestão: W mantém-se em 8; E mantém-se em 4.

Quer dizer: partindo de valores diferentes, continuam sendo diferentes: o sistema não é igualitário… 2. Repare-se: se se usar Multiplicative Decrease, e se α=1 e β=2, - as Janelas passam a ser CongW=8/2=4 e CongE=4/2=2;

- a evolução (Additive) será: CongW=5,CongE=3; CongW=6,CongE=4; CongW=7,CongE=5. - o próximo Segmento enviado perde-se, pois 7+5=12; as Janelas passam a CongW=3,5, CongE=2,5 - a evolução será: CongW=4,5,CongE=3,5; CongW=5,5,CongE=4,5; CongW=6,5,CongE=5,5.

Repare-se na evolução das Janelas no momento da congestão: W passou por 8 → 7 → 6,5; E passou por 4 → 5 → 5,5.

Quer dizer: partindo de valores diferentes, estão convergindo para o mesmo (6): o sistema é igualitário… Nota: em alternativa, pode argumentar-se como é feito no acetato "Justiça no protocolo TCP".


TCP através de uma única ligação. Assuma que o pedido de transferência feito pelo cliente segue juntamente com

o terceiro segmento da fase de estabelecimento da sessão TCP. Desprezam-se quaisquer tempos de processamento

no cliente e no servidor. Considere que:





(iii) somente os segmentos com dados não têm tempos de transmissão desprezáveis;

(iv) é enviado um segmento de confirmação (Ack) por cada segmento bem recebido;

(v) a janela TCP de emissão no servidor é apenas limitada pelos mecanismos

de controlo de congestionamento (isto é, os buffers na recepção do cliente são

ilimitados);

(vii) o limiar (threshold) entre a fase slow-start e a fase congestion avoidance

é 8;

(viii) o valor do timeout de retransmissão é de 4 ms.

Suponha que se perdem os Acks do 4º e 5º segmentos.

Admita a seguinte ordem de precedência: se, durante a transmissão dum

segmento, expirar o timeout (ou chegar um Ack), o servidor acaba essa

transmissão antes de o processar; após essa transmissão, ele processa o Ack (se

tiver chegado algum) e depois processa o timeout (se ele tiver expirado).

38.1. Apresente um diagrama temporal que ilustre a sequência de segmentos

trocados (e respectivos Acks) até que o ficheiro seja totalmente recebido pelo

cliente.

38.2. Calcule o tempo necessário até à completa recepção do ficheiro pelo

cliente, medido desde o instante em que o cliente inicia o estabelecimento da

ligação.

38.3. Qual a janela de congestionamento no Servidor, imediatamente depois

de receber o Ack do último segmento?

38.4. Qual o valor mínimo para o período de timeout para que, mesmo com as

perdas de Acks referidas, não houvesse retransmissão de segmentos?

R1: cfr fig. TCP29.c. R2: RTT+(RTT+TXmt)*2 +7* TXmt=33 ms (com TXmt=3000*8/(8*106) s=3 ms). R3: 3 R4: > 8 ms (Tempo entre o termo da transmissão de S4 e a chegada de Ack7).

39. [10E2.5] Considere o acesso de um browser a um servidor “Web” utilizando HTTP 1.1 sobre uma ligação TCP-

Reno. Quando o servidor finda a transmissão do último segmento do objecto-base de um dado documento, a

ligação encontra-se localmente na fase slow-start, com a janela de congestionamento valendo CongWin=5

(considere que o limiar entre a fase slow-start e a fase congestion avoidance é suficientemente elevado para que

a ligação nunca saia da fase slow-start, até que o emissor detecte a perda de um segmento). Após receber o

último segmento do objecto base, o Browser nota que ele referencia um objecto imagem com 14000 byte, pelo

que o solicita ao Servidor.

Considere ainda que:

i) Os segmentos utilizados têm 1000 bytes;

ii) a ligação tem um débito R=8 Mbit/s e um atraso de propagação de

2 ms;

iii) é enviado um segmento de confirmação (Ack) por cada segmento

bem recebido.

Suponha também que o segundo segmento do objecto imagem sofre

um atraso adicional na rede (i.e. para além do atraso de propagação) de 7

ms.

39.1. Calcule o tempo necessário, no mínimo, até à recepção do último

bit do objecto imagem pelo browser, medido desde o instante em que este

o solicita. Considere desprezáveis o comprimento dos cabeçalhos (de

todos os protocolos da pilha) e quaisquer tempos de processamento no

browser e no servidor;

39.2. Qual o menor valor da janela de recepção (RcvWindow)

anunciada pelo browser que possibilitaria esse tempo mínimo?

39.3. Qual o tamanho da janela de congestionamento do servidor, logo


após o envio do último bit do objecto imagem?

39.4. Qual o menor valor que o timeout poderia ter por forma a que a retransmissão do 2º segmento não seja

devida à expiração do temporizador?

R1: RTT+3*(TXmt+RTT)+5TXmt=4*4+8*1=24 ms (cfr TCP21.c); RTT=2*2ms R2: RcvWindowMin=8 (Para que o emissor fique limitado só pela política de controlo de congestionamento na rede) R3: CongWin =4 1/4; R4: Timeout>7 ms (que é o tempo, 3*TXmt+RTT, entre emitir o 2º segmento e receber o 3º duplicado de Ak2). Nota: Pode

suceder que o software TCP em W se baseie num só temporizador - que é cancelado (e eventualmente rearmado) quando chega um Ack que confirma a recepção do segmento mais antigo ainda por confirmar; nesse caso, bastará Timeout>4 ms.

TCP - Gestão da conexão

40. [08E1.4] A propósito do algoritmo de ajuste da janela de congestionamento designado Additive Increase,

Multiplicative Decrease (AIMD), que é utilizado no TCP, foi demonstrado (de acordo com um modelo

simplificado) que este algoritmo é justo no que diz respeito à alocação de débitos médios e também é eficiente

na alocação de recursos. Suponha agora que se alterava o TCP de forma a ajustar a janela de congestionamento

da seguinte forma: i) W=W*α, com α>1, na ausência de congestionamento; ii) W=W*β, com 0<β<1, na

presença de congestionamento. Suponha que a detecção de congestionamento seria feita da mesma forma que

no TCP convencional. Usando o mesmo tipo de argumentos, discuta se um algoritmo deste tipo também seria

justo e eficiente na alocação de recursos.

R: Considere-se uma Rede com duas conexões, uma ancorada em W e a outra ancorada em E. As Janelas de congestão são, respectivamente, CongW=8 e CongE=4. Admita-se que a Rede não suporta mais que um total de '11'. O próximo Segmento enviado por W e E perde-se, pois 8+4=12; os timeouts de W e E expiram.

Considerações sobre a equitatividade: 1. Se se usar Multiplicative Increase com α=1,6 e Multiplicative Decrease com β=0,625 (repare-se: α*β=1), - as Janelas passam a ser CongW=8*β=5 e CongE=4*β=2,5; - a evolução será: CongW=5*α=8 e CongE=2,5*α=4. Refez-se o cenário inicial… Repare-se no momento da congestão: W mantém-se em 8; E mantém-se em 4. Quer dizer: partindo de valores diferentes, continuam sendo diferentes: o sistema MIMD não é igualitário… Nota: em alternativa, pode argumentar-se como é feito no acetato "Justiça no protocolo TCP". Considerações sobre a eficiência: A evolução de CongW é (CongInicial*β)*α= CongInicial. Por mor de eficiência, deve então ser αβ=1 (ou α=1/β), e β

não se deve afastar de 1, para a Janela de Congestão não cair demasiado…

Repare-se que, no cenário acima, se verifica α*β=1. E se isso se não verificar? A resposta intui-se: 2. Se se usar α=2 e β=0,25 (repare-se: α2*β=1, e por conseguinte α*β<1), - as Janelas passam a ser CongW=8*β=2 e CongE=4*β=1; - a evolução será: CongW=2*α=4 e CongE=1*α=2; CongW=4*α=8 e CongE=2*α=4; 3. Se se usar α=1,5625 e β=0,8 (repare-se: α*β2=1, e por conseguinte α*β>1), - as Janelas passam a ser CongW=8*β=6,4 e CongE=4*β=3,2; - a evolução será: CongW=6,4*α=10 e CongE=3,2*α=5; CongW=10*β=8 e CongE=5*β=4; Repare-se: em ambos os casos (α≠β), é necessário mais tempo para repor o cenário inicial. No entrementes, - quando α*β<1, a Carga passou por 3→6: não se esgotou (i.e., desperdiçou-se) a Capacidade e Transmissão… - quando α*β>1, a Carga passou por 9,6→15: excedeu-se a Capacidade e Transmissão, 11 – provocando mais

perdas e, por conseguinte, desperdício em retransmissões…

controlo de congestão em tcpweb.ist.utl.pt/d898/public/rc-i/problems/tcpcongestion.pdf · como se...

Documents