File: rfc3135.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (2523 lines) | stat: -rw-r--r-- 114,825 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523






Network Working Group                                          J. Border
Request for Comments: 3135                        Hughes Network Systems
Category: Informational                                          M. Kojo
                                                  University of Helsinki
                                                               J. Griner
                                              NASA Glenn Research Center
                                                           G. Montenegro
                                                  Sun Microsystems, Inc.
                                                               Z. Shelby
                                                      University of Oulu
                                                               June 2001


    Performance Enhancing Proxies Intended to Mitigate Link-Related
                              Degradations

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document is a survey of Performance Enhancing Proxies (PEPs)
   often employed to improve degraded TCP performance caused by
   characteristics of specific link environments, for example, in
   satellite, wireless WAN, and wireless LAN environments.  Different
   types of Performance Enhancing Proxies are described as well as the
   mechanisms used to improve performance.  Emphasis is put on proxies
   operating with TCP.  In addition, motivations for their development
   and use are described along with some of the consequences of using
   them, especially in the context of the Internet.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Types of Performance Enhancing Proxies  . . . . . . . . . . . .  4
   2.1 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.1.1 Transport Layer PEPs . . . . . . . . . . . . . . . . . . . .  5
   2.1.2 Application Layer PEPs . . . . . . . . . . . . . . . . . . .  5
   2.2 Distribution . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.3 Implementation Symmetry  . . . . . . . . . . . . . . . . . . .  6
   2.4 Split Connections  . . . . . . . . . . . . . . . . . . . . . .  7



Border, et al.               Informational                      [Page 1]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   2.5 Transparency . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3. PEP Mechanisms  . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.1 TCP ACK Handling . . . . . . . . . . . . . . . . . . . . . . .  9
   3.1.1 TCP ACK Spacing  . . . . . . . . . . . . . . . . . . . . . .  9
   3.1.2 Local TCP Acknowledgements . . . . . . . . . . . . . . . . .  9
   3.1.3 Local TCP Retransmissions  . . . . . . . . . . . . . . . . .  9
   3.1.4 TCP ACK Filtering and Reconstruction . . . . . . . . . . . . 10
   3.2 Tunneling  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.3 Compression  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.4 Handling Periods of Link Disconnection with TCP  . . . . . . . 11
   3.5 Priority-based Multiplexing  . . . . . . . . . . . . . . . . . 12
   3.6 Protocol Booster Mechanisms  . . . . . . . . . . . . . . . . . 13
   4. Implications of Using PEPs  . . . . . . . . . . . . . . . . . . 14
   4.1 The End-to-end Argument  . . . . . . . . . . . . . . . . . . . 14
   4.1.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   4.1.1.1 Security Implications  . . . . . . . . . . . . . . . . . . 15
   4.1.1.2 Security Implication Mitigations . . . . . . . . . . . . . 16
   4.1.1.3 Security Research Related to PEPs  . . . . . . . . . . . . 16
   4.1.2 Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . 16
   4.1.3 End-to-end Reliability . . . . . . . . . . . . . . . . . . . 17
   4.1.4 End-to-end Failure Diagnostics . . . . . . . . . . . . . . . 19
   4.2 Asymmetric Routing . . . . . . . . . . . . . . . . . . . . . . 19
   4.3 Mobile Hosts . . . . . . . . . . . . . . . . . . . . . . . . . 20
   4.4 Scalability  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   4.5 Other Implications of Using PEPs . . . . . . . . . . . . . . . 21
   5. PEP Environment Examples  . . . . . . . . . . . . . . . . . . . 21
   5.1 VSAT Environments  . . . . . . . . . . . . . . . . . . . . . . 21
   5.1.1 VSAT Network Characteristics . . . . . . . . . . . . . . . . 22
   5.1.2 VSAT Network PEP Implementations . . . . . . . . . . . . . . 23
   5.1.3 VSAT Network PEP Motivation  . . . . . . . . . . . . . . . . 24
   5.2 W-WAN Environments . . . . . . . . . . . . . . . . . . . . . . 25
   5.2.1 W-WAN Network Characteristics  . . . . . . . . . . . . . . . 25
   5.2.2 W-WAN PEP Implementations  . . . . . . . . . . . . . . . . . 26
   5.2.2.1 Mowgli System  . . . . . . . . . . . . . . . . . . . . . . 26
   5.2.2.2 Wireless Application Protocol (WAP)  . . . . . . . . . . . 28
   5.2.3 W-WAN PEP Motivation . . . . . . . . . . . . . . . . . . . . 29
   5.3 W-LAN Environments . . . . . . . . . . . . . . . . . . . . . . 30
   5.3.1 W-LAN Network Characteristics  . . . . . . . . . . . . . . . 30
   5.3.2 W-LAN PEP Implementations: Snoop . . . . . . . . . . . . . . 31
   5.3.3 W-LAN PEP Motivation . . . . . . . . . . . . . . . . . . . . 33
   6. Security Considerations . . . . . . . . . . . . . . . . . . . . 34
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 34
   8. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 34
   9. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 35
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
   Appendix A - PEP Terminology Summary . . . . . . . . . . . . . . . 41
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 45




Border, et al.               Informational                      [Page 2]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


1. Introduction

   The Transmission Control Protocol [RFC0793] (TCP) is used as the
   transport layer protocol by many Internet and intranet applications.
   However, in certain environments, TCP and other higher layer protocol
   performance is limited by the link characteristics of the
   environment.

   This document is a survey of Performance Enhancing Proxy (PEP)
   performance migitigation techniques.  A PEP is used to improve the
   performance of the Internet protocols on network paths where native
   performance suffers due to characteristics of a link or subnetwork on
   the path.  This document is informational and does not make
   recommendations about using PEPs or not using them.  Distinct
   standards track recommendations for the performance mitigation of TCP
   over links with high error rates, links with low bandwidth, and so
   on, have been developed or are in development by the Performance
   Implications of Link Characteristics WG (PILC) [PILCWEB].

   Link design choices may have a significant influence on the
   performance and efficiency of the Internet.  However, not all link
   characteristics, for example, high latency, can be compensated for by
   choices in the link layer design.  And, the cost of compensating for
   some link characteristics may be prohibitive for some technologies.
   The techniques surveyed here are applied to existing link
   technologies.  When new link technologies are designed, they should
   be designed so that these techniques are not required, if at all
   possible.

   This document does not advocate the use of PEPs in any general case.
   On the contrary, we believe that the end-to-end principle in
   designing Internet protocols should be retained as the prevailing
   approach and PEPs should be used only in specific environments and
   circumstances where end-to-end mechanisms providing similar
   performance enhancements are not available.  In any environment where
   one might consider employing a PEP for improved performance, an end
   user (or, in some cases, the responsible network administrator)
   should be aware of the PEP and the choice of employing PEP
   functionality should be under the control of the end user, especially
   if employing the PEP would interfere with end-to-end usage of IP
   layer security mechanisms or otherwise have undesirable implications
   in some circumstances.  This would allow the user to choose end-to-
   end IP at all times but, of course, without the performance
   enhancements that employing the PEP may yield.

   This survey does not make recommendations, for or against, with
   respect to using PEPs.  Standards track recommendations have been or
   are being developed within the IETF for individual link



Border, et al.               Informational                      [Page 3]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   characteristics, e.g., links with high error rates, links with low
   bandwidth, links with asymmetric bandwidth, etc., by the Performance
   Implications of Link Characteristics WG (PILC) [PILCWEB].

   The remainder of this document is organized as follows.  Section 2
   provides an overview of different kinds of PEP implementations.

   Section 3 discusses some of the mechanisms which PEPs may employ in
   order to improve performance.  Section 4 discusses some of the
   implications with respect to using PEPs, especially in the context of
   the global Internet.  Finally, Section 5 discusses some example
   environments where PEPs are used: satellite very small aperture
   terminal (VSAT) environments, mobile wireless WAN (W-WAN)
   environments and wireless LAN (W-LAN) environments.  A summary of PEP
   terminology is included in an appendix (Appendix A).

2. Types of Performance Enhancing Proxies

   There are many types of Performance Enhancing Proxies.  Different
   types of PEPs are used in different environments to overcome
   different link characteristics which affect protocol performance.
   Note that enhancing performance is not necessarily limited in scope
   to throughput.  Other performance related aspects, like usability of
   a link, may also be addressed.  For example, [M-TCP] addresses the
   issue of keeping TCP connections alive during periods of
   disconnection in wireless networks.

   The following sections describe some of the key characteristics which
   differentiate different types of PEPs.

2.1 Layering

   In principle, a PEP implementation may function at any protocol layer
   but typically it functions at one or two layers only.  In this
   document we focus on PEP implementations that function at the
   transport layer or at the application layer as such PEPs are most
   commonly used to enhance performance over links with problematic
   characteristics.  A PEP implementation may also operate below the
   network layer, that is, at the link layer, but this document pays
   only little attention to such PEPs as link layer mechanisms can be
   and typically are implemented transparently to network and higher
   layers, requiring no modifications to protocol operation above the
   link layer.  It should also be noted that some PEP implementations
   operate across several protocol layers by exploiting the protocol
   information and possibly modifying the protocol operation at more
   than one layer.  For such a PEP it may be difficult to define at
   which layer(s) it exactly operates on.




Border, et al.               Informational                      [Page 4]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


2.1.1 Transport Layer PEPs

   Transport layer PEPs operate at the transport level.  They may be
   aware of the type of application being carried by the transport layer
   but, at most, only use this information to influence their behavior
   with respect to the transport protocol; they do not modify the
   application protocol in any way, but let the application protocol
   operate end-to-end.  Most transport layer PEP implementations
   interact with TCP.  Such an implementation is called a TCP
   Performance Enhancing Proxy (TCP PEP).  For example, in an
   environment where ACKs may bunch together causing undesirable data
   segment bursts, a TCP PEP may be used to simply modify the ACK
   spacing in order to improve performance.  On the other hand, in an
   environment with a large bandwidth*delay product, a TCP PEP may be
   used to alter the behavior of the TCP connection by generating local
   acknowledgments to TCP data segments in order to improve the
   connection's throughput.

   The term TCP spoofing is sometimes used synonymously for TCP PEP
   functionality.  However, the term TCP spoofing more accurately
   describes the characteristic of intercepting a TCP connection in the
   middle and terminating the connection as if the interceptor is the
   intended destination.  While this is a characteristic of many TCP PEP
   implementations, it is not a characteristic of all TCP PEP
   implementations.

2.1.2 Application Layer PEPs

   Application layer PEPs operate above the transport layer.  Today,
   different kinds of application layer proxies are widely used in the
   Internet.  Such proxies include Web caches and relay Mail Transfer
   Agents (MTA) and they typically try to improve performance or service
   availability and reliability in general and in a way which is
   applicable in any environment but they do not necessarily include any
   optimizations that are specific to certain link characteristics.

   Application layer PEPs, on the other hand, can be implemented to
   improve application protocol as well as transport layer performance
   with respect to a particular application being used with a particular
   type of link.  An application layer PEP may have the same
   functionality as the corresponding regular proxy for the same
   application (e.g., relay MTA or Web caching proxy) but extended with
   link-specific optimizations of the application protocol operation.

   Some application protocols employ extraneous round trips, overly
   verbose headers and/or inefficient header encoding which may have a
   significant impact on performance, in particular, with long delay and
   slow links.  This unnecessary overhead can be reduced, in general or



Border, et al.               Informational                      [Page 5]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   for a particular type of link, by using an application layer PEP in
   an intermediate node.  Some examples of application layer PEPs which
   have been shown to improve performance on slow wireless WAN links are
   described in [LHKR96] and [CTC+97].

2.2 Distribution

   A PEP implementation may be integrated, i.e., it comprises a single
   PEP component implemented within a single node, or distributed, i.e.,
   it comprises two or more PEP components, typically implemented in
   multiple nodes.  An integrated PEP implementation represents a single
   point at which performance enhancement is applied.  For example, a
   single PEP component might be implemented to provide impedance
   matching at the point where wired and wireless links meet.

   A distributed PEP implementation is generally used to surround a
   particular link for which performance enhancement is desired.  For
   example, a PEP implementation for a satellite connection may be
   distributed between two PEPs located at each end of the satellite
   link.

2.3 Implementation Symmetry

   A PEP implementation may be symmetric or asymmetric.  Symmetric PEPs
   use identical behavior in both directions, i.e., the actions taken by
   the PEP occur independent from which interface a packet is received.
   Asymmetric PEPs operate differently in each direction.  The direction
   can be defined in terms of the link (e.g., from a central site to a
   remote site) or in terms of protocol traffic (e.g., the direction of
   TCP data flow, often called the TCP data channel, or the direction of
   TCP ACK flow, often called the TCP ACK channel).  An asymmetric PEP
   implementation is generally used at a point where the characteristics
   of the links on each side of the PEP differ or with asymmetric
   protocol traffic.  For example, an asymmetric PEP might be placed at
   the intersection of wired and wireless networks or an asymmetric
   application layer PEP might be used for the request-reply type of
   HTTP traffic.  A PEP implementation may also be both symmetric and
   asymmetric at the same time with regard to different mechanisms it
   employs.  (PEP mechanisms are described in Section 3.)

   Whether a PEP implementation is symmetric or asymmetric is
   independent of whether the PEP implementation is integrated or
   distributed.  In other words, a distributed PEP implementation might
   operate symmetrically at each end of a link (i.e., the two PEPs
   function identically).  On the other hand, a distributed PEP
   implementation might operate asymmetrically, with a different PEP
   implementation at each end of the link.  Again, this usually is used
   with asymmetric links.  For example, for a link with an asymmetric



Border, et al.               Informational                      [Page 6]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   amount of bandwidth available in each direction, the PEP on the end
   of the link forwarding traffic in the direction with a large amount
   of bandwidth might focus on locally acknowledging TCP traffic in
   order to use the available bandwidth.  At the same time, the PEP on
   the end of the link forwarding traffic in the direction with very
   little bandwidth might focus on reducing the amount of TCP
   acknowledgement traffic being forwarded across the link (to keep the
   link from congesting).

2.4 Split Connections

   A split connection TCP implementation terminates the TCP connection
   received from an end system and establishes a corresponding TCP
   connection to the other end system.  In a distributed PEP
   implementation, this is typically done to allow the use of a third
   connection between two PEPs optimized for the link.  This might be a
   TCP connection optimized for the link or it might be another
   protocol, for example, a proprietary protocol running on top of UDP.
   Also, the distributed implementation might use a separate connection
   between the proxies for each TCP connection or it might multiplex the
   data from multiple TCP connections across a single connection between
   the PEPs.

   In an integrated PEP split connection TCP implementation, the PEP
   again terminates the connection from one end system and originates a
   separate connection to the other end system.  [I-TCP] documents an
   example of a single PEP split connection implementation.

   Many integrated PEPs use a split connection implementation in order
   to address a mismatch in TCP capabilities between two end systems.
   For example, the TCP window scaling option [RFC1323] can be used to
   extend the maximum amount of TCP data which can be "in flight" (i.e.,
   sent and awaiting acknowledgement).  This is useful for filling a
   link which has a high bandwidth*delay product.  If one end system is
   capable of using scaled TCP windows but the other is not, the end
   system which is not capable can set up its connection with a PEP on
   its side of the high bandwidth*delay link.  The split connection PEP
   then sets up a TCP connection with window scaling over the link to
   the other end system.

   Split connection TCP implementations can effectively leverage TCP
   performance enhancements optimal for a particular link but which
   cannot necessarily be employed safely over the global Internet.

   Note that using split connection PEPs does not necessarily exclude
   simultaneous use of IP for end-to-end connectivity.  If a split
   connection is managed per application or per connection and is under
   the control of the end user, the user can decide whether a particular



Border, et al.               Informational                      [Page 7]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   TCP connection or application makes use of the split connection PEP
   or whether it operates end-to-end.  When a PEP is employed on a last
   hop link, the end user control is relatively easy to implement.

   In effect, application layer proxies for TCP-based applications are
   split connection TCP implementations with end systems using PEPs as a
   service related to a particular application.  Therefore, all
   transport (TCP) layer enhancements that are available with split
   connection TCP implementations can also be employed with application
   layer PEPs in conjunction with application layer enhancements.

2.5 Transparency

   Another key characteristic of a PEP is its degree of transparency.
   PEPs may operate totally transparently to the end systems, transport
   endpoints, and/or applications involved (in a connection), requiring
   no modifications to the end systems, transport endpoints, or
   applications.

   On the other hand, a PEP implementation may require modifications to
   both ends in order to be used.  In between, a PEP implementation may
   require modifications to only one of the ends involved.  Either of
   these kind of PEP implementations is non-transparent, at least to the
   layer requiring modification.

   It is sometimes useful to think of the degree of transparency of a
   PEP implementation at four levels, transparency with respect to the
   end systems (network-layer transparent PEP), transparency with
   respect to the transport endpoints (transport-layer transparent PEP),
   transparency with respect to the applications (application-layer
   transparent PEP) and transparency with respect to the users.  For
   example, a user who subscribes to a satellite Internet access service
   may be aware that the satellite terminal is providing a performance
   enhancing service even though the TCP/IP stack and the applications
   in the user's PC are not aware of the PEP which implements it.

   Note that the issue of transparency is not the same as the issue of
   maintaining end-to-end semantics.  For example, a PEP implementation
   which simply uses a TCP ACK spacing mechanism maintains the end-to-
   end semantics of the TCP connection while a split connection TCP PEP
   implementation may not.  Yet, both can be implemented transparently
   to the transport endpoints at both ends.  The implications of not
   maintaining the end-to-end semantics, in particular the end-to-end
   semantics of TCP connections, are discussed in Section 4.







Border, et al.               Informational                      [Page 8]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


3. PEP Mechanisms

   An obvious key characteristic of a PEP implementation is the
   mechanism(s) it uses to improve performance.  Some examples of PEP
   mechanisms are described in the following subsections.  A PEP
   implementation might implement more than one of these mechanisms.

3.1 TCP ACK Handling

   Many TCP PEP implementations are based on TCP ACK manipulation.  The
   handling of TCP acknowledgments can differ significantly between
   different TCP PEP implementations.  The following subsections
   describe various TCP ACK handling mechanisms.  Many implementations
   combine some of these mechanisms and possibly employ some additional
   mechanisms as well.

3.1.1 TCP ACK Spacing

   In environments where ACKs tend to bunch together, ACK spacing is
   used to smooth out the flow of TCP acknowledgments traversing a link.
   This improves performance by eliminating bursts of TCP data segments
   that the TCP sender would send due to back-to-back arriving TCP
   acknowledgments [BPK97].

3.1.2 Local TCP Acknowledgements

   In some PEP implementations, TCP data segments received by the PEP
   are locally acknowledged by the PEP.  This is very useful over
   network paths with a large bandwidth*delay product as it speeds up
   TCP slow start and allows the sending TCP to quickly open up its
   congestion window.  Local (negative) acknowledgments are often also
   employed to trigger local (and faster) error recovery on links with
   significant error rates.  (See Section 3.1.3.)

   Local acknowledgments are automatically employed with split
   connection TCP implementations.  When local acknowledgments are used,
   the burden falls upon the TCP PEP to recover any data which is
   dropped after the PEP acknowledges it.

3.1.3 Local TCP Retransmissions

   A TCP PEP may locally retransmit data segments lost on the path
   between the TCP PEP and the receiving end system, thus aiming at
   faster recovery from lost data.  In order to achieve this the TCP PEP
   may use acknowledgments arriving from the end system that receives
   the TCP data segments, along with appropriate timeouts, to determine





Border, et al.               Informational                      [Page 9]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   when to locally retransmit lost data.  TCP PEPs sending local
   acknowledgments to the sending end system are required to employ
   local retransmissions towards the receiving end system.

   Some PEP implementations perform local retransmissions even though
   they do not use local acknowledgments to alter TCP connection
   performance.  Basic Snoop [SNOOP] is a well know example of such a
   PEP implementation.  Snoop caches TCP data segments it receives and
   forwards and then monitors the end-to-end acknowledgments coming from
   the receiving TCP end system for duplicate acknowledgments (DUPACKs).
   When DUPACKs are received, Snoop locally retransmits the lost TCP
   data segments from its cache, suppressing the DUPACKs flowing to the
   sending TCP end system until acknowledgments for new data are
   received.  The Snoop system also implements an option to employ local
   negative acknowledgments to trigger local TCP retransmissions.  This
   can be achieved, for example, by applying TCP selective
   acknowledgments locally on the error-prone link.  (See Section 5.3
   for details.)

3.1.4 TCP ACK Filtering and Reconstruction

   On paths with highly asymmetric bandwidth the TCP ACKs flowing in the
   low-speed direction may get congested if the asymmetry ratio is high
   enough.  The ACK filtering and reconstruction mechanism addresses
   this by filtering the ACKs on one side of the link and reconstructing
   the deleted ACKs on the other side of the link.  The mechanism and
   the issue of dealing with TCP ACK congestion with highly asymmetric
   links are discussed in detail in [RFC2760] and in [BPK97].

3.2 Tunneling

   A Performance Enhancing Proxy may encapsulate messages to carry the
   messages across a particular link or to force messages to traverse a
   particular path.  A PEP at the other end of the encapsulation tunnel
   removes the tunnel wrappers before final delivery to the receiving
   end system.  A tunnel might be used by a distributed split connection
   TCP implementation as the means for carrying the connection between
   the distributed PEPs.  A tunnel might also be used to support forcing
   TCP connections which use asymmetric routing to go through the end
   points of a distributed PEP implementation.

3.3 Compression

   Many PEP implementations include support for one or more forms of
   compression.  In some PEP implementations, compression may even be
   the only mechanism used for performance improvement.  Compression
   reduces the number of bytes which need to be sent across a link.
   This is useful in general and can be very important for bandwidth



Border, et al.               Informational                     [Page 10]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   limited links.  Benefits of using compression include improved link
   efficiency and higher effective link utilization, reduced latency and
   improved interactive response time, decreased overhead and reduced
   packet loss rate over lossy links.

   Where appropriate, link layer compression is used.  TCP and IP header
   compression are also frequently used with PEP implementations.
   [RFC1144] describes a widely deployed method for compressing TCP
   headers.  Other header compression algorithms are described in
   [RFC2507], [RFC2508] and [RFC2509].

   Payload compression is also desirable and is increasing in importance
   with today's increased emphasis on Internet security.  Network (IP)
   layer (and above) security mechanisms convert IP payloads into random
   bit streams which defeat applicable link layer compression mechanisms
   by removing or hiding redundant "information."  Therefore,
   compression of the payload needs to be applied before security
   mechanisms are applied.  [RFC2393] defines a framework where common
   compression algorithms can be applied to arbitrary IP segment
   payloads.  However, [RFC2393] compression is not always applicable.
   Many types of IP payloads (e.g., images, audio, video and "zipped"
   files being transferred) are already compressed.  And, when security
   mechanisms such as TLS [RFC2246] are applied above the network (IP)
   layer, the data is already encrypted (and possibly also compressed),
   again removing or hiding any redundancy in the payload.  The
   resulting additional transport or network layer compression will
   compact only headers, which are small, and possibly already covered
   by separate compression algorithms of their own.

   With application layer PEPs one can employ application-specific
   compression.  Typically an application-specific (or content-specific)
   compression mechanism is much more efficient than any generic
   compression mechanism.  For example, a distributed Web PEP
   implementation may implement more efficient binary encoding of HTTP
   headers, or a PEP can employ lossy compression that reduces the image
   quality of online-images on Web pages according to end user
   instructions, thus reducing the number of bytes transferred over a
   slow link and consequently the response time perceived by the user
   [LHKR96].

3.4 Handling Periods of Link Disconnection with TCP

   Periods of link disconnection or link outages are very common with
   some wireless links.  During these periods, a TCP sender does not
   receive the expected acknowledgments.  Upon expiration of the
   retransmit timer, this causes TCP to close its congestion window with
   all of the related drawbacks.  A TCP PEP may monitor the traffic
   coming from the TCP sender towards the TCP receiver behind the



Border, et al.               Informational                     [Page 11]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   disconnected link.  The TCP PEP retains the last ACK, so that it can
   shut down the TCP sender's window by sending the last ACK with a
   window set to zero.  Thus, the TCP sender will go into persist mode.

   To make this work in both directions with an integrated TCP PEP
   implementation, the TCP receiver behind the disconnected link must be
   aware of the current state of the connection and, in the event of a
   disconnection, it must be capable of freezing all timers.  [M-TCP]
   implements such operation.  Another possibility is that the
   disconnected link is surrounded by a distributed PEP pair.

   In split connection TCP implementations, a period of link
   disconnection can easily be hidden from the end host on the other
   side of the PEP thus precluding the TCP connection from breaking even
   if the period of link disconnection lasts a very long time; if the
   TCP PEP cannot forward data due to link disconnection, it stops
   receiving data.  Normal TCP flow control then prevents the TCP sender
   from sending more than the TCP advertised window allowed by the PEP.
   Consequently, the PEP and its counterpart behind the disconnected
   link can employ a modified TCP version which retains the state and
   all unacknowledged data segments across the period of disconnection
   and then performs local recovery as the link is reconnected.  The
   period of link disconnection may or may not be hidden from the
   application and user, depending upon what application the user is
   using the TCP connection for.

3.5 Priority-based Multiplexing

   Implementing priority-based multiplexing of data over a slow and
   expensive link may significantly improve the performance and
   usability of the link for selected applications or connections.

   A user behind a slow link would experience the link more feasible to
   use in case of simultaneous data transfers, if urgent data transfers
   (e.g., interactive connections) could have shorter response time
   (better performance) than less urgent background transfers.  If the
   interactive connections transmit enough data to keep the slow link
   fully utilized, it might be necessary to fully suspend the background
   transfers for awhile to ensure timely delivery for the interactive
   connections.

   In flight TCP segments of an end-to-end TCP connection (with low
   priority) cannot be delayed for a long time.  Otherwise, the TCP
   timer at the sending end would expire, resulting in suboptimal
   performance.  However, this kind of operation can be controlled in
   conjunction with a split connection TCP PEP by assigning different
   priorities for different connections (or applications).  A split
   connection PEP implementation allows the PEP in an intermediate node



Border, et al.               Informational                     [Page 12]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   to delay the data delivery of a lower-priority TCP flow for an
   unlimited period of time by simply rescheduling the order in which it
   forwards data of different flows to the destination host behind the
   slow link.  This does not have a negative impact on the delayed TCP
   flow as normal TCP flow control takes care of suspending the flow
   between the TCP sender and the PEP, when the PEP is not forwarding
   data for the flow, and resumes it once the PEP decides to continue
   forwarding data for the flow.  This can further be assisted, if the
   protocol stacks on both sides of the slow link implement priority
   based scheduling of connections.

   With such a PEP implementation, along with user-controlled
   priorities, the user can assign higher priority for selected
   interactive connection(s) and have much shorter response time for the
   selected connection(s), even if there are simultaneous low priority
   bulk data transfers which in regular end-to-end operation would
   otherwise eat the available bandwidth of the slow link almost
   completely.  These low priority bulk data transfers would then
   proceed nicely during the idle periods of interactive connections,
   allowing the user to keep the slow and expensive link (e.g., wireless
   WAN) fully utilized.

   Other priority-based mechanisms may be applied on shared wireless
   links with more than two terminals.  With shared wireless mediums
   becoming a weak link in Internet QoS architectures, many may turn to
   PEPs to provide extra priority levels across a shared wireless medium
   [SHEL00].  These PEPs are distributed on all nodes of the shared
   wireless medium.  For example, in an 802.11 WLAN this PEP is
   implemented in the access point (base station) and each mobile host.
   One PEP then uses distributed queuing techniques to coordinate
   traffic classes of all nodes.  This is also sometimes called subnet
   bandwidth management.  See [BBKT97] for an example of queuing
   techniques which can be used to achieve this.  This technique can be
   implemented either above or below the IP layer.  Priority treatment
   can typically be specified either by the user or by marking the
   (IPv4) ToS or (IPv6) Traffic Class IP header field.

3.6 Protocol Booster Mechanisms

   Work in [FMSBMR98] shows a range of other possible PEP mechanisms
   called protocol boosters.  Some of these mechanisms are specific to
   UDP flows.  For example, a PEP may apply asymmetrical methods such as
   extra UDP error detection.  Since the 16 bit UDP checksum is
   optional, it is typically not computed.  However, for links with
   errors, the checksum could be beneficial.  This checksum can be added
   to outgoing UDP packets by a PEP.





Border, et al.               Informational                     [Page 13]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   Symmetrical mechanisms have also been developed.  A Forward Erasure
   Correction (FZC) mechanism can be used with real-time and multicast
   traffic.  The encoding PEP adds a parity packet over a block of
   packets.  Upon reception, the parity is removed and missing data is
   regenerated.  A jitter control mechanism can be implemented at the
   expense of extra latency.  A sending PEP can add a timestamp to
   outgoing packets.  The receiving PEP then delays packets in order to
   reproduce the correct interval.

4. Implications of Using PEPs

   The following sections describe some of the implications of using
   Performance Enhancing Proxies.

4.1 The End-to-end Argument

   As indicated in [RFC1958], the end-to-end argument [SRC84] is one of
   the architectural principles of the Internet.  The basic argument is
   that, as a first principle, certain required end-to-end functions can
   only be correctly performed by the end systems themselves.  Most of
   the potential negative implications associated with using PEPs are
   related to the possibility of breaking the end-to-end semantics of
   connections.  This is one of the main reasons why PEPs are not
   recommended for general use.

   As indicated in Section 2.5, not all PEP implementations break the
   end-to-end semantics of connections.  Correctly designed PEPs do not
   attempt to replace any application level end-to-end function, but
   only attempt to add performance optimizations to a subpath of the
   end-to-end path between the application endpoints.  Doing this can be
   consistent with the end-to-end argument.  However, a user or network
   administrator adding a PEP to his network configuration should be
   aware of the potential end-to-end implications related to the
   mechanisms being used by the particular PEP implementation.

4.1.1 Security

   In most cases, security applied above the transport layer can be used
   with PEPs, especially transport layer PEPs.  However, today, only a
   limited number of applications include support for the use of
   transport (or higher) layer security.  Network (IP) layer security
   (IPsec) [RFC2401], on the other hand, can generally be used by any
   application, transparently to the application.








Border, et al.               Informational                     [Page 14]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


4.1.1.1 Security Implications

   The most detrimental negative implication of breaking the end-to-end
   semantics of a connection is that it disables end-to-end use of
   IPsec.  In general, a user or network administrator must choose
   between using PEPs and using IPsec.  If IPsec is employed end-to-end,
   PEPs that are implemented on intermediate nodes in the network cannot
   examine the transport or application headers of IP packets because
   encryption of IP packets via IPsec's ESP header (in either transport
   or tunnel mode) renders the TCP header and payload unintelligible to
   the PEPs.  Without being able to examine the transport or application
   headers, a PEP may not function optimally or at all.

   If a PEP implementation is non-transparent to the users and the users
   trust the PEP in the middle, IPsec can be used separately between
   each end system and PEP.  However, in most cases this is an
   undesirable or unacceptable alternative as the end systems cannot
   trust PEPs in general.  In addition, this is not as secure as end-
   to-end security.  (For example, the traffic is exposed in the PEP
   when it is decrypted to be processed.)  And, it can lead to
   potentially misleading security level assumptions by the end systems.
   If the two end systems negotiate different levels of security with
   the PEP, the end system which negotiated the stronger level of
   security may not be aware that a lower level of security is being
   provided for part of the connection.  The PEP could be implemented to
   prevent this from happening by being smart enough to force the same
   level of security to each end system but this increases the
   complexity of the PEP implementation (and still is not as secure as
   end-to-end security).

   With a transparent PEP implementation, it is difficult for the end
   systems to trust the PEP because they may not be aware of its
   existence.  Even if the user is aware of the PEP, setting up
   acceptable security associations with the PEP while maintaining the
   PEP's transparent nature is problematic (if not impossible).

   Note that even when a PEP implementation does not break the end-to-
   end semantics of a connection, the PEP implementation may not be able
   to function in the presence of IPsec.  For example, it is difficult
   to do ACK spacing if the PEP cannot reliably determine which IP
   packets contain ACKs of interest.  In any case, the authors are
   currently not aware of any PEP implementations, transparent or non-
   transparent, which provide support for end-to-end IPsec, except in a
   case where the PEPs are implemented on the end hosts.







Border, et al.               Informational                     [Page 15]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


4.1.1.2 Security Implication Mitigations

   There are some steps which can be taken to allow the use of IPsec and
   PEPs to coexist.  If an end user can select the use of IPsec for some
   traffic and not for other traffic, PEP processing can be applied to
   the traffic sent without IPsec.  Of course, the user must then do
   without security for this traffic or provide security for the traffic
   via other means (for example, by using transport layer security).
   However, even when this is possible, significant complexity may need
   to be added to the configuration of the end system.

   Another alternative is to implement IPsec between the two PEPs of a
   distributed PEP implementation.  This at least protects the traffic
   between the two PEPs.  (The issue of trusting the PEPs does not
   change.)  In the case where the PEP implementation is not transparent
   to the user, (assuming that the user trusts the PEPs,) the user can
   configure his end system to use the PEPs as the end points of an
   IPsec tunnel.  And, an IPsec tunnel could even potentially be used
   between the end system and a PEP to protect traffic on this part of
   the path.  But, all of this adds complexity.  And, it still does not
   eliminate the risk of the traffic being exposed in the PEP itself as
   the traffic is received from one IPsec tunnel, processed and then
   forwarded (even if forwarded through another IPsec tunnel).

