Maurice - Some random comments in the interest of exciting conversation:
First, I think you are missing one of the main points when it comes to data and delay. Believe it or not, the proximate issue isn't what delay you, as a human, can put up with. Its what the existing apps can deal with. For instance, long delays often imply large variation, and many protocols, such and video and fax, aren't very good at dealing with such variation.
Second, while it is certainly true that many modern packet systems work on a system of priorities, you shouldn't expect a small price differential for Variable Bit Rate - non real time (VBR-nrt) vs VBR-rt. This is true for a variety of reasons, but among them are:
1) Typically rt users also want tightly controlled variation in delay.
2) The combination of small absolute delays and low variability often means that the transmission medium must go with some un-used space so that when all of those VBR-rt happen to burst at once, ... . Now you might think that you could just load up the resulting empty spaces with low priority traffic, but then what do you do with the them when everything is being used. Queue it up? ... but this then results in weird network control issues (ever watched traffic on a freeway - why does it always move in clots? - Imagine the complexity in managing a freeway system where the high priority drivers can coopt the whole freeway.)
Bottom line - it is certainly reasonable to expect pricing differential based on priority, but don't expect it to be a small one. I'd guess a factor of many (4 or 5 (A WAG)) times from the lowest to highest priority. At that differential, I'd prefer to wait the 1/2 second unless the app just couldn't deal with it.
Clark
PS I know just enough about this at this point to be dangerous. So take the above with a grain of salt. |
