PEP-based solutions not only have the problems discussed in the preceding 
section, but are often regarded as being "inelegant" because they violate the 
fundamental design principle in data communications: protocol layering. The 
principle says that a service provided by a certain protocol layer may not 
depend on the semantics of a protocol on a different layer. For example, a 
service that is specific to a particular link is by definition a link layer 
service. According to the protocol layering principle it may not depend on 
network, transport, or application layer protocol semantics. Those semantics are 
often conveyed via the respective protocol headers. However, PEPs provide a link 
layer service but are dependent on transport layer protocol semantics and do 
rely on access to the information in the transport protocol’s headers. In 
Section 2.2.3, we have already encountered such an example of layer violation: 
TCP/IP header compression.

	[Fig. 2-18, see pdf]

Our goal is to find a solution that eliminates all the inefficient cross-layer 
interactions explained in Section 2.5 while satisfying the paradigm of protocol 
layering. Beyond academic ambition there is a more pragmatic reason for why it 
is desirable to find a solution that con-forms with protocol layering: network 
layer encryption for IP, IPsec [RFC2401]. PEP-based solutions are rendered 
useless if IPsec spans across an untrusted PEP, because IPsec encrypts the 
transport layer protocol headers. This means that a link layer cannot even 
identify a flow’s end-points. We believe that IPsec will become an important 
cornerstone of the future Internet, especially for mobile users who are free to 
roam between multiple wireless access providers and ISPs to get access to their 
corporate and/or residential Intranets (see Figure 2-18). Those users (usually) 
do not trust their wireless access providers, their ISPs, nor anybody on the 
"open" Internet when accessing their Intranets. IPsec provides them with the 
capability to secure their data against such untrusted parties by encrypting all 
traffic at the network layer either end-to-end, or between a host and a 
firewall.

In finding our solution, we were not discouraged by concerns about deploying 
changes to an end-to-end protocol or its implementation (see the "no" in the 
last row of Table 2-17) as dis-cussed in the preceding section. Nevertheless, 
with our proposed solutions we obey the Inter-net Engineering Task Force’s 
(IETF) key design principle: incremental deployment. The prin-ciple says that 
any change to the Internet, in particular to its end-to-end protocols, must be 
backwards compatible and may not interfere with existing mechanism, e.g., TCP’s 
congestion control behavior. Hence, we asked ourselves the following questions.

* What function, in general, is missing in the Internet’s design that would 
allow to optimize the end-to-end performance that loss responsive flows could 
provide when running across wireless links?

* Given that such a function is, in fact, missing and was added to the Internet, 
what, in par-ticular, is wrong with TCP or its implementations that decreases 
its end-to-end perfor-mance when it runs over wireless links, and how can that 
be solved?

Chapter 4 is dedicated to finding answers to the first question, while we study 
the second ques-tion in Chapter 5.