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

[Robert Raszuk]

Hey Mark,

Just to clarify

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.
>

Ahh no. See with decent TCP analyzer I am monitoring end to end network
behaviour regardless of the point I setup the TAP between src and dst.
Clearly easiest is to insert TAP in my ISP peering links. So no guessing -
real data only :).


> 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.
>

Ahh that is a fundamental misunderstanding to what I was apparently not
well trying to describe. I am not monitoring any targets. I am monitoring
and performing real time TCP analytics (using said analyzer) of all my
in-out data. And here I have few options. I can focus on optimizing most
active sessions per per volume. I can focus on optimizing sessions per
src/dst port, I can focus on optimizing sessions experiencing most
retransmissions or I could just try to improve RTT, jitter etc ...


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

I understand that if you have no right tools the problem is hard to solve.
But that is like everything else :) Go cut piece of wood with even best
japanese kitchen knife ....


> 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.
>

Fair. And the only point of my note is to just share a bit different
perspective. I am very well aware that we as networking industry are really
in the stone age as far as various aspects of performance routing is
concerned. Or for that matter dual disjoint path routing without any static
configuration or building two topologies.

All networking today Internet, intradomain, DC cares about reachability.
Quality of that reachability is pushed to the application layer. Well sure
this is ok if you have good app which can build multiple connections to
different destinations like say torrent. But not all apps are like that and
some would like network to be a little bit more smart :)

Best,
R.

On Sun, Mar 15, 2020 at 12:31 PM Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> 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.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>