4.1.1.3 Security Research Related to PEPs

   There is research underway investigating the possibility of changing
   the implementation of IPsec to be more friendly to the use of PEPs.
   One approach being actively looked at is the use of multi-layer IP
   security.  [Zhang00] describes a method which allows TCP headers to
   be encrypted as one layer (with the PEPs in the path of the TCP
   connections included in the security associations used to encrypt the
   TCP headers) while the TCP payload is encrypted end-to-end as a
   separate layer.  This still involves trusting the PEP, but to a much
   lesser extent.  However, a drawback to this approach is that it adds
   a significant amount of complexity to the IP security implementation.
   Given the existing complexity of IPsec, this drawback is a serious
   impediment to the standardization of the multi-layer IP security idea
   and it is very unlikely that this approach will be adopted as a
   standard any time soon.  Therefore, relying on this type of approach
   will likely involve the use of non-standard protocols (and the
   associated risk of doing so).

4.1.2 Fate Sharing

   Another important aspect of the end-to-end argument is fate sharing.
   If a failure occurs in the network, the ability of the connection to
   survive the failure depends upon how much state is being maintained



Border, et al.               Informational                     [Page 16]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   on behalf of the connection in the network and whether the state is
   self-healing.  If no connection specific state resides in the network
   or such state is self-healing as in case of regular end-to-end
   operation, then a failure in the network will break the connection
   only if there is no alternate path through the network between the
   end systems.  And, if there is no path, both end systems can detect
   this.  However, if the connection depends upon some state being
   stored in the network (e.g., in a PEP), then a failure in the network
   (e.g., the node containing a PEP crashes) causes this state to be
   lost, forcing the connection to terminate even if an alternate path
   through the network exists.

   The importance of this aspect of the end-to-end argument with respect
   to PEPs is dependent upon both the PEP implementation and upon the
   types of applications being used.  Sometimes coincidentally but more
   often by design, PEPs are used in environments where there is no
   alternate path between the end systems and, therefore, a failure of
   the intermediate node containing a PEP would result in the
   termination of the connection in any case.  And, even when this is
   not the case, the risk of losing the connection in the case of
   regular end-to-end operation may exist as the connection could break
   for some other reason, for example, a long enough link outage of a
   last-hop wireless link to the end host.  Therefore, users may choose
   to accept the risk of a PEP crashing in order to take advantage of
   the performance gains offered by the PEP implementation.  The
   important thing is that accepting the risk should be under the
   control of the user (i.e., the user should always have the option to
   choose end-to-end operation) and, if the user chooses to use the PEP,
   the user should be aware of the implications that a PEP failure has
   with respect to the applications being used.

4.1.3 End-to-end Reliability

   Another aspect of the end-to-end argument is that of acknowledging
   the receipt of data end-to-end in order to achieve reliable end-to-
   end delivery of data.  An application aiming at reliable end-to-end
   delivery must implement an end-to-end check and recovery at the
   application level.  According to the end-to-end argument, this is the
   only possibility to correctly implement reliable end-to-end
   operation.  Otherwise the application violates the end-to-end
   argument.  This also means that a correctly designed application can
   never fully rely on the transport layer (e.g., TCP) or any other
   communication subsystem to provide reliable end-to-end delivery.

   First, a TCP connection may break down for some reason and result in
   lost data that must be recovered at the application level.  Second,
   the checksum provided by TCP may be considered inadequate, resulting
   in undetected (by TCP) data corruption [Pax99] and requiring an



Border, et al.               Informational                     [Page 17]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   application level check for data corruption.  Third, a TCP
   acknowledgement only indicates that data was delivered to the TCP
   implementation on the other end system.  It does not guarantee that
   the data was delivered to the application layer on the other end
   system.  Therefore, a well designed application must use an
   application layer acknowledgement to ensure end-to-end delivery of
   application layer data.  Note that this does not diminish the value
   of a reliable transport protocol (i.e., TCP) as such a protocol
   allows efficient implementation of several essential functions (e.g.,
   congestion control) for an application.

   If a PEP implementation acknowledges application data prematurely
   (before the PEP receives an application ACK from the other endpoint),
   end-to-end reliability cannot be guaranteed.  Typically, application
   layer PEPs do not acknowledge data prematurely, i.e., the PEP does
   not send an application ACK to the sender until it receives an
   application ACK from the receiver.  And, transport layer PEP
   implementations, including TCP PEPs, generally do not interfere with
   end-to-end application layer acknowledgments as they let applications
   operate end-to-end.  However, the user and/or network administrator
   employing the PEP must understand how it operates in order to
   understand the risks related to end-to-end reliability.

   Some Internet applications do not necessarily operate end-to-end in
   their regular operation, thus abandoning any end-to-end reliability
   guarantee.  For example, Internet email delivery often operates via
   relay Mail Transfer Agents, that is, relay Simple Mail Transfer
   Protocol (SMTP) servers.  An originating MTA (SMTP server) sends the
   mail message to a relay MTA that receives the mail message, stores it
   in non-volatile storage (e.g., on disk) and then sends an application
   level acknowledgement.  The relay MTA then takes "full
   responsibility" for delivering the mail message to the destination
   SMTP server (maybe via another relay MTA); it tries to forward the
   message for a relatively long time (typically around 5 days).  This
   scheme does not give a 100% guarantee of email delivery, but
   reliability is considered "good enough".

   An application layer PEP for this kind of an application may
   acknowledge application data (e.g., mail message) without essentially
   decreasing reliability, as long as the PEP operates according to the
   same procedure as the regular proxy (e.g., relay MTA).  Again, as
   indicated above, the user and/or network administrator employing such
   a PEP needs to understand how it operates in order to understand the
   reliability risks associated with doing so.







Border, et al.               Informational                     [Page 18]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


4.1.4 End-to-end Failure Diagnostics

   Another aspect of the end-to-end argument is the ability to support
   end-to-end failure diagnostics when problems are encountered.  If a
   network problem occurs which breaks a connection, the end points of
   the connection will detect the failure via timeouts.  However, the
   existence of a PEP in between the two end points could delay
   (sometimes significantly) the detection of the failure by one or both
   of the end points.  (Of course, some PEPs are intentionally designed
   to hide these types of failures as described in Section 3.4.)  The
   implications of delayed detection of a failed connection depend on
   the applications being used.  Possibilities range from no impact at
   all (or just minor annoyance to the end user) all the way up to
   impacting mission critical business functions by delaying switchovers
   to alternate communications paths.

   In addition, tools used to debug connection failures may be affected
   by the use of a PEP.  For example, PING (described in [RFC792] and
   [RFC2151]) is often used to test for connectivity.  But, because PING
   is based on ICMP instead of TCP (i.e., it is implemented using ICMP
   Echo and Reply commands at the network layer), it is possible that
   the configuration of the network might route PING traffic around the
   PEP.  Thus, PING could indicate that an end-to-end path exists
   between two hosts when it does not actually exist for TCP traffic.
   Even when the PING traffic does go through the PEP, the diagnostics
   indications provided by the PING traffic are altered.  For example,
   if the PING traffic goes transparently through the PEP, PING does not
   provide any indication that the PEP exists and since the PING traffic
   is not being subjected to the same processing as TCP traffic, it may
   not necessarily provide an accurate indication of the network delay
   being experienced by TCP traffic.  On the other hand, if the PEP
   terminates the PING and responds to it on behalf of the end host,
   then the PING provides information only on the connectivity to the
   PEP.  Traceroute (also described in [RFC2151]) is similarly affected
   by the presence of the PEP.

4.2 Asymmetric Routing

   Deploying a PEP implementation usually requires that traffic to and
   from the end hosts is routed through the intermediate node(s) where
   PEPs reside.  With some networks, this cannot be accomplished, or it
   might require that the intermediate node is located several hops away
   from the target link edge which in turn is impractical in many cases
   and may result in non-optimal routing.







Border, et al.               Informational                     [Page 19]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   Note that this restriction does not apply to all PEP implementations.
   For example, a PEP which is simply doing ACK spacing only needs to
   see one direction of the traffic flow (the direction in which the
   ACKs are flowing).  ACK spacing can be done without seeing the actual
   flow of data.

4.3 Mobile Hosts

   In environments where a PEP implementation is used to serve mobile
   hosts, additional problems may be encountered because PEP related
   state information may need to be transferred to a new PEP node during
   a handoff.

   When a mobile host moves, it is subject to handovers.  If the
   intermediate node and home for the serving PEP changes due to
   handover, any state information that the PEP maintains and is
   required for continuous operation must be transferred to the new
   intermediate node to ensure continued operation of the connection.
   This requires extra work and overhead and may not be possible to
   perform fast enough, especially if the host moves frequently over
   cell boundaries of a wireless network.  If the mobile host moves to
   another IP network, routing to and from the mobile host may need to
   be changed to traverse a new PEP node.

   Today, mobility implications with respect to using PEPs are more
   significant to W-LAN networks than to W-WAN networks.  Currently, a
   W-WAN base station typically does not provide the mobile host with
   the connection point to the wireline Internet.  (A W-WAN base station
   may not even have an IP stack.)  Instead, the W-WAN network takes
   care of mobility with the connection point to the wireline Internet
   remaining unchanged while the mobile host moves.  Thus, PEP state
   handover is not currently required in most W-WAN networks when the
   host moves.  However, this is generally not true in W-LAN networks
   and, even in the case of W-WAN networks, the user and/or network
   administrator using a PEP needs to be cognizant of how the W-WAN base
   stations and the PEP work in case W-WAN PEP state handoff becomes
   necessary in the future.

4.4 Scalability

   Because a PEP typically processes packet information above the IP
   layer, a PEP requires more processing power per packet than a router.
   Therefore, PEPs will always be (at least) one step behind routers in
   terms of the total throughput they can support.  (Processing above
   the IP layer is also more difficult to implement in hardware.)  In
   addition, since most PEP implementations require per connection
   state, PEP memory requirements are generally significantly higher




Border, et al.               Informational                     [Page 20]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   than with a router.  Therefore, a PEP implementation may have a limit
   on the number of connections which it can support whereas a router
   has no such limitation.

   Increased processing power and memory requirements introduce
   scalability issues with respect to the use of PEPs.  Placement of a
   PEP on a high speed link or a link which supports a large number of
   connections may require network topology changes beyond just
   inserting the PEP into the path of the traffic.  For example, if a
   PEP can only handle half of the traffic on a link, multiple PEPs may
   need to be used in parallel, adding complexity to the network
   configuration to divide the traffic between the PEPs.

4.5 Other Implications of Using PEPs

   This document describes some significant implications with respect to
   using Performance Enhancing Proxies.  However, the list of
   implications provided in this document is not necessarily exhaustive.
   Some examples of other potential implications related to using PEPs
   include the use of PEPs in multi-homing environments and the use of
   PEPs with respect to Quality of Service (QoS) transparency.  For
   example, there may be potential interaction with the priority-based
   multiplexing mechanism described in Section 3.5 and the use of
   differentiated services [RFC2475].  Therefore, users and network
   administrators who wish to deploy a PEP should look not only at the
   implications described in this document but also at the overall
   impact (positive and negative) that the PEP will have on their
   applications and network infrastructure, both initially and in the
   future when new applications are added and/or changes in the network
   infrastructure are required.

5. PEP Environment Examples

   The following sections describe examples of environments where PEP is
   currently used to improve performance.  The examples are provided to
   illustrate the use of the various PEP types and PEP mechanisms
   described earlier in the document and to help illustrate the
   motivation for their development and use.

5.1 VSAT Environments

   Today, VSAT networks are implemented with geosynchronous satellites.
   VSAT data networks are typically implemented using a star topology.
   A large hub earth station is located at the center of the star with
   VSATs used at the remote sites of the network.  Data is sent from the
   hub to the remote sites via an outroute.  Data is sent from the
   remote sites to the hub via one or more inroutes.  VSATs represent an
   environment with highly asymmetric links, with an outroute typically



Border, et al.               Informational                     [Page 21]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   much larger than an inroute.  (Multiple inroutes can be used with
   each outroute but any particular VSAT only has access to a single
   inroute at a time, making the link asymmetric.)

   VSAT networks are generally used to implement private networks (i.e.,
   intranets) for enterprises (e.g., corporations) with geographically
   dispersed sites.  VSAT networks are rarely, if ever, used to
   implement Internet connectivity except at the edge of the Internet
   (i.e., as the last hop).  Connection to the Internet for the VSAT
   network is usually implemented at the VSAT network hub site using
   appropriate firewall and (when necessary) NAT [RFC2663] devices.

5.1.1 VSAT Network Characteristics

   With respect to TCP performance, VSAT networks exhibit the following
   subset of the satellite characteristics documented in [RFC2488]:

   Long feedback loops

      Propagation delay from a sender to a receiver in a geosynchronous
      satellite network can range from 240 to 280 milliseconds,
      depending on where the sending and receiving sites are in the
      satellite footprint.  This makes the round trip time just due to
      propagation delay at least 480 milliseconds.  Queueing delay and
      delay due to shared channel access methods can sometimes increase
      the total delay up to on the order of a few seconds.

   Large bandwidth*delay products

      VSAT networks can support capacity ranging from a few kilobits per
      second up to multiple megabits per second.  When combined with the
      relatively long round trip time, TCP needs to keep a large number
      of packets "in flight" in order to fully utilize the satellite
      link.

   Asymmetric capacity

      As indicated above, the outroute of a VSAT network is usually
      significantly larger than an inroute.  Even though multiple
      inroutes can be used within a network, a given VSAT can only
      access one inroute at a time.  Therefore, the incoming (outroute)
      and outgoing (inroute) capacity for a VSAT is often very
      asymmetric.  As outroute capacity has increased in recent years,
      ratios of 400 to 1 or greater are becoming more and more common.
      With a TCP maximum segment size of 1460 bytes and delayed
      acknowledgments [RFC1122] in use, the ratio of IP packet bytes for
      data to IP packet bytes for ACKs is only (3000 to 40) 75 to 1.




Border, et al.               Informational                     [Page 22]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


      Thus, inroute capacity for carrying ACKs can have a significant
      impact on TCP performance.  (The issue of asymmetric link impact
      on TCP performance is described in more detail in [BPK97].)

   With respect to the other satellite characteristics listed in
   [RFC2488], VSAT networks typically do not suffer from intermittent
   connectivity or variable round trip times.  Also, VSAT networks
   generally include a significant amount of error correction coding.
   This makes the bit error rate very low during clear sky conditions,
   approaching the bit error rate of a typical terrestrial network.  In
   severe weather, the bit error rate may increase significantly but
   such conditions are rare (when looked at from an overall network
   availability point of view) and VSAT networks are generally
   engineered to work during these conditions but not to optimize
   performance during these conditions.

5.1.2 VSAT Network PEP Implementations

   Performance Enhancing Proxies implemented for VSAT networks generally
   focus on improving throughput (for applications such as FTP and HTTP
   web page retrievals).  To a lesser degree, PEP implementations also
   work to improve interactive response time for small transactions.

   There is not a dominant PEP implementation used with VSAT networks.
   Each VSAT network vendor tends to implement their own version of PEP
   functionality, integrated with the other features of their VSAT
   product.  [HNS] and [SPACENET] describe VSAT products with integrated
   PEP capabilities.  There are also third party PEP implementations
   designed to be used with VSAT networks.  These products run on nodes
   external to the VSAT network at the hub and remote sites.  NettGain
   [FLASH] and Venturi [FOURELLE] are examples of such products.  VSAT
   network PEP implementations generally share the following
   characteristics:

      - They focus on improving TCP performance;

      - They use an asymmetric distributed implementation;

      - They use a split connection approach with local acknowledgments
        and local retransmissions;

      - They support some form of compression to reduce the amount of
        bandwidth required (with emphasis on saving inroute bandwidth).

   The key differentiators between VSAT network PEP implementations are:

      - The maximum throughput they attempt to support (mainly a
        function of the amount of buffer space they use);



Border, et al.               Informational                     [Page 23]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


      - The protocol used over the satellite link.  Some implementations
        use a modified version of TCP while others use a proprietary
        protocol running on top of UDP;

      - The type of compression used.  Third party VSAT network PEP
        implementations generally focus on application (e.g., HTTP)
        specific compression algorithms while PEP implementations
        integrated into the VSAT network generally focus on link
        specific compression.

   PEP implementations integrated into a VSAT product are generally
   transparent to the end systems.  Third party PEP implementations used
   with VSAT networks usually require configuration changes in the
   remote site end systems to route TCP packets to the remote site
   proxies but do not require changes to the hub site end systems.  In
   some cases, the PEP implementation is actually integrated
   transparently into the end system node itself, using a "bump in the
   stack" approach.  In all cases, the use of a PEP is non-transparent
   to the user, i.e., the user is aware when a PEP implementation is
   being used to boost performance.

5.1.3 VSAT Network PEP Motivation

   VSAT networks, since the early stages of their deployment, have
   supported the use of local termination of a protocol (e.g., SDLC and
   X.25) on each side of the satellite link to hide the satellite link
   from the applications using the protocol.  Therefore, when LAN
   capabilities were added to VSAT networks, VSAT customers expected
   and, in fact, demanded, the use of similar techniques for improving
   the performance of IP based traffic, in particular TCP traffic.

   As indicated in Section 5.1, VSAT networks are primarily used to
   implement intranets with Internet connectivity limited to and closely
   controlled at the hub site of the VSAT network.  Therefore, VSAT
   customers are not as affected (or at least perceive that they are not
   as affected) by the Internet related implications of using PEPs as
   are other technologies.  Instead, what is more important to VSAT
   customers is the optimization of the network.  And, VSAT customers,
   in general, prefer that the optimization of the network be done by
   the network itself rather than by implementing changes (such as
   enabling the TCP scaled window option) to their own equipment.  VSAT
   customers prefer to optimize their end system configuration for local
   communications related to their local mission critical functions and
   let the VSAT network hide the presence of the satellite link as much
   as possible.  VSAT network vendors have also been able to use PEP
   functionality to provide value added "services" to their customers
   such as extending the useful of life of older equipment which
   includes older, "non-modern" TCP stacks.



Border, et al.               Informational                     [Page 24]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   Of course, as the line between intranets and the Internet continues
   to fade, the implications of using PEPs start to become more
   significant for VSAT networks.  For example, twelve years ago
   security was not a major concern because the equipment cost related
   to being able to intercept VSAT traffic was relatively high.  Now, as
   technology has advanced, the cost is much less prohibitive.
   Therefore, because the use of PEP functionality in VSAT networks
   prevents the use of IPsec, customers must rely on the use of higher
   layer security mechanisms such as TLS or on proprietary security
   mechanisms implemented in the VSAT networks themselves (since
   currently many applications are incapable of making (or simply don't
   make) use of the standardized higher layer security mechanisms).
   This, in turn, affects the cost of the VSAT network as well as
   affects the ability of the customers to make use of Internet based
   capabilities.

5.2 W-WAN Environments

   In mobile wireless WAN (W-WAN) environments the wireless link is
   typically used as the last-hop link to the end user.  W-WANs include
   such networks as GSM [GSM], GPRS [GPRS],[BW97], CDPD [CDPD], IS-95
   [CDMA], RichoNet, and PHS.  Many of these networks, but not all, have
   been designed to provide mobile telephone voice service in the first
   place but include data services as well or they evolve from a mobile
   telephone network.

5.2.1 W-WAN Network Characteristics

   W-WAN links typically exhibit some combination of the following link
   characteristics:

      -  low bandwidth (with some links the available bandwidth might be
         as low as a few hundred bits/sec)

      -  high latency (minimum round-trip delay close to one second is
         not exceptional)

      -  high BER resulting in frame or packet losses, or long variable
         delays due to local link-layer error recovery

      -  some W-WAN links have a lot of internal buffer space which tend
         to accumulate data, thus resulting in increased round-trip
         delay due to long (and variable) queuing delays

      -  on some W-WAN links the users may share common channels for
         their data packet delivery which, in turn, may cause unexpected
         delays to the packet delivery of a user due to simultaneous use
         of the same channel resources by the other users



Border, et al.               Informational                     [Page 25]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


      -  unexpected link disconnections (or intermittent link outages)
         may occur frequently and the period of disconnection may last a
         very long time

      -  (re)setting the link-connection up may take a long time
         (several tens of seconds or even minutes)

      -  the W-WAN network typically takes care of terminal mobility:
         the connection point to the Internet is retained while the user
         moves with the mobile host

      -  the use of most W-WAN links is expensive.  Many of the service
         providers apply time-based charging.

5.2.2 W-WAN PEP Implementations

   Performance Enhancing Proxies implemented for W-WAN environments
   generally focus on improving the interactive response time but at the
   same time aim at improving throughput, mainly by reducing the
   transfer volume over the inherently slow link in various ways.  To
   achieve this, typically enhancements are applied at almost all
   protocol layers.

5.2.2.1 Mowgli System

   The Mowgli system [KRA94] is one of the early approaches to address
   the challenges induced by the problematic characteristics of low
   bandwidth W-WAN links.

   The indirect approach used in Mowgli is not limited to a single layer
   as in many other split connection approaches, but it involves all
   protocol layers.  The basic architecture is based on split TCP (UDP
   is also supported) together with full support for application layer
   proxies with a distributed PEP approach.  An application layer proxy
   pair may be added between a client and server, the agent (local
   proxy) on a mobile host and the proxy on an intermediate node that
   provides the mobile host with the connection to the wireline
   Internet.  Such a pair may be either explicit or fully transparent to
   the applications, but it is, at all times, under end-user control
   thus allowing the user to select the traffic that traverses through
   the PEP implementation and choose end-to-end IP for other traffic.

   In order to allow running legacy applications unmodified and without
   recompilation, the socket layer implementation on the mobile host is
   slightly modified to connect the applications, which are configured
   to traverse through the PEP, to a local agent while retaining the
   original TCP/IP socket semantics.  Two types of application layer
   agent-proxy pairs can be configured for mobile host application use.



Border, et al.               Informational                     [Page 26]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   A generic pair can be used with any application and it simply
   provides split transport service with some optional generic
   enhancements like compression.  An application-specific pair can be
   retailed for any application or a group of applications that are able
   to take leverage on the same kind of enhancements.  A good example of
   enhancements achieved with an application-specific proxy pair is the
   Mowgli WWW system that improves significantly the user perceived
   response time of Web browsing mainly by reducing the transfer volume
   and the number of round trips over the wireless link [LAKLR95],
   [LHKR96].

   Mowgli provides also an option to replace the TCP/IP core protocols
   on the last-hop link with a custom protocol that is tuned for low-
   bandwidth W-WAN links [KRLKA97].  This protocol was designed to
   provide the same transport service with similar semantics as regular
   TCP and UDP provide, but use a different protocol implementation that
   can freely apply any appropriate protocol mechanisms without being
   constrained by the current TCP/IP packet format or protocol
   operation.  As this protocol is required to operate over a single
   logical link only, it could partially combine the protocol control
   information and protocol operation of the link, network, and
   transport layers.  In addition, the protocol can operate on top of
   various link services, for example on top of different raw link
   services, on top of PPP, on top of IP, or even on top of a single TCP
   connection using it as a link service and implementing "TCP
   multiplexing" over it.  In all other cases, except when the protocol
   is configured to operate on top of raw (wireless) link service, IP
   may co-exist with the custom protocol allowing simultaneous end-to-
   end IP delivery for the traffic not traversing through the PEP
   implementation.

   Furthermore, the custom protocol can be run in different operation
   modes which turn on or off certain protocol functions depending on
   the underlying link service.  For example, if the underlying link
   service provides reliable data delivery, the checksum and the
   window-based error recovery can be turned off, thus reducing the
   protocol overhead; only a very simple recovery mechanism is needed to
   allow recovery from an unexpected link disconnection.  Therefore, the
   protocol design was able to use extremely efficient header encoding
   (only 1-3 bytes per packet in a typical case), reduce the number of
   round trips significantly, and various features that are useful with
   low-bandwidth W-WAN links were easy to add.  Such features include
   suspending the protocol operation over the periods of link
   disconnection or link outage together with fast start once the link
   becomes operational again, priority-based multiplexing of user data
   over the W-WAN link thus offering link capacity to interactive





Border, et al.               Informational                     [Page 27]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   applications in a timely manner even in presence of bandwidth-
   intensive background transfers, and link-level flow control to
   prevent data from accumulating into the W-WAN link internal buffers.

   If desired, regular TCP/IP transport, possibly with corresponding
   protocol modifications in TCP (and UDP) that would tune it more
   suitable for W-WAN links, can be employed on the last-hop link.

5.2.2.2 Wireless Application Protocol (WAP)

   The Mowgli system was designed to support mobile hosts that are
   attached to the Internet over constrained links, but did not address
   the specific challenges with low-end mobile devices.  Many mobile
   wireless devices are power, memory, and processing constrained, and
   the communication links to these devices have lower bandwidth and
   less stable connections.  These limitations led designers to develop
   the Wireless Application Protocol (WAP) that specifies an application
   framework and network protocols intended to work across differing
   narrowband wireless network technologies bringing Internet content
   and advanced data services to low-end digital cellular phones and
   other mobile wireless terminals, such as pagers and PDAs.

   The WAP model consists of a WAP client (mobile terminal), a WAP
   proxy, and an origin server.  It requires a WAP proxy between the WAP
   client and the server on the Internet.  WAP uses a layered, scalable
   architecture [WAPARCH], specifying the following five protocol layers
   to be used between the terminal and the proxy: Application Layer
   (WAE) [WAPWAE], Session Layer (WSP) [WAPWSP], Transaction Layer (WTP)
   [WAPWTP], Security Layer (WTLS) [WAPWTLS], and Transport Layer (WDP)
   [WAPWDP].  Standard Internet protocols are used between the proxy and
   the origin server.  If the origin server includes WAP proxy
   functionality, it is called a WAP Server.

   In a typical scenario, a WAP client sends an encoded WAP request to a
   WAP proxy.  The WAP proxy translates the WAP request into a WWW
   (HTTP) request, performing the required protocol conversions, and
   submits this request to a standard web server on the Internet.  After
   the web server responds to the WAP proxy, the response is encoded
   into a more compact binary format to decrease the size of the data
   over the air.  This encoded response is forwarded to the WAP client
   [WAPPROXY].

   WAP operates over a variety of bearer datagram services.  When
   communicating over these bearer services, the WAP transport layer
   (WDP) is always used between the WAP client and WAP proxy and it
   provides port addressed datagram service to the higher WAP layers.
   If the bearer service supports IP (e.g., GSM-CSD, GSM-GPRS, IS-136,
   CDPD), UDP is used as the datagram protocol.  However, if the bearer



Border, et al.               Informational                     [Page 28]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   service does not support IP (e.g., GSM-SMS, GSM-USSD, GSM Cell
   Broadcast, CDMS-SMS, TETRA-SDS), WDP implements the required datagram
   protocol as an adaptation layer between the bearer network and the
   protocol stack.

   The use of the other layers depends on the port number.  WAP has
   registered a set of well-known ports with IANA.  The port number
   selected by the application for communication between a WAP client
   and proxy defines the other layers to be used at each end.  The
   security layer, WTLS, provides privacy, data integrity and
   authentication.  Its functionality is similar to TLS 1.0 [RFC2246]
   extended with datagram support, optimized handshake and dynamic key
   refreshing.  If the origin server includes WAP proxy functionality,
   it might be used to facilitate the end-to-end security solutions,
   otherwise it provides security between the mobile terminal and the
   proxy.

   The transaction layer, WTP, is message based without connection
   establishment and tear down.  It supports three types of transaction
   classes: an unconfirmed request (unidirectional), a reliable
   (confirmed) request (unidirectional), and a reliable (confirmed)
   request-reply transaction.  Data is carried in the first packet and
   3-way handshake is eliminated to reduce latencies.  In addition
   acknowledgments, retransmission, and flow control are provided.  It
   allows more than one outstanding transaction at a time.  It handles
   the bearer dependence of a transfer, e.g., selects timeout values and
   packet sizes according to the bearer.  Unfortunately, WTP uses fixed
   retransmission timers and does not include congestion control, which
   is a potential problem area as the use of WAP increases [RFC3002].

   The session layer, WSP, supports binary encoded HTTP 1.1 with some
   extensions such as long living session with suspend/resume facility
   and state handling, header caching, and push facility.  On top of the
   architecture is the application environment (WAE).

5.2.3 W-WAN PEP Motivation

   As indicated in Section 5.2.1, W-WAN networks typically offer very
   low bandwidth connections with high latency and relatively frequent
   periods of link disconnection and they usually are expensive to use.
   Therefore, the transfer volume and extra round-trips, such as those
   associated with TCP connection setup and teardown, must be reduced
   and the slow W-WAN link should be efficiently shielded from excess
   traffic and global (wired) Internet congestion to make Internet
   access usable and economical.  Furthermore, interactive traffic must
   be transmitted in a timely manner even if there are other
   simultaneous bandwidth intensive (background) transfers and during
   the periods with connectivity the link must be kept fully utilized



Border, et al.               Informational                     [Page 29]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   due to expensive use.  In addition, the (long) periods of link
   disconnection must not abort active (bulk data) transfers, if an
   end-user so desires.

   As (all) applications cannot be made mobility/W-WAN aware in short
   time frame or maybe ever, support for mobile W-WAN use should be
   implemented in a way which allows most applications, at least those
   running on fixed Internet hosts, to continue their operation
   unmodified.

5.3 W-LAN Environments

   Wireless LANs (W-LAN) are typically organized in a cellular topology
   where an access point with a W-LAN transceiver controls a single
   cell.  A cell is defined in terms of the coverage area of the base
   station.  The access points are directly connected to the wired
   network.  The access point in each of the cells is responsible for
   forwarding packets to and from the hosts located in the cell.  Often
   the hosts with W-LAN transceivers are mobile.  When such a mobile
   host moves from one cell to another cell, the responsibility for
   forwarding packets between the wired network and the mobile host must
   be transferred to the access point of the new cell.  This is known as
   a handoff.  Many W-LAN systems also support an operation mode
   enabling ad-hoc networking.  In this mode access points are not
   necessarily needed, but hosts with W-LAN transceiver can communicate
   directly with the other hosts within the transceiver's transmission
   range.

5.3.1 W-LAN Network Characteristics

   Current wireless LANs typically provide link bandwidth from 1 Mbps to
   11 Mbps.  In the future, wide deployment of higher bandwidths up to
   54 Mbps or even higher can be expected.  The round-trip delay with
   wireless LANs is on the order of a few milliseconds or tens of
   milliseconds.  Examples of W-LANs include IEEE 802.11, HomeRF, and
   Hiperlan.  Wireless personal area networks (WPAN) such as Bluethooth
   can use the same PEP techniques.

   Wireless LANs are error-prone due to bit errors, collisions and link
   outages.  In addition, consecutive packet losses may also occur
   during handoffs.  Most W-LAN MAC protocols perform low level
   retransmissions.  This feature shields upper layers from most losses.
   However, unavoidable losses, retransmission latency and link outages
   still affect upper layers.  TCP performance over W-LANs or a network
   path involving a W-LAN link is likely to suffer from these effects.






Border, et al.               Informational                     [Page 30]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   As TCP wrongly interprets these packet losses to be network
   congestion, the TCP sender reduces its congestion window and is often
   forced to timeout in order to recover from the consecutive losses.
   The result is often unacceptably poor end-to-end performance.

5.3.2 W-LAN PEP Implementations: Snoop

   Berkeley's Snoop protocol [SNOOP] is a TCP-specific approach in which
   a TCP-aware module, a Snoop agent, is deployed at the W-LAN base
   station that acts as the last-hop router to the mobile host.  Snoop
   aims at retaining the TCP end-to-end semantics.  The Snoop agent
   monitors every packet that passes through the base station in either
   direction and maintains soft state for each TCP connection.  The
   Snoop agent is an asymmetric PEP implementation as it operates
   differently on TCP data and ACK channels as well as on the uplink
   (from the mobile host) and downlink (to the mobile host) TCP
   segments.

   For a data transfer to a mobile host, the Snoop agent caches
   unacknowledged TCP data segments which it forwards to the TCP
   receiver and monitors the corresponding ACKs.  It does two things:

   1. Retransmits any lost data segments locally by using local timers
      and TCP duplicate ACKs to identify packet loss, instead of waiting
      for the TCP sender to do so end-to-end.

   2. Suppresses the duplicate ACKs on their way from the mobile host
      back to the sender, thus avoiding fast retransmit and congestion
      avoidance at the latter.

   Suppressing the duplicate ACKs is required to avoid unnecessary fast
   retransmits by the TCP sender as the Snoop agent retransmits a packet
   locally.  Consider a system that employs the Snoop agent and a TCP
   sender S that sends packets to receiver R via a base station BS.
   Assume that S sends packets A, B, C, D, E (in that order) which are
   forwarded by BS to the wireless receiver R.  Assume the first
   transmission of packet B is lost due to errors on the wireless link.
   In this case, R receives packets A, C, D, E and B (in that order).
   Receipt of packets C, D and E trigger duplicate ACKs.  When S
   receives three duplicate ACKs, it triggers fast retransmit (which
   results in a retransmission, as well as reduction of the congestion
   window).  The Snoop agent also retransmits B locally, when it
   receives three duplicate ACKs.  The fast retransmit at S occurs
   despite the local retransmit on the wireless link, degrading
   throughput.  Snoop deals with this problem by dropping TCP duplicate
   ACKs appropriately at BS.





Border, et al.               Informational                     [Page 31]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   For a data transfer from a mobile host, the Snoop agent detects the
   packet losses on the wireless link by monitoring the data segments it
   forwards.  It then employs either Negative Acknowledgements (NAK)
   locally or Explicit Loss Notifications (ELN) to inform the mobile
   sender that the packet loss was not related to congestion, thus
   allowing the sender to retransmit without triggering normal
   congestion control procedures.  To implement this, changes at the
   mobile host are required.

   When a Snoop agent uses NAKs to inform the TCP sender of the packet
   losses on the wireless link, one possibility to implement them is
   using the Selective Acknowledgment (SACK) option of TCP [RFC2018].
   This requires enabling SACK processing at the mobile host.  The Snoop
   agent sends a TCP SACK, when it detects a hole in the transmission
   sequence from the mobile host or when it has not received any new
   packets from the mobile host for a certain time period.  This
   approach relies on the advisory nature of the SACKs: the mobile
   sender is advised to retransmit the missing segments indicated by
   SACK, but it must not assume successful end-to-end delivery of the
   segments acknowledged with SACK as these segments might get lost
   later in the path to the receiver.  Instead, the sender must wait for
   a cumulative ACK to arrive.

   When the ELN mechanism is used to inform the mobile sender of the
   packet losses, Snoop uses one of the 'unreserved' bits in the TCP
   header for ELN [SNOOPELN].  The Snoop agent keeps track of the holes
   that correspond to segments lost over the wireless link.  When a
   (duplicate) ACK corresponding to a hole in the sequence space arrives
   from the TCP receiver, the Snoop agent sets the ELN bit on the ACK to
   indicate that the loss is unrelated to congestion and then forwards
   the ACK to the TCP sender.  When the sender receives a certain number
   of (duplicate) ACKs with ELN (a configurable variable at the mobile
   host, e.g., two), it retransmit the missing segment without
   performing any congestion control measures.

   The ELN mechanism using one of the six bits reserved for future use
   in the TCP header is dangerous as it exercises checks that might not
   be correctly implemented in TCP stacks, and may expose bugs.

   A scheme such as Snoop is needed only if the possibility of a fast
   retransmit due to wireless errors is non-negligible.  In particular,
   if the wireless link uses link-layer recovery for lost data, then
   this scheme is not beneficial.  Also, if the TCP window tends to stay
   smaller than four segments, for example, due to congestion related
   losses on the wired network, the probability that the Snoop agent
   will have an opportunity to locally retransmit a lost packet is
   small.  This is because at least three duplicate ACKs are needed to
   trigger the local retransmission, but due to small window the Snoop



Border, et al.               Informational                     [Page 32]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   agent may not be able to forward three new packets after the lost
   packet and thus induce the required three duplicate ACKs.
   Conversely, when the TCP window is large enough, Snoop can provide
   significant performance improvement (compared with standard TCP).

   In order to alleviate the problem with small TCP windows, Snoop
   proposes a solution in which a TCP sender is allowed to transmit a
   new data segment for each duplicate ACK it receives as long as the
   number of duplicate ACKs is less than the threshold for TCP fast
   retransmission (three duplicate ACKs).  If the new segment reaches
   the receiver, it will generate another duplicate ACK which, in turn,
   allows the sender to transmit yet another data segment.  This
   continues until enough duplicate ACKs have accumulated to trigger TCP
   fast retransmission.  This proposal is the same as the "Limited
   Transfer" proposal [RFC3042] that has recently been forwarded to the
   standards track.  However, to be able to benefit from this solution,
   it needs to be deployed on TCP senders and therefore it is not ready
   for use in a short time frame.

   Snoop requires the intermediate node (base station) to examine and
   operate on the traffic between the mobile host and the other end host
   on the wired Internet.  Hence, Snoop does not work if the IP traffic
   is encrypted.  Possible solutions involve:

   - making the Snoop agent a party to the security association
     between the client and the server;

   - IPsec tunneling mode, terminated at the Snooping base station.

   However, these techniques require that users trust base stations.

   Snoop also requires that both the data and the corresponding ACKs
   traverse the same base station.  Furthermore, the Snoop agent may
   duplicate efforts by the link layer as it retransmits the TCP data
   segments "at the transport layer" across  the wireless link.  (Snoop
   has been described by its designers as a TCP-aware link layer.  This
   is the right approach: the link and network layers can be much more
   aware of each other than strict layering suggests.)

5.3.3 W-LAN PEP Motivation

   Wireless LANs suffer from an error prone wireless channel.  Errors
   can typically be considered bursty and channel conditions may change
   rapidly from mobility and environmental changes.  Packets are dropped
   from bit errors or during handovers.  Periods of link outage can also
   be experienced.  Although the typical MAC performs retransmissions,
   dropped packets, outages and retransmission latency still can have
   serious performance implications for IP performance, especially TCP.



Border, et al.               Informational                     [Page 33]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   PEPs can be used to alleviate problems caused by packet losses,
   protect TCP from link outages, and to add priority multiplexing.
   Techniques such as Snoop are integrally implemented in access points,
   while priority and compression schemes are distributed across the W-
   LAN.

6. Security Considerations

   The use of Performance Enhancing Proxies introduces several issues
   which impact security.  First, (as described in detail in Section
   4.1.1,) using PEPs and using IPsec is generally mutually exclusive.
   Unless the PEP is also both capable and trusted to be the endpoint of
   an IPsec tunnel (and the use of an IPsec tunnel is deemed good enough
   security for the applicable threat model), a user or network
   administrator must choose between improved performance and network
   layer security.  In some cases, transport (or higher) layer security
   can be used in conjunction with a PEP to mitigate the impact of not
   having network layer security.  But, support by applications for the
   use of transport (or higher) layer security is far from ubiquitous.

   Additionally, the PEP itself needs to be protected from attack.
   First, even when IPsec tunnels are used with the PEP, the PEP
   represents a point in the network where traffic is exposed.  And, the
   placement of a PEP in the network makes it an ideal platform from
   which to launch a denial of service or man in the middle attack.
   (Also, taking the PEP out of action is a potential denial of service
   attack itself.)  Therefore, the PEP must be protected (e.g., by a
   firewall) or must protect itself from improper access by an attacker
   just like any other device which resides in a network.

7. IANA Considerations

   This document is an informational overview document and, as such,
   does not introduce new nor modify existing name or number spaces
   managed by IANA.

8. Acknowledgements

   This document grew out of the Internet-Draft "TCP Performance
   Enhancing Proxy Terminology", RFC 2757 "Long Thin Networks", and work
   done in the IETF TCPSAT working group.  The authors are indebted to
   the active members of the PILC working group.  In particular, Joe
   Touch and Mark Allman gave us invaluable feedback on various aspects
   of the document and Magdolna Gerendai provided us with essential help
   on the WAP example.






Border, et al.               Informational                     [Page 34]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


9. References

   [BBKT97]    P. Bhagwat, P. Bhattacharya, A. Krishma, S.K. Tripathi,
               "Using channel state dependent packet scheduling to
               improve TCP throughput over wireless LANs," ACM Wireless
               Networks, March 1997, pp. 91 - 102.  Available at:
               http://www.acm.org/pubs
               /articles/journals/wireless/1997-3-1/p91-bhagwat/p91-
               bhagwat.pdf

   [BPK97]     H. Balakrishnan, V.N. Padmanabhan, R.H. Katz, "The
               Effects of Asymmetry on TCP Performance," Proc. ACM/IEEE
               Mobicom, Budapest, Hungary, September 1997.

   [BW97]      G. Brasche, B. Walke, "Concepts, Services, and Protocols
               of the New GSM Phase 2+ general Packet Radio Service,"
               IEEE Communications Magazine, Vol. 35, No. 8, August
               1997.

   [CDMA]      Electronic Industry Alliance (EIA)/Telecommunications
               Industry Association (TIA), IS-95: Mobile Station-Base
               Station Compatibility Standard for Dual-Mode Wideband
               Spread Spectrum Cellular System, 1993.

   [CDPD]      Wireless Data Forum, CDPD System Specification, Release
               1.1, 1995.

   [CTC+97]    H. Chang, C. Tait, N. Cohen, M. Shapiro, S. Mastrianni,
               R. Floyd, B. Housel, D. Lindquist, "Web Browsing in a
               Wireless Environment: Disconnected and Asynchronous
               Operation in ARTour Web Express," Proc. MobiCom'97,
               Budapest, Hungary, September 1997.

   [FMSBMR98]  D.C. Feldmeier, A.J. McAuley, J.M. Smith, D.S. Bakin,
               W.S. Marcus, T.M. Raleigh, "Protocol Boosters," IEEE
               Journal on Selected Areas of Communication, Vol. 16, No.
               3, April 1998.

   [FLASH]     Flash Networks Ltd., performance boosting products
               technology vendor based in Holmdel, New Jersey.  Website
               at http://www.flashnetworks.com.

   [FOURELLE]  Fourelle Systems, performance boosting products
               technology vendor based in Santa Clara, California.
               Website at http://www.fourelle.com.

   [GPRS]      ETSI, "General Packet Radio Service (GPRS): Service
               Description, Stage 2," GSM03.60, v.6.1.1, August 1998.



Border, et al.               Informational                     [Page 35]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   [GSM]       M. Rahnema, "Overview of the GSM system and protocol
               architecture," IEEE Communications Magazine, Vol. 31, No.
               4, pp. 92-100, April 1993.

   [HNS]       Hughes Network Systems, Inc., VSAT technology vendor
               based in Germantown, Maryland.  Website at
               http://www.hns.com.

   [I-TCP]     A. Bakre, B.R. Badrinath, "I-TCP: Indirect TCP for Mobile
               Hosts," Proc. 15th International Conference on
               Distributed Computing Systems (ICDCS), May 1995.

   [KRA94]     M. Kojo, K. Raatikainen, T. Alanko, "Connecting Mobile
               Workstations to the Internet over a Digital Cellular
               Telephone Network," Proc. Workshop on Mobile and Wireless
               Information Systems (MOBIDATA), Rutgers University, NJ,
               November 1994.  Revised version published in Mobile
               Computing, pp. 253-270, Kluwer, 1996.

   [KRLKA97]   M. Kojo, K. Raatikainen, M. Liljeberg, J. Kiiskinen, T.
               Alanko, "An Efficient Transport Service for Slow Wireless
               Telephone Links," IEEE Journal on Selected Areas of
               Communication, Vol. 15, No. 7, September 1997.

   [LAKLR95]   M. Liljeberg, T. Alanko, M. Kojo, H. Laamanen, K.
               Raatikainen, "Optimizing World-Wide Web for Weakly-
               Connected Mobile Workstations: An Indirect Approach,"
               Proc. of the 2nd Int. Workshop on Services in Distributed
               and Networked Environments, Whistler, Canada, pp. 132-
               139, June 1995.

   [LHKR96]    M. Liljeberg, H. Helin, M. Kojo, K. Raatikainen, "Mowgli
               WWW Software: Improved Usability of WWW in Mobile WAN
               Environments," Proc. IEEE Global Internet 1996
               Conference, London, UK, November 1996.

   [M-TCP]     K. Brown, S. Singh, "M-TCP: TCP for Mobile Cellular
               Networks," ACM Computer Communications Review Volume
               27(5), 1997.  Available at
               ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz.

   [Pax99]     V. Paxson, "End-to-End Internet Packet Dynamics,"
               IEEE/ACM Transactions on Networking, Vol. 7, No. 3, 1999,
               pp. 277-292.

   [PILCWEB]   http://pilc.grc.nasa.gov.





Border, et al.               Informational                     [Page 36]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   [RFC0792]   Postel, J., "Internet Control Message Protocol", STD 5,
               RFC 792, September 1981.

   [RFC0793]   Postel, J., "Transmission Control Protocol", STD 7, RFC
               793, September 1981.

   [RFC1122]   Braden, R., "Requirements for Internet Hosts --
               Communications Layers", STD 3, RFC 1122, October 1989.

   [RFC1144]   Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
               Serial Links", RFC 1144, February 1990.

   [RFC1323]   Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
               for High Performance", RFC 1323, May 1992.

   [RFC1958]   Carpenter, B., "Architectural Principles of the
               Internet", RFC 1958, June 1996.

   [RFC2018]   Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
               Selective Acknowledgment Options", RFC 2018, October
               1996.

   [RFC2151]   Kessler, G. and S. Shepard, "A Primer On Internet and
               TCP/IP Tools and Utilities", FYI 30, RFC 2151, June 1997.

   [RFC2246]   Dierk, T. and E. Allen, "TLS Protocol Version 1," RFC
               2246, January 1999.

   [RFC2393]   Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP
               Payload Compression Protocol (IPcomp)", RFC 2393,
               December 1998.

   [RFC2401]   Kent, S., and R. Atkinson, "Security Architecture for the
               Internet Protocol", RFC 2401, November 1998.

   [RFC2475]   Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
               and W. Weiss, "An Architecture for Differentiated
               Services", RFC 2475, December 1998.

   [RFC2488]   Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP
               Over Satellite Channels using Standard Mechanisms", BCP
               28, RFC 2488, January 1999.

   [RFC2507]   Degermark, M., Nordgren, B. and S. Pink, "IP Header
               Compression", RFC 2507, February 1999.






Border, et al.               Informational                     [Page 37]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   [RFC2508]   Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
               Headers for Low-Speed Serial Links", RFC 2508, February
               1999.

   [RFC2509]   Engan, M., Casner, S. and C. Bormann, "IP Header
               Compression over PPP", RFC 2509, February 1999.

   [RFC2663]   Srisuresh, P. and Y. Holdrege, "IP Network Address
               Translator (NAT) Terminology and Considerations", RFC
               2663, August 1999.

   [RFC2760]   Allman, M., Dawkins, S., Glover, D., Griner, J.,
               Henderson, T., Heidemann, J., Kruse, H., Ostermann, S.,
               Scott, K., Semke, J., Touch, J. and D. Tran, "Ongoing TCP
               Research Related to Satellites", RFC 2760, February 2000.

   [RFC3002]   Mitzel, D., "Overview of 2000 IAB Wireless
               Internetworking Workshop", RFC 3002, December 2000.

   [RFC3042]   Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing
               TCP's Loss Recovery Using Limited Transmit", RFC 3042,
               January 2001.

   [SHEL00]    Z. Shelby, T. Saarinen, P. Mahonen, D. Melpignano, A.
               Marshall, L. Munoz, "Wireless IPv6 Networks - WINE," IST
               Mobile Summit, Ireland, October 2000.

   [SNOOP]     H. Balakrishnan, S. Seshan, E. Amir, R. Katz, "Improving
               TCP/IP Performance over Wireless Networks," Proc. 1st ACM
               Conference on Mobile Communications and Networking
               (Mobicom), Berkeley, California, November 1995.

   [SNOOPELN]  H. Balakrishnan, R. Katz, "Explicit Loss Notification and
               Wireless Web Performance," Proc. IEEE Globecom 1998,
               Internet Mini-Conference, Sydney, Australia, November
               1998.

   [SPACENET]  Spacenet, VSAT technology vendor based in Mclean,
               Virginia.  Website at http://www.spacenet.com.

   [SRC84]     J.H. Saltzer, D.P. Reed, D.D. Clark, "End-To-End
               Arguments in System Design," ACM TOCS, Vol. 2, No. 4, pp.
               277-288, November 1984.

   [WAPARCH]   Wireless Application Protocol Architecture Specification,
               April 1998, http://www.wapforum.org.





Border, et al.               Informational                     [Page 38]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   [WAPPROXY]  Wireless Application Protocol Push Proxy Gateway Service
               Specification, August 1999, http://www.wapforum.org.

   [WAPWAE]    Wireless Application Protocol Wireless Application
               Environment Overview, March 2000,
               http://www.wapforum.org.

   [WAPWDP]    Wireless Application Protocol Wireless Datagram Protocol
               Specification, February 2000, http://www.wapforum.org.

   [WAPWSP]    Wireless Application Protocol Wireless Session Protocol
               Specification, May 2000, http://www.wapforum.org.

   [WAPWTLS]   Wireless Application Protocol Wireless Transport Layer
               Security Specification, February 2000,
               http://www.wapforum.org.

   [WAPWTP]    Wireless Application Protocol Wireless Transaction
               Protocol Specification, February 2000,
               http://www.wapforum.org.

   [Zhang00]   Y. Zhang, B. Singh, "A Multi-Layer IPsec Protocol," Proc.
               proceedings of 9th USENIX Security Symposium, Denver,
               Colorado, August 2000.  Available at
               http://www.wins.hrl.com/people/ygz/papers/usenix00.html.

10. Authors' Addresses

   Questions about this document may be directed to:

   John Border
   Hughes Network Systems
   11717 Exploration Lane
   Germantown, Maryland  20876

   Phone: +1-301-548-6819
   Fax:   +1-301-548-1196
   EMail: border@hns.com













Border, et al.               Informational                     [Page 39]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   Markku Kojo
   Department of Computer Science
   University of Helsinki
   P.O. Box 26 (Teollisuuskatu 23)
   FIN-00014 HELSINKI
   Finland

   Phone: +358-9-1914-4179
   Fax:   +358-9-1914-4441
   EMail: kojo@cs.helsinki.fi


   Jim Griner
   NASA Glenn Research Center
   MS: 54-5
   21000 Brookpark Orad
   Cleveland, Ohio  44135-3191

   Phone: +1-216-433-5787
   Fax:   +1-216-433-8705
   EMail: jgriner@grc.nasa.gov


   Gabriel Montenegro
   Sun Microsystems Laboratories, Europe
   29, chemin du Vieux Chene
   38240 Meylan, FRANCE

   Phone: +33 476 18 80 45
   EMail: gab@sun.com


   Zach Shelby
   University of Oulu
   Center for Wireless Communications
   PO Box 4500
   FIN-90014
   Finland

   Phone: +358-40-779-6297
   EMail: zach.shelby@ee.oulu.fi










Border, et al.               Informational                     [Page 40]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


Appendix A - PEP Terminology Summary

   This appendix provides a summary of terminology frequently used
   during discussion of Performance Enhancing Proxies.  (In some cases,
   these terms have different meanings from their non-PEP related
   usage.)

   ACK filtering

      Removing acknowledgments to prevent congestion of a low speed
      link, usually used with paths which include a highly asymmetric
      link.  Sometimes also called ACK reduction.  See Section 3.1.4.

   ACK spacing

      Delayed forwarding of acknowledgments in order to space them
      appropriately, for example, to help minimize the burstiness of
      TCP data.  See Section 3.1.1.

   application layer PEP

      A Performance Enhancing Proxy operating above the transport
      layer.  May be aimed at improving application or transport
      protocol performance (or both).  Described in detail in Section
      2.1.2.

   asymmetric link

      A link which has different rates for the forward channel (used for
      data segments) and the back (or return) channel (used for ACKs).

   available bandwidth

      The total capacity of a link available to carry information at any
      given time.  May be lower than the raw bandwidth due to competing
      traffic.

   bandwidth utilization

      The actual amount of information delivered over a link in a given
      period, usually expressed as a percent of the raw bandwidth of
      the link.

   gateway

      Has several meanings with respect to PEPs, depending on context:

         -  An access point to a particular link;



Border, et al.               Informational                     [Page 41]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


         -  A device capable of initiating and terminating connections
            on

            behalf of a user or end system (e.g., a firewall or proxy).

      Not necessarily, but could be, a router.

   in flight (data)

      Data sent but not yet acknowledged.  More precisely, data sent for
      which the sender has not yet received the acknowledgement.

   link layer PEP

      A Performance Enhancing Proxy operating below the network layer.

   local acknowledgement

      The generation of acknowledgments by an entity in the path
      between two end systems in order to allow the sending system to
      transmit more data without waiting for end-to-end
      acknowledgments.  Described (in the context of TCP) in Section
      3.1.2.

   performance enhancing proxy

      An entity in the network acting on behalf of an end system or user
      (with or without the knowledge of the end system or user) in order
      to enhance protocol performance.  Section 2 describes various
      types of performance enhancing proxies.  Section 3 describes the
      mechanisms performance enhancing proxies use to improve
      performance.

   raw bandwidth

      The total capacity of an unloaded link available to carry
      information.

   Snoop

      A TCP-aware link layer developed for wireless packet radio and
      cellular networks.  It works by caching segments at a wireless
      base station.  If the base station sees duplicate acknowledgments
      for a segment that it has cached, it retransmits the missing
      segment while suppressing the duplicate acknowledgement stream
      being forwarded back to the sender until the wireless receiver
      starts to acknowledge new data.  Described in detail in Section
      5.3.2 and [SNOOP].



Border, et al.               Informational                     [Page 42]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   split connection

      A connection that has been terminated before reaching the intended
      destination end system in order to initiate another connection
      towards the end system.  This allows the use of different
      connection characteristics for different parts of the path of
      the originally intended connection.  See Section 2.4.

   TCP PEP

      A Performance Enhancing Proxy operating at the transport layer
      with TCP.  Aimed at improving TCP performance.

   TCP splitting

      Using one or more split TCP connections to improve TCP
      performance.

   TCP spoofing

      Sometimes used as a synonym for TCP PEP.  More accurately, TCP
      spoofing refers to using transparent (to the TCP stacks in the
      end systems) mechanisms to improve TCP performance.  See Section
      2.1.1.

   transparent

      In the context of a PEP, transparent refers to not requiring
      changes to be made to the end systems, transport endpoints
      and/or applications involved in a connection.  See Section 2.5
      for a more detailed explanation.

   transport layer PEP

      A Performance Enhancing Proxy operating at the transport layer.
      Described in detail in Section 2.1.1.

   tunneling

      In the context of PEPs, tunneling refers to the process of
      wrapping a packet for transmission over a particular link
      between two PEPs.  See Section 3.2.









Border, et al.               Informational                     [Page 43]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   WAP

      The Wireless Application Protocol specifies an application
      framework and network protocols intended to work across
      differing narrow-band wireless network technologies.  See
      Section 5.2.2.2.













































Border, et al.               Informational                     [Page 44]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Border, et al.               Informational                     [Page 45]