The short answer is that you can't, and if utilizing bandwidth efficiently is your goal, you should use TCP.

The long answer is that you can use packet loss as a proxy for bandwidth, and slowly increase the bandwidth until you get a dropped packet, and then quickly throttle back. Where "slowly" means "linearly add some constant to your estimate of bandwidth" and "quickly" means "halve the estimated throughput," you will behave like traditional TCP stacks. (Main improvements in later years: quick-start, path memory, window scaling mechanisms.)

It's important that you behave like this (quick scale-back, slow growth) to avoid overwhelming some local choke point, or getting into extreme oscillation, when other sources of traffic are also sharing the connection.

If you use TCP, then set a buffer size that you're willing to live with, and keep sending on the socket. When the send blocks and/or doesn't transfer all the data, you know that the buffer is full, and thus the other end is behind compared to the speed you have been sending at.

Note that, when your girlfriend starts watching Netflix, or your ISP is doing router maintenance, the available bandwidth for an existing connection may quickly change!

Five packets dropped in a row does mean that you have a significant network congestion event, and should drastically scale back your estimate.
Perhaps you could say that each successive dropped packet after the first dropped packet after a successful packet back down by 0.8 instead of 0.5, but you'd still need to back off significantly if you get a significant amount of packet drop.

Feel free to keep a "minimum accepted" level, and either not drop below that, or kick the user off if it cannot be maintained (with proper user messaging so the user knows what the problem is.)