<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3390 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3390.xml">
<!ENTITY RFC6928 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6928.xml">
<!ENTITY RFC6356 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6356.xml">
<!ENTITY RFC5681 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-barik-mptcp-lisa-01"
    ipr="trust200902">
    <front>
        <title abbrev="A Linked Slow-Start Algorithm for MPTCP">A Linked Slow-Start Algorithm for MPTCP
        </title>
        
        <author fullname="Runa Barik" initials="R."
            surname="Barik">
            <organization>University of Oslo</organization>
            <address>
                <postal>
                    <street>PO Box 1080 Blindern</street>
                    <city>Oslo</city>
                    <code>N-0316</code>
                    <country>Norway</country>
                </postal>
                <email>runabk@ifi.uio.no</email>
            </address>
        </author>
        
        <author fullname="Simone Ferlin" initials="S."
            surname="Ferlin">
            <organization>Simula Research Laboratory</organization>
            <address>
                <postal>
                    <street>P.O.Box 134</street>
                    <city>Lysaker</city>
                    <region></region>
                    <code>1325</code>
                    <country>Norway</country>
                </postal>
                <email>ferlin@simula.no</email>
            </address>
        </author>
        
        <author fullname="Michael Welzl" initials="M."
            surname="Welzl">
            <organization>University of Oslo</organization>
            <address>
                <postal>
                    <street>PO Box 1080 Blindern</street>
                    <city>Oslo</city>
                    <region></region>
                    <code>N-0316</code>
                    <country>Norway</country>
                </postal>
                <phone>+47 2285 2420</phone>
                <email>michawe@ifi.uio.no</email>
            </address>
        </author>
        
        <date year="2016" />
        <area>General</area>
        <workgroup>Multipath TCP</workgroup>
        <keyword>I-D</keyword>
        <keyword>Internet-Draft</keyword>
        <keyword>Lisa</keyword>
        
        <abstract>
            <t>
                This document describes the LISA (Linked Slow-Start Algorithm) for
                Multipath TCP (MPTCP). Currently during slow-start, subflows behave like
                independent TCP flows making MPTCP unfair to cross-traffic and
				causing more congestion at the bottleneck. This also yields more losses among
				the MPTCP subflows. LISA couples the initial windows (IW) of MPTCP subflows 
				during the initial slow-start phase to remove this adverse behavior.
                <!-- This document describes the mechanism of LISA, the "Linked Slow-Start
                Algorithm" for Multipath TCP (MPTCP). LISA is an algorithm that deals
                with MPTCP's subflow initial window coupling in the slow-start phase.
                One of the main goals of MPTCP is to achieve higher throughput than
                regular TCP by utilizing multiple paths simultaneously. And when MPTCP
                subflows share a bottleneck, MPTCP tries not to be more aggressive than
                regular TCP in congestion avoidance. This is achieved by MPTCP's coupled
                congestion control mechanism. However, the slow-start phase remains
                unchanged <xref target="RFC6356">RFC 3550</xref>, hence, all subflows at
                this stage behave like independent TCP flows, making MPTCP to behave
                unfairly to itself and to cross-traffic at the bottleneck. LISA's design
                departs from this state and provides coupling for the subflows initial
                window during the first slow-start.-->
            </t>
        </abstract>
    </front>
    
    <middle>
        <section anchor="Introduction" title="Introduction">
            <t>
                The current MPTCP
                implementation provides multiple congestion control algorithms, which
                aim to provide fairness to TCP flows at the shared bottlenecks.
                However, in <xref target="RFC6356">RFC 6356</xref>, the subflows' slow-start
                phase remains unchanged to <xref target="RFC5681">RFC 5681</xref>,
                and all the subflows at this stage behave like independent TCP flows.
                Following the development of IW as per <xref target="RFC6928"></xref>,
                each MPTCP subflow can start with IW = 10. With an increasing number of subflows,
                the subflows' collective behavior during the initial slow-start phase can temporarily be
                very aggressive towards a concurrent regular TCP flow at the shared bottleneck.</t>
                
                <t>According to <xref target="UIT02"></xref>, most of the TCP sessions in the Internet consist of
                short flows, e.g., HTTP requests, where TCP will likely never leave slow-start.
                Therefore, the slow-start behavior becomes of critical importance for the
                overall performance.</t>
                
                <t>To mitigate the adverse effect during initial slow-start, we introduce LISA,
                    the "Linked Slow-Start Algorithm". LISA
                shares the congestion window MPTCP
                subflows in slow start whenever a new subflow joins.</t>
            
            <section anchor="Definitions" title="Definitions">
                <t>
                    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
                    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
                    document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
                </t>
                
                <t>Acronyms used in this document:
                    <list hangIndent="10" style="hanging">
                        <t hangText="   IW --"> Initial Window </t>
                        <t hangText="   RTT --"> Round Trip Time </t>
                        <t hangText="   CWND --"> Congestion Window </t>
                        <t hangText="   Inflight --"> MPTCP subflow's inflight data </t>
                        <t hangText="   old_subflow.CWND --"> Congestion Window of the subflow having largest sending rate </t>
                        <t hangText="   new_subflow.CWND --"> New incoming subflow's Congestion Window </t>
                        <t hangText="   Ignore_ACKs --"> a boolean variable indicating whether ACKs should be ignored </t>
                        <t hangText="   ACKs_To_Ignore --"> the number of ACKs for which old_subflow.CWND stops increasing during slow-start</t>
                        <t hangText="   compound CWND --"> sum of CWND of the subflows in slow-start</t>
                    </list>
                </t>
            </section>
        </section>
        
        <section title="MPTCP Slow-Start Problem Description">
            
                <t>Since it takes 1 RTT for the sender to receive any feedback on a given
                TCP connection, sending an additional segment after every ACK is rather
                aggressive. Therefore, in slow-start, all subflows independently
                doubling their CWND as in regular TCP results in MPTCP also doubling
                its compound CWND. The MPTCP aggregate only diverges from this behavior
                when the number of subflows changes.
                Coupling of CWND is therefore not necessary in slow-start
                except when a new subflow joins.</t>
            
            <section anchor="MPTCP_test" title="Example of current MPTCP slow-start problem">
                 <t>We illustrate the problematic MPTCP slow-start behavior with an example: Consider an MPTCP
                    connection consisting of 2 subflows. The first subflow starts with IW = 10, and
                    after 2 RTTs the CWND becomes 40 and a new subflow joins, again with IW = 10.
                    Then, the compound CWND becomes 40+10 = 50. With an increasing number of subflows, the compound
                    CWND in MPTCP becomes larger than that of a concurrent TCP flow.</t>
                 
                 <t>For example, MPTCP with eight subflows (as recommended in <xref target="DCMPTCP11" /> for datacenters)
                    will have a compound CWND of 110 (40+7*10). As a result, MPTCP would behave unfairly to a
                    concurrent TCP flow sharing the bottleneck. This aggressive
                    behavior of MPTCP also affects the performance of MPTCP. If multiple subflows share a bottleneck,
					each of them doubling their rate every RTT, will cause excessive losses at the bottleneck. This makes
					MPTCP enter the congestion avoidance phase earlier and thereby increases the completion time of the transfer.</t>

                 <t>This problem, and the improvement attained with LISA, are documented in detail in <xref target="lisa"/>.</t>
             </section>
        </section>
        
        <section title="Linked Slow-Start Algorithm">
            
            <section title="Description of LISA">
                <t>
                    The idea behind LISA is that each new subflow takes a 'packet credit' from an
                    existing subflow in slow-start for its own IW. We design the mechanism such that a new subflow has 10 segments as
                    the upper limit <xref target="RFC6928"></xref> and 3 segments as the lower limit
                    <xref target="RFC3390"></xref>. This is based on <xref target="RFC6928"></xref>, <xref target="RFC3390"></xref>
                    and the main reason behind it is to let these subflows compete reasonably with other flows.
					We also divide the CWND fairly in order to give all subflows an equal chance when competing with each other.</t>
                
                <t>LISA first finds the subflow with the largest sending rate measured over the last RTT.
                    Depending on the subflow's CWND, between 3 and 10 segments are taken
                    from it as packet credit and used for the new subflow's IW.
                    The packet credit is realized by reducing the CWND from the old subflow and
                    halting its increase for ACKs_To_Ignore number of ACKs.</t>
                
                <t>We clarify LISA with the example given in <xref target="MPTCP_test" />.
                    After 2 RTTs, the old_subflow.CWND = 40 and a new_subflow joins the connection.
                    Since old_subflow.CWND >= 20 (refer to <xref target="Algorithm" />),
                    10 packets can be taken by the new_subflow.CWND, resulting in
                    old_subflow.CWND = 30 and new_subflow.CWND = 10. Hence, MPTCP's compound CWND,
                    whose current size is 40, should ideally become 60+20 = 80 after 1 RTT (assuming
                    a receiver without delayed ACKs).
                    However, if 40 segments from
                    old_subflow.CWND are already in flight, the compound CWND becomes in fact
                    70+20 = 90. Here, LISA keeps old_subflow.CWND from increasing for the
                    next 10 ACKs. In comparison, MPTCP without LISA would have a compound CWND of
                    80+20=100 after 1 RTT.
                </t>
        
            </section>
        
            <section anchor="Algorithm" title="Algorithm">
                <t>
                Below, we describe the LISA algorithm. LISA is invoked before a new subflow sends
                its IW.
            
                <list counter="grouping" style="format %d." >
                <t>
                    Before computing the new_subflow.CWND, Ignore_ACKs = False and ACKs_To_Ignore = 0.
                </t>
                <t>
                    Then, ignoring the new_subflow, the subflow in slow-start with the largest
                    sending rate (old_subflow.CWND, measured over the last RTT) is selected.
                </t>
                <t>
                    If there is no such subflow, the IW of the new_subflow.CWND = 10
                    Otherwise, the following steps are executed:
                    
                    <list style="hanging">
                            <t> if old_subflow.CWND &ge; 20  // take IW(10) packets
                            <list style="hanging">
                                <t> old_subflow.CWND -= 10 </t>
                                <t> new_subflow.CWND = 10 </t>
                                <t> Ignore_ACKs = True </t>
                            </list></t>
                            <t> else if old_subflow.CWND &ge; 6    // take half the packets
                                <list style="hanging">
                                    <t> new_subflow.CWND -= old_subflow.CWND / 2 </t>
                                    <t> old_subflow.CWND -= new_subflow.CWND </t>
                                    <t> Ignore_ACKs = True </t>
                                </list></t>
                             <t> else
                              <list style="hanging">
                                        <t> new_subflow.CWND = 3  // can't take from old_subflow</t>
                               </list></t>
               </list></t>
               <t> if Ignore_ACKs and Inflight &gt; old_subflow.CWND
                <list style="hanging">
                    <t>// do not increase CWND when ACKs arrive</t>
                    <t> ACKs_To_Ignore = Inflight - old_subflow.CWND </t>
                </list></t>
            </list></t>
             </section>
        </section>
                
                
                <section title="Implementation Status">
                    <t>
                        LISA is implemented as a patch to the Linux kernel 3.14.33+ and
                        within MPTCP's v0.89.5. It is meant for research and provided by the
                        Unviersity of Oslo and Simula Research Laboratory,
                        and available for download from http://heim.ifi.uio.no/runabk/lisa
                        This code was used to produce the test results that are reported in <xref target="lisa"></xref>.
                    </t>
                </section>     
<!--
                <section title="Conclusions">
                    <t>
                        We identify the adverse effect of MPTCP's uncoupled slow-start on
                        the performance of MPTCP itself and on concurrent TCP traffic.
                        We propose LISA, a linked slow-start algorithm for MPTCP that
                        couples MPTCP subflows during slow-start phase. LISA was implemented as a patch
                        to the Linux kernel and evaluated in both emulated and real testbeds <xref target="lisa"/>.
						In this evaluation, we observed that TCP (CUBIC) completes its transmission earlier than MPTCP
						without LISA. This is due to the large overshoot when an additional subflow joins,
						causing more retransmissions. LISA solves this problem.
                    </t>
                </section>
-->

                <section anchor="Acknowledgements" title="Acknowledgements">
                    <t>
                        This work was part-funded by the European Community under its Seventh
                        Framework Programme through the Reducing Internet Transport Latency (RITE)
                        project (ICT-317700). The authors also would like to thank David Hayes (UiO) for his comments.
                        The views expressed are solely those of the authors.
                    </t>
                </section>
                
                <section anchor="IANA" title="IANA Considerations">
                    <t>This memo includes no request to IANA.</t>
                </section>
                
                <section anchor="Security" title="Security Considerations">
                </section>
                
                <section anchor="ChangeHistory" title="Change History">
                    <t>Changes made to this document:
                        <list hangIndent="16" style="hanging">
                            <t hangText="  00->01 :">Some minor text improvements and updated a reference.</t>
                        </list>
                    </t>
                    </section>
                    
                </middle>
                <back>
                    <references title="Normative References">
                        <!-- Here we use entities that we defined at the beginning. -->
                        &RFC2119;
                        &RFC3390;
                        &RFC5681;
                        &RFC6928;
                        &RFC6356;
                    </references>
                    <references title="Informative References">
                        <!-- Tech Report -->
                        <reference anchor="lisa">
                            <front>
                                <title>LISA: A Linked Slow-Start Algorithm for MPTCP</title>
                                <author initials="R.B." surname="Barik" fullname="R. Barik"> </author>
                                <author initials="M.W." surname="Welzl" fullname="M. Welzl" > </author>
                                <author initials="S.F." surname="Ferlin" fullname="S. Ferlin" > </author>
                                <author initials="O.A." surname="Alay" fullname="O. Alay" > </author>
                                <date year="2016" />
                            </front>
                            <seriesInfo name="IEEE ICC 2016, Kuala Lumpur, Malaysia" value="" />
                        </reference>

                        <reference anchor="UIT02">
        		  <front>
          			<title>Understanding internet traffic streams: Dragonflies and tortoises</title>

          			<author initials="N." surname="Brownlee">
            			<organization>California University</organization>
          			</author>
          			<author initials="K.C." surname="Claffy">
            			    <organization>California University</organization>
      		         	</author>
              			<date year="2002" />
        		</front>
	  		<seriesInfo name="IEEE Communications Magazine" value="p110-117"/>
     			 </reference>
                        
                        <reference anchor="DCMPTCP11">
                            <front>
                                <title>Improving datacenter performance and robustness with multipath TCP</title>
                                
                                <author initials="C. Raiciu" surname="Raiciu">
                                </author>
                                <author initials="S. Barre" surname="Barre">
                                </author>
                                <author initials="C. Pluntke" surname="Pluntke">
                                </author>
                                <author initials="A. Greenhalgh" surname="Greenhalgh">
                                </author>
                                <author initials="D. Wischik" surname="Wischik">
                                </author>
                                <author initials="M. Handley" surname="Handley">
                                </author>
                                <date year="2011" month="August"/>
                            </front>
                            <seriesInfo name="ACM SIGCOMM" value="p266-277"/>
                        </reference>


                    </references>
                    
                </back>
            </rfc>
