Introduction à la qualité de service dans les réseaux

Une « vue » sur l ’Internet • Des millions de machines connectées : hosts, end-systems – PCs stations, serveurs – PDAs téléphones, toasters

exécutant des applications en réseau

routeur serveur

station mobile

local ISP

• des liaisons – fibre, cuivre, radio, satellite – débit, bande passante • routeurs: acheminement des paquets

regional ISP

Cœur du réseau

1

Le service orienté connexion Objectif: transférer des données entre systèmes terminaux! • handshaking: préparation du transfert – Hello, protocol • Transfert • TCP - Transmission Control Protocol

TCP service [RFC 793] • Transfert du flux de données fiable et ordonné – Gestion des pertes et erreurs par accusés deréception et retransmissions • Contrôle de flux : – récepteur/émetteur • Contrôle de congestion: – émetteur/réseau

Le service sans connexion Objectif: le même! • UDP - User Datagram Protocol [RFC 768]:

– Transfert non sécurisé – Pas de contrôle de flux – Pas de contrôle de congestion

Des applications sur TCP: • HTTP, FTP, Telnet, SMTP (email)

Des applications sur UDP: : • streaming, téléconférence, DNS, telephonie sur IP

2

Le cœur du réseau • Des routeurs interconnectés en un réseau maillé • Deux modes principaux de commutation

– circuit switching – packet-switching

La commutation de circuit Réservation des ressources de bout en bout • bande passante, capacité des commutateurs • pas de partage de ressources • performances garanties • nécessite un établissement du circuit

3

TDMA and TDMA Exemple: 4 utilisateurs

FDMA fréquence

temps TDMA

fréquence temps

La commutation de paquets: un multiplexage statistique 10 Mbs Ethernet

A B

multiplexage

C

1.5 Mbs File d’attente de sortie

D

E

Les paquets issus de A et B arrivent aléatoirement Î multiplexage statistique. En TDM chaque station aurait un nombre fixe de “slots” à sa disposition.

4

La commutation de paquets Decoupage du flux entrant en paquets • A et B se partagent les resources du réseau

• chaque paquet utilise la totalité du débit utile • les ressources sont utilisées en fonction du besoin

Contention pour l’usage des ressources : la demande peut excéder l’offre congestion: mise en attente des paquets store and forward :

Pas de division du débit en slots Pas d’allocation fixe de ressources Pas de réservation

Circuit vs Paquet

• Liaison 1 Mbit • chaque application : – 100 kbps si “active” – active 10% du temps

N utilisateurs • circuit : – 10 users • paquet : – 35 utilisateurs , probabilité d’activité > 10 inférieure à 0.0004

1 Mbps

5

Et le MTU? L R • delai = 3L/R

R

R Exemple: • L = 7.5 Mbits • R = 1.5 Mbps • delai = 15 sec

La fragmentation 5000 paquets de 1500 bits

1 msec par lien pipelining: Delai réduit de 15 sec à 5.003 sec

500 paquets de 15000 bits?

6

L’acheminement dans les réseaux paquets • datagrammes : – L’adresse est portée par chaque paquet – les routes peuvent changer pendant la session – optimal? – Traitement de chaque paquet • Circuit virtuel: – chaque paquet transporte une étiquette – le chemin corespondant à l’étiquette est déterminé à l’établissement – les routeurs doivent maintenir une information d’état

Une taxinomie Réseaux

Commutation de circuits

FDM

TDM

Commutation de paquets Circuits virtuels

Datagrammes

• Mode connecté ou non connecté

7

Pertes et retard? Mise en file d’attente dans les tampons • Taux d’arrivée vs débit liaison de sortie et taux de service

Transmission (delai)

A B

Attente (delai) Tampons libres sinon perte

Les quatre causes du retard (1) • 1. Traitement: – contrôle d’erreur – recherche dans les tables

2. attente dépend de la congestion au niveau roiuteur et/ou liaison

transmission

A

propagation

B

traitement

attente

8

Les quatre causes du retard (2) 3. Transmission : • R=débit (bps) • L=longueur paquet (bits) • temps de transmission = L/R

4. Propagation : • d = longueur de la liaison • s = vitesse de propagation sur le medium (~2x108 m/sec) • délai de propagation = d/s

transmission

A

propagation

B

traitement

attente

Le retard sur un nœud d nodal

d proc  d queue  d trans  d prop

• dproc = processing delay – en général d qques P s • dqueue = queuing delay – dépend de la congestion • dtrans = transmission delay – = L/R, • dprop = propagation delay – de quelques P s à quelques centaines de ms

9

Le temps d’attente • R=link bandwidth (bps) • L=packet length (bits) • a=average packet arrival rate

Intensité du traffic = La/R

Exemple : le cas Internet • IP offre un service de type "best effort" • TCP garantit la fiabilité et le séquencement • TCP pratique un contrôle de congestion réactif

Aucune garantie ne peut être apportée pour le transport du trafic temps réel ou multimédia

Pour servir ces applications le réseau doit être doté de mécanisme lui permettant de garantir une QOS appropriée

10

Les principaux problèmes de la gestion de QOS • • • • • •

Contrôle de congestion Contrôle d'admission Réservation de ressources Spécification de la QOS Traduction des objectifs de QOS en paramètres réseau Contrôle des débits et du séquencement

Implique la notion de flux

Contrôle de congestion Contrôle réactif

Contrôle préventif

Congestion puis récupération

Essaie d'éviter la congestion

Récupération par réduction du trafic

Admission du trafic seulement si celui-ci n'est pas cause de congestion Flux et QOS doivent être admissibles

Admet tous les flux Contrôle de flux par le récepteur

Contrôle de débit par fenêtre Pas de réservation de ressource Possibilité d'inondation par un flot

Contrôle de débit (baquet percé) associé avec file d'attente (module QOS des routeurs) Contrôle du débit basé sur le flot Réservation de ressource à l'établissement Isolation des files d'attente par flot (WFQ)

11

Spécification de la QoS • La qualité de service est spécifiée selon les paramètres de l'application – MPEG : 30 fps, 100 ms de délai... • Pn doit en déduire les paramètre de la QoS – 500 pps moyen, 800 pps pic, 100 ms retard, performances garanties... • Ressourecs réseau : bande passante, taille trampons, panier de réservation (b,r), poids, pénalité, fonction de coût... • Ressources système final : mémoire, délais, threading... • Performances globales : débit, utilisation, retard, paramètres d'évaluation...

Principles for QOS Guarantees • Example: 1MbpsI P phone, FTP share 1.5 Mbps link. – bursts of FTP can congest router, cause audio loss – want to give priority to audio over FTP

Principle 1 packet marking needed for router to distinguish between different classes; and new router policy to treat packets accordingly

12

Principles for QOS Guarantees (more) • what if applications misbehave (audio sends higher than declared rate) – policing: force source adherence to bandwidth allocations • marking and policing at network edge: – similar to ATM UNI (User Network Interface)

Principle 2 provide protection (isolation) for one class from others

Principles for QOS Guarantees (more) • Allocating fixed (non-sharable) bandwidth to flow: inefficient use of bandwidth if flows doesn’t use its allocation

Principle 3 While providing isolation, it is desirable to use resources as efficiently as possible

13

Principles for QOS Guarantees (more) • Basic fact of life: can not support traffic demands beyond link capacity

Principle 4 Call Admission: flow declares its needs, network may block call (e.g., busy signal) if it cannot meet needs

Classes de trafic • Trafic élastique • Interactif et transactionnel • Transferts de masse

• Trafic temps réel • Garantie de service • Prédictif

14

Trafic élastique : les problèmes

• Trains de paquet • Variation du temps de transmission (gigue)

Exemple Internet

S

S

S

S

15

Emission du premier paquet

FTP A ADSP B Telnet C

Trains de paquets

FTP A ADSP B Telnet C

16

Scheduling And Policing Mechanisms • scheduling: choose next packet to send on link • FIFO (first in first out) scheduling: send in order of arrival to queue – real-world example? – discard policy: if packet arrives to full queue: who to discard? • Tail drop: drop arriving packet • priority: drop/remove on priority basis • random: drop/remove randomly

Scheduling Policies: more Priority scheduling: transmit highest priority queued packet • multiple classes, with different priorities – class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc.. – Real world example?

17

Scheduling Policies: still more round robin scheduling: • multiple classes • cyclically scan class queues, serving one from each class (if available) • real world example?

Scheduling Policies: still more Weighted Fair Queuing: • generalized Round Robin • each class gets weighted amount of service in each cycle • real-world example?

18

Policing Mechanisms Goal: limit traffic to not exceed declared parameters Three common-used criteria: • (Long term) Average Rate: how many pkts can be sent per unit time (in the long run) – crucial question: what is the interval length: 100 packets per sec or 6000 packets per min have same average! • Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 ppm peak rate • (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle)

Policing Mechanisms Token Bucket: limit input to specified Burst Size and Average Rate.

