Tuesday

Lezione Sopra Internet Monitoring & PingER presso SLAC

Home page di IEPM | PingER | Rapporti dettagliati di PingER | Mappa del sito di PingER | Lezione
Lavoro parzialmente finanziato da un sussidio di lavoro sul campo DOE / MICS per Monitoraggio delle prestazioni end-to-end di Internet (IEPM).


Contenuto della pagina Web
Ping dei nodi dei collaboratori


  • Qualità
  • Ritardo - Importanza del ritardo.
  • Perdita - Soglie di qualità; Definizioni ITU; Relazione con il VoIP; Definizioni meteo MCI e Internet; Distribuzioni di perdita.
  • Jitter - definizioni ITU; Definizione di ping jitter; Confronto tra jitter a una e due vie.
  • Utilizzo Utilizzo e perdita, salute della rete e variazione RTT.
  • Throughput
  • SLA Raggiungibilità e disponibilità
  • Direttività
  • Raggruppamento Possibili gruppi di coppie; Distribuzioni di gruppo; Siti Beacon.
  • Senso Unico misure progetti: Surveyor, Confronto di PingER & Surveyor, RIPE, NIMI, Waikato e Sting; Relazione a due vie. RFC IETF rilevanti.
  • Traceroute

Introduzione

Per fornire una migliore aspettativa delle prestazioni della rete tra i siti con cui collabora SLAC, nel maggio 1996 il progetto PingER (avviato nel gennaio 1995) ha monitorato circa 100 host in tutto il mondo da SLAC. Dal 2000, l'enfasi è più sulla misurazione del Digital Divide. Al giorno d'oggi (aprile 2007) ci sono oltre 35 siti di monitoraggio, oltre 600 siti remoti monitorati in oltre 150 paesi (contenenti oltre il 99% della popolazione connessa a Internet di mondi) e oltre 8000 coppie di siti remoti del sito di monitoraggio inclusi. Maggiori dettagli sulla distribuzione di PingER possono essere trovati in PingER Deployment e c'è una mappa dei siti.

Meccanismo

Il meccanismo principale utilizzato è il meccanismo Echo di Internet Control Message Protocol (ICMP), noto anche come funzione Ping. Ciò consente di inviare un pacchetto di una lunghezza selezionata dall'utente a un nodo remoto e farlo tornare indietro. Oggi di solito viene preinstallato su quasi tutte le piattaforme, quindi non c'è nulla da installare sui client. Il server (vale a dire l'echo reponder) viene eseguito ad alta priorità (ad esempio nel kernel su Unix) e quindi è più probabile che fornisca una buona misura delle prestazioni della rete rispetto a un'applicazione utente. È molto modesto nei suoi requisiti di larghezza di banda di rete (~ 100 bit al secondo per monitoraggio-host-remoto-coppia per il modo in cui lo usiamo).

Metodo di misurazione

Nel progetto PingER, ogni 30 minutescron da un nodo di monitoraggio (Measurement Point - MP), eseguiamo il ping di un set di nodi remoti con 11 ping di 100 byte ciascuno (inclusi gli 8 byte ICMP ma non l'intestazione IP). I ping sono separati da almeno un secondo e viene utilizzato il timeout ping predefinito di 20 secondi. Il primo ping viene buttato via (si presume che sia lento poiché sta caricando le cache ecc. (Martin Horneffer in "http://www.advanced.org/IPPM/archive.2/0246.html" ha riferito che l'utilizzo di UDP - pacchetti di sicurezza e un intervallo di arrivo di circa 12,5 secondi, il primo pacchetto impiega circa il 20% in più di tempo per il ritorno)). L'RTT minimo / medio / massimo per ciascun set di 10 ping viene registrato. Questo viene ripetuto per dieci ping di 1000 byte di dati. L'uso di due dimensioni del pacchetto ping ci consente di effettuare stime delle velocità dei dati ping e anche di individuare comportamenti che differiscono tra pacchetti piccoli e grandi (ad esempio limitazione della velocità). Vedi grande contro piccoli pacchetti, timing of ping measurement per maggiori dettagli. In generale, l'RTT è proporzionale a l (dove l è la lunghezza del pacchetto) fino alla dimensione massima del datagramma (in genere 1472 byte inclusi gli 8 byte echo ICMP). Il comportamento oltre quello non è definito (alcune reti frammentano i pacchetti, altri li rilasciano). Documentazione sullo script di misura raccomandato che viene eseguito in ogni sito di monitoraggio è disponibile. I tempi di risposta del ping sono tracciati per ogni mezz'ora per ciascun nodo. Questo è principalmente usato per la risoluzione dei problemi (ad esempio, vedere se è drammaticamente peggiorato nelle ultime ore).

Il set di host remoti per il ping è fornito da un file chiamato pinger.xml (per ulteriori informazioni consultare la documentazione di pinger2.pl). Questo file si compone di due parti: host Beacon che vengono automaticamente estratti giornalmente da SLAC e monitorati da tutti i MP; altri host che sono di particolare interesse per l'amministratore del MP. Gli host Beacon (e gli host particolari monitorati dallo SLAC MP) sono conservati in un database Oracle contenente il loro nome, indirizzo IP, sito, nickname, posizione, contatto ecc. La lista Beacon (e l'elenco di host particolari per SLAC) e un copia del database, in un formato per semplificare l'accesso Perl per gli script di analisi, vengono generati automaticamente dal database su base giornaliera.

Raccolta di dati

L'architettura del monitoraggio include 3 componenti:

  • I siti di monitoraggio remoto. Questi forniscono semplicemente un host remoto passivo con i requisiti appropriati.
  • Il sito di monitoraggio Gli strumenti di monitoraggio di PingER devono essere installati e configurati su un host in ognuno di questi siti. Anche i dati ping raccolti devono essere resi disponibili agli host di archivio tramite il protocollo HyperText Tansport (HTTP) (vale a dire che deve esistere un server Web per fornire i dati su richiesta tramite il Web). Esistono anche strumenti PingER per consentire a un sito di monitoraggio di fornire analisi e rapporti a breve termine sui dati presenti nella cache locale.
  • I siti di archiviazione e analisi. Ci deve essere almeno uno ciascuno di questi per ciascun progetto PingER. I siti di archiviazione e analisi possono trovarsi in un singolo sito o anche in un singolo host o possono essere separati. Il progetto PingER ha due siti di questo tipo, uno alla NUST di Islamabad, in Pakistan, l'altro allo SLAC. I siti Bot sono siti di archiviazione e analisi. Si completano a vicenda fornendo ridondanza. Il progetto XIWT aveva il suo sito di archivio / monitor al CNRI.
I siti di archivio gatheredgather le informazioni, utilizzando HTTP, dai siti di monitoraggio a intervalli regolari e archiviarle. Forniscono i dati archiviati ai siti di analisianalysis, che a loro volta forniscono rapporti disponibili via Web.

I dati vengono raccolti su base regolare (in genere ogni giorno) dai nodi di monitoraggio da due host di archivio, uno su SLAC e l'altro su FNAL (HEPNRC), che memorizzano, analizzano e uniformano, preparano e via web rendono disponibile reportpingtable pingtable sui risultati (vedere figura sotto).

L'architettura di PingER è illustrata di seguito:
PingER Architecture

Gotchas

È necessario prestare particolare attenzione nella selezione del nodo da eseguire sul ping (vedere Requisiti per il monitoraggio degli host WAN).

Abbiamo anche osservato varie patologie con vari siti remoti quando si utilizza il ping. Questi sono documentati nelle Patologie di misurazione di PingER.

La calibrazione e il contesto in cui vengono misurate le metriche del round trip sono documentate in Calibrazione e Contesto di PingER e alcuni esempi di come appaiono i risultati del ping quando si utilizzano statistiche elevate e in che modo si riferiscono al routing, possono essere trovati nei risultati del ping delle statistiche elevate.

Validazione

Abbiamo convalidato l'uso del ping dimostrando che le misurazioni effettuate con esso sono correlate alla risposta dell'applicazione. La correlazione tra i limiti inferiori delle risposte Web e ping è visibile nella figura seguente. Le misurazioni sono state effettuate il 18 dicembre 1996, da SLAC a circa 1760 siti identificati nelle cache NLANR. Per maggiori dettagli vedi Effetti delle prestazioni Internet sui tempi di risposta Web, di Les Cottrell e John Halperin, non pubblicati, gennaio 1997.

Il confine inferiore notevolmente visibile visto intorno a y = 2x non è sorprendente poiché: una pendenza di 2 corrisponde ai GET HTTP che impiegano il doppio del tempo di ping; il tempo minimo di ping è approssimativamente il tempo di andata e ritorno; e una transazione TCP minima comporta due round trip, un round trip per scambiare il secondo per inviare la richiesta e ricevere la risposta. La terminazione della connessione viene eseguita in modo asincrono e quindi non viene visualizzata nei tempi.

Scatter plot of min HTTP GET vs min ping (30951 bytes)
Il limite inferiore può anche essere visualizzato visualizzando la distribuzione dei residui tra le misure e la linea y = 2 x (dove y = tempo di risposta HTTP GET e x = tempo di risposta ping minimo). Una tale distribuzione è mostrata sotto. Il picco di piega nella frequenza delle misurazioni quando ci si avvicina a zero valore residuo (y = 2x) è evidente. L'intervallo interquartile (IQR), il range residuo tra il 25% e il 75% delle misurazioni, è di circa 220 msec, ed è indicato sul grafico dalla linea rossa.

Residuals for HTTP=2*Min Ping Response (37218 bytes)

Un modo alternativo di dimostrare che il ping è correlato alle prestazioni Web è mostrare che il ping può essere utilizzato per prevedere quale di un gruppo di server Web replicati debba ottenere una pagina Web. Per ulteriori informazioni su questo, vedere Selezione dinamica del server in Internet, di Mark E. Crovella e Robert L. Carter.

Il Case Study di Firehunter sul server Web di Whitehouse ha mostrato che sebbene la risposta al ping non tenga traccia delle prestazioni Web anormali, in questo caso la perdita di pacchetti ping ha fatto un lavoro molto migliore.

La valutazione della qualità del servizio Internet di Christian Huitema, fornisce misurazioni dei vari componenti che contribuiscono alla risposta del web. Questi componenti includono: RTT, velocità di trasmissione, ritardo DNS, ritardo di connessione, ritardo del server, ritardo di trasmissione. Mostra che i ritardi tra l'invio del comando GET URL e la ricezione del primo byte della risposta è una stima del ritardo del server ("in molti server, sebbene non necessariamente tutti, questo ritardo corrisponde al tempo necessario per pianificare le richieste di pagina , prepara la pagina in memoria e inizia a inviare i dati ") e rappresenta tra il 30 e il 40% della durata della transazione media. Per ovviare a questo, probabilmente hai bisogno di server più potenti. Ottenere connessioni più veloci aiuterebbe ovviamente l'altro 60% del ritardo.

Vedi anche la sezione sottostante Strumenti basati su non Ping per alcune correlazioni del throughput con round trip time e perdita di pacchetti.

Cosa misuriamo

Usiamo il ping per misurare il tempo di risposta (tempo di andata e ritorno in millisecondi (ms)), le percentuali di perdita del pacchetto, la variabilità del tempo di risposta sia a breve termine (scala temporale di secondi) che a lungo, e la mancanza di raggiungibilità , cioè nessuna risposta per una successione di ping. Per una discussione e una definizione di raggiungibilità e disponibilità, vedere Prestazioni Internet: analisi e visualizzazione dei dati un white paper di XIWT. Registriamo anche informazioni su pacchetti fuori ordine e pacchetti duplicati.

Con i dati misurati siamo in grado di creare linee di base a lungo termine per aspettative su medie / medie e variabilità per tempo di risposta, velocità effettiva e perdita di pacchetti. Con queste linee di base in atto possiamo impostare le aspettative, fornire informazioni sulla pianificazione, effettuare estrapolazioni e cercare eccezioni (ad esempio il tempo di risposta di oggi è più di 3 deviazioni standard superiori alla media degli ultimi 50 giorni lavorativi) e generare avvisi.

Perdita

La perdita è una buona misura della qualità del collegamento (in termini di velocità di perdita dei pacchetti) per molte applicazioni basate su TCP. La perdita è in genere causata dalla congestione che a sua volta causa code (ad esempio nei router) da riempire e pacchetti da eliminare. La perdita può anche essere causata dalla rete che recapita una copia imperfetta del pacchetto. Questo di solito è causato da errori di bit nei collegamenti o nei dispositivi di rete. Paxson (vedi Packet Dynamics end-to-end) dalle misurazioni effettuate nel 1994 e nel 1995 ha concluso che la maggior parte degli errori di corruzione provenivano da collegamenti T1 e la frequenza tipica era di 1 su 5000 pacchetti. Ciò corrisponde a un tasso di errore di bit per una media di pacchetti 300 byte di circa 1 su 12 milioni di bit. L'IP ha un checksum a 16 bit, quindi la probabilità di non rilevare un errore in un pacchetto corrotto è 1 su 65536 o 1 su circa 300 milioni di pacchetti. Uno studio più recente su Quando il checksum CRC e TCP non sono d'accordo pubblicati nell'agosto del 2000, indica che tracce di pacchetti Internet negli ultimi due anni mostrano che 1 su 30.000 pacchetti fallisce il checksum TCP, anche sui link in cui i CRC a livello di collegamento devono catturare tutti ma 1 su 4 miliardi di errori. Questi errori di checksum TCP sono di livello superiore (ad esempio possono essere causati da errori di bus nei dispositivi o computer di rete o da errori di stack TCP) rispetto agli errori a livello di collegamento che devono essere rilevati dai controlli CRC.

RTT

Il tempo di risposta o Round Trip Time (RTT) quando tracciato rispetto alla dimensione del pacchetto può dare un'idea della velocità dei dati del ping (kilo Byte / sec (KB / s)) Questo diventa sempre più difficile come si va ai collegamenti ad alte prestazioni, dal range del pacchetto è relativamente piccolo (in genere <1500bytes) e la risoluzione temporale è limitata. L'RTT è correlato alla distanza tra i siti più il ritardo ad ogni salto lungo il percorso tra i siti. L'effetto della distanza può essere approssimativamente caratterizzato dalla velocità della luce nella fibra, ed è approssimativamente dato dalla distanza / (0,6 * c) dove c è la velocità della luce (l'ITU nel documento G.144, la tabella A.1 raccomanda un moltiplicatore di 0,005 msec / km o 0,66 c). Mettendo questo insieme ai ritardi di hop, l'RTT R è approssimativamente dato da:

R = 2 * (distanza / (0,6 * c) + salto * ritardo)

dove il fattore di 2 è dato che stiamo misurando i tempi di andata e ritorno per il round trip. Questo è illustrato nella figura seguente, che mostra la risposta ping misurata in funzione della distanza tra 16 coppie di siti situati negli Stati Uniti, in Europa e in Giappone (Bologna-Firenze, Ginevra-Lione, Chicago-U di Notre Dame, Tokyo -Osaka, Amburgo-Dresda, Bologna-Lione, Ginevra-Magonza, Pittsburg-Cincinnatti, Ginevra-Copenaghen, Chicago-Austin, Ginevra-Lund, Chicago-San Francisco, Chicago-Amburgo, San Francisco-Tokyo, San Francisco-Ginevra e Ginevra-Osaka). I triangoli blu sono per la RTT misurata (in millisecondi), la linea nera è adatta ai dati, la linea verde è per y = x (distanza) / (0,6 * c), e i punti rossi si piegano nei ritardi dell'hop con un delay / hop di circa 2,25ms per ciascuna direzione (cioè i punti rossi sono la misura teorica di RTT). Abbiamo usato il Quanto è lontano? pagina web per ottenere le distanze "in linea d'aria" tra i punti principali lungo ciascuna rotta. Una misurazione più recente fatta da Mark Spiller nel marzo 2001, a circa 10 università dell'UC Berkeley ha misurato i ritardi dei router di 500-700 usec con alcuni picchi nella gamma di 800-900 usec.

rtt-predict.jpg (35216 bytes)

La lunghezza del percorso (Rkm) può essere utilizzata nel luogo di distanza per alcuni obiettivi prestazionali di Frame Transfer Delay (FTD). Se Dkm è la distanza del percorso aereo tra i confini, allora la lunghezza del percorso viene calcolata come segue (questo è lo stesso calcolo trovato nel documento ITU G.826).

  • se Dkm <1000 km, quindi Rkm = 1,5 * Dkm
  • se 1000 km <= Dkm <= 1200 km, quindi Rkm = 1500 km
  • se Dkm> 1200 km, quindi Rkm = 1,25 * Dkm
Questa regola non si applica se c'è un satellite nella rotta. Se un satellite è presente in qualsiasi parte del percorso, a tale porzione viene assegnato un FTD fisso di 320 msec. Il valore di 320 msec tiene conto di fattori quali angoli di visualizzazione della stazione di terra bassa e codifica di correzione dell'errore in avanti. La maggior parte delle parti che contengono un satellite non dovrebbero superare i 290 msec di ritardo. Se si tratta di un satellite geostazionario, il limite inferiore dell'orbita geosincrona è compreso tra 22.000 e 23.000 miglia, la velocità della luce è di ~ 186.000 miglia, la cifra è 45.000 e il percorso di andata è di 90.000 miglia, quindi arriviamo a 500ms proprio lì .
Questo RTT minimo allungato causato dai satelliti geostazionari fornisce un'utile firma dell'identità, in quanto il percorso tra il monitor e l'obiettivo include un satellite geostazionario. Un esempio può essere visto nella Figura 5 di Rapporto 2011 - 2012 del gruppo di lavoro di monitoraggio ICFA-SCIC.

I ritardi di ogni hop sono in funzione di 3 componenti principali: la velocità del router, i tassi di clock dell'interfaccia e l'accodamento nel router. I primi due sono costanti nel breve (pochi giorni) periodi di tempo. Pertanto gli RTT minimi danno una misura della distanza / (0,6 * c) + hop * ((velocità dell'interfaccia / dimensione del pacchetto) + tempo minimo di inoltro del router). Questo numero dovrebbe essere una funzione lineare della dimensione del pacchetto. Gli effetti di accodamento del router, d'altra parte, dipendono da più processi di accodamento casuali e traffico incrociato e quindi sono più variabili. Questo è illustrato nella seguente tabella MRTG che mostra la RTT minima molto stabile (area verde) e le RTT massime più casuali (linee blu) misurate dallo SLAC all'università del Wisconsin da domenica 25 febbraio 2001 a lunedì 5 aprile 2001. Il un piccolo bip nella RTT intorno a Martedì è probabilmente causato da un cambio di rotta.

Min & max RTTs between SLAC and UWisc

Strumenti non basati sul ping

SLAC era anche un sito di Surveyor. Surveyor effettua misurazioni del ritardo in un modo (non utilizzando ICMP), utilizzando dispositivi GPS (Global Positioning System) per sincronizzare l'ora e monitoraggio dedicato / host remoti. Noi ha confrontato i dati di PingER e Surveyor confrontare e confrontare i due metodi e verificare la validità dell'eco ICMP. Una delle preoccupazioni sollevate da ICMP echo è la possibilità che i provider di servizi Internet (ISP) tasso che limita ICMP echo e quindi dando luogo a misure di perdita di pacchetti non valide, per ulteriori informazioni su questo vedi la sezione su Gotchas sopra.

Utilizziamo anche strumenti più complessi come FTP (per misurare le velocità di trasferimento di massa) e traceroute (per misurare percorsi e numero di hop). Tuttavia, oltre ad essere più difficile da configurare e automatizzare, l'FTP è più intrusivo sulla rete e più dipendente dal caricamento del nodo finale. Quindi usiamo FTP principalmente in modalità manuale e per avere un'idea di quanto bene funzionano i test ping (Ad esempio Correlazioni tra FTP e Ping e Correlazioni tra throughput FTP, hop e perdita di pacchetti). Abbiamo anche confrontato Previsioni PingER del throughput con le misurazioni NetPerf. Un altro modo per correlare le misurazioni del throughput con la perdita di pacchetti è di Modellazione del throughput TCP.

Calcolo del punteggio medio di opinione (MOS)

L'industria delle telecomunicazioni utilizza il Mean Opinion Score (MOS) come parametro di qualità vocale. I valori del MOS sono: 1 = cattivo; 2 = mediocre; 3 = equo; 4 = buono; 5 = eccellente. Un intervallo tipico per Voice over IP è compreso tra 3,5 e 4,2 (vedere VoIPtroubleshooter.com). In realtà, anche una perfetta connessione è influenzata dagli algoritmi di compressione del codec, quindi il punteggio più alto che la maggior parte dei codec può raggiungere è compreso tra 4.2 e 4.4. Per G.711 il migliore è 4.4 (o un fattore R (vedi la raccomandazione ITU-T G.107, "Il modello elettronico, un modello di calcolo per l'uso nella pianificazione della trasmissione.") Di 94.3) e per G.729 che esegue compressione significativa è 4,1 (o un fattore R di 84,3).

Ci sono tre fattori che influiscono in modo significativo sulla qualità delle chiamate: latenza, perdita di pacchetti, jitter. Altri fattori includono il tipo di codec, il telefono (analogico o digitale), il PBX, ecc.). Mostriamo come calcoliamo il jitter dopo in questo tutorial. La maggior parte delle soluzioni basate su strumenti calcola ciò che viene chiamato un valore "R" e quindi applica una formula per convertirla in un punteggio MOS. Facciamo lo stesso. Questo calcolo da R a MOS è relativamente standard (vedere ad esempio ITU - Settore di normalizzazione delle telecomunicazioni Documento provvisorio XX-E WP 2/12 per un nuovo metodo). Il punteggio R è compreso tra 0 e 100, dove un numero più alto è migliore. I valori tipici da R a MOS sono: R = 90-100 => MOS = 4.3-5.0 (molto soddisfatto), R = 80-90 => MOS = 4.0-4.3 (soddisfatto), R = 70-80 => MOS = 3.6 -4.0 (un po 'di insoddisfazione), R = 60-70 => MOS = 3.1-3.6 (più insoddisfazione), R = 50-60 => MOS = 2.6-3.1 (Più insoddisfazione), R = 0-50 => MOS = 1.0-2.6 (non consigliato). Seguiamo la conversione di latenza, perdita, jitter in MOS Il metodo di Nessoft. Usano (in pseudo codice):

#Prendi la latenza di andata e ritorno medio (in millisecondi), aggiungi
# round trip jitter, ma raddoppiare l'impatto sulla latenza
#aden 10 per le latenze del protocollo (in millisecondi).
EffectiveLatency = (AverageLatency + Jitter * 2 + 10)
#Implementare una curva di base - dedurre 4 per il valore R a 160 ms di latenza
#(andata e ritorno). Qualunque cosa abbia una deduzione molto più aggressiva.

se EffectiveLatency <160 allora
    R = 93.2 - (EffectiveLatency / 40)
altro
    R = 93.2 - (EffectiveLatency - 120) / 10

#Ora, deduciamo 2,5 R valori per percentuale di perdita di pacchetti (ad esempio a
#loss del 5% verrà inserito come 5).
R = R - (PacketLoss * 2.5)

#Convertire R in un valore MOS (questa è una formula nota)
se R <0 allora
    MOS = 1
altro
    MOS = 1 + (0,035) * R + (.000007) * R * (R-60) * (100-R)

Vedi anche quanto segue per alcuni strumenti di misurazione e / o spiegazioni:


L'ITU ha escogitato un metodo per calcolare il contributo della rete al tempo di transazione in ITU-T Rec.G1040 "Contributo di rete al tempo di transazione". Il contributo dipende dalla RTT, dalla probabilità di perdita (p), dal Retransmission Time Out (RTO) e dal numero di round trips coinvolti (n) in una transazione. Il contributo della rete al tempo di transizione (NCTT) è dato come:
Media (NCTT) = (n * RTT) + (p * n * RTO)

I valori tipici per n sono 8, per RTO ci vogliono 2,5 secondi, prendiamo l'RTT e la probabilità di perdita (p) dalle misurazioni di PingER.

Derivare il throughput TCP dalle misurazioni ping

Il comportamento macroscopico dell'algoritmo di evitamento della congestione TCP di Mathis, Semke, Mahdavi & Ott in Computer Communication Review, 27 (3), luglio 1997, fornisce una formula breve e utile per il limite superiore della velocità di trasferimento:
Rate <(MSS / RTT) * (1 / sqrt (p))

dove:
Rate: è la velocità di trasferimento TCP
MSS: è la dimensione massima del segmento (fissa per ogni percorso Internet, in genere 1460 byte)
RTT: è il tempo di andata e ritorno (misurato dal TCP)
p: è il tasso di perdita di pacchetti.
A rigor di termini le perdite sono le perdite TCP che non sono necessariamente identiche alle perdite di ping (ad esempio, il TCP standard provoca perdite come parte della stima della congestione). Anche gli RTT ping sono diversi dal modo in cui TCP stima l'RTT (si veda ad esempio  Miglioramento delle stime relative al tempo di andata e ritorno in un protocollo di trasporto affidabile.) Tuttavia, specialmente per i collegamenti con prestazioni inferiori, è uno stimatore ragionevole. Si può usare il Po Errore Vota (BER) per stimare le perdite. Valori tipici sono BER = 10 ^ -9 (vale a dire la probabilità di perdita di pacchetti di ~ 0,001% per pacchetti da 100 byte) per un collegamento elettrico e 10 ^ -12 per un collegamento ottico (vedere CS244a: un'introduzione alle reti di computer - Stanford Università, e 10 Gigabit Ethernet e l'interfaccia XAUI).
Se non è possibile misurare empiricamente p, iniziare con il tasso di errore del bit previsto (BER) per 1000BaseT, 10 ^ -10 per la probabilità di perdita. Vedere Errore obiettivo prestazioni per 400GbE.

Una forma migliorata dell'equazione precedente può essere trovata in: Modellazione del throughput TCP: un modello semplice e la sua convalida empirica di J. Padhye, V. Firoiu, D. Townsley e J. Kurose, in Proc. SIGCOMM Symp. Architetture e protocolli di comunicazione agosto 1998, pp. 304-314.

Rate = min (Wmax / RTT, 1 / ((RTT / sqrt (2 * b * p / 3) + min (1, 3 * sqrt (3 * b * p / 8)) * (1 + 32 * p * p))))

dove:
Wmax: è la dimensione massima della finestra di congestione.
b: è il numero di pacchetti riconosciuti da un ACK ritardato. Molte implementazioni di ricevitori TCP inviano un ACK cumulativo per due pacchetti consecutivi ricevuti (vedi W. Stevens, TCP / IP Illustrated, Vol. 1 I protocolli, Addison-Wesley, 1994), quindi b è tipicamente 2.

Guardando il comportamento del throughput in funzione della perdita e della RTT Throughput contro RTT e perdita. Abbiamo utilizzato la formula Mathis per confrontare le misurazioni di throughput di PingER e NetPerf.

Normalizzazione della velocità derivata

Per ridurre l'effetto di 1 / RTT nella formula di Mathis per il throughput derivato, normalizziamo il throughput usando
norm_throughput = throughput * min_RTT (regione remota) / min_rtt (monitoring_region)

Direttezza della connessione

Questa è una metrica per identificare l'immediatezza della connessione tra 2 nodi in posizioni note. Valori di direttività vicini a uno indicano che il percorso tra gli host segue un percorso circolare approssimativamente grande. Valori molto più piccoli di 1 significa che il percorso è molto indiretto. La derivazione del coefficiente di direttività La direttività basata sulla RTT minima è riportata qui.

RTD =Distanza di andata e ritorno,
RTD [km] = Direttività * min_RTT [msec] * 200 [km / msec]
La direttività consente ritardi nell'attrezzatura di rete e indiretta del percorso effettivo.
D = 1 via di distanza
Direttività = D (km) / (min_RTT [msec] * 100 [km / msec])

  • Max (direttività) = 1 = diretto (grande cerchio) percorso e nessun ritardo di rete
  • La direttività ottenuta da mini mamma RTT è in genere ~ 0,45
  • I valori bassi in genere indicano una rotta molto indiretta, o una connessione via satellite o lenta (ad esempio wireless)
  • Directivity> 1 identifica probabilmente le cattive coordinate per gli host.
Nel caso del Traceroute visivo VTrace, la differenza tra distanza di salto e distanza da punto a punto può fornire una stima della direttività. La distanza da punto a punto è la grande distanza del percorso circolare tra sorgente e destinazione, dove la distanza totale del salto è la somma delle grandi distanze del cerchio tra tutti gli hop consecutivi. In questo caso stimiamo la Directivty come (end_to_end_distance / total_hop_distance).

Accesso ai dati

I dati di ping non elaborati sono accessibili pubblicamente, vedi Accesso ai dati di PingER per sapere come ottenere i dati e il formato. I dati riepilogati sono inoltre disponibili dal Web in formato Excel con valori separati da tabulazioni (.tsv) dai report dei dettagli di PingER.

Ping dei nodi dei collaboratori

Analisi dei dati e presentazione

Piazzole giornaliere
I tempi di risposta del ping sono tracciati per ogni mezz'ora per ciascun nodo, ad esempio vedere il Trama di affumicatura se RTT e perdita. Questo è principalmente usato per la risoluzione dei problemi (ad esempio, vedere se è drammaticamente peggiorato nelle ultime ore).
Plot 3D di Nodi vs Risposta vs Ora del giorno

3D ping plotTracciando un grafico 3D del nodo rispetto al tempo rispetto alla risposta, possiamo cercare correlazioni di diversi nodi con prestazioni scadenti o irraggiungibili allo stesso tempo (forse a causa di una causa comune), o un dato nodo con scarsa risposta o irraggiungibile per un tempo prolungato. A sinistra è un esempio che mostra diversi host (in nero) tutti irraggiungibili verso le 12.00.



Medie mensili di risposta al rumore e perdite che tornano indietro di anni:

Tabelle delle mediane mensili della prima serata (7 am- 7pm giorno della settimana) Tempo di risposta ping 1000 byte e perdita di pacchetti ping a 100 byte consentirci di visualizzare i dati tornando indietro per periodi più lunghi. Questi dati tabulari possono essere esportati in Excel e grafici composti dalle prestazioni di perdita del pacchetto ping a lungo termine.loss to RAL Jan-95 thru Jul-98 (8921 bytes)

Frequenza di rete quiescente
Quando otteniamo un campione di perdita di pacchetti pari a zero (un campione si riferisce a un insieme di n ping), ci riferiamo alla rete come quiescente (o non occupato). Possiamo quindi misurare la frequenza percentuale di quanto spesso la rete è risultata inattiva. Un'alta percentuale è un'indicazione di una buona rete (quiescente o non pesantemente caricata). Ad esempio, una rete occupata 8 ore lavorative al giorno della settimana e quiescente in altri momenti avrebbe una percentuale di riposo di circa il 75% ~ (totale_ora / settimana - 5 giorni della settimana / settimana * 8 ore / giorno) / (totale_ora / settimana) . Questo modo di rappresentare la perdita è simile nell'intento alla metrica del telefono di secondi senza errori. Il Frequenza di rete quiescente tabella mostra la percentuale (frequenza) dei campioni (in cui un campione è un insieme di 10 100 byte di ping) che ha rilevato una perdita di pacchetti pari a zero. I campioni inclusi in ciascuna percentuale riportata sono tutti i campioni per ciascun sito per ciascun mese (vale a dire dell'ordine di 30 giorni * 48 (periodi di 30 minuti) o di circa 1440 campioni) per sito / mese.
Jitter, vedi anche Jitter,
La variabilità a breve termine o "jitter" del tempo di risposta è molto importante per le applicazioni in tempo reale come la telefonia. La navigazione e la posta sul Web sono abbastanza resistenti al jitter, ma qualsiasi tipo di streaming multimediale (voce, video, musica) è abbastanza suscettibile al jitter. Il jitter è un sintomo che c'è una congestione, o non abbastanza bandwidt per gestire il traffico. Il jitter specifica la lunghezza del VoIP buffer di de-jitter del codec per prevenire sovra o sotto-flusso. Un obiettivo potrebbe essere quello di specificare che il 95% delle variazioni di ritardo del pacchetto deve essere compreso nell'intervallo [-30msec, + 30msec].

Un metodo richiede l'iniezione di pacchetti a intervalli regolari nella rete e la misurazione della variabilità nel tempo di arrivo. L'IETF ha Metrica di variazione del ritardo del pacchetto IP per IP Performance Metrics (IPPM) (vedi anche RTP: un protocollo di trasporto per applicazioni in tempo reale, RFC 2679 e RFC 5481

Misuriamo la variabilità istantanea o "jitter" in due modi.

  1. Lascia che la misurazione i-esima del tempo di andata e ritorno (RTT) sia Ri, quindi prendiamo il "jitter" come l'Inter Quartile Range (IQR) della distribuzione di frequenza di R. Vedi la SLAC <=> Ritardo di andata e ritorno del CERN per un esempio di una tale distribuzione.
  2. Nel secondo metodo estendiamo la bozza IETF Metrica di variazione del ritardo di pacchetto istantaneo per IPPM, che è una metrica a senso unico, a ping a due vie. Prendiamo l'IQR della distribuzione di frequenza di dR, dove dRi = Ri-Ri-1. Si noti che quando si calcola dR i pacchetti non devono essere adiacenti. Vedere il SLAC <=> Variazione del ritardo dei pacchetti istantanei a due vie del CERN per un esempio di una tale distribuzione.
Entrambe le distribuzioni sopra possono essere viste come non-gaussiane, motivo per cui usiamo l'IQR invece della deviazione standard come misura di "jitter". Vedi anche RFC 1889/3550.

Visualizzando il Ping "jitter" tra SLAC e CERN, DESY e FNAL si può vedere che i due metodi di calcolo del jitter si inseguono l'un l'altro bene (il primo metodo è etichettato come IQR e il secondo IPD etichettato nella figura). Variano di due ordini di magnitudine nel corso della giornata. Il jitter tra SLAC e FNAL è molto inferiore a quello tra SLAC e DESY o CERN. È anche degno di nota il fatto che il CERN abbia un maggiore jitter durante il giorno europeo mentre DESY ha un maggiore jitter durante il giorno degli Stati Uniti.

Abbiamo anche ottenuto una misura del jitter prendendo il valore assoluto dR, cioè | dR |. Questo è a volte indicato come il "metodo della gamma mobile" (vedi Disegno statistico e analisi degli esperimenti, Robert L. Mason, Richard F. Guest e James L. Hess. John Wiley & Sons, 1989). Viene anche utilizzato in RFC 2598 come definizione di jitter (l'RFC 1889 ha un'altra definizione di jitter per l'utilizzo e il calcolo in tempo reale). Vedere il Istogramma del campo di movimento per un esempio. In questa figura, la linea magenta è il totale cumulativo, la linea blu è una misura esponenziale per i dati e la linea verde è una serie di potenze adatta ai dati. Nota che tutti e 3 i grafici in questa sezione su jitter sono rappresentazioni di dati identici.






Al fine di comprendere più da vicino i requisiti del VoIP e in particolare l'impatto dell'applicazione delle misure della Qualità del Servizio (QoS), abbiamo creato un banco di prova VoIP tra SLAC e LBNL. Uno schema approssimativo è mostrato a destra. Solo il semicircuito dello SLAC è mostrato nello schema, l'estremità del LBNL è simile. Un utente può sollevare il telefono collegato al PBX alla fine dello SLAC e chiamare un altro utente su un telefono su LBNL tramite il gateway del router Cisco VoIP. Il gateway codifica, comprime ecc. Il flusso vocale in pacchetti IP (utilizzando lo standard G.729) creando circa 24kbps di traffico. Il flusso VoIP include sia i pacchetti TCP (per la segnalazione) che UDP. La connessione dal router ESnet al cloud ATM è un circuito virtuale permanente (PVC) ATM da 3,5 Mbps. Senza traffico concorrente sul collegamento, la chiamata si connette e la conversazione procede normalmente con una buona qualità. Quindi iniettiamo 4 Mbps di traffico sull'interfaccia Ethernet 10 Mbps condivisa a cui è connesso il router VoIP. In questa fase, la connessione VoIP è interrotta e non è possibile effettuare ulteriori collegamenti. Abbiamo quindi utilizzato la funzione CAR (Committed Access Rate) del router Edge per etichettare i pacchetti VoIP impostando i bit Per Hop Behavior (PHB). Il router ESnet viene quindi impostato per utilizzare la funzione WFQ (Weighted Fair Queuing) per accelerare i pacchetti VoIP. In questa configurazione è possibile eseguire nuovamente le connessioni vocali e la conversazione è di nuovo di buona qualità.
Servizio prevedibilità
Una misura di variabilità del servizio (o ping prevedibilità) può essere ottenuto per mezzo di un diagramma a dispersione delle variabili adimensionali frequenza dati ping giornaliera media / velocità dati ping massima rispetto al successo ping giornaliero medio / successo ping massimo (dove% successo = (pacchetti totali - pacchetti persi) / Pacchetti totali). Qui la frequenza dei dati del ping è definita come (2 * byte nel pacchetto ping) / tempo di risposta. Il 2 è dato che il pacchetto deve uscire e tornare indietro. Un altro modo di osservare i rapporti è che i numeri vicini a 1 indicano che la performance media è vicina alla migliore performance. I numeri non vicini a 1 sono in genere causati da grandi variazioni nel tempo di ping tra ore di lavoro e ore non lavorative, vedi ad esempio il  Risposta al ping UCD per il 3 ottobre 1996 per un esempio delle variazioni diurne. Di seguito sono riportati alcuni esempi di grafici di scattering di previsione del ping per varie parti di Internet, misurati da SLAC per luglio 1995 e marzo 1996.


DataTutti gli hostESnet

Jul '95all jul95esnet jul95

È possibile ridurre ulteriormente le informazioni dello scatterplot riportando il successo medio mensile del pacchetto ping successo / ping massimo rispetto al thruput ping mensile / thruput ping massimo per diversi mesi per vedere le modifiche. Tale trama per pochi Nodi americani per luglio 1995 e marzo 1996 mostra grandi cambiamenti, in tutti i casi in peggio (i punti più recenti sono più in basso a sinistra della trama).
Imprevedibilità
Si può anche calcolare la distanza di ciascun punto di prevedibilità dalla coordinata (1,1). Normalizziamo a un valore massimo di 1 dividendo la distanza di sqrt (2). Mi riferisco a questo come il ping imprevedibilità, poiché fornisce un indicatore percentuale dell'imprevedibilità delle prestazioni del ping.
Raggiungibilità
Osservando i dati di ping per identificare periodi di 30 minuti in cui non sono state ricevute risposte di ping da un determinato host, è possibile identificare quando l'host era inattivo. Usando queste informazioni si può calcolare l'irraggiungibilità del ping = (# periodi con il nodo in basso / numero totale di periodi), # periodi in giù, tempo medio tra insuccessi (MTBF o tempo medio da fallire MTTF)) e tempo medio da riparare (MTTR). Tieni presente che MTBF = sample_time / ping_unreachability dove per il tempo di campionamento di PingER è di 30 minuti. La raggiungibilità dipende molto dall'host remoto, ad esempio se l'host remoto viene rinominato o rimosso, l'host apparirà irraggiungibile eppure potrebbe non esserci nulla di sbagliato nella rete. Pertanto, prima di utilizzare questi dati per fornire tendenze di rete a lungo termine, i dati dovrebbero essere accuratamente scrub per gli effetti non di rete. Esempi di ping raggiungibilità e Down
i rapporti sono disponibili.

Si può anche misurare il frequenza delle lunghezze di interruzione utilizzando sonde attive e osservando la durata per cui le sonde sequenziali non riescono a passare.

Un altro parametro che viene talvolta utilizzato per indicare la disponibilità di un circuito telefonico è il numero di secondi senza errori. Alcune misure su questo possono essere trovate in Secondi senza errori tra SLAC, FNAL, CMU e CERN.

C'è anche un RFC IETF su Connettività di misurazione e un documento su Una moderna tassonomia ad alta disponibilità che può essere utile.

Pacchetti fuori ordine
PingER utilizza un algoritmo molto semplice per identificare e segnalare i pacchetti fuori ordine. Per ogni campione di 10 pacchetti, cerca di vedere se i numeri di sequenza delle risposte sono ricevuti nello stesso ordine in cui sono state inviate le richieste. Se non di quel campione è contrassegnato come avente una o più risposte fuori ordine. Per un dato intervallo (ad esempio un mese) il valore riportato per ou di ordine è la frazione di campioni contrassegnati con risposte ping fuori servizio. Poiché i pacchetti di ping vengono inviati a intervalli di un secondo, ci si aspetta che la frazione dei campioni fuori ordine sia molto piccola e potrebbe valere la pena di investigare ogni volta che non lo è.
Pacchetti duplicati
Le risposte ping duplicate possono essere causate da:

  • Più di un host ha lo stesso indirizzo IP, quindi tutti questi host risponderanno alla richiesta echo ICMP.
  • L'indirizzo IP inviato può essere un indirizzo di broadcast.
  • L'host ha più stack TCP associati a un adattatore Ethernet (vedere http://www.doxpara.com/read.php/tcp_chorusing.html).
  • Un router crede di avere due percorsi attraverso i quali può raggiungere l'host di fine e (presumibilmente erroneamente) inoltra le richieste di eco ICMP da entrambe le rotte, quindi l'host di destinazione vede due richieste di eco e risponde due volte.
  • Esistono forse due o più percorsi (non indirizzati) all'host finale e ciascuna richiesta viene inoltrata da più di un percorso.
  • Una scatola NAT comportamentale.
Alcuni test che possono aiutare includono:
  • Fare un ping ai router lungo il percorso per vedere se qualcuno di loro risponde con duplicati.
  • Cattura i pacchetti ping e controlla se tutti i pacchetti vengono restituiti dallo stesso indirizzo Ethernet.
Un'idea del valore dei pacchetti di ping duplicati deriva dalle misurazioni di PingER dal 31 marzo 2012 a 703 host in oltre 600 paesi. Di questi host 15 hanno risposto con ping duplicati. Per 13 dei 15 host si è verificato con ping da 100 e 1000 byte. Su 10 ping inviati 6 host avevano 1 ping duplicato, 5 avevano 2 ping duplicati, 2 4 duplicati di ping, 1 3 duplicati di ping e 1 ping di 12 ping inviati per ciascun ping inviato. I siti degli host spaziano da laboratori nazionali (CERN, IHEP SU), paesi sviluppati (Israele), paesi in via di sviluppo (Burkina Faso, Malawi, Mauritius, Sierra Leone, Swaziland, Zambia) e siti educativi (SDSC). PingER riporta semplicemente che ci sono stati duplicati o meno. Una metrica utile consiste nel riportare il numero di ping ricevuti / i ping dei numeri inviati. Il numero ricevuto può dipendere dalle opzioni del comando ping. Un'opzione invierà un determinato numero di ping fino a quando non riceverà più di un numero di volte. Un'altra opzione invierà 10 ping e attenderà (o timeout) finché non verranno ricevuti. Quindi il valore della metrica può dipendere anche dal comando ping.

Combinazione di tutte le misure ping
Si può mettere insieme un diagramma di tutte le misure di ping di cui sopra (perdita, risposta, irraggiungibilità e imprevedibilità) per provare e mostrare la combinazione di misure per un insieme di host per un dato periodo di tempo. La trama di seguito per l'1-11 marzo 1997 raggruppa gli host in gruppi logici (ESnet, Nord America Ovest, ...) e all'interno dei gruppi classifica gli host di% 100 byte di perdita di pacchetti ping per SLAC prime time (7am - 7pm nei giorni feriali), indicato anche da una linea blu è il tempo di risposta ping in prima serata, e il
negativo del ping% di irraggiungibilità e imprevedibilità.

ping performance mar96

Nel grafico sopra, i tempi di perdita e di risposta sono misurati durante il primo time di SLAC (7am - 7pm, nei giorni feriali), le altre misure sono per tutto il tempo.

  • I tassi di perdita sono tracciati come un grafico a barre sopra l'asse y = 0 e sono per pacchetti di ping del payload da 100 byte. Le linee orizzontali sono indicate con perdite di pacchetti dell'1%, 5% e 12% ai limiti delle qualità di connessione definite sopra.
  • Il tempo di risposta viene tracciato come una linea blu su un asse di registro, etichettato a destra, ed è il tempo di andata e ritorno per i pacchetti di payload ping da 1000 byte.
  • L'irraggiungibilità dell'host viene tracciata come un grafico a barre che si estende negativamente dall'asse y = 0. Un host è considerato irraggiungibile a intervalli di 30 minuti se non risponde a nessuno dei 21 ping effettuati in quell'intervallo di 30 minuti.
  • L'imprevedibilità dell'host è tracciata in verde qui come valore negativo, può variare da 0 (totalmente imprevedibile) a 1 (altamente prevedibile) ed è una misura della variabilità del tempo di risposta del ping e della perdita durante ogni giorno di 24 ore. È definito in modo più dettagliato in Ping imprevedibilità.
Le seguenti osservazioni sono anche rilevanti:

  • Gli host ESnet in generale hanno una buona perdita di pacchetti (mediana dello 0,79%). Le perdite medie di pacchetti per gli altri gruppi variano da circa il 4,5% (Nord America Est) al 7,7% (Internazionale). Tipicamente, il 25% -35% degli host nei gruppi non-ESnet è nell'intervallo da cattivo a cattivo.
  • Il tempo di risposta per host ESnet è in media a circa 50ms, per il Nord America Wes è di circa 80ms, per il Nord America a circa 150ms e per gli host internazionali a circa 200ms.
  • La maggior parte dei problemi irraggiungibili sono limitati a pochi ospiti principalmente nel gruppo internazionale (Dresda, Novosibirsk, Firenze).
  • L'imprevedibilità è più marcata per alcuni host internazionali e tiene traccia approssimativamente della perdita di pacchetti.
Qualità
Per poter riassumere i dati in modo che il significato possa essere rapidamente compreso, abbiamo cercato di caratterizzare la qualità delle prestazioni dei collegamenti. Alcuni rapporti interessanti sono qui sotto:


Di seguito sono riportate altre misure organizzate per metrica.

Ritardo

Il bene più scarso e più prezioso è il tempo. Studi condotti tra la fine degli anni '70 e i primi anni '80 da Walt Doherty di IBM e altri hanno dimostrato il valore economico del Rapid Response Time:
0-0.4s Risposta interattiva ad alta produttività
0.4-2s Regime completamente interattivo
2-12s Regime sporadicamente interattivo
12s-600s Rompere il regime di contatto
Regime Batch 600s
Per ulteriori informazioni sull'impatto dei tempi di risposta, vedi The Psychology of Human Computer Interaction, Stuart K. Card, Thomas P. Moran e Allen Newell, ISBN 0-89859-243-7, pubblicato da Lawrence Erlbaum Associates (1983).

C'è una soglia intorno ai 4-5 secondi in cui i reclami aumentano rapidamente. Per alcune nuove applicazioni Internet ci sono altre soglie, ad esempio per la voce una soglia per il ritardo di un modo appare a circa 150 ms (vedi raccomandazione ITU G.114 tempo di trasmissione unidirezionale, febbraio 1996) - al di sotto di questo si possono avere chiamate di qualità del pedaggio, e sopra quel punto, il ritardo provoca difficoltà per le persone che cercano di avere una conversazione e la frustrazione cresce.

Per mantenere il tempo nella musica, i ricercatori di Stanford hanno scoperto che la quantità ottimale di latenza è di 11 millisecondi. Al di sotto di questo ritardo, le persone tendevano ad accelerare. Al di sopra di questo ritardo e tendono a rallentare. Dopo circa 50 millisecondi (o 70), le prestazioni tendevano a crollare completamente.

L'orecchio umano percepisce i suoni come simultanei solo se vengono ascoltati entro 20 ms l'uno dall'altro, vedi http://www.mercurynews.com/News/ci_27039996/Music-at-the-speed-of-light-is-researchers- obbiettivo

Per multimedia in tempo reale (H.323) Misurazione delle prestazioni e analisi del traffico H.323 dà un ritardo di un modo (all'incirca un fattore due per ottenere RTT), di: 0-150 ms = Buono, 150-300 ms = Accettabile, e> 300 ms = scarso.

Lo SLA per il target di latenza di rete a una via per Cisco TelePresence è inferiore a 150 msec. Ciò non include la latenza indotta dalla codifica e dalla decodifica negli endpoint CTS.

Tutti i pacchetti che comprendono un frame di video devono essere consegnati al punto finale di TelePresence prima che il buffer di riproduzione sia esaurito. In caso contrario si può verificare un peggioramento della qualità del video. Il target di jitter picco-picco per Cisco TelePresence è sotto i 10 msec.

Il giornale su Internet alla velocità della luce fornisce diversi esempi dell'importanza di ridurre la RTT. Gli esempi includono motori di ricerca come Google e Bing, le vendite di Amazon e la borsa

Per il controllo tattile in tempo reale e il feedback per le operazioni mediche, i ricercatori di Stanford (vedi Shah, A., Harris, D., & Gutierrez, D. (2002). "Prestazioni di Anatomia remota e applicazioni di allenamento chirurgico in condizioni di rete diverse". Conferenza mondiale su Multimedia educativi, Hypermedia e Telecommunications 2002 (1), 662-667) trovato che un ritardo unidirezionale di <= 80 msec. era necessario.

Il Mappa del tempo di Internet identifica come cattivi eventuali collegamenti con ritardi superiori a 300 ms.

Perdita

Per la caratterizzazione della qualità ci siamo concentrati principalmente sulle perdite di pacchetti. Le nostre osservazioni sono state che oltre il 4-6% della videoconferenza per perdita di pacchetti diventa irritante e gli oratori della lingua non nativa diventano incapaci di comunicare. L'insorgere di lunghi ritardi di 4 secondi o più con una frequenza del 4-5% o superiore è anche irritante per attività interattive come telnet e X windows. Oltre il 10-12% della perdita di pacchetti c'è un livello inaccettabile di back to back loss di pacchetti e timeout estremamente lunghi, le connessioni iniziano a rompersi e la videoconferenza è inutilizzabile (vedi anche La questione dell'inutile trasmissione di pacchetti per multimedia su Internet, dove dicono a pagina 10 "concludiamo che per questo flusso video, la qualità del video è incomprensibile quando i tassi di perdita di pacchetti superano il 12%". D'altro canto, i funzionari di MSF (Multi Service Forum) hanno dichiarato che a seguito di test su reti di prossima generazione per IPTV "i test hanno dimostrato che anche la metà dell'1% della perdita di pacchetti in un flusso video può rendere inaccettabile la qualità del video. utenti "(vedi Computerworld, 29 ottobre 2008).

Originariamente i livelli di qualità per la perdita di pacchetti erano fissati a 0-1% = buono, 1-5% = accettabile, 5-12% = scarso e superiore a 12% = cattivo. Più recentemente, abbiamo perfezionato i livelli allo 0-0,1% eccellente, 0,1-1% = buono, 1-2,5% = accettabile, 2,5-5% = scarso, 5% -12% = molto scarso e superiore al 12% = cattivo La modifica delle soglie riflette i cambiamenti nella nostra enfasi, cioè nel 1995 ci occupavamo principalmente di e-mail e ftp. Questa citazione di Vern Paxson riassume la principale preoccupazione al momento: la saggezza convenzionale tra i ricercatori del TCP sostiene che un tasso di perdita del 5% ha un effetto negativo significativo sulle prestazioni del TCP, poiché limiterà notevolmente le dimensioni della finestra di congestione e quindi velocità di trasferimento, mentre il 3% è spesso sostanzialmente meno grave. In altre parole, il complesso comportamento di Internet si traduce in un cambiamento significativo quando la perdita di pacchetti supera il 3%. Nel 2000 ci siamo occupati anche di applicazioni X-window, prestazioni Web e videoconferenze a pacchetto. Nel 2005 eravamo interessati ai requisiti in tempo reale del VoIP e stiamo iniziando a guardare la voce su IP. Di norma, la perdita di pacchetti in VoIP (e VoFi) non deve mai superare l'1 percento, il che significa essenzialmente che una voce salta ogni tre minuti. Gli algoritmi DSP possono compensare fino a 30 ms di dati mancanti; più di questo, e l'audio mancante sarà evidente agli ascoltatori. Il EXchange della rete automobilistica (AND) imposta la soglia per il tasso di perdita di pacchetti (vedi AND / Auto Linx Metrics) essere inferiore allo 0,1%.

Il gruppo di lavoro ITU TIPHON (cfr. Aspetti generali sulla qualità del servizio (QOS), rapporto tecnico DTR / TIPHON-05001 V1.2.5 (1998-09) ha anche definito <3% perdita di pacchetti come buona,> 15% per media degrado, e il 25% per scarso degrado, per la telefonia via Internet. È molto difficile fornire un singolo valore al di sotto del quale la perdita di pacchetti dia una voce interattiva soddisfacente / accettabile / di buona qualità. Ci sono molte altre variabili coinvolte tra cui: delay, jitter, Packet Loss Concealment (PLC), se le perdite sono casuali o bursty, l'algoritmo di compressione (la compressione più pesante usa meno larghezza di banda ma c'è più sensibilità alla perdita di pacchetti dal momento che più dati sono contenuti / perso in un unico pacchetto). Vedi per esempio Rapporto del 1 ° evento di prova di qualità vocale ETSI VoIP, 21-18 marzo 2001, o Speech Processing, Transmission and Quality Aspects (STQ); Rapporto di prova anonimo dal 2 ° test di qualità vocale Evento 2002 ETSI TR 102 251 v1.1.1 (2003-10) o ETSI 3rd Speech Test di qualità Riepilogo eventi, qualità conversazione vocale per gateway VoIP e telefonia IP.

Jonathan Rosenberg di Lucent Technology e Columbia University in G.729 Error Recovery for Internet Telephony presentato al V.O.N. La conferenza 9/1997 ha fornito la seguente tabella che mostra la relazione tra il Mean Opinion Score (MOS) e i pacchetti consecutivi persi.

Le perdite di pacchetti consecutive degradano la qualità della voce
Fotogrammi consecutivi persi12345
M.O.S.4.23.22.42.11.7
dove:
Punteggio medio di opinione
ValutazioneQualità del parlatoLivello di distorsione
5EccellenteImpercettibile
4BuonaAppena percepibile, non fastidioso
3GiustoPercepibile, leggermente fastidioso
2PoveroFastidioso ma non obbiettivo
1InsoddisfacenteMolto fastidioso, discutibile
Se i pacchetti VoIP sono distanziati di 20 msec, allora una perdita del 10% (supponendo una distribuzione casuale della perdita) equivale a vedere 2 fotogrammi consecutivi persi circa ogni 2 secondi, mentre una perdita del 2,5% equivale a 2 fotogrammi consecutivi persi ogni 30 secondi.

Quindi impostiamo la perdita di pacchetti "Accettabile" a <2,5%. La carta Misurazione delle prestazioni e analisi del traffico H.323 fornisce le seguenti informazioni per VoIP (H.323): Perdita = 0% -0.5% Buono, = 0.5% -1.5% Accettabile e> 1.5% = Scadente.

Le soglie sopra indicate presuppongono una distribuzione di perdita di pacchetti casuali. Tuttavia, spesso le perdite arrivano a raffiche. Per quantificare la perdita di pacchetti consecutivi abbiamo utilizzato, tra le altre cose, la probabilità di perdita condizionale (CLP) definita in Characterizing End-to-end Packet Delay and Loss in Internet da J. Bolot nel Journal of High Speed Networks, vol 2, n. 3 pp 305-323 dicembre 1993 (lo è anche disponibile sul web). Fondamentalmente il CLP è la probabilità che, se un pacchetto viene perso, anche il seguente pacchetto venga perso. Più formalmente Conditional_loss_probability = Probability (loss (pacchetto n + 1) = true | loss (pacchetto n) = true). Le cause di tali burst includono il tempo di convergenza richiesto dopo una modifica del routing (da 10 secondi a 100 secondi), la perdita e il ripristino della sincronizzazione nella rete DSL (10-20 secondi) e le riconfigurazioni dello spanning bridge bridge (~ 30 secondi). Maggiori informazioni sull'impatto di una perdita di pacchetti esplosiva possono essere riscontrate nelle perdite di qualità del discorso delle perdite casuali rispetto a Bursty Packet da parte di C. Dvorak, documento interno ITU-T. Questo documento mostra che mentre per la perdita casuale il drop off nel MOS è lineare con la perdita del pacchetto%, per le perdite bursty la caduta è molto più veloce. Vedi anche Perdita di pacchetti Burstiness. La dispersione in MOS è da 5 a 3.25 per un cambiamento nella perdita di pacchetti da 0 a 1% e quindi è lineare che cade a un MOS di circa 2,5 per una perdita del 5%.

Altri sforzi di monitoraggio possono scegliere soglie diverse, probabilmente perché riguardano diverse applicazioni. La pagina sul traffico di MCI ha contrassegnato i collegamenti come verdi se hanno una perdita di pacchetti <5%, rossi se> 10% e arancione in mezzo. Il bollettino meteorologico di Internet ha colorato <6% di perdita come verde e> 12% come rosso e arancione in caso contrario. Quindi sono entrambi più clementi di noi o, o almeno, meno granulari. Gary Norton in Network World Dec. 2000 (p 40), afferma "Se viene consegnato più del 98% dei pacchetti, gli utenti dovrebbero sperimentare solo un tempo di risposta leggermente inferiore e le sessioni non dovrebbero scadere".

La figura seguente mostra le distribuzioni di frequenza per la perdita media mensile di pacchetti per circa 70 siti visti da SLAC tra gennaio 1995 e novembre 1997.

quality frequency

A causa dell'elevata quantità di compressione e previsione del movimento utilizzata dai codec video di TelePresence, anche una piccola quantità di perdita di pacchetti può comportare un degrado visibile della qualità video. Il SLA per obiettivo di perdita di pacchetti per Cisco TelePresence  dovrebbe essere inferiore allo 0,05 percento sulla rete.

Per il controllo e il feedback tattile in tempo reale per le operazioni mediche, i ricercatori di Stanford hanno scoperto che la perdita non era un fattore critico e che le perdite fino al 10% potevano essere tollerate.

Tuttavia, per un throughput dei dati ad alte prestazioni su lunghe distanze (alta RTT), come si può vedere in L'articolo di ESnet su Perdita di pacchettiperdite di appena lo 0,0046% (1 perdita di pacchetti in 22.000) su collegamenti 10Gbps con MTU impostato a 9000 byte (l'impatto è maggiore con MTU di default di 1500 byte) comportano fattori di riduzione del throughput di 10 per RTT> 10 msec.

Jitter

Il gruppo di lavoro ITU TIPHON (vedere gli aspetti generali del rapporto tecnico DTR / TIPHON-05001 V1.2.5 (1998-09) sulla qualità del servizio (QoS) definisce quattro categorie di degrado della rete basate sul jitter a una via. Questi sono:
Livelli di degrado della rete basati sul jitter

Categoria di degradoPicco jitter
Perfezionare0 msec.
Buona75 msec.
Medio125 msec.
Povero225 msec.
Stiamo studiando come correlare le soglie di jitter unidirezionali alle misurazioni del jitter ping (round-trip o bidirezionale). Abbiamo usato le misurazioni del ritardo a senso unico del Surveyor (vedi sotto) e misurato gli IQR del ritardo a una via (ja => b e jb => a, dove il pedice a => b indica che il nodo di monitoraggio è in a ed è monitoraggio di un nodo remoto in b) e differenza di ritardo tra pacchetti (Ja => b e Jb => a). Quindi aggiungiamo i due ritardi a una via per i timestamp equivalenti insieme e ricaviamo gli IQR per il ritardo di andata e ritorno (ja <=> b) e la differenza di ritardo tra pacchetti (Ja <=> b). Visualizzazione a Confronto tra jitter a uno e due vie si può vedere che le distribuzioni non sono distribuite gaussamente (essendo più nitide ma con code più larghe), il jitter misurato in una direzione può essere molto diverso da quello misurato nell'altra direzione e che in questo caso l'approssimazione di cui sopra per il round trip IQR funziona abbastanza bene (con un accordo del 2%).

La navigazione e la posta sul Web sono abbastanza resistenti al jitter, ma qualsiasi tipo di streaming multimediale (voce, video, musica) è abbastanza suscettibile a Jitter. Il jitter è un sintomo che esiste una congestione o una larghezza di banda insufficiente per gestire il traffico.

Il jitter specifica la lunghezza dei buffer di riproduzione del codec VoIP per prevenire il sovra-o il sotto-flusso. Un obiettivo potrebbe essere quello di specificare che il 95% delle variazioni di ritardo del pacchetto deve essere compreso nell'intervallo [-30msec, + 30msec].

Per multimedia in tempo reale (H.323) Misurazione delle prestazioni e analisi del traffico H.323 dà per un modo: jitter = 0-20 ms = Buono, jitter = 20-50 ms = accettabile,> 50 ms = scarso. Misuriamo il jitter di andata e ritorno che è all'incirca due volte il jitter a senso unico.

Per il controllo e il feedback tattile in tempo reale per le operazioni mediche, i ricercatori di Stanford hanno scoperto che il jitter era critico e che erano necessari nervosismi <1 msec.

Throughput

Requisiti di prestazione (da AT & T)

  • 768k - 1.5 Mbps: condivisione di foto, download di musica, e-mail, navigazione web.
  • 3.0 Mbps - 6.0 Mbps - streaming video, giochi online, rete domestica.
  • > 6 Mbps - hosting di siti Web, guardare la TV online, scaricare film.

Ecco alcune altre linee guida:

  • Di seguito è riportato Considerazioni sulla progettazione di Cisco Telepresence su un'architettura PIN. La larghezza di banda utilizzata per l'endpoint Cisco TelePresence varia in base a fattori che includono il modello implementato, la risoluzione video desiderata, l'interoperabilità con i sistemi di videoconferenza legacy e se l'input video ausiliario a bassa o alta velocità viene distribuito per la document camera o la presentazione. Ad esempio, quando si utilizza la migliore risoluzione video 1080p con ingresso video ausiliario ad alta velocità e interoperabilità, il requisito di larghezza di banda può arrivare fino a 20,4 Mbps per CTS-3200 e CTS-3000 o 10,8 Mbps per CTS-1000 e CTS-500 .
  • Guida a banda larga FCC

Utilizzo

L'utilizzo dei collegamenti può essere letto dai router tramite MIB SNMP (presumendo che uno abbia l'autorizzazione a leggere tali informazioni). "Con un utilizzo di circa il 90% una rete tipica scarterà il 2% dei pacchetti, ma questo varia I collegamenti a bassa larghezza di banda hanno meno ampiezza per gestire esplosioni, eliminando frequentemente pacchetti con solo l'80% di utilizzo ... Un controllo completo della rete dovrebbe misurare link capacity settimanale. Ecco un codice colore suggerito:

  • ROSSO: Packet scarta> 2%, non distribuire nessuna nuova applicazione.
  • AMBRA: utilizzo> 60%. Considera un aggiornamento di rete.
  • VERDE: utilizzo <60%. Accettabile per la nuova implementazione dell'applicazione. "
Rallentamento ad alta velocità, Gary Norton, Network Magazine, dicembre 2000. Quanto sopra non indica su quale periodo viene misurato l'utilizzo. Altrove, nell'articolo di Norton, afferma che "La capacità della rete ... è calcolata come una media delle ore di busiet in 5 giorni lavorativi".

"La teoria delle code suggerisce che la variazione nel tempo di andata e ritorno, o, varia proporzionale a 1 / (1-L) dove L è il carico di rete corrente, 0 <= L <= 1. Se Internet sta funzionando al 50% della capacità, prevediamo che il ritardo di andata e ritorno varierà di un fattore di + -2 o, 4. Quando il carico raggiunge l'80%, ci aspettiamo una variazione di 10. " Internetworking con TCP / IP, Principi, protocolli e architettura, Douglas Comer, Prentice Hall. Ciò suggerisce che si può essere in grado di ottenere una misura dell'utilizzo osservando la variabilità nella RTT. Non abbiamo convalidato questo suggerimento in questo momento.

Raggiungibilità

Il requisito generico Bellcore 929 (GR-929-CORE Affidabilità e misure di qualità per i sistemi di telecomunicazione (RQMS) (Wireline), viene utilizzato attivamente dai fornitori e dai fornitori di servizi come base per la segnalazione dei fornitori delle prestazioni trimestrali misurate rispetto agli obiettivi. la pubblicazione dell'ultimo numero di GR-929-CORE, tali obiettivi di prestazione rivisti sono implementati) indica che il nucleo della rete telefonica punta a una disponibilità del 99,999%, che si traduce in meno di 5,3 minuti di inattività all'anno. Come scritto, la misurazione non include interruzioni inferiori a 30 secondi. Si rivolge agli attuali switch digitali PSTN (come Electronic Switching System 5 (5ESS) e Nortel DMS250), utilizzando la tecnologia voice-over-ATM di oggi. Un sistema di commutazione pubblico è necessario per limitare il tempo di interruzione totale per un periodo di 40 anni a meno di due ore o meno di tre minuti all'anno, un numero equivalente a una disponibilità del 99,99943%. Con la convergenza di dati e voce, ciò significa che le reti di dati che porteranno più servizi, compresa la voce, devono partire da una disponibilità simile o migliore o gli utenti finali saranno infastiditi e frustrati.

I livelli di disponibilità sono spesso inseriti in un accordo sul livello di servizio. La tabella seguente (basata sul sondaggio Cahners In-Stat di un campione di Application Service Provider (ASP)) mostra i livelli di disponibilità offerti dagli ASP e i livelli scelti dai clienti.

Livelli offertiScelto dal cliente
Meno di 99%26%19%
99% disponibilità39%24%
99.9% disponibilità24%15%
99.99% disponibilità15%5%
99.999% disponibilità18%5%
Più del 99,999% di disponibilità13%15%
Non lo so13%18%
Media ponderata della disponibilità offerta99.5%99.4%
Per ulteriori informazioni su disponibilità ecc. Vedere: il white paper di Cisco su Disponibilità always-on per reti di carrier multiservizio per come Cisco si sta impegnando per l'alta disponibilità sulle reti di dati; Una moderna tassonomia ad alta disponibilità; e il documento IETF RFC 2498: metriche IPPM per la misurazione della connettività.

Direttività

I limiti teorici sulla direttività sono che deve essere ≥ 0 e ≤ 1. Un valore di 1 indica che la rotta è una grande rotta circolare e l'unico ritardo è dovuto alla velocità della luce nella fibra o agli elettroni nel rame. I valori> 1 in genere indicano la sorgente o la destinazione o entrambi hanno posizioni non corrette e pertanto rendono Directivity una diagnostica utile per le posizioni degli host. I valori tipici di direttività tra ricerca e siti educativi negli Stati Uniti, Canada, Europa, Asia orientale e Australia / Nuova Zelanda variano da 0,15 a 0,75 con una mediana di circa 0,4. Questo corrisponde a circa 4 volte più lentamente della velocità della luce nel vuoto. Valori bassi di direttività tipicamente indicano una rotta molto indiretta, o una connessione via satellite o lenta (ad esempio wireless)
Worldwide Directivity (983KB)
Raggruppamento
Man mano che aumenta il numero di coppie ospiti monitorate diventa sempre più necessario aggregare i dati in gruppi che rappresentano le aree di interesse. Abbiamo trovato utili le seguenti categorie di raggruppamento:

  • per area (ad es. Nord America, Europa occidentale, Giappone, Asia, paese, dominio di primo livello);
  • dalla separazione della coppia ospite (ad esempio collegamenti transoceanici, collegamenti intercontinentali, Internet scambio Punti);
  • Backbone del provider di servizi di rete a cui è connesso il sito remoto (ad es. ESnet, Internet 2, DANTE ...);
  • affiliazione di interessi comuni (ad esempio XIWT, HENP, collaborazione sperimentale come BaBar, i laboratori nazionali europei o DOE, interessi del programma ESnet, perfSONAR)
  • monitorando il sito;
  • un sito remoto visto da molti siti di monitoraggio. Dobbiamo essere in grado di selezionare i gruppi di controllo monitorando siti e siti remoti. Inoltre abbiamo bisogno della capacità di includere tutti i membri di un gruppo, di unire i gruppi e di escludere i membri di un gruppo.
Alcuni esempi di quante coppie remote-site di monitor-host PingER di ~ 1100 erano nei gruppi di aree globali e i gruppi di affinità possono essere trovati in Distribuzioni di raggruppamento di coppie PingER.

Allo stesso tempo è fondamentale scegliere attentamente i siti remoti e le coppie di host in modo che rappresentino le informazioni che si spera di scoprire. Abbiamo quindi selezionato un set di circa 50 "Siti Beacon" che sono monitorati da tutti i siti di monitoraggio e che sono rappresentativi dei vari gruppi di affinità a cui siamo interessati. Un esempio di grafico che mostra i tempi di risposta del ping per gruppi di siti è riportato di seguito :
Response history for groups of sites (39872 bytes) Loss history for groups of sites (37966 bytes)
Le percentuali mostrate a destra della legenda del grafico a perdita di pacchetti sono i miglioramenti (riduzione della perdita di pacchetti) al mese per la linea di tendenza esponenziale adatta ai dati di perdita di pacchetti. Si noti che un miglioramento del 5% / mese equivale al miglioramento del 44% / anno (ad esempio una perdita del 10% scenderebbe al 5,6% in un anno).

Senso Unico misure
SLAC sta inoltre collaborando al progetto perfSONAR per effettuare ritardi in un modo e misure di perdita tra i siti perfSONAR. Ogni sito perfSONAT ha un punto di misurazione costituito da un computer connesso a Internet con un ricevitore GPS. Ciò consente un'accurata sincronizzazione temporale dei pacchetti che consente le misurazioni del ritardo a senso unico. Le stime di ritardo generate sono più dettagliate di quelle di PingER e chiariscono l'asimmetria sui percorsi Internet nelle due direzioni. Per ulteriori informazioni sul confronto tra i due metodi, consultare Confronto di PingER e Surveyor.

RIPE ha anche un Prova il traffico progetto per effettuare misurazioni indipendenti dei parametri di connettività, come ritardi e vettori di routing in Internet. Un host RIPE è installato su SLAC.

L'NLANR Programma di misurazione attivo (AMP) per i beneficiari di HPC è inteso a migliorare la comprensione di come le reti ad alte prestazioni si comportano come visto dai siti e utenti partecipanti e per aiutare nella diagnosi dei problemi sia per gli utenti della rete che per i suoi fornitori. Installano una macchina FreeBSD montabile su rack nei siti e realizzano misurazioni ping attive a maglia piena tra le loro macchine, con i ping che vengono lanciati a intervalli di circa 1 minuto. Una macchina AMP è installata su SLAC.

I confronti più dettagliati di Surveyor, RIPE, PingER e AMP sono disponibili all'indirizzo Confronto di alcuni progetti di misurazione delle prestazioni end-to-end Internet Active.

SLAC è anche un sito NIMI (National Internet Measurement Infrastructure). Questo progetto può essere considerato come complementare al progetto Surveyor, in quanto (NIMI) è più focalizzato sulla fornitura dell'infrastruttura per supportare molte metodologie di misurazione come ping a senso unico, TReno, traceroute, PingER ecc.

La Waikato University in Nuova Zelanda sta anche distribuendo host Linux ciascuno con un ricevitore GPS e facendo in modo unidirezionale le misurazioni.  Per ulteriori informazioni su questo vedi Waikato's Risultati di ritardo pagina. A differenza dei progetti AMP, RIPE e Surveyor, il progetto Waikato effettua misurazioni passive, del traffico normale tra coppie esistenti, utilizzando firme di pacchetti basate su CRC per identificare i pacchetti registrati alle 2 estremità.

Il puntura Lo strumento di misurazione della rete basato su TCP è in grado di misurare attivamente la perdita di pacchetti in entrambi i percorsi di andata e ritorno tra coppie di host. Ha il vantaggio di non richiedere un GPS e di non essere soggetto a limitazione o blocco della velocità ICMP (secondo uno studio ISI ~ Il 61% degli host in Internet non risponde ai ping), tuttavia richiede una piccola modifica del kernel.

Se il ritardo a una via (D) è noto per entrambe le direzioni di una coppia di nodi Internet (a, b), allora il ritardo di andata e ritorno R può essere calcolato come segue:
R = Da => b + Db => a
dove Da => b è il ritardo a una via misurato dal nodo a al nodo b e viceversa.
La perdita P a due vie del pacchetto può essere derivata dalle perdite a senso unico (p) come segue:
P = pa => b + pb => a - pa => b * pb => a
dove pa => b è la perdita del pacchetto a senso unico dal nodo a verso b e viceversa.

Ci sono alcuni RFC IETF relativi a misurazione del ritardo a senso unico e perdita così come a ritardo di andata e ritorno.


Traceroute

Un altro strumento molto potente per diagnosticare i problemi di rete è traceroute. Ciò consente di trovare il numero di hop su un sito remoto e il modo in cui funziona il percorso.

John MacAllister di Oxford ha sviluppato Traceping Route Monitoring Statistics basato sulle utility standard traceroute e ping. Le statistiche sono state raccolte a intervalli regolari per periodi di 24 ore e hanno fornito informazioni sulla configurazione del routing, sulla qualità del percorso e sulla stabilità del percorso.

TRIUMF ha anche uno strumento Traceroute Map molto bello che mostra una mappa dei percorsi da TRIUMF a molti altri siti. Stiamo cercando di fornire una semplificazione di tali mappe per utilizzare i sistemi autonomi (AS) trasmessi piuttosto che i router.

Si può anche tracciare il Throughput FTP rispetto al conteggio hop del traceroute così come risposta ping e perdita di pacchetti per cercare correlazioni.

Appaiono molti siti che eseguono i server traceroute (è disponibile il codice sorgente (in Perl)) che aiutano nel debug e nella comprensione della topologia di Internet.

Alcuni siti forniscono accesso a utility di rete come nslookup per consentire a uno di scoprire ulteriori informazioni su un nodo particolare. Un paio di esempi sono SLAC e TRIUMF.


Glossario

  • CodePoint di servizi differenziati DSCP. The Differentiated Services CodePoint è 6 bit nel campo dell'intestazione IP che viene utilizzato per selezionare il comportamento per-hop di un pacchetto. I 6 bit per DSCP e 2 bit inutilizzati sono destinati a sostituire le definizioni esistenti dell'ottetto TOS IPv4, vedere RFC 2474 per ulteriori dettagli.
  • MTU Maximum Transfer Unit. L'unità di trasferimento massima è la dimensione più grande del datagramma IP che può essere trasferita utilizzando una connessione di collegamento dati specifica.
  • Dimensione massima del segmento MSS. MTU-40.
  • QBSS QBone Scavenger Services. QBone Scavenger Services è una classe aggiuntiva di servizio best-effort. Una piccola quantità di capacità di rete è allocata (in modo non rigido) per questo servizio; quando la capacità di sforzo ottimale predefinita è sottoutilizzata, QBSS può espandersi per consumare capacità inutilizzata.
  • Receive Window (Rwin) La dimensione del buffer TCP, il numero di pacchetti che la macchina invierà senza ricevere un ACK.

Ulteriori informazioni


cronUn cronjob chiama gli script appropriati. A SLAC questo cronjob è in pinger@pinger.slac.stanford.edu/.trs/crontab. Per PingER1 lo script è chiamato timeping.pl, per PingER2 è chiamato pinger2.pl. A SLAC gli script di PingER sono tutti in Perl e se non diversamente indicato si trovano nel percorso / afs / slac / package / netmon / pinger /
gatherI dati vengono raccolti su SLAC dallo script getdata.pl che utilizza Lynx per ottenere i dati dallo script CGI ping_data.pl in ogni sito di monitoraggio. Getdata.pl è chiamato giornalmente per raccogliere i dati nel sito di archiviazione SLAC. Viene chiamato dallo stesso cronjob delle chiamate timeping.pl (vedi sopra).
analysisInformazioni sulla catena di analisi degli script si possono trovare in: "Ripristino dei dati storici" che spiega l'intera catena di analisi.
pingtableIl principale meccanismo di reporting è tramite lo script pingtable.pl che in SLAC è memorizzato nel percorso CERI di PingER / afs / slac / g / www / cgi-wrap-bin / net / offsite_mon / pinghistory /.


Link utile: http://www.slac.stanford.edu/comp/net/wan-mon/tutorial.html


No comments:

Post a Comment