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

[John Leslie <[e-mail]>]

[e-mail] <[e-mail]> wrote:
> 
> http://www.ietf.org/id/draft-moncaster-congestion-exposure-problem-02.txt

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

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

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

   This part seems OK...

--
John Leslie <[e-mail]>