Reference
[1]Congestion Exposure (ConEx) Concepts and Abstract Mechanism
http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-07
[2]TCP modifications for Congestion Exposure
http://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-04
[3] Mobile Communication Congestion Exposure Scenario
http://tools.ietf.org/html/draft-ietf-conex-mobile-02
What is Congestion Exposure? [1]
Congestion exposure (CONEX) is a mechanism that senders inform the networks of the congestion occurred in the past. Traditional congestion control is done between sender and receiver by exchanging explicit congestion notification (ECN)or droppi ng packets at Transport layer. CONEX enables senders to relay the congestion info rmation in IP layer, so all IP devices along the path can provide input to the traffic management.
Benefits?
example: ConEx as a form of differential QoS [1]
Most QoS approaches require the active participation of routers to
control the delay and loss characteristics for the traffic. For
real-time interactive traffic it is clear that low delay (and
predictable jitter) are critical, and thus these probably always need
different treatment at a router. However if low loss is the issue
then ConEx offers an alternative approach.
Assuming the ingress ISP has deployed a ConEx Ingress Policer, then
the only control on a user's traffic is dependent on the congestion
that user has caused. Likewise, if they are receiving traffic
through a ConEx Egress Policer then their ISP will impose traffic
controls (prioritisation, rate limiting, etc) based on the congestion
they have caused. If an end-user (be they the receiver or sender)
wants to prioritise some traffic over other traffic then they can
allow that traffic to generate or cause more congestion. The price
they will pay will be to reduce the congestion that their other
traffic causes.
Streaming video content-delivery is a good candidate for such ConEx-
mediated QoS. Such traffic can tolerate moderately high delays, but
there are strong economic pressures to maintain a high enough data
rate (as that will directly influence the Quality of Experience the
end-user receives. This approach removes the need for bandwidth
brokers to establish QoS sessions, by removing the need to coordinate
requests from multiple sources to pre-allocate bandwidth, as well as
to coordinate which allocations to revoke when bandwidth predictions
turn out to be wrong. There is also no need to "rate-police" at the
boundaries on a per-flow basis, removing the need to keep per-flow
state (which in turn makes this approach more scalable).
[2]With CONEX, accurate downstream path information would be visible to
ingress network operators, which can respond to incipient congestion
in time. This can be equivalent to offering different levels of QoS,
e.g. premium service with zero congestion response.
Again, CONEX could be used in two different ways:
1. as additional information to assist network functions to impose
different QoS for different application sessions; and
2. as a tool to let applications decide on their response to
congestion notification, while incentivizing them to react (in
general) appropriately, e.g., by enforcing overall limits for
congestion contribution or by accounting and charging for such
congestion contribution.
