Loading…

Scheduling policies for real-time and non-real-time traffic in a statistical multiplexer

The performance of several policies for scheduling real-time and non-real-time messages in a statistical multiplexer is examined. The performance metric for the real-time traffic is the percentage of messages not transmitted within their deadlines; the performance metric for the non-real-time traffi...

Full description

Saved in:
Bibliographic Details
Main Authors: Chipalkatti, R., Jurose, J.F., Towsley, D.
Format: Conference Proceeding
Language:eng ; jpn
Subjects:
Online Access:Request full text
Tags: Add Tag
No Tags, Be the first to tag this record!
Description
Summary:The performance of several policies for scheduling real-time and non-real-time messages in a statistical multiplexer is examined. The performance metric for the real-time traffic is the percentage of messages not transmitted within their deadlines; the performance metric for the non-real-time traffic is the average delay. The scheduling policies are: (1) first-come first-served (FCFS); (2) head of the line priority, in which real-time packets are given priority; (3) minimum-laxity threshold (MLT) policy; and (4) queue-length threshold (QLT) policy. Under the MLT policy, priority is given to the real-time traffic when the minimum laxity is below some threshold. The QLT policy gives priority to the non-real-time traffic whenever the number of queued non-real-time packets is above some threshold. Results show that the FCFS policy causes relatively high losses for the real-time traffic while providing relatively low message delays for the non-real-time traffic; the converse holds true for the strict priority discipline. Both the MLT and QLT disciplines allow the designer to explicitly trade off the performance realized by each traffic class by using an appropriately chosen value for the threshold parameter. Little difference is observed in the performance tradeoffs available, so it is concluded that the QLT policy is more practical, as it is simpler to implement.< >
DOI:10.1109/INFCOM.1989.101526