Mecanismos para adaptação de QoS ao nível detransporte
“It did not take long to realise that an access rate available at the MAC
or LLC levels was far from being available above the transport layer.
This is not surprising, because opening a highway does not itself change
drastically the speed of bicycles.”
QoS II - UC/UM (21/03/2000)
Vitor Basto ([email protected])
DI - Universidade Minho
Vitor Basto - QoS II - Universidade doMinho (2)
Estrutura da apresentação
• Motivações do estudo
• Caracterização do cenário de operação
• Âmbito e Objectivos
• Causas do problema, soluções propostas, alternativas e limitações
• Caracterização do protocolo de transporte (ideal)
• Multicast ao nível de transporte
• QoS distribuída (?)
• Adaptação de QoS ao nível de transporte
• Modelos de decisão para a adaptação
• Protocolo hospedeiro
• Conclusões e trabalho futuro
Vitor Basto - QoS II - Universidade doMinho (3)
Motivações do estudo - problemas
• Problemas de desempenho, estabilidade e controledetectados na transferência de grandes quantidades deinformação sobre ligações de longas distâncias (pilhaTCP/IP).
E.x.
• EU/DG-JRC/CEO - Centre for Earth ObservationTCP (standard) limita a transferência a 200 kbit/s sobre ligações satélite de34 Mbit/s
• Electricite de FranceExperimenta resultados similares em ligações terrestres de longa distância.
Vitor Basto - QoS II - Universidade doMinho (4)
Motivações do estudo - atractivos
• Comunicações satélite (Vs infra-estruturas terrestres)
– Cobertura geográfica alargada e exploração rápida
– Insensibilidade à distância
– Tecnologia típica de difusão (distribuição multiponto)
– L.B a pedido ; ligações de banda larga
• Redes satélite:
– Presente: essencialmente interligação de redes terrestres
– Futuro: Serviços de distribuição multiponto com requisitos consideráveis de LB
Vitor Basto - QoS II - Universidade doMinho (5)
Caracterização do cenário
• Canais de dados e controle com LB tipicamente assimétricas.
• Taxas de transmissão - Mbit/s ou mesmo Gbit/s.
• Atrasos de propagação (GEO): RTT ~ 558ms.
• Capacidade de buffering: (buffer > bandwidth * RTT).
– E.g 34 Mbit * 558ms = 2.37 Mbyte
• BER(bit error rates) típica para satélite ~1 x 10-7 (melhor com FEC ao nível de ligação).
Para fibra 10-12 ou melhor.
• Detecção de perdas: mínimo 1*RTT (~ 0.558 s )
• Recuperação de perdas: mínimo 1.5*RTT ( ~ 0.837 s )
• GEO - não apresenta problemas de conectividade.
Vitor Basto - QoS II - Universidade doMinho (6)
Âmbito do estudo
• Estudo e desenvolvimento de serviços de transporte de suporte ao
tráfego gerado por aplicações multimedia tolerantes/adaptativas, no
contexto de ligações de longa distância (pilha TCP/IP).
Características de QoS do serviço de rede variáveis.
Vitor Basto - QoS II - Universidade doMinho (7)
Objectivos do estudo
• Identificar e medir a adequabilidade dos mecanismos de controle de
congestão e fluxo, ordem, detecção e recuperação de erros,
planeados, especificados e disponibilizados pelos serviços de
transporte TCP/IP no âmbito do estudo e propor soluções
alternativas.
• Enquadrar QoS ao nível de transporte (extremo a extremo) com
QoS no contexto mais global de arquitectura QoS (Aplicações,
Transporte, Rede).
Vitor Basto - QoS II - Universidade doMinho (8)
• Ao nível dos protocolos de transporte
– Detecção e recuperação de erros (TCP)
• ack+ acumulados - problemas de identificar status da tx após 1º erro
• timeouts - cálculo de RTT é difícil (LFN’s, routing dinâmico, reflectir a carga da rede,
ambiguidade nos casos de erros/retransmissões)
– Controle e prevenção da congestão (TCP)
• Slow start (activado no inicio da ligação e na ocorrência de erros)
• Não distingue atrasos excessivos, erros de transmissão e perda de informação por
congestão da rede.
• Dificulta tráfego de breves transacções (e.x. tráfego WWW-HTTP/1.0)
– UDP
• Serviço não fiável, não ordenado.
• Não previne nem controla situações de congestão da rede.
Causas do problema
Vitor Basto - QoS II - Universidade doMinho (9)
Soluções propostas• Soluções ao nível de controle do protocolo
RFC 1323 - TCP Window Scale e Timestamps Option melhor medição de RTT
RFC 1191 - (TCP Path MTU Discovery) Rácio Inf. Útil/Inf. Controle vs fragmentação
RFC 2018 - TCP Selective Acknowledgment Options
SNACK SCPS - TP Space Communications Protocol Standards -Transport Protocol(extensões TCP com problemas de interoperabilidade impedem aceitação generalizada)
• Soluções ao nível da arquitectura/topologia (redes híbridas/assimétricas)
• Filosofia cliente-servidor
• Comunicação tipicamente assimétrica (dados Vs inf. de controle)
• Tira partido das características dos canais de comunicação.
• Desempenho limitado pela capacidade e balanceamento das ligações.
tam. max. seg. dados /LB canal de dados >= tam. max. seg. de ack/LB canal de controle
Vitor Basto - QoS II - Universidade doMinho (10)
Soluções propostas• Soluções ao nível da arquitectura/topologia
Snoop (TCP-aware link layer schemes)
• Recuperação de erros ao nível de ligação. TCP necessita ter conhecimento para não
activar precipitadamente recuperação de erros e controle de congestão quando
TAMBEM detecta perdas/desordens. Redundância de funções a diferentes níveis =>
problemas de coordenação.
Spoofing (split de ligações TCP em cliente - sat. gateway - sat. gateway - servidor)
• Permite que o Gateway use protocolo de transporte mais apropriado ao canal decomunicação reagindo em representação do Cliente (quebrando a semântica extremo aextremo). Gateway trasparente para o servidor permite maior facilidade na comunicação(do ponto de vista do servidor).
Soluções ao nível das aplicações (File stripping)
• Transferência feita através de múltiplas ligações e sincronização ao nível das aplicações
proporciona melhorias de desempenho consideráveis (e.x XFTP, HTTP). Levanta no
entanto problemas ao nível da competição por ligações e da necessidade de
sincronização inter fluxo ao nível aplicacional.
Vitor Basto - QoS II - Universidade doMinho (11)
Soluções alternativas• Novos protocolos de transporte
– RDP (Reliable Data Protocol)
– NETBLT (Network Block Transfer Protocol) - específico para transferência de grandesvolumes de dados sobre LFN’s (mecanismos de controle orientados a buffers)
– T/TCP - Acelera processo de setup em ligações TCP
– RTP/RTCP (Real-time Transport Protocol) - Sincronização e Monitorização
– TP++, VMTP, XTP, DTP, Delta-t, SNR, MSP, “AALs”, …
– POC (Partial Order Connection)
• Ordens parciais são previamente acordadas entre os extremos antes da transferência.
• k-XP (connection oriented,unordered, partially reliable). É especificado número máximode retransmissões.
• POCv2 (connection oriented, unordered, controlled-loss services). São feitasretransmissões desde que não atrasem o restante tráfego da ligação.
– MMPOC protocol (End-to-End mobile code - java)
Vitor Basto - QoS II - Universidade doMinho (12)
Soluções alternativas
• Flexibilização dos serviços de transporte e respectivos mecanismos de ordem,
detecção e controle de erros e controle de fluxo.
• Permitir a gestão de compromissos entre QoS requerida pelas aplicações e recursos
disponibilizados pela rede, segundo uma lógica aplicacional (orientação à
mensagem/objecto da aplicação - Application Layer Framming).
• + fiabilidade +ordem => +atrasos -desempenho
• Aplicação deverá especificar ao serviço de transporte compromissos desejáveis entre
as diversas características de QoS, que verificam os níveis de serviço mínimos e
níveis de degradação toleráveis.
Vitor Basto - QoS II - Universidade doMinho (13)
Soluções alternativas• Serviços de transporte (TCP/IP) apresentam-se em extremos de um
espectro de QoS fiabilidade/ordem. Levanta problemas no desenho das
aplicações que não se enquadram nesses extremos de QoS.
Solução: Serviços de ordem e fiabilidade parcial.
0
1
Fiabilidade
Ordem1
UDP
TCPRDP
Serviços de Ordem e Fiabilidade Parcial
Vitor Basto - QoS II - Universidade doMinho (14)
Soluções alternativas
• Melhorias de desempenho dependem das características da tecnologia de rede (LB,atrasos, tx de erros, duplicações e violações de ordem), bem como da flexibilidade dasespecificações QoS das aplicações.
• [Marasli et al. 1994] estudos analíticos revelam as vantagens de serviços de ordem efiabilidade parcial ao nível de transporte TCP/IP.
• Probabilidades de buffering e tempo de buffering no receptor
• Menores atraso extremo a extremo; eventualmente melhor throughput (+ difícil)
• Menor degradação resultante do efeito da perda de confirmações (ACK)
• Papel do serviço de transporte na gestão de compromissos (QoS requerida pelaaplicação Vs QoS fornecida pela rede).
• + QoS (serviço rede) => - reflexos positivos dos serviços OP/FP.
Vitor Basto - QoS II - Universidade doMinho (15)
Soluções alternativasExige modelos formais de especificação das características de QoS
(fiabilidade, ordem, sincronização intra e interfluxo)
[Tmin,Tmax]Firing Rules
...
[Tmin,Tmax]
P1
P2
P3
P4
P5
place/processing node
arc
[time interval]
TransitionTime Stream
Petri Nets
[Tmin,Tmax] - associado a um arco (liga um nó - uma transição), representa o intervalo de processamento de um nó (e.g. tempo de apresentação).
Firing Rules - And, Weak-And, Strong-Or, Or, Master, And-Master,Weak-Master,Strong-Master,Or-Master
Transição - Representa sincronização temporal complexa dos arcos de entrada (processamentos individuais)
Vitor Basto - QoS II - Universidade doMinho (16)
Soluções alternativas
• Para o nível aplicacional
• XML, SMILE, ... (Geralmente os modelos de sincronização encontram-se
implícitos nas aplicações Vs modelos explícitos).
• Para o nível de transporte
• Time Stream Petri Nets
• Modelos de gestão de compromissos de QoS (heurísticos, probabilisticos, ...)
• Modelo computacional para animação/verificação da especificação
• Para o nível de rede
• Mapear QoS ao nível aplicacional em QoS/CoS ao nível da rede.
Vitor Basto - QoS II - Universidade doMinho (17)
Soluções alternativas• Mapear QoS ao nível aplicacional em QoS/CoS ao nível da rede.
• No contexto exclusivo de redes IP
• Classes IP diffserv
• No contexto de tecnologias de rede com características QoS diferentes
• IP , ATM, RDIS, GEO, LEO, ...
• Impossibilidade de encontrar protocolos genéricos e eficientes/eficazes
• Protocolos específicos a cada tipo de rede (TCP/TCPSat, IP, ATM, AALs)
• Diferentes protocolos, diferentes redes => Problemas de sincronização
• Problemas na escolha das redes e gestão dos diferentes protocolos
Aplicações
UDPTCP SatTCPATM RDIS IP ...
Mecanismos de ordem e fiabilidade parcial
Mecanismos de escolha da tecnologia de rede/pilha
Vitor Basto - QoS II - Universidade doMinho (18)
Protocolo hospedeiro• Características desejáveis do protocolo de transporte hospedeiro dado o âmbito e
motivações do estudo (principais funções do nível de transporte):
• Orientação à ligação (e.g. troca de informação sobre controle de fluxo da ligação)
• Detecção de erros/perdas e duplicados ; recuperação de erros (a pedido)
• Verificação de integridade da informação de controle e/ou dados (a pedido)
• Verificação de ordem (de acordo com especificação explicita)
• Efectuar controle de fluxo window/rate based (a pedido)
• Permitir transmissão ponto-ponto ou ponto-multiponto
• Entrega de tráfego prioritário fora de ordem (a pedido) [e.g. sinalização ao nível de sessão]
• Estabelecimento de prioridades entre ligações/sessões (complexo)
• Autenticação e confidencialidade (a pedido)
• Reportar estado interno do protocolo e da comunicação (ligação/sessão)
Vitor Basto - QoS II - Universidade doMinho (19)
Protocolo hospedeiro
• UDPServiço orientado a transferência de mensagens, não fiável, não orientado à ligação
• TCP (rfc 793 ...)Serviço fiável, transferência de fluxo de bytes; controle de fluxo baseado em ordem linear enão em ordem parcial; orientado à ligação (ponto a ponto).
• RDP (rfc 908 e 1151)Serviço fiável, transferência de mensagens ; serviço ordenado é possível se definido noestabelecimento da ligação; orientado à ligação (ponto a ponto).
• RTP/RTCP (rfc 1889 ...)Permite transmissão ponto-multiponto ; permite a definição das características do serviço detransporte numa lógica por mensagem/fluxo; preconiza mecanismos de monitorização dascaracterísticas de QoS.
Vitor Basto - QoS II - Universidade doMinho (20)
Multicast ao nível de transporte
Principais objectivos dos protocolos de transporte Multicast
Para tráfego de tempo real:
• Limitar atrasos. À custa de menor fiabilidade (e.g. RTP)
Não efectuam recuperação de erros
Não concebem fiabilidade e ordem parcial
Não realizam controle de fluxo, nem prevenção e controle de congestão.
Para tráfego sensível a perdas:
• Garantir fiabilidade. À custa de maiores atrasos (e.g. RMTP, SCE)
Não suportam sincronização (fluxo único)
Não concebem fiabilidade e ordem parcial
Ligações e receptores com capacidades mais baixas limitam QoS do grupo
Vitor Basto - QoS II - Universidade doMinho (21)
Multicast ao nível de transporteOutros protocolos de multicast fiável ao nível de transporte:
• MTP - multicast atómico com controle de fluxo; mantém sincronização entre os membros do grupo
• RAMP/MGA - participação controlada por nó raiz. Estabelece caminhos de conecção/desconecção
• XTP - multicast não fiável e semi-fiável - receptores que não se distanciem muito do estado do grupo
(Tratam semânticas de grupo muitos-muitos: FIFO, ordem total, atomic commitment, cordem causal, consensos. Centrais em sistemas transaccionais e orientados aos grupos)
• SCE - Interface entre o nível de rede/transporte para multicast fiável (e.g. TCP - SCE - IP)
Outros protocolos de multicast fiável ao nível da rede
• ST-II - Garante atraso extremo-extremo; implica reserva de L.B pª todas as ligações em fase de setup
• URGC - Apropriado para operações de S.O distribuídos que gerem recursos duplicados/redundância.
Vitor Basto - QoS II - Universidade doMinho (22)
Multicast ao nível de transporte
Sender
ACKProc.
RecACKProc.
RecRec
• Requer subtree multicasting (SUBTREE_MCAST packet type)
• Distribuição evita ACK Implosion em grupos grandes
• Permite RTT mais rigorosos, gestão de QoS + localizada/descentralizada
• Definição de AP estática (falta protocolo de sessão pª definição dinâmica)
RMTP (Reliable Multicast Transport Protocol)
Vitor Basto - QoS II - Universidade doMinho (23)
Multicast ao nível de transporte
• AP’s enviam pacotes de controle periodicamente (RTT inicial constante)
• Receptores escolhem AP dinamicamente com base em n.º hops (RTT)
• Primeiro AP de qualquer receptor é o emissor (depois é o mais o próximo).
• AP deixa de ser acessível (e.g. crash) pelo expirar de timeout de pacote de controle
• Detecção e recuperação de erros (ack acumulado + bitmap [ 0/1] janela de mensagens)
• Retransmissão multicast/unicast conforme n.º de receptores destino (receivers count).
• Controle de fluxo baseados em janela de mensagens e taxas de transmissão (descentralizado)
• Detecção de congestão feita com base nos pedidos de retransmissão dos receptores
• Controle de congestão através de janelas de envio e de congestão (descentralizado)
RMTP (Reliable Multicast Transport Protocol)
Vitor Basto - QoS II - Universidade doMinho (24)
Multicast ao nível de transporte
• Pressupõe disponibilidade/esforço dos participantes em fazer buffer de mensagens sempre que possível.
• Pedido de retransmissão é difundido (multicast) para os potenciais retransmissores (subgrupo).
• Requer contention resolution,nos pedidos de retransmissão.
• Requer contention resolution,na retransmissão (escuta e timers aleatórios [RTT, 2*RTT] do sub grupo)
• Gestão da recuperação de erros no grupo/sub grupo não requer líder. Feita com base em TTL (distância)
• Na impossibilidade de recuperação (ou recuperação parcial) no primeiro sub grupo => aumento de TTL
e novo pedido de retransmissão par ao próximo sub grupo
• Permite envio de mensagens não fiáveis (consideradas prioritárias
e sem qualquer verificção de ordem)
Light-Weight Reliable Multicast Protocol
R1
R2
R3 R1
R2
R1
R2
R4
Sender
Distance
Hierarquia de sub grupos/anéis
Vitor Basto - QoS II - Universidade doMinho (25)
Multicast ao nível de transporte
etc (which are central topics in transactional systems and group-oriented systems). Reliable distributed protocols imply complex relashionships. For example, both the atomic commitment and total order multicast rely on consensus, while the later is itself based on failure detections, on reliable point-to-point communications, and on reliable multicasts.This create a complex protocol dependency which we are not dealing with at the transport layer.
Falha pela ausência de um serviço adaptativo ao nível de transporte:
• Adaptação à QoS da rede e suas variações com base em requisitos QoS das aplicações
• Adaptação distribuída/localizada à degradação causada por assimetrias de QoS nas ligações
• Gestão de QoS entre fluxos ; sincronização (ultrapassar noção de fluxo único)
Necessitam mecanismos e modelos quantitativos de suporte à decisão:
• Para gestão e adaptação de QoS
• Para eliminação de participantes que comprometam a QoS do grupo
• Para descentralização e mobilidade de agentes de gestão de QoS (nível de transporte)
Vitor Basto - QoS II - Universidade doMinho (26)
QoS distribuída
RecRec
QoSProc.
QoSProc.
Sender
Rec
QoS Aware AdaptationMechanisms
RecRec
QoSProc.
QoS Aware AdaptationMechanisms
Satellite link
QoS Aware AdaptationMechanisms
Fiber high speed link
Vitor Basto - QoS II - Universidade doMinho (27)
QoS distribuída
• Topologia dinâmica => protocolo de sessão (escolha e mobilidade de QoS Proc’s)
• Mobilidade de QoS Proc. => capacidade dos QoS proc.’s e localização na arvore
• Mobilidade de agentes QoS (experiência/conhecimento) => plataformas virtuais de operação
• Criação de QoS proc => seccionamento mento com base nas características de QoS específicas
• Descentralizar , distribuir, localizar decisões sobre níveis de degradação a adoptar
• Isolar assimetrias/degradação resultantes de características de QoS da rede/receptores diferentes
• Adaptação QoS => monitorização e modelos de decisão quantitativos (emissor, receptor e QoS proc.)
Vitor Basto - QoS II - Universidade doMinho (28)
Adaptação de QoS (transporte)Modelos de decisão necessários no suporte às operações do nível de transporte:
• No emissor:
• Ordens de envio (dependem de erros e duração da transmissão, ciclo de vida na aplicação, etc.)
• FEC (forward error correction), taxas de erro e padrões/distribuição dos erros
• ...
• No receptor:
• Ignorar /recuperar perdas ? Reflexos/impacto na degradação de QoS ?
• Pedir retransmissão ? a um ou mais QoS proc. ?
• Em processador QoS:
• Risco de violação de QoS causada por limitações de ligações => Desafiar criação de sub arvores
• Risco de violação de QoS causada por limitações de ligações => remoção do grupo
• Escolha de QoS proc. pelos receptores => nº de hops (proximidade) + critérios de afinidade QoS
Vitor Basto - QoS II - Universidade doMinho (29)
QoS distribuída
RecRec
QoSProc.
QoSProc.
Sender
Rec
QoS Aware AdaptationMechanisms
RecRec
QoSProc.
QoS Aware AdaptationMechanisms
Satellite link
QoS Aware AdaptationMechanisms
Fiber high speed link
Source QoS for all receiversConstant ; No QoS adaptation
(IP flow)
Control flow path
managed QoS for a sub treeConstant ; No QoS adaptation
(IP flow)
Data flow path from sender
QoS Proc. data flow
• Adaptação efectuada só nos fluxos controlados pelos QoS Proc. e não no fluxo multicast emissor-receptores
• QoS do fluxo multicast emissor-receptores é controlado apenas pela entidade de transporte emissora
• Adaptação de QoS em agentes de transporte no fluxo multicast emissor - receptores ???!!!
• Protocolo de sessão, criação de nova arvore unicast/multicast para relay de transport com adaptação QoS ?!
Vitor Basto - QoS II - Universidade doMinho (30)
Minimum QoS value
Optimal QoS value
Current QoSmeasurement
Intolerable QoS value
Time
Tallowed Tallowed
QoSCharacteristic
Adaptação de QoS (transporte)
Níveis/zonas de degradação e riscos de violação de QoS:
Vitor Basto - QoS II - Universidade doMinho (31)
Adaptação de QoS (transporte)• Variáveis a considerar na especificação das características de QoS
• Tempo (virtual/elástico)
• Fiabilidade
• Ordem (dependências de ordem, operadores lógicos e temporais)
• Custo ?
• Variáveis a considerar nas decisões ao nível de transporte• Taxas de erros da rede e tipo de erros (congestão, transmissão, conectividade)
• Atraso extremo a extremo e Jitter
• Tamanho das mensagens e dos buffers
• Estado global da comunicação (múltiplos fluxos)
• Características de QoS da mensagem
• Densidade da ordem parcial, relações de dependência
• Tempo de processamento por pacote de dados/controle
Vitor Basto - QoS II - Universidade doMinho (32)
Adaptação de QoS (transporte)
FECProcessing
Transport MonitorError detectionand recovery
Buffer management interface
DegradationManager
ClassifierFormal descriptions
andDecision models
Fragmentation
Application layerTransport layer
Sender Application
Network layer
Dispatcher -> QoS classes(Does flow control)
Network Monitor
Transportmanagement
Transportmechanisms
Discarder
* Fluxo de controle do receptor não representado
Vitor Basto - QoS II - Universidade doMinho (33)
Adaptação de QoS (transporte)
• Fragmentation (MTU) - Especificação QoS deve automaticamente garantir que os fragmentos são
tratados como mensagem única.
• Classifier - Com o suporte dos modelos formais classifica mensagens de acordo com a sua
importância na manutenção da QoS especificada pela aplicação (fiabilidade, ordem, e
parâmetros calculados e.g. densidade da ordem linear, graus de inter-dependência das
mensagens, etc.)
• Degradation manager - Calcula ordens de envio. Estabelece compromissos na manutenção
da QoS desejada. Sacrifica fluxos com menos impacto na degradação ou melhores
níveis de QoS em favor de fluxos com QoS mais próxima dos limites toleráveis. Tem
em conta indicadores de QoS da rede (Network monitor -> B/W Broker ?, métricas
associadas a CoS ?)
Vitor Basto - QoS II - Universidade doMinho (34)
Adaptação de QoS (transporte)
• Transport monitor - Regista métricas de QoS dos fluxos de transporte (individuais e agregados).
Detecta e regista violações de QoS.
• Error detection and recovery - mecanismos de avaliação de perdas e seus padrões (transmissão,
congestão) e recuperação de erros/retransmissões.
• FEC - Cria redundância sobre mensagens individuais ou de forma sistemática sobre fluxos
• Discarder - Elimina mensagens em buffer, eventualmente de forma sistemática sobre os vários fluxos
• Dispatcher - Injecta mensagens na rede. Verifica (taxas e) janelas de controle de congestão e de fluxo
Vitor Basto - QoS II - Universidade doMinho (35)
Adaptação de QoS (transporte)
Transport Monitor DiscarderError detectionand recovery
Application layerTransport layer
Receiver Application
Reassembly
Buffer management interface
Dispatcher(synchronization interface)
DegradationManager
Formal descriptionsand
Decision models
Network layer
Transportmanagement
Transportmechanisms
* Fluxo de controle para o emissor não representado
Vitor Basto - QoS II - Universidade doMinho (36)
Modelos de decisãoVariáveis:
x: Densidade da ordem e relações de dependência da mensagem
y: Taxa de erros detectada por monitorização
z: Padrão dos erros (congestão, transmissão)
w: Ordem e fiabilidade exigível da mensagem
k: Atraso e jitter
i: Tamanho da mensagem
j: Tempo de processamento do pacote de dados/controle
Decisões:
Discarder(x, y, z, w, k) -> {0|1}
FEC(x, y, z, w, k, i, j) -> {0|1}
Recover(x, w, k, i) -> {0|1}
Classifier(j, i, k) -> {0 .. n}
Degradation manager(x, …, j) -> {0 .. n}
Dispatcher(x, z, w, k, I, j) -> {0|1}
...
Vitor Basto - QoS II - Universidade doMinho (37)
Protocolo hospedeiro
Padding
1b 1b
CSRC Count Mark Payload Type Sequence Number
16b7b1b4b2b
Timestamp
Synchronisation source (SSRC) identifier
Contributing source (CSRC) identifier...
Extension...
Ext.Flag
LengthDefined by profile Header extension
Version
RTP Header Format
• Transmissão ponto-multiponto; suporte a tráfego de tempo real
• Permite a definição das características do serviço de transporte numa lógica por mensagem
• Disponibiliza mecanismos de monitorização das características de QoS.
• Facilmente extensível (fluxo de dados, controle e de monitorização)
Vitor Basto - QoS II - Universidade doMinho (38)
Sender report RTCP packet
Padding
1b
Sender’s pack count
Sender’s octet count
SSRC_1 (SSRC of first source)
extended highest sequence number received
interarrival jitter
last SR (LSR)
delay since last SR (DLSR)
SSRC_2 (SSRC of second source)
...
profile-specific extensions
Recep. Rep. CountPayload Type (=200)
8b5b
Length
fraction lost cumulative number of packets lost
2b
Version
NTP Timestamp most significant word
NTP Timestamp least significant word
RTP Timestamp
SSRC of Sender
16b
Protocolo hospedeiro
Vitor Basto - QoS II - Universidade doMinho (39)
Application-defined RTCP packet
Protocolo hospedeiro
Padding
1b 8b5b2b
Version
SSRC of Sender
16b
Subtype Payload Type (=204) Length
Name (ASCII)
Application-dependent data
Vitor Basto - QoS II - Universidade doMinho (40)
Conclusões
Adaptação <=> Tolerância/Flexibilidade
Escalabilidade <=> Distribuição de funcionalidades
Heterogeneidade <=> Descentralização
Dinamismo <=> Mobilidade
Adaptação, Distribuição, Descentralização, Mobilidade
=>
DECISÃO
Vitor Basto - QoS II - Universidade doMinho (41)
Conclusões
• Limitações da abordagem
Difusão onde não seja requerida sincronização entre emissores, mas apenas sincronizaçãoentre fluxos de um emissor - um para muitos
E.g. partilha de recursos (ponteiros/cursores). Problemas em operações não idempotentes
Ultrapassado com recursos diferenciados por emissor: múltiplos ponteiros/cursores
• Trabalho futuro
– Definir extensões RTP, Payload types, ... RTCP reports, ...
– Formular, enquadrar, adaptar modelos de decisão para adaptação de QoS
– Avaliar QoS distribuida e estudar protocolos de sessão
– ...