From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B28403B29E for ; Sun, 30 Oct 2022 09:42:22 -0400 (EDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 29UDgKZZ020158; Sun, 30 Oct 2022 14:42:20 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5EA9AF30D5; Sun, 30 Oct 2022 14:42:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=irif.fr; h= content-type:content-type:mime-version:user-agent:references :in-reply-to:subject:subject:from:from:message-id:date:date :received:received; s=dkim-irif; t=1667137338; x=1668001339; bh= IkFaa7o4Wc50F0ocHIk3woN0Q8Yab91BMRV5Sr27Jvw=; b=DV36l67RLGvIFYib dpfq9IiYI7psxQnJXf3/qpQL5exOWcvkS/j25GKtbXatxFn/jzQlTvYX19JzctON 48J+Xa94GB0ieMNerWaCPOiRDTKnJGb+q+JrGASXL4lu17GSYD+UKy315loksktM /qG1//xuLmxGGmFr0t7fcof5RdPYQBZAWMqql8xIYTUaVxrhgTc7mDgWmNpdE7/+ 9WH9TrsF5x48oa59uQcOfPzCF9oW7tanW+CbNi7+Mt+sggQByNafKEUvHVZJBa6u htJyqP3GpRxpJ5QFS+SJs59ltnhaV3/4elsDC07SO8EN07CPYxkC4PR24SGk+asY Brqv/A== X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id dOyDKo6oC5eM; Sun, 30 Oct 2022 14:42:18 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B9013F30D3; Sun, 30 Oct 2022 14:42:18 +0100 (CET) Date: Sun, 30 Oct 2022 14:42:18 +0100 Message-ID: <87k04he8cl.wl-jch@irif.fr> From: Juliusz Chroboczek To: dan Cc: Herbert Wolverson , libreqos@lists.bufferbloat.net In-Reply-To: References: <87sfj7vczj.wl-jch@irif.fr> <87leozuh1s.wl-jch@irif.fr> <87tu3mtgst.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 30 Oct 2022 14:42:20 +0100 (CET) X-Miltered: at korolev with ID 635E7F3C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 635E7F3C.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 635E7F3C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham 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: Sun, 30 Oct 2022 13:42:22 -0000 > I wish I had a fancy pony with: That's not a pony. That's a whole herd. > Routing based on diffserv. That was originally supported by OSPFv2, but was removed from later versions of the specification, to be replaced by multi-topology routing (RFC 4915). It's a little costly if you only have a small number of ToS-specific routes, but I'm told it works well. In Babel, we defined and implemented an extension for ToS-specific routing, but found out there was no interest, so we dropped it. https://datatracker.ietf.org/doc/html/draft-chouasne-babel-tos-specific > 'Hitless' adjustments to path diffserv cost. ie, if a link has a cost change, > propagate that out without dumping routes. I'm not sure what you mean. > link cost with metrics matching diffserv model. [...] > with some method to modify this programmatically It's not sound engineering to implement the whole complexity of DiffServ within the routing daemon. On the other hand, one could envision, as you suggest, a DiffServ daemon that dynamically tweaks route metrics. Babeld has a simple IPC interface that allows tweaking the configuration of the daemon at runtime, and I'd be interested in working with someone who implements such a control daemon. > but something along the lines of 'if a service is being used up by > a higher class of service (enterprise...) then other routers should know > to try to route around that side. Again, that's not something that's likely to make it into routing software, but it's something that could conceivably be implemented in a separate daemon. > Then on the client side or the client's PoP it should discover it's paths for > each diffserv to gateways. This could be pre-mapping 1st, 2nd, 3rd next-hops > for each diffserv to each gateway for example, so failover for link downs is > pretty quick. Modern distance vector protocols do that. For example, EIGRP maintains three next-hops for each destination, while Babel maintains all next hops to a given destination, and only discards them when it runs low on memory (which never happens in my experience). > BFD capabilities, preferably built in vs separate BFD process. I'd have no objection to implementing BFD if there's user demand. However, since Babel can do Hellos up to 100 times per second, our users are not exactly clamouring for BFD. (BFD is useful with OSPF, where Hellos are overloaded and therefore huge data structures. Not as much with Babel, where Hellos are tiny. See https://www.rfc-editor.org/rfc/rfc8966.html#name-neighbour-acquisition for details.) > 'Route Oracles'. Routers that advertise that they'll store the router's cost > tables for all other routers to subscribe to. I'm not sure what you mean. > Finally, before I make this wish list too long, REDUNDANT packets. That's a data plane feature, and therefore has little to do with the routing protocol. A fun little project, to be sure, the difficulty lies in determining the right amount of FEC, which requires very accurate loss statistics (you need to distinguish between random loss and burst loss, and tune the amount of FEC for the former while carefully ignoring the latter). Hence, I suspect that it's better to do that at the application layer, e.g. in the videoconferencing software. -- Juliusz