• bucket can hold b tokens • tokens generated at rate r token/sec unless bucket full • over interval of length t: number of packets admitted less than or equal to (r t + b).

19

Policing Mechanisms (more) • token bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., QoS guarantee! arriving traffic

token rate, r bucket size, b

WFQ

per-flow rate, R

D = b/R max

TCP et le contrôle de flux

20

RTP • Utilisation de UDP – port 5004 • Reconstruction de la base de temps des flux audio et video • Détection des pertes de paquets • identification du type de contenu RTP RTP A/V A/V Profile Profile H.261 H.261 Video Video

MPEG MPEG Video Video

Layered Layered Video Video

PCM PCM Audio Audio

PVH PVH Video Video

LDCT LDCT Video Video

HVQ HVQ Video Video

LPC LPC Video Video

RTP Example • Consider sending 64 kbps PCM-encoded voice over RTP. • Application collects the encoded data in chunks, e.g., every 20 msec = 160 bytes in a chunk. • The audio chunk along with the RTP header form the RTP packet, which is encapsulated into a UDP segment.

• RTP header indicates type of audio encoding in each packet – sender can change encoding during a conference. • RTP header also contains sequence numbers and timestamps.

21

Contributing Source Count

Marker

Padding Extension

Version

RTP Packet Header Payload Format

Sequence Number

Timestamp

Monotonically Increasing Media Specific

Synchronization Source Identifier (SSRC)

Original Source or Mixer Identifier

Contributing Source Identifier (CSRC) ....

Mixers may combine multiple senders

Optional Header Extension

Payload type

22

Le mélangeur RTP

Real-Time Control Protocol (RTCP) • Works in conjunction with RTP. • Each participant in RTP session periodically transmits RTCP control packets to all other participants. • Each RTCP packet contains sender and/or receiver reports – report statistics useful to application

• Statistics include number of packets sent, number of packets lost, interarrival jitter, etc. • Feedback can be used to control performance

– Sender may modify its transmissions based on feedback

23

RTCP - Continued

- For an RTP session there is typically a single multicast address; all RTP and RTCP packets belonging to the session use the multicast address. - RTP and RTCP packets are distinguished from each other through the use of distinct port numbers. - To limit traffic, each participant reduces his RTCP traffic as the number of conference participants increases.

RTCP Packets Receiver report packets: • fraction of packets lost, last sequence number, average interarrival jitter. Sender report packets: • SSRC of the RTP stream, the current time, the number of packets sent, and the number of bytes sent.

Source description packets: • e-mail address of sender, sender's name, SSRC of associated RTP stream. • Provide mapping between the SSRC and the user/host name.

24

Header

RTCP Sender Report V=2 P

Reception Report Count

Packet Type=SR=200

Length

Synchronization Source Identifier (SSRC) of Sender NTP Timestamp, Most Significant Word

Sender Info

NTP Timestamp, Least Significant Word RTP Timestamp Sender’s Packet Count

Maps format specific timestamp to wall clock time. Used to synchronize different media streams.

Report Blocks

Sender’s Octet Count

Report Blocks and Profile Specific Extensions

Report blocks used in both Sender and Receiver Reports

RTCP Reception Report Blocks Synchronization Source Identifier 1 (SSRC_1) Fraction Lost

Cumulative Number of Packets Lost Extended Highest Sequence Number Received Interarrival Jitter Last Sender Report (LSR) Delay Since Last Sender Report (DLSR) Synchronization Source Identifier 2 (SSRC_2) ...

25

RTCP Scalability RTCP Control Traffic (5%)

RTP Data Traffic (95%)

Receiver messages (75%) Sender messages (25%)

• Calculé par l’applicatif – Basé sur une estimation du nombre de participants RTP • Méthode – Envoi sur temporisation aléatoire – Temporisation basée sur le nombre de clients

Exemple

Receiver Reports contain this information

26

Intervalle de retransmission RTCP • Fonction du nombre de membres • Décompte – Entrée dans la table pour chaque source RTP identifiée – Source marquée inactive si 5 intervalles sans messages • Source description (SDES) – certaines informations sont envoyées fréquemment (e.g. name) – d’autres informations sont envoyées à l’initialisation ou à période faible (e.g. email address, phone #)

Messages RTCP • Port 5005 • Packet types – RR: Receiver Report – SR: Sender Report – SDES: Source Description – BYE: End of Participation – APP: Application Specific

27

SIP • Session Initiation Protocol • Comes from IETF SIP long-term vision • All telephone calls and video conference calls take place over the Internet • People are identified by names or e-mail addresses, rather than by phone numbers. • You can reach the callee, no matter where the callee roams, no matter what IP device the callee is currently using.

SIP Services • Setting up a call – Provides mechanisms for caller to let callee know she wants to establish a call – Provides mechanisms so that caller and callee can agree on media type and encoding. – Provides mechanisms to end call.

• Determine current IP address of callee. – Maps mnemonic identifier to current IP address • Call management – Add new media streams during call – Change encoding during call – Invite others – Transfer and hold calls

28

Setting up a call to a known IP address Bob

Alice

167.180.112.24 INVITE bob@ 193.64.210.89 c=IN IP4 16 7.180.112.2 4 m=audio 38 060 RTP/AVP 0

193.64.210.89

port 5060

port 5060

Bob's terminal rings

• Bob’s 200 OK message indicates his port number, IP address & preferred encoding (GSM)

200 OK 9 c=IN IP4 193.64.210.8 /AVP 3 m=audio 48753 RTP AC K

P

port 5060

Law audio

• SIP messages can be sent over TCP or UDP; here sent over RTP/UDP.

port 38060

GSM

time

• Alice’s SIP invite message indicates her port number & IP address. Indicates encoding that Alice prefers to receive (PCM ulaw)

port 48753

time

•Default SIP port number is 5060.

Setting up a call (more) • Codec negotiation:

• Rejecting the call

– Suppose Bob doesn’t – Bob can reject with have PCM ulaw encoder. replies “busy,” “gone,” – Bob will instead reply “payment required,” with 606 Not Acceptable “forbidden”. Reply and list encoders • Media can be sent over RTP or he can use. some other protocol. – Alice can then send a new INVITE message, advertising an appropriate encoder.

29

Example of SIP message INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 167.180.112.24 From: sip:[email protected] To: sip:[email protected] Call-ID: [email protected] Content-Type: application/sdp Content-Length: 885 c=IN IP4 167.180.112.24 m=audio 38060 RTP/AVP 0 Notes: • HTTP message syntax • sdp = session description protocol • Call-ID is unique for every call.

• Here we don’t know

Bob’s IP address. Intermediate SIP servers will be necessary. • Alice sends and

receives SIP messages using the SIP default port number 506. • Alice specifies in Via: header that SIP client sends and receives SIP messages over UDP

Name translation and user locataion • Caller wants to call callee, but only has callee’s name or email address. • Need to get IP address of callee’s current host: – user moves around – DHCP protocol – user has different IP devices (PC, PDA, car device)

• Result can be based on: – time of day (work, home) – caller (don’t want boss to call you at home) – status of callee (calls sent to voicemail when callee is already talking to someone) Service provided by SIP servers: • SIP registrar server • SIP proxy server

30

Etat de l ’art • Largement utilisé – Constituant de l ’applicatif (pas de librairie, DLL…) • Pas de réservation de ressources – fonctionnement de bout en bout • Pas de garantie de délai de livraison ni de sécurisation – utilisation de UDP • En tête minimal de 12 octets – charge utile de 24 octets.

IETF Integrated Services • architecture for providing QOS guarantees in IP networks for individual application sessions • resource reservation: routers maintain state info (a la VC) of allocated resources, QoS req’s • admit/deny new call setup requests: Question: can newly arriving flow be admitted with performance guarantees while not violated QoS guarantees made to already admitted flows?

31

Intserv: QoS guarantee scenario • Resource reservation – call setup, signaling (RSVP) – traffic, QoS declaration – per-element admission control

request/ reply

– QoS-sensitive scheduling (e.g., WFQ)

Call Admission Arriving session must : • declare its QOS requirement

– R-spec: defines the QOS being requested • characterize traffic it will send into network

– T-spec: defines traffic characteristics • signaling protocol: needed to carry R-spec and T-spec to routers (where reservation is required)

– RSVP

32

Intserv QoS: Service models [rfc2211, rfc 2212] Guaranteed service:

Controlled load service:

•

•

•

worst case traffic arrival: leaky-bucketpoliced source simple (mathematically provable) bound on delay [Parekh 1992, Cruz 1988] arriving traffic

"a quality of service closely approximating the QoS that same flow would receive from an unloaded network element."

token rate, r bucket size, b

WFQ

per-flow rate, R

D = b/R max

Définition d ’un flot • “The basic stream construct… is a directed tree carrying traffic away from a source to all destinations.” RFC 1190

33

Définition des flots • Même source – problème de serveur vs micro • Connexion TCP – pas d’identification dans IP – problème des services UDP • Paire source/destination – favorise les stations multitâches

Les données "temps réel"

Gigue Bande passante Retard : un retard trop important rend les données inutilisables Taux de perte incohérent avec la qualité recherchée

34

Resource Reservation Protocol (RSVP)

S'appuie sur IP Datagram transport (UDP) Routage IP (OSPF, BGP-4, Enhanced IGRP, etc.) Routage Multicast (Protocol Independent Multicast) Permet La réservation de bande passante L'échange avec le réseau de politique : Gestion des files d'attente Préférence à l'écartement

Principes de RSVP • Les récepteurs réservent des ressources – adresse de destination, filtre spécifiant les paquets appartenant à la session, spécifications du flot (type de ressource à réserver) • Indépendance par rapport au routage – les sources envoient des messages de chemin vers la destination : les routeurs sur le chemin adopté noteront la réservation

35

Objectifs de RSVP

Données multicast ou unicast Réservation de ressources pour les flux de données unidirectionnels "Soft state" dans les routeurs Changements dynamiques de l'appartenance à un groupe Adaptation automatique au changements de routage Support de la plupart des applications Fonctionnement transparent pour les routeurs non RSVP

Identification des messages

Spécifié par le récepteur (adresse IP unicast ou multicast) Wildcard filters (filtre attrape tout) Sélectionne toutes les sources (mêmes les non actives) Bandwidth du plus grand demandeur ex : audio conférence Fixed filters (filtre fixe) autant de réservations que de sources (ex : tv d’entreprise) Dynamic filters (filtre dynamique) Identifie un besoin potentiel Les réservation sont faites au moment de l’activation de la source ex : visio conf à 2 caméras et n participants

36

Responsabilités de RSVP • Réservation de chemin • Utilisation des algorithme de file d’attente – Qualité de service • Informer les récepteurs des sources actives • Informer les récepteurs de la disponibilité des services demandés

Détection du chemin

37

Installation de la Réservation

Fusion des Réservations

38

Architecture d’un routeur Routing Routing Protocol

Configuration

Queuing Policy Database

Routing Database

Switching Interface 1

Packets In

Packet Scheduler

Packets Out

Route Selection Interface N Packet Scheduler

Packets Out

RFC 1633: Integrated Services in the Internet Architecture: An Overview 621_114/c2 20

Architecture d’un routeur RSVP Flow Request Routing Routing Protocol

Reservation Protocol

Admission Control

Packet Scheduler

Routing Database

Resource Utilization

Queuing Policy Database

Switching Interface 1

Packets In

Packet Scheduler

Packets Out

Route Selection Interface N

Packet Scheduler

Packets Out

621_114/c2 21

39

IETF Differentiated Services Concerns with Intserv: • Scalability: signaling, maintaining per-flow router state difficult with large number of flows • Flexible Service Models: Intserv has only two classes. Also want “qualitative” service classes – “behaves like a wire” – relative service distinction: Platinum, Gold, Silver Diffserv approach: • simple functions in network core, relatively complex functions at edge routers (or hosts) • Do’t define define service classes, provide functional components to build service classes

Diffserv Architecture Edge router:

r marking scheduling

- per-flow traffic management - marks packets as in-profile and out-profile

b

.. .

Core router: - per class traffic management - buffering and scheduling based on marking at edge - preference given to in-profile packets - Assured Forwarding

40

Edge-router Packet Marking • •

profile: pre-negotiated rate A, bucket size B packet marking at edge based on per-flow profile

Rate A B User packets

Possible usage of marking: • •

class-based marking: packets of different classes marked differently intra-class marking: conforming portion of flow marked differently than nonconforming one

Classification and Conditioning • Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6 • 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive • 2 bits are currently unused

41

Classification and Conditioning may be desirable to limit traffic injection rate of some class: • user declares traffic profile (eg, rate, burst size) • traffic metered, shaped if non-conforming

Forwarding (PHB) • PHB result in a different observable (measurable) forwarding performance behavior • PHB does not specify what mechanisms to use to ensure required PHB performance behavior • Examples: – Class A gets x% of outgoing link bandwidth over time intervals of a specified length – Class A packets leave first before packets from class B

42

Forwarding (PHB) PHBs being developed: • Expedited Forwarding: pkt departure rate of a class equals or exceeds specified rate – logical link with a minimum guaranteed rate • Assured Forwarding: 4 classes of traffic – each guaranteed minimum amount of bandwidth – each with three drop preference partitions

43