Question: In some cryptographic protocols I have seen messages protected for confidentiality, authenticity, replaying attacks, reordering attacks, etc. 

What protects a protocol from an attacker in a privileged network position (e.g. in control of a majority of the fibre networks connecting countries) from just dropping messages altogether, thus stopping the two parties from communicating (a *“Denial Of Service”*)?

For example: if a protocol includes a sequence number, the receiver sees messages `#233`, `#234`, and `#236`. What should the receiver do if they missed receiving the `#235` message?

Answer: 
Message sequencing AND hash-tabling for a trail of backward messages. The loss of a single message is not a disaster, actually. To be not over-paranoid, implement "resend request" in your protocol. If it works and hashes are matched - it can be just a communication error. But if it fails - a line should be dropped immediately. Try to use Tor by the way, and when requesting a re-send use a different chain. That will help you greatly with low implementation costs
Assuming that your question excludes any kind of “regular” transmission error (which might also lead to one of the messages not reaching the receiver) the receiver should regard message #236 to be potentially malicious since the “ticket” (what you call “sequence number”) for message #236 can not be verified as genuine. 

The specific reaction to such a detection will strongly depend on the individual scenario, protocol goals, and its implementation. In most cases, receiver would (immediately) drop the established communication, regarding message #236 to have potentially been modified by an attacker. If possible, sender and receiver could/should restart the protocol from scratch (including authorization etc.). 

Under no circumstances should message #236 be trusted. 

The reason is simple: in the described situation, the ticket for message #236 is (let’s just call it) “out of sequence”, which *practically breaks the protocol*.

Otherwise, there wouldn’t be much reason to use those “tickets” in the first place. The main reason for their existence within certain protocols is to be able to detect (among a few other things) the situation you described, and to react accordingly by not trusting messages that are “out of sequence”.