How to dig deeper into ASYNC_NETWORK_IO waits
ASYNC_NETWORK_IO is never a server side problem.
This wait indicates SQL Server has results to send to the client, but is waiting for the client to consume the results so it can finish sending.
It's possible (though unlikely) that a slow network is the bottleneck. This almost never is the reason, unless someone is using dial up quality network connections. The fix here is a faster network connection. (But that's not your problem.)
It's also possible that the application is explicitly stopping it's consumption of results due to bad design. This will happen if the application accepts the first 25 rows to display, then stops accepting results forcing the server to wait.... And only taking the next 25 rows when the user hits the &quot;next page&quot; button. In this case, you'd need to change the application to either consume the whole result set at once, then handle pagination just in the display, or to change the app to simply ask for one page of results and do a round trip for now 6 every time the user hits &quot;next page&quot;.
Lastly, it could be a client machine that is underpowered, or a poorly performing application. SSMS is one of those poorly performing applications. If you do a SELECT * FROM dbo.HugeTrillionRowTable you'll see ASYNC_NETWORK_IO waits pile up for your session. The right fix here depends on the details. You might need to add more memory to the client machine, or scale out to more client containers, or have a code change in the app (that's the fix for SSMS, but it's not a trivial change).
In your case, if you can get read only access to SolarWinds DPA, you will be able to drill into that wait to detrimine the query, client, etc to get into those details. If you can't access DPA, you can monitor sys.dm_exec_session_wait_stats, though this will only show you info for currently running queries, so you'll need to catch the offending code in the act. There isn't a &quot;time machine&quot; DMV to go back after the fact.