From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4608C3B29E for ; Wed, 19 Feb 2020 20:02:24 -0500 (EST) Received: by mail-ot1-x32e.google.com with SMTP id j20so2121636otq.3 for ; Wed, 19 Feb 2020 17:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dY8mEpsBgy+ANgousX8a+7GC8oc98sgErYZpTgHE8e0=; b=RpRlcqQn0UImsPCZulHDFrjEdOeb8mNENDhPtxjZFXQGvLgIFghqRQCOhlX+lRD7JT HN3Sk7OFWbDe9W7ZCukf3nH2F68p62pQs3yEwmFQK4MMslfVmSS+4xE/5Ent8l/C8m0s uujWPod8o9Gxa1ZDeEA4Uo5Mw84pD+SmPuBtigPrxPwPJYnJlct1xGWJ+eQZQC38Upx2 rdvKZxzTPPngVBdApSI04CBTSp1k+9nD5WzUDrv6Rx/aEjXWIjeh+p2S1NLyy7Zcr5kN LCg7dxM9/SyQNiWabVu4g7cv4R4DO4nb+JRGNASQ1/6v+nGctIDoURhTU7/ige2VTD4L ltvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dY8mEpsBgy+ANgousX8a+7GC8oc98sgErYZpTgHE8e0=; b=ANqk+Asmg0Ib0HY1qBhHmmFjlZadLbo0UeSNg91XsXxF6bL0K1MQSXIF9HBPHvPN3p GwfNeD4B7IvMnclPLfFXorP097hv7M58kcM5Nsy+3b9BcFCfbVJ6Qk/00FqaBdzyLEDu tGYe3ERDsXE7F/XdzQRcaoS6HLunzpFkoqXXPCrPcxa7R6+036II3eypn6cIw0Mz5pQI +N0N2icGxpWJ/a9jvgrLKYFHK6r1a1Dpl7ani15MzaAQQ3e7EuwgoX5M2xF5ljmzA2cJ 85vJhNDZwv1DHKTLbq60uLsTZ7JPPqZxJWq+6K4lREsKYnYwaJOWNB6B3q/gIEDBoNSE etEw== X-Gm-Message-State: APjAAAUwAUS184U56LsDvAuswvYY/qmyOTPHIq3SjxXasBfKoQtUb1mW V8yoof68yg7DKjzAO2x3NZ6RuBW4jtyojvTMotb8VT4U X-Google-Smtp-Source: APXvYqx9mJxJ/UJA5oNh7Fr+8KEvRwFQu4Hk/Girg2IxyRBRF/1rRU7Riky5bBCrSDFo1uDi/e9T32SFqJDQbkOz6/I= X-Received: by 2002:a9d:6288:: with SMTP id x8mr21032397otk.2.1582160543272; Wed, 19 Feb 2020 17:02:23 -0800 (PST) MIME-Version: 1.0 References: <19192.1581689899@dooku> In-Reply-To: <19192.1581689899@dooku> From: Daniel Sterling Date: Wed, 19 Feb 2020 20:02:11 -0500 Message-ID: To: Michael Richardson Cc: bloat@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Subject: Re: [Bloat] is extremely consistent low-latency for e.g. xbox possible on SoHo networks w/o manual configuration? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 01:02:24 -0000 Thanks to all for the input! Toke, Jonathan -- you were absolutely right! I sent this email because I -- I thought it inconceivable that "just" setting a single bandwidth tunable could both: * enforce / properly rate limit inbound and outbound traffic * and, simultaneously, *prevent* non-bulk streams from seeing latency. I know, I know. You've been telling everyone who will listen that cake works. I just couldn't wrap my head around that possibly being true -- But boy, I was wrong. cake is as amazing as you say. I got rid of my complex rules and swapped them out for: cake bandwidth 60Mbit besteffort internet nat ethernet Then I monitored my xbox game latency as I streamed videos, etc, to generate bulk traffic. There was no observable latency or jitter, and I did not see any issues during actual game-play either. Once again, I am truly amazed. Thank you to everyone who worked on this impressive tool! Ubuntu 19.10 finally ships with all the pieces in place (kernel, new iproute2 package) -- so cake is now finally usable "out of the box" for the average linux user. I look forward to telling everyone I know to have some cake! :) Thanks, Dan On Fri, Feb 14, 2020 at 9:18 AM Michael Richardson wrote: > > > Daniel Sterling wrote: > > I am looking for input / discussion on how to achieve: > > * on a "regular" SoHo network > > > * first and foremost, to the exclusion of all other goals, consistent > > low-latency for non-bulk streams from particular endpoints; usually > > those streams are easily identified and differentiated from all other > > streams based on UDP/TCP port number, > > > * and assuming the identified and prioritized streams behave > > themselves and stay non-bulk, decent throughput for all other traffic. > > > > That is to say, some endpoints are more important than others; and > > moreover some apps on some endpoints are most important. > > Distinguishing between apps is difficult in IPv4. > IPv6 lets you naturally have many IP addresses, so it could be easier, but > apps need to be taught to use "their" source address. Or OSes need to force > them, or "containers". > > In the specific case of a single network, I'd just do static DHCPv4 > allocation and change the parameters on the qos scripts. > > In general, I'd want RFC8520 to announce the type of the device, and suggest > a particular class of service. In the old days, we'd be talking RSVP to > signal desired Diffserv behaviour ("DiffEdge"), but that specification did > not, unfortunately, gain market momentum. > > > I put a linux laptop between CPE (WAN) and LAN. AT&T fiber in my case, > > 100+ mbit up and down. > > It's not a terrible thing to use a laptop, but at 100Mb/s, an Omnia Turris or > equivalenet running latest OpenWRT may be more foolproof. (I'm always the fool) > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >