Figure 7: Scheduling per priorità non-preemptive

E' necessario stabile una policy sul trattamento delle code in ingresso allo scheduler. In particolare, si deve decidere come e quando prendere i pacchetti da una determinata coda. Uno schema di principio potrebbe basarsi sul prendere il prossimo pacchetto dalla coda di più alta priorità che è non vuota (L'attribuzione ad una coda potrebbe essere basata sia su di un marking specifico del pacchetto, sia ad esempio sul numero di porta destinazione).

Questo principio di base può essere applicato in diversi modi, ad esempio è possibile stabilire se si deve interrompere il lavoro di invio di un pacchetto se in quel momento ne arriva un altro di priorità maggiore. Con quest'ultimo meccanismo, che viene indicato come preemptive, si ha un notevole incremento di complessità nella gestione dell'algoritmo. In Figure 7 è presentato un esempio di scheduling per priorità non-preemptive.

Una soluzione alternativa prevede l'utilizzo di uno scheduling round robin, ossia, lo schedulatore esamina una per volta le code di priorità e seleziona un pacchetto per ogni coda che non è vuota. Pero' questo meccanismo non garantisce alcuna QoS se non si adotta una queue discipline, in altre parole se le code sono tutte piene allo stesso modo non si ha QoS, se invece si adopera un meccanismo come quello presentato nei paragrafi precedenti in cui le code a maggior priorità sono più corte, allora la QoS è rispettata. In Figure 8 è riportato l'esempio precedente ma adottando uno scheduling round robin.

Figure 8: Scheduling round robin

Lo scheduling round robin presenta una ulteriore problematica. Fino ad ora si è dato per scontato che i pacchetti fossero tutti della stessa dimensione, ma se così non fosse, i pacchetti di dimensione più grande sarebbero avvantaggiati, poiché occuperebbero maggior tempo del router a svantaggio dei pacchetti più piccoli.

Una ulteriore decisione è se adottare un algoritmo work conserving. Questi algoritmi fanno sempre lavorare lo schedulatore finché c'è qualcosa in una delle code. Una scelta per un algoritmo non work conserving potrebbe essere dettata dalla necessità di contenere il jitter per pacchetti di priorità più alta. In realtà attualmente questa è un'ipotesi non verosimile e quindi le reti adoperano sempre algoritmi work conserving.