Aplicações e Reserva de Recursos na Internet

Apresentação em tema: "Aplicações e Reserva de Recursos na Internet"— Transcrição da apresentação:

1 Aplicações e Reserva de Recursos na Internet
Sistemas Telemáticos LESI Grupo de Comunicações por Computador 2000

2 Objectivos Abordar os requisitos das novas aplicações no âmbito das redes de computadores. Verificar a adequabilidade da filosofia best-effort a esses requisitos (alguns deles motivados pelas aplicações multimedia de tempo-real) Técnicas usadas pelas aplicações T.R sobre cenários best-effort. Novas soluções protocolares que garantam Qualidade de Serviço (QoS). A Internet do passado e dos nossos dias baseia-se no paradigma melhor esforço (best-effort). Exceptuam-se apenas algumas ilhas em que cumprem determinados padrões de qualidade de serviço. O que é o paradigma best-effort? Infra-estrutura de rede em que os diversos intervenientes acedem livremente acedem de forma concorrente e sem controlo aos recursos disponíveis. Aparecem cada vez mais aplicações com diferentes tipos de requisitos e exigências da rede subjacente. A gama é cada vez mais heterogénea. O funcionamento correcto de algumas dessas aplicações exige a adopção de estratégias particulares pelas entidades protocolares e por elas próprias. Bons exemplos são as aplicações multimédia, aplicações de suporte à comunicação entre utilizadores e aplicações com um elevado grau de interactividade. Os protocolos de transporte utilizados na Internet parecem n~ao se adequarem totalmente as necessidades deste tipo de aplicacões, quer por serem demasiado penalizantes em situacões anomalas (como seja o caso do TCP) quer por não incluirem os mecanismos imprescindveis ao correcto funcionamento das aplicacões de tempo-real.Por esta razão, e necessario proceder a definição ao de novos suportes protocolares mais adequados a esta famlia de aplicacões. Estes devem resolver com eficacia os problemas inerentes a este tipo de servicos como sejam: assegurar o isocronismo dos dados transportados, sincronizacão de fontes, adaptação a condicões anomalas, controlo deatrasos, controlo do estado das ligac~oes, etc Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

3 Classificação de Aplicações
Aplicações Elásticas Aplicações de Tempo Real Intolerantes Tolerantes -O tipo de aplicac~oes que actualmente operam sobre as redes de computadores apresentam diferentes tipos de comportamento e, adicionalmente, requerem diferentes tipos de qualidade de servico por parte das infra-estruturas onde operam. O cenario ideal corresponderia a termos, para cada tipo de aplicac~ao, um conjunto de par^ametros de qualidade de servico que as satiszessem totalmente (em termos de largura de banda, atrasos e variac~ao dos tempo de entrega dos pacotes, fiabilidade etc...). Claro esta que nem sempre isto sucede, e se tomarmos como exemplo a denominada Internet cedo verificamos que nem sempre as infra-estruturas foram inicialmente concebidas por forma a suportarem a perfeita conviv^encia entre t~ao diferentes tipos de aplicac~oes. De uma forma geral estas podem-se dividir em dois tipos: aplicac~oes elasticas e aplicac~oes de tempo-real. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

4 Classificação das Aplicações
Aplicações Elásticas ftp, , http, .... Aplicações que não são extremamente sensíveis a factores como: Atrasos, variação dos atrasos, variações de largura de banda, perdas, etc... apesar desses mesmos factores afectarem o seu desempenho Preocupação sob o ponto de vista de integridade do dados Protocolos de transporte tradicionais tais como: TCP, UDP, ... As aplicac~oes elasticas caracterizam-se pelo facto de os dados que elas manipulam n~ao serem extremamente sensveis a factores como o tempo de atraso na transmiss~ao,perdas verificadas, variac~ao de atrasos, largura de banda etc... N~ao quer isto dizer que o desempenho dessas mesmas aplicac~oes n~ao seja sensível a estes factores, bem pelo contrario, estes poder~ao condicionar o seu funcionamento e influenciar o grau de satisfac~ao do utilizador. No entanto a quest~ao central e que, nessas aplicac~oes,os dados por elas manipulados, apesar de poderem ser afectados por diversos con- dicionantes, podem ser imediatamente utilizados mal cheguem ao seu destino, sem existir o risco que isso influencie a sem^antica em que essas aplicac~oes operam. As tradicionais aplicac~oes FTP, e outras podem ser englobadas nesta famlia de aplicac~oes e utilizam protocolos de transporte fiaveis para a emiss~ao dos seus dados. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

5 Classif. das Aplicações (cont.)
Aplicações de Tempo Real (audio e vídeo em tempo real, vídeo-conferência...) Requisitos: garantia de isocronismo dos dados gerados, sensibilidade a atrasos, sensibilidade a perda de pacotes, necessidades de sincronização, largura de banda etc... Duas classes de aplicações de T.R: No respeitante as aplicac~oes de tempo-real existem ja diferencas significativas em relac~ao as aplicac~oes anteriormente descritas. Neste caso a propria natureza das aplicac~oes condiciona a validade dos dados que elas manipulam, estando estes muito dependentes de determinados requisitos temporais como sejam os atrasos introduzidos pela rede, a variac~ao desses mesmos atrasos, a perda de pacotes verificadas, etc. Um bom exemplo deste tipo de aplicac~oes s~ao as denominadas aplicac~oes de playback. Nestas aplicac~oes um dado emissor tem um determinado sinal a transmitir. Para tal recolhe uma serie de amostras desse sinal, e coloca-as num pacote que posteriormente é enviado para a rede. A rede introduz ent~ao uma serie de atrasos e condicionantes. Finalmente, quando o pacote chega ao destino, o receptor tentara reproduzir o sinal original, tendo para isso que utilizar alguns mecanismos de armazenamento e ajustar alguns par^ametros de funcionamento para tentar reproduzir o sinal tal como ele foi gerado na fonte. As aplicac~oes de tempo-real podem por sua vez ser sub-classicadas em diferentes tipos de acordo com os graus de exig^encia, em termos de qualidade de servico, impostos pelas mesmas. Assim sendo, temos duas categorias de aplicac~oes de tempo-real: intolerantes e tolerantes Aplicações Rígidas/Intolerantes Aplicações Adaptativas/Tolerantes Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

6 Aplicações de T.R. Aplicações Rígidas
Requerem suprtes que garantam limites para os diversos parâmetros que as condicionam (largura de banda, perdas, atrasos de pacotes...) Aplicações Tolerantes/Adaptativas Assumem um determinado grau de inadequação do meio não se baseiam em limites fixos para os parâmetros de funcionamento admitem um grau de tolerância às condições de operação observação vs adaptação As primeiras requerem que lhes seja fornecido um servico capaz de garantir limites associados a alguns par^ametros, como seja, por exemplo,o tempo de atraso dos pacotes. Desta forma, a aplicac~ao pode definir um determinado ponto de emiss~ao a partir do qual procede a reproduc~ao do sinal transmitido tendo garantias que, mesmo face ao maximo atraso introduzido pela rede, os dados continuar~ao a ser validos para aplicac~ao. Assim sendo, estas aplicac~oes requerem infra-estruturas com mecanismos capazes de lhes fornecerem tais condic~oes, ou de uma forma geral, tal qualidade de serviço. As denominadas aplicac~oes tolerantes baseiam o seu comportamento nas condic~oes que lhes s~ao oferecidas pelas infra-estruturas onde operam. Para tal, e baseando-se em algumas estatísticas extradas de um passado recente do funcionamento da aplicac~ao, ajustam os seus par^ametros de funcionamento de modo a optimizar o seu desempenho sobre determinadas condic~oes de operac~ao. Poderemos apontar algumas vantagens neste tipo de filosofia, como seja o facto de n~ao requererem algum tipo de mecanismos de reserva de recursos que lhes garanta uma dada qualidade de servico, o que por si so contribui para um mais elevado grau de utilizac~ao da rede. Noentanto, e como o processo de adaptac~ao nunca sera perfeito, estas aplicac~oes ter~ao que enfrentar ocasionalmente situac~oes anomalas que podem condicionar o correcto funcionamento das mesmas. Temos pois em dois extremos opostos estes dois tipos de aplicac~oes. Por um lado as que obrigam a exist^encia, na infra-estrutura utilizada, de mecanismos que garantam uma determinada qualidade de servico, por outro as que sem a exist^encia dos mesmos tentar-se-~ao adaptar e condicionar as condic~oes de operac~ao facultadas por essa mesma infra-estrutura. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

7 Aplicações de T.R. (cont.)
Suportes Protocolares Adequação aos objectivos das aplicações Protocolos usualmente utilizados TCP - fiabilidade à custa de mecanismos nem sempre apropriados... UDP - carece de alguns mecanismos indispensáveis às aplicações de T.R. Natureza multi-utilizador de muitas das aplicações multimédia com requisitos de T.R paradigma de comunicação multi-ponto (multicasting) Desenvolvimento de aplicações com requisitos de T.R. Soluções propriétarias. (aplicação + transporte - ex. aplicações Vchat, Vosaic, CuSeeme, etc...) Aplicações Adaptativas vs Intolerantes desempenho “custo” T.R estrito T.R tolerantes A motivac~ao principal em que assenta a segunda filosofia e o facto de que nem sempre as infra-estruturas existentes possuem mecanismos que assegurem tais garantias de qualidade de servico. Mesmo que as assegurem, essa abordagem podera ter consequ^encias ao nível da utilizac~ao das mesmas, visto que quase sempre isto implicaria uma alocac~ao de recursos que estariam dedicados a um unico fuxo de dados de uma dada aplicac~ao. Acredita-se pois que as possíveis anomalias verificadas nas aplicac~oes tolerantes poder~ao ser compensadas pelo que se ganha em termos de flexibilidade de utilizac~ao da infra-estrutura de comunicac~ao, pelo menos no sentido de n~ao haver necessidade de alocar recursos exclusivamente dedicados a um conjunto de aplicac~oes. Em termos conceptuais poderemos tracar um paralelo entre as aplicac~oes tolerantes e os denominados sistemas de tempo-real operando sob o paradigma do maior-esforco, mencionados em alguma literatura ligada a area dos sistemas distribuídos. Por definic~ao, um sistema de tempo-real deste tipo, e aquele em que a sua concepc~ao se baseia no princípio da inadequac~ao dos recursos disponveis, ou seja, e considerado que n~ao existe um suporte operacional capaz de garantir todas ascondic~oes necessarias ao referido servico, quer por este n~ao se adequar aos requisitos impostos, quer por n~ao ser economicamente viavel a sua alterac~ao para a satisfac~ao desses mesmos requisitos. Estes servicos ter~ao pois que adoptar estrategias que permitam um maior aproveitamento dos recursos disponveis, por forma a maximizaremo seu desempenho. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

8 Suporte de Aplicações Multimédia e de Tempo Real
Tempo Real sobre redes best-effort RTP (Real Time Protocol) Reserva de Recursos RSVP (Resource Reservation Protocol) Serviços Diferenciados A primeira secc~ao (1.4) aborda um dos protocolos usados para o transporte de dados gerados por aplicac~oes de tempo-real. O RTP[] tem sido utilizado sobre cenarios sem guarantias de reserva de recursos, constituindo pois um bom exemplo do tipo de mecanismos que as aplicac~oes ter~ao de implementar por forma a se adaptarem a situac~oes anomalas (perda de acotes, atrasos etc.) que podem occorer num ambiente deste tipo. Esta secc~ao sera a mais explorada pois apresenta a concepc~ao, em software, de mecanismos indispensaveis a muitas das aplicac~oes que actualmente proliferam nas redes computacionais. A segunda secc~ao (1.5) apresenta um dos protocolos propostos na comunidade IP para efectuar reserva de recursos. Atraves deste mecanismo torna-se possivel uma qualquer aplicac~ao alocar uma determinada largura de banda e outros par^ametros, e ter a garantia que os elementos da infra-estrutura de comunicac~ao (nomeadamente os routers) est~ao preparados para processar os seus fluxos de informac~ao.Por fim na ultima secc~ao (1.6) sera introduzido uma outra soluc~ao que esta neste momento a ser estudada, e que consiste no tratamento diferenciado do trafego pelos elementos de comutac~ao. Esta proposta esta a ser alvo de estudo pelo IETF, atraves do grupo de trabalho intitulado Diferenciated Services. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

9 Protocolos Streaming Adequados para aplicações geradoras de tráfego T.R. sobre cenários best-effort (IP) Operação sobre cenários sem garantia de alocação de recursos Conceitos: Tolerância a perdas de pacotes Controlo de atrasos (jitter vs buffers de amortecimento) Adaptação dinâmica dos serviços (mediante mecanismos de sinalização do estado de operação dos canais de dados) De seguida apresentam-se alguns requisitos que est~ao na base das funcionalidades de protocolos de transporte a aplicac~ao de tempo-real sobre infra-estruturas de rede sem capacidades de reserva de recursos. Toler^ancia a perdas de pacotes Como ja se referiu, o tipo de servico de rede oferecido pela infra-estrutura Internet pode ser classificado como um servico n~ao fiavel, n~ao havendo pois garantia de entrega de pacotes nem a sua sequencializac~ao. Nestes cenarios s~ao utilizados protocolos de transporte (como TCP) que possibilitam as aplicac~oes uma forma fiável de transmitirem os seus dados. Se para alguns casos isto sera uma boa escolha (como transfer^encia de cheiros, , etc...) , tambem e verdade que esta filosofia n~ao se adapta ao caso de aplicac~oes que lidem com media com requisitos semelhantes aos que foram abordados neste capiulo. Por exemplo, a transmiss~ao de uma pagina WWW podera ser suportada pelo protocolo TCP, visto que o resultado nal que se pretende e a integridade dos dados que comp~oem essa mesma pagina. No entanto, e tal como foi anteriormente referido, a transmiss~ao de um dado pacote audio ja tera outros requisitos que n~ao permitem o seu transporte sobre esse mesmo protocolo. Apresentado o caso por outras palavras, pode-se dizer que uma aplicac~ao de tempo-real tirara maior proveito de um protocolo que, embora mais debil em termos de qualidade de servico oferecida, n~ao utilize mecanismos que possam p^or em causa o sucesso de uma dada emiss~ao. Acredita-se por vezes que, em alguns cenarios, pequenas perdas de pacotes n~ao degradem consideravelmente o desempenho das aplicac~oes.O que ja n~ao aconteceria em relac~ao a cenarios onde se procedesse a recuperac~ao dessas mesmas perdas, mediante tecnicas passveis de alterar as características do trafego gerado por este tipo de aplicac~oes. Assim os potenciais suportes protocolares a este tipo de aplicac~oes ter~ao de ter em conta que as aplicac~oes poder~ao tolerar um certo numero de perdas durante as suas transmiss~oes, e por outro lado, a informac~ao transmitida devera ser sempre util mesmo na presenca de alguma percentagem de perdas de pacotes. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

