Re: [re-ECN] Charter Question

[Stewart Bryant <[e-mail]>]

On 08/05/2010 01:19, Woundy, Richard wrote:
> Bill,
>
> Maybe I can give one specific example of how a router might use the conex bit to do something lightweight and simple. This is specific to my type of network, and may not work in John's network or other networks -- it is just one way some of us have envisioned Conex to make things better than today.
>
> In my cable network, I have a broadband access router called the CMTS. It forwards traffic between the cable (DOCSIS) network and the regional access network. It counts transmitted and received bytes per cable modem and per interface, and it can assign priorities to cable modems.
>
> We have implemented a congestion management mechanism on top of this infrastructure, which is protocol- and application agnostic. See<http://tools.ietf.org/id/draft-livingood-woundy-congestion-mgmt-03.txt>  for details. In short, the CMTS reports its congestion state to a backend system, and reports on the subscribers contributing to that congestion (byte counts per modem and per interface). The backend system then changes the relative priority of modems to balance the traffic among subscribers during brief times of congestion.
>
> What's good about this system is that it seems to work, and is not targeted against a specific protocol/application mix that might change over time. Plus it avoids many net neutrality-related concerns raised against other congestion management schemes.
>
> One open issue is that this scheme cannot tell the difference between LEDBAT-enabled applications (eg uTorrent) and non-LEDBAT applications. A LEDBAT application might generate a lot of traffic in some short period of time, but it will back off when it senses congestion in the network (based on measuring the change in end-to-end delay). This is bad for both parties, because the ISP has a reduced ability to provide incentives to LEDBAT applications.
>
> So now let's add Conex marking, in which the end hosts add markings to send feedback about end-to-end congestion into the network. Now the CMTS has a new data point -- information about whether there is upstream (ECN) or downstream (Conex) congestion experienced/expected for a particular packet flow. The CMTS can count 'total bytes' as well as 'congestion bytes' on a per modem basis. As a result, the backend system can make a much better determination about whether a subscriber's overall traffic is dominated by LEDBAT or non-LEDBAT applications, without resorting to DPI and other such schemes. And the CMTS only maintains another set of packet counters, without disrupting its primary job of packet forwarding.
>
> We haven't worked out all the details of this use case, of course, but is that enough detail to answer your basic questions?
>
> -- Rich
This sounds like a relatively slow process - i.e. over a few packets the 
host tell anyone who wishes to listen that it is seeing congestion on a 
flow. That sounds like it could be addressed by having the host send an 
OAM packet from time to time over the path rather than including the 
information in every packet.

Stewart