HF-PEP: STANAG 5066 TCP Performance Enhancing Proxy Protocol (S5066-APP9) specifies a new protocol for efficiently running TCP over HF. This paper gives an overview of the requirements for this protocol and provides performance measurements and analysis.
The paper then looks at Web Browsing over HF, which is seen as a critical family of services operating over TCP. Measurements and notes on deployment are provided.
This section looks at how TCP and Web fit into a general strategy for providing applications and services over HF. STANAG 5066 is the open standard link layer for supporting applications over HF, and is the approach covered in this whitepaper.
Some mission critical applications define mappings directly onto STANAG 5066. There are a number of options for messaging protocols, as set out in Isode whitepaper Messaging Protocols for HF Radio. Performance of these protocols can give better than 90% link utilization as described in Isode whitepaper Measuring Performance of Messaging Protocols for HF Radio.
The approach for XMPP is described in Isode whitepaper Operating XMPP over HF Radio and Constrained Networks. This approach has been demonstrated in UK MoD trials to work well down to 300 bps, with low latency and high reliability.
These optimized protocols obviate the requirement to operate these services using generic capabilities, which would be significantly less efficient.
Most modern applications operate over IP. STANAG 5066 defines “IP Client” services for operating an IP subnet over HF, as shown in the diagram above. The approach is discussed in detail in the Isode whitepaper Measuring and Analysing STANAG 5066 F.12 IP Client.
The whitepaper shows that STANAG 5066 IP Client is a good approach for some low volume services such as ICMP Ping, and it works acceptably for some specialized military applications and services such as DNS Lookup.
Although STANAG 5066 IP Client follows the generic IP Architecture, the whitepaper shows that performance for TCP and bulk services in general is abysmal. Measurements from Measuring and Analysing STANAG 5066 F.12 IP Client are compared with the results in this paper using HF-PEP.
TCP is the dominant protocol for applications running over the Internet, and it is clearly important for HF to operate a range of standard and special protocols over TCP (e.g., Database Access).
HTTP (Web) operates over TCP. Many standard and most modern proprietary protocols operate over HTTP, rather than directly over TCP.
Support of TCP and Web applications is a key target for operation over HF and the subject of this whitepaper.
HF-PEP uses a PEP (Performance Enhancing Proxy) architecture, outlined in RFC 3135 “Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations”, to remove the inefficiencies of running TCP over STANAG 5066 IP Client. The overall architecture for using HF-PEP is shown in the following diagram.
In this TCP Proxy architecture, an application is communicating over TCP, running over IP in the normal manner. The TCP connection from each application is peered with a proxy, rather than the other application. The proxies communicate using the HF-PEP protocol specified in HF-PEP: STANAG 5066 TCP Performance Enhancing Proxy Protocol (S5066-APP9).
HF-PEP operates over SLEP (SIS Layer Extension Protocol), specified in S5066-APP3. SLEP provides the Stream Services used by HF-PEP. SLEP communicates over STANAG 5066, using the local STANAG 5066 SIS (Subnet Interface Service) to connect. STANAG 5066 peers communicate over an HF network, as shown.
The Proxy can multiplex TCP connections over a single HF link, so that a single STANAG 5066 SAP can be shared by multiple TCP connections and multiple applications running over TCP.
The proxy may control TCP applications based on port including:
A simple proxy may connect to just one peer and route all traffic to that peer. A proxy may connect to multiple peers and choose the peer proxy based on destination IP address of the destination specified in an inbound TCP connection.
Isode’s Icon-PEP product implements this architecture.
The above architecture is used to measure performance. Components as follows:
The following tests can be run from the LH Host:
STANAG 4539 emulation was used for speeds of 9600 bps and below. STANAG 5069 with 48 kHz bandwidth was used for the 240 kbps tests. All tests used short interleaver. Further details provided with the tests.
TCP performance was measured with a special test tool that opens a connection and transfers a specified volume of data to a responding tool, which measures latency throughput (based on time from initial TCP request to all the data being delivered. Data volumes are measured in kilobytes (kB). Data transfers of up to 10 MBytes were made.
The following tests were made over clear link for varying speeds and data sizes to provide a basic test of HF-PEP for a range of conditions.
Speed |
Size (kB) |
Utilization |
Connect Time |
Total Time |
Final Data Latency |
Close Time |
|---|---|---|---|---|---|---|
240 kbps |
1 |
1.8% |
1.9 secs |
1.9 secs |
1.9 secs |
4 secs |
240 kbps |
10 |
1.4% |
2.7 secs |
11.6 secs |
11.6 secs |
4 secs |
240 kbps |
100 |
25.7% |
1.9 secs |
12.9 secs |
12.9 secs |
4 secs |
240 kbps |
1,000 |
73.8% |
3.4 secs |
45 secs |
38 secs |
8 secs |
240 kbps |
10,000 |
90.7% |
5.4 secs |
367 secs |
166 secs |
3 secs |
9600 bps |
1 |
10.6% |
7.9 secs |
7.9 secs |
7.9 secs |
7 secs |
9600 bps |
10 |
29.3% |
8.2 secs |
28.4 secs |
28.4 secs |
7 secs |
9600 bps |
100 |
77.2% |
11.1 secs |
108 secs |
108 secs |
8 secs |
9600 bps |
1,000 |
90.6% |
12.9 secs |
919 secs |
579 secs |
7 secs |
9600 bps |
10,000 |
92.2% |
10.3 secs |
9037 secs |
606 secs |
7 secs |
1200 bps |
1 |
67.8% |
9.8 secs |
9.8 secs |
9.8 secs |
4 secs |
1200 bps |
10 |
80.9% |
21.2 secs |
82.4 secs |
82.4 secs |
3 secs |
1200 bps |
100 |
89.1% |
17.4 secs |
748 secs |
748 secs |
4 secs |
300 bps |
1 |
66.7% |
40.0 secs |
40.0 secs |
40.0 secs |
9 secs |
300 bps |
10 |
79.1% |
71.2 secs |
367 secs |
367 secs |
8 secs |
A number of observations are made on these results:
The following table provides comparative information when using STANAG 5066 IP Client. A detailed analysis is provided in in Measuring and Analysing STANAG 5066 F.12 IP Client. It can be seen that HF-PEP gives much better performance for all settings, and dramatically better for some settings. HF-PEP is not subject to the failures and degradation seen with IP Client.
Speed |
Size (kB) |
Utilization |
Connect Time |
Total Time |
Final Data Latency |
|---|---|---|---|---|---|
240 kbps |
1 |
0.3% |
11.5 secs |
11.5 secs |
0.0 secs |
240 kbps |
10 |
2.2% |
6.2 secs |
14.9 secs |
8.3 secs |
240 kbps |
100 |
8.4% |
12.6 secs |
39.8 secs |
9.4 secs |
240 kbps |
1,000 |
26.6% |
12.7 secs |
125 secs |
64.6 secs |
240 kbps |
10,000 |
7.2% |
3.8 secs |
4660 secs |
1119 secs |
9600 bps |
1 |
2.2% |
37.6 secs |
38.7 secs |
4.1 secs |
9600 bps |
10 |
17.5% |
26.9 secs |
47.6 secs |
24.6 secs |
9600 bps |
100 |
56.2% |
22.0 secs |
148 secs |
130 secs |
9600 bps |
1,000 |
80.7% |
27.9 secs |
1033 secs |
566 secs |
9600 bps |
10,000 |
Failed |
|
|
|
1200 bps |
1 |
17.2% |
30.9 secs |
38.7 secs |
9.5 secs |
1200 bps |
10 |
60.3% |
19.2 secs |
111 secs |
95.3 secs |
1200 bps |
100 |
74.9% |
19.3 secs |
890 secs |
548 secs |
300 bps |
1 |
32.2% |
48.7 secs |
82.9 secs |
55.1 secs |
300 bps |
10 |
39.4% |
110 secs |
677 secs |
603 secs |
Error rate tests were made at 9600 bps with 100 kB of data transferred, using different Bit Error Rate (BER) values for the link. These parameters are chosen, so that a direct comparison can be made with the measurements in Measuring and Analysing STANAG 5066 F.12 IP Client.
Error Rate |
TCP Utilization |
STANAG 5066 Utilization |
STANAG 5066 Protocol Overhead |
STANAG 5066 Turnaround Overhead |
STANAG 5066 Gaps & Padding Overhead |
STANAG 5066 Data Loss Overhead |
|---|---|---|---|---|---|---|
Clear |
77.2% |
92.1% |
2.6% |
5.3% |
0% |
0% |
BER 10-6 |
77.1% |
92.1% |
2.6% |
5.3% |
0% |
0% |
BER 10-5 |
76.1% |
88.6% |
2.5% |
5.3% |
0% |
3.6% |
BER 10-4 |
40.6% |
55.9% |
5.8% |
5.8% |
0.9% |
34.9% |
The BER range of 10-5 to 10-6 is a typical target for normal operation. BER 10-4 is to illustrate behavior in worse conditions.
The “STANAG 5066 Utilization” column was derived from the Icon-5066 logs for the long data transmission of each measurement. It can be seen that the TCP utilization is well aligned to the STANAG 5066 utilization. The STANAG 5066 overhead is broken into four groups:
These are seen as good results.
Web browsing was tested by using various Web browsers to connect over the simulated HF link to Web sites on the Internet in order to test use of HF-PEP with Web. The goal is to examine the viability of accessing the Web over HF.
Two Web sites were examined at three speeds using the Firefox browser, to give a direct comparison to measurements made for STANAG 5066 IP Client in Measuring and Analysing STANAG 5066 F.12 IP Client.
Site |
Speed |
HF-PEP |
IP Client |
|---|---|---|---|
example.com |
240 kbps |
11 secs |
26 seconds |
example.com |
57.6 kbps |
8 secs |
did not test |
example.com |
9600 bps |
18 secs |
4 minutes with one retry |
isode.com |
240 kbps |
4 minutes |
23 minutes to complete partial load |
isode.com |
57.6 kbps |
6:30 minutes |
did not test |
isode.com |
9600 bps |
10 minutes to complete partial load |
failed |
Partial loading is discussed in subsequent sections. It can be seen that HF-PEP gives dramatically better results than STANAG 5066 IP Client. It is clear that HF-PEP is the better way to support Web browsing over HF.
Typical Web sites are built using many files (HTML, CSS, Javascript etc) that are retrieved. When accessing a Web page, a browser will start to retrieve files, which in turn point to other files. Files in modern websites are generally protected by use of TLS, which needs extra protocol for each retrieval. A Web site will typically have files referencing multiple domains (e.g., to load standard scripts and fonts).
Browsers will generally open multiple TCP connections to retrieve elements of a Web site in parallel, but will generally limit the number of TCP connections used.
Web browsers do not typically work by ensuring that all files of a Web page are retrieved. They will retrieve files incrementally, and then render the files that have come back as best they can. This can lead to partial loading, where some files (typically large graphics) are not loaded.
The low speeds provided by HF have a significant impact on performance when accessing standard sites, as graphics and other large data blocks are commonly used. However, the impact of “hand shaking” is often more significant due to the high latency of data over HF. In the above measurements of example.com, which has very little data on the site, performance is limited by latency.
Some specific points are noted:
The detailed way that a browser behaves has potential to make significant difference to performance of Web browsing over HF. To optimize performance for browsing general purpose Web sites at narrowband HF speeds, it is likely that a tuned browser will be needed.
Most testing was done using Chrome and Firefox. Some tests were tried with Opera, which did not offer better performance and might be inferior.
Much testing was done with Chrome, which works reasonably well. At 9600, partial loading is observed quite a bit. There is no option to configure timeouts in Chrome, so performance has to be accepted “as is”. In practice, Chrome appeared the better option.
Firefox also works reasonably well. It’s partial loading behavior appears slightly better than Chrome. However, it appears to retry loading in a manner which means that a lot of redundant traffic is created. At 9600 bps, Chrome was faster than Firefox to complete a partial load of isode.com (4 minutes vs 6:30 minutes). Firefox led to HF traffic for many minutes after the partial load was completed. In both cases, the isode.com site was quite usable, although it was not presented as designed.
Firefox provides extensive customizability of timers. Some experimentation did not lead to improvements over default behavior. There appears to be potential for tuning.
Further browser testing is desirable.
The Web site a-k-apart.com hosts a competition to prepare websites with less than 10 kBytes data on the initial page. This was helpful for testing at 9600 bps. Some of the sites loaded quickly and fully, but not all of them.
Tests were made on three general websites, with results below.
Site | Speed | Browser | Initial Load | Full Load |
|---|---|---|---|---|
isode.com |
240 kbps |
Firefox |
1:40 |
6:30 |
isode.com |
57.6 kbps |
Firefox |
3:50 |
6:10 |
| isode.com | 9600 bps |
Firefox |
5:00 | 10:00 (partial) |
240 kbps |
Chrome |
0:30 |
1:20 |
|
57.6 kbps |
Chrome |
0:40 |
2:30 |
|
9600 bps |
Chrome |
1:30 |
8:20 |
|
Wikipedia |
240 kbps |
Chrome |
0:30 |
1:20 |
Wikipedia |
57.6 kbps |
Chrome |
0:40 |
3:40 |
Wikipedia |
9600 bps |
Chrome |
2:50 |
8:30 |
The initial load time was when the screen showed the core information on the page. Full load was when the browser declared load complete, after graphics and other information was loaded.
A Google search of “NATO” was made. At 9600 bps, a partial load missing some of the graphics occurred.
The Wikipedia NATO page was viewed. At 9600 bps, many of the graphics did not load.
This suggests that at higher (WBHF) speeds, that browsing many standard Web sites is viable, although slow. At 9600 bps (top narrowband speed), some operation is still possible.
It is not anticipated that general purpose Web browsing will be the primary target of Web over HF. Consider a Mobile Unit (e.g., a ship or plane) communicating with shore systems. For many applications, “push” communication such as email will be ideal. However, Web access can complement this, enabling the Mobile Unit to have “pull” access to selected information and resources. It is anticipated that the shore systems would provide Web sites optimized for Mobile Unit access. This section provides some recommendations for such a site:
This paper has shown the HF-PEP is an effective way to support TCP connections over HF, and that optimal use is made of the HF link using STANAG 5066 for a wide range of transmission speeds and transfer sizes in a manner resilient to HF errors.
HF-PEP provides a viable way to perform Web Browsing over HF. This can work with general purpose Web sites, but it is anticipated that special Web sites will be built for HF operation.
Recommendations to NATO: