From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450: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 65FCD3CB37 for ; Fri, 28 Oct 2022 20:02:03 -0400 (EDT) Received: by mail-wr1-x42d.google.com with SMTP id bp11so8476203wrb.9 for ; Fri, 28 Oct 2022 17:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cYaAHAaGULSErzvng1f+XZXb8w98iG6KoCra0Q8l7wA=; b=DOtjOb1Yd+c4RlEtspbCdimcJ7JyAkJSnZljCn2r2BksFXNPnGVzfPEO4mvODkdqoB oIYpgdkGcdD+vIvg+W+IC9VQ9+fMHXCf3fhVYwF/0YpOloW0LpzJYMNEOG4jCUhHTuPG ++g/6XFo7cNy9g/jYJViIJCLifShQlkkW2yrt8SpjJrSXLhXNupD6kyS1aYh+QJeIl6I T3sacSUSuwDNCyQO6AzkZTToAxwa8XRfL7RVvtyrTH1zqddgL6Ia6txS1kkpYCxgI9iu /fALyrZrPh/OwftlMnsrs1Qtv5/J1OMPSI45pRbITP7LTnArTWHDwy1h51B6NhaM+Ipn UsIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cYaAHAaGULSErzvng1f+XZXb8w98iG6KoCra0Q8l7wA=; b=5IPYjaLoGGLdUDJU+SG0yJ5Q5hqs53ijaka4UArsdLuJwcLC04YoATPDPpBsob8h8a 20A60VO23kTLrQAtX8OW9nWGK1bD1DTRGIHn0H96wYkJmJX/yK3GuAGEe08+h52KpJ1F wxIi89Lb4blLYTTDCgZ8oyvXoVpUiZW1hk3Iwhfa36FQau3vMTYrsOCfsuC8W2NLiTKt Wa6OkfrpuYUNgbXvn8fFhS94LPqFyO+RY3VkuCWxzjBS0MVHK3bdGWS7xwLozzg9WYIB qoQFmYenulV9PvD1M2Xt/sxKtyphAfjEQJjE5GGdK2t5X16UIu0MrqeZkrHY+SYTDB1j t0Ng== X-Gm-Message-State: ACrzQf2qYXCYwDi03v6APVacOFWNjJQ3AWCtQ57aGFMQtnrqLatW+rB6 BSdaQP7RD4dH4K61xVsqqwclaPFxgyWQd7APVxY= X-Google-Smtp-Source: AMsMyM7bgoTXMT+2PxVFLyhsCV860VG3EkxEK+3LV1V6NoBWefWjZdzZa9WX/kXxG6c5ne4E3f+i0x3mQ3+9ZimxLHo= X-Received: by 2002:a05:6000:69b:b0:22e:36aa:5f1 with SMTP id bo27-20020a056000069b00b0022e36aa05f1mr924135wrb.430.1667001722087; Fri, 28 Oct 2022 17:02:02 -0700 (PDT) MIME-Version: 1.0 References: <87sfj7vczj.wl-jch@irif.fr> In-Reply-To: <87sfj7vczj.wl-jch@irif.fr> From: Dave Taht Date: Fri, 28 Oct 2022 17:01:49 -0700 Message-ID: To: Juliusz Chroboczek Cc: Herbert Wolverson , libreqos@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [LibreQoS] routing protocols and daemons X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2022 00:02:03 -0000 On Fri, Oct 28, 2022 at 2:45 PM Juliusz Chroboczek wrote: > > > found babel, corresponded with (and frankly thoroughly annoyed) the > > author, > > Being said author, I can confirm that you did thoroughly annoy me. But > then, you also made me think. I'm glad, ultimately, we also drank, and I'll always remember (somewhat blurrily) the day/night of our toasts to the builders of Notre-Dame. earlier on in this thread, herbert listed his complaints about OSPF, if you have a spare moment, have you ever had any deep thoughts about it? --snip snip-- Dijkstra's algorithm remains a very natural approach to mapping a graph (I've waxed lyrical about it in various book/article/blog posts over the years in the game-dev world), so I find it a very comfy way to model the underlying network. Very easy to reason "this will go that way". So what's bad about it? * ECMP is equal; if you have routes with different costs it will only use the lowest cost - it won't try and "mesh" some of the traffic in other directions. Likewise, if you have two equal routes - and one of them is running at a low capacity - you wind up only utilizing twice the capacity of the slowest link. You're often better off dropping the link over the degraded circuit (hence "carrier drop" features on various radios). * OSPF has no idea what the capacities of various links are. It'll use the shortest cost route, and leave the details up to the lower layers of the stack. There have been various attempts to integrate capacity into network design, and I've yet to see one that holds up well on a multi-vendor network. If you ask a Ubiquiti Rocket AC Gen2 its capacity, it'll often give you some nice big number - but it'll stall out far before that number. The Force 400C link we just put up doesn't even try to estimate its capacity. So multi-vendor mesh routing tends to be problematic, because the advertised capability of "we'll utilize everywhere you have capacity" tends to get snarled up in figuring out what the capacity is. I understand Teragraph is supposed to do better there. MPLS traffic engineering was originally announced as solving this one, too! I don't see a lot of hope for capacity-aware routing protocols taking off, but I imagine we'll get a few new ones announced and then quietly forgotten as before. And lastly: once your network gets really big, OSPF tables can get too large - and you're stuck either dividing your OSPF zones and/or using some BGP in interior mode. You can mitigate this with some careful design. -- unsnip -- I don't suppose you have ever had any ideas to how to improve things? > > > Babel is so simple that toke wrote a near complete implementation from > > the spec, in python, during a string of extremely boring IETF > > meetings, over the course of a week. He later took on the bird port. > > This is not correct. Babel was first reimplemented in Python during two > nights during an IETF meeting by Markus Stenberg. As to Toke, he did the > BIRD reimplementation in C during a Battlemesh meeting, and it took him > a whole four days. I later did a minimal implementation in C, which > compiled to 20kB of x86 code. You're working on galene, now, primarily? How's android treating you? > > > I forget what happened to toke's python version). > > Markus Stenberg's. It's still available, but fairly obsolete due to > advances in babeld and BIRD. > > https://github.com/fingon/pybabel yea! > > Althea is using babel and fq_codel in their blockchain routing thing > > (I reserve comment), and I don't know where else, besides as part of > > wireguard tunnels, babel is being used today. > > Now that Babel is no longer a legitimate research project, the main user > and main source of funding for Babel are Nexedi, who use it in their > distributed cloud > > https://www.nexedi.com/ If you can stomach it, I have a copy of althea's most current preso, which I can send under separate cover. They scored 15 out of a 100 on a funding round with it, but there babel and fq_codel were, with an rtt metric on page 16... At least they leave breadcrumbs back to where the actual good ideas came from. Many others in web3 haven't. > > But I agree with you, Dave, Babel did not take over the world. The main > reason, I suspect, is that OSPF is very good, and that most people are > happy enough with it. Everything can be improved. > Notwithstanding that, we're still maintaining both the standalone babeld > and Toke's BIRD module, and we've been busy extending the protocol with > source-specific routing, with v4-via-v6 routing, with MAC protection. I am so in love with v4 via v6. It's just having to wait 6+ years for places like mikrotik to ship it that I can't stand. > > -- Juliusz -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656= 07352320-FXtz Dave T=C3=A4ht CEO, TekLibre, LLC