Aula Anterior Diferentes tipos de Aplicações Aplicações de Tempo Real

Apresentação em tema: "Aula Anterior Diferentes tipos de Aplicações Aplicações de Tempo Real"— Transcrição da apresentação:

1 Aula Anterior Diferentes tipos de Aplicações Aplicações de Tempo Real
Aplicações Elásticas (ftp, etc...) Aplicações Tempo Real Aplicações de Tempo Real Aplicações multimedia (audio, vídeo, etc...) Aplicações ponto-ponto/multi-ponto Dois tipos de Aplicações T.R. : Adaptativas vs Rígidas Suportes Protocolares Sobre cenários best-effort inadequação do TCP e UDP Necessidade de procedimentos adaptativos Protocolo RTP (Real Time Protocol) Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

2 Aula Anterior (cont.) Protocolo RTP
unicast/multicast Canais RTP + RTCP (informação de controlo) Mecanismos de Controlo adoptados pelas Aplicações atrasos variação dos atrasos (jitter) Buffers de amortecimento Estratégias de reprodução de informação Adaptação às perdas de pacotes Algoritmos para cenários multicast (ponderação de estados) Sincronização dados sobre canais RTP Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

3 Requisitos das Aplicações
Aplicações Elásticas (ftp, , etc...) Largura de banda ++ Para algumas limites nos atrasos Aplicações Tempo-Real (Adaptativas) Proliferam cada vez mais nos ambientes computacionais (IP) Audio, Vídeo, Vídeo-Conferência - aplicações usuais para os utilizadores finais Largura de banda (apesar das compressões, adaptações,...) Limites aceitáveis para atrasos, variações de atrasos, etc. isto porque.... Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

4 Requisitos das Aplicações
Processos adaptativos são limitados Em situações de saturação da infra-estrutura torna-se impossível a utilização deste tipo de aplicações Existem aplicações não se enquadram na perspectiva adaptativa e tolerante Redes IP - Infra-estrutura inicialmente concebida para a comutação de pacotes e que agora enfrenta o desafio dos requisitos das novas aplicações. Necessidade de introduzir novas funcionalidades que satisfaçam as aplicações/utilizadores Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

5 Qualidade de Serviço (QoS)
QoS - conjunto de parâmetros segundo os quais a aplicação poderá ter um desempenho aceitável. Largura de Banda ( X Kbytes/seg) Atraso máximo fim-a-fim Variação de atrasos limitada (jitter limitado) etc... A aplicação quer uma Qualidade de Serviço Guarantida pela infra-estrutura de comunicação utilizada. Protocolos adequados à garantia de QoS requerida pelas aplicações Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

6 Redes IP Tradicionais Adequadas à comutação de dados
Não foram projectadas para serem utilizadas massivamente por aplicações com requisitos estritos de QoS Protocolo IP não estava projectado objectivamente para esses requisitos Comutadores utilizados (routers) não tinham preocupações com requisitos de QoS orientados às aplicações Em termos gerais um infra-estrutura best-effort Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

7 Infra-estrutura best-effort
Cenário muito simplificado: L4 Router IP fila de espera L1 L3 L2 Capacidade de processamento Memória, buffers internos Técnicas de gestão dos buffers Características: Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

8 Infra-estrutura best-effort
Num cenário IP best-effort Comutadores não atendem às necessidades particulares de cada aplicação (stream de pacotes IP) Tratamento é igual para todos os pacotes IP (salvo algumas excepções implementadas pelos fabricantes e previstas nos protocolos..., protocolos prioritários..., mecanismos de priorização de tráfego etc...) Em situações de congestão os pacotes são eliminados independentemente do tipo de dados que transportam. Aplicações elásticas podem recuperar através de protocolos fiáveis (TCP) Aplicações de Tempo Real perdem informação que dificilmente poderá ser útil após recuperação. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

9 Situações de Congestão
Router buffer cheio L1 L3 Pacotes de aplic. T.R. Pacotes gerados por ftp L2 Situação de congestão: capacidade de output de pacotes não acompanha os ritmos de chegada ao router. Proceder à eliminação de pacotes que chegam ao router (independentemente...) Como conseguir tratamento diferenciado de tráfego na infra- -estrutura e diferentes níveis de QoS ? Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

