Protocolos de transferência confiáve de dados com paralelismos
Controle de fluxo
controle de congestionamento
Mecanismos de transferência confiáveis.
rdt3.0 é correto, mas possui desempenho ruim
Porque?
quando uma maquina a manda um grupo para a maquina b
ele manda um pacote e esse pacote chega depois e ele não
manda outro porque ele espera uma confirmação
para lidar com isso usa-se um paralelismo
pode-se mandar uma quantidade maior e só aí
aguardar a confirmação por exemplo
Introduzindo o paralelismo
o atraso de propragação (ida e volta) á velocidade da luz - RTT
é de cerca de 30ms por ex.
suponha que eles estejam conectados por um canal com
capacidade de transmissão - R - de qGbps
um tamanho de pacote - L - de mil bytes (8 mil bits)
Qual é o tempo de transmissão?
tamanho dividido pela taxa de transmissão:
8 mil bits/pacotes dividido por 10^9bits/s = 8Us
Ttrans = L/R
Se o remetente começar a enviar o pacote em t = 0, então t =
L/R = 8 μs (micro segundos)
Quando o ultimo bit entrará no canal do lado
remetente
Na ida o pacote faz sua jornada de 15 ms atravessando o país;
Quando o ultimo bit do pacote emertino no
destinatário em t = RTT/2 + L/R = 15,008 ms
Ignoramos aqui o tempo de transmissão dos pacotes ACK (para
simplificar).
Quando o destinatário receber o ultimo bit, o ACK emergirá de
volta no remetente em t = RTT + L/R = 30,008 ms
Aqui o remetente poderá transmitir a próxima
mensagem
Conclusão: em 30,008 ms o remetente esteve enviando por
apenas 0,008 ms.
Se definirmos a utilização do canal como a fração do tempo em que o
remetente está realmente ocupado, a ideia do pare espere tem a utilização assim:
𝑈𝑟𝑒𝑚𝑒𝑡 = (𝐿/𝑅)/(𝑅𝑇𝑇+𝐿/𝑅)= 0,008/30,008= 0,0027
O remetente ficou ocupado apenas 2,7 centésimos de 1% do tempo.
Em outras palavras: ele só foi capaz de enviar 1000 bytes em 30,008 ms.
Vazão efetiva de 267 Kbits/s
O enlace não era de 1 Gbps?
O pare e espere no tempo zero manda o pacote, quando o pirmeiro bit chega ele manda a confirmação e só depois da confirmação ele envia o próximo em um tempo rtt + transmissão
Ja no paralelismo, no tempo t zero ele manda os pacotes até um determinado
limite, nao espera a confirmação, na medida que os cates chegam ele envia o ACK, ele define quantos pacotes vai mandar de uma vez, no exemplo são 4 Go-Bank-N (GBN) - algoritimo que determina até que ponto pode mandar multiplos pacotes até ter a confirmação (precisa da confirmação pois é transferencia confiável)
É um protocolo que o remetente é autorizado a transmitir múltiplos pacotes
sem esperar por reconhecimento.
Temos variáveis, sendo:
base: número de sequencia mais antigo do pacote não
reconhecido;
nextseqnum: menor número de sequencia não utilizado
(próximo a ser enviado)
(slide 10 - aula 5/5A 23minutos) Ex: tem-se uma quantidade de
pacote, por exemplo, uma aplicação quer mandar uma foto então ele quebra essa foto em vários pacotes, o azulzinho são os pacotes que enviaram, que saiu do sul e foi pro norte, viajou, teve o rtt e foi confirmado. Ou seja, a variável base é o numero de sequencia do comecinho da minha janela de transmissão, pro algoritmo tcp enviar o pacote ele envia o base, mas a medida que ele vai enviando, ele manda o pacote e nao espera a confirmação e ja manda o próximo até cehgar no fim da janela, de forma paralela.
Se o pacote nao chegar ele envia novamente o pacote e enquanto isso a janela nao prospera
O problema é que se um pacote se perder a janela nao anda, para resolver usa- se a repetição seletiva, deixando a janela andar e retransmitindo somente os pacotes com erro
O destinatario aceita receber os pacotes fora de ordem e depois
organiza, até o tamanho da janela
O GBN permite que o remetente “inunde” a rede com pacotes evitando
problemas de utilização de canal observados em protocolos do tipo pare e espera;
Mas ele possui um problema!
Quando o tamanho da janela e o produto entre o atraso e a largura de banda
são grandes pode haver muitos pacotes pendente na rede.
Um único erro de pacote fazo GBN retransmitir um número grande de
pacotes;
O protocolo de repetição seletiva (selective repeat – SR) evita retransmissão
desnecessárias.
São retransmitidos apenas pacotes suspeitos de terem sido recebidos com erro (perdidos ou corrompidos) A repetição seletiva resolve o problema do Go-Bank-N
ganha em volume com transmissão confiável
porém tudo deve ser controlado
CONTROLE DE FLUXO
Buffers – Recepção
Hospedeiros de cada lado de uma conexão TCP reservam um buffer de recepção para a conexão;
O processo de aplicação associado lerá os dados a partir desse buffer, mas não necessariamente no momento em que são recebidos;
Se a aplicação for relativamente lenta na leitura dos dados, o remetente pode saturar o buffer de recepção.
Solução para a saturação do buffer
TCP fornece um serviço de controle de fluxo às suas aplicações;
Tal controle elimina a possibilidade de o remetente estourar o buffer do destinatário;
Serviço de compatibilização de velocidades – taxa à qual o remetente está enviando
com a taxa que a aplicação receptora está lendo.
deixa a transmissão mais macia, sem muitas perdas e sem muitas retransmissões
TCP faz o controle do fluxo
Controle de fluxo
TCP oferece controle de fluxo fazendo com que o remetente mantenha uma variável denominada janela de recepção;
O objetivo da janela de recepção é dar ao remetente uma ideia do espaço do buffer
livre disponível no destinatário;
Como o TCP é full-duplex, o remetente de cada lado da conexão mantém uma janela de recepção distinta.
Suponha que o host A esteja enviando um arquivo grande ao host B por uma conexão TCP. O hospedeiro B aloca um buffer de recepção – RcvBuffer. De tempos em tempos, o processo de aplicação no host B faz a leitura do buffer. Duas importantes variáveis são mantidas pelo TCP:
LastByteRead – número do último byte lido do buffer pelo processo de
aplicação;
LastByteRcvd – número do último byte que chegou da rede e foi colocado no
buffer de recepção.
Dados LastByteRead e LastByteRcvd é possível estimar um tamanho máximo para
que está livre, a janela de recepção é enviada por meios dos AKS para quem esta recebendo)
Controle de fluxo – Janela de recepção
O host B diz ao hospedeiro A quanto espaço disponível ele tem no buffer da conexão colocando o valor atual de rwnd no campo da janela de recepção de cada segmento que envia a A.
Inicialmente rwnd = RcvBuffer.
a cada ack ele conta o tamanho do buffer ainda disponível
Controle de fluxo – Janela de recepção - Rementente
O host A monitora duas variáveis:
LastByteSent – número do último byte enviado
LastByteAcked – número do último byte reconhecido
Suponha que LastByteSent = 90000 e LastByteAcked = 20000. O host A poderia
continuar a enviar dados?
Com base nisso, o que podemos dizer da relação entre LastByteSent, LastByteAcked e rwnd?
LastByteSent – LastByteAcked <= rwnd
Ou seja, LastByteSent – LastByteAcked é a quantidade de dados não reconhecidos que
A enviou para B.
Mantendo a quantidade de dados não reconhecidos menor que o valor de rwnd, o
host A tem certeza de que não está fazendo transbordar o buffer de recepção em B.
Controle de fluxo – Janela de recepção - Problema
Suponha que rwnd = 0. Após anunciar ao host A que rwnd=0, imagine que B não tenha nada para enviar ao host A.
O que vai acontecer?
Suponha que rwnd = 0. Após anunciar ao host A que rwnd=0, imagine
que B não tenha nada par enviar ao host A.
O que vai acontecer?
O processo de aplicação em B esvazia o buffer e o TCP não envia
segmentos com novos valores rwnd para o host A.
O host A nunca será informado de que foi aberto algum espaço no buffer de recepção do host B!
Host A ficará bloqueado e não poderá transmitir dados...
Como resolver?
Controle de fluxo – Janela de recepção - Solução
A especificação do TCP requer que o host A continue a enviar
segmentos com um byte de dados quando a janela de recepção de B for zero!
Esses segmentos serão reconhecidos pelo receptor e na
medida que o buffer esvazia, novos segmentos enviados por B terão valores diferentes de zero em rwnd. Ou seja, A continua mandando nem que seja pelo menos um lixo para verificar o estágio do buffer
![[Tutorial] Estou No Computador, Como Acesso a Rede Wi-Fi Conecta UFPE_ - FAQ - Central de Serviços de TIC - NTI](https://imgv2-1-f.scribdassets.com/img/document/411729632/149x198/0945a684b5/1559061260?v=1)
