[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

TCP Maintenance Working Group                                  M. Mathis
Internet-Draft                                               Google, Inc
Intended status: Experimental                              July 15, 2012
Expires: January 16, 2013


    Laminar TCP and the case for refactoring TCP congestion control
                  draft-mathis-tcpm-tcp-laminar-01.txt

Abstract

   The primary state variables used by all TCP congestion control
   algorithms, cwnd and ssthresh, are heavily overloaded, carrying
   different semantics in different states.  This leads to excess
   implementation complexity and poorly defined behaviors under some
   combinations of events, such as application stalls during loss
   recovery.  We propose a new framework for TCP congestion control, and
   to recast current standard algorithms to use new state variables.
   This new framework will not generally change the behavior of any of
   the primary congestion control algorithms when they are invoked in
   isolation.  It will permit new algorithms with better behaviors in
   many corner cases, such as when two distinct primary algorithms are
   invoked concurrently.  It will also foster the creation of new
   algorithms to address some events that are poorly treated by today's
   standards.  For the vast majority of traditional algorithms the
   transformation to the new state variables is completely
   straightforward.  However, the resulting implementation is likely to
   technically be in violation of existing TCP standards, even if it is
   fully compliant with their principles and intent.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 16, 2013.

Copyright Notice



Mathis                  Expires January 16, 2013                [Page 1]


Internet-Draft                 Laminar TCP                     July 2012


   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview of the new algorithm  . . . . . . . . . . . . . . . .  3
   3.  Standards Impact . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Meta Language  . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  State variables and definitions  . . . . . . . . . . . . . . .  6
   6.  Updated Algorithms . . . . . . . . . . . . . . . . . . . . . .  6
     6.1.  Congestion avoidance . . . . . . . . . . . . . . . . . . .  7
     6.2.  Proportional Rate Reduction  . . . . . . . . . . . . . . .  8
     6.3.  Restart after idle, Congestion Window Validation and
           Pacing . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.4.  RTO and F-RTO  . . . . . . . . . . . . . . . . . . . . . .  9
     6.5.  Undo . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.6.  Control Block Interdependence  . . . . . . . . . . . . . . 10
     6.7.  New Reno . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Example Pseudocode . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Compatibility with existing implementations  . . . . . . . . . 12
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15















Mathis                  Expires January 16, 2013                [Page 2]


Internet-Draft                 Laminar TCP                     July 2012


1.  Introduction

   The primary state variables used by all TCP congestion control
   algorithms, cwnd and ssthresh, are heavily overloaded, carrying
   different semantics in different states.  Multiple algorithms sharing
   the same state variables lead to excess complexity, conflicting
   correctness constraints, and makes it unreasonably difficult to
   implement, test and evaluate new algorithms.

   We are proposing a new framework for TCP congestion control that
   separate transmission scheduling, which determines precisely when
   data is sent, from pure congestion control, which determines the
   amount of data to be sent in each RTT.  This separation is
   implemented with new state variables and greatly simplifies the
   interactions between the two subsystems.  It permits vast range of
   new algorithms that are not feasible with the current
   parameterization.

   This note describes the new framework and presents a preliminary
   mapping between current standards and new algorithms based on the new
   state variables.  At this point the new algorithms are not fully
   specified, and many have still unconstrained design choices.  In most
   cases, our goal is to precisely mimic today's standard TCP, at least
   as far as well defined primary behaviors.  In general, it is a non-
   goal to mimic behaviors in poorly defined corner cases, or other
   cases where standard behaviors are viewed as being problematic.

   It is called Laminar because one of its design goals is to eliminate
   unnecessary turbulence introduced by TCP itself.


2.  Overview of the new algorithm

   The new framework separates transmission scheduling, which determines
   precisely when data is sent, from pure Congestion Control, which
   determines the total amount of data sent in any given RTT.

   The default algorithm for transmission scheduling is a strict
   implementation of Van Jacobsons' packet conservation principle
   [Jacobson88].  Data arriving at the receiver cause ACKs which in turn
   cause the sender to transmit an equivalent quantity of data back into
   the network.  The primary state variable is implicit in the quantity
   of data and ACKs circulating in the network.  This state observed
   through an improved "total_pipe" estimator, which is based on "pipe"
   as described in RFC 3517 [RFC3517] but also includes the quantity of
   data reported by the current ACK and pending transmissions that have
   passed congestion control but are waiting for other events such as
   TSO.



Mathis                  Expires January 16, 2013                [Page 3]


Internet-Draft                 Laminar TCP                     July 2012


   A new state variable, CCwin, is the primary congestion control state
   variable.  It is updated only by the congestion control algorithms,
   which are concerned with detecting and regulating the overall level
   of congestion along the path.  CCwin is TCP's best estimate for an
   appropriate average window size.  In general, it rises when the
   network seem to be underfilled and is reduced in the presence of
   congestion signals, such as loss, ECN marks or increased delay.
   Although CCwin resembles cwnd, cwnd is overloaded and used by
   multiple algorithms (such as burst suppression) with different and
   sometimes conflicting goals.

   Any time total_pipe is different from CCwin the transmission
   scheduling algorithm slightly adjusts the number of segments sent in
   response to each ACK.  Slow start and Proportional Rate Reduction
   [PRRid] are both embedded in the transmission scheduling algorithm.

   If CCwin is larger than total_pipe, the default algorithm to grow
   total_pipe is for each ACK to trigger one segment of additional data.
   This is essentially an implicit slowstart, but it is gated by the
   difference between CCwin and total_pipe, rather than the difference
   between cwnd and ssthresh.  In the future, additional algorithms such
   as pacing, might be used to raise total_pipe.

   During Fast Retransmit, the congestion control algorithm, such as
   CUBIC, generally reduces CCwin in a single step.  Proportional Rate
   Reduction [PRRid] is used to gradually reduce total_pipe to agree
   with CCwin.  PRR was based on Laminar principles, so its
   specification has many parallels to this document.

   Connection startup is accomplished as follows: CCwin is set to
   MAX_WIN (akin to ssthresh), and IW segments are transmitted.  The
   ACKs from these segments trigger additional data transmissions, and
   slowstart proceeds as it does today.  The very first congestion event
   is a special case because there is not a prior value for CCwin.  By
   default and on the first congestion event only, CCwin would be set
   from total_pipe, and then standard congestion control is invoked.

   The primary advantage of the Laminar framework is that by
   partitioning congestion control and transmission scheduling into
   separate subsystems, each is subject to simpler design constraints,
   making it far easier to develop many new algorithms that are not
   feasible with the current organization of the code.


3.  Standards Impact

   Since we are proposing to refactor existing standards into new state
   variables, all of the current congestion control standards documents



Mathis                  Expires January 16, 2013                [Page 4]


Internet-Draft                 Laminar TCP                     July 2012


   will potentially need to be reviewed.  Although there are roughly 60
   RFCs that mention cwnd or ssthresh, most only need self evident
   reinterpretation.  Others, such as MIBs, warrant a sentence or two
   clarifying how to map CCwin and total_pipe onto existing
   specifications that use cwnd and ssthresh.  There are however several
   RFCs that explicitly address the interplay between cwnd and ssthresh
   in today's TCP, including RFC 5681 [RFC5681], RFC 5682 [RFC5682], RFC
   4015 [RFC4015], and RFC 6582 [RFC6582].  These need to be reviewed
   more carefully.  In most cases the algorithms can easily be restated
   under the Laminar framework.  Others, such as Congestion Window
   Validation [RFC2861], potentially require redesign.

   This document does not propose to change the TCP friendly paradigm
   [RFC2914].  By default all updated algorithms using these new state
   variables would have behaviors similar to the current TCP
   implementations, however over the longer term the intent is to permit
   new algorithms that are not feasible today.  For example, since CCwin
   does not directly affect transmissions during recovery, it is
   straightforward to permit recovery ACKs to raise CCwin even while PRR
   is reducing total_pipe.  This facilitates so called "fluid model"
   algorithms which further decouple congestion control from the details
   of the TCP the protocol.

   But even without these advanced algorithms, we do anticipate some
   second order effects.  For example while testing PRR it was observed
   that suppressing bursts by slightly delaying transmissions can
   improve average performance, even though in a strict sense the new
   algorithm is less aggressive than the old [IMC11PRR].


4.  Meta Language

   We use the following terms when describing algorithms and their
   alternatives:

   Standard - The current state of the art, including both formal
   standards and widely deployed algorithms that have come into standard
   use, even though they may not be formally specified.  [Although PRR
   does not yet technically meet these criteria, we include it here].

   default - The simplest or most straightforward algorithm that fits
   within the Laminar framework.  For example implicit slowstart
   whenever total_pipe is less than CCwin.  This term does not make a
   statment about the relative aggressiveness or any other properties of
   the algorithm except that it is a reasonable choice and
   straightforward to implement.

   conformant - An algorithm that can produce the same packet trace as a



Mathis                  Expires January 16, 2013                [Page 5]


Internet-Draft                 Laminar TCP                     July 2012


   TCP implementation that strictly conforms to the current standards.

   mimic - An algorithm constructed to be conformant to standards.

   opportunity - An algorithm that can do something better than the
   standard algorithm, typically better behavior in a corner cases that
   is either not well specified or where the standard behavior is viewed
   as being less than ideal.

   more/less aggressive - Any algorithm that sends segments earlier/
   later than another (typically conformant) algorithm under identical
   sequences of events.  Note that this is an evaluation of the packet
   level behavior, and does not reflect any higher order effects.

   Observed performance - A statement about algorithm performance based
   on a measurement study or other observations based on a significant
   sample of authentic Internet paths. e.g. an algorithm might have
   observed data rate that is different than another (typically
   conformant) algorithm.

   application stall - The application is failing to keep up with TCP:
   either the sender is running out of data to send, or the receiver is
   not reading it fast enough.  When there is an application stall,
   congestion control does not regulate data transmission and some of
   the protocol events are triggered by application reads or writes, as
   appropriate.


5.  State variables and definitions

   CCwin - The primary congestion control state variable.

   DeliveredData - The total number of bytes that the current ACK
   indicates have been delivered to the receiver.  (See [PRRid] for more
   details).

   total_pipe - The total quantity of circulating data and ACKs.  In
   addition to RFC 3517 pipe, it includes DeliveredData for the current
   ack, plus any data held for delayed transmission, for example to
   permit a later TSO transmission.

   sendcnt - The quantity of data to be sent in response to the current
   ACK or other event.


6.  Updated Algorithms

   A survey of standard, common and proposed algorithms, and how they



Mathis                  Expires January 16, 2013                [Page 6]


Internet-Draft                 Laminar TCP                     July 2012


   might be reimplemented under the Laminar framework.

6.1.  Congestion avoidance

   Under the Laminar framework the loss recovery mechanism does not, by
   default, interfere with the primary congestion control algorithms.
   The CCwin state variable is updated only by the algorithms that
   decide how much data to send on successive round trips.  For example
   standard Reno AIMD congestion control [RFC5681] can be implemented by
   raising CCwin by one segment every CCwin worth of ACKs (once per RTT)
   and halving it on every loss or ECN signal (e.g.  CCwin = CCwin/2).
   During recovery the transmission scheduling part of the Laminar
   framework makes the necessary adjustments to bring total_pipe to
   agree with CCwin, without tampering with CCwin.

   This separation between computing CCwin and transmission scheduling
   will enable new classes of congestion control algorithms, such as
   fluid models that adjust CCwin on every ACK, even during recovery.
   This is safe because raising CCwin does not directly trigger any
   transmissions, it just steers the transmission scheduling closer to
   the end of recovery.  Fluid models have a number of advantages, such
   as simpler closed form mathematical representations, and are
   intrinsically more tolerant to reordering since non-recovery
   disordered states don't inhibit window growth.

   Investigating alternative algorithms and their impact is out of scope
   for this document.  It is important to note that while our goal here
   is not to alter the TCP friendly paradigm, Laminar does not include
   any implicit or explicit mechanism to prevent a Tragedy of the
   Commons.  However, see the comments in Section 9.

   The initial slowstart does not use CCwin, except that CCwin starts at
   the largest possible value.  It is the transmission scheduling
   algorithms that are responsible for performing the slowstart.  On the
   first loss it is necessary to compute a reasonable CCwin from
   total_pipe.  Ideally, we might save total_pipe at the time each
   segment is scheduled for transmission, and use the saved value
   associated with the lost segment to prime CCwin.  However, this
   approach requires extra state attached to every segment in the
   retransmit queue.  A simpler approach is to have a mathematical model
   the slowstart, and to prime CCwin from total_pipe at the time the
   loss is detected, but scaled down by the effective slowstart
   multiplier (e.g. 1.5 or 2).  In either case, once CCwin is primed
   from total_pipe, it is typically appropriate to invoke the reduction
   on loss function, to reduce it again per the congestion control
   algorithm.

   Nearly all congestion control algorithms need to have some mechanism



Mathis                  Expires January 16, 2013                [Page 7]


Internet-Draft                 Laminar TCP                     July 2012


   to prevent CCwin from growing while it is not regulating
   transmissions e.g. during prolonged application stalls.

6.2.  Proportional Rate Reduction

   Since PRR [PRRid] was designed with Laminar principles in mind,
   updating it is a straightforward variable substitution.  CCwin
   replaces ssthresh, and RecoverFS is initialized from total_pipe at
   the beginning of recovery.  Thus PRR provides a gradual window
   reduction from the prior total_pipe down to the new CCwin.

   There is one important difference from the current standards: CCwin
   is computed solely on the basis of the prior value of CCwin.  Compare
   this to RFC 5681 which specifies that the congestion control function
   is computed on the basis of the FlightSize (e.g.
   ssthresh=FlightSize/2 ) This change from prior standard completely
   alters how application stalls interact with congestion control.

   Consider what happens if there is an application stall for most of
   the RTT just before a Fast Retransmit: Under Laminar it is likely
   that CCwin will be set to a value that is larger than total_pipe, and
   subject to available application data PRR will go directly to
   slowstart mode, to raise total_pipe up to CCwin.  Note that the final
   CCwin value does not depend on the duration of the application stall.

   With standard TCP, any application stall reduces the final value of
   cwnd at the end of recovery.  In some sense application stalls during
   recovery are treated as though they are additional losses, and have a
   detrimental effect on the connection data rate that lasts far longer
   than the stall itself.

   If there are no application stalls, the standard and Laminar variants
   of the PRR algorithm should have identical behaviors.  Although it is
   tempting to characterize Laminar as being more aggressive than the
   standards, it would be more apropos to characterize the standard as
   being excessively timid under certain combinations of overlapping
   events that are not well represented by benchmarks or models.

6.3.  Restart after idle, Congestion Window Validation and Pacing

   Decoupling congestion control from transmission scheduling permits us
   to develop new algorithms to raise total_pipe to CCwin after an
   application stall or other events.  Although it was stated earlier
   that the default transmission scheduling algorithm for raising
   total_pipe is an implicit slowstart, there is opportunity for better
   algorithms.

   We imagine a class of hybrid transmission scheduling algorithms that



Mathis                  Expires January 16, 2013                [Page 8]


Internet-Draft                 Laminar TCP                     July 2012


   use a combination of pacing and slowstart to reestablish TCP's self
   clock.  (See [Visweswaraiah99].)  For example, whenever total_pipe is
   significantly below CCwin, RTT and CCwin can be used to directly
   compute a pacing rate.  We suspect that pacing at the previous full
   rate will prove to be somewhat brittle, sometimes causing excessive
   loss and yielding erratic results.  It is more likely that a hybrid
   strategy will work better and be better for the network, for example
   by pacing at some fraction (1/2 or 1/4) of the prior rate until
   total_pipe reaches some fraction of CCwin (e.g.  CCwin/2) and then
   using conventional slowstart to bring total_pipe the rest of the way
   up to CCwin.

   This is far less aggressive than standard TCP without cwnd validation
   [RFC2861] or when the application stall was less than one RTO, since
   standards permit TCP to send a full cwnd size burst in these
   situations.  It is potentially more aggressive than conventional
   slowstart invoked by cwnd validation when the application stall is
   longer than several RTOs.  Both standard behaviors in these
   situations have always been viewed as problematic, because interface
   rate bursts are clearly too aggressive and a full slowstart is
   clearly too conservative.  Mimicking either is a non-goal, when there
   is ample opportunity to find a better compromise.

   Although strictly speaking any new transmission scheduling algorithms
   are independent of the Laminar framework, they are expected to have
   substantially better behavior in many common environments and as such
   strongly motivate the effort required to refactor TCP implementations
   and standards.

6.4.  RTO and F-RTO

   We are not proposing any changes to the RTO timer or the F-RTO
   [RFC5682] algorithm used to detect spurious retransmissions.  Once it
   is determined that segments were lost, CCwin is updated to a new
   value as determined by the congestion control function, and Laminar
   implicit slowstart is used to clock out (re)transmissions.  Once all
   holes are filled, a hybrid paced transmissions can be used to
   reestablish TCPs self clock at the new data rate.  This can be the
   same hybrid pacing algorithm as is used to recover the self clock
   after application stalls.

   Note that as long as there is non-contiguous data at the receiver the
   retransmission algorithms require timely SACK information to make
   proper decisions about which segments to send.  Pacing during loss
   recovery is not recommended without further investigation.






Mathis                  Expires January 16, 2013                [Page 9]


Internet-Draft                 Laminar TCP                     July 2012


6.5.  Undo

   Since CCwin is not used to implement transmission scheduling, undo is
   trivial.  CCwin can just be set back to its prior value and the
   transmission scheduling algorithm will transmit more (or less) data
   as needed.  It is useful to note that the discussion about ssthresh
   in [RFC4015] also applies to CCwin in TCP Laminar.  Some people might
   find it useful to think of CCwin as being equivalent to
   MAX(ssthresh,cwnd).

   There is an opportunity to do substantially better than current
   algorithms.  Undo can be implemented by saving the arithmetic
   difference between the current and prior value of CCwin, and then
   adding this delta back into CCwin when all retransmissions are deemed
   to be spurious.  If the congestion avoidance algorithm is linear (or
   can be linearized), and is mathematically transportable across undo,
   it is possible to design a congestion control algorithm that is
   completely immune to reordering in the sense that the overall
   evolution of CCwin is not affected by low level reordering, even if
   it is pervasive.  This is an area for future research.

6.6.  Control Block Interdependence

   Under the Laminar framework, congestion control state can be easily
   shared between connections [RFC2140].  An ensemble of connections can
   each maintain their own total_pipe (partial_pipe?) which in aggregate
   tracks a single common CCwin.  A master transmission scheduler
   allocates permission to send (sndcnt) to each of the constituent
   connection on the basis of the difference between the CCwin and the
   aggregate total_pipe, and a fairness or capacity allocation policy
   that balances the flows.  Note that ACKs on one connection in an
   ensemble might be used to clock transmissions on another connection,
   and that following a loss, the window reductions can be allocated to
   flows other than the one experiencing the loss.

6.7.  New Reno

   The key to making Laminar function well without SACK is having good
   estimators for DeliveredData and total_pipe.  By definition every
   duplicate ACK indicates that one segment has arrived at the receiver
   and total_pipe has fallen by one.  On any ACK that advances snd.una,
   total pipe can be updated from snd.nxt-snd.una, and DeliveredData is
   the change in snd.una, minus the sum of the estimated DeliveredData
   of the preceding duplicate ACKs.  As with SACK the total
   DeliveredData must agree with the overall forward progress over time.






Mathis                  Expires January 16, 2013               [Page 10]


Internet-Draft                 Laminar TCP                     July 2012


7.  Example Pseudocode

   On startup:

     CCwin = MAX_WIN
     sndBank = IW

   On every ACK:

     DeliveredData = delta(snd.una) + delta(SACKd)
     pipe = (RFC 3517 pipe algorithm)
     total_pipe = pipe+DeliveredData+sndBank
     sndcnt = DeliveredData    // Default # transmissions


     if new_recovery():
        if CCwin == MAX_WIN:
           CCwin = total_pipe/2 // First time only
        CCwin = CCwin/2         // Reno congestion control
        prr_delivered = 0       // Total bytes delivered during recov
        prr_out = 0             // Total bytes sent during recovery
        RecoverFS = total_pipe  //


     if !in_recovery() && !application_limited():
        CCwin += (MSS/CCwin)
     prr_delivered += DeliveredData  // noop if not in recovery
























Mathis                  Expires January 16, 2013               [Page 11]


Internet-Draft                 Laminar TCP                     July 2012


     if total_pipe > CCwin:
        // Proportional Rate Reduction
        sndcnt = CEIL(prr_delivered * CCwin / RecoverFS) - prr_out

     else if total_pipe < CCwin:
        if in_recovery():
           // PRR Slow Start Reduction Bound
           limit = MAX(prr_delivered - prr_out, DeliveredData) + SMSS
           sndcnt = MIN(CCwin - total_pipe, limit)
        else:
           // slow start with appropriate byte counting
           inc = MIN(DeliveredData, 2*MSS)
           sndcnt = DeliveredData + inc


     // cue the transmission machinery
     sndBank += sndcnt
     limit = maxBank()
     if sndBank > limit:
        sndBank = limit
     tcp_output()

   For any data transmission or retransmission:

   tcp_output():
     while sndBank && tso_ok():
        len = sendsomething()
        sndBank -= len
        prr_out += len  // noop if not in recovery




8.  Compatibility with existing implementations

   On a segment by segment basis, the above algorithm is [believed to
   be] fully conformant with or less aggressive than standards under all
   conditions.

   However this condition is not sufficient to guarantee that observed
   performance can't be better than standards.  Consider an application
   that keeps TCP in bulk mode nearly all of the time, but has
   occasional pauses that last some fraction of one RTT.  A fully
   conforment TCP would be permitted to "catch up" by sending a partial
   window burst at full interface rate.  On some networks, such bursts
   might be very disruptive, causing otherwise unnecessary packet losses
   and corresponding cwnd reductions.




Mathis                  Expires January 16, 2013               [Page 12]


Internet-Draft                 Laminar TCP                     July 2012


   In Laminar the default algorithm would be slowstart.  Other
   algorithms that might cause the same bursts would be permitted,
   although are not described here.  A better algorithm would be to pace
   the data at (some fraction of) the prior rate.  Neither pacing nor
   slowstart is likely to cause unnecessary losses, and as was observed
   while testing PRR, being less aggressive at the segment level has the
   potential to increase the observed performance[IMC11PRR].  In this
   scenario Laminar with pacing has the potential to outperform both of
   the behaviors described by standards.


9.  Security Considerations

   The Laminar framework does not change the risk profile for TCP (or
   other transport protocols) themselves.

   However, the complexity of current algorithms as embodied in today's
   code present a substantial barrier to people wishing to cheat "TCP
   friendliness".  It is a fairly well known and easily rediscovered
   result that custom tweaks to make TCP more aggressive in one
   environment generally make it fragile and perform less well across
   the extreme diversity of the Internet.  This negative outcome is a
   substantial intrinsic barrier to wide deployment of rogue congestion
   control algorithms.

   A direct consequence of the changes proposed in this note, decoupling
   congestion control from other algorithms, is likely to reduce the
   barrier to rogue algorithms.  However this separation and the ability
   to introduce new congestion control algorithms is a key part of the
   motivation for this work.

   It is also important to note that web browsers have already largely
   defeated TCP's ability to regulate congestion by opening many
   concurrent connections.  When a Web page contains content served from
   multiple domains (the norm these days) all modern browsers open
   between 35 and 60 connections (see:
   http://www.browserscope.org/?category=network ).  This is the Web
   community's deliberate workaround for TCP's perceived poor
   performance and inability make full use of certain types of consumer
   grade networks.  As a consequence the transport layer has already
   lost a substantial portion of its ability to regulate congestion.  It
   was not anticipated that the tragedy of the commons in Internet
   congestion would be driven by competition between applications and
   not between TCP implementations.

   In the short term, we can continue to try to use standards and peer
   pressure to moderate the rise in overall congestion levels, however
   the only real solution is to develop mechanisms in the Internet



Mathis                  Expires January 16, 2013               [Page 13]


Internet-Draft                 Laminar TCP                     July 2012


   itself to apply some sort of backpressure to overly aggressive
   applications and transport protocols.  We need to redouble efforts by
   the ConEx WG and others to develop mechanisms to inform policy with
   information about congestion and it's causes.  Otherwise we have a
   looming tragedy of the commons, in which TCP has only a minor role.

   Implementers that change Laminar from counting bytes to segments have
   to be cautious about the effects of ACK splitting attacks[Savage99],
   where the receiver acknowledges partial segments for the purpose of
   confusing the sender's congestion accounting.


10.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


11.  References

   [Jacobson88]
              Jacobson, V., "Congestion Avoidance and Control",
              SIGCOMM 18(4), August 1988.

   [RFC2140]  Touch, J., "TCP Control Block Interdependence", RFC 2140,
              April 1997.

   [RFC2861]  Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
              Window Validation", RFC 2861, June 2000.

   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
              RFC 2914, September 2000.

   [RFC3517]  Blanton, E., Allman, M., Fall, K., and L. Wang, "A
              Conservative Selective Acknowledgment (SACK)-based Loss
              Recovery Algorithm for TCP", RFC 3517, April 2003.

   [RFC4015]  Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm
              for TCP", RFC 4015, February 2005.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, September 2009.

   [RFC5682]  Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata,
              "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
              Spurious Retransmission Timeouts with TCP", RFC 5682,



Mathis                  Expires January 16, 2013               [Page 14]


Internet-Draft                 Laminar TCP                     July 2012


              September 2009.

   [RFC6582]  Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
              NewReno Modification to TCP's Fast Recovery Algorithm",
              RFC 6582, April 2012.

   [PRRid]    Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional
              Rate Reduction for TCP",
              draft-mathis-tcpm-proportional-rate-reduction-01 (work in
              progress), July 2011.

   [IMC11PRR]
              Mathis, M., Dukkipati, N., Cheng, Y., and M. Ghobadi,
              "Proportional Rate Reduction for TCP", Proceedings of the
              2011 ACM SIGCOMM conference on Internet measurement
              conference , 2011.

   [Savage99]
              Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
              "TCP congestion control with a misbehaving receiver",
              SIGCOMM Comput. Commun. Rev. 29(5), October  1999.

   [Visweswaraiah99]
              Visweswaraiah, V., "Improving Restart of Idle TCP
              Connections", Tech Report USC TR 97-661, November 1997.


Author's Address

   Matt Mathis
   Google, Inc
   1600 Amphitheater Parkway
   Mountain View, California  93117
   USA

   Email: mattmathis@google.com















Mathis                  Expires January 16, 2013               [Page 15]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/