[j-nsp] Internet monitoring in case of general issues

[Mark Tinka]

On 15/Mar/20 12:56, Robert Raszuk wrote:
> All,
>
> It seems that most answers and in fact the question itself assumes that all
> we can do here is to be reactive. In my books that is an indication that we
> have already failed.
>
> I do think that any one who has more then one internet upstream ISPs (full
> table or even defaults out)  can do performance routing in real time by
> evaluating quality of TCP sessions across 2 (or more). Based on that data
> it can intelligently shift the exit traffic on a per prefix basis.
>
> Folks like Google or Facebook are using such home grown tools for a long
> time (Espresso, Edge Fabric). Cisco pfr had at least originally single
> sided Internet edge OER. Of course with a bit of automation skills any
> one can build your own tool too - the only real requirement is tapped
> traffic such that you can passively measure the TCP quality to your user
> destinations.
>
> For TCP analysis for few years now I am using https://palermotec.net/ analyzer.
> TCP analytics it offers is simply fantastic. GUI and user interface still
> needs improvement - if someone is to rely on that. Just fyi ... I am also
> working with that team to build (Smart Edge Routing) SER controller - they
> already have alpha version, but hopefully in the coming months there will
> be more progress making it beta and eft. The assumption is of course that
> all interaction with routers (any vendor) is over standard protocols (BGP
> or static).
>
> As we all know each decent SD-WAN or Cisco iWAN has ability to monitor
> performance over the mesh of endpoints and choose more optimal paths. But
> that is slightly different as it relies on both ends ownership. Here I
> assume we are talking about just single sided exit routing where we have
> zero control over dst.
>
> All above is about exit. To do analogy inbound is also to some extent
> possible if you are advertising prefixes for your services out. But here
> the issue is much more difficult from the perspective of aggregating
> different services - so at most one could just average which uplinks are
> best for a given prefix for *most* of the users.

My thing is you probably have much better insight and control for
on-net. That leaves off-net as the main issue, as your direct upstream
and peering may be fine, but beyond that is anyone's guess.

If you are monitoring a specific off-net target for some reason, you can
easily control for that. But if you are looking at a generalized
situation, that's a lot harder.

Doubly worse for operators who connect to only one or two upstream
providers/peering points.

I'm not saying we should resign ourselves to, "Ah well, I can't fix what
I can't touch"; but time and resources are limited, so given your
circumstances, spend some time finding out how best to deploy them as
you also seek elegant ways to solve this particular issue itself.

Mark.