Earlier quoted context omitted.
When the internal receiver buffer is full, you drop the frames. Basically any protocol out there has some way of dealing with dropped packets (including UDP's "don't care") DHCP requests are usually repeated several times for this reason, the first one can get lost (this can and will happen even on a clean and underloaded gigabit homenetwork)
Well if it dropped the frames and it kept getting hammered then multiple repeats would still not have any real chance of getting through (like 5 repeats over 5 seconds would be completely swamped by the literally million of frames it could get at the same time) Traffic shaping on higher layers usually lets some packages deemed important through while dropping bulk traffic, tcp which is usually used for bulk transfers…
Not if, it does. The repeats are usually good enough to get into the receiving buffer. If there is constant noise on the interface that it even interferes with basic protocol operation you're probably running something that doesn't know how to throttle the connection properly. Those things are usually best retrofitted with some form of ratelimiting in the kernel.
But yes, in this case you wouldn't be able to do DHCP or ARP. This is also true for any further hops on the network. If the receive buffer is full there isn't much you can do about it other than try again later. And "try again later" is purely a protocol decision.
On an internal network the fix is usually to have a Switch that can ratelimit a peer. Otherwise, there is no protection and you can easily replicate the effect by taking an old switch and patching up a loop. The resulting packet storm can easily shut down larger networks.
On the larger internet, the telco's and ISPs are largely responsible for making sure their receive buffer doesn't get full.