FYI -- Congestion Exposure (CONEX) BoF in Hiroshima

[Leslie Daigle <leslie at thinkingcat.com>]

Hi,

I just wanted to give a heads-up about the Congestion Exposure (CONEX) 
Bof in Hiroshima - currently scheduled for Tues 15.20 – 18.10.

While CONEX is clearly Transport work, there are implications for 
applications do/not have to do in order to work well with networks, so I 
thought it might be of interest, here.


Best,

Leslie Daigle  & Philip Eardley (BoF Chairs)

Congestion Exposure (CONEX)
(was re-ECN)

Description

Congestion Exposure (ConEx) is a proposed new IETF activity to enable 
congestion to be exposed along the forwarding path of the Internet. By 
revealing expected congestion in the IP header of packets, congestion 
exposure provides a generic network capability which allows greater 
freedom over how capacity is shared. Such information could be used for 
many purposes, including congestion policing, accountability and 
inter-domain SLAs. It may also open new approaches to QoS and traffic 
engineering.

The Internet is, in essence, about pooling resources. The ability to 
share capacity has been paramount to its success and has traditionally 
been managed through the voluntary use of TCP congestion control. 
However, TCP alone is unable to prevent bandwidth intensive 
applications, such as peer-to-peer or streaming video, from causing 
enough congestion over time to severely limit the user-experience of 
many other users. This has led ISPs to deploy ad-hoc solutions such as 
volume accounting, rate policing and deep packet inspection in an 
attempt to distribute capacity differently. The consequences of such 
practices are increasingly leading to calls for government regulations 
and stifling innovation at the transport and application layer (see for 
example, the problem statement I-D (ref below) and RFC5594).

We believe these problems stem from the lack of a network-layer system 
for accountability -- among all parties -- for sending traffic which 
causes congestion. We propose a metric where IP packets carry 
information about the expected rest-of-path congestion, so that any 
network node may estimate how much congestion it is likely to cause by 
sending or forwarding traffic. A network operator can then count the 
volume of congestion about to be caused by an aggregate of traffic as 
easily as it can count the volume of bytes entering its network today. 
Once ISPs can see rest-of-path congestion, they can discourage users 
from causing large volumes of congestion, discourage other networks from 
allowing their users to cause congestion, and more meaningfully 
differentiate between the qualities of services offered from potential 
connectivity partners. Meanwhile end-hosts may be freed from rate 
restrictions where their traffic causes little congestion.

The purpose of the BoF is to explore the support for and viability of 
pursuing an IETF activity to define a basic protocol to expose the 
expected rest-of-path congestion in the IP header. Any such protocol 
should work with minimal changes to the existing network, in particular 
it should work with unmodified routers. There is already one existing 
proposal that builds on ECN to provide rest-of-path congestion 
information in IP headers and other proposals may come forward.

If supported, an eventual WG would focus on the development of its 
chosen congestion exposure protocol as its main work item. The chosen 
protocol will need to be deployable with minimal changes to the existing 
Internet, preferably working with unmodified routers. Additional work 
items could include detailing the motivations for congestion exposure, a 
threat analysis of the subsequent protocol, reporting on experimental 
trials and describing deployment considerations. Importantly, the 
proposed WG would encourage experimentation but not deliberate on how 
congestion exposure should be used: our concern would be how flexibly 
the resulting protocol can support differing needs at run-time, rather 
than dictating a particular usage at design time.

Related Internet-Drafts include:

ConEx Problem statement:
 http://tools.ietf.org/id/draft-moncaster-congestion-exposure-problem
re-ECN protocol spec:
 http://tools.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp
re-ECN motivation:
 http://tools.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-motivation

Other useful reference material:

Overview: problem & solution (7pp):
 http://www.bobbriscoe.net/projects/refb/FairerFasterWP.pdf

Mailing list for discussion:  re-ecn at ietf.org
Subscribe:  https://www.ietf.org/mailman/listinfo/re-ecn

--

-------------------------------------------------------------------
"Reality:
     Yours to discover."
                                -- ThinkingCat
Leslie Daigle
leslie at thinkingcat.com
-------------------------------------------------------------------