Does such a query (that is suspended due to an ongoing ASYNC_NETWORK_IO) cause blocking on this table?
It might or might not.
ASYNC_NETWORK_IO itself isn't capable of blocking anyone else (ok, it can if your system runs out of worker threads, but that's an edge case). Read on.
For example: does ASYNC_NETWORK_IO mean that execution is ongoing or execution has finishes and the client app is pulling the data?
You say the session running the query is "suspended" not "sleeping". A suspended query has not finished, by definition. If it were finished, it would have a status of "done" (very briefly) or "sleeping".
In the later case I don't see reason why this query could potentially block other queries given that it has already produced its result.
Well, the session is holding locks. Those locks would block any other session needing an incompatible lock. In other words, the suspended session could block someone else, it just isn't at the moment.
The important point is that it is the locks that would block, not the ASYNC_NETWORK_IO status directly.
You might ask at this point why the session is holding locks.
You might have a mental model where SQL Server produces a result, stores it somewhere, then ends the query and waits for the client to consume the result. That's not (generally) how it works. It would be inefficient and impractical to always store arbitrarily large results on the server.
Instead, SQL Server streams result rows to the client as they become available from the execution plan, which you can think of as a 'pipeline' of data. When the client stops receiving rows, the pipeline stops, and execution is suspended until the client starts asking for rows again.
If the query was holding locks when the session was suspended, these locks continue to be held as long as the suspended status continues.
Side notes:
There is a small amount of buffering between the server and client (a few network packets worth) but this isn't normally sufficient to hold the entire result and the query doesn't complete until the buffers have been emptied by the client reading rows anyway.
A query won't always hold locks when suspended. It depends on what the execution plan looks like and what it was doing when SQL Server tried to put the next result row in the buffer and found no room.
For example, some plans might have a final sort that will indeed consume all result rows in order to sort them. Data access has finished by the time the sort is ready to produce output, so there often won't be any need to hold locks (depending on isolation level etc.)
For more on how execution plans stream rows one at a time, see my article Iterators, Query Plans, and Why They Run Backwards.