10 Protocolo Streamming (cont)
Controlo dos atrasos Alem da quest~ao das possveis perdas de pacotes durante a transmiss~ao de determinada informac~ao na Internet existe uma outra caracterstica que deve ser levada em conta: a variac~ao dos atrasos a que est~ao sujeitas as tramas, ou seja, o denominado jitter. O tipo de condicionantes que este factor imp~oe depende do tipo de aplicac~ao em quest~ao e da ordem de grandeza dessas mesmas variac~oes nos atrasos. As aplicac~oes de tempo-real ser~ao exactamente aquelas que poder~ao ser mais penalizadas pelo denominado jitter, sendo imprescindvel que adoptem estrategias que possam diminuir a influ^encia deste factor no seu desempenho. Os problemas que o jitter introduz podem ser parcialmente resolvidos pelo uso de um buffer de amortecimento , que corresponde a dizer que os dados n~ao s~ao imediatamente processados aquando a sua recepc~ao, mas que estes sofrem um ligeiro atraso inicial no intuito de se amortecerem os efeitos da variac~ao dos atrasos no decorrer de seu percurso desde o emissor ate ao receptor. Surge ent~ao a noc~ao de play-out delay que correspondera a maxima variac~ao que pode ser suportada por um buffer de amortecimento. O seu dimensionamento e de extrema import^ancia para, por um lado, melhorar a qualidade do servico obtido, e por outro n~ao ser demasiado extenso de modo a que o atraso m-a-m introduzido no processo da comunicac~ao n~ao seja inadequado para o tipo de aplicac~ao em quest~ao. Por exemplo, para o caso de uma comunicac~ao humana, e apontado que atrasos ate ms ainda s~ao aceitaveis, enquanto valores superiores afectam consideravelmente o servico . Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

11 Protocolo Streamming (cont.)
Adaptação dinâmica ao serviço Uma das raz~oes para a ocorr^encia de perdas de pacotes s~ao erros de hardware ou perturbac~oes electricas nas linhas de transmiss~ao que provocam a eliminac~ao de alguns pacotes da rede. No entanto, a causa mais corrente das perdas de pacotes naInternet resulta da sobrecarga de trafego que ocorre em algumas ligac~oes. Situac~oes como esta produzir~ao os denominados pontos de congest~ao12 que condicionar~ao o desempenho das aplicac~oes. Estes pontos de congest~ao poder~ao existir tanto em linhas intermedias como ate mesmo nas proprias interfaces utilizadas pelos utilizadores (por exemplo, a tentativa de um dado utilizador transmitir informac~ao a uma taxa de 64Kbits/s estando este a utilizar um modem de 28.8Kbits/s). Uma das formas das aplicac~oes se protegerem contra este tipo de problemas e dotar a aplicac~ao geradora de trafego de mecanismos que possibilitem uma adaptac~ao do seu debito as condic~oes oferecidas pelos servicos de nvel inferior. Na pratica isto podera corresponder a escolha de mecanismos de codificac~ao de dados menos exigentes em termos de largura de banda ou a diminuic~ao da taxa de emiss~ao desses mesmos dados (por exemplo, numa sess~ao de vdeo, diminuir o numero de imagens emitidaspor segundo) sempre que se verificaram perdas de pacotes crescentes e signicativas na rede. Atraves da utilizac~ao deste mecanismo acredita-se que seja possvel uma adap- tac~ao das aplicac~oes as situac~oes de maior congest~ao na rede. Acredita-se tambem que, apesar da aplicac~ao ter diminudo de alguma forma a qualidade com que codicava e transmitia os seus dados, este facto pode vir a ser compensado pela diminuic~ao significativa de perdas que a partir da ocorram, podendo mesmo vir a obter-se melhores resultados. Alem disso, desta forma, a aplicac~ao contribui de uma forma activa para a eliminac~ao da situac~ao de congest~ao verfiicada. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

12 Protocolo RTP Protocolo RTP (Real Time Protocol)
(RFC 1889) Implementado como base às aplicações de T.R (adaptativas) Fornece mecanismos de transporte fim-a-fim a dados gerados por aplic. T.R Apto a ser aplicado em cenários unicast ou multicast Canal de dados + canal de controlo (RTCP - Real Time Control Protocol) RTCP - mecanismos de notificação do estado de operação do canal de dados (perdas, atrasos, sincronização etc ...) De uma forma muito geral poder-se-a salientar os seguintes pontos da especicac~ao do protocolo RTP: Fornece mecanismos de transporte m-a-m adequados para aplicac~oes que operem na transmiss~ao de dados em tempo-real. Independ^encia do protocolo de transporte usado (caso este seja implementado sobre outro protocolo de transporte tradicional) e das camadas de rede que o suportam. Na realidade deve ser usado um protocolo de transporte que implique um mínimo de controlo adicional e um mnimo de ocupac~ao de largura de banda, como e o caso do UDP. No que diz respeito a camada de rede, poder-se-a dizer que esta vocacionado para cenarios de operac~ao sem a necessidade de reserva de recursos por parte dos elementos da rede. No entanto, e caso esse servico seja fornecido (por exemplo pelo RSVP), o RTP continuara a desempenhar o papel de protocolo de transporte embora sem a vertente de adaptac~ao com que ele e abordado neste trabalho. Suporte a mecanismos de comunicac~ao em ambientes multicast ou unicast. Engloba um protocolo de controlo adicional (RTCP) que permite controlar o estado das conex~oes. Neste canal transitar~ao todo um conjunto de informac~oes de estado de cada uma das entidades participantes. Na especficac~ao da utilizac~ao do protocolo RTP ficou definido que na transmiss~ao simult^anea de varios media, cada um deles deveria ser transmitido num canal RTP independente. Entre outras vantagens, uma delas podera ser a flexibilidade introduzida no servico, permitindo, por exemplo, que um dos participantes opte unicamente pela recepc~ao de um unico medium. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

13 Protocolo RTP (cont.) Camada Protocolar com o RTP (best-effort)
Fornecer um mecanismo de transmissão a dados T.R. Fornecer mecanismos para controlo dos dados por parte da aplicação Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

14 Protocolo RTP (cont.) Sessão RTP = canal dados + canal de controlo Emissão de vários media- cada um é transmitido em sessões independentes Endereço de sessão = endereço de rede (unicast ou multicast) + porta protocolar Canal RTCP = porta protocolar do canal RTP+1 Assim, e se tomarmos como exemplo a comunicac~ao baseada em som e imagem entre dois indivduos, existir~ao quatro canais RTP independentes, dois para cada participante, correspondendo cada um deles ao transporte de som e imagem, como se pode observar na figura 1.1 Como ja tinha sido referido, o RTP esta vocacionado para a comunicac~ao em ambientes de multi-participante, suportados por mecanismos de multicast. Assim. sendo um grupo de utilizadores poder-se-a juntar a uma dada sess~ao RTP e nela participar activamente desempenhando o papel de mero receptor quer tambem de transmissor de informac~ao. O RTP foi desenhado com o intuito de operar sobre mecanismos de multicast de uma forma a minimizar o trafego da sess~ao, muito em especial no que se refere a informac~ao de controlo, como adiante se explicara quando se abordar algumas quest~oes relacionadas com o canal RTCP. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

15 Protocolo RTP (cont.) Cenários multicast:
Canal RTP - dados das aplicações Canal RTCP - dados de controlo informação de alto nível estatísticas sobre o desempenho dos receptores: perdas de pacotes , atrasos, jitter, inf. sincronização, etc... Na figura 1.2 esta esquematizada uma sess~ao RTP onde participam quatro entidades, em que tr^es s~ao simultaneamente emissoras/receptoras de trafego RTP, enquanto uma quarta desempenha unicamente o papel de emissora. Desta forma todos os receptores de trafego RTP ter~ao obrigatoriamente que relatar a qualidade com que quest~ao a receber as tramas, das varias entidades emissoras, para todos os participantes na sess~ao. Atraves deste mecanismo as entidades geradoras tomam n~ao so consci^encia de como o seu trafego esta a chegar aos diversos destinos, mas tambem como o trafego gerado por outras entidades esta a chegar a esses mesmos destinos. Deste modo, todo o grupo tem consci^encia do estado de todos os participantes envolvidos na sess~ao. Num ambiente multi-participante uma ligac~ao logica RTP e identicada por um endereco de rede (correspondente a um dado grupo multicast), e por um par de portas protocolares, que que multiplexam os canais RTP e RTCP. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

16 RTP sobre Multicasting
Protocolos de encaminhamento (diferentes filosofias) Protocolos de gestão de grupos multicast (IGMP) Túneis IP (interoperacionalidade entre encaminhadores) Propagação de sessões multicast (parâmetro TTL) Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

17 Formato Pacote RTP Um pacote RTP esta dividido em cabecalho e na parte dos dados. No cabecalho figura informac~ao sobre o tipo de dados transportados (mais propriamente o tipo do medium e sua codicac~ao) bem como informac~ao util para funcionalidades inerentes aos proprios mecanismos do RTP.. Version (V): a vers~ao do protocolo RTP que esta a ser usado (2 para a ultima vers~ao). Padding (P): Bit que quando activado indica que o pacote contem informac~oes adicionais que n~ao fazem parte da codicac~ao do medium transmitido. Extension (X): Bit que quando activado indica que existe um cabecalho adicional para ser interpretado mediante o tipo de conteudo transportado (identicado pelo payload type). CSRC count (CC): Indica o numero de fontes de contribuic~ao que operaram sobre este canal RTP. Estes indicadores s~ao usados aquando da participac~ao dos denominados mixers16 sistemas intermediarios que combinam e tratam as streams RTP originadas por outros sistemas. Marker (M): Interpretado consoante o medium transportado e a sua codicac~ao. Por exemplo, no caso de transporte de vdeo, podera signicar qualquer coisa como o um de uma imagem que faz parte da sequ^encia transmitida. Payload Type (PT): Identicador unico que tera correspond^encia para um dado payload for- mat, que definira como a aplicac~ao devera tratar a informac~ao recebida. Sequence Number: Identicador do numero de pacote RTP. Estes numero sofrera incrementosde uma unidade por parte do emissor sempre que for emitido um novo pacote RTP. Timestamp: Estampilha temporal que reecte o instante em que o primeiro octeto de infor- mac~ao transportado no pacote RTP foi processado pela entidade geradora. Esta estampilha devera ser calculada de uma forma monotona e linear de modo a que seja possvel ao receptor efectuar a sincronizac~ao do medium em quest~ao e o calculo do jitter que esta a ocorrer. SSRC: Identicador da fonte de sincronizac~ao. Identica univocamente a fonte geradora de tramas RTP. Este identicador devera ser unico sendo pois necessario a utilizac~ao de um algoritmo aleatorio de gerac~ao de SSRC. O identicador de sincronizac~ao devera possibilitar ao receptor de uma sess~ao RTP agrupar as tramas de um dado emissor para posterior pro- cessamento, sabendo que nesse domnio as estampilhas temporais e os numeros de sequ^encia est~ao relacionados entre si. CSRC: Identicador da fonte contribuinte. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

18 Multiplexagem das sessões RTP
Cada média transportado numa sessão independente Estratégia de multiplexagem: endereço de transporte (IP+Porta) Transitam pacotes dum único tipo (payload type) Gerados por uma ou mais entidades(SSRC) Se as entidades trocarem entre si outro tipo de dados abre-se numa nova sessão RTP, independente da primeira Ja foi anteriormente referido que cada medium deveria ser transportado numa sess~ao independente. Vai-se aqui tentar esclarecer quais as motivac~oes de uma filosofia deste genero. O protocolo RTP utiliza como estrategia de multiplexagem o endereco de transporte, ou seja, um endereco de rede mais uma porta de destino denem uma unica sess~ao RTP. Nessa sess~ao ir~ao transitar pacotes RTP de um unico tipo (denido plo payload type), e gerados por uma ou mais entidades (identicadas pelo SSRC). Caso as entidades troquem entre si outro tipos de dados uma nova sess~ao RTP, independente da primeira, devera ser utilizada. Vejamos algumas justicac~oes para adopc~ao desta estrategia, e n~ao optar, por exemplo, por multiplexar atraves do uso de diferentes payload types para um mesmo SSRC: Se um dado metodo de codicac~ao17 fosse alterado numa dada sess~ao RTP ficariamos sem saber qual deles e que realmente se alterou. A um identicador SSRC estara associado um dado domnio tanto ao nvel de numeros de sequ^encia como ao nvel de estampilhas temporais. Multiplexando,numa mesma sess~ao RTP, varios media para um mesmo SSRC originaria a necessidade de termos domnios de estampilhas bem como diferentes numeros de sequenciac~ao que permitissem calcular o numero de pacotes perdidos para cada um media transportados na mesma sess~ao RTP. Os pacotes RTCP transportam informac~ao de controlo referente a cada uma das fontes de informac~ao (designadas pelo SSRC) e n~ao fazem qualquer refer^encia aos respectivos conteudos transportados nos pacotes RTP. Multiplexando varios media numa mesma sess~ao RTP compromete o uso de diferentes estrategias de encaminhamento para cada um dos media, consoante as suas necessidades. Outra estrategia que esta soluc~ao inviabilizaria, seria a recepc~ao de um dado subconjunto dos media transmitidos. Este tipo de soluc~ao pode ser usada caso a entidade receptora n~ao seja capaz de suportar a totalidade dos media transmitidos por uma aplicac~ao operando sobre o RTP. Claro esta que a multiplexagem numa mesma sess~ao de varios payloads usando para cada um deles diferentes SSRC poderia evitar as desvantagens apresentadas nostr^es primeiros pontos, mas n~ao solucionaria a adopc~ao de estrategias do tipo das que foram especifcadas no ultimo. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

19 Real Time Control Protocol
Protocolo de controlo associado ao RTP Usado para trocar mensagens de controlo entre os participantes Identificação de fontes: nome e dos participantes Mensagens do estado da sessão Geradas por todos os participantes Relatar valores de diversos parâmetros: perdas, atrasos, estados de sincronização 2 tipos: sender report (SR) e receiver report (RR) Uma das características dos RTP e a definic~ao de um protocolo de controlo a ele associado. Algumas das principais caractersticas do RTCP s~ao de seguida apresentadas. No canal RTCP ser~ao trocadas mensagens de controlo entre os diversos participantes na sess~ao RTP associada. Essas mensagens poder~ao ser de identicac~ao das fontes (como o nome dos utilizadores participantes, enderecos , etc...) ou ent~ao mensagens do estado da sess~ao. Estas ultimas s~ao geradas por todos os participantes da sess~ao e tem como objectivo principal o de relatar os valores dos diversospar^ametros de funcionamento (perdas de pacotes, variac~ao nos atrasos, estado de sincronizac~ao, etc) verificados por cada uma das entidades. Existem dois tipos de relatorios que s~ao gerados pelas entidades: os SR20 e os RR21. Em ambos os casos esses relatorios incluem informac~ao de estado referente a todos os emissores RTP cujastramas est~ao a ser processadas pela entidade que gera esses mesmos relatorios. Este e o mecanismo que permite ao emissor ter conhecimento do desenrolar da aplicac~ao na perspectiva dos receptores de informac~ao e que permite aos mesmos obterem informac~oes uteis para efectuarem alguns ajustes ao seu funcionamento. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

20 Mecanismos de Controlo
Variação nos atrasos dos pacotes - Jitter Influência no desempenho das aplicações (isocronismo). Cálculo nas estações receptoras: jitterx = jitter(x-1) + fact*(dst - jitter(x-1)), dst = Diffdest(x,x-1) + Difforg(x,x-1) Necessidade de buffers de amortecimento. Atraso dos Pacotes Um dos factores de vital import^ancia que condicionam o comportamento das aplicac~oes de tempo-real s~ao os atrasos introduzidos na transmiss~ao de um dado pacote de dados. Este factor, n~ao sendo constante, provoca que a frequ^encia de emiss~ao de pacotes, por parte da entidade emissora, nem sempre corresponda a frequ^encia com que os mesmos alcancam as entidades receptoras. Este factor e normalmente denominador por jitter, e o seu estudo podera ser util para a adopc~ao de diferentes estrategias de funcionamento por parte das aplicac~oes. Cada entidade receptora devera ser capaz de manter, para cada entidade geradora, uma estimativa deste par^ametro. Consideremos a seguinte formula, que atribui a cada pacote, um determinado valor de tr^ansito, (1) Transx = Tchegx- Pacx:t; Se(Transx < 0) ) Transx = - Transx Dst= Transx –Transx-1 Dst= deltaTdst(x,x-1) – delta Torig(x,x-1) Jitter duma sequencia de pacotes como Jittx= Jitt(x-1) – fact*(Dst-Jitt(x-1)) que constitui uma func~ao-filtro (passa a baixo) de analise da variac~ao do intervalo de chegada dos pacotes face aos intervalos com que eles foram gerados. A constante fact ditara a sensibilidade da estatística calculada face aos ultimos valores vericados. Na figura 1.5 e apresentado um caso simulado de uma fonte que gera pacotes com intervalos de 20ms. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

21 Mecanismos de Controlo
Buffers de Amortecimento Amortecer o efeito da variação dos atrasos (assegurar isocronismo) Reordenação de pacotes Análise de n amostras e cálculo de um valor de amortecimento a ser adoptado. D = u(1) - u(n) com u(k) - késsimo maior valor dos atrasos das amostras. Antes de começar a reproduzir espera-se um determinado tempo. Para fazer face a este tipo de problemas introduzidos pelo jitter, as aplicac~oes poder~ao optar por estrategias que diminuam a inu^encia deste factor no desempenho das mesmas. Uma das soluc~oes muitas vezes adoptada e a utilizac~ao de um buffer que amorteca os efeitos dos atrasos dos pacotes. A ideia sera atrasar o processamento do primeiro pacote de um dado tempo D (destination wait time). Esta tecnica resulta numa diminuic~ao das possveis interfer^encias causadas pelas variac~oes dos atrasos introduzidos pelas infra-estruturas de comunicac~ao. Um valor ideal para o par^ametro D sera a diferenca entre os atrasos do pacote com um maior atraso e do primeiro pacote processado. Obviamente, em infra-estruturas que n~ao garantam um valor maximo para esse atraso, o para ^ metro D tera que ser estimado mediante os valores que v~ao sendo observados pela aplicac~ao. A escolha deste tempo tera que ser equacionada mediante o tipo de aplicac~ao e tipo de dados que s~ao manipulados. E preciso ter em conta que uma estrategia deste tipo implicara um atraso no proprio processamento das tramas, tendo pois o par^ametro D que estar limitado a um perodo que n~ao inuencie a qualidade do servico. Por exemplo, e como se referiu anteriormente, no caso de uma comunicac~ao de voz existem estudos que apontam que valores na casa dos 500ms n~ao afectam consideravelmente a qualidade do servico . Neste mesmo cenario e possvel a aplicac~ao proceder a um reajuste do dimensionamento do par^ametro D durante o seu funcionamento. Por exemplo, e no mesmo cenario de comunicac~ao de voz, a aplicac~ao poderia escolher os perodos de sil^encio para proceder a tais reajustes. A introduc~ao de um buffer de amortecimento alem de diminuir a probabilidade de quebras na transmiss~ao permite, em situac~oes de excepc~ao, a reordenac~ao de pacotes pelas entidades receptoras. De uma forma muito simples a a figura 1.6 descreve como, perante a utilizac~ao de uma tecnica deste tipo, uma aplicac~ao podera estar interessada no processamento de pacotes atrasados. Nesse caso, o facto de se ter adoptado uma estrategia de utilizac~ao de um buer de amortecimento das variac~oes dos atrasos, tornou possvel que a aplicac~ao reordenasse os pacotes (2) e (3), porque apesar do n n-1 n-2 n-3 D RECEPTOR n n-1 n-2 n-3 EMISSOR t1 t2 t3 tf tf tf Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

22 Mecanismos de Controlo
ultimo ter sofrido uma variac~ao excessiva em relac~ao ao primeiro, esse facto tornou-se irrelevante pela adopc~ao de um atraso no processamento do primeiro pacote.Tendo pois consci^encia da import^ancia da adopc~ao de mecanismos de buffering nas entidades receptoras, e tendo em conta que o seu dimensionamento estara relacionado com as possíveis diferencas de atraso entre os pacotes, sera util para as aplicac~oes terem uma estimativa do tempo que dever~ao adoptar para amortecerem as possíveis quebras nos media que est~ao a tratar. Idealmente um valor que cobrisse a diferenca de atrasos entre o primeiro pacote e o pacote com maior atraso seria suciente para n~ao existir nenhuma quebra na emiss~ao. Na pratica isto torna-se impossvel por duas raz~oes: impossibilidade de uma previs~ao desse tipo, e a limitac~ao a que esse amortecimento esta sujeito de modo a n~ao desvirtuar as caractersticas do processo de comunicac~ao. Assim sendo, uma das tecnicas que pode ser usada consiste na observac~ao de um determinado numero de amostras anteriores, a partir das quais se estima um tempo de amortecimento padr~ao, sendo este processo repetido com determinada frequ^encia. Consideremos ainda a func~ao D(m; k) como representativa das diferencas entre os atrasos das diversas tramas enviadas, em que D(m; k) = u(Ik+1) Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

23 Mecanismos de Controlo
Estratégias de Reprodução (1) (2) Preservação Temporal Tentar reproduzir a informação que obedeça ao limite temporal imposto Preservação de Informação Tentar reproduzir toda a informação recebida independentemente. De estar atrasada ou não (3) (4) D D (5) (1) (1) (6) (2) (2) (7) (3) (3) (8) (9) (4) (5) (6) (6) (7) (8) (8) (9) Estrategias de playback Depois de discutida a import^ancia da utilizac~ao de mecanismos de buffering pelas entidades receptoras bem como do tipo de informac~ao disponibilizada pela entidade protocolar para o dimensionamento dos mesmos, pretende-se agora abordar as diferentes estrategias que a aplicac~ao podera optar para processar os dados que recebe. Basicamente a aplicac~ao podera adoptar duas estrategias: preservac~ao da informac~ao ou preservac~ao temporal. Na primeira a aplicac~ao opta pelo tratamento de toda a informac~ao recebida, independentemente se esta atrasada ou n~ao, ou seja, um pacote atrasado (mesmo apos a aplicac~ao de buering) ira provocar uma quebra na transmiss~ao e consequente atraso no processamento nas tramas subsequentes, isto porque a aplicac~ao continuou interessada no processamento desse pacote atrasado. Este metodo tera a desvantagem de apresentar um desiquilbrio em termos de tempos de entrada e de saída da informac~ao no processo, ou seja, uma dada sequ^encia de tramas transmitidas pelo emissor com uma durac~ao de x ms ira ter correspond^encia do lado do receptor a uma durac~ao de (x+ )ms, estando dependente do número de quebras na transmiss~ao. Novamente este factor tera de ser bem equacionado mediante o tipo de aplicac~ao em quest~ao. A vantagem obvia deste metodo e a tentativa de preservac~ao de toda a informac~ao transmitida, que podera ser util para alguns cenarios de operac~ao. Alternativamente, a aplicac~ao podera optar por um metodo de preservac~ao temporal. Esta assenta na ideia de que, a partir do momento em que se inicia o processamento da primeira trama (possivelmente apos a buering), as restantes tramas devem ser processadas no instante devido. Caso isto n~ao aconteca estas ser~ao eliminadas. Como resultado este metodo n~ao levara em conta as tramas atrasadas29 recebidas pelo emissor, mas por outro lado n~ao extendera o tempo total do processamento da informac~ao como acontecia no metodo anterior . (9) Recepção dos pacotes Preservação Temporal Preservação da Informação Probabilidades diferentes de cortes nos media Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

24 Estratégias de Reprodução (cont.)
Preservação de Informação Quebra no pacote i se: u(i) > (u(0) + D) e u(i) > u(1), u(2)..u(i-1) Cálculo da probabilidade de quebra baseado em funções de distribuição de probabilidades dos atrasos e função de distribuição de tempos de amortecimento. Preservação Temporal Quebra no pacote i se: u(i) > u(0) + D idem - maior número de quebras.... mas com outras vantagens No primeiro (preservac~ao de informac~ao) uma quebra sera observada num pacote i se: u(i) > (u(0) + D) e u(i) > u(1), u(2)..u(i-1) nos da o atraso do pacote x. Ou seja, um pacote originara uma quebra se o seu atraso exceder o atraso do primeiro pacote por um tempo superior ao que foi utilizado para amortecimento inicial. Alem disso esse atraso tera que ser superior a todos os atrasos anteriores, caso contrario, a quebra ter-se-a dado anteriormente. No respeitante ao segundo metodo (preservac~ao temporal) e condic~ao suficiente para a ocorr^encia de uma quebra a primeira premissa apresentada na situac~ao anterior, u(i) > u(0) + D. A definic~ao das condic~oes de aplicac~ao de cada um destes metodos a situac~oes concretas n~ao e muito clara. Se e verdade que para as mesmas condic~oes de atrasos de pacotes, o metodo de preservac~ao de informac~ao originara um menor numero de quebras, tambem e verdade que apresentara alguns problemas pelo facto de extender o seu tempo de processamento face ao tempo de entrada da informac~ao. Como em muitas outras coisas, parece que a adopc~ao de uma soluc~ao hbrida podera levar a bons resultados visto constituir uma ponderac~ao entre a integridade da informac~ao e a integridade temporal. Isto poderia ser alcancado pela modificac~ao do metodo de preservac~ao de informac~ao de modo a se introduzir um limite a partir do qual a aplicac~ao ja n~ao estaria interessada em pacotes atrasados. Desta forma continuaria a haver algum interesse em preservar toda a informac~ao mas tendo sempre a preocupac~ao de n~ao deixar atrasar o processo por um perodo exagerado Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

25 Mecanismos de Controlo
Perda de Pacotes Afectam desempenho das aplicações. Situações de saturação da infra-estrutura. Cada receptor mantém estatísticas das perdas verificadas informa periodicamente as entidades emissoras. filtroperdas=fact * (filtroperdas)+ (1-fact)*percperdas com (0<fact<1) Percperdas presentes nos pacotes RTCP Definição de limites para o filtro de análise de perda de pacotes. Outro dos problemas que as aplicac~oes de tempo-real enfrentam frequentemente e a perda de pacotes que ocorrem durante uma dada sess~ao. Essas perdas dever~ao ser observadas de modo a que cada uma das entidades geradoras de informac~ao tenha consci^encia da forma como os outros intervenientes, numa dada sess~ao multicast, est~ao a receber os dados por ela gerados. Atraves de noticac~oes periodicas das perdas de pacotes observadas, os emissores poder~ao tentar adaptar o seu comportamento as condic~oes actuais da rede. Varias estrategias poder~ao ser seguidas, podendo, por exemplo, os emissores diminuir a frequ^encia de emiss~ao de pacotes para a rede ou optar por metodos de codicac~ao menos penalizantes para situac~oes de insuci^encia de largura de banda. A ideia base ao se adoptarem estes comportamentos, sera a de que, embora se possa perder qualidade na informac~ao transmitida, esse facto possa vir a ser compensado com a diminuic~ao de perdas que se passa a verificar. Esta ideia esta expressa na figura, onde se pode observar o comportamento din^amico de uma fonte geradora face as perdas observadas na rede e que s~ao relatadas pela entidade receptora. Como se pode observar, o que se espera e que, atraves da definic~ao de duas fronteiras de percentagens de perdas de pacotes, a aplicac~ao aumente, diminua ou mantenha o seu debito consoante essas fronteiras sejam violadas ou n~ao. Nestes cenarios e usual a utilizac~ao de um filtro que acompanhe as perdas verificadas de modo a serem atenuados alguns picos que correspondam a situac~oes de congest~ao passageiras. O calculo da percentagem de pacotes perdidos e realizado nas estac~oes receptoras, e e baseado na informac~ao dos pacotes RTP gerados pelas estac~oes emissoras. Estas emitem pacotes que cont^em um determinado numero de sequ^encia. As estac~oesreceptoras mant^em variaveis de estado, associadas a cada emissor, que controlam o numero de pacotes recebidos e os que seriam esperados. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

26 Perdas de Pacotes (cont.)
Indicador para a aplicação diminuir o seu débito (alteração de codificações, diminuição do frame-rate, etc...) Receptor define limites inferiores/superiores para as percentagens admissíveis de perda de pacotes (> limite_superior) dimin. débito ; (< limite_inferior) aum. débito. Consideremos pois as variaveis, seqmax ! sequ^encia maxima recebida seqbas ! sequ^encia base recebida receb ! numero de pacotes recebidos em que as variaveis receb e seqmax s~ao actualizadas sempre que e recebido um pacote da rede. Sempre que for gerado um pacote de relatorio, sera indicada a percentagem de pacotes perdidos. Esta e calculada com base nas variaveis anteriores, sendo concretizada nas seguintes formulas: perdidos = seqmax -- seqbas percentperdidos = perdidos/receb Esses mesmos relatorios ser~ao analisados pelas estac~oes emissoras que poder~ao manter uma estatística das perdas observadas pelos receptores. Por forma a se conseguir uma certa imunidade a alguns picos de perda de pacotes, que podem ser originados por situac~oes moment^aneas, as aplicac~oes poder~ao aplicar um filtro estatístico as perdas apresentadas pelas entidades externas. A formula seguinte denota exactamente este tipo de abordagem,. filtroperdidos = Lambda * (filtroperdidos) + (1- Lambda) * %perdidos (1) -em que podera ser ajustavel consoante se queira valorizar, ou n~ao, as perdas observadas mais recentemente. Com base na estatstica denida em (1), e mediante a adopc~ao de limites inferior e superior para as percentagens de perda de pacotes, a aplicac~ao tentar-se-a adaptar ao tipo de condic~oes da rede. Este tipo de estrategia tem como objectivo evitar oagravamento de uma zona de congest~ao. Neste contexto, existem alguns estudos que mencionam a import^ancia da analise do jitter como sendo um bom indicador de uma possvel formac~ao de uma zona de congest~ao [16]. Basicamente tenta-se relacionar um crescendo do jitter com o facto de se poder vir a vericar, a partir desse momento, a ocorr^encia de perdas de pacotes. Desta forma, torna-se possvel a uma aplicac~ao n~ao so adaptar-se a estas situac~oes mas tambem antever possveis problemas que possam surgir. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

27 Perdas de Pacotes (cont.)
Perda de Pacotes - Ambientes multicast (n participantes) Vários receptores diferentes situações de operação. Decisão a tomar pelos emissores? Atender ao pior caso? Ponderação dos estados dos intervenientes (classificação das entidades + algoritmo de decisão). Emissão simultânea de um mesmo medium codificado de diferentes maneiras: Cada codificação numa sessão multicast independente Cada receptor escolhe a mais apropriada Vantagens/inconvenientes... Anteriormente foi apresentado o modo como a informac~ao de controlo retornada pelo receptor podera ser utilizado pelo emissor de modo a adaptar-se as condic~oesde operac~ao da rede. Em cenarios multicast ser~ao varias entidades a relatar a uma mesma entidade emissora a qualidade com que a sess~ao esta a decorrer. E pois obvio, que as possveis decis~oes tomadas pela entidade emissora estar~ao dependentes dos diversos par^ametros de operac~ao associados as diversas entidades receptoras. Assim sendo, e tendo em conta que diferentes entidades receptoras poder~ao estar geogracamente dispersas, interligadas com diferentes infra-estruturas de rede, e com a possibilidade de trabalhar sobre diferentes nveis de QoS, e natural que esses mesmos par^ametros de operac~ao devolvidos pelas entidades receptoras poder~ao relatar situac~oes completamente diferentes. Pode por exemplo acontecer, n entidades estarem a receber perfeitamente os dados transmitidos enquanto as restantes enfrentam condic~oes mais adversas. Apresentam-se de seguida estrategias que poder~ao ser adoptadas pelas aplicac~oes que operem em cenarios deste tipo. Uma das hipoteses e a aplicac~ao basear a sua decis~ao nos relatorios da entida- de que apresente um maior numero de pacotes perdidos. Desta maneira, todos os possveis congestionamentos inerentes as entidades participantes ir~ao estar sobre a aplicac~ao de uma poltica que atende ao pior desses casos. Esta e pois uma tecnica que se baseia no pior caso e age segundo essa mesma situac~ao. Uma das maiores desvantagens deste algoritmo reside no facto de todo o sistema33 ser afectado pela entidade que tem um pior desempenho, ou seja, no caso extremo de termos uma enti- dade sob uma dada ligac~ao de muito baixo debito isso implica que todo o sistema ira funcionar com uma qualidade demasiado reduzida para as possveis potencialidades da maioria do sistema. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

28 Perdas de Pacotes (cont.)
Técnica de ponderação de estados dos receptores Cada receptor é classificado e depois é tomada uma decisão de débito de informação. %PERDAS 100% Congestionada Normal %Perdas anunciada lim_sup filtroperdas lim_inf Sem perdas 0% Outro tipo de algoritmo baseia-se numa ponderac~ao dos estados de todos os intervenientes [16]. As decis~oes, neste caso, n~ao estar~ao dependentes do pior caso mas sim do estado global com que o sistema se esta a comportar. Assim, cada uma das entidades receptoras encontra-se classicada num de tr^es estados: congestionada, normal ou n~ao congestionada (ver figura 1.9). Esta classicac~ao estara dependente da denic~ao de limites inferiores (a) e superiores (b) para as percentagens de perda de pacotes relatadas pelos receptores. Baseada nesta classicac~ao de cada uma das entidades receptoras, sera tomada uma decis~ao que considera o numero de entidades que se encontram em cada uma das situac~oes. Desta forma vericar-se-a qual a relac~ao entre o numero de entidades em cada uma das situac~oes e o numero total de entidades presentes no sistema. Novamente podem-se definir níveis que ajustem a decis~ao favorecendo as entidades que se encontrem com melhor desempenho ou, pelo contrario, favorecendo aquelas em que se verica um maior numero de perdas de pacotes. O algoritmo a seguir apresentado descreve exactamente este raciocnio: Se (Nc/Ntot) >= Percd ======= d <- aumenta Se (Nn/Ntot) >= Percu ========d <- mantem Senão == d < Aumenta Nc – entidades congestionadas, Nn – entidades normais, Ntot – total entidades. Perd e Peru são percentagens que ditarão a tendência da tomada de decisão. Há autores que defendem que a diminuição deve ser multiplicativa e o aumento linear. Esta filosofia é semelhante à usada pelo TCP/IP para manipular situações de congestão. Débito - Diminuição, aumento,continuação Se ((Nentcong/Ntot) > %entcong) Se (Nentnorm/Ntot) > %entcong) Senão Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

29 Perdas de Pacotes (cont.)
Cenário multicast com 3 entidades (A,B,C). C relata as perdas; a partir de um dado instante as perdas de C ultrapassam os limites admissíveis pelos emissores A e B; A e B diminuem os débitos; as %ens perdas em C diminuem. RTP sobre multicast B Nesta tecnica um emissor codica um determinado medium de diferentes formas e transmite essas mesmas codicac~oes em canais logicos distintos. Cada uma desses canais contem informac~ao correspondente a diferentes graus de qualidade na codicac~ao do medium enviado. Se se partir do pressuposto que cada uma das codicac~oes transitara em enderecos multicast diferentes, torna-se possvel que cada um dos receptores se lie em ambos os grupos e, mediante o desempenho associado a cada um deles, ajuste a sua escolha a que lhe garantir uma melhor qualidade de servico. A figura 1.10 ilustra exactamente a situac~ao em que um dos receptores ja optou por uma das tramas emitidas, enquanto o outro ainda procede a recepc~ao das mesmas, optando mais tarde por uma delas. Em [17] e apresentada uma estrategia de comunicac~ao multicasting essencialmente baseada na ideia de varios tipos de codicac~ao de um mesmo recurso, optando o receptor pela escolha da mais apropriada. Outro tipo de soluc~ao e a utilizac~ao de mecanismos de prioridades para efectuar a codicac~ao de determinado medium. A ideia e utilizar os mecanismos de priorizac~ao de pacotes de rede, previstos nas vers~oes do protocolo IP. Desta forma a aplicac~ao podera transmitir numa mesma sess~ao informac~ao de diferente qualidade sobre o mesmo media. informac~ao essencial ser~ao atribuidas prioridades elevadas, enquanto que informac~ao de maior qualidade tera menores prioridades. Atraves deste mecanismo, em situac~oes de congest~ao, a informac~ao essencial tera maior probabilidade de atingir os receptores, sendo os pacotes de menor prioridade os primeiros a serem eliminados. A ideia e possibilitar aos receptores ligados a circuitos de baixo debito terem acesso a informac~ao basica, enquanto que receptores com melhores condic~oes de rede possam receber informac~ao de maior qualidade. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

30 Mecanismos de Controlo
Módulo Sincronização Emissores enviam + do que 1 medium Transmissão em sessões distintas (assumido pelo RTP) Afectados por condições variáveis (perdas, atrasos ....) Processamento local das estações Necessidade de sincronização periódica dos dados pelas entidades receptoras. Outro dos problemas que as aplicac~oes enfrentam nesta arquitectura (suportada pelo protocolo IP) e a possibilidade de dessincronizac~oes entre varios media que s~ao emitidos por uma mesma entidade geradora. Basicamente o problema coloca-se quando se pretende transmitir dois tipos de dados e estes devam estar temporalmente relacionados, ou seja, devam ser processados conjuntamente nas entidades receptoras. Um caso evidente e a transmiss~ao de imagem e voz, em que os media dever~ao estar sincronizados, caso contrario o receptor tera diculdades na percepc~ao da informac~ao que recebe. Isto podera acontecer devido a inumeros factores, dos quais se salientam: * Os protocolos utilizados poder~ao n~ao garantir a entrega completamente fiavel dos dados, pelo que e possível um dos medium transmitidos sofrer um numero de perdas substancialmente diferente do outro, o que originara uma dessincronizac~ao entre eles. * De igual modo, os atrasos sofridos pelas tramas poder~ao inuenciar o desfaza- mento entre dois determinados media. * Em protocolos em que se opte por transmiss~oes independentes para cada um dos media, os mesmos poder~ao sofrer diferentes anomalias pelo que igualmente ter~ao de ser periodicamente sincronizados34. * O proprio processamento local de cada uma dos media podera esporadicamente gerar algum tipo de dessincronizac~ao entre eles. Alguns destes problemas poderiam n~ao ser t~ao evidentes caso se optasse pela transmiss~ao de ambos os media num mesmo conjunto de pacotes de rede, o que n~ao acontece na losoa seguida pelo protocolo RTP com as vantagens que ja se apresentaram. fsincroniza(Ses1,Ses2) : nºpacotes de desfazamento entre as sessões como medida dessa dessincronização (+Ses1 atrasada, -Ses2 atrasada) Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

31 Sincronização (cont.) Como é realizada a sincronização ?
Através da informação presente nos pacotes RTCP de cada uma das sessões: “no instante x do emissor o último pacote do canal A estava etiquetado com t1, no instante y do emissor o último pacote do canal B estava etiquetado com t2” Canal A Canal B RECEPTOR eliminação buffering EMISSOR pontos de sincronização Como havia ja sido referido, todos os pacotes de dados gerados pelas entidades ir~ao ser etiquetados por um estampilha temporal. Esta devera constituir um contador linear que ao longo de toda a sess~ao sofre acrescimos constantes. Por exemplo, numa emiss~ao de audio codicado em PCM, em que a frequ^encia de emiss~ao de pacotes fosse de 20ms, os valores da estampilha temporal presentes nos pacotes poderia ser um contador (correspondentes a unidades de tempo em milisegundos) em que se iria observar um acrescimo de 20 unidades em dois pacotes sucessivos. Outra hipotese, e dado que nessa mesma codicac~ao cada pacote transportaria 160 amostras, seria a utilizac~ao de um contador cujo acrescimo fosse de 160 unidades. Consideremos pois o caso de uma sess~ao em que se transmitiam dois media (A e B), em que as estampilhas temporais sofrem acrescimos iguais a frequ^encia com que s~ao gerados (em milisegundos). Imagine-se que os pacotes gerados por um dado emissor t^em as seguintes estampilhas temporais: {A} 20ms ->0::::20x:::40:::60:::80:::100:::120:::140:::160:::180::: {B} 40ms _>1000:::::1040::::::1080y::::::::1120::::::::1160:::::::::1200 No medium A, existe um pacote identicado com um X, o mesmo acontecendo para o medium B, com um Y. Considerou-se que nestes dois pontos o emissor gerou um Sender Report para o medium A, e no outro gerou o mesmo tipo de pacote para o medium B. Os relatorios gerados pelos emissores (para ambos os media que transmite) s~ao acompanhados por uma estampilha temporal absoluta, ou seja, que explicita o tempo absoluto da maquina emissora no instante em que gerou o pacote RTCP. Desta forma, e colocando-nos agora do lado das entidades receptoras, estas ir~ao ter acesso a uma informac~ao do tipo: no instante x da entidade emissora, o ultimo pacote da stream A estava etiquetado com o valor 20; no instante y da entidade emissora, o ultimo pacote da stream B estava etiquetado com o valor 1080. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

32 Sincronização (cont.) Mesmo cenário multicast (entidades A, B C)
Problemas de sincronização aumentam com a escala da infra-estrutura utilizada Como os tempos x e y est~ao relacionados, x-y representara o tempo de intervalo entre a gerac~ao dos dois relatorios, que neste caso sera 60ms. Visto que o medium A estava a ser transmitido com uma frequ^encia de 20ms o receptor pode tirar aconclus~ao que, aquando da emiss~ao do pacote etiquetado com 1080 (medium B), estaria igualmente a ser transmitido o pacote 80 do medium A, isto porque em 60ms ser~ao gerados 3 pacotes do medium A. Ou seja, no instante y deveria estar a ser emitido um pacote do medium A com o valor de = 80. A partir desse instante o receptor podera estimar qual o pacote da codicac~ao do medium A que deveria estar associado a um dado pacote da codicac~ao do medium B, por exemplo ao pacote etiquetado com a estampilha 1160, dado que {A} -> 80 e {B}->1080, como estimar {Ag } ::: para um valor {Bg} -- 1160 ? como 1160 –1080= ms e nesse intervalo cabem 4 pacotes de codicac~ao de A, temos 80+4*20=160ms como o valor do pacote que deveria estar a ser tratado aquando do processamento do pacote 1160 do medium B, alias, como se conrma pela sequ^encia inicialmente apresentada. Pretende-se pois que a aplicac~ao tenha possibilidade de receber alguma infor- mac~ao da entidade protocolar acerca da exist^encia de algum desfazamento entre as varias streams geradas por um dado emissor. Para tal podera periodicamente invocar uma rotina que revelara qual o medium mais atrasado, bem como uma estimativa (em numero de pacotes) desse mesmo atraso. Perante tal indicac~ao, a aplicac~ao podera proceder a eliminac~ao de alguns pacotes do medium mais atrasado37, bem como a algum armazenamento necessario de outros pacotes38. A figura 1.11 exemplica uma situac~ao deste tipo, em que o medium B se encontra atrasado em relac~ao ao medium A. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet

33 RTP (cont.) Encapsulamento de diferentes media sobre o RTP (grupo AVT do IETF) Compressão dos cabeçalhos RTP diminuir a sobrecarga por eles gerados. Questões de segurança encriptação de conteúdos. geração aleatória de estampilhas temporais e identificadores Mecanismos de gestão e notificação de sessões Protocolo SDP - Session Description Protocol Mixers - Entidades modificadoras dos conteúdos dos pacotes RTP. Sistemas Telemáticos - Aplicações Adaptativas/Rígidas e Reservas de Recursos na Internet