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

Wed Jun 1 10:33:43 PDT 2016

On Sat, May 28, 2016 at 7:05 AM, John Crispin <john at phrozen.org> wrote:
>
>
> On 28/05/2016 16:02, Hauke Mehrtens wrote:
>> On 05/28/2016 03:36 PM, Dave Taht wrote:
>>> 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?

My original question here remains unanswered. Being thus far unable to
convince a single DSL firmware maker that they've been screwing up,
despite proving how to do it right (free.fr 4+ years back), showing
the problem in innumerable public tests and papers, describing how
easy it would be to fix (given source code and a few six-packs of beer
with a dev that grokked the blob), getting the cable industry to
recognise and fix the bufferbloat problem in DOCSIS 3.1 - and even
going so far as talking to the top people in the FCC as to how simply
and cheaply they could help make the internet better for everyone,
particularly on DSL... has been quite frustrating.

It would be *so* straightforward to fix the dsl binary firmware to add
in BQL-like techniques and then manage it dynamically on top with
fq_codel.

doing it with a software rate limiter (htb+fq_codel) instead is
fraught with problems in getting the framing right - which, of course,
an ISP (as opposed to a typical user) *could* easily get right with a
clean interface between tr-069 and sqm-scripts and/or cake. (And is
probably still necessary to do on inbound traffic in a world that has
not seen much improvement in dslam/bras technology.)

Asking users to get the framing right for software shaping on dsl or
ppoe has been a PITA.

>>> 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. (?)
>>>
>>
>> The Lantiq / Intel DSL drivers are open source and integrated in
>> OpenWrt, but I haven't checked if BQL is implemented there. They are
>> also using a big firmware which does all the PHY related stuff.
>>
>> You can get some statistics from the device like this. These information
>> are from the DSL PHY layer, so it does not show when your ISP would
>> limit your rate somewhere else in the internal network, but these
>> information are available on all DSL lines.
>
>
> there is no BQL and there is a 256 packet buffer in the driver.

sigh. Even if BQL was there, the firmware has...

> if i am not mistaken, there is a secondary 64 packet ring handled by the
> firmware blob.

bytes, not packets, is easier to manage, and two full size packets
(3k) is more than enough at nearly any DSL rate to get sane network
performance and latency. So the default blob has 62 packets too many
in it for full size packets, and were they acks only (66 bytes each),
I'd bet that 10 in the firmware blob would more than suffice for
upload speeds up to 10Mbits on most hardware.

but the right answer is to count bytes, not packets, in the firmware.

>         John
>
>>
>> root at lede:~# /etc/init.d/dsl_control status
>> ATU-C Vendor ID:                          Broadcom 176.15
>> ATU-C System Vendor ID:                   Broadcom
>> Chipset:                                  Lantiq-VRX200 Unknown
>> Firmware Version:                         5.7.3.3.0.6
>> API Version:                              4.16.6.3
>> XTSE Capabilities:                        0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> 0x0, 0x2
>> Annex:                                    B
>> Line Mode:                                G.993.2 (VDSL2)
>> Profile:                                  17a
>> Line State:                               UP [0x801: showtime_tc_sync]
>> Forward Error Correction Seconds (FECS):  Near: 0 / Far: 2116802
>> Errored seconds (ES):                     Near: 0 / Far: 2938
>> Severely Errored Seconds (SES):           Near: 0 / Far: 50
>> Loss of Signal Seconds (LOSS):            Near: 0 / Far: 0
>> Unavailable Seconds (UAS):                Near: 31 / Far: 31
>> Header Error Code Errors (HEC):           Near: 0 / Far: 0
>> Non Pre-emtive CRC errors (CRC_P):        Near: 0 / Far: 0
>> Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
>> Power Management Mode:                    L0 - Synchronized
>> Latency / Interleave Delay:               Down: Interleave (8.0 ms) /
>> Up: Interleave (4.0 ms)
>> Data Rate:                                Down: 51.391 Mb/s / Up: 10.046
>> Mb/s
>> Line Attenuation (LATN):                  Down: 10.6dB / Up: 10.6dB
>> Signal Attenuation (SATN):                Down: 10.6dB / Up: 10.2dB
>> Noise Margin (SNR):                       Down: 7.7dB / Up: 13.9dB
>> Aggregate Transmit Power (ACTATP):        Down: -11.6dB / Up: 12.5dB
>> Max. Attainable Data Rate (ATTNDR):       Down: 61.928 Mb/s / Up: 23.355
>> Mb/s
>> Line Uptime Seconds:                      62
>> Line Uptime:                              1m 2s
>> root at lede:~#
>>
>> 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