Decoupling the Bandwidth and Latency Bounding for Table-based Schedulers

Abstract

The provision of Quality of Service (QoS)

Comparing the latency performance of the DTable and DRR schedulers

“…If the average packet size of the different flows is different, the bandwidth that the flows obtain may not be proportional to the number of table entries [8]. Figure 1 shows the performance of various table-based schedulers when there are four Virtual Channels (VCs) in the network.…”

“…In [8] we proposed a new table-based scheduling algorithm that works properly with variable packet sizes (as can be seen in Figure 1(c)). In order to do so, the DTable scheduler defines an arbitration table in which each table entry has associated a flow identifier and an entry weight.…”

“…In [8] we proposed a methodology to configure the DTable scheduler to decouple, at least partially, the bounding between the bandwidth and latency assignments. With this methodology we can assign the flows with a bandwidth varying between a minimum and a maximum value that depends not only on the number of table entries assigned, but also on two table configuration parameters.…”

“…However, even with this consideration, the DTable scheduler has not the problem of the increasing tag value and does not require the very complex hardware, including floating-point units, to manage the time tags, which is needed to implement the schedulers of the "sorted-priority" family of algorithms [8].…”

“…However, these schedulers do not work properly with variable packet sizes and face the problem of bounding the bandwidth and latency assignments [9,2]. In [8] we reviewed these problems and proposed a new tablebased scheduler, that works properly with variable packet sizes. Moreover, we proposed a decoupling methodology to configure this table-based scheduler without the bounding between bandwidth and latency.…”