From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5435F21F18C for ; Sun, 29 Dec 2013 05:51:23 -0800 (PST) Received: from [192.168.2.43] ([79.202.32.60]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lwnem-1VM3GK0joe-016QjR for ; Sun, 29 Dec 2013 14:51:20 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 29 Dec 2013 14:51:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <22A1BB53-E417-4EDC-8633-04B4874DE835@gmx.de> References: <3AE6C690-F53C-471F-9980-9E071B87D983@gmail.com> <41ec2fd6-4fb8-4e17-8458-861e27c2c5ff@email.android.com> To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:Ly0XAYng8b0atYASGV0SqCST+SZGQq2vn7UQk4teosy0KbimS/Q nacJD6Quv8dDuZUAWy0w0+7xygbunwxeJE3/MRXNrbWv3TuQC0XZ8AGauUlOvtFb0X9vcIu iNlVhwtn/pnBMexGmmQ9z2ajRBa/XNDp/6PDnJQPxDk5l+OwdH+DuBrcUQeSJvhKjKRmsVs Zt0PIJYw9oVQMQWLKIAcg== Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] SQM Question #2: How does CeroWrt use info gleaned from the link layer adaptation? 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: Sun, 29 Dec 2013 13:51:23 -0000 Hi Dave, On Dec 29, 2013, at 09:54 , Dave Taht wrote: > I would like it if we had a couple per-provider recomendations and > relevant discussion. I think this is a can of worms we should open carefully ;). In = Germany several providers serve part of their area with their own = infrastructure while reselling bitstream access provided by other = carriers in other parts of their area, with potential differences in = encapsulation. Also in the US at&t is in the process of relabeling their = ADSL2 access as U-Verse High Speed Internet (the same label they use for = VDSL as well) making it quite complicated to give proper = recommendations=85 But to make a start here are only connections I = actually measured (there is no guarantee that all connections of the = same ISP use the same technology): Date Country ISP = nominal Speed D/U line type link layer = access type overhead = comment 2013-12-29 Germany Deutsche Telekom 16Mbit/s = 2.8Mbit/s ADSL2+ ATM PPPoE, LLC/SNAP RFC-2684 = 40bytes 16M down also offered as VDSL version without = ATM 2013-12-29 Germany Deutsche Telekom 2Mbit/s = 0.2Mbit/s ADSL1 ATM PPPoE, LLC/SNAP = RFC-2684 40bytes connections below 16M down are = always ADSL, either v1 or v2+ 2013-12-29 Germany Netaachen = 18Mbit/s 1.0Mbit/s ADSL2+ ATM PPPoE, LLC/SNAP = RFC-2684 40bytes =09 General Notes:=20 Deutsche Telekom; the network is slowly moved to fiber to the node/curb = using VDSL2 (PTM) for speeds >=3D 16M down and ADSL2+ (ATM) for slower = speeds . These new DSLAMs replacements are called MSANs, customers on=20 ADSL ports are still using ATM on the last mile and need the link layer = adjustments. Best Regards Sebastian >=20 > On Sat, Dec 28, 2013 at 11:36 PM, Sebastian Moeller = wrote: >> Rich Brown wrote: >>> QUESTION #2: How does CeroWrt use info gleaned from the link layer >>> adaptation? >>=20 >> The link layer adaptations work in correcting the kernels = estimate of a packets behavior on the wire. In the tc_stab case the = kernel calculates the effective size of the packet on the wire, that is = it pretends the packet is larger than it really is, so for a given = bandwidth it estimates the correct time it takes for that packet to be = actually transmitted. In the htb_private case the kernel keeps the = packet's size (more or less) intact but adjusts its estimate of the = packets transmit rate. Both methods boil down to the same idea, make = sure the packet scheduler will only send packet N+1 after packet N has = just cleared the wire. >>=20 >>>=20 >>> Specifically, the link layer adaptation all seem to be designed to >>> compute the actual time it takes to transmit a packet, accounting = for >>> Ethernet & PPPoE header bytes, other overhead, and ATM 48-in-53 >>> framing. >>=20 >> And the annoying size dependent padding of the last ATM cell. >>=20 >>>=20 >>> How does CeroWrt use this time calculation? Does it simply make sure >>> that the target time doesn=92t get too low for a particular flow=92s = queue? >>=20 >> Thanks to the link layer adjustments (lla) cero now estimates = the correct time each packet takes and will not send any faster than the = shaped rate allows. If no lla is performed cero would overestimate the = link capacity, send more than expected and potentially fill the modems = bloated buffers. Traditionally people tried to reduce their shaped rate = by >10% to at least account for the 48 in 53 framing, but failed = miserably for small packets since overhead and padding can more than = double the wire size of a packet. Note that ACQ packets typically are = small as are voice over IP packets. >>=20 >> I hope this helps >> Sebastian >>=20 >>> (I could imagine that a short packet over ATM would take 2x the = (naive) >>> expected/calculated time for a packet of that length, and that flow >>> would be penalized. Is there more to it?) >>> _______________________________________________ >>> Cerowrt-devel mailing list >>> Cerowrt-devel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>=20 >> Hi Rich >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html