> What I think we're missing is the integration of network attributes and class
> of service. For instance, user to 'internet' has 3 potential paths with each
> having these end-to-end latency, upload throughput, download throughput, and
> say 'quality' or packet loss. Then having your QoS
> 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.
> Babel is so simple that toke wrote a near complete implementation from
> the spec, in python, during a string of
> our toasts to the builders of Notre-Dame.
...which then burnt down :-/
> Dijkstra's algorithm remains a very natural approach to mapping a
> graph
I'm not sure what that means. Dijkstra's is a shortest path algorithm,
it's not in the business of mapping. I guess the author meant that
> 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
> OSPF is where it is now because it's "good enough (for now)"
It is very good.
> Sure, an implementation that spits out bad LSAs is going to break
> everything - you're going to get some pretty nasty results from sending
> out broken destination-distance-vector data, too.
I claim that in DV
> 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
> quic takes over
Now if only thay had gotten the layering right... such a terrible wasted
opportunity.
(SCTP forever!)
-- Juliusz
___
LibreQoS mailing list
LibreQoS@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos
