Rutkowsa's RP/BP doesn't apply to what the initial question needed answered. I've spoken with people about her theories via the Daily Dave list once upon a time (
http://seclists.org/dailydave/2008/q4/author.html) which is how I derived: "plague" which is a proof of concept undetectable backdoor. This came about after the Matasano/Rutkowska/etc. challenge. (
http://www.darkreading.com/security/security-management/208804717/index.html) This came about when they offered like a $100,000 challenge to put up or shut up... I joined in on the fray and asked Peter Ferrie if I could join, submitted my PoC and they said no

Anyhow, apples and oranges. It's actually easy to detect if you're on a virtual machine that's not the issue. Detecting it FROM the network is an issue. Timing and latency have little to do with anything. For example, 1) if I semi-flooded all the machines with traffic, your timing theory is thrown out the door. 2) If I changed my TTL responses on each machine, that too is thrown out the door.
For the most part, there isn't an effective way of remotely determining whether or not the remote machine is running on a VM image. If it's on your RFC1918 space, it would be easier, but if I decided to do some NAT voodoo and place a VMWare image from ONE address block, say in England, mapped it via tunneling to an American IP space... You'd never know where that machine is/was. Please see:
http://www.mail-archive.com/nanog@merit.edu/msg52017.html to validate/confirm/understand this.
Just doing NAT alone adds ms overheard as would traversing networks. Throw in a firewall, some IDS and your entire fingerprint is out of whack.
The reason I mentioned the conflict, is that, the original poster might be interested in researching and extending the techniques used to detecting the presence of a VM from OS level to the network level.
I knew network latency is not the only thing that is going to hamper the technique thats why I blew my own theory in the post. I just wanted to point out something that can be extended. For instance, what If there is a behavior in a particular VM package that takes notably long time to respond to a specially crafted packet but the delay is not good enough for a detection technique because of other factors like network latency..
Every detection mechanism has a reliability factor (OS detection, service detection etc). If someone is determined to protect the identity of OS/Service from popular tools he/she can. Neither detection nor protecting from detection is 100% possible. Is there a reliable way to determine the OS in a network 100% of the time? No not possible. I was going for something thats detects a VM in a network starting from a theoretical point of view and then that can be practically extended.
I am not proposing a solution, I am pointing to something that can be researched and extended.