Re: [re-ECN] Charter Question

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

----- Original Message -----
From: re-ecn-bounces@ietf.org <re-ecn-bounces@ietf.org>
To: bmanning@vacation.karoshi.com <bmanning@vacation.karoshi.com>
Cc: re-ecn@ietf.org <re-ecn@ietf.org>
Sent: Fri May 07 17:56:24 2010
Subject: Re: [re-ECN] Charter Question

bmanning@vacation.karoshi.com <bmanning@vacation.karoshi.com> wrote:
> On Fri, May 07, 2010 at 04:02:35PM -0400, John Leslie wrote:
>> 
>> I don't believe any of us are talking a "congested/notcongested"
>> binary switch, and I'm certainly not.
> 
> well, we -could- be, if this is truely hop/hop - then the
> only link you care about is the link betwn the two hops.

   IMHO, even if this ends up in an IPv6 "hop-by-hop" option, it won't
concern the link between two hops. This is about _exposing_ information
now at the transport layer _to_ the forwarding layer.

>> I agree with Bill that the binary switch he mentions isn't really
>> applicable to the problem, though I don't agree the "inspecting
>> forwarder" is a likely cause of congestion.
> 
> perhaps I am jaded, but for many years there were real problems
> with forwarders being able to operate at "line-rates".

   I remember that too...

> If the forwarder spends too much time "inspecting, detecting,
> neglecting, infecting" the datagrams - it could be considered a point
> of congestion.. 
> Or I am misunderstanding (again)

   It is, of course, always possible to create yet-another-point-of-
congestion. :^(

   I would, however, view it as an abuse for any forwarder to spend
much time evaluating ConEx marking.

   There is an unstated presumption that "true backbone" links will
have sufficient aggregation to have negligible congestion except
during extraordinary DoS conditions. Thus, there would be no point
in putting congestion-policing at these. If their design allows, we'd
like them to ECN mark (in the rare case); but dropping packets during
congestion is perfectly fine.

>> I'm a bit confused by Bill's "how is it different" question: to
>> me "a range" is totally different from QoS...
>> 
>> Nevertheless, congestion-expected marking is a fundamentally
>> different thing than QoS marking, and rather orthogonal IMHO. QoS
>> deals with what _kind_ of special treatment you request; CE marking
>> deals with passing information about an estimate of future
>> congestion the packet might encounter.
> 
> qos is a range,

   Not, IMHO, to any forwarder that actually acts on it...

> ecn is (for this thread) a range.

   Yes.

> based on other parts in this thread, ecn markers could be
> used to tag/flag which flows needed priority - which sounded
> like QOS to me.

   I don't believe any of us intend ConEx marking to indicate a
"need" for priority; nor do I believe there is any current proposal
calling for giving such packets priority (though I personally don't
want to rule out such things in some future charter -- if it might
lead to better congestion management).

> CE marking sounds more like a warning to the destination that the
> path taken by the source should be avoided (congested) if possible.

   The reECN proposal calls for CE marks in just a few packets of a
flow. Treating those packets any differently than non-CE-marked
packets seems counter-productive.

   (There is, of course, ongoing work in MPTCP; and I don't mean to
try to forbid a case where MPTCP pays attention to CE markings.
But IMHO there doesn't seem to be any _reason_ for them to do so.)

>> Thus, IMHO, it's quite reasonable to imagine QoS marking in
>> addition to CE marking, to designate what you want a forwarder to
>> do in the event of lengthening queues, for example (though I don't
>> mean to say the two markings _should_ overlap in the slightest!).
>> Or it might be the case that a forwarder could benefit from CE
>> markings to estimate whether a particular QoS path is becoming
>> congested... Any such work goes _far_ beyond our initial charter.
> 
> i'm ok with this idea.  what would be useful here is some
> guidance from the IAB (the architecture people) about the 
> 10'000m view.

   Hmm... I'm willing to push for that, but the IAB appears to have
a pretty full plate of liaison issues, and I doubt we'd get anything
from them in less than 3-6 months.

> granted we may be working on a small piece, but it would be nice to
> know that when we start mass hallucination that we are either
> ontrack or way out of scope. e.g. I'd like to see a larger context
> in which this work would be a contributing part.

   I think we'd have to start that discussion here, and hand IAB
members much more specific questions to see whether they bite...

>> I believe it is our intent to specify the meaning of CE marks,
>> expecting nothing of intermediate forwarders than that they signal
>> congestion experienced, whether by ECN, dropping packets, or some
>> other method entirely.
> 
> ok.  hop/hop or end/end?

   End-to-end, IMHO. We're talking about making transport-layer
information visible at a lower layer -- the transport-layer info
is strictly end-to-end.

> can intermediate nodes modify CE marking?

   I suppose they "can", but it doesn't seem helpful to do so.

--
John Leslie <john@jlc.net>
_______________________________________________
re-ECN mailing list
re-ECN@ietf.org
https://www.ietf.org/mailman/listinfo/re-ecn