Re: [conex] WGLC for draft-ietf-conex-concepts-uses-03.txt

[Alissa Cooper <[e-mail]>]

Hi Mirja,

Thanks for your comments. Some replies below.

On Jan 10, 2012, at 8:36 AM, Mirja Kühlewind wrote:

> Hi,
> 
> sorry, I'm very late with my comments on the doc mentioned below but there are 
> only a few comments:
> 
> The example in "2.2.  Congestion-Volume" says the loss propability is 0,2% and 
> the congestion volume 2MB. Maybe it's helpful to says more explicit that 1) 
> the loss propability is the measurement of the network congestion (level) and 
> 2) this is in percent, while the congestion volume depends on the actual 
> 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.

> 
> Section '2.3.  Rest-of-Path Congestion' talks only about ECN as a congestion 
> 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).

> 
> In "2.4.  Definitions" in the definition of congestion-volume the following 
> 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 
> experienced" -> maybe "... multiplied by the mean congestion during the 
> 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. 

> 
> Upstream congestion: 
> 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."

> 
> 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 
> original congestion signal (before a policer can drop anything based on 
> ConEx). I though the point is that this mechanism is helpful when a users 
> 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 
> second important point: a (misbehaving) user can be policed at the ingress  
> before the traffic will disturb other users further.
> 

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 
> entirely clear to me. This sounds like ConEx proposes to use a per-congestion 
> 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

> 
> Mirja
> 
> 
> 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)
>> 
>> Please review the document and send comments before the 5th december.
>> 
>> Thanks, marcelo
>> _______________________________________________
>> conex mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/conex
> 
> 
>