It sounds like you may just need to install some monitoring utilities on the systems under test (if they are not already available). Can you tell us a little about the architecture? Who is responsible for managing the server? They probably have some monitoring tools that you can use or will be willing to work with you to perform the monitoring.
You can use a network sniffer to capture the bandwidth information. We use Network Associates Sniffer, but there are some free ones out there, too (Ethereal is one I've played around with a little). If your company has a Network team, you may want to talk to them to find out what tools are available and may even be able to enlist their help.
SoCalGal - Defender of end user response times!
You may have a bit of a challenge. Most tools are designed to present a load on the server by using a transaction paradigm. Your quest is for simple requests that trigger a continuous data stream to the end-user. Presumably you cannot trigger more requests from the same source node until the data stream is interrupted and killed, or until it has completed normally. You would have to incorporate a wait in each script for some menu or something to reappear that signals the end of the streaming download, and then to re-request another download from the same source. I am sure that a tool like LoadRunner can do this, but it will take a little trial and error to make it work (I have not done such a thing myself). As Laura already pointed out you also need sniffer logic to monitor lines and ports that represent the bottlenecks. In this case you also need to monitor the workstation(s) used to generate the load, as in this case each virtual user must process a lot of download data.