Post on 05-Dec-2014
description
Redes e Servizos MultimediaRedes e Servizos MultimediaCurso 2008/09
Tema 2Provisión de calidade de servizo (QoS)
Exposición do problemaExposición do problema
Tipos de tráficoAtendendo basicamente aos requisitos QoS podemos distin uir:Atendendo basicamente aos requisitos QoS, podemos distinguir:
Tráfico elástico: Flexible en canto a requisitos de BW, adáptanse ás condiciones da rede.
Son bastante tolerantes a retardos pero non a perdasSon bastante tolerantes a retardos, pero non a perdas Corresponde ás aplicacións de datos tradicionais que usan tipicamente TCP
e, polo tanto, os seus mecanismos reactivos de control de conxestión Dous tipos de aplicacións:p p
• Transferencia masiva: FTP, aplicacións P2P, etc.• Transaccionais (moitas preguntas e respostas relativamente curtas): Web,
acceso a BBDD, etc.
Tráfico inelástico (ou de tempo real): Pouco flexibles en canto a requisitos de BW, necesitando un mínimo para
traballar axeitadamente. Son relativamente tolerantes a perdas pero moi traballar axe tadamente. Son relat vamente tolerantes a perdas pero mo pouco a retardos
Corresponde a aplicacións de tempo real, tipicamente multimedia, que usan UDP e técnicas de de disimulo ou FEC para paliar as perdasD s ti s d li ió s Dous tipos de aplicacións:
• Interactivas (retardo ida-volta crítico, entre 200-400 ms.): Son as conversacionais (VoIP, videoconferencia) e algúns xogos en rede (de acción, ou tipo Doom)
d d / íd ( d d l í ) fl • Streaming de audio e/ou vídeo (retardo ida-volta menos crítico): O fluxo multimedia só viaxa dende un servidor a un cliente
Exposición do problema O modelo de servizo extremo a extremo ofrecido por
IP é best-effort (BE) os paquetes IP son indistinguibles uns doutros e reciben o mesmo trato indistinguibles uns doutros e reciben o mesmo trato por parte da rede
Aplicacións tradicionais de Internet (Web FTP e mail Aplicacións tradicionais de Internet (Web, FTP, e-mail, Telnet) son orientados a datos, é dicir, tolerantes a retardos, pero non a perdas (tráfico elástico)S i i BE d IP fi bilid d Servicio BE de IP xunto coa fiabilidade extremo a
extremo de TCP resulta axeitado
Sen embargo, as novas aplicacións multimedia son de tempo real, é dicir, tolerantes a perdas pero non a retardos (os datos posúen un prazo de entrega)retardos (os datos posúen un prazo de entrega)
Necesidade de garantías sobre o servizo, que se traduce na necesidade de distinguir os paquetes e darlles tratamentos diferenciados darlles tratamentos diferenciados
Limitacións do best-effortRetardo extremo a extremo
Especialmente crítico en aplicacións interactivas p p Retardos > 400 ms. poden danar a interactividade da
conversación seriamente, polo que normalmente pimplican descartes no receptor
Variación do retardo (jitter) Datos multimedia son xerados a tasa constante e deben
ser reproducidos coa mesma tasa constante N d d d l d d d Necesidade de eliminar o jitter introducindo un retardo artificial (búfer), fixo ou adaptativo,
Compromiso entre o tamaño de búfer de recepción, que Compromiso entre o tamaño de búfer de recepción, que incrementa o retardo, e a tasa de paquetes fora de prazo
Escenario aplicación multimedia
DesempaquetadorDesempaquetadorTCt
r mostras ou tramas/sg.
TD
Codificador Codificador EmpaquetadorEmpaquetador
DesempaquetadorDesempaquetadorDecodificadorDecodificador
r mostras ou tramas/sg.
TREDE
REDEBúferBúfer
recepciónrecepciónTB
T T’ T + T + T + T + TTplayout(0) = T 0 = T0 + TC + TREDE + TB + TD
T’i = T’i 1 + 1/rT i T i-1 1/r
Discusión no foro
A vantaxe do tráfico multimedia é a súa A vantaxe do tráfico multimedia é a súa tolerancia ás perdas
Estas perdas poderían eliminarse con TCP, pero
¿cales son os inconvenientes?¿ca es son os ncon en entes?
As intervencións no foro serán puntuadas con ata 1 As intervencións no foro serán puntuadas con ata 1 punto na parte teórica, nota que será publicada antes do exame teórico.
Redes e Servizos MultimediaRedes e Servizos MultimediaCurso 2008/09
Tema 2óProvisión de calidade de servizo (QoS)
O contrato de servizo e os i i i d i ió d Q Sprincipios da provisión de QoS
A provisión de QoSUnha arquitectura de provisión de QoS permite
distinguir paquetes e distinguir paquetes e tratalos de xeito distinto
A provisión de QoS implica o establecemento A provisión de QoS implica o establecemento dun contrato entre un usuario (final ou ISP) e a rede que inclúe rede, que inclúe un acordo sobre o patrón de tráfico Traffic
Conditioning Agreement (TCA)Conditioning Agreement (TCA) un acordo sobre a QoS que recibirá do usuario
Service Level Agreement (SLA) Service Level Agreement (SLA) O incumplimento do TCA por parte do usuario
supón unha rotura de contrato e libera ao supón unha rotura de contrato e libera ao operador da súa obriga de cumprir o SLA
Principios da provisión de QoS
I. Para cada fluxo, as fontes declaran o seu patrón de tráfico e os requisitos de QoSq Q
II. A clasificación e marcado permiten a un routerdistinguir paquetes
III As fontes deben conformar (shape) ou regular o seu III. As fontes deben conformar (shape) ou regular o seu patrón de tráfico ao declarado e a rede ten que monitorizar (police) o seu cumprimento
l d áf d b ll IV. As clases de tráfico deben illarse para evitar interferencias nas QoS, pero isto debe facerse mediante un uso o máis eficiente posible dos precursos da rede (BW e búferes) Mecanismos de planificación/asignación de recursos
V Necesítase un mecanismo de control de admisión: V. Necesítase un mecanismo de control de admisión: Admitir ou rexeitar un fluxo se a QoS solicitada non pode ser satisfeita sen comprometer a doutros fluxos xa aceptadosfluxos xa aceptados.
Diagrama de bloques funcionalA provisión de QoS nos routers dunha rede IP consta das seguintes fases: No acceso á rede:
Distinción de paquetes:• Clasificación: Agrupar paquetes segundo algún criterio ou regra• Marcado: Código na cabeceira que identifica un fluxo ou clase• Monitorización de tráfico: medición e marcado adicional
No núcleo da rede: Tratamento diferenciado para cumprir SLA:
• planificación de recursos: búfer e BW Na saída da rede:
Re ulación de tráfic para cumprir TCA Regulación de tráfico para cumprir TCA
R t IPClasificaciónde paquetes
Marcadode paquetes
Monitorizaciónde tráfico
Router IP
Active QueueManagement Planificación
BW
Regulaciónde tráfico
g(AQM) BW
Redes e Servizos MultimediaRedes e Servizos MultimediaCurso 2008/09
Tema 2óProvisión de calidade de servizo (QoS)
Regulación e Monitorización(Sh i d P li i )(Shaping and Policing)
Regulación de Tráfico (Traffic Shaping)Quero cumprir
co TCA, polo tanto regularei o meu
Eu vixío que secumpre o TCA
tráfico
ador
Datos reguladosDatos reais
Regu
lRede
A regulación (conformación) do tráfico é realizada polo usuario para asegurar que o tráfico inxectado á rede é conforme ao patrón declarado no SLAconforme ao patrón declarado no SLA
A regulación é un mecanismo activo que altera (suaviza) o tráfico introducido
Empréganse reguladores de tipo Leaky Bucket (cubo con goteo)
Leaky Bucket No caso máis simple, o
tráfico dun fluxo T áfi almacénase nun búfer
(bucket) de tamaño C bytes, do que se extrae a tasa
Tráfico senregular
Descarte sebucket cheodo que se extrae a tasa
constante ρ bytes/seg. Cando o bucket se enche o
bucket cheo
Cando o bucket se enche, o exceso de tráfico é descartado
Bucket con capacidade
para C bytes
¿Inconveniente? Pode servir para regular Tráfico
f d Tasa cte.fluxos de tasa constante, pero non serve claramente para os de tasa variable
conformado(regulado)
Tasa cte.ρ bytes/sg.
Token Bucket (I) Tasa cte.ρ testigos/sg.
Bucket con capacidade para
Descarta testigosse bucket cheop p
C testigosse bucket cheo
Paquete de lonxitude L bytes
Espera porL testigos
EliminaL testigos Rede
á
Para permitir maior flexibilidade para o tráfico de tasa variable, é l d li i t di ti t d i d T k
Tasa máximaR bytes/sg.
emprégase un regulador lixeiramente distinto, denominado Token Bucket, que regula a tasa media ρ, permitindo ráfagas de tamaño C
Cada paquete debe obter do bucket tantos testigos como a súa p q glonxitude (en bytes) para poder ser transmitido
Os testigos son xerados a unha tasa constante ρ testigos/seg. e acumúlanse no bucket hasta un máximo de C testigosacumúlanse no bucket hasta un máximo de C testigos
Token Bucket (e II)celdas/sg.
R
AfórranseC = TMÁX.(R-ρ )
AfórranseA = min (C, ρ.T)
testigos
A
ρTMÁX.ρ
Bucket cheo
TMÁX
tT
Bucket cheo
A mellora aportada por Token Bucket é que permite “aforrar” testigos, cando a tasa de tráfico está por debaixo de ρ, para poder ser usados cando esta tasa se atope por ribacando esta tasa se atope por riba
EXERCICIO: Calcular a duración máxima dunha ráfaga a tasa de pico R
TMÁX = C/(R - ρ)
Monitorización (Policing) Marcadores No acceso á rede, debe verificarse se se cumple o TCA, función que se
denomina monitorización ou vixilancia (policing). A monitorización dun fluxo implica realizar medidas para verificar a
úp p
súa conformidade co TCA En función das medidas e a conformidade co TCA, asígnaselles aos
paquetes unha marca adicional, tipicamente denominadas cores. Por á
p q pisto, fálase habitualmente de marcadores ou algoritmos de marcado
É habitual o uso de tres cores (verde/vermella /amarela) para indicar o nivel de conformidade dun fluxo con patrón declarado:p O tráfico conforme márcase verde O tráfico claramente non conforme márcase vermello, e habitualmente é
descartado na fonte ou antes de chegar ó destinoO t áfi f “ ” á l d O tráfico non conforme “por pouco” márcase amarelo, e pode ser:
• Conformado, é dicir, retardado para que cumpra o TCA• Marcado cunha prioridade inferior ao conforme (verde)
Monitorización (Policing) Marcadores
Este usuario non está cumprindo o contrato.¿Cal debe ser a multa?¿Cal debe ser a multa?
•• DEIXAR PASAR, RETARDARDEIXAR PASAR, RETARDARPrioridadePrioridade
Monitorización
•• MARMARCAR BAIXA PRIORIDADECAR BAIXA PRIORIDADE•• DESCARTARDESCARTAR
E ó
HHALB00 HH HHABC 00C HHC
Prioridade baixa: Prioridade baixa: En caso de conxestión, a rede pode descartar máis tarde os paquetes marcados de baixa prioridade
Paquete descartado C
Dado que o patrón de tráfico se especifica segundo o Token Bucket co que é regulado este, parece lóxico que a monitorización e marcaxe na rede se base no mesmo Token Bucketrede se base no mesmo Token Bucket
Redes e Servizos MultimediaRedes e Servizos MultimediaCurso 2008/09
Tema 2óProvisión de calidade de servizo (QoS)
Illamento de clases de tráfico: Planificación de búfer e BWPlanificación de búfer e BW
Planificación de búfer (AQM) Os mecanismos de planificación de búfer reciben
tamén o nome de mecanismos de xestión activa de cola (Active Queue Management AQM)(Active Queue Management - AQM)
En ausencia dun mecanismo AQM nun router IP, todos s p t s h n n búf h s n os paquetes que chegan a un búfer cheo son
descartados de xeito indiscriminado, mecanismo que se denomina tail drop Sincronización global en TCP S l ió d t i di i i d Solución: descarte no indiscriminado
O mecanismo AQM máis amplamente usado é RED RED Q p((RandomRandom EarlyEarly DropDrop), ), baseado en Descarte aleatorio de paquetes (para evitar a sincronización
global en TCP) global en TCP) Tras detección adiantada da conxestión (unha vez superado
un límite do tamaño medio da cola)
O algoritmo REDÁ Funcionamento: Á chegada dun paquete estímase o
tamaño medio Q da cola de saída Qi+1 = Qi*a + q*(1 – a) Se Q < min Funcionamento normal: Almacenamento do paquete Se Q < minth Funcionamento normal: Almacenamento do paquete Se minth ≤ Q < maxth Evitar conxestión: O paquete descártase
cunha probabilidade crecente linealmente con Q: P P *(Q i )/( i )Pdrop=Pmax*(Q – minth)/(maxth–minth)
Se Q maxth Conxestión: Descártase o paquete O comportamento de RED ven determinado polo conxunto O comportamento de RED ven determinado polo conxunto
de parámetros (minth, maxth, Pmax). Recoméndase que maxth sexa dous ou tres veces minth. q th th
Valores típicos de Pmax atópanse entre 0.01 e 0.2
Planificación de BW: GPS Estes mecanismos de planificación úsanse para decidir cal será o
próximo paquete a enviar sobre un enlace dado. FIFOFIFO e PQ PQ (Priority Queueing) non garanten BW mínimo nin equidade
na súa asignación Disciplinas basadas en GPSGPS (GeneralizedProcessor Sharing)g)
Dadas N colas con pesos wi para un enlace de capacidade C, GPS GPS reparte este BW entre todas as colas non baleiras de forma proporcional ao peso de xeito que en cada instante a tasa de servizo proporcional ao peso, de xeito que en cada instante a tasa de servizo para unha cola non baleira i é Ri = C . (wi /k non baleira wk) , garantindo a cada cola un BW mínimo proporcional ó peso
GPSGPS é un algoritmo ideal, imposible de implementar, dado que asume que o servidor pode atender simultaneamente todas as colas non baleiras (a una tasa de servizo Ri) e que o tráfico é fluído, cando nun ( i) q ,sistema realista só se pode atender unha cola cada vez (a tasa máxima C) e o tráfico consta de paquetes de lonxitude variable.
Todas as aproximacións prácticas de GPS propostas fan uso dun Todas as aproximacións prácticas de GPS propostas fan uso dun reparto circular. WFQ (Weighted Fair Queueing) é a aproximación de GPS máis amplamente usada
Exercicio Suposicións nun caso ideal:p
Temos un fluxo fluído regulado con Token BucketToken Bucket(C, ρ) Este fluxo atravesa N routers Todos os routers usan GPSGPS e garanten a este fluxo un BW
mínimo R>ρ
Obter o retardo máximo extremo a extremo
TB e GPS (WFQ): Retardo acotado Suposicións caso ideal:
Fluxo fluído regulado con Token BucketToken Bucket(C, ρ) Todos os routers usan GPSGPS e garanten a este fluxo un BW R>ρ
Peor caso: bucket cheo Retardo máximo no primeiro router = C/R
Seguintes routers: Dado que a tasa de saída (R) é d d ( ) d 0sempre maior que a de entrada (ρ) Retardo = 0
Retardo máx. extremo a extremo TMAX ≤ C/R Caso real: WFQWFQ e un fluxo con paquetes de tamaño máx.
m (M na rede), H saltos e Rk capacidade en cada enlace k [Parekh 92]:k [Parekh 92]:
H MHC )1(
H
k kMAX R
MR
mHRCT
1
)1(