Subject: [re-ECN] preliminary draft of problem statement- authors wanted

From: <[email-masked]>
Date: Fri, 18 Sep 2009 10:57:34 +0100

<<draft-moncaster-congestion-exposure-problem-00.txt>> Hi All,

Here is a very preliminary version of a Problem Statement for Congestion Exposure. It is mainly in note form and needs MAJOR bashing. I am hoping by posting it in this early form to persuade a few more people to volunteer as co-authors with me...

We need to have this in a reasonable shape by mid-October in order to make the initial submission deadline (which is scarily close - only 4 weeks and 4 days away).

Absolutely everything in the document is fair game for change including title, draft name, table of content, content, ...

Toby
___________________________________________________________________ 
Toby Moncaster, <[email-masked]> Networks Research Centre, BT 
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 18 Sep 2009 19:46:41 -0400

Toby,

Here are some ideas for the table of contents for the problem statement. I have stolen ideas for sections from problem statements from other WGs/BoFs, and stolen ideas for content from the existing re-ECN drafts, especially http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-motivation-00.

I would change "Myoptic Solutions" to "Existing Work". You have identified two existing ISP solutions: "rate limiting" and "volume limiting". I would add "simple best effort traffic and flow-rate fairness" (RFC5290), as well as ECN (RFC3168) with nonces (RFC3540). You can steal content from sections 3.1.2 and 4.7 of the motivation draft, of course.

I would add a section about use cases. The primary use case would seem to be an "incentive environment that ensures optimal sharing of capacity", although that could use a better title. Other use cases may include "DDoS mitigation", "end-to-end QoS", "traffic engineering", and "inter-provider service monitoring". (You can see I am stealing liberally from the motivation draft here. We'll have to see whether the other use cases are "core" to this group, or "freebies" that come along with re-ECN as a particular protocol.)

I would also add a section on requirements. Here are some initial ideas: enable a view of whole path congestion (both upstream and downstream congestion), enable policing of flows, and monitor the flow of congestion across ISP borders. Be responsive to real-time congestion in the network. Solve the problem at the IP layer; avoid making assumptions about the behavior of specific applications (e.g. be application agnostic). Enable a diversity of intra-domain and inter-domain congestion management practices. Don't force a "universal rate adaptable policy" such as TCP-friendliness. Enable incremental deployment and an evolution to new congestion responses. Support integrity of congestion notifications; that is, make it difficult to generate false positives and false negatives in congestion notifications. Be robust in the face of DoS attacks aimed at either congestion transparency itself (e.g. persistently negative flows for re-ECN), or at the network elements implementing congestion transparency (e.g. policers and droppers for re-ECN).

At some point, I would add a section for "definitions", but that content can wait until we see what terms have to be introduced into the other sections first.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, September 18, 2009 5:58 AM
To: [email-masked]
Subject: [re-ECN] preliminary draft of problem statement- authors wanted

Toby
___________________________________________________________________
Toby Moncaster, <[email-masked]> Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170

---

From: <[email-masked]>
Date: Tue, 22 Sep 2009 09:50:00 +0100

Hi Rich,

Thanks for the extensive comments. This is just the sort of thing I am hoping to trigger by sending the draft in so early - always better to get significant structural comments before I have wasted too much time going down a blind alley...

More inline...

> From: Woundy, Richard [mailto:[email-masked]]
> Sent: 19 September 2009 00:47
> To: Moncaster,T,Toby,DER3 R
> Cc: [email-masked]
> Subject: RE: [re-ECN] preliminary draft of problem statement- authors
> wanted
> 
> Toby,
> 
> Here are some ideas for the table of contents for the problem
> statement. I have stolen ideas for sections from problem statements
> from other WGs/BoFs, and stolen ideas for content from the existing re-
> ECN drafts, especially http://tools.ietf.org/html/draft-briscoe-tsvwg-
> re-ecn-tcp-motivation-00.
> 
> I would change "Myoptic Solutions" to "Existing Work". You have
> identified two existing ISP solutions: "rate limiting" and "volume
> limiting". I would add "simple best effort traffic and flow-rate
> fairness" (RFC5290), as well as ECN (RFC3168) with nonces (RFC3540).
> You can steal content from sections 3.1.2 and 4.7 of the motivation
> draft, of course.

I really wanted a title that conveyed a little more than just "existing work". But I agree "myopic" is the wrong word. Will add some of those other bits as well. Perhaps I should group them into categories (things the network does and things end-systems do?).

> 
> I would add a section about use cases. The primary use case would seem
> to be an "incentive environment that ensures optimal sharing of
> capacity", although that could use a better title. Other use cases may
> include "DDoS mitigation", "end-to-end QoS", "traffic engineering", and
> "inter-provider service monitoring". (You can see I am stealing
> liberally from the motivation draft here. We'll have to see whether the
> other use cases are "core" to this group, or "freebies" that come along
> with re-ECN as a particular protocol.)

This seems a good idea, but we need to try and not put the cart before the horse. This document is intended to stand independently of re-ECN and I actually want to write it in such a fashion that doesn't kill off other solutions... That means we can't tailor the list of use-cases to those ones that re-ECN covers! I reckon if we give the "core" use cases but hint that other things may be possible? How about "Incentive-based capacity sharing architecture"?

> 
> I would also add a section on requirements. Here are some initial
> ideas: enable a view of whole path congestion (both upstream and
> downstream congestion), enable policing of flows, and monitor the flow
> of congestion across ISP borders. Be responsive to real-time congestion
> in the network. Solve the problem at the IP layer; avoid making
> assumptions about the behavior of specific applications (e.g. be
> application agnostic). Enable a diversity of intra-domain and inter-
> domain congestion management practices. Don't force a "universal rate
> adaptable policy" such as TCP-friendliness. Enable incremental
> deployment and an evolution to new congestion responses. Support
> integrity of congestion notifications; that is, make it difficult to
> generate false positives and false negatives in congestion
> notifications. Be robust in the face of DoS attacks aimed at either
> congestion transparency itself (e.g. persistently negative flows for
> re-ECN), or at the network elements implementing congestion
> transparency (e.g. policers and droppers for re-ECN).

Definitely agree but as with the use-cases above I am keen to make the requirements general-enough to not just give re-ECN as the answer (even though that is the preferred answer at the moment). I would add "being transport-agnostic" to the list...

> 
> At some point, I would add a section for "definitions", but that
> content can wait until we see what terms have to be introduced into the
> other sections first.

Will see if this is needed once there is a bit more text there...

Toby

> Here is a very preliminary version of a Problem Statement for
> Congestion Exposure. It is mainly in note form and needs MAJOR bashing.
> I am hoping by posting it in this early form to persuade a few more
> people to volunteer as co-authors with me...
> 
> We need to have this in a reasonable shape by mid-October in order to
> make the initial submission deadline (which is scarily close - only 4
> weeks and 4 days away).
> 
> Absolutely everything in the document is fair game for change including
> title, draft name, table of content, content, ...
> 
> Toby

---

From: João Taveira Araújo <[email-masked]>
Date: Tue, 22 Sep 2009 10:25:24 +0100

Inline,

> I really wanted a title that conveyed a little more than just "existing work". But I agree "myopic" is the wrong word. Will add some of those other bits as well. Perhaps I should group them into ca…

I'm not so sure about using the term "existing work" to refer to ad-hoc, 
poorly documented solutions in most cases. They are workarounds, not 
work. Might also want to mention voluntary rate-limiting on the 
end-hosts (p2p apps) as a symptom of dodgy capacity sharing.

I was hoping for more text before bashing the document, but I assume 
it'll take a while before getting to a semi-finished state. I've toyed 
around with a few paragraphs for section 4, but I'm not sure how 
lightweight you want the economics to be. I think the main ideas to get 
across are:

a) congestion as an externality
b) congestion as the marginal cost of provisioning network
c) exposing congestion corrects information asymmetry.

I'm also unsure whether taking re-ECN out of the picture implies taking 
re-feedback out as well, or whether its the framework we want to have 
for any potential solution. Feel free to pick & mix any of the text, 
I'll be waiting for a future revision to bash.

Joao.

4.  Towards a better solution

   In the previous section, we have documented how network operators
   attempt to limit the damage any single user can inflict on others by
   imposing restrictions on user behaviour.  While these solutions
   differ in approach, they all attempt to tackle the root cause
   indirectly by inferring congestion.  To move beyond such shoddy
   patchwork, there is a need to explicitly treat congestion as a cost.

4.1.  Congestion as a cost

   Congestion is a negative externality - an individual's usage of the
   network has a negative impact on others.  Unheeded, the ability to
   inflict congestion on others at no personal cost may lead to a
   "tragedy of the commons", where self-interested end users undermine
   the value of the network through selfish behaviour.  Such an extreme
   case was initially averted due to genuine cooperation through the
   voluntary deployment of TCP.  As increased commercial pressure is
   exerted on the Internet however, the assumption that stakeholders
   will continuously cooperate towards a common goal no longer holds.

   A possible solution is to apply shadow pricing to the negative
   externality, effectively forcing individuals to internalise the costs
   they impose on others and therefore holding individuals accountable
   for their actions.  Kelly [] has shown that charging end-points a
   shadow price proportional to the congestion they cause leads to the
   maximization of social welfare.

   Additionally, shadow pricing plays a dual role, both reflecting the
   social costs of increased bandwidth usage and the marginal cost of
   provisioning the network.  As such, adequate resource pricing can be
   used to recover expansion costs while subscription revenue recovers
   non-recurring costs.

   While exerting economic pressure on end-points effectively induces
   sociable behaviour, retrofitting the Internet with means to enforce
   congestion pricing has proved elusive.  The best-effort delivery
   provided by the Internet was built on the assumption that forwarding
   elements should discard traffic they are unable to service.  While
   remarkable in its simplicity, this design choice has lead to an
   Internet which is opaque to failure.  As congestion is viewed end-to-
   end, only end-points hold information on the quality of service
   provided by the network.  In this case the buyer knows more about the
   product being sold than the seller.  While this is converse to
   Akerlof's classic examples of information asymmetry [], the outcome
  is similar, resulting in a suppressed market price which in turn
   leads to reduced investment in supply.

(...)

4.2.  The limitations of ECN in exposing cost

   The lack of accountability for congestion was partially addressed
   with the introduction of ECN [], an explicit marking scheme to
   indicate the onset of congestion.  While ECN was introduced to
   maintain networks operating below the point where losses would be
   experienced, as a side-effect it revealed congestion downstream of
   the congested link, allowing network devices to quantify congestion
   without the need for inspecting transport headers.

   This newfound visibility of congestion was duly exploited by Kelly
   [].  Using ECN, a network could apply shadow pricing by simply
   charging the upstream network proportionally to the amount of
   congestion marked traffic it sent.  Unfortunately, this scheme proved
   impractical and suffers from shortcomings derived from the asymmetry
   inherent to classic feedback.

   The fundamental problem with using ECN for congestion pricing is that
   it reveals the correct metric, but to the wrong entities.
   Intermediate routers can only view congestion ex post and are
   therefore not only unable to act upon the information provided, but
   also incapable of verifying its integrity.

(..)

4.3.  Refeedback for congestion exposure

(...)

---

From: <[email-masked]>
Date: Tue, 22 Sep 2009 10:36:27 +0100

Thanks for the text. It will give me a good starting point and makes my life easier!

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of João Taveira Araújo
> Sent: 22 September 2009 10:25
> To: [email-masked]
> Subject: Re: [re-ECN] preliminary draft of problem statement- authors
> wanted
> 
> Inline,
> 
> > I really wanted a title that conveyed a little more than just
> "existing work". But I agree "myopic" is the wrong word. Will add some
> of those other bits as well. Perhaps I should group them into
> categories (things the network does and things end-systems do?).
> >
> 

I had pondered calling it something truly controversial like "existing failures". Perhaps "existing attempts

> it'll take a while before getting to a semi-finished state. 

I will try and get something a bit longer out in the next day or so to give you more to work on!

I've toyed
> c) exposing congestion corrects information asymmetry.

Indeed. My idea is to give the economic concepts in a manner that is quickly intelligible to people with no background in economics

> I'll be waiting for a future revision to bash.

The idea is to present re-feedback without going into any details. Re-ECN is a special case of re-feedback that requires more understanding. My idea is to say something like "here is re-feedback in an abstract way, this is how it reveals congestion, we have actually implemented it in a real system called re-ECN [see lots of refs for details]"

> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 22 Sep 2009 14:48:40 +0200

Regarding the problem statement, I think it should not only focus on TCP. 
Often UDP traffic is the problem with "heavy usage". Re-ECN is focusing 
mainly (so far) on TCP but congestion exposure in general is not protocol 
dependent. Having a system which requires congestion information for rate 
limiting there needs to be some (negative) impact on flows which not reveal 
this information (as proposed with the Re-ECN framework).

Then talking about trust I don't know if it is okay to just talk about "users 
want to cheat the system". I think the point is that some applications can 
gain benefit by not being TCP-fair without any disadvantages. So there needs 
to be a incentive to play fair. (When you are using TCP you might have less 
packet loss. When you are download something it might be more important to be 
as fast as possible.)

Gone wait for more input by now:-)

Mirja

On Friday 18 September 2009 11:57:34 [email-masked] wrote:
> Here is a very preliminary version of a Problem Statement for Congestion
> Exposure. It is mainly in note form and needs MAJOR bashing. I am hoping by
> posting it in this early form to persuade a few more people to volunteer as
> co-authors with me...
>
> We need to have this in a reasonable shape by mid-October in order to make
> the initial submission deadline (which is scarily close - only 4 weeks and
> 4 days away).
>

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

web: www.ikr.uni-stuttgart.de
email: [email-masked]
tel: +49(0)711/685-67973
-------------------------------------------------------------------

---

From: <[email-masked]>
Date: Tue, 22 Sep 2009 14:28:56 +0100

I completely agree we need to cover all transports, not just TCP. But TCP dies still account for 80+% of traffic by volume so it is a particularly important case, hence concentrating on it in the re-ECN protocol document. The ideal situation would be to end up with re-ECN being on ALL IP traffic, regardless of transport.

The "trust issue" is actually more subtle. Users want to get the most out of the system - they want to maximise their own return. Application writers want to sell their apps to these users and will therefore incorporate anything that improves the experience of that user. The trick is to add another layer that means the overall social welfare of the system is also maximised whilst allowing the individual user to still benefit. It is our thesis that re-ECN coupled with appropriate congestion rationing (through token bucket policing of congestion rates) and using a weighted congestion controller in the end-system achieves all these aims...

> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: 22 September 2009 13:49
> To: [email-masked]
> Cc: Moncaster,T,Toby,DER3 R
> Congestion
> make

---

From: <[email-masked]>
Date: Wed, 23 Sep 2009 16:29:18 +0100

Hi All,

As promised here is a new draft of the problem statement with a bit more meat on the bones. There is still an awful lot of work to be done on this and not too much time to do it. Our absolute deadline to get something in is October 19th - only just over 3 weeks away...

As before I would welcome any contributions of text or general comments. When I have a bit more time I will do proper xml2rfc author entries for everyone that has contributed... For political reasons I want it to be clear that this is a document that has been worked on from people across the whole range of the IETF community.

Toby

____________________________________________________________________ 
Toby Moncaster, Senior Researcher, Network Infrastructure Practise
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170

---

From: Michael Menth <[email-masked]>
Date: Wed, 23 Sep 2009 23:40:59 +0200

Hi Toby,

I read the whole document and still it is unclear in many parts. I 
marked them in the attached doc-file. I hope this helps to improve its 
clarity.

Regards,

    Michael

[email-masked] schrieb:
> ------------------------------------------------------------------------
>

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: <[email-masked]>
Date: Thu, 24 Sep 2009 09:04:03 +0100

Hi Michael,

Thanks for the useful feedback. Clearly this document is still in its
very early stages. I will try and produce a new version by end of the
week  which will hopefully address some of your comments.

Meanwhile I am still keen to get volunteers willing to contribute chunks
of text for any of the sections. 

Toby

> From: Michael Menth [mailto:[email-masked]]
> Sent: 23 September 2009 22:41
> > As promised here is a new draft of the problem statement with a bit
> more meat on the bones. There is still an awful lot of work to be done
> on this and not too much time to do it. Our absolute deadline to get
> something in is October 19th - only just over 3 weeks away...
> >
> > As before I would welcome any contributions of text or general
> comments. When I have a bit more time I will do proper xml2rfc author
> entries for everyone that has contributed... For political reasons I
> want it to be clear that this is a document that has been worked on
> from people across the whole range of the IETF community.
> >
> > Toby
> >
---------------------------------------------------------------------
> -
> University of Wuerzburg, Institute of Computer Science Am Hubland, D-
> 97074 Wuerzburg, Germany, room B206

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 24 Sep 2009 13:27:43 +0200

Hi Toby,

I've tried to fill section 5.3 (see below). I've moved some points form 4. 
(Requirements for a Solution) into this section. So I'm not sure if 4. is 
still an own section. Might be enough to include on paragraph into the 
introduction.
I hope this input helps somehow as a starting point for 5.3 or if this is not 
what was meant to be there it may be included in some other part on the 
document.

Mirja

-----------------------------------------
5.3.  Re-feedback as a potential solution

To eliminate the asymmetry of information between end-points and network 
components it can be supposed to re-insert the congestion feedback signaled 
by the receiver into the Internet. Thereby an approximation about how much 
congestion needs to be expected over the whole path is given. Having this 
information within the network the congestion policing can be enforced before 
other users get discriminated by "heavy users".

Considering the ECN information as the downstream congestion and the 
re-feedbacked congestion information as whole-path congestion, the upstream 
congestion (or rest-path congestion) can easily be achieved by subtracting 
one form the other. That enables network components to be responsive to 
congestion instead just rely on the end-hosts.

The upstream congestion reveals valuable information at ISP borders. On the 
one hand the amount of congestion that will be pushed into a domain can 
become part of an inter-domain agreement. One the other hand the amount of 
the expected upstream congestion might lead to switch to a less congestion 
network-domain (what might boost the competition to provide a more reliable 
network).

Summing up, the exposure of downstream, upstream and the whole-path congestion 
can be achieved by re-insertion of congestion notifications and will 
establish an information symmetry between users and network providers. This 
will open a door for incremental deployment and an evolution to new 
congestion responses which are not bounded anymore to an "universal rate 
adaptable policy" as the information equilibrium implicit controls a fair 
capacity sharing.

---

From: <[email-masked]>
Date: Thu, 24 Sep 2009 13:44:02 +0100

Hi Mirja,

Thanks, that is extremely useful. I will try and incorporate it into the next revision of the document...

Toby

> Sent: 24 September 2009 12:28
> To: [email-masked]

---

From: <[email-masked]>
Date: Thu, 24 Sep 2009 15:43:02 +0100

Hi Mirja,

I am in the process of integrating this into the document and expanding it. I have decided to insert some extra bits and am actually completely re-working the whole of section 5 at the same time.

One thing needs to be clarified (as I have noticed it with other people as well): you seem to have got your terminology back to front. We refer to upstream congestion as being the congestion between a given point and the origin (source) of the traffic. The downstream congestion is between that point and the destination (sink) of the traffic. In other words downstream is in the direction of flow and upstream is against the flow. This is based on the conventional usage in English when referring to real flows e.g. water in rivers...

Toby

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 24 Sep 2009 19:00:06 +0200

Hi Toby,

Sorry, yes, you're absolutly right. I felt wrong with this use of upstream and 
downstream as well. I actually checked it with the previous section and 
somehow thought it would be this way... 
But swapping down und up shouldn't be such a big problem :-)

Mirja

On Thursday 24 September 2009 16:43:02 [email-masked] wrote:
> Hi Mirja,
>
> I am in the process of integrating this into the document and expanding it.
> I have decided to insert some extra bits and am actually completely
> re-working the whole of section 5 at the same time.
>
> One thing needs to be clarified (as I have noticed it with other people as
> well): you seem to have got your terminology back to front. We refer to
> upstream congestion as being the congestion between a given point and the
> origin (source) of the traffic. The downstream congestion is between that
> point and the destination (sink) of the traffic. In other words downstream
> is in the direction of flow and upstream is against the flow. This is based
> on the conventional usage in English when referring to real flows e.g.
> water in rivers...
>
> Toby
>
> > > Meanwhile I am still keen to get volunteers willing to contribute
> >
> > chunks
> >
> > > > Subject: Re: [re-ECN] preliminary draft of problem statement-
> >
> > authors
> >
> > > > wanted
> > > >
> > > > Hi Toby,
> > > >
> > > > marked them in the attached doc-file. I hope this helps to improve
> >
> > its
> >
> > > > clarity.
> > > >
> > > > Regards,
> > > >
> > > >     Michael
> > > >
> > > > > As promised here is a new draft of the problem statement with a
> >
> > bit
> >
> > > > more meat on the bones. There is still an awful lot of work to be
> >
> > done
> >
> > > > on this and not too much time to do it. Our absolute deadline to
> >
> > get
> >
> > > > comments. When I have a bit more time I will do proper xml2rfc
> >
> > author
> >
> > > > entries for everyone that has contributed... For political reasons
> >
> > I
> >
> > > > > Toby Moncaster, Senior Researcher, Network Infrastructure
> >
> > Practise
> >
> > > > University of Wuerzburg, Institute of Computer Science Am Hubland,
> >
> > D-
> >

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 24 Sep 2009 13:03:58 -0400

> In other words downstream is in the direction of flow and upstream is against the flow. This is based on the conventional usage in English when referring to real flows e.g. water in rivers...

I understand this... but in other contexts, ironically, "upstream congestion" could also refer to congestion on a broadband uplink. Probably worth including these terms in a "definitions" section in the future. :)

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, September 24, 2009 10:43 AM
To: [email-masked]; [email-masked]
Subject: Re: [re-ECN] preliminary draft of problem statement- authors wanted

Hi Mirja,

Toby

---

From: Michael Menth <[email-masked]>
Date: Fri, 25 Sep 2009 01:00:34 +0200

Hi Toby,

here is some text for the abstract.

>    We need to add an abstract summarising the problem and pointing
>
>    towards congestion exposure as an answer...
>

I like it short:

The idea of congestion exposure means that a flow reveals an estimate of 
the congestion it causes on its remaining downstream path. It makes 
policing or other actions depending on downstream congestion in the 
Internet more effective and leads thereby to a more efficient and fairer 
Internet. This document motivates the need for congestion exposure and 
illustrates its usefulness in different use cases. Therefore, actions 
should be taken to implement a simple form of congestion exposure in the 
Internet.

However, an enumeration for what congestion exposure may be useful can 
help to catch the reader's interest:

The idea of congestion exposure means that a flow reveals an estimate of 
the congestion it causes on its remaining downstream path. Congestion 
exposure may be useful for various purposes, e.g.,  meaningful policing 
at network ingresses, congestion-based accounting between ISPs, fairer 
bandwidth sharing among users, increased trust in the 
congestion-responsiveness of end-systems, and possibly 
congestion-dependent load balancing and routing. Therefore, congestion 
exposure leads to a more efficient and fairer Internet. This document 
motivates the need for congestion exposure and illustrates its 
usefulness in different use cases. Therefore, actions should be taken to 
implement a simple form of congestion exposure in the Internet.

