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)

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

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
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
4 ETSI TR 102 676 V1.1.1 (2009-11)
Annex F: Bibliography . 41
History . 42

ETSI
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
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
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
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
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
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
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
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 standard TCP/UDP and PEP specific transport protocols. As
shown in figures 1a, 1b and 2, the PEP specific transport protocol can be:
• A modified TCP (TCP+) such as the Hybla protocols [i.13], which is used in integrated PEP configurations,
where only Gateway PEP will be used (no ST PEP).
• Standard Interoperable PEP Transport Protocol (I-PEP TP), recommended by Satlabs [i.4] and used in the
distributed PEP configurations. The I-PEP TP is based on an extension set to TCP termed SCPS-TP, which
was produced by the Consultative Committee for Space Data Systems (CCSDS).
• Proprietary distributed Transport Protocol (TP+), where company specific (non-standard) protocols are used.
The ST/Gateway PEPs can be managed either locally or remotely. For remote management, either SNMP or HTTP
protocols can be used to communicate with the BSM management system. In both cases the PEP monitoring and
configuration controls can be based on the standard MIB II and enterprise specific PEP MIBs.
The optimum PEP performance is expected to require a close matching between the PEP configuration and the QoS
provisioning of the associated lower layer bearer services. In some PEP implementations, there is a customized
(proprietary) signalling between the PEP and the Satellite terminal. Such signalling can be used for QoS monitoring of
the terminal queues and adjusting rate control parameters accordingly to maximize the use of the satellite capacity.

ST PEP (PEP
Management agent client) with
BSM Management (e.g. SNMP or web
BSM ST
System
ST QoS
Application
manager
PEP
SI-SAP
I-PEP TP
UDP TCP TP+
IP layer
Link layer
S-MAC
S-PHY
Ethernet 2
Host/hosts Satellite link
Figure 1a: BSM ST with internal PEP
ETSI
13 ETSI TR 102 676 V1.1.1 (2009-11)

ST PEP
(PEP client)
Management agent
BSM Management (e.g. SNMP or web
System
BSM ST
Application
PEP
SI-SAP
ST QoS
manager
I-PEP TP
UDP TCP TP+
IP layer IP layer
Link layer Link layer
S-MAC
Ethernet 2 Ethernet 1 Ethernet 1 S-PHY
Host/hosts Satellite link
LAN
Figure 1b: BSM ST with external PEP

Gateway PEP
Management agent (PEP Server)
(e.g. SNMP or web
BSM Management
System
BSM Gateway
Application
PEP
SI-SAP
Gateway -QoS
manager
I-PEP TP
UDP TCP TCP+
TP+
IP layer IP layer
Link layer Link layer
S-MAC
Ethernet 2 Ethernet 1 Ethernet 1 S-PHY
Satellite link
Content provider
Internet LAN
Figure 2: BSM Gateway PEP with external GW PEP
4.4 PEP scenarios
Several PEP usage scenarios are presented here following the Satlabs recommendations [i.4]. All scenarios apply to
both star and mesh satellite link topologies.
4.4.1 Scenario 1: Single user
Figure 3 shows the single user scenario, where there is a clear one-to-one mapping between users and PEP clients
(ST PEP). The multi-user scenario expands beyond the single user variant in that several application clients are served
by the same PEP client. This reflects the typical home user or home office scenario. The PEP client may be integrated
with the BSM ST, or it may be a stand-alone entity separate from both the end user's device and the ST.
ETSI
14 ETSI TR 102 676 V1.1.1 (2009-11)
The end-to-end TCP connection is split into three connections:
• The first connection is between the content provider and the GW PEP (standard TCP).
• The second connection is between the GW PEP and the ST PEP. The transport protocol here can be either
proprietary or standardized PEP such as the I-PEP [i.4].
• The third connection is between the host and the ST PEP (standard TCP).

GW PEP (using
ST PEP (using
PEP protocol)
PEP protocol)
Internet
BSM GW
BSM ST
Content provider
Host (using
(using standard TCP)
standard TCP)
Figure 3: Scenario 1: ST PEP serving a single host with co-located BSM and PEP Gateways
4.4.2 Scenario 2: Independent satellite and PEP gateways
Scenario 1, assumed that the PEP server (Gateway PEP) is co-located with the BSM Gateway (which implies that the
satellite service provider either operates the PEP or provides hosting facilities for the respective system components). In
scenario 2, the PEP server is external to the BSM Gateway (see figure 4), motivating two different set-ups:
• PEP server may be run by a separate Internet Service Provider (ISP) on behalf of many users; or
• PEP server may be operated by an enterprise on its own behalf.
Similar to scenario 1, end-to-end TCP connection is split into three connections. However there are few difference:
• The communication link between the PEP server and BSM Gateway now extends through a wide area network
that is not trusted and the satellite service provider may also not be trusted. A typical connection will be an IP
tunnel (possibly with IPsec).
• Addressing schemes for PEP and BSM entities may be controlled by two different administrations.
ETSI
15 ETSI TR 102 676 V1.1.1 (2009-11)

GW PEP
ST PEP
(using PEP
(using PEP
protocol)
protocol)
IP
Network
BSM GW
BSM ST
Internet
Host (using
standard TCP
Content provider (using
standard TCP)
Figure 4: Scenario 2: Independent Gateway PEP from BSM Gateway
A variation in scenario 2 will be to have independent transport layer and application layer PEPs. So in figure 4, each
PEP box (ST and GW PEPs) may include two functionally independent PEPs (e.g. T-TCP and A-PEP).
4.4.3 Scenario 3: Multiple PEP Gateways

VPN Server
(using standard
TCP)
Private
Network
ST PEP
(using I-PEP)
GW PEP 1
(using I-PEP)
IP
Network
GW PEP 2
(using I-PEP)
BSM ST BSM GW
Host (using Internet
standard TCP
Content provider (using
standard TCP)
Figure 5: Scenario 3: ST PEP accessing multiple Gateway PEPs
This scenario is depicted in figure 5 and it is useful in cases where a remote terminal, has an IP tunnel for enterprise
communications as well as a direct Internet connection for general communications. PEP acceleration is required for
both and can only be operated independently.
In this scenario, there is no longer a single "centralized" Gateway PEP. Instead, multiple Gateway PEPs are used: either
due to the presence of multiple ISPs or because performance enhancement is managed directly between user sites
(VPN configuration).
ETSI
16 ETSI TR 102 676 V1.1.1 (2009-11)
Similar to scenario 1 and 2, end-to-end TCP connection is split into three connections. In comparison to scenario 2, the
PEP client (ST PEP) needs to interoperate with multiple PEP servers from different vendors. Therefore, one possible
solution is that the ST could house multiple PEPs. Another and more elegant solution is using the I-PEP protocol [i.4],
where a single client PEP can communicate seamless with server PEPs from different vendors.
4.4.4 Scenario 4: Integrated PEP (single PEP)
The previous three scenarios showed various aspect of a distributed PEP (PEP client and server at both ends of the
satellite link, like the ST and Gateway PEPs). Scenario 4 shows an example of an integrated PEP (see figure 6).

Integrated PEP
(using modified
Host (using TCP)
standard TCP
Internet
BSM ST BSM GW
Content provider
(using Standard
TCP)
Figure 6: Scenario 4: Integrated PEP implemented at the BSM Gateway
Here the TCP connection established among the end hosts, is split in two separated connections, with the integrated
PEP at the BSM Gateway. The first connection (between the web server and the integrated PEP makes use of the TCP
standard and is terminated at the PEP. The second connection, between PEP and the final user, can exploit an enhanced
TCP version compatible with a standard TCP receiver (such as the Hypla protocol [i.13]). In comparison to the
distributed PEPs scenarios, integrated PEP is simpler but has limited enhancement capabilities.
4.5 Cross layer improvements
Due to the bandwidth-limited (and sometimes dynamic) nature of the radio channel, there is tight interdependence
between the performance of protocol layers in satellite systems. "Cross-layering" is the mechanism that exploits
interactions between protocols at adjacent or non-adjacent layers (i.e. exchanging of information/commands related to
the 'internal state' of protocols, meaning here the 'variables' that are typical of a layer, representing its state or behaviour;
for instance:
(i) queue length for MAC layer or IP layer;
(ii) congestion window value for TCP at transport layer) to improve system performance.
ETSI
17 ETSI TR 102 676 V1.1.1 (2009-11)
Cross-layer signalling exchange can be in downward or upward directions in the protocol stack (i.e. following the same
direction of the application data flow or in a feedback direction, respectively). Downward signalling could be used to
notify information such as: application and audio/video codec type, QoS requirements, priority, protocol type and
internal protocol state. Upward signalling could be employed to send information concerning: available air interface
options, propagation conditions, handover preparation measures, congestion notification, policing options, and a request
to change the codec type (the reference is here to a scalable application layer) depending on the varying capacity offered
by the PHY layer, referring to an air interface supporting adaptive modulation and coding. In general, two methods
could be used to support the exchange of signalling across layers [i.19]:
• In-band signalling with the use of enriched packet headers to notify internal state variables to either other
layers within a given host (internal cross-layering) or in a peer-to-peer case with another host or gateway
(external cross-layering). This method needs the redefinition of packets headers (e.g. unallocated header fields
or new message type) and can be used for signalling going in the same direction of related data
(downward/forward signalling).
• Out-of-band signalling via the control plane, that is the use of new primitives and suitable Service Access
Points (SAPs) to allow the dialogue between protocol layers.
Cross-layering requires to adopt mechanisms to allow the exchange of signalling also among non-adjacent layers. The
coordination of signalling could be made by a protocol layer (horizontal approach) or by an external controller that is
common to all the layers (vertical approach). In the first case, as shown in figure 7a, the coordinating protocol layer can
have direct interfaces (SAPs) with adjacent layers and cross-layer interfaces (X-SAPs) between non-adjacent layers
(e.g. creating holes in the protocol stack by means of the Internet Control Message Protocol (ICMP) [i.29]. In the
second case, a global coordinator of different layers has interfaces (X-SAPs), with all the protocol layers and can have
control on their internal state variables, reading and modifying them, depending on triggering events (see figures 7a
and 7b).
C-plane
Layer a
Write primitive involving non-adjacent
layers
X-SAP
Layer b
SAP
Get primitive
Generic layer
controlling cross-layering
SAP
Get primitive Write primitive
Layer d
Figure 7a: Diagram of cross-layer signalling exchange among protocol layers
horizontal approach with a protocol having the control
ETSI
18 ETSI TR 102 676 V1.1.1 (2009-11)
C-pC-pllaannee
Get primitive
X-SAP
Layer a
r
o
.
Write primitive t
a
…
n
i
…
d
r
o
Layer b
o
c
l
a
n
La y er c r
e
t
x
E
La ye r d
Figure 7b: Diagram of cross-layer signalling exchange among protocol layers
vertical approach with an external coordinator
A classical transport-layer PEP does not use cross-layer information to manage TCP flows. This non-cross-layer type of
PEP is called sometimes "Blind-PEP". Alternatively, a PEP that exploits cross-layer signalling is called "Sighted PEP".
The cross-layer PEP scheme envisaged here is a transport-layer integrated PEP operated on the NCC side and based on
the horizontal cross-layer signalling approach, where MAC layer has the control of signalling exchange [i.19]. In this
study the NCC/PEP is collocated with the BSM Gateway. In satellite networks, the bottleneck link is the satellite one.
Hence, the NCC/gateway can have a direct control on it via the resource allocation decided at layer 2: the NCC/PEP can
thus anticipate congestion events and use an upward cross-layer signalling (out-of band message) to notify its transport
layer when the capacity available in the satellite network is close to be saturated. Then, modified ACK* (in-band
signalling) could be used to notify the TCP sender to stop the traffic injection increase. In a Blind PEP this is not
possible, thus causing large packet losses with consequent possible time out events with a significant drop of the TCP
congestion window for a long time interval. These additional layer functionalities of the Sighted PEP need that the
NCC/PEP supports a cross-layer signalling dialogue between TCP and MAC layer. Annex E presents a detailed
description of the functionalities needed to support the "Sighted PEP" for File Transfer Protocol (FTP) data flows from
the ST (TCP sender) through the gateway towards the Internet, where an integrated PEP is co-located with the gateway.
Finally, Excessive use of cross-layering can increases implementation complexity and dependence on the protocol
details of other layers, classically regarded as layer-violation. This may raise cause difficulties when the protocol
specifications is updated, or new functions are added. Hence most of these techniques are still in research stage and are
not widely implemented in existing PEP products.
5 Security impact on Performance Enhancing Proxies
5.1 Previous research work related to PEP security
Interworking between PEPs and security system has been researched in the past [i.15]. For example, many researchers
had addressed the issue of interworking between IPsec and PEPs. One solution was the use of an intelligent switch at
the PEP. As such, the PEP provides acceleration for the unencrypted packets, while the encrypted packets are allowed
to bypass the PEP. With this approach, the applications can choose between security and performance, but both are not
obtainable together.
Some modifications to IPsec had been proposed. Transport Friendly Encapsulated Security Protocol (TF-ESP) or
Modified ESP (M-ESP) [i.15] proposes a modification to ESP header to accommodate the necessary TCP header
information in the ESP header outside the scope of encryption. The mechanism proposes that the unencrypted TCP
header information in ESP should be authenticated for integrity. Although this method addresses the performance
issues, it exposes enough in
...