10 QoS Garantido Protocolos de setup da infra-estrutura
Definem o tipo de QoS desejado pelas aplicações Comunicam o tipo de tráfego e o QoS aos elementos de comutação da infra-estrutura IP - RSVP (Resource Reservation Protocol) Elementos de comutação habilitados a cumprir esses requisitos Técnicas de processamento de pacotes que guarantam um determinado nível de serviço para determinados pacotes Domínio da matemática, estatística, e de diversos métodos de gestão de tráfego Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

11 QoS Garantido Exemplo simplificado (router) com múltiplas filas de espera: Router R1 R2 L3 Data L1 Pacotes de aplic. T.R. Pacotes gerados por ftp L2 Priorizar pacotes de tempo-real para as filas de espera Garantir que se processa x pacotes/tempo numa dada fila de espera Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

12 RSVP (Resource Reservation Protocol)
Protocolos de sinalização de reserva de recursos projectado para as redes IP Informar os elementos (routers) da infra-estrutura de um determinado QoS garantido aos pacotes gerados por uma determinada aplicação Apto para comunicações unicast ou multicast Processo iniciado pelos receptores de informação Engloba uma série de mensagens emitidas pelos emissores e pelos receptores Processo de reservas é independente do processo de routing Soft State - poderão existir alterações dinâmicas às reservas efectuadas (mensagens de actualização, time-outs, etc...) O RSVP foi proposto para incluir garantias de QoS na Internet. O objectivo é permitir a comunicação entre as aplicações e routers, para serem reservados os recursos necessários para o trafego gerado pelas aplicações.O RSVP está concebido para funcionar tanto em ambientes unicast como multicast. O pedido transita por um conjunto de nós do emissor até ao receptor.O pedido de alocação de recursos é feito pelo receptor e não pelo emissor. O emissor envia inicialmente uma descrição do tráfego (PATH) que vai ser recebido pelos receptores. Com base nessa descipção os receptores geram uma mensagem de reserva (RESV) que especifica o tipo de tráfegoa tratar e o QoS pretendido.Esta mensagem passa por todos os encaminhadores do recpetor até ao emissor e caso eles possam oferecer o serviço pretendido será enviada uma mensagem de confirmação (RESvConf). As mensagens PATH (com endereço IP unicast do 1º router) são transmitidas da mesma forma que os dados de aplicação segundo a árvore multicast duma dada sessão. Também têm como objectivo armazenar informação de estado em cada encaminhador. Uma outra característica importante do RSVP é o processo de encaminhamento e o processo de reservas serem independentes. O RSVP tem que se adaptar e ajustar os recursos alocados em caso de alteração da rota dos pacotes. Esta e outras características definem o RSVP como seguindo uma filosofia de soft state (estado fraco): podem existir alterações dinâmicas às reservas efectuadas usando mensagens de sinalização. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

13 Modelo de serviço RSVP Fazer reservas para fluxos de dados simplex.
O recpetor decide quando fazer reservas Mensagens de controlo em datagramas IP (proto #46). Mensagens PATH/RESV enviadas para refrescarem o estado periodicamente. Um passo: Pedidos não satisfeitos devolvem uma mensagem de erro- O Rx deve tentar de novo Não há confirmação fim a fim para sucesso. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

14 Soft State Os encaminhadores mantêm o estado de reserva.
Mensagens refrescam o estado Estados não refrescados são removidos automaticamente Alternativa: Hard state Não há mensagens periódicas de refrescamento. Há garantia que o estado é mantido até ser explicitamente removido. Porque pode ser um problema? Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

15 Soft State (cont) Propriedades Filosofia: a reserva é uma optimização.
Adapta-se a mudanças em rotas, emissores e recpetores. Recupera de falhas Filosofia: a reserva é uma optimização. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

16 RSVP (cont.) Duas mensagens fundamentais:
Path - Descreve o tráfego que vai ser gerado pelo emissor; gerada pelo emissor; transmitida até aos receptores (passando pelos routers e armazenando o end. nó anterior) Resv - Geradas pelos receptores; especifica o QoS pretendido para um conjunto de pacotes gerados pelo emissor; terá que passar por todos os routers no caminho entre o emissor e receptor endereço do emissor endereço do destino (por exemplo um grupo multicast) parâmetros de QoS pretendidos (atrasos, variações, perdas...) filter - indica o tipo de dados a que se pretende atribuir o QoS especificado (protocolos, portas,...) Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

17 Arquitectura do RSVP (router)
Policy Control Routing Protocol RSVP Daemon Admission Control Data Packet Classifier Packet Scheduler Antes de se efectuar a reserva o RSVPD comunica com 2 módulos: Admission Control - Verifica se o router tem recursos suficientes para satisfazer o pedido Policy Control - determina se a entidade responsável pelo pedido está ou não autorizada a fazê-lo Se algum destes módulos não autorizar - mensagem de erro Se estes dois módulos autorizarem Em cada encaminhador antes de fazer qq reserva o processo RSVP comunica com dois módulos: o controle de admissão e o controlo de autorizações. Se algum dos módulos não autorizar o pedido, é gerada uma mensagem de erro para a aplicação. Em caso afirmativo, são actualizados os parâmetros pelo classificador de pacotes e pelo escalonador. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

18 Arquitectura do RSVP (cont.)
Actualização de parâmetros nos módulos: packet classifier - classifica o pacote para um determinado processamento; calcula a rota; QoS necessário etc... packet scheduler - processo de forwarding do pacote; alocar tempo de CPU, buffers, etc. Ambientes multicast Conjunto de routers que reservam recursos para pedidos de n receptores Em alguns pontos da árvore multicast os routers poderão fazer o merging de pedidos feitos por diferentes receptores Actualização de estado consoante entrada/abandono dos receptores no grupo multicast O RSVP está apto a funcionar em ambientes de comunicação um-para muitos. Se tivermos n receptores para um emissor, teremos uma mensagem de path e n mensagens de reserva. Há aqui pontos de junção dos pedidos, em pontos do caminho comuns desde os receptores até ao emissor... Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

19 guardar o caminho inverso
RSVP (multicast) Mensagens RSVP E E path resv resv path resv path path resv resv path necessário guardar o caminho inverso R R R R R R E - Emissor R - Receptor ponto de junção de pedidos mensagens path mensagens Resv para o emissor E Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

20 Estilos de Reserva 3 Estilos
Wildcard/Sem filtro – Não especifica um emissor particular no grupo Filtro fixo – o emissor é especificado para a reserva. Conferência Video Filtro dinâmico – emisores válidos podem variar com o tempo. Conferência Audio Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

21 Estilos de Reservas (cont.)
Um pedido de reservas inclui uma série de opções: Identificação de emissores: wildcard - pedido de reserva para aplicar a todos os emissores explicit - pedido de reservas para aplicar a uma determinada lista de emissores Forma processamento de reservas entre os emissores: distinct - reserva independente para cada emissor shared - reserva partilhada entre todos os emissores Um pedido de reserva efectuado por qualquer receptor inclui uma série de opções geralmente designadas por estilos de reserva. Uma dessas opções diz respeito à identificação dos diferentes emissores na sessão de comunicação em grupo. Ou se identificam explicitamente os emissores ou se faz uma selecção automática para todos emissores. Uma outra opção ocupa-se da forma como são processadas as reservas entre os diferentes emissores. Podem ser distintas (independentes) ou partilhadas. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

22 Estilos de Reservas (cont.)
Reservation Distinct Shared Sender Selection Fixed-Filter (FF) Explicit Shared-Explicit (SE) Wildcard-Filter (WF) (not defined) Wildcard As reservas partilhadas do tipo WF ou SE, são apropriadas para as aplicações em grupo em que é improvável que as múltiplas fontes de informação transmitam simultaneamente. Um exemplo de aplicações deste tipo será um canal áudio numa dada sessão, pois só um número de pessoas poderá falar ao mesmo tempo. Assim cada receptor poderá gerar pedidos WF ou SE num valor que seja o dobro da LB necessária para contemplar a sobreposição. Pelo contrário o estilo FF cria reservas distintas para emissores diferentes e poderá ser apropriado para sinais de vídeo numa dada videoconferência. Neste caso os e de encaminhadores não poderão juntar reservas de tipos diferentes. Os estilos WF, SE e FF são incompatíveis. Exemplo de Vídeo-Conferência, que tipos de reservas ? SE ou WF para o canal audio (2*débito da codificação) FF para o canal vídeo (n*débito da codificação) Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

23 Exemplos de Reservas Exemplo de Reserva do tipo WF Router SEND RESERVE
(c) (S1) (R1) Router (b) (d) (R2) (S2,S3) (R3) Exemplo de Reserva do tipo WF SEND RESERVE RECEIVE Suponhamos a existência dum router com 2 interfaces de entrada e duas de saída. Imaginemos três emissores e três receptores de informação.Os pacotes enviados por S1 chegam através de (a). Os pacotes de S2 e S3 chegam através de (b). Os pacotes destinados a R1 são enviados através de (c) e os destinados a R2 e R3 através de (d), que está ligada a uma LAN com difusão e que o R2 e R3 são atingíveis através de diferentes encaminhadores. Os tráfego multicast recebido dos Si é encaminhado através das duas interfaces de saída. Assume-se que todos os pedidos de reserva são múltiplos duma quantidade B de recursos. A coluna receive mostra os pedidos de reserva recebidos na interfaces de saida. A coluna reserve mostra o resultado da reserva para cada uma das interfaces. A coluna Send mostra os pedidos de reserva que serão enviados para os routers imediatamente acima das interfaces (a) e (b). WF( * {4B}) <(a) (c) * {4B}) (c) < WF( * {4B}) * {3B}) (d) < WF( * {3B}) < WF( * {2B}) WF( * {4B}) <(b) (d) Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

24 Exemplos de Reservas (cont.)
Router (b) (d) (R2) (S2,S3) (R3) Exemplo de Reserva do tipo FF SEND RESERVE RECEIVE FF(S1{4B}) <(a) (c) S1{4B}) (c) < FF(S1{4B},S2{5B}) Os exemplos apresentados assumem como tinha sido indicado que os pacotes enviados por S1, S2 e S3 eram encaminhados por ambas as interfaces de saída. Existem S2{5B}) (d) S1{3B}) (d) < FF(S1{3B},S3{B}) < FF(S1{B}) FF(S2{5B},S3{B}) <(b) S3{B}) Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

25 Anomalias no RSVP P1 (KR-I) Designadas por Killer reservation problems
Existe uma reserva Q0 Tentativa de uma segunda reserva Q1> Q0 Rejeição em encaminhador intermédio Não deve resultar no bloquear de Q0 Solução: manter as reservas anteriores, quando o módulo de admissão negar determinada reserva. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

26 Anomalias no RSVP P2 (KR-II)
Tentativa de reserva persistente Q1 é negada Persistência: apesar de negado, o receptor persiste na tentativa de a obter. Se houver novo pedido Q0 não deve ser negado (se houver recursos) Não deve ser feita junção Solução: A mensagem de erro ResErr estabelece um novo estado nos encaminhadores por onde passou o pedido. Este estado altera o procedimento de junção, permitindo que reservas inferiores possam ser aceites. A Reserva Q1 permanece em estado bloqueado Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

27 Anomalias no RSVP Uma reserva negada num nó de comutação
Origina um estado de bloqueado nesse nó mas as reservas dos nós inferiores continuam activas Não será desnecessário? O rx está interessado em descobrir a disponibilidade de recursos ao longo uma rota ou no máximo nº de nós nessa rota Poder-se-ia prejudicar a resposta em situações transitórias Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

28 API para o RSVP Os mecanismos de reservas de recursos alteram alguns conceitos inerentes à programação em rede (sockets, etc.) Necessidade de elaborar librarias que incorporem os mecanismos definidos pelo RSVP Permitir ao programador manipular pedidos de QoS aos routers da infra-estrutura. Host Router libraria rsvp cliente aplicação Servidor Rsvp Servidor Rsvp Como se compreende o modelo proposto pelo RSVP implica n~ao so o desenvolvi-mento de novas funcionalidades para adicionar aos routers, como tambem alterac~aodos interfaces de programac~ao postos ao dispor do utilizador. Assim e suposto odesenvolvimento de novas librarias de programac~ao e novos interfaces de comuni- cac~ao em rede que contemplem as funcionalidades descritas anteriormente. Em [20] edescrita uma API de programac~ao para o protocolo RSVP. Basicamente existe uma libraria que devera ser compilada com o programa. Esta libraria comunica com o modulo RSVP local, que por sua vez se encarrega de propagar as mensagens RSVPaos servidores RSVP dos routers vizinhos. Os routers poder~ao aceitar ou negar o pedido, dependendo dos recursos disponveis. Em caso da n~ao aceitac~ao o modulo RSVP local devolvera a aplicac~ao (via API) a decis~ao tomada. Na gura est~ao esquematizados os modulos que est~ao directa ou indirectamente ligados a API. User mensagens rsvp Kernel pipe unix dados dados dados classifier scheduler classifier scheduler Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

29 Reserva de Recursos Não é consensual !!!
Vantagens/Desvantagens (elevada informação de estado nos nós) Altera o cenário normal de distribuição de recursos pelos utilizadores/aplicações Se levada a extermos poderá bloquear acessos ao serviços de rede por parte das aplicações Dúvidas quanto ao tipo de utilização desta técnica (usar em interligação de infra-estruturas de redes, extender a tecnologia até ao utilizador) Reservar/pagar ? Técnicas intermédias de diferenciação de tráfego prioridades codificação hierárquica ..... Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

30 Divergências É possível construir aplicações inteligentes que se adaptam às condições da rede (playout buffers, codificações adaptativas, codificação hierárquica, mecanismos de prioridades, etc.) No entanto, em qq uma delas não se tem à priori a certeza de que tipo de condições elas vão enfrentar. Para tal é necessário garantias de QoS Devemos garantir QoS num futuro próximo na infra-estrutura da Internet Esta filosofia é desnecessária e devemos unicamente fornecer + largura de banda e continuar a desenvolver aplicações adaptativas, e alguns mecanismos de diferenciação do tráfego. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

31 Mecanismos alternativos (ao rsvp)
Atribuir diferentes prioridade de processamento a diferentes protocolos, portas protocolares, etc... Utilizar codificações hierárquicas da informação a transmitir Apostar nas técnicas de codificação/compressão de informação Utilizar informação do cabeçalho IP para o router dar um tratamento preferêncial a determinados pacotes. flow label do IPv6 TOS (type of Service IPv4 e análogo do IPv6) Differentiated Services - Grupo IETF que tenta normalizar a interpretação do TOS (IPv4) e Traffic Class (IPv6) por forma aos routers realizarem um tratamento diferenciado para diferentes pacotes IP Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

32 Codificação Hierárquica
Por exemplo: O emissor envia em grupos multicast distintos diferentes codificações dos media vantagens: dados de uma codificação só chegam a uma determinada rede se existir alguem interessado desvantagens: condições da infraestrutura afectam por igual todas as sessões; período probatório poderá prejudicar outros receptores alta qualidade média qualidade R E qualidade básica R grupos multicast diferentes R Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

33 Cod. Hierárquica + Prioridades
Por exemplo: Dados são emitidos na mesma sessão indicando quais os mais/menos prioritários (opções do IP). Em caso de congestão routers eliminam os menos prioritários vantagens: Em caso de congestão a informação básica terá + hipóteses de alcançar os receptores Permite à aplicação definir quais as codificações +/- importantes em termos de serviço básico/médio/alta qualidade, etc.... Em situações de congestão os pacotes - prioritários são eliminados não prejud. assim a informação básica desvantagens: Existem situações em que existe informação redundante na infra-estrutura <próximo acetato> Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

34 Priorização de Tráfego
Por vezes é necessário algum feedback para não estar a ser desperdiçada largura de banda. ligação de alto débito ligação débito médio X ligação baixo débito alta média baixa média baixa baixa E R Y Camadas alta e média são redundantes e prejudicam outo tráfego Necessidade de alguma comunicação fim-a-fim entre E/R para optimizar o processo Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet