Proposed Additional Use Cases for
Congestion Exposure
draft-mcdysan-conex-other-usecases-00.txt
Dave McDysan
1
Outline
• Purpose
– Use cases proposed in addition/extending to those in draftmoncaster-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
2
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
3
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)
4
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 noncongested 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
5
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.
6
Traffic Growth and Capacity Provisioning Example
Out
Out
In
In
Out
100%
100%
100%
80%
80%
80%
60%
60%
60%
40%
40%
40%
20%
20%
20%
0%
0:00
4:00
0%
0:00
8:00 12:00 16:00 20:00
1Qx0
In
100%
80%
60%
40%
20%
0%
0:00
4:00
8:00 12:00 16:00 20:00
0%
0:00
8:00 12:00 16:00 20:00
3Qx1
1Qx1
Out
4:00
4Qx1
Out
4:00
8:00 12:00 16:00 20:00
1Qx2
100%
80%
80%
60%
60%
40%
40%
20%
20%
4:00
8:00 12:00 16:00 20:00
4Qx2
Out
In
100%
0%
0:00
Short-term
conex
mechanism
could defer
marginal
capacity
provisioning
approximatel
y one
Quarter (1Q)
at these
points
In
0%
0:00
4:00
In
8:00 12:00 16:00 20:00
7
Example of Time Shifting Potential Reduction of
Provisioned Capacity
80% link
utilization
Relative Traffic
• 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
0:00
4:00
8:00
12:00
16:00
20:00
0:00
Local Time
Out is Network to User
In is User to Network
Out
In
Unused
8
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
9
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
10