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

[Mark Tinka]

On 15/Mar/20 17:25, Robert Raszuk wrote:

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

Yes - I'm not talking about performance between two targets. I'm talking
about what you can do to fix those issues once you've found them.


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

Practically, I'd be very keen to understand how you can optimize for
volume, beyond the obvious.


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

Again, my issue isn't the tools. Those are plenty.

My issue how to effectively fix issues that are so far apart between
source and target.


> 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 :)

So for me, this is my biggest problem with the theme of this thread.

Identifying the problem between source and target isn't the problem.
Getting it fixed is.

It's great that we can optimize for volume as best as possible. But most
of the tickets customers send through are, "I am having a problem
getting from my network A to network B, or network B getting to me,
network A. In many cases, network B is some obscure customer of some
obscure network who probably has no personal or commercial relationship
with me or my customer, and trying to find whomever operates the network
that serves network B is much harder than verifying there is an issue to
begin with.

For me, improving the communication between operators and their
downstream customers to get problems fixed is what really matters to me.

I am regularly contacted by various people I know or don't know to help
fix issues between the network I operate and the one looking for some
help. And vice versa. And I am sure several folk on this and other lists
are going through the same. It's rather rudimentary, but for better or
worse, it's the best we have at the moment.

As we've all seen over the decades, most people just gave up and left
the problem to CDN's to fix :-).

Mark.