Re: [re-ECN] ConEx BoF announcement

[<[e-mail]>]

A sprinkling of magic will enliven the BoF! Just a few bits in line...

Toby

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of João Taveira Araújo
> Sent: 12 October 2009 17:33
> To: John Leslie
> Cc: [e-mail]
> Subject: Re: [re-ECN] ConEx BoF announcement
> 
> 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" ;^)

But it is magic! I agree we need to make sure people are able to believe we have a serious proposal here, not just a load of waffle and hot air.

> >
> >
> >> 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).

I agree with João here - we want to avoid dictating the solution at this stage. But there is no harm in saying something like "one proposal has already been put forward that builds on ECN to add rest of path information into the IP header." (that will need some more work probably, but basically we say "yes this seems like magic but there is already at least one easy proposal to do this and more may be possible"

> 
> 
> 
> >> 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.

"allows greater freedom for resource allocation". Somewhere we need to highlight that this is just a way of adding information that can then be used to monitor how resources are being shared, thus freeing us from the constraints of e.g. TCP friendliness, flow fairness, etc.


> 
> >> 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.

I think it would be nice to hint this is a powerful tool, but limit things to a short list initially with something like " This information may in turn be used for many purposes, including congestion policing, accountability and inter-domain SLAs. It also opens exciting possibilities for new approaches to QoS and traffic engineering." 
> 
> 
> >> 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.

I'll leave this to others to decide which way we put this emphasis. One thing though - currently no user has an incentive to use LEDBAT unless they are the primary cause of their own congestion (or have a stupid home router with a 2s queue). If we can shift the emphasis globally to congestion then suddenly ISPs will incentivise the use of LEDBAT, etc

> 
> 
> >> 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".

"Fairly" probably should be avoided and not all ISPs claim that word - some just claim to be "limiting the impact of a minority of customers"

> 
> 
> >> 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.

Probably summarise the work items rather than list them - you can always include a link to the draft charter. 


> 
> Joao.
> 
> 
> 
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn