Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet Aula...

Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

Aula Anterior

Diferentes tipos de Aplicações Aplicações Elásticas (ftp, email 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)


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

Aula Anterior (cont.)


Requisitos das Aplicações

Aplicações Elásticas (ftp, email, 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....


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

Requisitos das Aplicações


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


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


Infra-estrutura best-effort

• Cenário muito simplificado:

IP

Router

L2

L1 L3

L4

fila de espera

• Capacidade de processamento

• Memória, buffers internos

• Técnicas de gestão dos buffers

Características:


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.

Infra-estrutura best-effort


Situações de Congestão

Router

L2

L1 L3

buffer cheio

• 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...)

Pacotes de aplic. T.R.

Pacotes gerados por ftp

Como conseguir tratamento diferenciado de tráfego na infra--estrutura e diferentes níveis deQoS ?


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

QoS Garantido


QoS Garantido

• Exemplo simplificado (router) com múltiplas filas de espera: Router

L2

L1L3

Pacotes de aplic. T.R.

Pacotes gerados por ftp

R1

R2

Data

• Priorizar pacotes de tempo-real para as filas de espera

• Garantir que se processa x pacotes/tempo numa dada fila de espera


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...)


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.


Soft State

Os encaminhadores mantêm o estado de reserva. Mensagens refrescam o estado Estados não refrescados são removidos

automaticamenteAlternativa: 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?


Soft State (cont)

Propriedades Adapta-se a mudanças em rotas,

emissores e recpetores. Recupera de falhas

Filosofia: a reserva é uma optimização.


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,...)


Arquitectura do RSVP (router)

Packet Classifier

Packet Scheduler

Routing Protocol

RSVP Daemon

Policy Control

Admission Control

Data

• 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


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

Arquitectura do RSVP (cont.)


RSVP (multicast)

E

RRR

E - EmissorR - Receptor

mensagens path

necessárioguardar o caminho inverso

E

RRR

mensagens Resv para o emissor E ponto de junção de pedidos

path

path

path

path

path

resv

resv

resv

resv

resv

Mensagens RSVP


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


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

emissoresexplicit - pedido de reservas para aplicar a uma

determinada lista de emissores

Forma processamento de reservas entre os emissores:distinct - reserva independente para cada emissorshared - reserva partilhada entre todos os emissores


Estilos de Reservas (cont.)

Sender Selectio

n

Reservation

Distinct Shared

Explicit

Wildcard (not defined)

Fixed-Filter (FF)

Shared-Explicit (SE)

Wildcard-Filter (WF)

• 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)


Exemplos de Reservas

Router

(S1)

(S2,S3)

(R1)

(R2)

(R3)

(a)

(b)

(c)

(d)

Exemplo de Reserva do tipo WF

SEND RESERVE RECEIVE

(c) < WF( * {4B})

(d) < WF( * {3B}) < WF( * {2B})

(c)

(d) * {3B})

* {4B})

WF( * {4B}) <(a)

WF( * {4B}) <(b)


Exemplos de Reservas (cont.)

Router

(S1)

(S2,S3)

(R1)

(R2)

(R3)

(a)

(b)

(c)

(d)

Exemplo de Reserva do tipo FF

SEND RESERVE RECEIVE

(c) < FF(S1{4B},S2{5B})

(d) < FF(S1{3B},S3{B}) < FF(S1{B})

(c)

(d)

S3{B})

S1{4B})

FF(S1{4B}) <(a)

FF(S2{5B},S3{B}) <(b)

S2{5B})

S1{3B})


Anomalias no RSVP

Designadas por Killer reservation problems P1 (KR-I)

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.


Anomalias no RSVPP2 (KR-II)

Tentativa de reserva persistente Q1 é negadaPersistê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


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


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

User

Kernel

aplicação libraria rsvpcliente Servidor

Rsvp

Servidor Rsvp

dados dados dados

mensagens rsvp

pipe unix

classifierscheduler

classifierscheduler


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 .....


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.


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


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

E

alta qualidade

média qualidade

qualidade básica

grupos multicast diferentes

R

R

R


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>

Cod. Hierárquica + Prioridades


Priorização de Tráfego

Por vezes é necessário algum feedback para não estar a ser desperdiçada largura de banda.

E R

X

Y

médiabaixa baixa

altamédiabaixa

• Necessidade de alguma comunicação fim-a-fim entre E/R para optimizar o processo

• Camadas alta e média são redundantes e prejudicam outo tráfego

ligação de alto débito

ligação débito médio

ligação baixo débito

Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet Aula...

Documents

Transcript of Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet Aula...