Taking juliusz off the cc for a sec. He's the author of a lot of cool stuff: https://www.rfc-editor.org/rfc/rfc8965 being one of them, but I first got to know him via the polipo web proxy... Anyone ever use that?
I also thought his work on continuation passing C (CPC https://www.irif.fr/~jch/research/ ) was way, way ahead of its time. One of his students wrote the then-fastest torrent server... and you can see reflections of this work in modern frameworks in tokio and elsewhere. I switched to his galene.org videoconferencing server early on in the pandemic and have never looked back. On Fri, Oct 28, 2022 at 5:01 PM Dave Taht <dave.t...@gmail.com> wrote: > > On Fri, Oct 28, 2022 at 2:45 PM Juliusz Chroboczek <j...@irif.fr> 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-6981366665607352320-FXtz > Dave Täht CEO, TekLibre, LLC -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz Dave Täht CEO, TekLibre, LLC _______________________________________________ LibreQoS mailing list LibreQoS@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/libreqos