The abstract may also contain a summary of the problem (I don't find 
it's necessary in the abstract) and be placed before the text above:

The Internet relies on TCP's congestion control algorithm and saved it 
from a major congestion collapse since its adoption. However, TCP is 
applied on a voluntary base and the bandwidth is fairly shared among 
flows instead of users. This is problematic so that ISPs take simple or 
advanced policing actions on some sorts of traffic. However, since 
congestion on the downstream path of a flow is not visible, these 
approaches possibly hit users unnecessarily and are not effective enough.

Regards,

    Michael

---

From: <[email-masked]>
Date: Fri, 25 Sep 2009 09:54:56 +0100

And here-in lies a serious terminology problem. Downstream and upstream are always going to be seen in terms of the precise point of measurement. In a BB network we talk about upstream data going TO the network because the overwhelming majority of data flows in the other direction (DOWN to the user), and because we are talking about overall data flows. But when you are looking at individual packets belonging to a single flow you have to reverse the terminology...

Which makes me wonder if we would be better off talking about it in different terms...?

Toby

> Sent: 24 September 2009 18:04
> To: Moncaster,T,Toby,DER3 R; [email-masked]
> Cc: [email-masked]
> > In other words downstream is in the direction of flow and upstream is
> against the flow. This is based on the conventional usage in English
> when referring to real flows e.g. water in rivers...
> 
> I understand this... but in other contexts, ironically, "upstream
> congestion" could also refer to congestion on a broadband uplink.
> Probably worth including these terms in a "definitions" section in the
> future. :)
> 
> -- Rich
> 
> Behalf Of [email-masked]
> I am in the process of integrating this into the document and expanding
> it. I have decided to insert some extra bits and am actually completely
> One thing needs to be clarified (as I have noticed it with other people
> as well): you seem to have got your terminology back to front. We refer
> to upstream congestion as being the congestion between a given point
> and the origin (source) of the traffic. The downstream congestion is
> between that point and the destination (sink) of the traffic. In other
> words downstream is in the direction of flow and upstream is against
> the flow. This is based on the conventional usage in English when
> referring to real flows e.g. water in rivers...
> 
> Toby
> 
> > I've tried to fill section 5.3 (see below). I've moved some points
> form
> > 4.
> > (Requirements for a Solution) into this section. So I'm not sure if
> 4.
> > is
> > I hope this input helps somehow as a starting point for 5.3 or if
> this
> > is not
> > information within the network the congestion policing can be
> enforced
> > before
> > The upstream congestion reveals valuable information at ISP borders.
> On
> > the
> > become part of an inter-domain agreement. One the other hand the
> amount
> > of
> > establish an information symmetry between users and network
> providers.
> > This

---

From: Matthew Ford <[email-masked]>
Date: Fri, 25 Sep 2009 10:02:12 +0100

> Which makes me wonder if we would be better off talking about it in different terms...?

I'm not sure about this. Terminology is always to some extent arbitrary, 
hence the importance of defining terms in the document, so that within 
the confines of the text the meaning is clear.

Uplink and downlink are the appropriate terms for the broadband end 
site. Upstream and downstream are only meaningful in reference to a 
specific flow.

(In case it's not clear, I'm saying don't refer to 'upstream' when you 
mean 'uplink')

Mat

---

From: <[email-masked]>
Date: Fri, 25 Sep 2009 10:38:48 +0100

Hi Michael,

Thanks for this, extremely useful. I will try to decide which of these
versions fits best into the document. If anyone has views on that shout
now!

Toby

> Sent: 25 September 2009 00:01
bit
get
I

---

From: <[email-masked]>
Date: Fri, 25 Sep 2009 10:50:10 +0100

That is a very good point... and we certainly need to make sure we include a definitions section in this document.

Toby

> From: Matthew Ford [mailto:[email-masked]]
> Sent: 25 September 2009 10:02
> Cc: [email-masked]; [email-masked]
> stuttgart.de; [email-masked]
> > And here-in lies a serious terminology problem. Downstream and
> upstream are always going to be seen in terms of the precise point of
> measurement. In a BB network we talk about upstream data going TO the
> network because the overwhelming majority of data flows in the other
> direction (DOWN to the user), and because we are talking about overall
> data flows. But when you are looking at individual packets belonging to
> a single flow you have to reverse the terminology...
> >
> >>> by the receiver into the Internet. Thereby an approximation about
> how
> >>> much
> >>> congestion needs to be expected over the whole path is given.
> Having
> >>> this
> >>> one form the other. That enables network components to be
> responsive
> >> to
> >>> adaptable policy" as the information equilibrium implicit controls
> a
> >>> fair
> >>> capacity sharing.
> >>>
> >>>

---

From: <[email-masked]>
Date: Fri, 25 Sep 2009 13:13:03 +0100

Here is what I have done so far. I haven't yet incorporated one of Michael's abstracts and I still haven't added in the proper list of authors. I have heavily edited several sections but have to admit I haven't tried to read through to see if it makes any sense.

I am going to leave this now for a couple of days, probably until Tuesday. Anyone wanting to edit it in the meantime please feel free!

Toby

---

From: Tom Taylor <[email-masked]>
Date: Fri, 25 Sep 2009 08:40:43 -0400

I think it would be best to define the terms upstream and downstream 
consistently with the metaphor they imply, that is, in terms of a flow of 
packets past a certain point. One can add a note that this is NOT the same 
directionality as implied by the terms "upload" and "download", and that the 
latter terms are not used in this document (if that is true).

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 28 Sep 2009 17:22:30 +0200

Hi Toby,

two comments for my side so far:

Regarding the requirements, I'm not sure if their are understandable for 
somebody who don't know the re-ECN ideas. Although another ordering might 
help. And at this point of the document upstream and downstream congestion 
needs to be explained first.

In 5.2 I don't see why you are referring to re-ECN in the first paragraph 
while remaining very general in the rest of the section. I would prefer to 
move the reference to re-ECN to the end of the section. Where else a direct 
mention of ECN as a mechanism giving feedback would make the idea of 
re-feedback more clear to me.
Btw. why has ECN been kicked out completely?

Mirja

On Friday 25 September 2009 14:13:03 [email-masked] wrote:
> Here is what I have done so far. I haven't yet incorporated one of
> Michael's abstracts and I still haven't added in the proper list of
> authors. I have heavily edited several sections but have to admit I haven't
> tried to read through to see if it makes any sense.
>
> I am going to leave this now for a couple of days, probably until Tuesday.
> Anyone wanting to edit it in the meantime please feel free!
>
> Toby
>

---

From: <[email-masked]>
Date: Mon, 28 Sep 2009 16:29:18 +0100

Hi Mirja,

Thanks for the comments, I know the text is a bit of a mess! Hopefully things will get tidied up over the coming week (as we now know this BoF is going ahead for certain...) 

Currently the text is very much a mix of rough notes, blocks of text from various contributors and some edited stuff from me. As I said in the email I haven't myself read through the whole thing - I just wanted to get something out before the weekend for anyone who had some spare time :)

I am intending to devote a whole day this week to tidying things up and hopefully getting rid of any glaring inconsistencies. My intention is to concentrate on better explaining the problem, highlighting that congestion exposure seems to give a nice solution and show that re-feedback (in the more general case e.g. not re-ECN specifically) is a possible embodiment of congestion exposure...

Toby

> Sent: 28 September 2009 16:23
> To: [email-masked]
> Regarding the requirements, I'm not sure if their are understandable
> for somebody who don't know the re-ECN ideas. Although another ordering
> might help. And at this point of the document upstream and downstream
> congestion needs to be explained first.
> 
> In 5.2 I don't see why you are referring to re-ECN in the first
> paragraph while remaining very general in the rest of the section. I
> would prefer to move the reference to re-ECN to the end of the section.
> Where else a direct mention of ECN as a mechanism giving feedback would
> make the idea of re-feedback more clear to me.
> > authors. I have heavily edited several sections but have to admit I
> > haven't tried to read through to see if it makes any sense.
> >
> > > authors wanted
> > > The idea of congestion exposure means that a flow reveals an
> > > estimate of the congestion it causes on its remaining downstream
> > > path. It makes policing or other actions depending on downstream
> > > congestion in the Internet more effective and leads thereby to a
> > > more efficient and fairer Internet. This document motivates the
> need
> > > for congestion exposure and illustrates its usefulness in different
> > > use cases. Therefore, actions should be taken to implement a simple
> > > form of congestion exposure in the Internet.
> > >
> > > However, an enumeration for what congestion exposure may be useful
> > > can help to catch the reader's interest:
> > >
> > > The idea of congestion exposure means that a flow reveals an
> > > estimate of the congestion it causes on its remaining downstream
> > > path. Congestion exposure may be useful for various purposes, e.g.,
> > > meaningful policing at network ingresses, congestion-based
> > > accounting between ISPs, fairer bandwidth sharing among users,
> > > increased trust in the congestion-responsiveness of end-systems,
> and
> > > possibly congestion-dependent load balancing and routing.
> Therefore,
> > > congestion exposure leads to a more efficient and fairer Internet.
> > > This document motivates the need for congestion exposure and
> > > illustrates its usefulness in different use cases. Therefore,
> > > actions should be taken to implement a simple form of congestion
> > > exposure in the Internet.
> > >
> > > The Internet relies on TCP's congestion control algorithm and saved
> > > it from a major congestion collapse since its adoption. However,
> TCP
> > > is applied on a voluntary base and the bandwidth is fairly shared
> > > among flows instead of users. This is problematic so that ISPs take
> > > simple or advanced policing actions on some sorts of traffic.
> > > However, since congestion on the downstream path of a flow is not
> > > visible, these approaches possibly hit users unnecessarily and are
> > > not effective enough.
> > >
> > >
> > > Regards,
> > >
> > >     Michael
> > >
> > > > Thanks for the useful feedback. Clearly this document is still in
> > > > its very early stages. I will try and produce a new version by
> end
> > > > of the week  which will hopefully address some of your comments.
> > > >
> > > >> I read the whole document and still it is unclear in many parts.
> > > >> I marked them in the attached doc-file. I hope this helps to
> > > >> improve
> > >
> > > its
> > >
> > > >> clarity.
> > > >>
> > > >> Regards,
> > > >>
> > > >>     Michael
> > > >>
> > > >> get something in is October 19th - only just over 3 weeks
> away...
> > > >>
> > > >> entries for everyone that has contributed... For political
> > > >> reasons I want it to be clear that this is a document that has
> > > >> been worked on from people across the whole range of the IETF
> community.
> > > >>
> > > >>> Toby
> > >
> > >
> > > >>> Practise B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918
> > > >>> 901170
> > > >
> > > > -----------------------------------------------------------------
> -
> > > > ---
> > > >
> > > >> -
> > > >>
> > > >>> --
> > > >>>
> > > >> Dr. Michael Menth, Assistant Professor University of Wuerzburg,
> > > >> Institute of Computer Science Am Hubland,
> > >
> > > D-
> > >
> > > Dr. Michael Menth, Assistant Professor University of Wuerzburg,
> > > Institute of Computer Science Am Hubland, D-97074 Wuerzburg,
> > > Germany, room B206
> University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 29 Sep 2009 01:59:45 +0100

