From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 75FF021F231 for ; Sat, 19 Apr 2014 11:57:50 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so597096wib.11 for ; Sat, 19 Apr 2014 11:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=J/W0YJI2oSVNKb0LtjJpvX8Brozws5vtoc2yXQVf2dc=; b=qJkbAteDzJENjRusrVKBd2lHjEiVhP1kEaNHcNV+iWTxzz0K2iRP2VVnvyf4JQFPm8 Bv0jtvTtNy5xYL2ubv3azXMg6ed4cklAei0pL5mCc5miM08ff9BPJCmdKu4Jn9NGdfAr JaSNmosfiJluoT7y1DM3kPkvU5Mnlrz1c7tY5A01YZKskJjbXFOhOjv8ktQpJc1cNaSd pk8nRzUTIZ7ZcxuIwHRvNjRsWWxk+tuih1UoVhcLFd/VFaRouyMyMgtvlJB0lxtQPd2b Ud+KHdn0YZ1K/PL3ScBxSCgHnovrqsxalAzmZohF+3KFDgdHYIOCwYMqr03SN7Rd5Uvq xw8Q== MIME-Version: 1.0 X-Received: by 10.180.76.166 with SMTP id l6mr7545778wiw.17.1397933868725; Sat, 19 Apr 2014 11:57:48 -0700 (PDT) Received: by 10.216.177.10 with HTTP; Sat, 19 Apr 2014 11:57:48 -0700 (PDT) In-Reply-To: References: <1397924468.489728228@apps.rackspace.com> <1397931395.018720381@apps.rackspace.com> Date: Sat, 19 Apr 2014 11:57:48 -0700 Message-ID: From: Dave Taht To: David Reed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] comcast provisioned rates? 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: Sat, 19 Apr 2014 18:57:51 -0000 On Sat, Apr 19, 2014 at 11:40 AM, Dave Taht wrote: > On Sat, Apr 19, 2014 at 11:16 AM, wrote: >> Very good. So the idea, rather than Comcast implementing codel or >> something proper in the DOCSIS 3.0 systems they have in the field, is to >> emulate power boost to "impedance match" the add-on router-based codel >> approach to some kind of knowledge of what the DOCSIS CMTS buffering sta= te >> looks like.... > > http://tools.ietf.org/html/draft-white-aqm-docsis-pie-00 > > is mandated in DOCSIS 3.1 modems. > > The ECO has gone out for DOCSIS 3.0 as well. > > Pie is tightly intertwined with the powerboost capable scheduler. > > The powerboost feature is viewed Oops, hit send too early. The powerboost feature is viewed as a way to reward those that use bandwidth sporadically, such as with website downloads (it's typical duration is more than a website). The cable is a shared medium, and it makes some sense to allow for a bigger burst to someone that isn't otherwise using up that cable as much as someone else. The feature arose in a world of much less bandwidth on the modem by default, and far less users behind a cable modem by default. Yes, in my world, and the upcoming one, I want consistent, predicable, jitter free, bandwidth as it simplifies queue management and makes more possible less hacks on the appliction side to deal with spikes, and so on... but everybody here is living in the future, a bit more than other makers can react. We use more interactive applications, in particular, and some of us have hopes that one day we don't have to co-locate critical servers in the data center anymore. So far as I know powerboost is not enabled on multiple portions of multiple ISPs networks. It wasn't "on" on several places in the west coast when last I checked, anyway. >> And of course nothing can be done about "downstream" bufferbloat in the >> Comcast DOCSIS deployment. > > I have seen promising noises from Arris at least, on the CMTS side, and > had posted some of their thinking from the last meeting of the society > of cable engineers on one of our mailing lists fairly recently, which > induced no comment. > > http://www.ietf.org/mail-archive/web/aqm/current/msg00538.html > > They had come up with a variant of red, called "LRED", and a nifty enhanc= ement > to SFQ, but hadn't got as far as grokking that queue length and packet > scheduling > together were a better answer. > > I would certainly like the overall level of overbuffering in CMTSes to be > reduced which is something the cable providers could do today, and that > certainly bugs me. > >> >> So instead of fixing Comcast's stuff "correctly", we end up with a liter= al >> "half measure". > > The cable ISP industry as a whole is slave to their equipment makers. > cablelabs only has dominion over the cable modem side. > > What the world needs is better long distance media types not designed > by former telecoms, and designed for packet data. > > If you thought cable was complex and had bad ideas > in it, see gpon, also. Or moca, or various powerline standards. > > What my hope has been has been that the increasingly common > hybrid cable modem/wireless gateways would gain fq_codel support and mana= ge > both the up and downstreams themselves, thus bypassing the > slow to update million dollar head end portion of the industry > entirely. > > I'd like something as powerful and as loved as the revolution V6 box > to appear. > > I'm not holding my breath. > > Apple could do it right. > >> Who does Comcast buy its CMTS gear from, and if it has a Heartbleed bug, >> maybe some benevolent hacker should just fix it for them? > > There are only 3 makers of CMTS gear - cisco, arris, and a third company > from china whose name I forget. > >> >> >> It's now been 2 years since Comcast said they were deploying a fix. Was >> that just them hoping the critics would dissipate their time and effort? > > Competition is needed. I'm rooting for gfiber to provide some. > >> And is Comcast still using its Sandvine DPI gear? > > No idea. I certainly see an aweful lot of packets remarked CS1. > >> >> >> >> I'm afraid that monopolists really don't care. Even friendly-sounding o= nes. >> Especially when they can use their technical non-deployments to get paid >> more by Netflix. > > Well, grump, I am fair minded. Netflix's business model has always been > to colocate their servers within the ISP itself with things like the > open-connect > appliance. > > http://www.networkworld.com/community/blog/netflix-goes-edge-internet > > It makes a rediculous amount of sense to do so, and is a cost savings > to both ISP and netflix on external bandwidth, but somebody still has to > cover the rack space, hardware, and electricity no matter where located. > > > >> >> >> >> On Saturday, April 19, 2014 1:57pm, "Dave Taht" sa= id: >> >>> The features of the PowerBoost feature are well documented at this >>> point. A proper >>> emulation of them is in the ns2 code. It has been a persistent feature >>> request, to >>> add support to some Linux rate shaper to properly emulate PowerBoost, >>> but no funding >>> ever arrived. >>> >>> Basically you get 10 extra megabytes above the base rate at whatever >>> rate the line >>> can sustain before it settles back to the base rate. >>> >>> You can also see that as presently implemented, at least on a short >>> RTT path, the feature >>> does not prevent bufferbloat. >>> >>> http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html >>> >>> I'd like a faster, less cpu intense rate shaper than sch_htb in >>> general, and powerboost emulation would be nice. >>> >>> >>> On Sat, Apr 19, 2014 at 9:38 AM, Aaron Wood wrote: >>> > Based on these results: >>> > >>> > http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html >>> > >>> > And talking off-list with Jim, I think that the "PowerBoost" is above >>> > the >>> > quoted rate, as the 24/4 service hits >36Mbps TCP data rate. I'm >>> definitely >>> > sad that using SQM in the router instead of the modem loses features >>> > like >>> > that. But I'll just be happy to have upload over 1Mbps again. >>> > >>> > I do know that the FCC was cracking down on advertised vs. actual rat= es, >>> > and >>> > started a "measuring broadband in America" project: >>> > >>> > http://www.fcc.gov/measuring-broadband-america >>> > >>> > -Aaron >>> > >>> > >>> > On Sat, Apr 19, 2014 at 6:21 PM, wrote: >>> >> >>> >> As a non-Comcast-customer, I am curious too. I had thought their >>> "boost" >>> >> feature allowed temporary rates *larger* than the quoted "up to" rat= es. >>> >> (but I remember the old TV-diagonal games and disk capacity games, >>> >> where >>> any >>> >> way to get a larger number was used in the advertising, since the FT= C >>> didn't >>> >> have a definition that could be applied). >>> >> >>> >> >>> >> >>> >> I wonder if some enterprising lawyer might bring the necessary consu= mer >>> >> fraud class-action before the FTC to get clear definitions of the >>> numbers? >>> >> It's probably too much to ask for Comcast to go on the record with a >>> precise >>> >> definition. >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> On Saturday, April 19, 2014 8:55am, "Aaron Wood" >>> said: >>> >> >>> >> I'm setting up new service in the US, and I'm currently assuming tha= t >>> all >>> >> of Comcast's rates are "boosted" rates, not the "provisioned" rates. >>> >> So if they quote 50/10Mbps, I assume that's not what will need to be >>> >> set >>> >> in SQM with CeroWRT. >>> >> Does anyone have good info on the "provisioned" rates that go with e= ach >>> of >>> >> the Comcast tiers? >>> >> Basically, I'm trying to get to an apples-to-apples comparison with >>> >> Sonic.net DSL (I'll be close enough to the CO to run in Annex M "upl= oad >>> >> priority" mode and get ~18/2 service). >>> >> Thanks, >>> >> Aaron >>> > >>> > >>> > >>> > _______________________________________________ >>> > Cerowrt-devel mailing list >>> > Cerowrt-devel@lists.bufferbloat.net >>> > https://lists.bufferbloat.net/listinfo/cerowrt-devel >>> > >>> >>> >>> >>> -- >>> Dave T=C3=A4ht >>> >>> NSFW: >>> >>> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_in= decent.article >>> > > > > -- > Dave T=C3=A4ht > > NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_029= 6_indecent.article --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article