ETSI TR 102 676 V1.1.1 (2009-11)

Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia (BSM); Performance Enhancing Proxies (PEPs)

DTR/SES-00294

General Information

• Status: Published
• Publication Date: 26-Nov-2009
• Technical Committee: SES BSM - SES Broadband Satellite Multimedia
• Current Stage: 12 - Completion
• Due Date: 20-Nov-2009
• Completion Date: 27-Nov-2009

Standards Content (Sample)

ETSI TR 102 676 V1.1.1 (2009-11)
Technical Report


Satellite Earth Stations and Systems (SES);
Broadband Satellite Multimedia (BSM);
Performance Enhancing Proxies (PEPs)

---------------------- Page: 1 ----------------------
2 ETSI TR 102 676 V1.1.1 (2009-11)



Reference
DTR/SES-00294
Keywords
architecture, broadband, IP, management,
multimedia, satellite
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2009.
All rights reserved.

TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI TR 102 676 V1.1.1 (2009-11)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 9
4 Need for PEPs in BSM networks . 10
4.1 Performance improvement using standard end-to-end techniques . 10
4.2 Motivation for using PEPs . 10
4.3 PEP terminal architecture and components . 11
4.4 PEP scenarios . 13
4.4.1 Scenario 1: Single user . 13
4.4.2 Scenario 2: Independent satellite and PEP gateways . 14
4.4.3 Scenario 3: Multiple PEP Gateways . 15
4.4.4 Scenario 4: Integrated PEP (single PEP) . 16
4.5 Cross layer improvements . 16
5 Security impact on Performance Enhancing Proxies . 18
5.1 Previous research work related to PEP security . 18
5.2 Security solutions for BSM PEPs . 19
5.2.1 Interworking between PEPs and transport/application layer security systems . 19
5.2.2 Interworking between PEPs and IPsec. 20
5.2.3 Interworking between PEPs and link layer security systems . 21
5.3 BSM link layer security architecture suitable for PEPs . 22
6 Analysis of PEP deployment impact on current and future BSM architecture . 23
Annex A: End-to-end options and improvement techniques . 24
A.1 TCP end-to-end techniques . 24
A.2 Application layer end-to-end techniques . 24
Annex B: PEPs options and improvement techniques. 26
B.1 PEPs types and classifications . 26
B.2 TCP PEP (T-PEP) techniques . 27
B.3 Application layer PEP (A-PEP) techniques . 29
Annex C: Summary of techniques used by PEP manufacturers . 30
Annex D: Examples of distributed and integrated PEPs . 31
D.1 Application layer PEP: Hughes HPEP . 31
D.2 Distributed TCP PEP: Satlabs I-PEP . 32
D.2.1 TCP Noordwijk . 34
D.3 Integrated PEP: PEPsal . 35
Annex E: Example cross layer improvement for FTP data flows . 38
ETSI

---------------------- Page: 3 ----------------------
4 ETSI TR 102 676 V1.1.1 (2009-11)
Annex F: Bibliography . 41
History . 42

ETSI

---------------------- Page: 4 ----------------------
5 ETSI TR 102 676 V1.1.1 (2009-11)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Satellite Earth Stations and
Systems (SES).
Introduction
The present document presents an overview of PEP issues over satellites and focuses on BSM-related issues. It is based
on current ETSI BSM architecture documents [i.1] and [i.2]. Also it is aligned with the relevant IETF standards. The
IETF documented general PEP issues are described in RFC 3135 [i.3]. However, RFC 3135 [i.3] is not satellite specific
and, more importantly, is now seven years old.
Also the present document is aligned with the Satlabs group solution called Interoperable PEP (I-PEP) that is aimed at
DVB-RCS systems [i.4].
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TR 102 676 V1.1.1 (2009-11)
1 Scope
The present document aims to describe the current solutions for Performance Enhancing Proxies in broadband
multimedia satellite systems. The range of PEPs considered includes TCP accelerators, TCP header compression and
HTTP proxies. The PEPs are classified in terms of ease of implementation, interworking capability with other PEPs and
performance potential.
Analysis of various PEP types/mechanisms and recommendations are made for using PEPs in BSM networks. Also
recommendations are made for further work to support the introduction of PEPs in satellite systems, and in particular
their introduction into the BSM architectures and standards.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
Not applicable.
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1] ETSI TS 102 465: "Satellite Earth Stations and Systems (SES); Broadband Satellite
Multimedia (BSM); General Security Architecture".
[i.2] ETSI TS 102 292: "Satellite Earth Stations and Systems (SES); Broadband Satellite
Multimedia (BSM) services and architectures; Functional architecture for IP interworking with
BSM networks".
[i.3] IETF RFC 3135 (June 2001): "Performance Enhancing Proxies Intended to Mitigate Link-Related
Degradations".
[i.4] I-PEP specifications, Issue 1a. Satlabs group recommendations (October 2005).
NOTE: Available at http://www.satlabs.org.
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TR 102 676 V1.1.1 (2009-11)
[i.5] ETSI TS 102 463: "Satellite Earth Stations and Systems (SES); Broadband Satellite
Multimedia (BSM); Interworking with IntServ QoS".
[i.6] ETSI TS 102 464: "Satellite Earth Stations and Systems (SES); Broadband Satellite
Multimedia (BSM); Interworking with DiffServ Qos".
[i.7] ETSI TS 102 466, "Satellite Earth Stations and Systems (SES); Broadband Satellite
Multimedia (BSM); Multicast Security Architecture".
[i.8] IETF RFC 4326: "Unidirectional Lightweight Encapsulation (ULE) for Transmission of
IP Datagrams over an MPEG-2 Transport Stream (TS)".
[i.9] ETSI EN 301 790: "Digital Video Broadcasting (DVB); Interaction channel for satellite
distribution systems".
[i.10] Xiplink.
NOTE: See http://www.xiplink.com/.
[i.11] Space Bel - SPB-FS-651-DS-001 (February 2004): "FastSat".
NOTE: Available at http://www.spacebel.be/FR/Space/FastSatDataSheet.pdf.
[i.12] HUGHES: "Delivering outstanding application performance over satellite".
NOTE: Available at:
http://www.direcway.com/HUGHES/Doc/0/SIKPBJS69O6KP42VCE4K4ER2BF/Hughes%20PEP-
H35661-A4-LR-091206.pdf.
[i.13] IEEE A&E Systems Magazine (August 2007): "PEPsal: A Performance Enhancing Proxy for TCP
Satellite Connections", C. Caini, R. Firrincieli, D. Lacamera.
[i.14] IETF RFC 5458 (March 2009): "Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol".
[i.15] V. Obanaik (2006): "Secure performance enhancing proxy: To ensure end-to-end security and
enhance TCP performance over IPv6 wireless networks". Elsevier Computer Networks 50 (2006)
2225-2238.
[i.16] S. Bellovin (February 1997): "Probable plaintext cryptanalysis of the IPSecurity protocols,
Proceedings of the Symposium on Network and Distributed System Security".
[i.17] IETF RFC 5246 (August 2008): "The Transport Layer Security (TLS) Protocol Version 1.2".
[i.18] L. Moser, etal (February 2007): "Building Dependable and Secure Web Services". Journal of
Software, Vol. 2, N . 1.
[i.19] G. Giambene, S. Kota (September - October 206): "Cross-layer Protocol Optimization for Satellite
Communications Networks: A Survey", Int. Journal Sat. Communications and Networking,
Vol. 24, pp. 323-341.
[i.20] G. Giambene, S. Hadzic: "A Cross-Layer PEP for DVB-RCS Networks", to be presented at the
First International Conference on Personal Satellite Services 2009 (PSATS2009),
March 18-19, 2009, Rome, Italy.
[i.21] P. Chini, G. Giambene, D. Bartolini, M. Luglio, C. Roseti: "Dynamic Resource Allocation based
on a TCP-MAC Cross-Layer Approach for DVB-RCS Satellite Networks", Int. Journal Sat.
Communications and Networking, Vol. 24, pp. 367-385, September-October 2006.
[i.22] C. Gomez, etal: "Web browsing optimization over 2.5G and 3G: end-to-end mechanisms vs. usage
of performance enhancing proxies". Wireless Communications and Mobile Computing. 2008;
8:213-230. Wiley InterScience.
[i.23] ESA ARTES-1 programme, 2006: "Transport Protocol for DVB-RCS Interoperable PEP".
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TR 102 676 V1.1.1 (2009-11)
[i.24] C. Roseti and E.Kristiansen: "TCP behaviour in a DVB-RCS environment". In Proceedings
th
24 AIAA International Communications Satellite Systems Conference (ICSSC),
San Diego, 2006.
[i.25] IETF RFC 4614 (September 2006): "A Roadmap for Transmission Control Protocol (TCP)
Specification Documents".
[i.26] IETF RFC 2581 (April 1999): "TCP Congestion Control".
[i.27] Space Communications Protocol Specification (SCPS)-Transport Protocol (SCPS-TP).
"Recommendation for Space Data System Standards, CCSDS 714.0-B-2". Blue Book. Issue 2.
Washington, D.C.: CCSDS, October 2006.
[i.28] C. Dovrolis, P. Ramanathan, D. Moore, "What do packet dispersion techniques measure?", in
Proceedings of IEEE INFOCOM, pp. 905-914, Apr. 2001.
[i.29] M. Karaliopoulos, R. Tafazzoli, B.G. Evans, "Providing Differentiated Services to TCP Flows
Over Bandwidth on Demand Geostationary Satellite Networks", IEEE Journal on Selected Areas
in Communications, vol. 22, No. 2, Feb. 2004.
[i.30] M. Sooriyabandara, G. Fairhurst, "Dynamics of TCP over BoD satellite networks, International
Journal of Satellite Communications and Networking", Vol. 21, No. 4-5, Jul. 2055, pp. 427-449.
[i.31] M. Luglio, C. Roseti, F. Zampognaro, "Performance evaluation of TCP-based applications over
DVB-RCS DAMA schemes", International Journal of Satellite Communications and Networking,
Vol. 27, Issue 3, pp. 163-191, Published online 2 Mar 2009, DOI: 10.1002/sat.930.
[i.32] IETF RFC 5374: "Multicast Extensions to the Security Architecture for the Internet Protocol".
[i.33] IETF RFC 793: "Transmission Control Protocol".
[i.34] IETF RFC 1122: "Requirements for Internet Hosts - Communication Layers".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
distributed PEP: PEP client and server are located at both ends of the satellite link (BSM ST and Gateway)
GateWay PEP (GW PEP): PEP server located near the BSM Gateway
integrated PEP: there is only one PEP entity residing with the satellite gateway (BSM Gateway)
interoperable PEP (I-PEP): functional architecture assumes a split-connection approach with the I-PEP server and a
client both capable of supporting the I-PEP protocol
NOTE 1: The I-PEP protocol consists of a transport protocol heavily based on TCP and modified/augmented by
SCPS-TP as well as a session protocol comprising several optional additions to support service and
session management.
NOTE 2: Specified by the ESA/Satlabs [i.4] and aims to provide enhancement for satellite-based communications.
Performance Enhancing Proxy (PEP): network agents designed to improve the end-to-end performance of some
communications protocol such as Transmission Control Protocol (TCP)
NOTE: More information on Transmission Control Protocol (TCP) is available at
http://en.wikipedia.org/wiki/Transmission_Control_Protocol.
ST PEP: PEP client located near the BSM ST terminal
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TR 102 676 V1.1.1 (2009-11)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACCE ACK-based Capacity and Congestion Estimation
ACK ACKnowledgement
A-PEP Application layer PEP
BDP Bandwidth Delay Product
BSM Broadband Satellite Multimedia
CCSDS Consultative Committee for Space Data Systems
cwnd congestion window (TCP)
DAMA Demand Assignment Multiple Access
DNS Domaine Name System
DVB-RCS Digital Video Broadcasting - Return Channel for Satellites
ESP Encapsulated Security Protocol
FSS Fixed Service Satellite
FTP File Transfer Protocol
GW PEP GateWay PEP
HPEP HTTP PEP
ICMP Internet Control Message Protocol
IP Internet Protocol
ISP Internet Service Provider
LAN Local Area Network
M-ESP Modified ESP
MF-TDMA Multi Frequency - Time Division Multiple Access
MIB Management Information Base
ML-IPSEC Multilayer IPSEC protocol
MPE Multi Protocol Encapsulation
MSS Maximum Segment Size
MTU Maximum Transmission Unit
NCC Network Control Centre
PEP Performance Enhancing Proxy
QID Queue ID
QIDSPEC Queue ID SPECifications
QoS Quality of Service
RTO Retransmission Time Out
RTT Round-Trip Time
RWIN Receive WINdow
SACKs Selective ACKnowledgements
SCPS Space Communications Protocol Specification
SCPS-TP Space Communications Protocol Specification-Transport Protocol
SID Security association IDentity
SIP Session Initiation Protocol
SI-SAP Satellite Independent - Service Access Point
SSL Secure Socket Layer
ST Satellite Terminal
TBTP Terminal Burst Time Plan
TCP Transmission Control Protocol
TCPN TCP Noordwijk
TF-ESP Transport Friendly - ESP
TLS Transport Layer Security
T-PEP TCP (transport) layer - PEP
UDP User Datagram Protocol
ULE Unidirectional Lightweight Encapsulation
UMTS Universal Mobile Telephone System
URL Uniform Resource Locator
VPN Virtual Private Network
X-SAP Cross Layer Service Access Point
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TR 102 676 V1.1.1 (2009-11)
4 Need for PEPs in BSM networks
4.1 Performance improvement using standard end-to-end
techniques
The original Internet adopted an end-to-end architecture, where a transport connection was between a pair of hosts,
bound to a globally unique IP address and locally meaningful transport port at each end host. The literature background
for end-to-end improvements to TCP and HTTP (without using PEPs) is presented in clauses A.1 and A.2.
There are two main reasons in favour of using end-to-end mechanisms for improving performance over satellite links:
1) End-to-end mechanisms are based on standard options and maintain end-to-end semantics. Thus, they are fully
compliant with the Internet architecture.
2) Empirical results demonstrate a significant improvement, especially when adequate HTTP settings are used.
However, end-to-end techniques have the following drawbacks:
1) The design criteria of Internet servers aim to optimize server throughput. Such goal might be difficult to
achieve, because the configuration of many Internet servers limits the number of parallel transport connections
per session.
3) Certain parameters cannot be optimized at the same time for different access technologies. For example, the
Bandwidth Delay Product (BDP, see annex A) in satellite networks is much larger than UMTS. Moreover,
servers are by default unaware of the access technology used by a client.
4) At least one TCP Slow Start phase will still take place during a web page download, unless persistent
connections are used. However, the configuration of many Internet servers seeks to minimize the amount of
memory consumed per session, a side-effect of this is that servers often unwilling to hold state for connections
which become passive.
5) Should multiple objects be hosted under different domain names, DNS lookup overhead cannot be avoided or
reduced using end-to-end options.
6) The performance of end-to-end mechanisms reduces over paths that experience gaps in connectivity (e.g. due
to a link outages). The reason is that a server is unable to distinguish between congestion and radio link losses.
This can lead to unwanted activation of TCP congestion control mechanisms or timeouts and thus significantly
reducing performance.
Considering the issues discussed above, optimization of current end-to-end methods can provide improvements, but as
yet cannot provide optimal performance for satellite systems. An alternative solution is the use of PEPs (see clauses 4.2
and 4.3).
4.2 Motivation for using PEPs
The present document focuses on the current work in defining the PEP architecture for BSM satellite networks.
In general, the Internet transport protocol (namely TCP) exhibits suboptimal performance due to the following satellite
characteristics:
• Long feedback loops: Propagation delay from a sender to a receiver in a geosynchronous satellite network can
range from 240 to 280 milliseconds.
• Large bandwidth*delay products: TCP needs to keep a large number of packets "in flight" in order to fully
utilize the satellite link.
• Asymmetric capacity: The return link capacity for carrying ACKs can have a significant impact on TCP
performance.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TR 102 676 V1.1.1 (2009-11)
An alternative solution to clause 4.1 is to place an entity called Performance Enhancing Proxy (PEP) somewhere
between the endpoints of a communication link. We focus on TCP PEPs (T-PEP) and Application PEPs (A-PEP).
clauses B.1, B.2 and B.3 present details on PEP types, transport and application layer PEPs. As a summary of this
approach, among the TCP PEP proposals, one solution is represented by the splitting approach [i.3]. The rationale of the
splitting concept is to separate the satellite portion from the rest of the network. This approach can be further be divided
into two categories: Distributed PEPs where the PEP client and server are located at each end of the satellite link. The
other category is Integrated PEPs with only one PEP entity residing with the satellite gateway. Typical TCP PEP
improvements are:
• TCP Spoofing: Eliminates effects of satellite delay on TCPs slow start and window sizing.
• ACK Reduction: Reduces unnecessary acknowledgements to improve bandwidth efficiency.
• Flow Control: Employs network feedback to intelligently control traffic flow.
• Error Recovery: Works closely with flow control to recover damaged or lost packets.
• Traffic Prioritization: Classifies traffic by application protocol, matching this to the MAC layer.
• Connection Establishment Spoofing: Intelligently spoofs the TCP three-way handshake to speed up
establishment of a connection.
• PEPs can also compress protocol information, or change protocol characteristics to match specific
characteristics of the satellite channel.
In addition to TCP PEPs (T-PEP), there are other complementary solutions such as application layer PEPs (A-PEP),
where web browsing is the major target for application PEPs. Typical application layer PEPs improvements are:
• HTTP pre-fetching: Intercepting requested Web pages, identifying Web objects referred to by the Web pages,
downloading these objects in anticipation of the next user requests.
• Browser Cache Leveraging: Caching some web pages not residing in browser cache, improving efficiency.
• Bulk Transfer Prioritization: Prioritizes bulk transfers to prevent adverse effect on other Web traffic.
• Cookie Handling: Ensures accurate painting of Web pages with the proper cookies.
• Compression: Payload compression provides increased transmission speeds. In addition, header compression
for TCP, UDP, and RTP protocols results in additional bandwidth savings.
• DNS caching techniques, to further improve bandwidth utilization.
Commercial PEPs normally combine some or all of the T-PEP and A-PEP techniques together such the Hughes [i.12],
XipLink [i.10], FastSat [i.11], Newtec, TAS-F and STM PEPs. A summary of the various techniques used in PEP
products is presented in annex C.
4.3 PEP terminal architecture and components
There are two possibilities for the location of ST PEP: one is being internal to the BSM ST as shown in figure 1a, where
the PEP run as a software process above the SI-SAP in the ST itself. The other possibility, as shown in figure 1b, is that
ST PEP is external to the BSM ST and connected to the BSM ST with an Ethernet cable. Figure 2 shows the PEP
protocol stack with the BSM Gateway terminal architectures, where the common location is that the Gateway PEP is
external to the BSM Gateway.
The PEP residing on the BSM ST side is called ST PEP (PEP client) and the one on the BSM gateway side is called
Gateway PEP (GW PEP, PEP server). Both PEPs have a similar architecture with two interfaces, one to the BSM
satellite network and one to terrestrial networks. On the satellite side, the ST/Gateway PEP are connected to BSM
ST/Gateway through an Ethernet LAN (except the internal ST PEP). On the terrestrial network side, normally, the PEP
terminal connects to host/hosts on the same LAN, while the gateway PEP connects to a content server through the
general Internet. However, the Gateway PEP can be located remotely from the BSM Gateway terminal (such as
Gateway PEP run by a service provider), more details are presented in clause 4.4.
ETSI

---------------------- Page: 11 ----------------------
12 ETSI TR 102 676 V1.1.1 (2009-11)
Also, figures 1a, 1b and 2 show the Satellite Independent Service Access Point (SI-SAP) interface. It enables the BSM
system to abstract the lower layer functions. It allows the network protocols developed in the satellite independent layer
to perform over any BSM family (specific satellite technologies). Moreover, the SI-SAP also enables the use of
standard Internet protocols for example address resolution, QoS, security and network management, directly over the
satellite system or with minimal adaptation to satellite physical characteristics. Finally the SI-SAP even makes it
possible to envisage switching from one satellite system to another and to even a non-satellite technology while
preserving the BSM operator's investment in upper layers software developments.
The transport protocol in the PEP is divided between st
...