[Make-wifi-fast] [Cerowrt-devel] routers you can throw off the back of a truck

[moeller0]

Hi Richard,

> On Jan 19, 2016, at 02:06 , Michael Richardson <mcr at sandelman.ca> wrote:
> 
> 
> Jonathan Morton <chromatix99 at gmail.com> wrote:
>>> Jonathan Morton <chromatix99 at gmail.com> wrote:
>>>> I haven’t yet found a robust way to automatically sense link capacity from
>>>> the upstream side.  You’ll therefore need to set a conservative static
>>>> value for the uplink capacity.
>>> 
>>> 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.
>>> 
>>> Sadly, I mostly just think about this while cycling; I haven't written any
>>> code yet.
> 
>> 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’s 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.
> 
> 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… Then userspace would have an easy method to get information about the most relevant set of links.

> 
> The modem might know what speed it has with the tower/DSLAM, but won't know how
> congested the backhaul link is.  

	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

> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel