Handling Traffic 2

DESCRIPTION: Note: It is required that you have solved the question handling_traffic before attempting this to ensure you have complete context of the problem.

If you think about the arbiter we designed earlier in the problem handling_traffic, you will realize that despite ensuring fairness among all the unique channels, its configurability requires improvement. For example, that arbiter does not provide the following features A channel is awarded a grant based on its weight irrespective of whether or not it needs access. I.e precious bandwidth can go wasted if that channel doesn’t require access at that point of time. The customer who purchases the highest bandwidth also gets the highest priority in the time window. This is a constraint that may not always be desirable in the real world. Someone might have a tighter latency requirement despite not having much data to send on the line. They would unnecessarily be purchasing extra bandwidth. Customers may require a different share of the bandwidth at different times in the day. Forcing the weights to be static configurations prevents this flexibility. Some customers may block others for an unfair amount of time by purchasing a large chunk of the available bandwidth. This may not be acceptable for ethical reasons. (imagine some billionaire purchased access to the road in front of your house and now you get to use it only once a day).

We shall be addressing all these problems in this iteration of the problem. Before proceeding. I highly suggest you pause and think about how you would modify the design to fix all 4 issues.

PROBLEM STATEMENT:

Implement the following upgraded arbitration scheme: