From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 A85B821F1B9 for ; Sat, 28 Dec 2013 23:57:45 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so10820429wib.12 for ; Sat, 28 Dec 2013 23:57:43 -0800 (PST) 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=nh5V0OXLkq1Z7J3mzr9j4n+ITXBjgPxNN53sibGo6xk=; b=mWvD2QPli5i50/g079LZ2HiF54wkBD6pLrQWTTiGkbG+aDIdFu0K1K8QylizBocs+o HXfqPvNHAUVkwVpLnCMXtzLb+bAchHzQhudp3US2g643Ke2enHFXprDl/1Z7ASzkwgBw ob+CJs2kIIqqVAJZLAtbveZSsBeFF4Qx0JDbZndHdKRFvr8bduGEXpxvdHHiNR3NZxik JTNIk33vYkbAO/2z+jWgiPXEWBfIrK3/CwPYV5qXF+tiRk0asGaqbjeCGPFSXq3A4Gf/ HaaxNA+fOSr7M+isZptxfL4sCeKT4LyFqZZjZNfenapozMCGbzXABYPIRW4aQd04EFwd oDEw== MIME-Version: 1.0 X-Received: by 10.180.37.69 with SMTP id w5mr39655950wij.53.1388303863341; Sat, 28 Dec 2013 23:57:43 -0800 (PST) Received: by 10.217.123.69 with HTTP; Sat, 28 Dec 2013 23:57:43 -0800 (PST) In-Reply-To: <2dda55ee-b40e-45c3-b973-2494f90ca182@email.android.com> References: <2dda55ee-b40e-45c3-b973-2494f90ca182@email.android.com> Date: Sat, 28 Dec 2013 23:57:43 -0800 Message-ID: From: Dave Taht To: Sebastian Moeller Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] SQM Question #1: How does SQM shape the ingress? 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 07:57:46 -0000 This is one of the harder questions for even experts to grasp: that ingress shaping is indeed possible, and can be made to work well in most circumstances. Mentally I view it as several funnels. You have a big funnel at the ISP, and create a smaller one on your device. It is still possible for the big funnel at the ISP to fill up, but if your funnel is smaller, you will fill that one up sooner, and provide signalling back to make sure the bigger funnel at the ISP doesn't fill up overmuch, or over-often. (It WILL fill up at the ISP at least temporarily fairly often - a common buffer size on dslams is like 64k and it doesn't take many iw10 flows to force a dropping scenario) Note: I kind of missed the conversation about aiming for 85% limits, etc. It's in my inbox awaiting time to read it. On egress, in cero, you have total control of the queue AND memory for buffering and can aim for nearly 100% of the rated bandwidth on the shaper. You have some trouble at higher rates with scheduling granularity (the htb quantum). On ingress, you are battling your ISP's device (memory, workload, your line rate, queuing, media acquisition, line errors) for an optimum, it's sometimes several ms away (depending on technology), and the interactions between these variables are difficult to model, so going for 85% as a start seems to be a good idea. I can get cable up to about 92% at 24mbit. I have trouble recommending a formula for any other technology. In fact ingress shaping is going to get harder and harder as all the newer, "faster" technologies have wildly variable rates, and the signalling loop is basically broken between the dumb device (with all the knowledge about the connection) and the smarter router (connected via 1gig ethernet usually) My take on it now (as well as then) is we need to fix the cmts's and dslams (and wireless, wifi, gpon, etc). DOCSIS 3.1 mandates pie and makes other AQM and packet scheduling technologies possible. The CMTSes are worse than the devices in many cases, but I think the cmts's are on their way to being fixed - but the operators need to be configuring them properly. I had had hope the erouters could be fixed sooner than docsis 3.1 will ship... One interesting note about dslams I learned recently (also from free who have been most helpful) is that most DSL based triple play services uses a VC (virtual circuit) for TV and thus a simpleminded application of htb on ingress won't work in their environment. (I think it might be possible to build a smarter htb that could monitor the packets it got into it's direct queue and subtract that bandwidth from it's headline queues, but haven't got back to them on that). Also gargoyle's ACC-like approach might work if better filtered. (from looking at the code last year I figured it wouldn't correctly detect inbound problems on cable in particular, but I think I have a filter for that now) I would really like to get away from requiring a measurement from the user and am willing to borrow ideas from anyone. http://gargoylerouter.com/phpbb/viewtopic.php?f=3D5&t=3D2793&start=3D10 Incidentally I liked gargoyle when I tried it. Those of you that have secondary routers here might want to give it a go. (They did sfqred briefly then went back to sfq + acc) In reading what I just wrote I'm not sure how to make any of this clear to mom. "Scheduling granularity"? I like what sebastian wrote below, but I think a picture or animation would make it clearer. On Sat, Dec 28, 2013 at 11:23 PM, Sebastian Moeller wrote= : > Rich Brown wrote: >>As I write the SQM page, I find I have questions that I can=92t answer >>myself. I=92m going to post these questions separately because they=92ll >>each generate their own threads of conversation. >> >>QUESTION #1: How does SQM shape the ingress? >> >>I know that fq_codel can shape the egress traffic by discarding traffic >>for an individual flow that has dwelt in its queue for too long >>(greater than the target). Other queue disciplines use other metrics >>for shaping the outbound traffic. >> >>But how does CeroWrt shape the inbound traffic? (I have a sense that >>the simple.qos and simplest.qos scripts are involved, but I=92m not sure >>of anything beyond that.) > > So ingress shaping conceptually works just as egress shaping. The= shaper accepts packets at any speed from both directions but limits the sp= eed used for transmitting them. So if your ingress natural bandwidth would = be 100Mbit/s you would set the shaper to say 95Mbit/s, so the shaper will c= reate an internal artificial bottleneck just in front of its queue, so that= it can control the critical queue. > Technically, this works by creating an artificial intermediate fu= nctional block device? (IFB), moving all ingress traffic to this device and= setting up classification and shaping on that device. > > I hope this helps... > > Sebastian >> >> >>_______________________________________________ >>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 --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html