What's the consequence of having a short IV? Is one mode better in that case?
The point of the IV is to prevent the same (key,IV) from ever being used for two different messages in practice. This is an absolute requirement for stream ciphers or block cipher modes such as CTR that are effectively stream ciphers, because re-using the same (key,IV) pair lets an eavesdropper trivially obtain the XOR of two plaintext messages, which means they are effectively decrypted. Other modes behave somewhat differently, but the IV requirements for a mode are generally non-negotiable, and security is broken if they are not followed.

With a smaller IV, the chances of using the same (key,IV) go up dramatically. Hashing a low-bit value as you suggest does not fix this problem at all, as there are only 65k IVs possible with a 16 bit counter.

If your application cannot handle transport of at least 96 extra bits with each message, you should exchange an "IV seed" at the start of your protocol, then each side can use that as the state for a CSPRNG and generate the IV for each packet on its own. Using something like HASH-DRBG is probably simplest, you start with your IV seed, concatenate a counter with value N, hash and use the output as the IV for packet number N.
Making this scheme tolerate packet loss while never ever repeating (key,IV) is left as an exercise for the reader; see the ChaCha TLS draft RFC as an example of how packet sequence numbers are used to generate IVs.
http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02