From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 266113CBA1; Fri, 22 Jan 2016 02:23:28 -0500 (EST) Received: from hms-beagle.home.lan ([217.247.221.45]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MB1C4-1aEr5L2Pv2-009wem; Fri, 22 Jan 2016 08:23:23 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <31692.1453165586@obiwan.sandelman.ca> Date: Fri, 22 Jan 2016 08:23:21 +0100 Cc: Jonathan Morton , make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6737994D-CE0B-46F5-B55C-A584FF6A8014@gmail.com> <23342.1453133686@dooku.sandelman.ca> <6ACF3DA5-AEA7-43DD-A3BA-33F680374F09@gmail.com> <31692.1453165586@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:HvQ6/mA7VJDOSsyqR7qwVN/ixIBmQc8wMx+hIJ6SPVYhxCITgNy Ax4KU3idlVAk+7lg/qVwjkVl7PFc0/Mxhp0eNyUd06i6aUTs8mOApA7EkO14Ad2wxOxKivz 4HUNTgxI/PZJrRQW6bJaItZB3v3pgxpmPVkdrQSb5AD94vYdCAP+Gz/FDigbFOqsc1L3zp1 N04oKa+EZsTfFXLxBTE0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:xJBcFEo3meE=:qTQi3GWnwF1dyoExEKS1MI kkIKmbw27XmtQx7wpdNZFPSXHEhdH0bMC7aCvQMPDF9dLVIPBixUCU8KgBvAgT3kTGNDYf/u6 tPo8xLpfA12I2e2BijTuMUQ6+m5s14jnp2hOBpPwkuXVSrrz++TR006mfXJoTtjrg08U6RII9 Sy0Ja7BrV76cDm2CYBtDYADL7a1OwdnlDFr9xHy8EYzsIU+8b2bpQw4SReMcsSiwrYtTH8C61 B1cedAe8XQTvzcwWTIY+I/MDWKcSBHr4vH7Sn993h5cOxRxpmbNva3Jb2OzWQm6YHi4MwfFY5 24ZmkLYoKiDOWCstXJMuvPiSCEvLCC3bwlKRpBUa605DKqFZTyjQinGfxd0tBZD+KacnAzXeE 3cuRBYZ/fTtG3UtitUsIuZIhv8buNtGdnNxXXwJiIPvOXBYbZ2PzPBXanEqgucu5WZB1GWgkz ZRdwKomca5NbA2u9ZyWHau9afo+XlLXiuMES3ryVAh3d4GAGGT/wKf92jMoVNiuqoT/RfS6r0 +ePomAbshn/FgVGFrw6EomRm3gNOE832sPuJPHLc94HNGAwU+Qr5efhbLs8EIZg/5KQBMU7Sb PDn75ouIjxUqgARLmdZL6CYKPjAqWucgBsBkDilNXYTuZ4FTUPyqRWsp3CX22oOi3OGlVwEqV cJ8pvJW7NNiRgR/ORf70zoc8P1yvHmmkQ5ErYA/jFt3fRv8eISsWrk13iu4j7RVcJuUR3X83H rHzHlL0n1KGIar446flYYKD6bF/trFp+wRsd2yFtTOGKzFHe6RHhKViL6vR9w4pjexu1avz21 pT9E2WU Subject: Re: [Cerowrt-devel] routers you can throw off the back of a truck X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 07:23:29 -0000 Hi Richard, > On Jan 19, 2016, at 02:06 , Michael Richardson = wrote: >=20 >=20 > Jonathan Morton wrote: >>> Jonathan Morton wrote: >>>> I haven=E2=80=99t yet found a robust way to automatically sense = link capacity from >>>> the upstream side. You=E2=80=99ll therefore need to set a = conservative static >>>> value for the uplink capacity. >>>=20 >>> As the maintainer of a PPPoE concentrator, and operator of some = networks, >>> I've been considering whether one can estimate the bandwidth using = round >>> trip PPP IPCP keep alives. Clearly, if both ends participate in = time >>> stamping then it is much better, but I've been wondering if we can = do some >>> incremental deployment on one side or the other. >>>=20 >>> Sadly, I mostly just think about this while cycling; I haven't = written any >>> code yet. >=20 >> In most PPPoE deployments I know about, there is also a modem from >> which the actual, precise link rates can usually be queried. Where >> that=E2=80=99s not the case, IPCP (or is it LPCP?) probes would be a = reasonable >> workaround, but it must still be understood that the signal it = provides >> is only valid under saturating traffic, which complicates >> implementation. >=20 > Yes, you are rtight, I want to do LPCP echo requests. It is a pity, that these do not carry a (high-resolution) time = stamp per default. It would be sweet if at least the bidirectional RTT = of each of the periodic keep-alive probes would be accessible, say = somewhere under /sys=E2=80=A6 Then userspace would have an easy method = to get information about the most relevant set of links. >=20 > The modem might know what speed it has with the tower/DSLAM, but won't = know how > congested the backhaul link is. =20 Then there is the issue of lack of standardized link speed = reporting, which probably gets worse if we start looking at different = link technologies (xDSL, LTE, dial-up, ...) > There are some third party/white label 3G > arrangements in Canada that use PPP/L2TP back to the third-party = provider, > but most route the IPv4 (only) packets via IPsec or MPLS. Then again the further away the bottleneck actually is the less = effective our artificial bottleneck is going to be. (It is for example = not guaranteed that pur traffic actually gets any bandwidth guarantee so = reducing the bandwidth might simply ceed more bandwidth to other users = without improving the latency under load, as on those links we do not = compete with ourselves only, but I digress) Best Regards Sebastian >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | network = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel