1

Proposed Additional Use Cases for Congestion Exposure

draft-mcdysan-conex-other-usecases-00.txt

Dave McDysan

2

Outline

• Purpose– Use cases proposed in addition/extending to those in draft-

moncaster-conex-concepts-uses-01 • -02 had not been published prior to -00 deadline

– Focus was primarily on use case and NOT mechanism• Motivation and Background

– Primarily from Maastricht technical plenary focusing on “congestion pricing”

• Proposed Additional/Augmented Use Cases– Inequity of Heavy versus Light Users– Usage Tier/ Volume Feedback– Feedback on Time of Day, Day of Week Charging– Recharging for Implementing Congestion Pricing

• Recommendations

3

Motivation and Background• Value proposition centers on incentives (i.e., congestion pricing) and cost of

providing marginal capacity• Timescales of congestion pricing and example responses

– Short (ms to sec): ECN– Medium (min to hrs/days): Traffic Engineering– Long (mon to yrs): provisioning marginal capacity

• Challenges identified in Maastricht Technical Plenary not (completely) addressed by -01 use case draft– 20% of the users generate 80% of the traffic and create unfairness– Volume-based pricing makes it difficult for users to manage costs incurred– Customers will pay a premium for unmetered use– A form of congestion pricing is "recharging" (e.g., "free shipping") where

someone other than the end user pays for incurred congestion.– Some form of adaption, such as time-shifting, route-shifting, or moderating

demand is required to bottlenecks in service provider networks• If conex exposes congestion without damage (e.g., loss) then many forms of

adaption are feasible, as long as incentives are aligned with the signaled congestion

4

Inequity of Heavy versus Light Users

• Problem Summary– In some networks 20% of users are Heavy and generate 80% of

the traffic– In bandwidth tiered network, remaining 80% of users are light

but charged same as heavy users in same tier• Bandwidth tiers often implemented using a hierarchical scheduler,

with the outermost scheduler being a non-work conserving shaper (or policer)

– See DSL Forum/ BBF TR-059 for an example– Access network engineered for peak period and when near

capacity provisioning upgrade event, congestion can occur• During these time heavy users create much more congestion

volume (e.g., 16x) as compared with light users• Proposed Conex Use Case

– Feed forward/back regarding burstiness (e.g., short term peak/ longer term average) as a congestible resource

– Could be used as alternative method for incentives (charging, policing)

5

Usage Tier/ Volume Feedback

• Problem Summary– Complex for users to track usage and manage activity to make

price paid more predictable– Doesn’t address case where heavy users send at high rate for

fraction of usage measurement interval (e.g., only a few hours/days of a month).

– If usage counting done differently for congested and non-congested flows, then user’s tracking problem becomes more complex

• Proposed Conex Use Case– Feed forward and back (to sender) information regarding volume

tier (e.g., fraction used, run rate, predicted exhaust)– Sender could use feedback in several ways (e.g., slow down to

avoid congestion charges, agree to recharging)– Conex feedback could contain a authenticated pointer to above

information

6

Feedback on Time of Day, Day of Week Charging• Problem Summary

– Congestion occurs when offered load approaches provisioned capacity, which occurs shortly before need to provision additional capacity.

• Productive use of restoration capacity results in congestion occurring during peak periods AND failures,

• Reserved restoration capacity produces congestion during all peak periods– Without Conex, peak utilization of 70-80% occurs typically without loss occurs at

aggregate network bottlenecks– Assuming short term Conex achieves 90% utilization during peak periods, a gain

of 10-20% appears feasible– If traffic increases ~75% per year then short term Conex defers marginal capacity

provisioning by a small number of months– Looking over an entire day, typically 100-1000% unused capacity exists at

network bottlenecks.• Proposed Conex Use Case

– Congestion exposure supporting incentives (e.g, pricing) motivating users/content providers to time shift traffic to off-peak periods can defer need to provision marginal capacity by potentially years

• Authenticated feed forward information could increment different counters– Use of only historical traffic patterns insufficient since exceptional events do

occur, and longer term congestion exposure useful to handle these cases.

7

0%

20%

40%

60%

80%

100%

0:00 4:00 8:00 12:00 16:00 20:00

Out In

Traffic Growth and Capacity Provisioning Example

0%

20%

40%

60%

80%

100%

0:00 4:00 8:00 12:00 16:00 20:00

Out In

0%

20%

40%

60%

80%

100%

0:00 4:00 8:00 12:00 16:00 20:00

Out In

0%

20%

40%

60%

80%

100%

0:00 4:00 8:00 12:00 16:00 20:00

Out In

0%

20%

40%

60%

80%

100%

0:00 4:00 8:00 12:00 16:00 20:00

Out In

1Qx0 1Qx1 3Qx1 1Qx24Qx1 4Qx2

0%

20%

40%

60%

80%

100%

0:00 4:00 8:00 12:00 16:00 20:00

Out In

Short-term conex mechanism could defer marginal capacity provisioning approximately one Quarter (1Q) at these points

8

Example of Time Shifting Potential Reduction of Provisioned Capacity

0:00 4:00 8:00 12:00 16:00 20:00 0:00

Local Time

Re

lati

ve

Tra

ffic

Out In Unused

80% link utilization

Out is Network to UserIn is User to Network

• Unused capacity is 4x used capacity in this representative example

• Time shifting 2-5% of peak traffic achieves same provisioning deferral benefit as short-term conex

• More time shifting results in more benefit

9

Recharging for Implementing Congestion Pricing

• Problem Summary– Recharging (i.e., someone other than receiver pays) for usage

causing congestion is an important incentive not currently covered in use case draft

– Congestion can be for a shared, aggregate queue per current conex use case draft, and/or other congestible resources (e.g., burstiness measure, usage tier, time of day)

• Conex Use Case– Augment TCP (and/or higher layer protocols) to feedback one or

more congestion measures, e.g., short term but also with burstiness, usage tier, and/or Time of Day (or a pointer to this information)

– Include information in forward direction so that IP devices react appropriately (e.g., increment different counters)

– Authentication method needed to valid third party charging, prevent spoofing

10

Conclusions & Recommendations

• Shared queue serving aggregate traffic is not the only congestible resource in some service provider networks

• Longer-term conex easier to implement experimentally (i.e., software) as compared with per-packet short term conex (i.e., hardware)

• Include a summary of key points from the Maastricht technical plenary regarding “Congestion Pricing” in the wg use case draft– Propose using section 3 of this draft as starting point

• Include other use cases from section 4 in working group use case draft– Note those aspects which are (or are not) supported by current

version of abstract mechanism draft