[LEDE-DEV] TR-069, bufferbloat, and BQL

[Dave Taht]

On Sat, May 28, 2016 at 5:34 AM, Hauke Mehrtens <hauke at hauke-m.de> wrote:
> On 05/27/2016 12:43 PM, David Lang wrote:
>> On Thu, 26 May 2016, Delbar Jos wrote:
>>
>>> We are conscious of the fact that together with the proposals made by
>>> Felix, Luka and Wojtek we are now looking at many "competing"
>>> proposals. As a next step, we recommend to organize a workshop, at a
>>> practical location and time, where we put everything on the table and
>>> define the most appropriate path forward to the benefit of OpenWrt as
>>> a whole.
>>
>> nothing wrong with supporting many different remote management daemons.
>>
>>> TR-069 is a complicated remote management system and in order to make
>>> this initiative a success, we must ensure that the complexity is
>>> handled in an elegant way and with respect for OpenWrt's core
>>> architecture. More than on the protocol itself, we believe that we
>>> should focus on the architectural enhancements required to support
>>> remote management in general.
>>
>> What is it that you think is needed to "support remote management in
>> general"?

I am curious if TR-069 has any ability to set parameters for upload
and download speeds, so they could be leveraged by sqm-scripts to
manage the bufferbloat that DSL modems and dslams have?

Also:

I have been hoping for nearly 4 years now that we'd see *someone*
actually produce a BQL enabled dsl driver for their modem interface so
advanced QoS techniques wouldn't be needed on outbound, where we could
just enable fq-codel on top of a tightly written driver and be done
with it. 100 million modems, all exhibiting 100s of ms of extra,
unneeded latency, under load:

http://www.dslreports.com/speedtest/results/bufferbloat?up=1

sadly, aside from the freebox revolution v6, I'm not aware of anyone
actually doing dsl more right yet. (?)

>> It's worth pointing out that many people are remotely managing OpenWRT
>> devices, Ansible/Salt/Puppet/Chef/etc are all common tools for the job.
>>
>> now, those are all tools aimed at managing Linux Servers, not networking
>> gear, but OpenWRT is a server.
>>
>> So I'd suggest starting off by creating a daemon that talks <your
>> protocol> and just stores the stuff it's sent in some simple files so
>> that it can return the info when queried.
>>
>> Once you have something that talks the network protocol correctly,
>> modifying it to change the real files, make uci calls, etc for different
>> distros is much easier (just write your daemon with the expectation that
>> the input and output details are going to change, so don't get fancy
>> with them).
>>
>> David Lang
>
> The TR-069 family is currently wildly used by ISPs controlling the (DSL)
> CPE devices of their customers. There are probably more than 100 million
> device controlled by standards from the TR-069 family out there.  When
> you get a DSL router from your ISP or buy one in the retail store it is
> very likely it supports the standards from the TR-069 family, as a
> vendor in this area you basically need support for this to sell your
> devices.
>
> In other technologies you have different protocols to manage your
> devices, like cable often uses something different and EPON and GPON
> even have all their own management standards. Then there are also some
> technology independent standards and so on. It makes sense to build such
> a solution in a way to make it easily to expendable for new protocols.
>
> Hauke
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org