Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Alissa Cooper <acooper@cdt.org>
In-Reply-To: <201201101436.37128.mkuehle@ikr.uni-stuttgart.de>
Date: Thu, 2 Feb 2012 17:11:41 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF4BADA4-E739-4643-87E6-DE1251472628@cdt.org>
References: <4EC4690C.2060707@it.uc3m.es>
 <201201101436.37128.mkuehle@ikr.uni-stuttgart.de>
To: =?iso-8859-1?Q?Mirja_K=FChlewind?= <mirja.kuehlewind@ikr.uni-stuttgart.de>
Cc: Bob Briscoe <rbriscoe@jungle.bt.co.uk>, ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] WGLC for draft-ietf-conex-concepts-uses-03.txt
Precedence: list

Hi Mirja,

Thanks for your comments. Some replies below.

On Jan 10, 2012, at 8:36 AM, Mirja K=FChlewind wrote:

> Hi,
>=20
> sorry, I'm very late with my comments on the doc mentioned below but =
there are=20
> only a few comments:
>=20
> The example in "2.2.  Congestion-Volume" says the loss propability is =
0,2% and=20
> the congestion volume 2MB. Maybe it's helpful to says more explicit =
that 1)=20
> the loss propability is the measurement of the network congestion =
(level) and=20
> 2) this is in percent, while the congestion volume depends on the =
actual=20
> amount of traffic send by the user and thus is in MB.

I'm not really sure what you're asking for here since we say both (1) =
and (2) directly prior to the example -- last para of 2.1 explains loss =
probability and first para of 2.2 explains that congestion-volume is =
measured in bytes.

>=20
> Section '2.3.  Rest-of-Path Congestion' talks only about ECN as a =
congestion=20
> signal and ignores loss.

This is by design since rest-of-path congestion cannot be reliably =
measured if congestion is signaled with loss (as abstract-mech says).

>=20
> In "2.4.  Definitions" in the definition of congestion-volume the =
following=20
> sentence does not seem to be entirely correct or I don't get it right:
> "data volume multiplied by the congestion each packet of the volume=20
> experienced" -> maybe "... multiplied by the mean congestion during =
the=20
> measurement time period..."?

I think the idea of the second sentence is to provide another way to =
conceptualize congestion-volume other than the straight definition in =
the first sentence. So the first sentence talks about congestion =
measured over a period of time and the second sentence explains the =
concept the same way the example does in 2.2.=20

>=20
> Upstream congestion:=20
> s/by a traffic flow thus far/by a traffic flow so far/ ??

Not sure what you mean by this -- to my ear "so far" is a colloquial way =
of saying "thus far."

>=20
> In 3.1.  Use Case Description
> "Those users would be expected to react in the typical way to drops,
>   backing off (assuming use of standard TCP), and thereby lowering
>   their congestion-volumes back within the quota limits."
> If those users would use standard TCP, they would have reacted already =
on the=20
> original congestion signal (before a policer can drop anything based =
on=20
> ConEx). I though the point is that this mechanism is helpful when a =
users=20
> does e.g. not back off on congestion.

I think the point is that it can be helpful in either situation, and =
this example implicitly assumes that the behavior that triggers policing =
is, e.g., a user with many open flows but using standard TCP. In the =
scenario described, indeed the users whose packets get dropped by the =
policer will have backed off in response to congestion, but the point is =
to get them to back off more, because they have more flows and are =
therefore congesting the link more than others.

Since this is just an example, I don't think we need to exhaustively =
list all the effects of the policer. I suggest the following edit to the =
sentence above to make the text a little more clear:

s/expected/likely/

> And additionally I believe there is a=20
> second important point: a (misbehaving) user can be policed at the =
ingress =20
> before the traffic will disturb other users further.
>=20

Here is my suggestion:

OLD:

By deploying a congestion policer at the BRAS location, the network =
operator can measure
        the congestion-volume created by users within the access nodes.

NEW:

By deploying a congestion policer at the BRAS location, the operator can
   measure the congestion-volume created by users within the access
   nodes and police misbehaving users before their traffic affects =
others on the access network.

> The last paragraph in "3.3.  Comparison with Existing Approaches" is =
not=20
> entirely clear to me. This sounds like ConEx proposes to use a =
per-congestion=20
> pricing. Do we need to talk about flat-rate pricing at all?

It mentions pricing, but the point is actually about how ConEx creates =
transparency around performance for anyone (user or operator) who cares =
to look. I've added a sentence at the end in response to one of Phil's =
wglc comments, so perhaps that helps:

        By exposing congestion
        information at the IP layer, ConEx instead provides a metric =
that can
        serve as an open, transparent basis for traffic management =
policies
        that both providers and their customers can measure and verify. =
It can be used to reduce the performance uncertainty that some users =
currently experience.

Alissa

>=20
> Mirja
>=20
>=20
> On Thursday 17 November 2011 02:53:16 marcelo bagnulo braun wrote:
>> This note issues the WGLC for draft-ietf-conex-concepts-uses-03.txt.
>> (http://www.ietf.org/id/draft-ietf-conex-concepts-uses-03.txt)
>>=20
>> Please review the document and send comments before the 5th december.
>>=20
>> Thanks, marcelo
>> _______________________________________________
>> conex mailing list
>> conex@ietf.org
>> https://www.ietf.org/mailman/listinfo/conex
>=20
>=20
>=20