[Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration.
moeller0 at gmx.de
Fri Aug 1 14:28:56 EDT 2014
On Aug 1, 2014, at 06:21 , Michael Richardson <mcr at sandelman.ca> wrote:
> On symmetric links, particularly PPP ones, one can use the LCP layer to do
> echo requests to the first layer-3 device. This can be used to measure RTT
> and through some math, the bandwidth.
> On assymetric links, my instinct is that if you can measure the downlink
> speed through another mechanism, that one might be able to subtract, but I
> can't think exactly how right now.
> I'm thinking that one can observe the downlink speed by observing packet
> arrival times/sizes for awhile --- the calculation might be too low if the
> sender is congested otherwise, but the average should go up slowly.
If you go this rout, I would rather look at the minimum delay between incoming packets as a function of the size of the second packet.
> At first, this means that subtracting the downlink bandwidth from the uplink
> bandwidth will, I think, result in too high an uplink speed, which will
> result in rate limiting to a too high value, which is bad.
But given all the uncertainties right now finding the proper shaping bandwidths is an iterative process anyway, but one that is best started with a decent initial guess. My thinking is that with binary search I would want to definitely see decent latency under load after the first reduction...
> But, if there something wrong with my notion?
> My other notion is that the LCP packets could be time stamped by the PPP(oE)
> gateway, and this would solve the asymmetry.
If both devices are time synchronized to a close enough delta that would be great. Initial testing with icmp timestamp request makes me doubt the quality of synchronization (at least right now).
> This would take an IETF action
> to make standard and a decade to get deployed, but it might be a clearly
> measureable marketing win for ISPs.
But if the “grown ups” can be made to act wouldn’t we rather see nice end-user query-able SNMP information about the current up and downlink rates (and in what protocol level, e.g. 2400Mbps down, 1103Kbps up ATM carrier) (For all I know the DSLAMs/BRASes might already support this)
> Michael Richardson
> -on the road-
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
More information about the Cerowrt-devel