Hi Richard,
> On Jan 19, 2016, at 02:06 , Michael Richardson <m...@sandelman.ca> wrote:
>
>
> Jonathan Morton <chromati...@gmail.com> wrote:
>>> Jonathan Morton <chromati...@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 [
> ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails
> [
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
