V.92 V.92 FAQs  About V.92
About V.92

  Components of V.92  
  Handshake Sequence  
  Quick Connect  
  Modem-On-Hold  
  PCM Upstream  
  V.44 Compression  
  NetWaiting  
     

What is V.44 data-compression?
V.44 is a new data-compression protocol that delivers data rates 10 percent through 120 percent faster than those achieved by the existing V.42bis compression protocol.

The most popular activity on the Internet is browsing, and this is where V.44 delivers the greatest improvement over V.42bis, so users can enjoy speeds up to 120 percent faster than with the older protocol. Popular sites such as Amazon.com and eBay use highly compressible HTML files, so online shopping is faster than ever. V.44 also increases data throughput for email (by 27 percent), Word documents (by 21 percent), Power Point files (by 10 percent), and C source files (by 45 percent).

Client and server modem software require an update to support V.44, compliance with this standard will vary by region and service provider.

V.44 Background
Voice band modem technology provides the most ubiquitous data communication method on earth. But this ubiquity has its limitations. Because of the severely limited bandwidth and the widely varying quality of this bandwidth, data rates are slow relative to broadband channels. As a result, every byte sent across the channel is precious.

Early in the development of modem data technologies, it was recognized that one of the best ways to optimize the amount of data transferred across this narrow channel was to compress the data immediately before sending it and having a matching decompression on the other side of the link. A number of data compression standards were developed over the years. The V.42bis standard became the method most widely used.

In order to make the compression techniques as widespread as possible, the compression engine is pushed as low in the OSI stack as possible, to just above the link layer. In this way, all kinds of applications benefit from the compression without having to worry about implementing it separately in every application for different operating systems on different platforms. This pushed the V.42bis compression algorithm to be implemented directly on the modem itself, rather than on the host processor.

As a result, compression algorithms need to have the following characteristics:

  • Low processing load—the processors used to control modems are low complexity microcontrollers
  • Low memory requirements—to bound the cost of modems, the memory sizes are kept small
  • Low latency requirements—to make sure that applications such as gaming and telephony are possible, the amount of time to go through the encoder and the decoder on the other side must be very small. V.42bis became and is a widespread standard in the voice band modem area


Hughes Network System encountered a similar problem with precious bandwidth when it implemented its VSAT and DirecPC products. Hughes implemented a compression algorithm that has many of the same constraints as voice band modems. This algorithm is ideal for packet networks and has been deployed and executed worldwide in HNS satellite networks. Late in 1999, Hughes offered its compression algorithm as an alternative to V.42bis in public communications standards bodies. This algorithm was reviewed by the American and International communication standards bodies, and adopted as a new compression standard called V.44.

Choosing Files to Compare
Choosing files to compare two algorithms always creates acrimony. There are contrived files that show off one algorithm over another. However, most modems today are used to access the Internet. The most meaningful files to compare performance of two algorithms are those typical of Internet usage.

Files examined here are considered typical of an Internet session, some contrived files, and ones based on files create by standards testing bodies:

  • Webfile: a file consisting of the captured downstream data from a web browsing session created by ADI – This stream went into map.com, so there are lots of images
  • Websurf: a file consisting of the captured downstream data from a web browsing session created by HNS. Browsing was mostly cnn.com, yahoo, etc. Intended to capture a typical Internet browsing session
  • Amazon.ts6: eight web pages from Amazon.com searches merged together with 20 K of random images data between each page
  • Mail.txt: A electronic mail file was created consisting of the following:
    1. Jokes received from a friend (pretty bad ones at that). All subjects, typically about 2,000 to 4,000 bytes each
    2. TR30.1 meeting notices and some mail
    3. Mail with attachments:
      • LZJH C code
      • LZJH Study Group 16 contribution Word document
      • RTF Document
      • Other Word documents
  • Big1.tst, Big2.tst, Big3.tst: created by replicating the TSB38 standard test file BIG1, BIG3 and BIG5 respectively many times
  • Ebay.ts1: several web pages from eBay.com while searching for sports collectibles
  • Cdsearch.tst: results of an artist search from an online CD music store
  • Maxlen.tst: 255 A's, then 255 B's, etc. to test string extensions. All possible 8-bit characters are duplicated 255 times. This file is a contrived file that stresses the compression algorithms.

These files were developed to emulate the type of data transferred over the Internet in a typical session, and to include some files used in standardized testing of communications systems.

How Does V.44 Stack Up?
Table 1-1lists the results of running the files mentioned above through three different compression algorithms: V.44, V.42bis, and WinZip.

What Does This Mean for Me?
In Figure 1, V.42bis is normalized to 1. The graph illustrates that V.44 has 12 to 230 percent better compression ratios than V.42bis on the same files. This means that a V.92 modem with V.44 included would effectively run 12 to 230 percent faster than one with V.42bis. This improvement is significant, and similar to the improvement seen when going from V.34 modems to V.90 modems.

Can’t We Do Better Than That?
But this graph also shows that WinZip has much higher compression ratios. Why not just use the
WinZip algorithm and be that much better? Remember the limitations stated in the introduction:
Limited processing horsepower, limited memory, low latency. Because the WinZip algorithm runs on the PC, it has access to a very powerful processor and a lot of memory. It can look at very large chunks of data because of all of that memory. Also, because WinZip essentially is a batch process, and not done in real time, there are no latency requirements. It can take a long time looking for similarities and compressing optimally. In addition, the WinZip and other similar algorithms do a two-pass compression. This is not possible with streaming data, because the modem compression algorithms never see the entire file – only pieces as it streams past. So V.44 shows a very good improvement over V.42bis while having similar processing, memory and latency performance. The compression ratios found in PC standard compression programs cannot be reached with streaming data.

What Does This Mean for Me?
Let’s assume that V.44 delivers a 26% improvement in compression rates over the existing V.42bis compression method. If you were connecting with a V.90 modem at 44 Kbps with V.44, your effective data rate would be the same as if you could connect with that same modem at 56 K. If you were connecting at 28.8 K with V.42b, with V.44, you would have the equivalent performance of 36
Kbps. Clearly, V.44 provides a next level of performance for voice band modems.

· top ·