Re: [ledbat] Suggestion re "How to deal with the modem buffer"

Thanks Nick,

Big thing -- as in defining a new addressable hardware parameter?  (Isn't
that more of an IEEE thing?)

Haven't we all been dealing with this for years?  On the chance that we
won't get anything from the ISP or hardware vendors soon (given the various
modems and buffers out there), what can users do now?  What can developers
do to keep users from calling and saying, "The Internet is down?" that would
still keep working if we did make progress on dealing with the buffer
itself?

Isn't avoiding the effects of the buffer why some VOIP uses a packet every
50 ms? Isn't the buffer's effects why my Ubicom QoS gateway dynamically
fragments packets and delivers them upstream at a rate lower than my
subscribed speeds?  Couldn't we take these concepts and suggest a way for
P2P programs to sense and adjust to the buffer's effects so that running
torrents never fills the buffer (e.g. speed test, set upload limit to 25% of
result, check RTT somewhere, addititive increase until RTT average starts to
rise).?

Robb

On Thu, Nov 20, 2008 at 12:50 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu
> wrote:

>
> On Nov 20, 2008, at 2:32 PM, Robb Topolski wrote:
>
>  Comment in response to Nick's VG presentation:  Even if there is no silver
>> bullet, as a "to do item" for the WG, in the recommendations and current
>> practices paper, we ought to address the issue that Nick brings up on how to
>> deal with large modem buffers.
>>
>
> The big thing is it needs to be parameterizeable by the ISP, with exposure
> to whatever ISP control mechanisms are available.
>
> There needs to be a floor of a couple of packets for the DSL case, and
> nothing can really fix that.  Thus a floor of probably 4 packets * 1500B MTU
> => ~8 kB as a floor.  OTOH, uploads from a 128 Kbps DSL link are going to be
> painful, period.
>
>
> Once you shift to higher bandwidth networks, the buffering needs to be
> bandwidth * generic RTT.
>
> A good generic RTT for most uses is probably 150ms, which puts a bound on
> additional latency & jitter for realtime uses (VoIP, games, SYNs for web
> surfing) of 150ms regardless of the TCP flows going simultaneously,  while
> ensuring that you can do a full rate TCP flow for any host <150ms away, and
> only lose throughput for hosts >150ms away.
>
>
> Thus for a 1 Mbps DOCSIS link, it should be ~20 kB, and at a 4 Mbps link,
> it should be ~80 kB.
>
> The key thing for the vendors is the following:  It is ENCOURAGED to
> oversize the buffer (eg, 256 kB), but the ISP MUST be able to remotely
> configure the access device to use less than the full buffer capacity, as
> this way the device can be parameterized for the actual network, as the same
> modem is used for different service-tiers.
>
>

-- 
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/