[LibreQoS] routing protocols and daemons
dan
dandenson at gmail.com
Sat Oct 29 20:09:14 EDT 2022
I wish I had a fancy pony with:
Routing based on diffserv.
'Hitless' adjustments to path diffserv cost. ie, if a link has a cost
change, propagate that out without dumping routes.
link cost with metrics matching diffserv model.
ie, if diffserv 4 then a link might have:
a cost for the hop
a cost of it's expected latency + it's measured latency
a cost for it's fixed/set throughput with some method to modify this
programmatically (say radio modulation changes, admins can run scripts to
adjust this)
Above link cost, have a router cost. So if a router is considered to have
a throughput limit of 1.5Gbps aggregate, then it might have a cost that
varies based on throughput or cpu use or something like that. So we can
route around saturated sites. This might also make the network be more
ad-hoc, lots of sites might try to jam data through a central hub site but
when it get's saturated, other paths might start looking good.
type of service cost. This might be an IP map or something, but for
operators to classify business vs residential vs enterprise services.
and a reservation cost which may be a bit hard to describe, 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.
obviously, some method to slow adjustments and ramp up/down on various
factors. Maybe some method to do some reservations with rolling updates to
keep things from oscillating or routes from flapping. If a path gets
hammered so latency spikes, back it off and then creep up slowly.
Probably configurable on each link. An AF60LR for example has some more
or less fixed modulation levels so when it starts bucking, it's going to
modulate down super fast. Maybe the cost for throughput has some steps
built in so it falls back to pre-defined levels quickly. Whilte AF5XHD is
going to be more a noise issue, new noise might reduce modulations but a
bit so the fixed numbers put in might need backed down.
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.
BFD capabilities, preferably built in vs separate BFD process.
'Route Oracles'. Routers that advertise that they'll store the router's
cost tables for all other routers to subscribe to. Would allow routers to
evaluate which other routers are even remotely in their path and then watch
for cost changes. Also give operators access to routing maps to use for
crazy shit like LibreQoS tree building. or show links that are
underperforming vs stated fixed values etc.
Finally, before I make this wish list too long, REDUNDANT packets. For
instance, maybe we want to tag, for a specific customer or customer class,
that anything that looks realtime should have a FEC type packet sent and
the most different but usable path possible to be re-assembled on the other
side. This might even be a link that is described as a 'dont use this for
anything but FEC except last resort route, and still only use it for real
time packets' so you could strap in an LTE or Starlink type link. The FEC
packets are smaller, say 5-10% adjustable, so you don't need to entirely
match the capacity, just to catch packets that get lost in a re-route due
to link packet loss.
ok, that's enough for now. You said I could have a pony, I asked for a
clydesdale.
On Sat, Oct 29, 2022 at 4:18 PM Juliusz Chroboczek <jch at irif.fr> wrote:
> > Ultimately though, these are just shortest hop path builders and need
> some
> > other kit on top of them to do any sort of traffic engineering or load
> > balancing. ECMP doesn't work for me, and doesn't work for a lot of wisps
>
> Perhaps one of you could explain what kind of traffic engineering and load
> balancing you'd like to have? Please don't try to be realistic, try to
> describe the pony you wish you had.
>
> -- Juliusz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20221029/f935b156/attachment.html>
More information about the LibreQoS
mailing list