[Bloat] Overview modifications

[Jim Gettys]

On 02/06/2011 09:39 AM, Eric Raymond wrote:
> I'm trawling through the mailing list archives for bits to improve the
> overview document with.
>
> jg wrote:
>> Note that lossy wireless networks behave much better than "clean"
>> variable bandwidth wireless networks; packet drops due to such losses at
>> least cause TCP to back off sometimes....
>
> This is an important enough point to be in the overview.
>
> Change in progress -- append to the "Hating" paragraph the following
> sentence: "Lossy networks such as wireless actually show less chaotic
> behavior under load than clean ones."  Is this correct and adequate?

It's not chaotic behaviour.  In fact, it is much more worrying: it is 
periodic (oscillatory) behaviour.  Chaos is good, in this case.

My nightmare, is that as traffic shifts over more and more to saturated 
links as XP retires, we end up with self synchronising behaviour on a 
local, regional or global scale, and havoc ensues, and parts/all of the 
Internet stop working. Whether these fears are justified, I do not know.

Think: we may be a column of soldiers in cadence approaching a bridge...

>
> Ah, now I've found jg's original reply on the overview.
>
> jg wrote:
>> 1) the latency-speed connection needs to be emphasised; along with
>> bandwidth !=speed. You can at least start to attack the conflation of
>> "speed" and "bandwidth" that is in the market.
>
> *Excellent* point.
>
> New 'graph, after the one on DNS et al going kerflooey.
>
>      The way these latency-sensitive services degrade illustrates a
>      general point.  From a user point of view, perceived speed of the
>      network is much more a function of latency (time to get a
>      response) than of bandwidth (ability to bulk-ship). Thus,
>      bufferbloat hammers the performance characteristic users care
>      about most.
>
> jg:
>> To use the highway analogy, only a few areas have carpool lanes, and
>> most of the highway is still jammed.  Once the carpool lanes are gone
>> (you get to another part of the network), you're still stuck behind
>> miles of traffic.
>
> Yup, I'll add this to the QoS section.
>
> Jim criticized "How Hard Is It?"  Rewritten section looks like this:
>
> ----------------------------------------------------------------------
> == How Hard Is It? ==
>
> We started by asserting that bufferbloat is easy to fix.  First
> we'll lay out the both the reasons for optimism, then the problems:
>
> First, it's easy to detect once you understand it - and verifying
> that you've fixed it is easy, too.
>
> Second, the fixes are cheap and give direct benefits as soon as
> they're applied.  You don't have to wait for other people to fix
> bufferbloat in their devices to improve the performance of your own.
>
> Third, you'll usually only have to fix it once per device; continual
> tuning isn't necessary.
>
> Fourth (and importantly!), trying to fix bufferbloat won't significantly
> increase your risk of a network failure. If you fumble the first time,
> it's reversible.
>
> The hard problems are these:
>
> First, we don't yet know how to write good buffer-management rules for
> networks with variable bandwidth.  This is a research area, though not
> an especially difficult one: good results seem likely in 12 to 36
> months.
>
> Second, a lot of routers (especially consumer-grade ones) are difficult
> enough to upgrade firmware on that they will need to be replaced. Since
> the IPv6 transition is bearing down on us, however, it may be possible
> to fold our upgrade wave into that one.
> ----------------------------------------------------------------------

There is an additional point: understanding bufferbloat may allow you to 
avoid bufferbloat suffering immediately.  Example:

Upgrade your wireless access to 802.11N, so that the bufferbloat stays 
in the broadband hop where you may have already mitigated it, rather 
than fighting bufferbloat in the 802.11 hop, where we don't have as 
effective short term mitigations.

   or:

Wander to a part of your house where the 802.11 "goodput" is above that 
of the broadband link, for the same reasons.

Won't help you when doing local copy/backup to your file server; then 
you really do need to start working on your laptop/router.  Unless you 
plug into ethernet, of course, again, as a short term mitigation.


>
> dtaht wrote:
>> Both ARE useful, but can be addressed in order of reducing unmanaged
>> buffers, applying AQM, and then QoS.
>
> That priority list needs to be made explicit in the overview.  I will now do so.
> End of section:
>
>      Explicit QoS may a place in our overall strategy for network performance,
>      but the right order to do things is this: first reduce unmanaged buffers,
>      then get buffer queue management right, then implement QoS on top of that.
>
> richard wrote:
>> Might add a note that if equipment does need to be changed out, isn't it
>> nice that we also have to change it out for the IPV4->IPV6 problem too
>> and/or that we're hoping the device manufacturers will address the
>> problem in the IPV6 equipment roll out.
>
> Done, as you can see above.
>
> richard:
>> Here in Canada the metered billing is very high visibility at the
>> moment. Would love to be able to point to this from some of the
>> discussion areas ASAP :)
>
> This *doesn't* go in the overview.  Two reasons:
>
> Here, I don't want to be topical in a way likely to go stale rapidly.
>
> Also, dtaht and jg are right that there's a political hazard in
> getting too far into the whole tiered-billing/usage-metering issue.  I
> don't think we can or should avoid it entirely; the fact that fixing
> bufferbloat may eliminate the technical necessity is simply too
> important a fact to elide.  On the other hand, we need to be very
> careful and diplomatic and not pick any fights about this.
>
> That completes my mining of the back mail.

There is tons of mining in the replies to my blog to do.

>
> I'll expect another round of responses to this post, then I'll run
> an edit for conciseness and length, then I'll start transplanting
> the overview onto the wiki.