Subject: [re-ECN] FW: New Version Notification for draft-moncaster-conex-problem-00

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 1 Mar 2010 20:09:36 -0500

Leslie and Phil,

I volunteered to take on the editing of moncaster-congestion-exposure-problem-03 from Toby Moncaster. To ensure that this draft is firmly identified with the Conex work, the new draft is called draft-moncaster-conex-problem-00, <http://tools.ietf.org/html/draft-moncaster-conex-problem-00>.

This version includes some edits from Bob Briscoe and updates to the references.

In the works for -01 are significant changes suggested by Michael Menth, and (hopefully) some improvements to the Use Cases section.

If there are any other suggested changes to this draft, please send them my way and I'll do my best to incorporate them. Thanks.

-- Rich

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Monday, March 01, 2010 7:43 PM
To: Woundy, Richard
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Woundy, Richard
Subject: New Version Notification for draft-moncaster-conex-problem-00 

A new version of I-D, draft-moncaster-conex-problem-00.txt has been successfuly submitted by Richard Woundy and posted to the IETF repository.

Filename:	 draft-moncaster-conex-problem
Revision:	 00
Title:		 The Need for Congestion Exposure in the Internet
Creation_date:	 2010-03-01
WG ID:		 Independent Submission
Number_of_pages: 22

Abstract:
Today's Internet is a product of its history.  TCP is the main
transport protocol responsible for sharing out bandwidth and
preventing a recurrence of congestion collapse while packet drop is
the primary signal of congestion at bottlenecks.  Since packet drop
(and increased delay) impacts all their customers negatively, network
operators would like to be able to distinguish between overly
aggressive congestion control and a confluence of many low-bandwidth,
low-impact flows.  But they are unable to see the actual congestion
signal and thus, they have to implement bandwidth and/or usage limits
based on the only information they can see or measure (the contents
of the packet headers and the rate of the traffic).  Such measures
don't solve the packet-drop problems effectively and are leading to
calls for government regulation (which also won't solve the problem).

We propose congestion exposure as a possible solution.  This allows
packets to carry an accurate prediction of the congestion they expect
to cause downstream thus allowing it to be visible to ISPs and
network operators.  This memo sets out the motivations for congestion
exposure and introduces a strawman protocol designed to achieve
congestion exposure.

The IETF Secretariat.

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 01 Mar 2010 20:17:41 -0500

Thanks, Rich.  Will have a look.

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 02 Mar 2010 10:11:46 +0000

Leslie,

Currently both the old -03 and the new -00 are live, because of the 
name change, which is confusing.

Am I correct that a chair can link a name change to the previous 
name? So that if people access the old draft, it points to the new. 
Or is this only for WG docs?

In the mean time, I've updated the link to this doc on the Wiki:
<http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN>

Bob

At 01:17 02/03/2010, Leslie Daigle wrote:

>>I volunteered to take on the editing of 
>>moncaster-congestion-exposure-problem-03 from Toby Moncaster. To 
>>ensure that this draft is firmly identified with the Conex work, 
>>the new draft is called draft-moncaster-conex-problem-00, 
>><http://tools.ietf.org/html/draft-moncaster-conex-problem-00>.
>>In the works for -01 are significant changes suggested by Michael 
>>Menth, and (hopefully) some improvements to the Use Cases section.
>>If there are any other suggested changes to this draft, please send 
>>them my way and I'll do my best to incorporate them. Thanks.
>>-- Rich
>>From: IETF I-D Submission Tool [mailto:[email-masked]] Sent: 
>>Monday, March 01, 2010 7:43 PM
>>To: Woundy, Richard
>>Cc: [email-masked]; [email-masked]; 
>>[email-masked]; [email-masked]; 
>>[email-masked]; Woundy, Richard
>>A new version of I-D, draft-moncaster-conex-problem-00.txt has been 
>>successfuly submitted by Richard Woundy and posted to the IETF repository.
>_______________________________________________
>re-ECN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Leslie Daigle <[email-masked]>
Date: Sun, 07 Mar 2010 18:34:01 -0500

Hi,

Some comments & suggestions from me as an individual, not bof co-chair, 
and following up some of the points recently raised on the list as we 
try to get clarity.

I think it's important to focus the problem statement on the generative 
technology that is congestion exposure -- which makes it independent of 
any potential applications or services (use cases) built with it, or of 
any implementation.  So, here are some suggestions for turning the crank 
to do that.

> 
> 1.  Introduction
> 
>    The Internet has grown from humble origins to become a global
>    phenomenon with billions of end-users able to share the network and
>    exchange data and more.  One of the key elements in this success has
>    been the use of distributed algorithms such as TCP that share
>    capacity while avoiding congestion collapse.  These algorithms rely
>    on the end-systems altruistically reducing their transmission rate in
>    response to any congestion they see.
> 
>    In recent years ISPs have seen a minority of users taking a larger

Reading through the document again, I was struck by the focus on "ISPs". 
  Perhaps one of the ways to emphasize the "inter-network" aspect of 
this proposal is to back out of that:  remove all instances of "ISP" in 
this document, and focus the text on networks, whatever their type.

(That said, the access network example here is a fair illustration of 
one possible cases, and the text is probably helpful.  As long as it 
doesn't distract the reader from pausing to imagine other, completely 
different, network and network-to-network situations that could be 
addressed with congestion exposure).

>    share of the network by using applications that transfer data
>    continuously for hours or even days at a time and even opening
>    multiple simultaneous TCP connections.  This issue became prevalent
>    with the advent of "always on" broadband connections.  Frequently
>    peer to peer protocols have been held responsible [RFC5594] but
>    streaming video traffic is becoming increasingly significant.  In
>    order to improve the network experience for the majority of their
>    customers, many ISPs have chosen to impose controls on how their
>    network's capacity is shared rather than continually buying more
>    capacity.  They calculate that most customers will be unwilling to
>    contribute to the cost of extra shared capacity if that will only
>    really benefit a minority of users.  Approaches include volume
>    counting or charging, and application rate limiting.  Typically these
>    traffic controls, whilst not impacting most customers, set a
>    restriction on a customer's level of network usage, as defined in a
>    "fair usage policy".

The latter part of this paragraph seems to become a bit of a distraction 
from a problem statement about a specific technology?  It's fairly far 
into business practices of the moment.  I appreciate that it is 
illustrating some *bad* traffic control practices, but it would perhaps 
be better to spell out how these practices break networking than simply 
citing them as actions.  That may go to Alissa & Hannes' point about 
describing the shortcomings of current technologies.

> 
>    We believe that such traffic controls seek to control the wrong
>    quantity.  What matters in the network is neither the volume of
>    traffic nor the rate of traffic, it is the contribution to congestion
>    over time - congestion means that your traffic impacts other users,
>    and conversely that their traffic impacts you. 

 >  So if there is no
>    congestion there need not be any restriction on the amount a user can
>    send; restrictions only need to apply when others are sending traffic
>    such that there is congestion.  

Could this paragraph spell out the network-technology reasons why 
traffic should not be restricted in the absence of congestion?  Or is 
that getting into a choice, question?  I.e., this seems to state a 
business choice (don't restrict your customers in the absence of 
congestion) rather than a network technology reality, and I think this 
document needs to stay focused on the former.

 >In fact some of the current work at
>    the IETF [LEDBAT] and IRTF [CC-open-research] already reflects this
>    thinking.  For example, an application intending to transfer large
>    amounts of data could use LEDBAT to try to reduce its transmission
>    rate before any competing TCP flows do, by detecting an increase in
>    end-to-end delay (as a measure of incipient congestion).  However
>    these techniques rely on voluntary, altruistic action by end users
>    and their application providers.  ISPs cannot enforce their use.
>    This leads to our second point.

The above is a fine place to excise "ISP".  The point is well taken that 
LEDBAT and CONEX can play well together.  Everything else speaks to 
motivations of individuals, which seems beyond the scope of a problem 
statement for a generative technology, IMO.

(It's not that I'm disagreeing with it as a statement of reality; just 
trying to suggest where to level the document up a bit).

> 
>    The Internet was designed so that end-hosts detect and control
>    congestion.  We believe that congestion needs to be visible to
>    network nodes as well, not just to the end hosts.  More specifically,

And this is very true, and well motivated, even if "ISP" is excised, above.
> 
> 
> 
> Moncaster, et al.       Expires September 2, 2010               [Page 4]
> 
>  
> Internet-Draft         Congestion Exposure Problem            March 2010
> 
> 
>    a network needs to be able to measure how much congestion traffic
>    causes between the monitoring point in the network and the
>    destination ("rest-of-path congestion").  This would be a new
>    capability; today a network can use explicit congestion notification
>    (ECN) [RFC3168] to detect how much congestion traffic has suffered
>    between the source and a monitoring point in the network, but not

This para, to here, should probably find its way earlier in the 
document, because it goes to the heart of the matter.

>    beyond.  Such a capability would enable an ISP to give incentives for
>    the use, without restrictions, of LEDBAT-like applications whilst
>    perhaps restricting excessive use of TCP and UDP ones.

Excise ISP.  Perhaps, "Such a capability would enable networks to 
support LEDBAT-enabled applications in adjusting their use of network 
capacity over time.  This would provide motivation for deploying 
LEDBAT-enabled applications, as other applications will be unable to 
make full use of network availability."

> 
>    So we propose a new approach which we call congestion exposure.  We
>    propose that congestion information should be made visible at the IP
>    layer, so that any network node can measure the contribution to
>    congestion of an aggregate of traffic as easily as straight volume
>    can be measured today.  Once the information is exposed in this way,
>    it is then possible to use it to measure the true impact of any
>    traffic on the network.  Lacking the ability to see congestion, some
>    ISPs count the volume each user transfers.  On this basis LEDBAT

s/ISPs/networks/

>    applications would get blamed for hogging the network given the large
>    amount of volume they transfer.   However, because they yield rather
>    than hog, they actually contribute very little to congestion.  One
>    use of exposed congestion information would be to measure the
>    congestion attributable to a given user, and thereby incentivise the
>    use of protocols such as [LEDBAT] which aim to reduce the congestion
>    caused by bulk data transfers.

I think this is getting beyond the problem statement of the basic 
technology?  It posits a possible future, but is heavily tied up in 
possible motives of network operators (ISPs or otherwise).

> 
>    Creating the incentive to deploy low-congestion protocols such as
>    LEDBAT is just one of many motivations for congestion exposure.  In
>    general, congestion exposure gives ISPs a principled way to hold
>    their customers accountable for the impact on others of their network
>    usage and reward them for choosing congestion-sensitive applications.
>    It can measure the impact of an individual consumer, a large
>    enterprise network or the traffic crossing a border from another ISP
>    - anywhere where volume is used today as a (poor) measure of usage.
>    In Section 7, a range of potential use cases for congestion exposure
>    are given, showing it is possible to imagine a wide range of other
>    ways to use the exposed congestion information.

I think the para above is driving at an important point -- the 
granularity of choices that will be available at nodes within the 
network.  However, as written, it is too steeped in a specific part of 
the network (the edge), and business motivations at that part of the 
network, to really carry home the architectural point.

> 
> 1.1.  Definitions
> 
>    Throughout this document we refer to congestion repeatedly.
>    Congestion has a wide range of definitions.  For the purposes of this
>    document it is defined using the simplest way that it can be measured
>    - the instantaneous fraction of loss.  More precisely, congestion is
>    bits lost divided by bits sent, taken over any brief period.  By
>    extension, if explicit congestion notification (ECN) is being used,
>    the fraction of bits marked (rather than lost) gives a useful metric
>    that can be thought of as analagous to congestion.  Strictly
> 
> 
> 
> Moncaster, et al.       Expires September 2, 2010               [Page 5]
> 
>  
> Internet-Draft         Congestion Exposure Problem            March 2010
> 
> 
>    congestion should measure impairment, whereas ECN aims to avoid any
>    loss or delay impairments due to congestion.  But for the purposes of
>    this document, the two will both be called congestion.
> 
>    We also need to define two specific terms carefully:
> 
>    Upstream Congestion:  The congestion that has already been
>       experienced by a packet as it travels along its path.  In other
>       words at any point on the path it is the congestion between that
>       point and the source of the packet.
> 
>    Downstream Congestion:  The congestion that a packet still has to
>       experience on the remainder of its path.  In other words at any
>       point it is the congestion still to be experienced as the packet
>       travels between that point and its destination.
> 
> 1.2.  Changes from previous versions
> 
>    From -03 to -04 (current version):
> 
>          Many edits throughout per comments from Bob Briscoe about the
>          intentions of ConEx.
> 
>          References section updated; reference to Comcast congestion
>          management system added as ISP example.
> 
>          NOTE: there are still sections needing more work, especially
>          the Use Cases.  The whole document also needs trimming in
>          places and checking for repetition or omission.
> 
>    From -02 to -03:
> 
>          Abstract re-written again following comments from John Leslie.
> 
>          Use Cases Section re-written.
> 
>          Security Considerations section improved.
> 
>          This ChangeLog added.
> 
>    From -01 to -02:
> 
>          Extensive changes throughout the document:
> 
>          +  Abstract and Introduction re-written.
> 
>          +  The Problem section re-written and extended significantly.
> 
> 
> 
> 
> Moncaster, et al.       Expires September 2, 2010               [Page 6]
> 
>  
> Internet-Draft         Congestion Exposure Problem            March 2010
> 
> 
>          +  Why Now?  Section re-written and extended.
> 
>          +  Requirements extended.
> 
>          +  Security Considerations expanded.
> 
>          Other less major changes throughout.
> 
>    From -00 -01:
> 
>          Significant changes throughout including re-organising the main
>          structure.
> 
>          New Abstract and changes to Introduction.
> 
> 2.  The Problem
> 
> 2.1.  Congestion is not the problem
> 
>    The problem is not congestion itself.  The problem is how best to
>    share available capacity.  When too much traffic meets too little
>    capacity, congestion occurs.  Then we have to share out what capacity
>    there is.  But we should not (and cannot) solve the capacity sharing
>    problem by trying to make it go away - by saying there should somehow
>    be no congestion, slower traffic or more capacity.  That misses the
>    whole point of the Internet: to multiplex or share available capacity
>    at maximum bit-rate.

Without making claims about missing the point of the Internet, I think 
it's fair and neutral to say there will always be cases where demand 
exceeds reasonably available capacity.

> 
>    So as we say, the problem is not congestion in itself.  Every elastic
>    data transfer should (and usually will) congest a healthy data
>    network.  If it doesn't, its transport protocol is broken. 

That's a pretty broad statement.

  There
>    should always be periods approaching 100% utilisation at some link
>    along every data path through the Internet, implying that frequent
>    periods of congestion are a healthy sign.  If transport protocols are
>    too weak to congest capacity, they are under-utilising it and hanging
>    around longer than they need to, reducing the capacity available for
>    the next data transfers that might be about to start.

This may be the text I was looking for to speak to the network 
technology impact (not business reasoning) for not restricting traffic 
when congestion is not a problem -- might be good to put the two pieces 
of text closer together?

> 
> 2.2.  Increase capacity or manage traffic?
> 
>    Some say the problem is that ISPs should invest in more capacity.

Excise ISP.

And it would be grand to come up with some illustrations that go beyond 
access networks...

>    Certainly increasing capacity should make the congested periods
>    during data transfers shorter and the non-congested gaps between them
>    longer.  The argument goes that if capacity were large enough it
>    would make the periods when there is a capacity sharing problem
>    insignificant and not worth solving.
> 
>    Yet, ISPs are facing a quandary - traffic is growing rapidly and
> 
> 
> 
> Moncaster, et al.       Expires September 2, 2010               [Page 7]
> 
>  
> Internet-Draft         Congestion Exposure Problem            March 2010
> 
> 
>    traffic patterns are changing significantly (see Section 4 and
>    [Cisco-VNI]) They know that any increases in capacity will have to be
>    paid for by all their customers but capacity growth will be of most
>    benefit to the heaviest users.  Faced with these problems, some ISPs
>    are seeking to reduce what they regard as "heavy usage" in order to
>    improve the service experienced by the majority of their customers.
> 
>    If done properly, managing traffic should be a valid alternative to
>    increasing capacity. 

Because of the point above.  It may not solve the problem, but at least 
makes more efficient use of available bandwidth before considering 
increasing capacity.  (It might be good to spell that out -- so that it 
doesn't sound like "I don't want to have to upgrade my networks", which 
it isn't trying to say).

 > An ISP's customers can vote with their feet if
>    the ISP chooses the wrong balance between managing heavy traffic and
>    charging for too much shared capacity.  Current traffic management
>    techniques (Section 3) fight against the capacity shares that TCP is
>    aiming for.  Ironically, they try to impose something approaching
>    LEDBAT-like behaviour on heavier flows.  But as we have seen, they
>    cannot give LEDBAT the credit for doing this itself - the network
>    just sees a LEDBAT flow as a large amount of volume.

IMO -- this part of the para gets way too into business models for a 
problem statement about an architectural building block.
> 
>    Thus the problem for the IETF is to ensure that ISPs and their
>    equipment suppliers have appropriate protocol support - not just to
>    impose good capacity sharing themselves, but to encourage end-to-end
>    protocols to share out capacity in everyone's best interests.

Excise ISP.  And equipment suppliers while you're at it -- the IETF is 
here to engineer Internet technology specifications, for whoever happens 
to be in the Internet development business.

> 
> 2.2.1.  Making Congestion Visible
> 
>    Unfortunately ISPs are only able to see limited information about the

Excise... (The point stands, well, with "networks").

>    traffic they forward.  As we will see in section 3 they are forced to
>    use the only information they do have available which leads to myopic
>    control that has scant regard for the actual impact of the traffic or
>    the underlying network conditions.  All their approaches are unsound
>    because they cannot measure the most useful metric.  The volume or
>    rate of a given flow or aggregate doesn't directly affect other
>    users, but the congestion it causes does.  This can be seen with a
>    simple illustration.  A 5Mbps flow in an otherwise empty 10Mbps
>    bottleneck causes no congestion and so affects no other users.  By
>    contrast a 1Mbps flow entering a 10Mbps bottleneck that is already
>    fully occupied causes significant congestion and impacts every other
>    user sharing that bottleneck as well as suffering impairment itself.
>    So the real problem that needs to be addressed is how to close this
>    information gap.  How can we expose congestion at the IP layer so
>    that it can be used as the basis for measuring the impact of any
>    traffic on the network as a whole?
> 
> 2.2.2.  ECN - a Step in the Right Directions

Perhaps this should move down to "existing approaches"?

> 
>    Explicit Congestion Notification [RFC3168] allows routers to
>    explicitly tell end-hosts that they are approaching the point of
>    congestion.  ECN builds on Active Queue Mechanisms such as random
>    early discard (RED) [RFC2309] by allowing the router to mark a packet
> 
> 
> 
> Moncaster, et al.       Expires September 2, 2010               [Page 8]
> 
>  
> Internet-Draft         Congestion Exposure Problem            March 2010
> 
> 
>    with a Congestion Experienced (CE) codepoint, rather than dropping
>    it.  The probability of a packet being marked increases with the
>    length of the queue and thus the rate of CE marks is a guide to the
>    level of congestion at that queue.  This CE codepoint travels forward
>    through the network to the receiver which then informs the sender
>    that it has seen congestion.  The sender is then required to respond
>    as if it had experienced a packet loss.  Because the CE codepoint is
>    visible in the IP layer, this approach reveals the upstream
>    congestion level for a packet.
> 
>    So Is ECN the Solution?  Alas not - ECN does allow downstream nodes
>    to measure the upstream congestion for any flow, but this is not
>    enough.  This can make a receiver accountable for the congestion
>    caused by incoming traffic.  But a receiver can only control incoming
>    congestion indirectly, by politely asking the sender to control it.
>    A receiver cannot make a sender install an adaptive codec, or install
>    LEDBAT instead of TCP.  And a receiver cannot ask an attacker to stop
>    flooding it with traffic.  What is needed is knowledge of the
>    downstream congestion level for which you need additional information
>    that is still concealed from the network - by design.
> 
> 3.  Existing Approaches to Traffic Control
> 
>    Existing approaches intended to address the problems outlined above
>    can be broadly divided into two groups - those that passively monitor
>    traffic and can thus measure the apparent impact of a given flow of
>    packets and those that can actively discriminate against certain
>    packets, flows, applications or users based on various
>    characteristics or metrics.
> 
> 3.1.  Layer 3 Measurement
> 
>    L3 measurement of traffic relies on using the information that can be
>    measured directly or is revealed in the IP header of the packet (or
>    lower layers).  Architecturally, L3 measurement is best since it fits
>    with the idea of the hourglass design of the Internet [RFC3439].
>    This asserts that "the complexity of the Internet belongs at the
>    edges, and the IP layer of the Internet should remain as simple as
>    possible."
> 
> 3.1.1.  Volume Accounting
> 
>    Volume accounting is a technique that is often used to discriminate
>    between heavy and light users.  

Is this specific to access providers (ISPs)?  Are there other instances 
(e.g., enterprise networks) where it might also be true?

The volume of traffic sent by a given
>    user or network is one of the easiest pieces of information to
>    monitor in a network.  Measuring the size of every packet from the
>    header and adding them up is a simple operation.  Consequently this
>    has long been a favoured measure used by operators to control their
> 
> 
> 
> Moncaster, et al.       Expires September 2, 2010               [Page 9]
> 
>  
> Internet-Draft         Congestion Exposure Problem            March 2010
> 
> 
>    customers.
> 
>    The precise manner in which this volume information is used may vary.
>    Typically ISPs may impose an overall volume cap on their customers
>    (perhaps 10Gbytes a month).  Alternatively they may decide that the
>    heaviest users each month are subjected to some sanction.
> 
>    Volume is naively thought to indicate the impact that one party's
>    traffic has on others.  But the same volume can cause very different
>    impacts on others if it is transferred at slightly different times,
>    or between slightly different endpoints.  Also the impact on others
>    greatly depends on how responsive the transport is to congestion,
>    whether responsive (TCP), very responsive (LEDBAT), aggressive
>    (multiple TCPs) or totally unresponsive.
> 
> 3.1.2.  Rate Measurement
> 
>    Rate measurements might be thought indicative of the impact of one
>    aggregate of traffic on others, and rate is often limited to avoid
>    impact on others.  However such limits generally constrain everyone
>    much more than they need to, just in case most parties send fast at
>    the same time.  And such limits constrain everyone too little at
>    other times, when everyone actually does send fast at the same time.
> 
>    The problem with measuring rate is that it doesn't say how much the
>    rate is occupying shared capacity over time, and whether the high
>    rate of one user comes at times when others want a high rate.
> 
> 3.2.  Higher Layer Discrimination
> 
>    Over recent years a number of traffic management techniques have
>    emerged that explicitly differentiate between different traffic
>    types, applications and even users.  This is done because ISPs and
>    operators feel they have a need to use such techniques to better
>    control a new raft of applications that break some of the implicit
>    design assumptions behind TCP (short-lived flows, limited flows per
>    connection, generally between server and client).
> 
> 3.2.1.  Bottleneck Rate Policing
> 
>    Bottleneck flow rate policers such as [XCHOKe] and [pBox] have been
>    proposed as approaches for rate policing traffic.  But they must be
>    deployed at bottlenecks in order to work.  Unfortunately, capacity
>    sharing is not only about congestion-responsive behaviour of each
>    flow, but also about how long the flows occupy the capacity and the
>    combined total of multiple flows.  Such rate policers also make an
>    assumption about what constitutes acceptable per-flow behaviour.  If
>    these bottleneck policers were widely deployed, the Internet could
> 
> 
> 
> Moncaster, et al.       Expires September 2, 2010              [Page 10]
> 
>  
> Internet-Draft         Congestion Exposure Problem            March 2010
> 
> 
>    find itself with one universal rate adaptation policy embedded
>    throughout the network.  With TCP's congestion control algorithm
>    approaching its scalability limits as the network bandwidth continues
>    to increase, new algorithms are being developed for high-speed
>    congestion control.  Embedding assumptions about acceptable rate
>    adaptation would make evolution to such new algorithms extremely
>    painful.
> 
> 3.2.2.  DPI and Application Rate Policing
> 
>    Some operators use deep packet inspection (DPI) and traffic analysis
>    to identify certain applications they believe to have an excessive
>    impact on the network.  ISPs generally pick on applications that that
>    they judge as low value to the customer in question and high impact
>    on other customers.  A common example is peer-to-peer file-sharing.
>    Having identified a flow as belonging to such an application, the
>    operator uses differential scheduling to limit the impact of that
>    flow on others, which usually limits its throughput as well.  This
>    has fuelled the on-going battle between application developers and
>    DPI vendors.
> 
>    When operators first started to limit the throughput of P2P, it soon
>    became common knowledge that turning on encryption could boost your
>    throughput.  The DPI vendors then improved their equipment so that it
>    could identify P2P traffic by the pattern of packets it sends.  This
>    risks becoming an endless vicious cycle - an arms race that neither
>    side can win.  Furthermore such techniques may put the operator in
>    direct conflict with the customers, regulators and content providers.

I think it would be good (after excising ISP ;-) ) to add a bit here to 
spell out the problem:  any approach that attempts to ascertain 
application type and act on an application-specific approach is a poor 
long-term architectural approach:  this is where we can observe that 
such a tactic will stifle evolution and growth of applications (and 
managed networks).

> 
> 4.  Why Now?
> 
>    The accountability and capacity sharing problems highlighted so far
>    have always characterised the Internet to some extent.  In 1988 Van
>    Jacobson coded capacity sharing into TCP's e2e congestion control
>    algorithms [TCPcc].  But fair queuing algorithms were already being
>    written for network operators to ensure each active user received an
>    equal share of a link and couldn't game the system [RFC0970].  The
>    two approaches have divergent objectives, but they have co-existed
>    ever since.
> 
>    The main new factor has been the introduction of residential
>    broadband, making 'always-on' available to all, not just campuses and
>    enterprises.  Both TCP and approaches like fair queuing don't take
>    account of how much of each user's data is occupying a link over
>    time, which can significantly reduce the capacity available to
>    lighter usage.  Therefore residential ISPs have been introducing new
>    traffic management equipment that can prioritise based on each
>    customer's usage volume, e.g.  [Comcast].  Otherwise capacity
> 
> 
> 
> Moncaster, et al.       Expires September 2, 2010              [Page 11]
> 
>  
> Internet-Draft         Congestion Exposure Problem            March 2010
> 
> 
>    upgrades get eaten up by transfers of large amounts of data, with
>    little gain for interactive usage [BB-Incentive].

Okay, I can buy the use of ISP above ;-)

> 
>    In campus networks, capacity upgrades are the easiest way to mitigate
>    the inability of TCP or FQ to take account of activity over time.
>    But capacity upgrades are much more expensive in residential
>    broadband networks that are spread over large geographic areas and
>    customers will only be happy to pay more for their service if the
>    majority can see a significant benefit.

Nice example of an access network that is not an ISP.

> 
>    However, these traffic management techniques fight the capacity
>    shares e2e protocols are aiming at, rather than working together in
>    unison.  And, the more optimal ISPs try to make their controls, the
>    more they need application knowledge within the network - which isn't
>    how the Internet was designed to work.  Congestion exposure hasn't
>    been considered before, because the depth of the problem has only
>    recently been understood.  We now understand that both networks and
>    end-systems to focus on contribution to congestion, not volume or
>    rate.  Then application knowledge is only needed on the end-system,
>    where it should be.  But the reason this isn't happening is because
>    the network cannot see the information it needs (congestion).

I think another para after this one would be suitable -- to emphasize 
that *today* the problem is seen in ISPs (access networks), but an 
architectural solution really has to address the overall inter-network 
issue, whether it's from the access networks or somewhere else in the 
middle.  And that solution has to scale up.

> 
>    As long as ISPs continue to use rate and volume as the key metrics
>    for determining when to control traffic there is no incentive to use
>    LEDBAT or other low-congestion protocols to improve the performance
>    of competing interactive traffic.  We believe that congestion
>    exposure gives ISPs the information they need to be able to
>    discriminate in favour of such low-congestion transports.  In turn
>    this will give users a direct benefit from using such transports and
>    so encourage their wider use.

I'm not sure this para is necessary, and may get too much into current 
realities.  At a minimum, it should be generalized beyond "ISPs".

> 
> 5.  Requirements for a Solution
> 
>    This section proposes some requirements for any solution to this
>    problem.  We believe that a solution that meets most of these
>    requirements is likely to be better than one that doesn't, but we
>    recognise that if a working group is established in this area, it may
>    have to make tradeoffs.

I think this whole section seems pretty solid -- good and general and 
not ISP-centric.

> 
> 6.  A Strawman Congestion Exposure Protocol
> 
>    In this section we explore a simple strawman protocol that would
>    solve the congestion exposure problem. 

I appreciate that this has been stripped down to the bare essentials of 
the description.  But, I wonder if it is still too detailed for a 
problem statement.  Perhaps this, and subsequent sections, now need to 
migrate into a separate document?

  This protocol neatly
>    illustrates how a solution might work.  A practical implementation of
>    this protocol has been produced and both simulations and real-life
>    testing show that it works.  The protocol is based on a concept known
>    as re-feedback [Re-fb] and builds on existing active queue management
>    techniques like RED [RFC2309] and ECN [RFC3168] that network elements
>    can already use to measure and expose congestion.
> 
>    Re-feedback, standing for re-inserted feedback, is a system designed
>    to allow end-hosts to reveal to the network information about their
>    network path that they have received via conventional feedback (for
>    instance congestion).
> 
>    In our strawman protocol we imagine that packets have two
>    "congestion" fields in their IP header:
> 
>    o  The first is a congestion experienced field to record the upstream
>       congestion level along the path.  Routers indicate their current
>       congestion level by updating this field in every packet.  As the
>       packet traverses the network it builds up a record of the overall
>       congestion along its path in this field.  This data is sent back
>       to the sender who uses it to determine its transmission rate.
> 
>    o  The other is a whole-path congestion field that uses re-feedback
>       to record the total congestion along the path.  The sender does
>       this by re-inserting the current congestion level for the path
>       into this field for every packet it transmits.
> 
>    Thus at any node downstream of the sender you can see the upstream
>    congestion for the packet (the congestion thus far), the whole path
>    congestion (with a time lag of 1RTT) and can calculate the downstream
>    congestion by subtracting one from the other.
> 
>    So congestion exposure can be achieved by coupling congestion
>    notification from routers with the re-insertion of this information
>    by the sender.  This establishes information symmetry between users
>    and network providers.
> 
> 7.  Use Cases
> 
>    Once downstream congestion information is revealed in the IP header
>    it can be used for a number of purposes.  Precise details of how the

All of these use cases seem pretty ISP, and ISP-business, centric. 
While I appreciate that they are powerful and useful in that context, I 
think they may be distractions from the overall point of a problem 
statement for an architectural building block that the CONEX group is 
meant to tackle.  We run the risk of getting people arguing about 
business practices rather than focusing on the specific, 
inter-networking issue that CONEX needs to address.

So -- I believe these need to migrate out of the problem statement document.

If use cases (applicability cases) are needed, they need to be more 
general.  Having said that -- I think that they are something of a 
distraction.  People need to get the architectural intent.  I think 
we've struggled with the balance between "illustrations so you can see 
how it would be useful" and mistaking the illustrations for the thing.

--