Subject: BCP 69, RFC 3449 on TCP Performance Implications of Network Path Asymmetry

From: [email-masked]
Date: Thu, 19 Dec 2002 17:37:09 -0800

A new Request for Comments is now available in online RFC libraries.

        BCP 69
        RFC 3449
                                      
        Title:      TCP Performance Implications of Network Path
                    Asymmetry
        Author(s):  H. Balakrishnan, V. Padmanabhan, G. Fairhurst,
                    M. Sooriyabandara
        Status:     Standards Track
        Date:       December 2002
        Mailbox:    [email-masked], [email-masked],
                    [email-masked], [email-masked]
        Pages:      41
        Characters: 108839
        See Also:   BCP 69
                                      
        I-D Tag:    draft-ietf-pilc-asym-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3449.txt

This document describes TCP performance problems that arise because of
asymmetric effects.  These problems arise in several access networks,
including bandwidth-asymmetric networks and packet radio subnetworks,
for different underlying reasons.  However, the end result on TCP
performance is the same in both cases: performance often degrades
significantly because of imperfection and variability in the ACK
feedback from the receiver to the sender.

The document details several mitigations to these effects, which have
either been proposed or evaluated in the literature, or are currently
deployed in networks.  These solutions use a combination of local
link-layer techniques, subnetwork, and end-to-end mechanisms,
consisting of: (i) techniques to manage the channel used for the
upstream bottleneck link carrying the ACKs, typically using header
compression or reducing the frequency of TCP ACKs, (ii) techniques to
handle this reduced ACK frequency to retain the TCP sender's
acknowledgment-triggered self-clocking and (iii) techniques to
schedule the data and ACK packets in the reverse direction to improve
performance in the presence of two-way traffic.  Each technique is
described, together with known issues, and recommendations for use.  A
summary of the recommendations is provided at the end of the document.

This document is a product of the Performance Implications of Link
Characteristics Working Group of the IETF.

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.