Internet DRAFT - draft-palanivelanchetansenthil-mptcp-enhancements

draft-palanivelanchetansenthil-mptcp-enhancements



 



INTERNET-DRAFT                                             A. Palanivelan
Intended Status: Experimental                                Verizon Labs
Expires: Apr 19, 2016                                       Chetan Harsha
                                                             Verizon Labs
                                                        Senthil Sivakumar
                                                            Cisco Systems
                                                             Oct 17, 2015


                    MPTCP Enhancement Opportunities
          draft-palanivelanchetansenthil-mptcp-enhancements-00


Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2015 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.
 


Palanivelan,Chetan,.      Expires Apr 19,2016                   [Page 1]

INTERNET DRAFT      MPTCP Enhancement Opportunities          Oct 17,2015


Abstract

   MPTCP Intends to address a wide range of issues, with minimal
   implementation tweaks. Though this works in a range of use
   cases,there are some use cases, where some standard implementation
   recommendations could help. The Purpose of this draft is to document
   Opportunities, where Enhancements to MPTCP can translate to more
   wider deployments.


Table of Contents

   1  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
      1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
   2 MPTCP Enhancement Opportunities - End user Use cases  . . . . . . 3
      2.1 Short Flows vs Long Flows  . . . . . . . . . . . . . . . . . 3
      2.2 Application based Path selection and Adaptive buffering  . . 4
      2.3 Path Selection Enhancements  . . . . . . . . . . . . . . . . 4
      2.4 Optimal number of paths  . . . . . . . . . . . . . . . . . . 5
   3 UseCase Scenarios (Simulated in Lab) and Results  . . . . . . . . 6
      3.1 MPTCP Enabled Client Uploads data from Non-MPTCP Capable
          Server   . . . . . . . . . . . . . . . . . . . . . . . . . . 6
      3.2 MPTCP Enabled Client Uploads data from MPTCP Enabled
          Server   . . . . . . . . . . . . . . . . . . . . . . . . . . 6
      3.3 MPTCP Enabled Client Uploads data from Non-MPTCP Capable
          Server with Intermediate MPTCP Enabled devices (proxy?)  . . 6
      3.4 MPTCP Enabled Client Uploads data from MPTCP Enabled
          Server with Intermediate MPTCP Enabled devices (proxy?)  . . 6
      3.5 MPTCP Enabled Client Downloads data from Non-MPTCP
          Capable Server   . . . . . . . . . . . . . . . . . . . . . . 7
      3.6 MPTCP Enabled Client Downloads data from MPTCP Enabled
          Server   . . . . . . . . . . . . . . . . . . . . . . . . . . 7
      3.7 MPTCP Enabled Client Downloads data from Non-MPTCP
          Capable Server with Intermediate MPTCP Enabled devices (proxy?)  . 7
      3.8 MPTCP Enabled Client Downloads data from MPTCP Enabled
          Server with Intermediate MPTCP Enabled devices (proxy?)  . . 7
   4  Security Considerations  . . . . . . . . . . . . . . . . . . . . 8
   5  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 8
   6  References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
      6.1  Normative References  . . . . . . . . . . . . . . . . . . . 8
      6.2  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8






 


Palanivelan,Chetan,.      Expires Apr 19,2016                   [Page 2]

INTERNET DRAFT      MPTCP Enhancement Opportunities          Oct 17,2015


1  Introduction

   The Scope of the use cases discussed is limited to impact on end-user
   experience only and recommended updates at SP (PE Router). The
   initial versions of this draft would document findings from tests
   covering various end-user use cases in detail, that presents mptcp
   enhancement opportunities. The later versions of the document would
   strive to provide solutions for the documented usecase scenarios.

1.1  Terminology

   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 RFC 2119 [RFC2119].

2 MPTCP Enhancement Opportunities - End user Use cases

2.1 Short Flows vs Long Flows

   Internet traffic MUST have Security, Throughput, Reliability,.. taken
   care across different network conditions, modes of access and flows.
   Data access can be categorized into short or long flows.

   Too many Small Flows => Higher Number of Transactions. But, much less
   Bandwidth Consumption

      Can we achieve Low latency for short flows?

      Average completion of flow with mptcp can be higher than
      completion time without mptcp With Bunch of Short Flows, MPTCP may
      negatively impact throughput

      Even a single lost packet can force an entire connection to wait
      for an RTO.

   Far Lesser Long Flows => Lesser Number of Transactions. But, higher
   Bandwidth Consumption

      Can we achieve higher Throughput for Long Flows Without
      compromising on performance?

      How do we maintain Reliability? How do we manage tolerance to
      sudden and high bursts of traffic?

   In Summary, Both long and short flows are important from the enduser
   perspective. We need to come up with appropriate definition and clear
   demarcation for short and long flows, from MPTCP Perspective. These
   need be dealt differently (Probably with multiple profiles).
 


Palanivelan,Chetan,.      Expires Apr 19,2016                   [Page 3]

INTERNET DRAFT      MPTCP Enhancement Opportunities          Oct 17,2015


2.2 Application based Path selection and Adaptive buffering

   How much of benefit it would be when we consider different type of
   applications, for better mptcp profiling. Typical internet
   applications are categorized as Elastic and InElastic.

   Elastic vs Inelastic Applications..How does it matter to MPTCP?

      MPTCP performance is impacted :

        When the size of the receive buffer is limited.

        Path with high RTT may result in the receive buffer size
        growing beyond the allowed maximum

        Diversified RTT

      Different ways of handling packets => Better Performance.

   In Summary, Application based Path Selection and Adaptive Buffering
   can help with the above scenarios. Tweaking the buffer sizes based on
   the type of application and/or network condition can positively
   impact the flows.

