Subject: [Ieprep] TCP PEPs and Priority-based Mechanisms

From: "King, Kimberly S." <[email-masked]>
Date: Mon, 22 Dec 2003 11:10:23 -0500

This Information RFC may be of interest.  For example, PEPs can be useful 
for moving TCP traffic over satellite links.

http://www.ietf.org/rfc/rfc3135.txt

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
   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.

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Rex Buddenberg <[email-masked]>
Date: 22 Dec 2003 10:50:42 -0800

Make sure you read section 6 on page 33.

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.

-- 
b