[139387] in North American Network Operators' Group
Re: IPv4 Address Exhaustion Effects on the Earth
daemon@ATHENA.MIT.EDU (Jared Mauch)
Tue Apr 5 18:18:48 2011
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <4D9B9299.4080808@freedesktop.org>
Date: Tue, 5 Apr 2011 18:17:56 -0400
To: Jim Gettys <jg@freedesktop.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Apr 5, 2011, at 6:07 PM, Jim Gettys wrote:
> On 04/05/2011 05:59 PM, Michael Proto wrote:
>> On Tue, Apr 5, 2011 at 5:38 PM, Jared Mauch<jared@puck.nether.net> =
wrote:
>>> On Apr 4, 2011, at 4:30 PM, Jim Gettys wrote:
>>>=20
>>>> Note that the paper "Characterizing Residential Broadband Networks" =
by Dischinger, et. al. indicates that a large fraction (in their 2 year =
old sample, 30% or so) of broadband head ends are running without RED, =
and should be doing so if at all possible; alternatives are years out by =
the time they are tested and deployed, and operators running without it =
in congested systems are inflicting pain on their customers.
>>> Something I've observed is if you are sending data 'upstream' on the =
cable modem setup i have (16 down/ 2 up) and you saturate the upstream, =
the buffering destroys any downstream capability at the same time. I'm =
not even sure where to start diagnosing to explaining this to the =
carrier involved, as this isn't the desired behavior of a "business =
class" service.
>>>=20
>>> - Jared
>>>=20
>> Isn't this just a case or prioritizing outbound ACKs?
>>=20
>> http://www.benzedrine.cx/ackpri.html
>>=20
>=20
> Nope. Your acks get delayed to what you are sending upstream, behind =
the downstream traffic.
>=20
> Bufferbloat hurts both directions, once saturation occurs and your =
latencies start to go up.
>=20
> Note that on many of these links, the RTT becomes (literally) as =
though you are half way (or further than) the moon.
> =20
I sent a private reply, but I guess i'll post some of it here:
1) there are no ways to identify the devices doing the buffering and/or =
drop counts
2) I can obviously feed the cable modem much faster on the lan vs what =
it can send upstream
Doing things like rate-limiting/QoS are merely just papering over the =
problem. I would take a T1 and rate-limit it to 1.2Mb/s for TCP to =
allow VoIP to work. Junipers can buffer up to 1 second on these =
low-speed interfaces, which obviously creates the problems you describe.
There are a lot more problems with the gateway devices, such as the =
forcible dns proxy that exists.
- Jared=