it wouldn't overwhelm it, TCP will quickly realize and get the flow set to 20 mbps so its utilized, but not overwhelmed. when a 2nd data stream is introduced to the flow, TCP will get pushbacks to its layer session controls and cause the streams to fall to 10 mbps each, this will continue to split down until the packet sizes begin to shrink to fit in the stream, your available bandwidth per stream will fall as expected to that individual customer but the link doesn't become overwhelmed until it is unable to collect frames in the radios buffer and has to start sending pauses or dumping packets. each radio will handle a different mix of steams and packet types before becoming overwhelmed and with good QoS controls and a solid MAC can keep on overwhelmed link kinda usable.
the pause frames get sent when the ETHERNET side of the radio becomes overwhelmed and can't cache anymore in the radio.
for example, a EPMP sync ap with MCS 15 to 50 different subs. assume everything is perfect, no noise, no NACKs ect. all customers are set to 20 meg service.
the radio can deliver 170 ish megs downlink to the subscribers. lets also assume that this is the only active AP on a tower being fed with a 300 meg backhaul.
all 50 subs begin to start a single session file download all at the same time. you've got a situation that your radio cannot supply 50 people with 20 megs of service each. the radio would be at "capacity" but not overwhelmed. the customers will 3.4 mbps on average each. which is significantly less than the assigned rates. in this situation you will likely not see any pause frames fire, or very few. the reason being the radios TDD mechanism will cause enough delay in the layer 3 session controls that the sending side won't try and send 300 meg based on the delay in the handshack process. it will start some place in the middle, the next packet group will also have a reasonable delay on the path and will further reduce the data rate being sent along the stream. once the TCP session controls have a good idea of an acceptable information rate, it will attempted to continue to provide that rate. since all of these data streams experience the same latency being implemented on the first few packets, they all will see the need to slow down and the regulate the data flows. most of the speed adjustments and delays are done within the AP and the first few very high data rate packets that came in, are slowed down in the APs buffers, which cause the delay going back to the original source of that data download. the reason the link isn't actually overwhelmed is because of the packet scheduler. yes this situation is clearly over subscribed, but your radio will only have 100 sessions active, not exceeding the packet rate of the radio, likely not over flowing the buffers thanks the internal delay in the data rate. this is part of the magic of using a TDD radio with a solid MAC layer that includes a good packet scheduler.
the same situation on a wifi MAC or polling based MAC wouldn't work out so well. since the MAC isn't as controlled and defined delays that are dictated by the AP the ACKs that go all the way back to the source would be less aligned and consist which results in unstable latency, which in turn causes information rates to fluctuate and in turn causes to fast of streams to hit the AP, resulting in Pause frames being sent. reducing the overall actual usable throughput being sent down the link. now add in a few of the other eliminates that can happen in a polling environment, like a NACK out of turn, and you've got a possible snow ball effect that will cause pause frames to be kicked. when the polling radio has free air time, this likely will be fine, but with full air time, comes chaos. (that why some systems turn down hill all at once rather than slowly)
smooth constant latency that's introduced with a pre-mapped out schedule like wimax, LTE, epmp, cambium mac will cause more effective use the TCP session controls than a poling system which produces more wild shifts in latency, which intern causes a lot of fluctuations in the data flows that hit the AP before hitting the air interface...
the radios become overwhelmed with they're buffers spill over and discard and or pause packets.
overwhelmed in a wifi situation, happens significantly sooner than overwhelmed in a good scheduled TDD MAC