2.3 Path Selection Enhancements

   Path Selection is one of the important part of MPTCP. Though there
   are existing tools that help diagnose issues in the path, there still
   is scope to fine tune it further flexible based on certain factors.

   Usecases where MPTCP path selection can be enhanced:

      For High packet loss and High latency networks?

      Multiple profiles to dynamically switch (move across) the
      networks?

      Roaming scenarios

   In Summary, The best optimal path is ever changing in the Internet.
   Frequent switching may cause unnecessary overheads and can impact
   performance. Enhanced yet controlled Path Selection and Path
   Switching can help get better performance out of the network.





 


Palanivelan,Chetan,.      Expires Apr 19,2016                   [Page 4]

INTERNET DRAFT      MPTCP Enhancement Opportunities          Oct 17,2015


2.4 Optimal number of paths

   The best and effective path selection is critical to the effect of
   MPTCP for the client application. How about the optimal number of
   sub-flows? Can we improve client experience by controlling number of
   sub flows based on certain factors? 

   Controlling the number of sub flows getting created:

   How many is too many? 

   Can this be controlled? What Inputs to Consider?

        Based on Network Characteristics

        Historic data (region wise)


   In Summary, MPTCP being not too strict as well as not too flexible,
   Certain profiling based on detailed analysis of data can positively
   impact MPTCP experience



























 


Palanivelan,Chetan,.      Expires Apr 19,2016                   [Page 5]

INTERNET DRAFT      MPTCP Enhancement Opportunities          Oct 17,2015


3 UseCase Scenarios (Simulated in Lab) and Results

   Data for enhancement opportunities are derived from our lab tests.
   These tests are done in a reasonably populated, yet contained test
   network. The initial set of tests are more focused on the throughput
   side and covers simulated Near, Mid and Far cell network conditions.
   The Intention is to get detailed data from set of tests to cover
   different types of data access (short/long or elastic/inelastic
   applications, mobile network conditions,..etc) as well as different
   mptcp profiles (for eg. number of sub flows). The detailed analysis
   and summary would be presented in the later sections of the document,
   followed by design/implementation recommendations for the SPs.


3.1 MPTCP Enabled Client Uploads data from Non-MPTCP Capable Server

   <Shared in IETF-94 WG Discussion.. Will be updated here>



3.2 MPTCP Enabled Client Uploads data from MPTCP Enabled Server

   <Shared in IETF-94 WG Discussion.. Will be updated here>



3.3 MPTCP Enabled Client Uploads data from Non-MPTCP Capable Server with
   Intermediate MPTCP Enabled devices (proxy?)

   <Shared in IETF-94 WG Discussion.. Will be updated here>



3.4 MPTCP Enabled Client Uploads data from MPTCP Enabled Server with
   Intermediate MPTCP Enabled devices (proxy?)

   <Shared in IETF-94 WG Discussion.. Will be updated here>











 


Palanivelan,Chetan,.      Expires Apr 19,2016                   [Page 6]

INTERNET DRAFT      MPTCP Enhancement Opportunities          Oct 17,2015


3.5 MPTCP Enabled Client Downloads data from Non-MPTCP Capable Server

   <Shared in IETF-94 WG Discussion.. Will be updated here>



3.6 MPTCP Enabled Client Downloads data from MPTCP Enabled Server

   <Shared in IETF-94 WG Discussion.. Will be updated here>




3.7 MPTCP Enabled Client Downloads data from Non-MPTCP Capable Server
   with Intermediate MPTCP Enabled devices (proxy?)

   <Shared in IETF-94 WG Discussion.. Will be updated here>



3.8 MPTCP Enabled Client Downloads data from MPTCP Enabled Server with
   Intermediate MPTCP Enabled devices (proxy?)

   <Shared in IETF-94 WG Discussion.. Will be updated here>
























 


Palanivelan,Chetan,.      Expires Apr 19,2016                   [Page 7]

INTERNET DRAFT      MPTCP Enhancement Opportunities          Oct 17,2015


4  Security Considerations

   None


5  IANA Considerations

   None


6  References 

6.1  Normative References

   [RFC2119]   S. Bradner, "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

6.2  Informative References

   [RFC6182]	Ford, A., Raiciu, C., Handley, M., Barre, S., and
               J.Iyengar, "Architectural Guidelines for Multipath TCP
               Development", RFC 6182, March 2011.

   [RFC6356]	Raiciu, C., Handley, M., and D. Wischik,"Coupled Congestion
               Control for Multipath Transport Protocols", RFC
               6356,October 2011.

Author's Addresses


      Palanivelan Appanasamy
      Manager Technology, Verizon Labs
      Bangalore, India
      Email: palanivelan.appanasamy@verizon.com  

      Chetan Harsha
      R&D Software Engineer, Verizon Labs
      Bangalore, India
      Email: chetan.harsha@verizon.com

      Senthil sivakumar
      Principal Engineer, Cisco systems
      Durham, NC
      Email: ssenthil@cisco.com







Palanivelan,Chetan,.      Expires Apr 19,2016                   [Page 8]