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

From: "Robb Topolski" <[email-masked]>
Date: Thu, 20 Nov 2008 12:32:40 -0800

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.

-- 
Robb Topolski ([email-masked])
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
ledbat mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ledbat

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 20 Nov 2008 14:50:36 -0600

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

---

From: "Robb Topolski" <[email-masked]>
Date: Thu, 20 Nov 2008 14:42:46 -0800

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 <[email-masked]
> 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.
>
> 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.
>
>
> 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.
>
> 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.
>
>