Subject: A PEP draft update...

From: John Border <[email-masked]>
Date: Thu, 16 Nov 2000 09:29:06 -0500

FYI,

    We have only a few comments on document and we are in the process of
making the updates so that we can get the -05 version out before the San Diego
meeting deadline.  The only two changes which are anything other than cleanup
are the addition of an explicit statement pointing out that PEPs are used with
existing link layers which have not had the benefit of the ADVICE draft and an
observatation re QoS Transparency pointing out the potential for PEP
mechanisms to conflict with things like diffserv...

John

Section 1, 1st Paragraph, Page 4

******

   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.  [Karn00] discusses various link layer design
   considerations that should be taken into account when designing a
   link layer service that is intended to support the Internet
   protocols.  Such 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. 
+  (Also, it is difficult to apply the advice in [Karn00] to link
<  layers which already exist.)  A Performance Enhancing Proxy (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.

******

Section 4.5, Page 22

******

   This document describes some significant implications re 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.

******

Section 8, Page 39

******

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

******