From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 0B58E3CB36 for ; Tue, 16 Oct 2018 11:57:06 -0400 (EDT) Received: by mail-pf1-x42d.google.com with SMTP id l81-v6so11675319pfg.3 for ; Tue, 16 Oct 2018 08:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Wozqj8IQFtFhU60JzgYZ9IwwNzPbntpmN63Si/iJiQ4=; b=j2QJmbSskWKW1dFmoXtf0nijn6Gma7UXZST3ozHeTLlnHsik+ok+fvrhSpe1wPbiYD Mdj23yFW13Yp9x6NkZgBnx/7yQ1URg02cDmkuuYua3DBmwPtmrrf7PP0xWFymavYASNb /Wxa1gsM8p8dqzwvbifoP5bGV7Lida3+dovUsB0xTuIlokbkpJBTMFe9QP90RmLxJecM JkE0KCvNM+KFebWfr0Q6Xb6zXs43Fvp6BZPcdCRBPIAJH7xv7/z1YdsyILKqt/trsGGY Qcpy3JnXvhk4RPRkREqnUqu/3kRLswDZtyDTMOf8JWsFKa/HD/a6Ho4v9Ao7uJ6FHCVU qu2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Wozqj8IQFtFhU60JzgYZ9IwwNzPbntpmN63Si/iJiQ4=; b=rdWea23tHYJkBIdqFOvOcLOpmg1IShMb9rwoVVmTNeAlEwj46fM51RwHaoEGm67CG4 49yK2q+PYTjIZ8u8fCfTh2nTy2xY+gCA5RcPXQU/vuwThC1m4Es22SgTaJlp5DM2aubA 4/vWs/AMIrbmFHSCfjnSFNCzyHwvCFhcc9NLMYVIjevJdMOtIc46ieqghXNxXsoumNQm NanjFsB7ZyJiTIT2/jv2ArvLiZgIwn+e2OTu5KncvlqipuSQV6G5JpoTUvOAn4hQZ/R9 TVlYVvJ2NR5D+upS5V3EMJFIgvuf9xFJXDzN8qd4ZjXbKxdjUp2+YDOXw7R4r6l/+5IS 3pnw== X-Gm-Message-State: ABuFfohHodSQhvb9BLkQztzCL7YXmpdOPFFijQ+rS+aCskp9Taw2Txsr 0iswzTQ7qHR60qH9Q1SoXyr90Q== X-Google-Smtp-Source: ACcGV60LNj/tMzXGO0upzglUb1OVQx/tuT1z3oObjpJ1YmahpG5bcM/FQfnpYZBtLXSYMwiWv37RGg== X-Received: by 2002:a63:ac56:: with SMTP id z22-v6mr20868403pgn.444.1539705425022; Tue, 16 Oct 2018 08:57:05 -0700 (PDT) Received: from xeon-e3 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id s85-v6sm22600493pfi.15.2018.10.16.08.57.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Oct 2018 08:57:04 -0700 (PDT) Date: Tue, 16 Oct 2018 08:57:01 -0700 From: Stephen Hemminger To: Dave Taht Cc: Stefan Alfredsson , bloat Message-ID: <20181016085701.08aea245@xeon-e3> In-Reply-To: References: <68031ed5-05e5-8f53-5e7d-ef0fce9d08da@kau.se> <20181016080628.2ca3652b@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] vyatta in AT&T 5G gear 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: Tue, 16 Oct 2018 15:57:06 -0000 On Tue, 16 Oct 2018 08:14:36 -0700 Dave Taht wrote: > On Tue, Oct 16, 2018 at 8:06 AM Stephen Hemminger > wrote: > > > > On Tue, 16 Oct 2018 11:59:18 +0200 > > Stefan Alfredsson wrote: > > > > > On 2018-10-16 11:31, Mikael Abrahamsson wrote: > > > > > > > On Mon, 15 Oct 2018, Dave Taht wrote: > > > > > > > >> Vyos (the open source fork of vyatta) was one of the first to add > > > >> fq_codel support... I wonder.... > > > >> > > > >> http://linuxgizmos.com/att-releases-white-box-spec-for-its-linux-based-5g-routers/ > > > >> > > > > > > > > Isn't Vyos just running the Linux kernel for forwarding? So they > > > > received fq_codel for free when the Linux kernel got support for it? > > > > They just had to make it configurable? > > > > > > > > > > Yes, according to this blog post, > > > http://www.five-ten-sg.com/mapper/blog/Bufferbloat%20solved%20with%20Vyos > > > > > > "Now that Vyos "helium" is available with a Linux 3.13 kernel, the > > > fq_codel queueing discipline can be used to solve many bufferbloat > > > issues. The nightly "lithium" builds contain my patches that allow > > > fq_codel to be used via the native Vyos configuration system." > > > > > > Anyway it's nice to see the Vyatta heritage living on in it's various > > > forms (the AT&T "production hardened" Vyatta, to the Ubiquity EdgeMax > > > and some UniFi devices, to the VyOS open version and now the future > > > plans with dNOS -> DANOS. > > > > > > /Stefan > > > > > > > > > > > > > There are two basic components to network OS, the control plane and the > > data plane. VyOs has the old V1 which is filesystem based control plane > > and kernel dataplane. DaNoS has yang/netconf database based control plane > > (in Go) and DPDK (or switch offload?) based dataplane. Ubiquity redid > > the control plane as well, and uses their own hardware for dataplane. > > > > So more of "my grandfather's ax"... > > so in other words we should have done a dpdk version long ago. And even then, > this white box brags of the "deep buffering" in the switch chip. > > ... and I have an initial report of 2 seconds of buffering on one of > the first 5G devices. > > Sigh. > > And what was so wrong with the "everything as a file" model?? Two things were an issue. At scale, the filesystem was a bottleneck and it would have been harder to implement netconf/yang model as required by the big boy market. Filesystem works as toy. (see plan 9)