From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 8D89B21F5A4; Fri, 12 Dec 2014 07:52:29 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id vb8so8685650obc.0 for ; Fri, 12 Dec 2014 07:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=pbo9bEMHLYsfq37CtGn2uGybV/h+HFIo2PToKNQpGdQ=; b=S8mN5Cn6Tjz7tFVcb9Edq7p4oY1yOXCxYKM2tSuCwXBD8AflP3L1HJzUQixoHeCBIg MUMtOzu4I43Het0mmH8Vf0HiaPs9BrVQHZlbtYWSKvsvIWDZWJcRDOnY/stKUN5TRWZB u/GtEiWYLnbsvudPlRFviem1TbYNVP4bjHOc/qYMcmwF8rsxmtAUD1WthOxLl2aYtNsl PwcNgqERH7IHFzTQdd960GQOv9dbyKkbjBW7A/E5Exq5G0CpBqKzEipKpTllBoNuC0Cj Fd2ofbMu7Fca2PT7yZfi4ECLXWj8XCIEjaG5XomvzxLxciElLAJqFU3n680ADGN/pcDD RBaA== MIME-Version: 1.0 X-Received: by 10.182.101.169 with SMTP id fh9mr6557425obb.0.1418399548486; Fri, 12 Dec 2014 07:52:28 -0800 (PST) Received: by 10.202.227.77 with HTTP; Fri, 12 Dec 2014 07:52:28 -0800 (PST) Date: Fri, 12 Dec 2014 07:52:28 -0800 Message-ID: From: Dave Taht To: "cerowrt-devel@lists.bufferbloat.net" , bloat-devel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cerowrt-devel] cake: changing bandwidth on the rate limiter dynamically 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, 12 Dec 2014 15:52:57 -0000 One of the nice things that the gargoyle-qos system does is that it attempts to measure the bandwidth actively and modify the actual bandwidth in the rate limiter to suit. It does this with some very hairy code into the htb/hfsc subsystem, and measuring ping to either a server elsewhere or short ttl udp + icmp returns.... (can't remember which) dealing with the measurements correctly when traffic is possibly bottlenecking in both directions I think it fails on. As does streamboost. Now, it turns out that cake makes altering the bandwidth really easy, you can just change it from the command line. http://pastebin.com/Jr9s6EBW I am pretty sure changing it is currently pretty damaging to stuff in flight (don't remember), but it needent be. I think dynamically sensing the underlying bandwidth would be a great boon, rather than having to set it so explicitly, and perhaps by sensing some other parameters like ack clocks or overall traffic flow at a depth that bpf could resolve, might be a valid approach. --=20 Dave T=C3=A4ht http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks