Subject: [re-ECN] FW: New Version Notification for draft-moncaster-congestion-exposure-problem-02

From: <[email-masked]>
Date: Fri, 23 Oct 2009 14:09:30 +0100

I have posted an updated version taking into account comments I received over the past week or so. Apologies if I have missed any comments.

http://www.ietf.org/id/draft-moncaster-congestion-exposure-problem-02.txt

The big missing pieces still are: use cases (I have added a couple of sentences suggesting what the end result should look like) and security (which Bob is hoping to be able to do - meanwhile I added some rough notes that I hope are a start).

If anyone has anything to contribute before the ID deadline on Monday let me have it by 1200 GMT Monday and I will endeavour to add it...

Toby

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

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 23 October 2009 13:30
To: Moncaster,T,Toby,DEE1 R
Cc: Krug,AL,Louise,DES3 R; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-moncaster-congestion-exposure-problem-02 

A new version of I-D, draft-moncaster-congestion-exposure-problem-02.txt has been successfuly submitted by T Moncaster and posted to the IETF repository.

Filename:	 draft-moncaster-congestion-exposure-problem
Revision:	 02
Title:		 The Need for Congestion Exposure in the Internet
Creation_date:	 2009-10-23
WG ID:		 Independent Submission
Number_of_pages: 19

Abstract:
The success of the Internet is largely down to the ability to share
capacity amongst all users while avoiding congestion collapse.
However this relies on the cooperation of all end users to work
efficiently - even if everyone uses TCP, a minority of users can
command a large share of the network.  To mitigate the growth in this
problem over recent years, some ISPs have imposed various controls on
traffic using a range of proprietary approaches.  These controls set
ISPs in conflict with their customers and with some regulators.

The root of the problem lies in the fact the ISPs are unable to see
the most important information about the traffic - namely the amount
of congestion that traffic is going to cause in the network.  We
propose congestion exposure as a possible solution.  This allows
packets to carry an accurate prediction of the congestion they expect
to cause downstream.  This memo sets out the motivations for
congestion exposure and introduces a strawman protocol designed to
achieve congestion exposure.

The IETF Secretariat.

---

From: John Leslie <[email-masked]>
Date: Fri, 23 Oct 2009 10:55:10 -0400

> ISPs in conflict with their customers and with some regulators.

   I really don't think this will do.

   "largely down to" doesn't convey to all readers the meaning I think
we intend, which is much closer to "depends upon".

   "congestion collapse" is basically a solved problem -- even UDP
which is completely congestion-unaware isn't causing collapse.

   "cooperation" isn't quite the right word, and it's between stacks,
not users.

   "everyone uses TCP" simply isn't an option -- the conventional
wisdom is everyone using "TCP-friendly congestion control"; and that's
what we're trying to offer an alternative to.

   ISPs are trying to "solve", not "mitigate", and the "problem" they
try to solve isn't at all defined in this text.

   The problem of "some regulators" is twofold: government regulation
has to work from inadequate information, and government regulation
will be different for differing jurisdictions -- all trying to regulate
something which cannot be limited to their jurisdiction. (IMHO, we'd
do better to mostly avoid talking about it.)

   Furthermore, I don't think this captures enough of Bob Briscoe's
understanding of the problem space. To recap Bob:
] 
] TCP *does* prevent high bandwidth apps. That's the problem.

   Seriously! TCP-friendly congestion control prevents high-bandwidth
from _ever_ filling certain pipes.

   AIMD causes high-bandwidth to back off much more than low-bandwidth:
thus the presence of both high-bandwidth and low-bandwidth causes
"random" fluctuation in drop percentage, with only the high-bandwidth
drop signals being sufficient to reduce congestion. (The low-bandwidth
flows are also punished more than necessary: that's actually the
problem ISPs are trying to solve.)

] And implying intensive bandwidth usage needs to be prevented is
] rubbish marketing for the idea behind ConEx, given it *enables*
] higher bandwidth apps.

   We really shouldn't be doing "rubbish marketing" for ISP measure
"aimed at" reducing congestion (especially if they don't work).

   High-bandwidth usage should indeed be asked to back off (or pay
the cost of upgrading the bottleneck), but they should be asked to
back off the correct amount and low-bandwidth apps usually don't
actually need to back off (when high-bandwidth apps are also
forwarding through the bottleneck).

] I believe congestion exposure will enable an Internet where high
] bandwidth and high volume apps can co-exist optimally. I want to
] encourage high bandwidth apps *and* high volume apps, not prevent
] either.

   (Bob is correct that high-bandwidth and high-volume are different
issues.)

] I sometimes think there really are people on this list who believe
] that too much use of the Internet is the problem. Or congestion is
] the problem. No. No. No. Rubbish capacity sharing is the problem.

   Hopefully we don't have many folks that think too-much-Internet
is the problem. ;^)

   But we do have folks that think congestion is the problem. They
need to read Bob more carefully.

] This is the same point as moving away from TCP-friendly, which is
] what LEDBAT aims for. LEDBAT deliberately allows interactive stuff
] to go faster while background stuff temporarily goes slower. That
] is the opposite of TCP-friendly, which is better overall.

   Do we agree that it's good for interactive stuff to go faster
while background stuff backs off? I hope so...

] With congestion exposure, we will be able to have weighted
] congestion control. Then we should be able to repeat the LEDBAT
] trick recursively as different size flows arrive.

   We aren't actually in competiton with LEDBAT; but we do intend
that ConEx should be a trick in LEDBAT's bag-of-tricks.

   And our very specific intent is that congestion signals should
enable high-bandwidth apps to know how much to back off, leaving
low-bandwidth interactive apps free to run full-speed.

] Ie. imagine three types of flows co-existing:
] 
] - small foreground flows
] - medium middleground flows
] - larger background flows
] 
] The larger background can be background to the medium middleground,
] and both can be background to the small foreground. This can continue
] with any number of recursions. All transfers complete much faster,
] except the very largest flows which should complete in not much more
] time than they do now.

   Actually, even the very largest would probably complete _faster_
than they do now, because they'd never have to back off more than
actually necessary to let the other flows run full-speed.

   So let me try a rewrite of the first paragraph:
" 
" Today's Internet depends upon TCP Congestion Control not only to
" avoid "congestion collapse" but to signal how much the "bottleneck"
" paths are congested. These signals are only visible to end-systems,
" many (but not all) of which implement "TCP-friendly" congestion
" control. Network Infrastructure managers, not being able to see
" these signals, can't tell whether a "moderate" level of packets
" being dropped is due to "unfriendly" congestion control or simply
" a large number of low-bandwidth flows. Thus, they choose to
" implement bandwidth and/or usage limits which cannot solve the
" packet-drop problems and are leading to calls for government
" regulation (which also cannot solve the problem).

> achieve congestion exposure.

   This part seems OK...

--
John Leslie <[email-masked]>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Sat, 24 Oct 2009 19:57:31 +0200

Hi,

I think the problem statement should be shorten a little as a lot of things 
are mentioned twice and the introduction doesn't come clearly to the point. 
Not sure if someone not involved into the re-ECN activity will be able to 
grab the problem in some simple sentences after reading this. 
Generally, I think it is really good readable, so simply shorten it might 
help...?

Here is some input from my side for the use cases. Not sure if that is what is 
was intended to be, but at least it's some input:

"Congestion exposure can enable ISPs to give an incentive to end-systems to 
response to congestion in a way that leads to a better share of the available 
capacity. For example the introduction of a per-user congestion volume might 
motivate "heavy-user" to back off with their high-bandwidth traffic (when 
congestion occurs) to save their congestion volume for more time-critical 
traffic. If every end-system reacts to congestion in such a way that it 
avoids congestion for non-critical traffic and allow a certain level of 
congestion for the more important traffic (from the user's point of view), 
the all-over user experience will be increased. More-over the network might 
be utilized more equally when less-important traffic is shifted to less 
congested time slots."

Mirja

On Friday 23 October 2009 15:09:30 [email-masked] wrote:
> I have posted an updated version taking into account comments I received
> over the past week or so. Apologies if I have missed any comments.
>
> The big missing pieces still are: use cases (I have added a couple of
> sentences suggesting what the end result should look like) and security
> (which Bob is hoping to be able to do - meanwhile I added some rough notes
> that I hope are a start).
>
> If anyone has anything to contribute before the ID deadline on Monday let
> me have it by 1200 GMT Monday and I will endeavour to add it...
>
> Toby
>
> Cc: Krug,AL,Louise,DES3 R; [email-masked];
> [email-masked]; [email-masked];
> [email-masked] Subject: New Version Notification for
> draft-moncaster-congestion-exposure-problem-02
>
>
> A new version of I-D, draft-moncaster-congestion-exposure-problem-02.txt
> has been successfuly submitted by T Moncaster and posted to the IETF
> repository.
>
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn

-- 
-------------------------------------------------------------------
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: Michael Menth <[email-masked]>
Date: Mon, 26 Oct 2009 01:24:45 +0100

Hi Toby,

I did a review of Sections 1-4. You find my comments in the attached 
doc. I also formulated a use case on meaninful policing, differentiating 
in per-flow and per-customer congestion policing and showing that the 
latter sets incentives for congestion-minimizing transport protocols and 
allows fairer tariffs (rewording required).

Kind regards,

    Michael

-- 
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: Mon, 26 Oct 2009 10:05:06 -0000

Hi Mirja,

I agree that it is starting to get a bit long - that tends to be the way with documents like this where multiple people are contributing text.

Realistically I am not going to be able to do a major revision today before the deadline, however I will try and incorporate your text into the use cases section so we have something for people to start to discuss.

Thanks,

Toby

> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: 24 October 2009 18:58
> To: [email-masked]
> Cc: Moncaster,T,Toby,DEE1 R
> Subject: Re: [re-ECN] FW: New Version Notification for draft-moncaster-
> congestion-exposure-problem-02
> 
> Hi,
>

---

From: <[email-masked]>
Date: Mon, 26 Oct 2009 10:06:52 -0000

Hi Michael,

Thanks as always for getting your review out so quickly. I am not sure I will have time to do more than a quick pass through the document this afternoon before the cut-off. However I will certainly incorporate your text into the use-cases...

Toby

> From: Michael Menth [mailto:[email-masked]]
> Sent: 26 October 2009 00:25
> Cc: re-ECN unIETF list
> doc. I also formulated a use case on meaninful policing,
> differentiating in per-flow and per-customer congestion policing and
> showing that the latter sets incentives for congestion-minimizing
> transport protocols and allows fairer tariffs (rewording required).
> 
> Kind regards,
> 
>     Michael
> 
> > I have posted an updated version taking into account comments I
> received over the past week or so. Apologies if I have missed any
> comments.
> >
> > http://www.ietf.org/id/draft-moncaster-congestion-exposure-problem-
> 02.
> > txt
> >
> (which Bob is hoping to be able to do - meanwhile I added some rough
> notes that I hope are a start).
> >
> > If anyone has anything to contribute before the ID deadline on Monday
> let me have it by 1200 GMT Monday and I will endeavour to add it...
> >
> > Toby
> >
> > A new version of I-D, draft-moncaster-congestion-exposure-problem-
> 02.txt has been successfuly submitted by T Moncaster and posted to the
> IETF repository.
> >
> University of Wuerzburg, Institute of Computer Science Am Hubland, D-
> 97074 Wuerzburg, Germany, room B206