TCP is a symmetric protocol which has built-in support for failures through re-transmissions. For every packet of data that has been sent to you from the server you are downloading from, it expects your computer to return an acknowledgement packet confirming that it has received that piece of data correctly. If it doesn't, it will re-transmit it back to the client on the assumption that somewhere along the line it was dropped before the client ever received it.
This acknowledgement can be piggybacked on data the client uploads back to the server, but in the case of HTTP downloads (or most large downloads), there is nothing to send back to the server once the download has started, so an "empty" packet with an acknowledgement in the header will normally be sent. So, to "download" a packet, you must "upload" a packet to "download" the next.
If you saturate your uplink and fill the outgoing buffer of the router full of data, then the packet your returning to the server will be stuck behind all this data. Most consumer connections are asymmetric (downloads are faster than uploads) as they work on the principal that most people will download far more than they upload. This is typically fine: You're looking at around a 35:1 ratio in download packet size verses upload (acknowledgement) packet size, depending on the type of connection you're using.
This has the size effect that when your upload buffer fills, it will take longer to clear than anything in the buffer for downloads at the ISP side. This means your download link will download everything well before the uploads have finished causing your download link to pause as it waits for more data. You effectively reach a point of symmetry: One packet up means you can get one packet back down again and gives you the result you see when trying to download while you upload at the same time.
TCP does have a concept of a "window size." This is the allowed amount of data that the server can send before it requires an acknowledgement from the client to allow it to send more. This can help in some situations, especially with smaller downloads, by allowing more data to be sent in one go, but you are still limited by the returning acknowledgement packets for larger or longer downloads.
So long as one buffer is full (and this will typically be the upload buffer before the download one), the other side of the connection will be limited.
There are some tricks around this, such as smaller buffers (can slow down a connection, but make it more responsive), Quality of Service rules (to better prioritise packets being uploaded, re-arranging the order in the buffer to making larger upload packets wait behind smaller ones), or limiting the upload speed to below the limit to better manage buffers.