1
00:00:00,630 --> 00:00:04,860
Diamo un'occhiata ad alcuni dei meccanismi di accodamento della gestione della congestione.

2
00:00:04,860 --> 00:00:06,960
Esistono molti meccanismi di accodamento.

3
00:00:07,110 --> 00:00:12,990
Alcuni di questi sono più vecchi o inefficienti per le moderne reti Rich Media.

4
00:00:12,990 --> 00:00:19,290
In altre parole, erano buoni in passato ma non sono buoni per voice over IP e video in esecuzione

5
00:00:19,290 --> 00:00:21,200
su una rete di dati.

6
00:00:21,210 --> 00:00:25,410
Quindi iniziamo con una coda FIFO First In First Out.

7
00:00:25,410 --> 00:00:32,100
È costituito da una singola coda con pacchetti inviati nell'ordine esatto in cui sono arrivati.

8
00:00:32,100 --> 00:00:36,780
Probabilmente tutti abbiamo sperimentato questo meccanismo di accodamento nel mondo reale.

9
00:00:36,840 --> 00:00:41,260
In questo esempio abbiamo persone che vogliono pagare per i loro acquisti.

10
00:00:41,280 --> 00:00:44,460
C'è solo un cassiere al quale possono pagare.

11
00:00:44,460 --> 00:00:48,120
Le persone vengono servite in ordine di primo arrivato, primo servito.

12
00:00:48,150 --> 00:00:49,870
In altre parole, First In First Out.

13
00:00:50,010 --> 00:00:51,450
Questa signora è arrivata per prima.

14
00:00:51,480 --> 00:00:53,490
Quindi ha servito per prima.

15
00:00:53,580 --> 00:00:58,690
Questo signore è arrivato secondo, quindi ha servito un secondo e così via.

16
00:00:58,710 --> 00:01:00,080
Questa è la parte anteriore della coda.

17
00:01:00,090 --> 00:01:03,810
Questo è il retro della coda e le persone vengono servite in questo ordine.

18
00:01:05,200 --> 00:01:13,180
Allo stesso modo in un algoritmo di accodamento FIFO su un pacchetto rota vengono serviti nell'ordine in cui sono arrivati.

19
00:01:13,180 --> 00:01:14,320
Questa è la parte anteriore della coda.

20
00:01:14,320 --> 00:01:20,440
Questo è il retro della coda in cui i nuovi pacchetti sono in coda nei pacchetti posteriori nella parte anteriore della

21
00:01:20,880 --> 00:01:24,000
coda o D in coda e inoltrati per la trasmissione.

22
00:01:24,010 --> 00:01:30,820
Il problema con questo meccanismo di accodamento è che i pacchetti vocali possono essere ritardati da pacchetti di dati più grandi.

23
00:01:30,820 --> 00:01:36,910
Ognuno è servito nello stesso modo che potrebbe funzionare bene in alcuni casi nel mondo reale,

24
00:01:36,910 --> 00:01:41,530
ma che non funzionerebbe come esempio se ci fosse un'emergenza e un'ambulanza.

25
00:01:41,530 --> 00:01:47,620
Ad esempio, per andare in coda alla coda e un camion che trasporta cemento

26
00:01:47,620 --> 00:01:51,160
o merci secche, ad esempio, dovrebbe aspettare l'ambulanza.

27
00:01:51,160 --> 00:01:56,560
Non vuoi un camion o un camion che si muove lentamente di fronte a un'ambulanza.

28
00:01:56,560 --> 00:02:01,690
Volete che un'ambulanza vada in prima fila nello stesso modo in cui volete che i pacchetti vocali siano in

29
00:02:01,690 --> 00:02:03,430
grado di andare in prima fila.

30
00:02:03,580 --> 00:02:10,810
Quindi FIFO non è buono per voce e video, un altro meccanismo di accodamento più vecchio è una chiave carina.

31
00:02:10,830 --> 00:02:17,330
Questo è costituito da code complete che sono servite in un rigoroso ordine di priorità e questo algoritmo di accodamento

32
00:02:17,330 --> 00:02:20,000
che abbiamo avuto per segnali un mezzo alto.

33
00:02:20,030 --> 00:02:27,680
Chiave normale e bassa applicando una proprietà rigorosa, le code con priorità più bassa vengono servite solo quando i segnali

34
00:02:27,680 --> 00:02:31,740
proteici più alti sono vuoti, quindi quando arriva il traffico.

35
00:02:31,770 --> 00:02:38,250
Se è classificato come importante, viene inserito nella classificazione chiave ad alta priorità che potrebbe essere

