One thing I never understood is how you can guarantee consistency in distributed transactions given this problem. Can you really build a 2-way ACID system, or is only "eventual" consistency achievable?
A special case would be if the network is broken only in one direction. In that case, the same command may be sent multiple times, but even this is not a problem, since the 2PC commands are idempotent (e.g. receiving the Commit-message multiple times won't hurt, since the receiving node knows that it has already committed the transaction).
A trivial commit protocol that is consistent but not live simply sends no messages. All updates that succeed are consistent, but no updates succeed.
An eventually consistent protocol is often correct for stronger consistency guarantees, but instead sacrifices consistency in the case of network problems rather than liveness.
(sidebar: this is really what the CAP theorem is driving at. You must choose between consistency and liveness if the network can lose messages).
http://en.wikipedia.org/wiki/Paxos_algorithm
(Bigtable uses 'Chubby' - google's implementation of Paxos)