Controlo de Congestão TCP. Redes e Serviços de Comunicação Multimédia Secção de Redes de Comunicação de Dados

Transcrição

1 Controlo de Congestão TCP Redes e Serviços de Comunicação Multimédia Secção de Redes de Comunicação de Dados

2 Sumário: Controlo de Congestão Contexto e motivação Classificação de esquemas de controlo de congestão Controlo de congestão LDA+ Controlo de congestão TFRC. Controlo de congestão MTCP Controlo de congestão RLC Controlo de congestão FLID-DL Avaliação crítica dos esquemas de controlo de congestão Conclusões 27/12/06 2

3 Motivação Caso geral: Ausência de reserva de recursos (e.g. RSVP) Apenas o controlo de congestão ponto-a-ponto pode evitar o colapso da rede Acima de tudo: Justiça! Controlo de congestão TCP : As fontes variam o seu débito modificando a dimensão da janela do TCP Window = min {Advertised window, Congestion Window} throughput Rate 27/12/06 3 t load

4 Motivação Controlo de congestão através da janela do TCP não é apropriado para aplicações multimédia: A escala de tempo muito curta (RTT) obriga a fonte a mudar o débito constantemente Variações de qualidade! Tráfego não-tcp (e.g. tipíco na distribuição de dados multimédia) pode levar a situações de distribuição injusta da largura de banda ou mesmo a situações de colapso: Quando se encontra congestão todos os fluxos TCP diminuem o seu débito Os fluxos não-tcp (e.g. UDP) continuam a enviar ao mesmo débito Essencial definir mecanismos de adaptação de débito compatíveis com os requisitos das aplicações multimédia e garantindo uma distribuição justa dos recursos disponíveis 27/12/06 4

5 Classificação de esquemas de controlo de congestão Window-based: baseado na noção de uma janela no emissor ou receptor Cada pacote enviado consome um slot da janela de transmissão Cada pacote recebido ou o ACK de um pacote liberta um slot na transmissão O emissor só pode enviar pacotes quando existe espaço livre na janela Rate-based: adapta o ritmo de transmissão baseada num mecanismo de medida da congestão da rede Esquemas tipo AIMD (Additive Increase Multiplicative Decrease) não servem para distribuição de dados multimédia Esquemas baseados em modelos: o ritmo do tráfego é mais suavizado em comparação com o controlo de congestão do TCP Unicast vs. Multicast: desejável para ambos os tipos de tráfego, para o caso multicast é necessário ajustar cuidadosamente o tráfego na congestão sofrida por todos os receptores 27/12/06 5

6 Classificação de esquemas de controlo de congestão Single-rate (aplicável ao unicast/multicast) : Os dados são enviados ao mesmo débito para todos os receptores Multirate (aplicável apenas ao multicast): Alocação dinâmica da largura de banda entre os diferentes caminhos/receptores Os dados são transmitidos por camadas em diferentes grupos multicast O receptor pode subscrever um ou mais grupos de acordo com a largura de banda disponível ou capacidades do terminal Quantos mais grupos mais qualidade! End-to-End: o receptor envia feedback sobre a qualidade da emissão e o emissor ajusta o débito de acordo com a congestão que observa Router supported: os routers podem facilitar o controlo de congestão através de várias estratégias: medidas de RTT, gestão de grupos ou de filas de espera 27/12/06 6

7 Protocolos de controlo de congestão TCP-friendly 27/12/06 7

8 Controlo de congestão LDA+ O emissor ajusta o ritmo de transmissão baseado apenas nas mensagens de RTCP periódicas Controlo de congestão AIMD em que os factores aditivos (aumento do ritmo transmissão) e multiplicativos (decréscimo do ritmo de transmissão) dependem das condições da rede: Estimativa do débito binário máximo da ligação Factor aditivo depende de três regras: Os fluxos não podem exceder o débito binário máximo Os fluxos não podem aumentar o seu ritmo mais rapidamente que o protocolo TCP Os fluxos com ritmos de transmissão mais baixos aumentam o seu ritmo de transmissãio mais rápidamente que fluxos com ritmos de transmissão elevados Factor multiplicativo depende das perdas de pacotes observadas 27/12/06 8

9 Controlo de congestão TFRC TCP Friendly Rate Control (TFRC) : RFC 3448, Unicast O ritmo de transmissão é baseado num complexo modelo matemático com vários parâmetros que exprimem o atraso, perda de pacotes, dimensão dos segmentos, etc. São enviados reports do receptor para o emissor para indicar as perdas observadas (em média) O emissor estima o RTT entre o emissor e o receptor a partir dos reports recebidos e de informação de temporização (timestamps) já enviada O emissor actualiza os parâmetros do modelo e calcula o novo ritmo de transmissão 27/12/06 9

10 Controlo de congestão TEAR Window-based: o receptor emula o comportamento do TCP no emissor (especialmente a janela de congestão) calcula um ritmo de transmissão que é enviado ao emissor (report), e este altera o ritmo de transmissão de acordo com o pedido O ritmo de transmissão é suavizado de forma a evitar alterações de débito muito frequentes Não é necessário o envio de pacotes ACK, suporte a multicast CWND The sender sets its xmission rate to R Sender Report rate R. Receiver Emulate TCP window adjustment Receiver 27/12/06 10

11 Controlo de congestão MTCP Multicast TCP : controlo de congestão baseado em janelas. MTCP junta os participantes numa árvore (raiz é o emissor) em que cada nó: Encaminha e guarda o pacote até receber o respectivo ACK de todos os nós filhos Depois de receber um pacote transmite um ACK a cada um dos seus nós pai Em cada nó existe uma janela de congestão semelhante á do TCP : Só é incrementada quando todos os ACKs dos nós filhos forem recebidos Um nó filho pode enviar NACKs para pedir a retransmissão ao respectivo nó pai A janela de congestão é reduzida a ½ se receber três NACKs ou ocorrer um timeout Em cada ACK, um nó envia um relatório de congestão aos seus nós pai com estatísticas sobre a congestão observada por ele e pelos seus vizinhos O emissor ajusta o débito de acordo com os relatórios recebidos (evita implosão de ACKs) 27/12/06 11

12 Controlo de congestão multicast Sender 1 Mb/s R 1 Mb/s 512 Kb/s 2. Congestão ocorre por que não existe largura de banda suficiente para suportar uma nova camada. Receiver 3 R Receiver 3 1 Mb/s 128 Kb/s Receiver 2 1. Receiver 2 realiza uma experiência de join. Adiciona uma camada através da subscrição do respectivo grupo multicast. 3. Receiver 2 detecta a congestão e abandona a camada adicionada. A experiência de join falhou 27/12/06 12

13 Controlo de congestão RLC Protocolo Multirate: Receiver-Driven Layered Congestion Control (RLC) Introdução de camadas em que a largura de banda consumida por cada camada aumenta exponencialmente, e.g. L0->2, L1->4, L2->8 Um receptor antes de subscrever uma nova camada deve esperar um tempo que aumenta exponencialmente conforme a camada Uma camada é abandonada imediatamente pelo receptor (leave) quando se observa perda de pacotes Os receptores podem subscrever novas camadas de uma forma síncrona nos pontos de sincronização SP Antes de cada SP, o ritmo de transmissão de cada camada duplica de forma a evitar subscrições falhadas 27/12/06 13

14 Controlo de congestão FLID-DL Fair Layered Increase/Decrease with Dynamic Layering Baseado em Digital Fountains, uma abstracção dos códigos correctores de erros utilizados nas redes de comunicações. Os receptores podem descodificar os dados quando tiverem recebido um número fixo mas arbitrário de pacotes distintos Dynamic Layering: largura de banda consumida por uma camada decresce ao longo do tempo O receptor deve subscrever a novas camadas de uma forma periódica para garantir o débito binário desejado As camadas são reutilizadas ao fim de um determinado período de tempo Para reduzir o débito apenas é necessário não subscrever a novas camadas Evita a latência dos leaves, os joins são sincronizados de forma semelhante ao RLC 27/12/06 14

15 Avaliação crítica dos esquemas de controlo de congestão Esquemas single-rate: Os protocolos rate-based ignoram os timeouts o que causa comportamentos mais agressivos e reacções mais lentas MTCP é bastante complexo e exige suporte nos routers Esquemas multirate: Exigem que os dados sejam organizados em camadas o que não é muito comum na codificação de voz, áudio e vídeo Granularidade baixa, e.g. latência de joins e leaves Assentam no uso de serviços multicast 27/12/06 15

16 Avaliação crítica dos esquemas de controlo de congestão 27/12/06 16

17 Conclusões Os protocolos de congestão apresentados fornecem uma alternativa importante para Distribuição de fluxos multimédia com uma latência baixa Manter a justiça e o equilibrio quando ocorre congestão Devem ser combinados com mecanismos ao nível do router que penalizem os fluxos não conformes Outra alternativa: controlo de congestão sobre UDP Uma vez que para algumas aplicações multimédia (e.g. VoIP) as retransmissões não são úteis 27/12/06 17