How does TCP's slow start handle a send rate below network capacity?

Question

I'm working on a UDP-based project that requires congestion avoidance. After studying the algorithms used by TCP (example sources here and here), I have what I believe is a reasonably compliant implementation of the slow start and congestion avoidance states of TCP Reno. However, while testing I have observed the following surprising behavior:

1. Say the sender opens a new connection, and sends data at a constant and sufficiently slow rate such that no packets or acknowledgements are dropped. In slow start, a typical sender will increase cwnd by the number of new acknowledged bytes for each acknowledgement that it receives (see RFC5681, section 3.1). Thus, in this scenario, cwnd will increase linearly without bound.

2. After some time has passed, say the sender suddenly has a trove of data to send. If a sufficient amount of data has already been sent at that slower rate, cwnd will be much larger than the true network capacity, and the sender will flood the network with packets.

Considering how much effort has been put into avoiding such floods, I don't think this is the intended behavior. Have I overlooked something?

---

Idea 1: Idle conditions will cause the sender to restart in slow-start, but this is generally avoidable so long as the sender does not wait more than 1 RTO between packets (see RFC5348, section 4.1). Furthermore, RTO should be rounded up to 1 second (see RFC6298, section 2), and so this mechanism can be circumvented by sending one small packet every half second.

Idea 2: TCP Friendly Rate Control (RFC5348) has a notion of "data-limited intervals", and TFRC has been designed so as to mirror the behavior of TCP. I suspect there might be special behavior related to TCP being data-limited, as opposed to congestion-window-limited (part 1 is an example of such a scenario), but I have yet to find such behavior defined anywhere.