From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 672FD21F20A for ; Sun, 29 Dec 2013 02:52:05 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 34B3E20F20; Sun, 29 Dec 2013 05:52:04 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 29 Dec 2013 05:52:04 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imap.cc; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type; s=mesmtp; bh=SIrRoNpQDey9oj9i9e9iQZjv c/Q=; b=CjH3cg+6o9jKwGzytrNNo5K/CCOu0OebCCKCWLxDgHQZfLA+DO/wuoJ9 vLYY1DilGCzC7hz/YNWFu9PNPQI+E22kXWoYOexEYvuCaRx1PUKDkStMs0BrAE5X CTjzC/GVNOzIDwMJ7P7gIhppTLydUdRg6Fa8OxjVQyYHBVdm9Gk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type; s=smtpout; bh=SIrR oNpQDey9oj9i9e9iQZjvc/Q=; b=B9xWEEzE8eMBQoEXby/tEdkmyhTBdI0NKbg0 Ht8JiE29lswFZMTfkwS4EOEzh+Kp/6CtB+OLwffR+1qoBtkT+qw3x8/IYN3WovvS RNev7JSa+vgMVDTcbzpZBysGlAG3M9oIdjHKBs3z3/B5AfS67j+z2MTxF3v9IFiv kpBGI+U= X-Sasl-enc: wX78eNkWbNsOlyYyZlVCcQklQax2lKeIHN+Cd2IsCOzx 1388314323 Received: from [172.30.42.8] (unknown [78.147.119.216]) by mail.messagingengine.com (Postfix) with ESMTPA id 3878E680143; Sun, 29 Dec 2013 05:52:03 -0500 (EST) Message-ID: <52BFFED2.4000602@imap.cc> Date: Sun, 29 Dec 2013 10:52:02 +0000 From: Fred Stratton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Dave Taht , cerowrt-devel@lists.bufferbloat.net References: <3AE6C690-F53C-471F-9980-9E071B87D983@gmail.com> <41ec2fd6-4fb8-4e17-8458-861e27c2c5ff@email.android.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010207090101050705060702" 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 10:52:06 -0000 This is a multi-part message in MIME format. --------------010207090101050705060702 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Providers differ across countries. European competition laws are interpreted quite differently in different countries. AFAIK, Deutsche Telekom and France Telecom are monopolies. ISPs there therefore use the same infrastructure. BT is not. Here there are differences between ISPs. http://www.samknows.com/broadband/exchange/MRPOY Shows service availability in the area where I am, immediately to the south of the Manchester conurbation. Recommendations are also affected by service cost. In this country, BT increases its prices once or even twice a year by just below the ten per cent threshold where the regulator takes an interest. Sky and TalkTalk then follow. Individuals then have to make decisions based not just on shaping policy, the type of CPE supplied, and TV channels specific to the provider, but on cost. Negotiation on cost involves a yearly conversation with the provider, and cashback offers available elsewhere. Recommendations are therefore problematic. On 29/12/13 08:54, Dave Taht wrote: > I would like it if we had a couple per-provider recomendations and > relevant discussion. > > 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? >> 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. >> >>> 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. >> And the annoying size dependent padding of the last ATM cell. >> >>> How does CeroWrt use this time calculation? Does it simply make sure >>> that the target time doesn’t get too low for a particular flow’s queue? >> 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. >> >> I hope this helps >> Sebastian >> >>> (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 >> 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 > > --------------010207090101050705060702 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Providers differ across countries.

European competition laws are interpreted quite differently in different countries. AFAIK, Deutsche Telekom and France Telecom are monopolies. ISPs there therefore use the same infrastructure. BT is not. Here there are differences between ISPs.

http://www.samknows.com/broadband/exchange/MRPOY

Shows service availability in the area where I am, immediately to the south of the Manchester conurbation.

Recommendations are also affected by service cost. In this country, BT increases its prices once or even twice a year by just below the ten per cent threshold where the regulator takes an interest. Sky and TalkTalk then follow. Individuals then have to make decisions based not just on shaping policy, the type of CPE supplied, and TV channels specific to the provider, but on cost.

Negotiation on cost involves a yearly conversation with the provider, and cashback offers available elsewhere. Recommendations are therefore problematic.



On 29/12/13 08:54, Dave Taht wrote:
I would like it if we had a couple per-provider recomendations and
relevant discussion.

On Sat, Dec 28, 2013 at 11:36 PM, Sebastian Moeller <moeller0@gmx.de> wrote:

Rich Brown <richb.hanover@gmail.com> wrote:

QUESTION #2: How does CeroWrt use info gleaned from the link layer
adaptation?

      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.


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.

       And the annoying size dependent padding of the last ATM cell.


How does CeroWrt use this time calculation? Does it simply make sure
that the target time doesn’t get too low for a particular flow’s queue?

        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.

I hope this helps
        Sebastian


(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

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

--------------010207090101050705060702--