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(