36
00:02:38,250 --> 00:02:42,830
eseguita sul protocollo o sull'interfaccia sorgente o su altri criteri.

37
00:02:42,960 --> 00:02:49,020
Il traffico nella coda ad alta priorità viene sempre gestito per primo solo quando le code alta e media

38
00:02:49,020 --> 00:02:51,740
sono vuote quando viene elaborata la coda normale.

39
00:02:52,230 --> 00:02:59,010
La coda a bassa priorità viene elaborata solo quando le code medio alta e normale sono vuote.

40
00:02:59,250 --> 00:03:00,720
Quindi questo è il problema.

41
00:03:00,720 --> 00:03:07,980
La coda a bassa priorità potrebbe morire di fame se c'è traffico costante nelle code medio alte o normali, quindi le

42
00:03:08,790 --> 00:03:13,550
code a bassa priorità potrebbero essere affamate da code a priorità più alta.

43
00:03:13,560 --> 00:03:19,450
Era un meccanismo più vecchio che andava bene in passato ma non funziona bene per le reti moderne.

44
00:03:19,530 --> 00:03:26,550
Un guadagno in una coda di partito è che abbiamo code complete alta media normale e bassa Le code ad alta priorità

45
00:03:26,550 --> 00:03:29,610
sono sempre gestite prima delle code a bassa priorità.

46
00:03:29,610 --> 00:03:34,890
Il problema qui è che potrebbe provocare la fame di code con priorità inferiore.

47
00:03:35,190 --> 00:03:38,090
Un terzo algoritmo di accodamento è l'accodamento personalizzato.

48
00:03:38,100 --> 00:03:44,490
È composto da un massimo di 16 code servite in modo circolare per prevenire la fame.

49
00:03:44,520 --> 00:03:46,920
Fornisce garanzie sul traffico.

50
00:03:46,980 --> 00:03:54,020
Il problema con questo metodo è tuttavia che non fornisce una priorità rigorosa per il traffico in tempo reale.

51
00:03:54,020 --> 00:03:59,790
Quindi, ad esempio, abbiamo pacchetti in arrivo che sono classificati in varie code che possono essere

52
00:03:59,790 --> 00:04:03,380
fino a 16 di essi possono avere dimensioni diverse.

53
00:04:03,420 --> 00:04:08,820
Quindi potresti fornire maggiore larghezza di banda ad alcune code rispetto ad altre code.

54
00:04:08,820 --> 00:04:14,700
Il problema con l'accodamento personalizzato, tuttavia, è che se si riceve traffico vocale importante, verrà gestito

55
00:04:14,760 --> 00:04:21,810
solo a turno o a sua volta, quindi un esempio di voce viene elaborato di tanto in tanto, quindi

56
00:04:21,810 --> 00:04:26,760
è il turno della seconda coda e di un nuovo pacchetto vocale arriva.

57
00:04:26,760 --> 00:04:34,090
Quel nuovo pacchetto vocale non verrà elaborato fino alla quinta Q4 Q4 e fino alla coda 16

58
00:04:34,090 --> 00:04:41,840
viene revisionato e poi torna agli utenti di accodare i clienti vocali uno scheduler di accodamento round robin.

59
00:04:42,620 --> 00:04:48,950
Quindi, una volta elaborata la voce, diventa il turno del secondo tasto lo scheduler non ritorna alla prima

60
00:04:48,950 --> 00:04:54,490
coda o alla coda La voce finché non viene elaborata tutte le altre code.

61
00:04:54,620 --> 00:04:57,700
Quindi il problema con questo metodo è che introduce un ritardo.

62
00:04:57,870 --> 00:05:05,180
Non c'è priorità per la voce, quindi il traffico vocale viene spesso ritardato, il che introduce ritardo e Jetta e

63
00:05:05,180 --> 00:05:07,130
influisce sulla qualità della voce.

64
00:05:07,130 --> 00:05:16,190
Quindi né l'accodamento delle feste FIFO né l'accodamento personalizzato sono ideali per una rete moderna, un quarto algoritmo è

65
00:05:16,190 --> 00:05:17,680
ponderato per l'accodamento.

66
00:05:17,690 --> 00:05:25,040
Questo è un algoritmo che divide la larghezza di banda di Internet per il numero di flussi, cercando così di garantire

67
00:05:25,040 --> 00:05:29,280
una corretta distribuzione della larghezza di banda per tutte le applicazioni.

68
00:05:29,420 --> 00:05:36,830
Fornisce generalmente un buon servizio per il traffico in tempo reale, ma non sono garanzie di larghezza di banda per

69
00:05:37,010 --> 00:05:40,970
flussi particolari e alcuni flussi possono effettivamente arrestare altri flussi.