Michael,

Going back a few days in this thread... I'm concerned about using the 
phrase "...a flow reveals..." The issue is subtle.

The idea (of re-ECN) is that *packets* reveal remaining congestion on 
their respective paths. But only when measured in aggregate. The 
aggregate doesn't have to be a flow, it can be all the traffic 
passing through an interface card. Or all the traffic matching a 
link-local VLAN tag, etc.

Of course congestion is changing all the time, and the encoding is 
unary with only one bit per packet. So each packet doesn't say 
anything accurate on its own. But they do when collected into any aggregate.

So I'd prefer to say
"The idea of congestion exposure is for packets to reveal an estimate 
of the congestion they will cause on the rest of their path across 
the Internet."

I'd quite like to say (either early in the intro, or in the abstract):
"The aim is to be able to measure the volume of downstream congestion 
for any aggregate of traffic as easily as data volume can be measured 
at any granularity (per flow, per user, per any identifier, over any 
duration)."

Bob

At 00:00 25/09/2009, Michael Menth wrote:
>more efficient and fairer Internet. This document motivates the need 
>path. Congestion exposure may be useful for various purposes, 
>e.g.,  meaningful policing at network ingresses, congestion-based 
>increased trust in the congestion-responsiveness of end-systems, and 
>possibly congestion-dependent load balancing and routing. Therefore, 
>it from a major congestion collapse since its adoption. However, TCP 

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 29 Sep 2009 02:22:28 +0100

Mirja,

Going back to you posting in this thread a few days ago...

The last sentence said, "...implicit[ly] controls a fair capacity sharing"

Certainly, I wear out my keyboard telling people 
that flow rate equality shouldn't be called 
fairness at all. But we need to avoid implying we 
have the one and only definition of fair capacity sharing in its place.

"...provides a metric that can be used to share 
capacity under a range of fairness policies 
likely to be needed in production networks."

Bob

---

From: Michael Menth <[email-masked]>
Date: Wed, 30 Sep 2009 00:41:53 +0200

Hi Bob,

I believe we should substitute "flows" by "traffic" and not by "packets" 
becaus traffic is a more general aggregation of packets than flows:

The idea of congestion exposure means that traffic reveals an estimate 
of the congestion it causes on its remaining downstream path. It makes 
policing or other actions depending on downstream congestion in the 
Internet more effective and leads thereby to a more efficient and fairer 
Internet. This document motivates the need for congestion exposure and 
illustrates its usefulness in different use cases. Therefore, actions 
should be taken to implement a simple form of congestion exposure in the 
Internet.

Regards,

    Michael

Bob Briscoe schrieb:
> aggregate doesn't have to be a flow, it can be all the traffic passing 
> through an interface card. Or all the traffic matching a link-local 
> VLAN tag, etc.
>
> of the congestion they will cause on the rest of their path across the 
> Internet."
>
>> The idea of congestion exposure means that a flow reveals an estimate 
>> of the congestion it causes on its remaining downstream path. It 
>> makes policing or other actions depending on downstream congestion in 
>> the Internet more effective and leads thereby to a more efficient and 
>> fairer Internet. This document motivates the need for congestion 
>> exposure and illustrates its usefulness in different use cases. 
>> Therefore, actions should be taken to implement a simple form of 
>> congestion exposure in the Internet.
>>
>> The idea of congestion exposure means that a flow reveals an estimate 
>> of the congestion it causes on its remaining downstream path. 
>> Congestion exposure may be useful for various purposes, e.g.,  
>> meaningful policing at network ingresses, congestion-based accounting 
>> between ISPs, fairer bandwidth sharing among users, increased trust 
>> in the congestion-responsiveness of end-systems, and possibly 
>> congestion-dependent load balancing and routing. Therefore, 
>> should be taken to implement a simple form of congestion exposure in 
>> the Internet.
>>