Re: [re-ECN] ConEx BoF announcement

[João Taveira Araújo <[e-mail]>]

John Leslie wrote:
> Jo?o Taveira Ara?jo <[e-mail]> wrote:
>   
>> Congestion Exposure (ConEx) is a proposed new IETF activity to enable
>> congestion to be exposed within the network layer of the Internet.
>>     
>
>    I think the point is "exposed along the forwarding path" in the
> network (IP) layer.
>
>    Further, AFAIK what will be exposed is both "expected congestion" and
> "congestion experienced so far". (This sounds like magic, of course, and
> we should perhaps take some pains to convince readers it is merely
> "sufficiently advanced technology" ;^)
>
>   
>> By revealing expected congestion in the IP header of every packet,
>>     
>
>    Here's a good place to start dispelling the "magic" appearance.
> AFAIK we don't intend to put a high-precision number in every packet,
> but instead to put one bit in some fraction of packets sent, in
> proportion to the congestion expected. The former sounds like magic;
> the latter like advanced technology.
>   

I was wary of going into greater detail because I wasn't sure we want to 
convey the expected congestion / congestion experienced is the only 
means of achieving congestion exposure. Matt's proposal on checking for 
duplicate packets can reveal expected congestion for example. Likewise, 
the v6 version of re-ECN may potentially include a high-precision number 
in every packet (although this is up for grabs).



>> congestion exposure provides a generic network capability which
>> simplifies resource allocation.
>>     
>
>    I'm not sure "simplifies" is correct -- instead I think we mean
> "enables better resource allocation".
>   

Simplifies in the sense networks don't have to infer congestion from 
loosely related metrics - such as traffic rate, volume or application 
type. Better might be more assertive though.

>> This information may in turn be used for multiple purposes, including
>> congestion policing, inter-domain SLAs, end-to-end QoS and traffic
>> engineering.
>>     
>
>    It's sounding like magic again... I don't think those should be run
> together.
>
>    For congestion policing, we might say something like
> " 
> " At any point along the forwarding path, such as a peering point, a
> " congestion policing function could check whether the percentage of
> " congestion-expected-marked packets exceeds the contracted percentage,
> " and assess additional charges or refuse some of the traffic.
>
>    The other items are too broad for me to wordsmith at this time...
>   

I don't think we should go into this much detail in the announcement 
itself. The reason I put these use cases in the first paragraph was to 
act as keywords and attract potential contributors from those areas. I 
do think this should be in the charter however.


>> The internet is, in essence, about pooling resources. The ability to
>> share capacity has been paramount to its success and has traditionally
>> been managed through the voluntary use of TCP.
>>     
>
>    "TCP congestion-control", I think.
>   

Noted.

>> TCP alone however is unable to prevent bandwidth intensive applications,
>> such as peer-to-peer or streaming video, from causing enough congestion
>> to severely limit the user-experience of many other end-hosts.
>>     
>
>    This isn't the right emphasis, IMHO. Let me try to shift the emphasis:
> " 
> " Traditional TCP congestion-control, however, is proving ill-suited to
> " the needs of bandwidth-intensive applications such as streaming audio
> " and video. Similarly, background-file-sharing applications are finding
> " a need for alternative congestion-control when congestion limits the
> " ability of TCP to ever fill the available bandwidth.
>   

Half empty, half full. I was taking the opposite viewpoint because ISPs 
react adversely to heavy users taking too much, not too little. While 
your statement is correct (and is the driving force behind LEDBAT), it 
doesn't really tie in with the next sentence.


>> This has lead ISPs to deploy ad-hoc solutions such as volume accounting,
>> rate policing and deep packet inspection in an attempt to distribute
>> capacity differently.
>>     
>
>    Although I hate the concept of distributing "fairly", that is what
> they claim to be attempting, and I think we should use their word.
>   

I wanted to avoid historically loaded terms. I'll leave this open to 
discussion to see if there is consensus on using "fairly".


>> It is increasingly recognised that in today's internet this leads to
>> issues from technical, business and regulatory viewpoints [ref problem
>> statement, p2pi workshop]
>> *snip*
>>    A bit wimpy... Perhaps:
>> " 
>> " The proposed WG will not attempt to detail what management practices
>> " are appropriate for managing congestion, though we expect wide-ranging
>> " experimentation along those lines: our concern will be how well the
>> " protocol expresses expected and actual congestion.
>>     

All noted.


>> The proposed work items are:
>>     
>
>    These need work, but not necessarily right now. In any case, I won't
> address them in this email.
>   

I just copied the work items from the draft charter, which is what I'll 
do in the final version, so any discussion relating to this list should 
be addressed on the charter thread. Thanks for the input, I'll be 
waiting a few more days for feedback before sending out another copy.

Joao.