From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7BA0121F735 for ; Fri, 1 Aug 2014 11:29:00 -0700 (PDT) Received: from hms-beagle.home.lan ([217.231.210.84]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LmNHK-1WdOrD3AQc-00ZuOS; Fri, 01 Aug 2014 20:28:57 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <11000.1406866900@sandelman.ca> Date: Fri, 1 Aug 2014 20:28:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <70BB6CDF-5A8C-4F44-A308-8681536BB085@gmx.de> References: <13144.1406313454@turing-police.cc.vt.edu> <36889fad276c5cdd1cd083d1c83f2265@lang.hm> <2483CF77-EE7D-4D76-ACC8-5CBC75D093A7@gmx.de> <11000.1406866900@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:dngoQTDpQhqUNtaW9pNDIVnhXtf7Qaca5yGKB7nYUbsDlamHPjX fOX3TRDWWiSgAjSEAu1LuOzxmhPfBQKTsUIxHjN+YlcLdsSTH3DNiXxCsDMGpk5NUjAqfRt mq+UbI9GABDEeuh2p5PCNOM/yrUdz94co28l0oBegKHNjUijw4WB6hd/VJs4WVbAVTI1IxU EKxJtNtIRJlSBBG0ymOog== Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration. X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 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, 01 Aug 2014 18:29:01 -0000 HI Michael, On Aug 1, 2014, at 06:21 , Michael Richardson wrote: >=20 > 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. Sure. >=20 > 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. >=20 > 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... > =20 >=20 > But, if there something wrong with my notion? >=20 > My other notion is that the LCP packets could be time stamped by the = PPP(oE) > gateway, and this would solve the asymmetry. =20 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 =93grown ups=94 can be made to act wouldn=92t 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) Best Regards Sebastian >=20 > --=20 > Michael Richardson > -on the road- >=20 >=20 >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel