Windows application developers building video telephony or networked phone applications will get a boost later this year with the release of the software development kit for WinSock version 2.0. The latest version of the ubiquitous Windows programming interface for network connections will support the ReSerVation Protocol, RSVP, an Internet Engineering Task Force draft standard that […]
Windows application developers building video telephony or networked phone applications will get a boost later this year with the release of the software development kit for WinSock version 2.0. The latest version of the ubiquitous Windows programming interface for network connections will support the ReSerVation Protocol, RSVP, an Internet Engineering Task Force draft standard that is expected to be ratified this autumn. The protocol provides applications with a standard way of communicating with network routers to request particular classes of services. Examples might be constant bit-rate or guaranteed delay. The effort is part of a larger multimedia networking project going on at the IETF, covering Quality of Service. This includes a multicast routing protocol that establishes the path the data will take; an admission control module to manage network resources and a packet scheduler that orders packet transmission to meet the quality of service established by the admission control. Two of the biggest router manufacturers; Cisco Systems Inc and Bay Networks Inc have announced that they intend to have Quality of Service implementations by the end of the year. Transmissions across the network are termed flows in quality parlance and Winsock 2 attempts to describe flow characteristics in a number of ways. The Source Traffic Description describes the way the application’s traffic will be injected into the network, including things like peak bandwidth. The second measure is the latency, specifying the upper limits on the amount of delay and delay variation that are acceptable. Third is the level of service guarantee – whether or not an absolute guarantee is required as opposed to best effort. Providers that have no feasible way to provide the level of service requested are expected to fail the connection. One obvious question is, why won’t every application demand an absolutely guaranteed level of service from the network, invalidating the whole idea? The answer is that guaranteed bit-rates do not always give the best results.
Fail the connection
The WinSock 2 specifications defines three levels of service, Guaranteed, Predictive, and Best Effort (the last being equivalent to today’s TCP/IP routing policies). The reason for defining both predictive and guaranteed service is that predictive one may achieve substantially better performance given the same level of network resource usage, while guaranteed service provides the mathematical level of certainty needed by some applications. In addition to the application being able to specify its requirements to the network more accurately, the network can also pass information to the application about its own loading, so the application can make intelligent choices about its data handling. Moreover, if congestion suddenly mounts in the middle of a session, the network can tell the application about it and try to re-negotiate quality of service levels. The new specifications are available today on the Intel Architecture Laboratory pages on Intel Corp’s Web server (www.intel.com). A software development kit is expected to ship in early autumn. Before then, Scotts Valley-based Syzygy Communications has added RSvice-president support to its existing, proprietary Network Quality of Service Solutions software. The software adds Quality of Service support to Winsock 1.1, for any authors who want top get a taste of the future. The company said it has been working with the likes of Starlight Networks Inc, Intel, PictureTel Corp, InSoft Inc and InVision Systems Corp and that its redirector software provides standard Quality of Service application programming interfaces for developers to write to.