Why we need different levels of service?

Concreteness

• What is the goal of the network administrators?
• Why extend the model?
• Who chooses the service?
• Admission Control or Overprovisioning?

What is the goal?

The goal is to maximize benefits with utility functions.

Allocation among n users:

Vector S = { s₁, s₂ , …., s_n}

U_i – utility function of client i

U_i = f(s_i)

Max V = S U_i(s_i)

Some points about this scheme:

This scheme does not achieve fairness.

Pricing incentives are missing.

Different traffic types have different utility functions.

Bulk: ftp, telnet

utility

bandwidth

Real Time(completely rigid)

bandwidth

Completely rigid real-time applications don’t benefit until you reach a certain bandwidth.

Delay – Adaptive

bandwidth

You need a certain B/W to be happy.

Rate-Adaptive

utility

bandwidth

Should we stop admitting flows at some point?

Max V = S U_i(s_i)

Is there a local maxima of V as flow increases?

1 link: capacity B

n users

fair share: B/n

same utility function

V = n * U(B/n)

V(n) concave

n

For bulk, if we keep increasing users with concave utility function, then V keeps increasing.

V(n) Adaptive

n

Admission control makes sense for adaptive applications and not for bulk applications.

Link M/M/1

2 users

U₁ = 4 - 2d₁

U₂ = 4 – d₂

V = U₁ + U₂ d₁ + d₂ = 2

If d₁ = d₂ = 1

Then U₁=2 and U₂=3 and V=5

So the idea is to prioritize d₁ over d₂ to maximize V. (FIFO is no good)

Who should specify the service requirements?

• Network figures it out.

• How will network figure it out? Reclassifying?

• End users specify it

• Users have no incentive to ask for low service requirements.

1) Guaranteed Services Vs Predicted Services

2) Service Interface

3) Scheduling Discipline (FIFO, WFQ, FIFO+)

4)Admission Control

FIFO: complete sharing

WFQ: complete isolation

WFQ has this problem that when there are many bulk flows and a delay inelastic busty flow, then that round robin would be bad on that flow.

Scheduling Mean 99.9 %ile

WFQ 3.16 53.86

FIFO 3.17 34.72

FIFO+ : keep jitter low for packets in the same class

Idea: If the jitter of a packet is high at a switch compared to its class avg., then the next switch inserts the packet in the queue in the order as if it arrived at the expected time and not according to the actual arrival time.