cPacket Proactive Service Assurance and Compliance

Thank you for joining us. My name's Eric ine, uh, I'm Field CTO for C Packett, and I'm joined with R Devoux, our, our CTO. And we're, we're gonna talk specifically about being proactive.

So, so far we've been talking about reactive, right? Users are impacted, um, something's going on. Uh, service has been degraded.

Or more specifically, there is a condition in the network or a condition on a server that's, that's happened that the systems have already identified. So hopefully in a, in a, a proper, you know, future state, we are identifying the issue, hopefully fixing the issue and avoiding the ticket in the first place, right? So this will actually reduce the number of human created incidents and shift to more machine created.

Hey, I did something, identified it, I was using, uh, different, uh, processes. I know the network, I know, uh, what's going on. And then I have a human in the loop giving me some, uh, guidance as once we surface this up, and therefore we'll get, uh, a better response when we're more proactive.

Yeah. So I think in a way it's kind of the, what we're thinking about is the nirvana that people, uh, were asking me about, which is, so today the way I think about, uh, our users is they always dread the phone call, right? And it's always there is a, a fire that they have to fight.

So can we, so in the day where they actually come in the morning and say, I don't have any fire to fight, can I go and check what I should do today? Right? And can I use the system to tell me, uh, what is important?

What can I actually do today that will make the network better? And we're using this, uh, triangle to kind of talk about, to think about it, right? So if you think about, uh, data information knowledge, right?

So we are always, we always start with the packets, three streams of packets, and we're able to take them into our dashboarding and show nice graphs and whatnot. And very quickly you get to hundreds of graphs and which graphs should they look at? Which dashboard should they check?

So what we're using the insights for is to say, okay, out of these hundreds and hundreds of things, here are a few handful of things that are more important and more important can be in the eye of the beholder, right? Can be more important because it's more severe because it impacts a lot of station. But I may not care about it because it's a data for different data center and not responsible to data center a or it may be security, and I'm not dealing with security, right?

So the idea is I am able to show and highlight, here are the handful of things that you should care about. And then again, in the beginning of the shift or at the end of the shift, you can say, okay, what things should I care about? Uh, today, uh, the use case we're gonna show here is, um, actually from our network is a case where, uh, one of our clusters is getting, uh, uh, busy.

So it's not, it didn't generate any phone call yet, but it's certainly something there that is worth expanding the capacity of the server. Okay? So the idea here is I'm coming in the morning and I'm asking the users ask, what's new in the last 24 hours?

Are there, again, I don't have any phone calls, I don't have hot tickets to work with. What can you tell me about the network? Right?

And it says, well, he is looking for the last 24 hours. And it says, well, there are some clients that are, uh, having issues as with latency, they're too slow. I'm seeing errors and I'm seeing different location.

Now, I specifically, or the user specifically in this case actually was interested in the, uh, what's going on with our core network core, uh, core engineering network. And we servers in our core engineering network have any, have an issue and this is the, uh, proxy, or this is the server that is actually having this, uh, resource utilization issue. So if that's now the one, so essentially if you think about it, it's like, okay, there are many issue, even even when I reduce the hundreds to a handful, it's still a handful.

I still need to pick one thing now to work on, right? So this, in that case, I was like, okay, tell me a little more about that specific server, right? And now it's gonna go there, it is gonna compare all the informations that we have, all the endpoint analysis and endpoints that are talking to it.

Who is this? Who is impacted by that, by that network, and is gonna bring in more and more information about that one. And if you remember, the 10 52 51 8 is our VLAN server is the one that I'm unhappy with.

So that's the one I'm gonna chase, right? So now it's like, okay, there are many issues out of this issues. There is one specific thing that I think I can, we can do something about it.

And this is, and what you always see here is to your point, some of the things that we embedded, some of the things that the, uh, we're using cloud here, uh, anthropic, some of the things philanthropic bring in, right? So, okay, so some of the classification critical, not critical, you know, that's come actually from the engine. The difficulty I have is you don't know how reliable, I know that on the other side of the MCP service is reliable because you guys programmed it and you experts on the side of the LLM, I'm not quite sure how reliable it is, right?

In terms of the logic, in terms of the Accuracy. It, it's a great question. So part of the US releasing, so there is a lot of work that we're doing in writing the CPS and the servers.

There is even more work we are doing on val, what we call validation, right? Because the validation is not easy to, is is somewhat some of, some of that is subjective. That's correct.

Yeah. Yeah. So there is a lot of, uh, work that we're doing today on, you know, did it bring in the answer?

Did it bring in everything and right? Yeah. Uh, the Attributes, the false negative problem, right?

Which is false positive is one thing. Worst case you've wasted time. The false negative is, you know, that's dangerous because you miss something.

I mean, the other question I have maybe a larger higher level question, which is, you know, it's kind of cool you're typing all these things in. Like if I'm a network admin, I would, I prefer to have an appropriate PAC at UI that does these things automatically for, for me surfaces all the right things with the right colors, right? Right.

Alerts. Or would I be talking to my LLM, right? What's the most, what's more efficient for what kind of task?

Because I, you know, like the, you know, the, the morning off task, I'd rather have a dashboard where, you know what my business is, you know what my job is and you've organized it for me in the way that's the most efficient for me. Maybe some preferences, customization, but I'm not sure I wanted to be sitting there talking because I don't know what I missed. Right?

I, I don't know how to ask it or I don't, I mean, some of the queries in there are very sophisticated, right? I don't know. I could do that, right?

It's really cool, right? But how do I know what I don't know? Right?

That's, that's the difficulty I Right. To add on. Yeah.

These are really sophisticated prompts and it's like, you, you're copy and pasting this 'cause you're saying gimme this, but don't gimme this and gimme this and gimme don't give this. Um, which is obviously needed to get the right information, but now I'm sitting there with a, you know, spreadsheet or a, you know, a text file sitting there copy and pasting every morning to do the same thing. Yeah.

That's, that's a discovery problem, right? The, the, the ui, the UX discovery problem, which is that how do I know what the system is capable of? And in the good UX design, you help me understand it, and I know I've explored all the spaces completely.

I feel comfortable as a network admin here, your space is infinite, right? Because I could type in anything I want in English, but I don't know what the capabilities are. I don't know how reliable those capabilities are.

I think that's the, the, I mean, it's cool demo wise, right? And it can be useful, but as a network admin, I'm sitting there and like, it's not deterministic enough, right? I I, I'm, I'm worried.

Right? Right. So there are multiple questions that you asked me.

Oh, great. So there is a, we don't also have in, in the actual, the other network field day, we did show the dashboard. Mm-hmm.

So yes, absolutely are People, which I'm sure we would all be very happy. No, No. The, the, the card, what we call the cards.

Okay, I see. Yes. So, so absolutely we, yes, there is the logic.

They say, uh, show me, choose for me what the information is, and you click, we didn't want to repeat the same thing that we did last time. Sure. Yeah.

Uh, so absolutely there, I think there is the other level, which is, uh, one way to encourage. So, so one of the things that you need in order to do the characterization right, is to choose the, um, what is relevant for the user. Mm-hmm.

That's, uh, this interaction is one way to get the, the reference. So as, as users ask us, we basically collect what they are care, because a lot of that there is customization and there is personalization. Yes.

Right? You may not care specific on data center in Japan. Mm-hmm.

Correct. So you say, yep. And I don't know that to begin with.

Yep. So the first dashboard will show everything and then you'll, you know, you can taste the like or didn't like. So the dashboard as in show me all the cards and go from there is absolutely there.

Uh, the second question about the length of the prompt, that's something that becomes part of the rag. I just, for the quickness of setting up this, I don't, I didn't put it as a, but, but that's in the context of a project or a chat. Uh, so you don't have to reco, uh, copy it.

Uh, and uh, what was the third one? There was third question. I think that was the length.

Yeah, I think the discovery, I mean, part of it, I think what, what Ryan was saying is that, that it's a very long prompt, right? And right, I mean that Prompt, so the long prompt doesn't have to be there. No, but we don't know, like, I mean, Right.

So this is when we put, yeah. So this is all we're showing you what's coming, right? Right.

But that's absolutely, uh, the validation is, is something we work a lot, a lot on, uh, making sure that the context in there is something that we work a lot on. I would say that at the end of the day, if you start, uh, peeling the onion, the issues that you deal with in a network are not infinite. They basically say, do I have a server issue?

And the server issue, is it related to network? Mm-hmm. As in when I see higher load, the server is loading, or is it something that has nothing to do?

It's an application issue. And then if it's a network issue, it's gonna be where in the network it's gonna be, right? Is it a load bouncer, a proxy, a router?

So there is a lot more that we can do to, uh, uh, to basically, uh, structure the questions such that they're not that open and that's part of the things we're doing now, right? Yeah. And if it's sufficiently constrained, it shouldn't be a chat interface, right?

Mm-hmm. So like in here, there was something where it was talking about like the, you got, you know, separate data charts for each VLAN listed at the bottom there. But if you're only, if you're doing packet captures and not looking at like a switch config itself, you're, you would only know what VLAN it's on if it's tagged, right?

Like how, how, if you've got a big network and you're going across VLANs, you've got an UN-tag VLAN or whatever do, is there a way that you can tell what that looks like? 1 Q tag on this packet and then it came off. It could be, you know, native VLAN 100, the packet doesn't know.

Yeah. So our packet brokering, uh, solution tags, the packets, we have two, two ways. So what we call is, is the, uh, monitoring point.

And a monitoring point is either the physical port that arrived at the packet broker or in the cloud, the instance of the cstore that received it. So when we, I say villain here, but what I mean is a monitoring point, which is actually a physical, uh, location in your network based on either span or a tap. Yeah.

So again, the chat used VN the way to think about it is a monitoring port. So where, where exactly in the network it happened, and essentially what the, this whole thing, uh, led led me to say is this wasn't, so I did see a latency issue. So the server was reacting slowly at a given point of time, but it wasn't really an issue of the network at that point.

It was because I saw it everywhere in the network. Uh, in the same way that really meant that it was, uh, ours. Basically, VM host is running out of resources, or it was a good time to upgrade the host.

Let, I'll just stop it there, right? So the idea is really to be able to, again, if I don't have anything to do and I want to get the network to be better, or the application to be better, this is the analysis. You have time to run a lot of interaction, then you need to decide, do I need to do something about my network or do I go back to the application team and tell them to upgrade the server?

Alright, so just to summarize, um, you know, I think this really does highlight the key point that work goes on as a network operator. And these type of processes and tools will really help augment what you do today. Um, lot some folks want to stay on the dashboard, some folks want to go to the command line, some folks want to go to logs.

Um, the, the reality is, it's, it's about the clock, right? It's also about being proactive. And that's what we're really highlighting here is that the, the AI is augmenting what you're currently doing.

It gives you another tool in the toolbox. And I think as Ron was saying, it's evolved. The technology is evolving so fast.

The, probably one of the core fundamentals is that you, you have enough capabilities to integrate it in different, different ways based on the workflow. And that's where, um, the model context protocol really does allow you to build these new, uh, NetOps agentic workflows. And we haven't built those yet.

Like they're, the, the customer's gonna evolve with this, and we're gonna evolve with the customer. But you do need to have all the data. You need the packet insights, you need the session based metrics, you need to roll that into the capture.

You need to get all of that, uh, together. And that's what we're really focused on. So the other thing is baselining, right?

So there's, because you're dealing with huge volumes of data, um, and to try to surface up on a a, a Tuesday morning trying to understand where to spend the time, the baselining is gonna show you that anomaly, and that's gonna help shorten the triage time. We do have to integrate this into the processes. So this might even be like a level two or a level three engineer problem where they know enough context of the network where they can run the prompt.

But there may be other cases where it's a level three and it's a really complex issue, and you do need to get into the details, right? And so now this is AI assisted to help you triage that faster. And we also know that we can get, um, you know, this, this, the timing down based on MTTR, that's our indicator.

Um, it which part of the network? Is it the load balancer? Is it the application?

We need to better understand that. So really it's at the end of the day, it's gonna be data driven, right? This is, this is the outcome for the, for the customer.