Scano di Montiferro – Reti di Calcolatori 1 RETI DI CALCOLATORI rucchio/Reti_Scano
Corso di Reti di Calcolatori LS
description
Transcript of Corso di Reti di Calcolatori LS
QoS 1
Corso diReti di Calcolatori LS
Antonio Corradi
Anno accademico 2005/2006
Università degli Studi di BolognaFacoltà di Ingegneria
Variazioni sulla Qualità di Servizio (QoS)
e protocolli per la nuova Internet
QoS 2
Molti indicatori e parametri per connotare un flusso di informazioni e le sue proprietàProntezza di risposta ritardo, tempo di risposta, jitter (variazione ritardo di consegna)
Banda bit o byte al secondo (per applicazione e sistema) Throughout numero di operazioni al secondo (transazioni)
Affidabilità percentuale di successi/insuccessi
MTBF, MTTR
Molti aspetti legati alla qualità del servizio anche non funzionali ma dipendenti dalla applicazione specifica o da fattori esterni e valutabili dall’utente finale
Qualità di ServizioQualità di Servizio
QoS 3
anche proprietà non funzionali dettagli dell'immagine accuratezza dell'immagine velocità di risposta alle variazionisincronizzazione audio/video
la QoS può essere garantita solo attraverso un accordo negoziato e controllato
osservando il sistema in esecuzione e adeguando dinamicamente il servizio alle condizioni operative correnti del sistema e dell’ambiente in base alle specifiche dell’utente
QoS INDICATORIQoS INDICATORI
QoS 4
Proprietà richieste dall’utente finaleImportanza (priorità) QoS percepita (dettagli, accuratezza, sincronizzazione
e qualità audio/video) Costo (per accesso, per servizio) Sicurezza (integrità, confidenzialità, autenticazione,
non repudio)
QoS deve tenere conto di tutti gli aspetti ai diversi livelli del sistema e tenendo conto di tutti i requisiti
L’accordo negoziato deve essere verificato durante la esecuzione per potere fare in modo veloce azioni correttive
QoS INDICATORI UtenteQoS INDICATORI Utente
QoS 5
Banda (throughput) quantità di dati trasmessi su un canale con successo (per secondo)
Ethernet 10Mbps (quantità informazioni/sec) 10 Mbit al secondo
Tempo di latenza tempo impiegato per trasmettere una unità di informazione (bit)
anche tempo di andata/ritorno (Round Trip Time o RTT)
TL = Tprop + Ttx + Tq
Tprop dipende dalla velocità della luce nel mezzo (Spazio / Velocità)
Ttx dipende dal messaggio e dalla banda (Dimensione / Banda)
Tq dipende dai ritardi di accodamento in diversi punti intermedi
Tq tempo critico che tiene conto dell’overhead
Qualità di ServizioQualità di Servizio
QoS 6
Un buon servizio richiede la identificazione dei colli di bottiglia e deve considerare la gestione delle risorse se invio/ricezione di 1 byte dominante la latenza RTTse invio/ricezione di molti MegaByte dominante la banda
Impegno risorse Prodotto Latenza x Banda risorsa canale dati
latenza 40ms e banda 10Mbps prodotto 50 KBps (400 Kbps)è necessario che il mittente invii 50KB prima che il primo bit sia arrivato al destinatario e 100KB prima di una risposta al mittente
Le infrastruttura tendono a mantenere le pipe piene con proprie risorse per la garanzia i tempi di risposta, ma i tempi vanno sempre consideratiSi tende ad incorporare un tempo di buffering nelle applicazioni
Qualità di ServizioQualità di Servizio
QoS 7
JITTER definito come varianza della latenza in un flusso situazione ottimale se la latenza fosse fissa ma…
A volte è significativo anche lo SKEW come eventuale sfasamento tra più flussi visti come un unico stream (esempio, in uno stream audio / video)
Qualità di Servizio - JitterQualità di Servizio - Jitter
QoS 8
In caso di sistemi multimediali, o con flussi continui di informazioni Video on Demand (VoD) erogazione di servizi video via una infrastruttura Internet compatibileperché interesse?
stream di informazioni audio e video con cui giocano fattori real-time: banda, ritardi, jitter, variazioni di ritardo ammissibile
Le entità negoziano certe caratteristiche di qualità per i servizi ripetuti o di flusso e li rispettano- ritardo iniziale per assorbire il jitter medio- scarto dei pacchetti che arrivano oltre un certo ritardo
Interesse alla QoSInteresse alla QoS
QoS 9
TCP/IP CON o SENZA CONNESSIONE le entità comunicano utilizzando le risorse che sono disponibili al momento della azione (dinamico) senza un impegno predeterminato
Il livello di IP è responsabile della semantica best-effort
IN OSIle entità OSI impegnano risorse e possono anche fornire garanzie, che devono essere rispettate da tutte le entità del percorso
Come garantire QoS in TCP/IP in ambienti best effort? Applicazioni per i nuovi servizi di Internet
QoS in DIVERSI AMBIENTIQoS in DIVERSI AMBIENTI
QoS 10
requisiti di qualità delle applicazioni Applicazioni Elastiche e Non Elastiche
CLASSIFICAZIONE APPLICAZIONICLASSIFICAZIONE APPLICAZIONI
elastiche
Interattive
telnet, X-windows
Interattive bulk
FTP, HTTP
Asincrone
e-mail, voce
Tolleranti
Adattative
tradizionali
real-timeapplicazioni
Non elastiche - Real Time
real-timeapplicazioninuove
Non tolleranti
Non-adattative
Adattative in banda
Adattative in banda
Adattative al ritardo
QoS 11
Le elastiche senza vincoli di qualità ma con requisiti diversi indipendenti da ritardi
lavorano meglio con ritardi bassi e lavorano male in caso di congestioneInterattive con ritardi inferiori a 200ms
Le non elastiche hanno necessità di garanzie e del rispetto di vincoli di tempo
poco tolleranti per essere usabili al di fuoridello spazio di ammissibilità richiesto
Il servizio si può adeguare ai requisitiadattative al ritardo audio scarta pacchettiadattative alla banda video che si adatta la qualità
APPLICAZIONI ELASTICHE o MENOAPPLICAZIONI ELASTICHE o MENO
QoS 12
La buona gestione si può ottenere con azioni che devono essere attive per l’intera durata del servizio
Le azioni devono essere sia preventive (preliminari alla erogazione) sia reattive (durante il deployment)sia statiche (preventive), sia dinamiche (reattive)
Azioni statiche decise e negoziate prima della erogazione
Azioni dinamiche identificate durante la erogazione
Sono necessari dei modelli precisi di gestionemodello di monitor e qualità
GESTIONE QoSGESTIONE QoS
QoS 13
Azioni statiche Prima della erogazione
specifica dei requisiti e variazioniDefinizione univoca delle specifiche per i livelli di QoS Si parla di Service Level Agreement (SLA)
negoziazioneAccordo tra tutte le entità e livelli interessati nel determinare QoS
controllo di ammissione (admission control)Confronto tra il QoS richiesto e le risorse offerte
riserva e impegno delle risorse necessarieAllocazione delle risorse necessarie per ottenere il QoS considerato
SLA rappresenta l’accordo statico (come descriverlo?)
GESTIONE QoS: FASE STATICAGESTIONE QoS: FASE STATICA
QoS 14
Azioni dinamiche Durante la erogazione
monitoring delle proprietà e delle variazioni rispettando la politica stabilita
Misura continua del livello di QoS e dei parametri del SLA
controllo del rispetto e sincronizzazioneVerifica del mantenimento e della eventuale sincronizzazione di più risorse (video / audio)
rinegoziazione delle risorse necessarieNuovo contratto per rispettare QoS
variazione delle risorse per mantenere QoS e adattamento a nuove situazioni
Dopo la rinegoziazione si deve controllare di nuovo il rispetto di SLA
GESTIONE QoS: FASE DINAMICAGESTIONE QoS: FASE DINAMICA
QoS 15
Problema del costo della strumentazione per garantire la QoS
Necessità di avere meccanismi di raccolta di dati dinamici e di politiche che non incidano troppo sulle risorse (usate anche dalle applicazioni)
Tutte le corrette gestioni si scontrano con il requisito di impegnare meno risorse possibili
L’area della performance (monitor e gestione dati) deve arrivare a strumenti e politiche che siano meno intrusivi possibile
Principio di minima intrusione
GESTIONE e MONITORAGGIOGESTIONE e MONITORAGGIO
QoS 16
Necessità di accoppiare il piano operativo (o utente) con gli strumenti di controllo della operatività Piano User per protocolli utente
Piano di Management per la gestione, il monitoring, la negoziazione
Piano di Controllo per la connessione e segnalazione tra livelli (in telefonia, della chiamata)
GESTIONE e MONITORAGGIOGESTIONE e MONITORAGGIO
Piano di Controllo
controlplane
userplane
Operazioni Utente
Piano Management
managementplane
Operazioni di monitoring
QoS 17
Aree funzionali di Management dei diversi Standard di gestione• Fault Management• Configuration Management• Accounting Management• Performance Management• Security Management
Vedi OSI di ISOSNMP di IETFTINA di CCITT
GESTIONE e MONITORAGGIOGESTIONE e MONITORAGGIO
areefunzionali
di management
fault
configuration
performance security
accounting
QoS 18
Management Standard OSI (standard durevole)Modello di network management standard basato su oggetti astrattiMappaggio da oggetti astratti a concreti non è standardizzatoad es. le interfacce utente sono non standard ma standard de facto
OSI Distributed ManagementUso di descrizione standard di oggetti e azioni Common Management Information Base (CMIB)Management Information Service (MIS)Management unico delle informazioni Common Management Information Service Element (CMISE)
OSI più sofisticato si applica a qualunque sistema distribuito per la gestione distribuita del sistema
GESTIONE di SISTEMI - OSIGESTIONE di SISTEMI - OSI
QoS 19
Management Standard basato su ruoli
- manager e
- agent che sono responsabili delle risorse gestite
Il modello non impone vincoli a priori e può portare a realizzazioni molto semplici o più complesse
NETWORK MANAGEMENTNETWORK MANAGEMENT
Informazioni di Management Protocollo di
Management
Stazione di Management
Risorsa
Agente
Risorsa
AgenteRisorsa
Agente
Rete
Risorsa
Agente
QoS 20
Management Standard IETFdefinizione di un semplice protocollo di managementSNMP Simple Network Management Protocolusando TCP/IP e usato in ambienti UNIX e LAN
SNMP opera su un sottoinsieme di CMIPincompatibile con lo standard CMIP
variabili che gli agenti controllano in lettura e scrittura
SNMP è passato attraverso molte ridefinizioni e reingegnerizzazioniper tenere conto di esigenze di sicurezzaper tenere conto di modelli di gestione flessibiliper tenere conto di sistemi legacy esistenti…e per potere gestire non solo apparati, ma entità di qualunque tipo
GESTIONE di SISTEMI - SNMPGESTIONE di SISTEMI - SNMP
QoS 21
SNMP Simple Network Management ProtocolSi considera un manager (solamente uno) e degli agenti che controllano variabili che rappresentano gli oggettiIl manager richiede operazioni (get e set) e riceve risposteGli agenti attendono richieste e possono anche inviare trap
Simple Network Management ProtocolSimple Network Management Protocol
requests
responsestraps &
managementstazione di entità
gestita
variabili MIBcomunicazionidi protocollo
AGENTEMANAGER
QoS 22
Si usano messaggi molto semplici e limitati
Set,
Get,
Get_Next
(attributi multipli),
Trap
Indicazioni semplici
Porta 161 messaggi
porta 162 nel manager per trap
Simple Network Management ProtocolSimple Network Management Protocol
oggettigestiti
fetch
store
get / getNext
set
manager
response
response
Porta 161
Porta 161
QoS 23
Struttura di un agente SNMP
Arrivano richieste di azioni di get e set del manager
Si possono generare trap a fronte di eventi
SNMP - AgenteSNMP - Agente
Trap PDU GetResponse PDU
GetRequest PDU GetNextRequest PDU
SetRequest PDU
daemon
trapgenerator generator
response
QoS 24
SNMP - ManagerSNMP - Manager
Struttura di un manager SNMP
Su richiesta arrivano risposte per le azioni di get e set dagli agenti
Si devono gestire i trap degli agenti
Trap PDU GetResponse PDU
GetRequest PDU GetNextRequest PDU
SetRequest PDU
trapdaemon receiver
response
managerpoll
QoS 25
SNMPv1Estrema semplicità e Limitata espressivitàSolo aree di configuration management (fault)Limitata previsione dei trap (azioni iniziate dall’oggetto)
SNMPv2Superamento del C/S con gerarchia di manager agent
SNMPv3Introduzione della sicurezza S-SNMPsi trattano i problemi di integrità delle informazioni (anche stream), masquerading, privacy (prevenire disclosure)non si trattano denial of service e analisi del traffico
In generale, SNMP incorpora le proprietà di gestione di CMIP e CMISE
PROBLEMI DI SNMPPROBLEMI DI SNMP
QoS 26
SNMPv2Concetto di agente proxyEntità che si comporta come agent e anche come manager
superando i problemi detti di micromanagement (ossia di congestione intorno al manager)
PROBLEMI DI SNMPPROBLEMI DI SNMP
NMS
AgenteProxy
AgenteProxy
QoS 27
SNMP gestisce solo gli apparati localie il traffico di rete? Remote MONitorIntrodotte le parti di supporto alla comunicazioneed alle statistiche relativeRMON per aumentare la visibilità dell'utente sul traffico
come facciamo a monitorare la rete?Introduzione di monitor e del protocollo di interazione tra manager e monitor RMON1 sviluppi nel senso della azioni multiple e innestateRMON2 e nel senso della garanzia di sicurezza
PROBLEMI DI GESTIONE RETEPROBLEMI DI GESTIONE RETE
QoS 28
RMON approccio orientato al traffico e non ai dispositiviprobe entità in grado di monitorare i pacchetti sulla reteI probe possono lavorare in autonomia e quindi anche scollegati dal manager fino a tracciare sottosistemi e a riportare informazioni filtrate al manager
RMON e PROBERMON e PROBE
probe standalone
SNMPSNMP
NMS
Switch con probe RMON
QoS 29
Modello Distributed Management basato su entità attive (manager) entità da controllare (oggetti)entità intermediarie (agenti)
anche manager a loro volta in gerarchia
GESTIONE RETE AVANZATAGESTIONE RETE AVANZATA
MANAGER
richieste dioperazioni
processigestionali
AGENT
risposte e
Command Handler
Agent
Object ManagerMIB
GDMO
notifiche
RisorsaFisica
RisorsaFisica
RisorsaFisica
RRisorsa fisica o logica
OGGETTI
GESTITI e
di supporto
MIB
QoS 30
I Manager gestori realizzano le politiche di gestione sulla base di più agenti di loro competenze o di altri manager
Un manager può inserire una risorsa o toglierla dinamicamentedal sistema di gestione
Gli Agenti agiscono su richiesta dei manager per fornire le funzioniservizi di attuazione comandi, raccolta informazionima anche di inserimento risorse, creazione nuovi agenti
Managed Object sono le risorse descritte in termini di oggettiUn oggetto astrae una o più risorse nel sistemarisorse semplici un modem, o complesse più sistemi interconnessi… e se ne possono creare dinamicamente
GESTIONE RETE AVANZATAGESTIONE RETE AVANZATA
QoS 31
Management entity usano il protocollo CMISE/PInsieme di operazioni remote per la comunicazione tra manager ed agenti realizzando un modello dinamico al massimo grado
Set-Modify stabilire, aggiungere o togliere un attributo ad un oggetto
Get / Cancel Get lettura di un attributo ad un oggetto (e revoca lettura)
Action azione su uno o più oggetti
Create/ Delete richiesta di una generazione/ distruzione ad un agente
Event Report invio di un evento notificato dall'agente al manager
Si noti la aggiunta dinamica di attributi, azioni, agenti, e eventiper cambiare la struttura del sistema durante la esecuzione
GESTIONE RETE AVANZATAGESTIONE RETE AVANZATA
QoS 32
Operazioni di Management in OSIper consentire un controllo dinamico
operazioni per creare agenti e nuove azioni
GESTIONE RETE AVANZATAGESTIONE RETE AVANZATA
QoS 33
Specifiche differenziate di servizio più o meno stringenti
best-effort adatto per servizi elastici come i servizi Internet
nessun throughput garantito, ritardi qualunque, non controllo duplicazioni o garanzie di ordine azioni
controlled load simili a best-effort con basso carico ma con
limiti superiori al ritardo servizi elastici e real-time tolleranti
guaranteed load limite stretto al ritardo ma non al jitter
servizi real-time non tolleranti
SERVIZI INTERNET e NUOVI REQUISITISERVIZI INTERNET e NUOVI REQUISITI
QoS 34
IP best-effort
TCP elastico garanzie di ordinamento, unicità, controllo flusso
OSI QoS ottenuto ad ogni livelloNaturalmente, le garanzie di qualità di servizio hanno un costo
Internet in transizione da infrastruttura a basso costo e basse prestazioni a infrastruttura a costi differenziati e prestazioni corrispondenti
Servizi Integrati lavorando a livello di singolo flusso (RFC2210)
Servizi Differenziati aggregando e classificando flussi per diverse qualità (RFC 2475)
http://www.rfc-editor.org/
SERVIZI e NUOVI REQUISITISERVIZI e NUOVI REQUISITI
QoS 35
Evoluzione dei protocolliNuovi protocolli per adeguare Internet per ottenere il controllo delle operazioni e risorse compatibilmente con le proprietà best-effort
RSVP => Resource Reservation Setup Protocol(RFC 2205) protocollo per riservare e garantire risorse sui nodi intermedi
RTP => Real-Time Protocol(RFC 1889) formato di messaggi generali in datagrammi UDP invio affidabile
RTCP => Real-Time Control Protocolsegnalazione e controllo per mantenere QoS negoziato
NUOVI PROTOCOLLINUOVI PROTOCOLLI
managementplane
userplane
RTP
RTCPRSVP
QoS 36
Traffic Management Per un buon servizio, è necessaria la gestione del traffico tipicamente attuata dai nodi router che si occupano del traffico stesso (in best-effort) Router devono gestire code e traffico
Scheduling e queue managementil router deve mandare i pacchetti considerando i diversi flussi mantenendo QoS al momento giusto
Router devono mantenere stato per differenziare i flussi
Sono necessarie forme di gestione delle code
ESTENSIONI per QoSESTENSIONI per QoS
QoS 37
Il Router passa i pacchetti senza diversificare accodamenti o scheduling senza nessuna distinzione tra i flussiil router esegue per ogni pacchetto che arriva in coda FIFO:1) Verifica della destinazione2) Accesso alle tabelle di routing per trovare un cammino di uscita3) Selezione del migliore percorso in uscita per il pacchetto tenendo conto del match più adatto (massima lunghezza di match)4) Invio del pacchetto attraverso la interfaccia selezionata dal cammino scelto
ROUTER INTERNETROUTER INTERNET
code outputcode input
SchedulerPolitica routing
Tabelle routing
PacketClassifier
SwitchingFabric
BufferOutput
QoS 38
Router in Internetil router passa i datagrammi senza considerare la lunghezza o destinazione/sorgenteIl normale modo di lavoro è FIFO, unica coda per tutti i flussi: questo impedisce qualunque servizio differenziato
Politica semplice e code unificateUn pacchetto in arrivo (di qualunque lunghezza) potrebbe impegnare il router e bloccare ogni altro flussoNon possiamo risparmiare risorse per flussi che ne possano avere bisogno
ROUTER INTERNETROUTER INTERNET
coda output
code input
QoS 39
Il Router considera politiche per accodamenti o scheduling basate sulla lunghezza o destinazione/sorgente dei pacchetti (differenziando i flussi)
il router può prevedere anche, oltre al classificatore dei pacchett in base al flusso (sorgente/destinazione e lunghezza), anche una funzionalità di condizionamento del traffico che può decidere anche di buttare via o ritardare pacchetti
ROUTER per QoSROUTER per QoS
code outputcode input
Scheduler
Politica routing
Tabelle routing
PacketClassifier
SwitchingFabric
BufferOutputConditioner
Traffic
Traffic Conditioner
Controllore / Misuratore
Marcatore Dropper/Shaper
QoS 40
Router con caratterizzazione del trafficoil router deve conoscere i flussi e il servizio possibile (capacità del router) e deve potere gestire il traffico
Modello LEAKY BUCKET per modellare un servizio ATTIVO del router e limitare il flusso in uscitaPossiamo controllare dei flussi attraverso la capacità:
Se arrivano dati oltre la capacità vengono persi (best-effort) Se arrivano dati troppo velocemente oltre il flusso in uscita ammissibile, vengono rallentati (best-effort)
ROUTER per QoSROUTER per QoS
secchio che perde
coda output
coda inputlimitare il flusso uscita
capacità C
flusso di ingresso R
flusso uscita r
QoS 41
LEAKY BUCKET per caratterizzare il trafficor flusso massimo di uscita, R flusso medio di arrivoLEAKY BUCKET spegne i burst di pacchettiUn pacchetto accodato solo se c’è posto nel secchio (altrimenti scartato) e dipende dalla capacità del secchio C I pacchetti possono uscire con velocità massima che dipende dal flusso ammesso in uscita (r < R)Se 100Mbyte in 300msec e se ne fanno uscire a 33Mb/sec il leaky regola il flusso portandolo a quello ammissibile Se 150Mbyte in 300msec, cominciamo a perdere dati ( 50Mbyte)
c = 100Mbyter = 33Mb/sec
LEAKY BUCKETLEAKY BUCKET
QoS 42
TOKEN BUCKET come modello del traffico in cui i flussi hanno storia: il secchio accumula token che servono per il passaggio dei pacchetti
TOKEN BUCKET permette anche alcuni burst di pacchettiDati oltre la capacità non vengono persi ma solo ritardati
Se arrivano dati troppo velocemente oltre il flusso in uscita ammissibile, possono anche uscire per accumulo dei token
Se il bucket è vuoto attesa e non si passa
Se il bucket è pieno si possono impegnare tutti i token
Se parzialmente pieno qualcosa può passare, il resto aspetta
TOKEN BUCKETTOKEN BUCKET
secchio che perde
coda outputcoda input
flusso uscita r
capacità C
flusso di ingresso R flusso uscita r
QoS 43
Modello TOKEN BUCKET per il servizio del router con variazioni e politiche diverseAttesa di un numero di token congrui e invio di tutti i bit insieme del pacchettoIl pacchetto non viene scartato se non contenibile, ma si ha un effetto di ritardare l’invio del pacchetto
ROUTER per QoSROUTER per QoS
r token per secondo
C token
<= R bps
regolazionet
bit
C*R/(R-r)
flusso R
flusso r
r uscita
QoS 44
TOKEN BUCKET impone vincoli sui flussi, inteso come ritardo, tenendo conto dei flussi e richiedendo risorse di bufferizzazione, per l’uscita dal router
SERVIZIO - QoSSERVIZIO - QoS
Router rR
Rin(t) = processo di arrivo
dati arrivati fino all’istante t
rout(t) = processo di uscita
dati serviti fino all’istante t
bit
t
ritardo
buffer
QoS 45
Politiche sui router: i router possono lavorare secondo una politica di conservazione del lavorolegge di conservazione di Kleinrock: il router non può essere idle se ci sono pacchetti da portare in uscita (router work-conservative)
(non si possono introdurre ritardi sul traffico in alcun modo)Se ci sono n flussi con traffico n per ogni flusso, e se il flusso n ha un tempo di servizio medio n, allora l’utilizzo è dato da n=nn dove
n rappresenta l’utilizzo medio di quel flusso, mentre
qn indica il tempo di attesa medio per il flusso nLa legge di Kleinrock per scheduler work-conservative verifica
nqn = Costantecioèsi può dare o un ritardo minore o una maggiore banda a un flusso, solo se facciamo crescere il ritardo di un altro o facciamo diminuire la banda di un altro
POLITICHE per ROUTER con QoSPOLITICHE per ROUTER con QoS
QoS 46
Router Internet - First Come First Serve o FIFO - lavorano rispettando la legge di conservazione di Kleinrock
Per dare priorità ad un flusso si devono sfavorire gli altriSi tendono a pensare e sperimentare altre politiche
Scheduling e Accodamento con rispetto di alcune proprietà Facilità implementativa
per consentire progetto dei router e realizzabilità effettivaGiustizia (fairness) e Protezione
in condizioni operative uguali nessun flusso deve ricevere meno di altri
Limiti di performance come vincoli sulla corretta operatività dei diversi flussi
Admission Control come decisione di ammissione prima della erogazione
POLITICHE per ROUTER con QoSPOLITICHE per ROUTER con QoS
QoS 47
Max-Min FairnessCriterio generale per rispondere alla proprietà di fairness,spesso implementato con una politica più facile da realizzare
Max-min share le richieste di risorse dei diversi flussi devono essere considerate in ordine di richieste crescenti (prima quelli con esigenze minori poi quelli con esigenze superiori)C capacità massima globale di risorse
Xn richiesta di risorse del flusso n X1 < X2 < X3 < … Xi < … XN-1 < XN
mn risorse allocate al flusso n con successo precedentemente
Mn risorse disponibili al flusso n
mn = min (Xn, Mn) e
Si possono anche considerare pesi diversi per i diversi flussi
POLITICHE FAIRPOLITICHE FAIR
1nN
mCM
1n
1i in
QoS 48
Nel modello Max-Min facciamo passare prima chi fa richieste meno gravose e poi gli altri successivamente in ordine di peso delle richieste
Generalized Processor Scheduling (GPS)Modello fluido del traffico
Questo criterio risponde ad un servizio Round Robin molto fairAd ogni giro si serve un solo bit per flusso che viene portato in uscita
Si potrebbe dimostrare che questa politica di scheduling è ottima per i servizi
Purtroppo il GPS NON è praticamente implementabile
Si possono servire solo pacchetti e non bit (overhead)Se ne fanno delle approssimazioni facili da implementare
GENERAL. PROCESSOR SCHEDULINGGENERAL. PROCESSOR SCHEDULING
QoS 49
Strategie alternative a FCFSForme di Queue Scheduling (anche non work-conservative) per evitare che un flusso eccessivo non controllato possa congestionare l’intero traffico e tutti i flussi Scheduling con Priorità
politica di accodamento e scheduling facili da implementare Un flusso prioritario può causare starvation di un flusso meno prioritario
POLITICHE di SCHEDULINGPOLITICHE di SCHEDULING
QoS 50
Round Robin flussi serviti dalla politica di gestione in round-robin (se hanno traffico). Serviamo ripetutamente traffico di un flusso se è l’unico presente
Weighted Round RobinI flussi sono serviti in round-robin in proporzione a un peso assegnato ad ogni flusso e ogni coda è visitata per ogni giro una volta sola e per un solo pacchetto per servizioIl peso normalizzato difficile da valutare per flussi corti
POLITICHE di SCHEDULINGPOLITICHE di SCHEDULING
QoS 51
Deficit Round RobinOgni flusso mantiene un valore di stato (deficit a zero) Alla visita della coda, il pacchetto è estratto se minore di una certa soglia, altrimenti non estratto ma registrando storicamente nel deficit la attesa (aumentando il deficit di un quanto)
I pacchetti anche oltre la soglia passano dopo una attesa opportuna
Funziona bene per pochi flussi e piccoli pacchetti
Ci sono molte altre variazioni del Round Robin con prestazioni diverse e algoritmi vari di costi diversi
POLITICHE di SCHEDULINGPOLITICHE di SCHEDULING
QoS 52
Fair Queuing e variazioniRound-Robin fatto bit-a-bit
Un pacchetto di un flusso di dimensione N può essere inviato solo dopo avere visitato le altre code N volteNon si mandano però i messaggi un bit alla volta, ma usando tag di fine per ogni coda per tenere conto del pacchetto che deve uscire per primo (quello che avrebbe completato per primo il servizio bit-a-bit)
Anche altre variazioniWeighted Fair Queuing con peso diverso associato ai flussi
NON CONOSCENZA del TRAFFICO IN ARRIVOil problema è non sapere alla trasmissione di un pacchetto cosa stia arrivando sui flussi che si dividono le risorseSoluzione: inserire stato nel sistema intero
POLITICHE di SCHEDULINGPOLITICHE di SCHEDULING
QoS 53
Una delle situazioni più spiacevoli dei sistemi best-effort
Congestione in cui nessuno lavora più correttamenteSpesso affrontata con politiche semplici
In Internet tradizionale best effortsi possono fare solo azioni reattive
scartare solo i pacchetti in eccesso (in modo silenzioso) oppure mandare indicazioni di limitare il traffico (pacchetti choke)
Nella nuova Internet con QoS con varie strategiesi possono fare anche azioni preventive
Ad esempio un uso della finestra di trasmissione su un canaleo altro che prevenga situazioni pericolose
PREVENZIONE della CONGESTIONEPREVENZIONE della CONGESTIONE
QoS 54
RANDOM EARLY DETECTION (o RED)
una coda per ogni flusso, code con uguale priorità con una forma di
prevenzione della congestione che prevede uno scarto random dei
pacchetti, da prima che si possa arrivare alla congestione
Ci sono molte variazioni: i pacchetti sono scartati in modo random tanto più quanto le code si allungano
RED definisce lunghezza minima e massima e media di codaSe coda < soglia minima nessuna azioneSe coda > soglia massima nuovi pacchetti scartatiAltrimenti scarto con probabilità crescente con lunghezza coda
POLITICHE PROATTIVE: REDPOLITICHE PROATTIVE: RED
QoS 55
Servizi Integrati INTSERV (RFC2210)Supporto al QoS a livello applicativo con la distinzione dei flussiL'idea dei servizi integrati è quella di definire e mantenere un certo livello di servizio per uno specifico flusso in un certo dominio di amministrazione o anche in uno scenario globale, sia best effort, sia real-time
Una applicazione richiede un certo livello di servizio (SLA) specificato usando una interfaccia opportuna e un protocollo di segnalazioneIl supporto verifica che il servizio si possa fornire (controllo di ammissibilità) e accetta di fornirlo
Le applicazioni non si occupano direttamente del protocollo la cui garanzia deve essere ottenuta a basso livello in modo opportunodel protocollo locale si devono occupare i livelli bassi (di rete) in INTSERV
Servizi Integrati per QoSServizi Integrati per QoS
QoS 56
IntServicesPrincipio di baseNella erogazione dei diversi flussi, si deve cambiare il punto di vista
I flussi sono considerati uno per uno (con SLA)
Per ogni flusso, si devono considerare non solo gli endpoint ma anche tutti i cammini che permettono il passaggio e devono fornire risorse e attivarsi
In genere il servizio prevede un iniziatore attivo (ricevente) e un fornitore del servizio (provider) che devono poi essere collegati dal cammino più adatto alla fornitura del servizio stesso
Servizi Integrati per QoSServizi Integrati per QoS
QoS 57
RSVP Reservation ProtocolIl protocollo specifica come riservare le risorse necessarie a garantire un certo livello di servizio in modo del tutto separato dal traffico corrente sui canali
Il ReSerVation Protocol provvede alla gestione attraverso informazioni di traffico che sono inviate dal ricevente di un servizio e trattate su sua iniziativa da tutti i nodi del cammino attivo per ottenere il servizio stesso (in direzione dal ricevente al mittente)
Messaggi: Resv, Path, ResvTear, PathTear, ResvErr, PathErr, …
Negoziazione delle FlowSpec (Specifiche di Flusso)
* TSpec (descrizione del traffico) inviate sulla rete dal ricevente
* AdSpec (opzionale) conferma la reservation al ricevente
* riserva le risorse in modo unidirezionale
RSVP - Reservation ProtocolRSVP - Reservation Protocol
QoS 58
RSVP (RFC 2205) come parte di INTSERVRSVP Protocollo a due passi, con soft state in cui il ricevente di un servizio cerca di prenotare le risorse di cui ha bisogno per la durata del servizio stesso
In modo indipendente da eventuali multicast o unicast di routing
In modo non permanente ma per un intervallo (da rinfrescare) soft-state
Si possono riservare risorse in modo condiviso o fissato (con possibili ottimizzazioni per la condivisione)
RSVP - Reservation ProtocolRSVP - Reservation Protocol
messaggi
RSVPcontrolloammissione
messaggi classificatore schedulertrafficoapplicativi
di RSVP
RTP e RTCP
QoS 59
RSVP Protocollo a due fasi con messaggi di Path e Resvreceiver: messaggio Resv -
TSpec (+ RSpec) in broadcast
sender: messaggio Path
Si può rispondere con PathTear
o time-out
sender: PathTear
receiver(s): ResvTear
refresh del soft-state usando altri Path e Resv
• Uso di broadcast dove necessario con alto costo
• I nodi mantengono il soft-state fino alla prossima reservation
• I cammini e le risorse sono prenotate in modo condiviso o meno
RSVP - Reservation ProtocolRSVP - Reservation Protocol
SA
BPathResv
mergepoint
QoS 60
RSVP le fasi si propagano in contemporanea
RSVP - Reservation ProtocolRSVP - Reservation Protocol
QoS 61
RSVP introduce l'idea di lasciare la responsabilità di riservare risorse al livello di applicazione
Per il protocollo a due passi una reservation può bloccarne un'altra producendo ResvErrLo stato deve essere mantenuto per ogni ricevente e si produce traffico per ogni rinfresco dello stato
Inoltre, si possono fornire solo livelli di servizio compatibili per riceventi diversi
Eventi da considerare:
In caso di router failure, la QoS può anche degradare fino a best-effort in questo caso è necessario rinegoziare QoS
Applicazioni e router devono sapere che si usa RSVP e si possono riscontrare problemi con applicazioni legacy Al momento viene raccomandato solo per reti locali ristrette e non per ambienti globali
Anche altri approcci
RSVP - Reservation ProtocolRSVP - Reservation Protocol
QoS 62
Protocolli di supporto al QoS a livello applicativo
Considerando come trasporto il solo protocollo UDP si costruiscono nuovi protocolli a livello di singolo flusso
RTP Real-Time Protocol (RFC1889)
RTCP Real-Time Control Protocol
che non garantiscono QoS, ma rendono possibile un controllo della QoS durante la erogazione del servizio stesso rendendo alcuni indicatori disponibili a livello della applicazione
attraverso una accresciuta visibilità a livello applicativo
Per la erogazione del flusso, e per tutta la durata
I messaggi sono mandati in banda con numeri progressivi
RTP messaggi di marking del traffico e applicativi
RTCP messaggi di gestione della connessione astratta
Supporto al QoS al livello applicazioneSupporto al QoS al livello applicazione
QoS 63
Protocolli di supporto al QoS a livello applicativo
• I flussi di informazione sono mandati dal sender attraverso una connessione di livello applicativo
• I singoli pacchetti (frame) sono identificati con tag numerati successivamente e possono anche essere riconosciuti dai classificatori dei diversi router
• In caso di pacchetti mancanti, si suggerisce una interpolazione dei precedenti
• Si possono fornire indicazioni di tempo di passaggio per le diverse posizioni del cammino tra mittente e ricevente
• Si prevedono anche formati differenziati nella parte dati dei datagrammi per andare incontro alle esigenze delle diverse applicazioni
RTP e RTCP per QoSRTP e RTCP per QoS
QoS 64
Real-Time ProtocolRuolo attivo sia per il sorgente sia per mescolatori (mixer) che possono incidere sul protocollo
Gli intermediari possono lasciare traccia ed intervenire sul messaggio, per consentire di mantenere le garanzie attraverso informazioni aggiunte sui messaggi applicativi
RTP
I nodi intermedi (come sorgenti addizionali) possono inserire informazioni che servono per qualificare ulteriormente ogni consegna di informazioni
Il cammino diventa un insieme di sorgenti per ogni nodo di passaggio
Si possono anche considerare cammini condivisi che prevedono quindi grafi più complessi con nodi di congiunzione
RTP - Real-Time ProtocolRTP - Real-Time Protocol
QoS 65
Real-Time Protocol - varie sorgenti
RTP - Real-Time ProtocolRTP - Real-Time Protocol
SSRC = mixerCSRC1 = s1CSRC2 = s2CSRC3 = s3
SSRC = s1
SSRC = s2
SSRC = s3
s1
s2
s3mixer
SSRC = s1
s1
SSRC = s1
translator
V 2-bit, numero versione (=2)P 1-bit, paddingX 1-bit, indica extension di header CC 4-bit, numero di CSRC (CSRC count)M 1-bit, marker specifico per profiloPT 7-bits, payload type, specifico del profiloSSRC synchronisation sourceCSRC contributing source
timestamping in unità specifiche di profilo/flusso
P X M
31160
aggiuntodal mixer
CC
SSRC
PT sequence number
CSRC
timestamp
V
QoS 66
Real-Time Control Protocol
deve fornire informazioni di controllo sul flusso di dati applicativo con informazioni sullo svolgimento della erogazione
attraverso nuovi messaggi di controllo inviati insieme al traffico
I messaggi di RTCP possono viaggiare nelle due direzioni e permettono di propagare informazioni a tutti ipertecipanti, nei due versi, sia relativi alla normale operatività sia ad eventi eccezionali
QoS per flussoinformazioni sui pacchetti: perdite, ritardi, jitter
informazioni di end system: utente
informazioni di applicazione: specifiche di flusso applicativo
RTP - Real-Time ProtocolRTP - Real-Time Protocol
QoS 67
RTCP Protocollo aggiunto a RTP per la gestione dei flussi di RTP
non trasporta dati applicativi ma solo informazioni di controllo del flusso corrente per RTP
deve fornire informazioni sintetiche sui parametri dei flussi, tipo ritardo, banda, jitter, ecc.
uso di messaggi tipati
RR / SR Receiver / Sender Report
SDES Source Description
BYE Abort di sessione
APP Specifica di applicazione
Spesso il protocollo RTCP è vincolato ad operare in banda rispetto a RTP e viene contenuto in overhead, limitandone l’impegno di banda
RTCP - Real-Time Control ProtocolRTCP - Real-Time Control Protocol
QoS 68
Messaggi di tipo RR e SR (Receiver / Sender Report)
RTCP - Real-Time Control ProtocolRTCP - Real-Time Control Protocol
V P 31160
RC
NTP timestamp, hi-word
PT=SR length
NTP timestamp, lo-word
SSRC of sender
RTP timestamp
sender’s packet count
sender’s octet count
cum. no. of pkts lost
ext. highest seq. n. recv’d
inter-arrival jitter
frac. lost
SSRC1 (SSRC of source 1)
last SR NTP timestamp (part)
delay since last SR
V P 31160
RC PT=RR length
SSRC of sender
cum. no. of pkts lost
ext. highest seq. n. recv’d
inter-arrival jitter
frac. lost
SSRC1 (SSRC of source 1)
last SR NTP timestamp (part)
delay since last SR
Anche più istanzeripetute in un report
QoS 69
Messaggi di tipo SDES
Source DEScription stringhe ASCII
* CNAME: canonical identifier (mandatory)
* NAME: user name
* EMAIL: user address
* PHONE: user number
* LOC: user location, application specific
* TOOL: name of application/tool
* NOTE: transient messages from user
* PRIV: application-specific/experimental use
RTPC - Real-Time Control ProtocolRTPC - Real-Time Control Protocol
QoS 70
Messaggi di tipo BYEBYE consente di lasciare una sessione RTP
Per un SSRC (o SSRC e lista CSRC se mixer)
Fornendo un suggerimento sulle ragioni dell’abbandono
Messaggi di tipo APPAPP definisce pacchetti application-specific
Per un SSRC (or SSRC e lista CSRC se mixer)
ASCII stringhe ‘for name of element’ come dati application dependent
Il flusso prima della erogazione viene sottoposto
a ritrovare il cammino ed a riservare risorse con RSVP
poi durante il provisioning viene associato a RTP e RTCP
RTCP - Real-Time Control ProtocolRTCP - Real-Time Control Protocol
QoS 71
Protocolli di Streaming Real Time Streaming Protocol (RFC 2326)integrazione di uno streaming acceduto via Web e trasportato fino al cliente (RealPlayer) Si parte, dopo avere scaricato la specifica del file
Il player contatta il server via UDP o TCP cercando di ottenere il migliore adattamento sfruttando il buffering
Il ricevente non aspetta di avere scaricato l’intero brano (tutti i frame), ma mantiene un buffer di riproduzione con almeno alcuni frame presenti
se UDP, aspetta 2-5 secondi e poi comincia a mostrare
se TCP, deve usare un buffer più ampio
Politiche a pull e push sul server con tecniche di watermark per la sincronizzazione (soglia)
Si usano anche tecniche di interleaving per ovviare a perdita di pacchetti
RTSP - Real-Time Streaming ProtocolRTSP - Real-Time Streaming Protocol
QoS 72
Si considera come intervenire sul routing per ottenere garanzie (RFC1889) sui flussi come stream di byte Nuove organizzazioni per qualità pensate per localitàlocalità costituita da nodi interni e da nodi di confine
ESTENSIONI per QoSESTENSIONI per QoS
misuratore
dropper/shaper
traffic conditionerspacketclassifier
meter
marker dropper/shaper
packets control information
marcatore
QoS 73
Misurazione del profilo di trafficouso di profili: in-profile, out-of profile
per decidere come trattare il trafficoanche re-marking (nuovi DS codepoint) per condizionare / ricondizionare il traffico
Possibilità di avere Shaper Dropper sui pacchetti
ESTENSIONI per QoSESTENSIONI per QoS
meter
marker dropper/shaper
traffic conditionerspacketclassifier
meter
marker dropper/shaper
packets control information
QoS 74
Servizi Differenziati (DIFFSERV RFC 2474, 2475, …)
L'idea è di differenziare i servizi offerti in classi diverse con caratteristiche di scalabilità
I servizi differenziati sono lasciati ad un dominio specifico di applicazione e un gruppo di IETF sta definendone diversi
I servizi sono a livello di utenti e di comunità di utenti e di utilizzo più facile degli INTSERV ed adatti per applicazioni legacy
I pacchetti sono marcati a livello di rete (non a livello applicativo) e sono riconosciuti e trattati dai router in modo aggregato e diretto
NON si lavora per ogni flusso di informazioni, ma
aggregando classi di flussi
DIFFSERV (Servizi Differenziati)DIFFSERV (Servizi Differenziati)
QoS 75
Si definiscono e si usano classi di servizio diverse: ad esempio
* premium (basso ritardo)
* assured (alta velocità, bassa perdita di pacchetti)
e anche
* oro
* argento
* bronzo
La classificazione viene fatta all'ingresso del pacchetto sulla base del contenuto del pacchetto stesso
Service Level Agreement (SLA) basato sulla classificazione
Politica di servizio concordata tra utente e server, e servizio fornito dalla rete con politiche assicurate dai router
DIFFSERV (Servizi Differenziati)DIFFSERV (Servizi Differenziati)
QoS 76
Classi di servizio RFC3246 expedited forwardingExpedited forwarding vs. Regular
I router devono mantenere almeno due code differenziate e garantire la consegna dei pacchetti expedited
Nel caso Expedited PHB bassa perdita, basso ritardo, basso jitter
Si crea una connessione punto a punto tipo virtual leased line tra endpoint
Service Level Agreement (SLA) (tipo 80 –20)
I pacchetti devono ricevere almeno un Weighted Fair Queuing
Classi di servizio RFC2579 assured forwardingQuattro classi di priorità con tre livelli di congestione (basso, medio, alto)
I diversi pacchetti devono essere marcati a trattati in modo differenziato
DIFFSERV (Servizi Differenziati)DIFFSERV (Servizi Differenziati)
QoS 77
DIFFSERV possono usare molti modi per differenziare i servizi
il più praticabile sembra essere il byte DS nell'header di ogni pacchetto
(Type of Service, o ToS, in IPv4)
packet marking nel DS byte
IPv4 ToS byte
IPv6 traffic-class byte
classificatori di traffico basati su
multi-field (MF): DS byte + other header fields
aggregazioni di behavior (BA): solo DS field
DS codepoint dipendenti dalla applicazione
Si tentano Per-hop behaviour (PHB) aggregando flussi nella rete
DIFFSERV (Servizi Differenziati)DIFFSERV (Servizi Differenziati)
QoS 78
I classificatori di traffico lavorano nella selezione dei pacchetti sulla base delle informazioni contenute negli header, nel modo più ampio possibile
Si possono anche considerare
* le porte,
* il tipo di protocollo,
* il tipo di reservation,
* ...
Però DIFFSERV presentano ancora limiti rispetto a quello che si può ottenere con RSVP e i servizi integrati
DIFFSERV (Servizi Differenziati)DIFFSERV (Servizi Differenziati)
QoS 79
INTSERV e DIFFSERV insieme
Al momento sono in fase di sviluppo sia i protocolli di tipo differenziato, sia di tipo integrato
anche se i servizi differenziati sembrano essere più scalabili e fornire prestazioni anche a servizi legacy
Naturalmente, i router devono fornire i nuovi servizi
Nuove Proposte DIFFSERVNuove Proposte DIFFSERV
Internet
INTSERV
DIFFSERV
QoS 80
Internet Protocol v6 (IPv6)nuove proposte di sistemi di routing e di nomi a fronte dell'esaurimento degli indirizzi IP
solo 2,11 M reti (alcune classi C libere), 3,72 G connessioni
IPv6 => 128 bit / 16 byte forte estensione del sistema
mantenendo anche compatibilità con IPv4 (7 1023 indirizzi per metro2)
X:X:X:X:X:X:X:X dove X sta per una word a 16 bit
0:0:0:0:0:0:137.204.57.33 o ::137.204.57.33
La scelta è nata dopo discussioni e varie proposte con obiettivi diversi:
Facilitare multicast, roaming, sicurezza, QoS, … limitare routing table e rendere routing efficiente
Permettere evoluzioni e coesistenza
IPv6IPv6
QoS 81
Internet Protocol v6 (IPv6)
Gerarchia di indirizzi divisi per forniture di servizi e indirizzi geografici, e per usi locali e non visibili
Inoltre, si riconoscono funzionalità per:
* point-to-point
* multicast
* anycast (il più vicino o più comodo di un insieme di destinatari)
Con attribuzioni parziali
0: IPv4
1: OSI
2: Novell
...
255: Multicast
IPv6IPv6
QoS 82
Internet Protocol v6 (IPv6)
L'header del messaggio è più limitato e fisso
senza variazioni (8 byte) a parte gli indirizzi del mittente e destinatario
solo in caso di necessità si punta ad eventuali header di estensione
Nessuna frammentazione e checksum
IPv6IPv6
VERS PRIO FLOW LABEL PAYLOAD LENGTH NEXT HEADER HOP LIMIT
SOURCE IP ADDRESS (128 bit)
DESTINATION IP ADDRESS (128 bit)
0 4 8 16 19 24 31classe
traffico
PAYLOAD (preceduto da altri header)
QoS 83
PRIO Type of Service (ToS) 0-7 best effort 8-15 Streaming e QoS
FLOW LABEL 24 bit tiene traccia di flussi nei diversi cammini
PAYLOAD minima 536 massima 64K
NEXT HEADER (type length value)
uso di estensioni segnalati con header aggiunti
hop by hop (jumbo)routingfragmentauthenticationencapsulating security payloaddestination options
HOP LIMIT tipo il time to live (IPv4)
HEADER - IPv6HEADER - IPv6
VERS PRIO FLOW LABEL PAYLOAD LENGTH NEXT HEADER HOP LIMIT
SOURCE IP ADDRESS (128 bit)
DESTINATION IP ADDRESS (128 bit)
0 4 8 16 19 24 31classe
traffico
PAYLOAD (preceduto da altri header)