This document was written in about 2009. Since then, client-server communications options for the web have developed and may now be a viable transport, though still with some tradeoffs and overhead vs. plain VIP.

VOS Infrastructure Protocol

VIP stands for VOS Infrastructure Protocol, and is a transport-layer protocol similar to TCP, but specifically provides for low latency sending of small messages while simultaneously also allowing for other types of data transfer (such as large file download/upload) over the same logical connection. This attempts to provide quick communication for wide-area interactive use, as well as improving local network utilization in high-traffic situations. (Or what you may be thinking of as a "bandwidth" problem, even when more stricly speaking, simple bandwidth capacity is not the actual or only problem.) 

VIP is not specific to VOS (and thus may be useful for other applications) but was developed because VOS demanded specific features from the transport layer that were not found in any other available protocol.

VIP was designed and implemented by Peter Amstutz

VIP is data (payload) format agnostic. VOS uses it by serializing VOS Messages (the contents of which are defined by object types, e.g. the [[A3DL]] object types for 3D graphical objects) (see Manual) or [[Compact_Object_Description]]s.

VIP is written in standard C++ and consists of approximately 2,000 lines of code. It depends on VUtil from VOS (for reference counting and a few other small utilitites), boost_threads, the STL and OS (Linux or Windows) IP sockets implementation.

Problem statement

Why not use TCP?

  1. Head of line problem: large downloads takes time, data sent after the download is "stuck behind it" until the download finshes sending; unsuitable for interactive sessions
  2. Send every byte problem: once data has been committed to the OS to be sent, no way to revoke sending it (for example, because the unsent data becomes out of date and it would be more efficient to only send the most recent data)
  3. No priorities: can't ask TCP to send data out of order because there is some new data that should preempt the data already in the send buffer
  4. TCP doesn't care about latency: it will happily delay sending out your packets (Nagle algorithm), delay sending ACKS (cumulative acks) and (by design, to maximize average throughput) will happily fill up the buffers of every router between you and the remote host (which are often needlessly large, this is "bufferbloat"), which has the side effect of significantly increasing the effective latency of each individual packet. This can especially be bad over wireless networks, and last-mile residential connections (cable/DSL).
  5. We did try it (the TCP VOS protocol is called VOP and is still supported in VOS through the LocalSocketSiteExtension) and encountered all these problems!
These problems may also apply to any connection that is routed through a network link that forces all data through a single serial stream, such as any TCP protol based tunnel (e.g. HTTP tunnel), a point-to-point radio or satellite link, a modem, etc.

TCP Workarounds

All of these approaches are still using TCP, with the associated problems as described above.


Desired VIP Features:

  1. Have a single connection with multiple simultaneous prioritized channels
  2. Support different sending algorithms for different channels (with different performance characteristics) for within the logical connection
  3. Be able to cancel messages that have been passed to the transport layer but not yet sent/acknowledged, and replace them with updated data
  4. Model the network capacity between the local and remote hosts, and schedule packet sending so as not to overwhelm network buffers

How does it work?

Low-Latency sub-protocol

Standard sub-protocol

Other sub-protocols

Packet Scheduling

  • low latency packets want to go from end to end in least possible time
  • VIP explicitly models queuing in order to avoid creating congestion
  • tracks count of "in-flight" data (bytes which may still be in the network)
  • standard protocol computes congestion window
  • to make low latency packets actually low latency, the network must not be congested
  • thus, the standard protocol must stop sending for some time prior to sending the low latency packet, in order to let the network buffers "drain out"
  • because the low latency protocol has a heartbeat, standard protocol sends inbetween heartbeats
  • VIP computes "CANSEND" which is the estimate of how much data we are allowed to send, such that it will have been transmitted completely through the network by the time we are ready to send a low latency packet
  • end result: VIP makes it possible to have a large-scale transfer take full advantage of available bandwidth, but with having a negative impact on the latency of packets scheduled with the low-latency protocol

    VIP Performance Test Results

  • VIP Implementation

    Discussion and requests (won't go into the final doc)

    Request: from looking at ter'angreal, I assume there is a way to interact with vip from vos - as in "get me the value of this property, but via standard subprotocol"; "send this message via low-latency subprotocol". If I'm right, please document the APIs to do that. If not, please point to why not and how to achieve the desired effect instead :-) -- Lalo

    --> Yeah, there's not much at the application level (Property class) like that, but you can set the "priority" of a Message object to Normal, LowLatency or Bulk. I expect that individual [MetaObject] classes like Property will expose that to applications when appropriate, (or we could add a method to the MetaObject class to set the priority for all messages sent by that object...). I expect more features of VIP to be exposed at the VOS and application (MetaObject) levels as needed in the future as well. -reed

    --> The property class has a "setPriority" method on it which determines what priority the property read/write/update messages will be sent with.

    You're right, I will add a section describing how VIP fits into VOS. -- Pete