From: "Richard Scheffenegger" <rscheff@gmx.at>
To: "Jim Gettys" <jg@freedesktop.org>, <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Bloat on Layer 2 Was: ECN & AQM Hall of Fame?
Date: Mon, 31 Jan 2011 16:36:00 +0100 [thread overview]
Message-ID: <A057D4F27D224ECD82B43262646EB38A@srichardlxp2> (raw)
In-Reply-To: <4D46C44F.8000406@freedesktop.org>
There is currently a IPPM Draft in the works, talking about TCP Performance
measurement methodology. It talks a little bit about measuring throughput
during steady state and using in-band latency measurements (instead of ICMP
pings in parallel):
http://tools.ietf.org/html/draft-ietf-ippm-tcp-throughput-tm-11
As of yet, there is no detailed discussion section about buffer bloat in
that doc (and it may be out-of-scope to discuss this effect in there very
extensively), but it might be good to have more knowledgable people review
that doc as well, and give some feedback to the authors.
After all, doing meaningful measurements is obviously the very first step
necessary to reveal this to a larger audience and make people aware. Hinting
at buffer bloat in a standard doc that talks about TCP performance
measurment seems to be a good idea!
Best regards,
Richard
BTW, I found this legacy document, where the authors boldly claim that more
buffers are always better for 802.11 networks, to circumvent costly TCP
congestion control decisions....
http://csl.snu.ac.kr/~ecpark/papers/TCP_WLAN_TMC08.pdf
Also, this paper hints that more buffers are better:
http://www.ieee-infocom.org/2004/Papers/16_1.PDF
(I didn't spot a mentioning, that a packet switches network with infinite
buffering will deliver zero goodput under congestion, as has been prooven in
the dawn of time :). Here, the authors seem to be concerned only with work
conservation on each individual router interface - i.e. that no interfaces
is ever idle....). But at least: "The important aspect of end-to-end packet
delay evaluation taking into consideration retransmissions of lost packets
is beyond the scope of this paper."
Ah, so many unexploited paths to go (tweaking ACK windowsizes by the network
in 802.11, for example, to give detailed congestion/network goodput feedback
to the tcp sender)....
Richard
----- Original Message -----
From: "Jim Gettys" <jg@freedesktop.org>
To: <bloat@lists.bufferbloat.net>
Sent: Monday, January 31, 2011 3:16 PM
Subject: Re: [Bloat] Bloat on Layer 2 Was: ECN & AQM Hall of Fame?
> On 01/31/2011 03:41 AM, Florian Lohoff wrote:
>> On Sun, Jan 30, 2011 at 11:40:05PM +0100, Richard Scheffenegger wrote:
>>> Hi,
>>>
>>> wasn't there talk about getting a Hall of Fame for networks / operators,
>>> which are using and actively supporting AQM and ECN in their
>>> administrative
>>> domain?
>>>
>>
>> The problem is not only in the IP Path.
>>
>> In the old days i was used to be able to work interactive on a Serial
>> connection with 33600 Bit/s shared with 10 Dialup users.
>>
>> After reading Jims blog i started to dig in our Network and found
>> huge buffers on the Huawei MA5600 DSLAMs which are Ethernet based
>> DSLAMs. These DSLAMs are basically invisible to the user as they
>> are only in the L2 PPPoE path for the customer.
>>
>> I found the Buffer to be roughly 1MByte per Line. With a 1MBit/s DSL
>> line this is roughly 10s worth of Buffer which i can observe on my line
>> in the real world.
>
> Yes, Dave Clark first ran into bufferbloat on a DSLAM he runs, and it was
> 6 seconds.
>
> Even a gigabit ethernet switch needs to have buffering (which will work
> out to 8ms, worst case).
>
>
>>
>> There is no way of tuning this buffer based on the speed or even shrink
>> it so its difficult to fix.
>
> DOCSIS has the same issue: it's not currently tunable for the speed, and
> different people are provisioned greatly different bandwidth.
>
>>
>> ANCP + a shaper on the BRAS would be a solution which is basically how i
>> solved
>> it for me - As i have a fixed rate 1MBit/s DSL i attached a 1MBit/s rate
>> limiter to my profile on the BRAS which immediatly fixed the problem for
>> me.
>>
>> And the Hall of Shame probably is a good idea - but wont fix it. The
>> ISPs are not aware of the problem as testing happens on empty lines with
>> 30cm of wire. I sent the link to Jims blog to certain people and the
>> DSLAM
>> guys immediatly promised to contact Huawei about the non tunable
>> buffersize.
>>
>
> Yes, please do. And yes, it is the lack of "latency under load" tests
> that mean that most won't see it in typical testing.
>
> That we're also trying to fix, by getting the formal tests done by
> government agencies and testing services to add such a test. I think
> we're likely to succeed for speedtest.net and for the FCC broadband test.
> Those who are helping other government's agencies out with similar tests
> should also be educated.
>
> I believe in the meanwhile, and because having the tests for development
> lab and corporate environments is also really necessary and those tests
> typically aren't available in those environments, we should try to build
> some better tests here and make them available to everyone. This is part
> of the purpose of bufferbloat.net.
>
> And please, please make sure everyone treads gently: we're all bozos on
> this glass bus, and don't pick up stones. Everyone (myself included) has
> been making the same class of mistakes, again and again; so do be gentle.
> The problem is truly counter intuitive to most people.
>
> I will be presenting at the IETF transport area meeting in Prague.
> Best regards,
> - Jim
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
next prev parent reply other threads:[~2011-01-31 15:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-30 22:40 [Bloat] " Richard Scheffenegger
2011-01-31 0:24 ` Jim Gettys
2011-01-31 1:03 ` Dave Täht
2011-01-31 1:43 ` Jim Gettys
2011-01-31 8:41 ` [Bloat] Bloat on Layer 2 Was: " Florian Lohoff
2011-01-31 14:16 ` Jim Gettys
2011-01-31 15:36 ` Richard Scheffenegger [this message]
2011-01-31 17:35 ` Dave Täht
2011-01-31 19:16 ` Jim Gettys
2012-04-13 13:38 ` Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A057D4F27D224ECD82B43262646EB38A@srichardlxp2 \
--to=rscheff@gmx.at \
--cc=bloat@lists.bufferbloat.net \
--cc=jg@freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox