Internet DRAFT - draft-deng-mptcp-nrsack

draft-deng-mptcp-nrsack













    Network Working Group                                     Zhenjie Deng
    Internet Draft                                                   UCAS
    Intended status: Standards Track                      December 2, 2013
    Expires: May 3, 2014



           Non-Renegable Selective Acknowledgements (NR-SACKs) for MPTCP
                          draft-deng-mptcp-nrsack-00.txt


    Status of this Memo

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

       This Internet-Draft is submitted in full conformance with the
       provisions of BCP 78 and BCP 79. This document may not be modified,
       and derivative works of it may not be created, and it may not be
       published except as an Internet-Draft.

       This Internet-Draft is submitted in full conformance with the
       provisions of BCP 78 and BCP 79. This document may not be modified,
       and derivative works of it may not be created, except to publish it
       as an RFC and to translate it into languages other than English.

       This document may contain material from IETF Documents or IETF
       Contributions published or made publicly available before November 10,
       2008. The person(s) controlling the copyright in some of this
       material may not have granted the IETF Trust the right to allow
       modifications of such material outside the IETF Standards Process.
       Without obtaining an adequate license from the person(s) controlling
       the copyright in such materials, this document may not be modified
       outside the IETF Standards Process, and derivative works of it may
       not be created outside the IETF Standards Process, except to format
       it for publication as an RFC or to translate it into languages other
       than English.

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





    Deng, et al             Expires May  3, 2014                  [Page 1]

    Internet-Draft      Non-renegable SACK for MPTCP         December 2013


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

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

       This Internet-Draft will expire on May 3, 2014.

    Copyright Notice

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

       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.

    Abstract

       Multipath Transmission Control Protocol (MPTCP) [RFC6824] adopts
       Selective Acknowledgements (SACKs) at the subflow level to allow an
       MPTCP receiver to acknowledge the receipt of out-of-order data. In
       MPTCP, SACK information is expected (but not mandated)--though SACKs
       notify a data sender the reception of specific out-of-order data, the
       out-of-order data cannot be delivered to application layer until it
       has been cumulatively acknowledged at the connection-level. The MPTCP
       data receiver is permitted to later abandon the out-of-order data
       cached in the receive buffer. The out-of-order data is called
       renegable. Since the delivery of a SACKed out-of-order data is
       renegable, the sender has to maintain copies of SACKed data in the
       send buffer until it is cumulatively acked. As a result, the send
       buffer is inevitably wasted and the transmission rate is restricted
       even though the network is not congested.



    Deng, et al              Expires May 3, 2014                  [Page 2]

    Internet-Draft      Non-renegable SACK for MPTCP         December 2013


       In current MPTCP, only the packets have been cumulatively acked and
       delivered to the application are considered as non-renegable. The
       transport sender has to maintain the renegable packets in the
       retransmission queue in case of retransmission. SACKs in MPTCP
       inevitably result in send buffer wastage. Interestingly, MPTCP
       implementation can be configured such that the MPTCP receiver is not
       allowed to and therefore discard the out-of-order data.

       This document specifies an extension to MPTCP's acknowledgement
       mechanism called Non-Renegable Selective Acknowledgements (NR-SACKs).
       This mechanism allows a data receiver to explicitly inform the data
       sender of non-renegable out-of-order data. That is, the data receiver
       will not discard the out-of-order data such that retransmission is
       not required for them. Therefore, the data sender can remove the NR-
       SACKed out-of-order data from the retransmission queue and the
       application can write the new data to the send buffer.

    Table of Contents


       1. Introduction ................................................ 3
       2. Conventions used in this document
                                           ............................ 4
       3. Negotiation ................................................. 4
       4. Non-renegable SACK (NR-SACK)
                                      ................................. 5
       5. INNA Consideration .......................................... 7
       6. Security Considerations
                                 ...................................... 7
       7. References .................................................. 8
          7.1. Normative References
                                   .................................... 8
          7.2. Informative References
                                     .................................. 8
       8. Acknowledgments ............................................. 8

    1. Introduction

       To provide full end-to-end reliable data transfer, MPTCP specifies a
       connection-level acknowledgement, to act as a cumulative ACK for the
       connection as a whole. That is the "Data ACK" field of the Data
       Sequence Signal (DSS) option. Meanwhile, In MPTCP, each subflow acts
       as a standard TCP connection with its own subflow-level sequence
       numbers space (i.e., the regular sequence numbers in the TCP header).
       The data sequence mapping is used to define the mapping from the
       subflow sequence number to the data sequence number. Through the use
       of this mapping, the data stream can be reassembled and delivered to
       the application layer. SACKs information is advisory at the subflow
       level to improve efficiency. In this document, we refer to the "Data
       ACK" at the connection-level as "cum-ack", the selective
       acknowledgement at the subflow-level as "Gap-ack".



    Deng, et al              Expires May 3, 2014                  [Page 3]

    Internet-Draft      Non-renegable SACK for MPTCP         December 2013


       In current MPTCP implementation, the connection-level Data ACK and
       the subflow level acknowledgements are separated. Data has been
       received and delivered to the application layer only when it is cum-
       acked. The segments are delivered to the receive buffer after
       acknowledgement at the subflow level and a receiver has the freedom
       to drop them. For example, there is not enough memory space to cache
       the out-of-order segments. Discarding a previously gap-acked segment
       is known as "reneging". Due to the characteristic of the renegable
       out-of-order data, any gap-acked segment MUST be maintained in the
       data sender's retransmission queue until it is later cum-acked at the
       connection-level.

       There are some situations that the out-of-order data in the receive
       buffer will never be discarded. That is, reneging will never take
       place. For example, the out-of-order data is delivered to and handled
       by the application layer instead of dropping from the receive buffer
       due to the memory constraint. In these situations, a data sender can
       improve transmission efficiency by removing the out-of-order data in
       the retransmission queue and the application can write the new data
       into the send buffer. This document describes an extension to MPTCP
       to allow for Non-Renegable Selective Acknowledgements (NR-SACKs).
       Some MPTCP operations SHOULD be modified to allow this extension to
       be implemented. Such modifications, such as the structure of the NR-
       SACK, will be described in section 4.

       If NR-SACKs are used, the data receiver MAY include the Data Sequence
       Number (DSN) of the delivered out-of-order segments in a NR-SACK
       message to inform a data sender the deliveries have occurred and the
       out-of-order segments are non-renegable, allowing the data sender to
       remove the copies of the delivered segments from the retransmission
       queue even before the segments are cum-acked.

    2. Conventions used in this document

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

    3. Negotiation

       Before sending/receiving NR-SACKs, both peer endpoints MUST support
       and agree on using NR-SACKs. Note that all MPTCP operations are
       signaled with a TCP option, this agreement MUST be negotiated during
       the initiation of an MPTCP connection and the "MP_CAPABLE" option of
       the MPTCP [RFC6824] MUST be modified to contain the
       "NR_SACK_CAPABLE"field to declare its capability of NR-SACK.
       The structure of "NR_SACK_CAPABLE" option will be described
       in the next section.


    Deng, et al              Expires May 3, 2014                  [Page 4]

    Internet-Draft      Non-renegable SACK for MPTCP         December 2013


       Note that the connection initiation of MPTCP begins with the three-
       way handshake containing a SYN, SYN/ACK, ACK exchange on an
       initiating path. An endpoint supporting and expecting the NR-SACK
       extension of MPTCP MUST explicitly contain the "MP_CAPABLE" and the
       "NR_SACK_CAPABLE" option in each packet exchanging during the
       initiation phase. The receive endpoint MUST assume that the send
       endpoint is capable of NR-SACK if it receive the
       "NR_SACK_CAPABLE" message from the peer endpoint.

       Both endpoints MUST support NR-SACKs for either endpoint to expect to
       use NR-SACK. If one of the SYN, SYN/ACK, and ACK signals does not
       contain "NR_SACK_CAPABLE" option, the connection MUST not use NR-SACK
       and fallback to standard MPTCP described as [RFC6824]. After the
       initiation of the MPTCP connection, an endpoint MUST not negotiate
       the use of NR-SACK.

    4. Non-renegable SACK (NR-SACK)

       In order to support the Non-renegable SACK, a new TCP option of MPTCP
       signaled in the Data Sequence Signal (DSS) option MUST be defined to
       transfer NR-SACK information. Figure 1 describes the meaning of each
       field of the NR-SACK option of MPTCP. Note that MPTCP uses the "Data
       ACK" in the DSS option for cumulative acknowledgement at connection-
       level; similarly, the NR-SACK is also signaled in the DSS option. We
       refer to the Non-renegable SACKs as "nr-gap-ack".

       As the NR-SACKs are also signaled in the DSS option, many NR-SACKs
       fields are similar to the "Data ACK" option. Some fields in the NR-
       SACKs option have the same semantics with the corresponding fields in
       the "Data ACK" option.

       Similar to the "Data ACK" option, the NR-SACK is sent the peer
       endpoint to (1) acknowledge the segments received in-order through
       cumulative acknowledgement, (2) explicitly inform the peer endpoint
       of the non-renegable out-of-order segments.














    Deng, et al              Expires May 3, 2014                  [Page 5]

    Internet-Draft      Non-renegable SACK for MPTCP         December 2013


                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

                 +---------------+---------------+-------+----------------------+

               |       Kind     |       Length   | Subtype |(reserved)  |n|N|F|m|M|a|A|

                 +---------------+---------------+-------+----------------------+

               |             Data ACK (4 or 8 octets, depending on flags)           |

                 +--------------------------------------------------------------+

                 |             Number of NR Gap Ack Blocks = N                  |

                 +--------------------------------------------------------------+

                 | NR Gap Ack Block #1 Start (4 or 8 octets, depending on flags)|

                 +-------------------------------+------------------------------+

                 |  NR Gap Ack Block #1 End (4 or 8 octets, depending on flags) |

                 +-------------------------------+------------------------------+

               |                                 ...                                |

                 +--------------------------------------------------------------+

                 | NR Gap Ack Block #N Start (4 or 8 octets, depending on flags)|

                 +-------------------------------+------------------------------+

                 |  NR Gap Ack Block #N End (4 or 8 octets, depending on flags) |

                 +-------------------------------+------------------------------+

                             Figure 1: NR-SACK option

       The flags, n and N, when set, define the contents of this option, as
       follow:

       O  N = Non-renegable SACK present

       O  n = Non-renegable SACK is 8 octets (if not set, NR-SACK is 4
       octets), note that 'n' only has meaning when the corresponding flag
       'N' is set.



    Deng, et al              Expires May 3, 2014                  [Page 6]

    Internet-Draft      Non-renegable SACK for MPTCP         December 2013


       Subtype

       This field contains the INNA defined MPTCP operation for
       "NR-SACK" option. The suggested value of this field for
       INNA is 0X2.

       Data ACK: used for cumulative acknowledgement

       Number of NR Gap Ack Blocks: Indicates the number of Non-Renegable Gap Ack
       Blocks included in this NR-SACK.

       NR Gap Ack Block Start:

       The length of this field depends on the flags 'n' and'N'. When 'n'
       is set, the length is 8 octets (if not set, NR-SACK is 4 octets).
       This field indicates the start offset of Data sequence number of the
       NR Gap Ack Block. This number is set relative to the cumulative
       acknowledgement number defined in the "Data ACK" field. The actual
       value of this field is calculated by subtracting the value in the
       "Data ACK" field from the first data sequence number in the NR Gap
       Ack Block.

       NR Gap Ack Block End:

       The length of this field depends on the flags 'n' and'N'. When 'n'
       is set, the length is 8 octets (if not set, NR-SACK is 4 octets).
       This field indicates the end offset of data sequence number of the NR
       Gap Ack Block. This number is set relative to the cumulative
       acknowledgement number defined in the "Data ACK" field. The actual
       value of this field is calculated by subtracting the value in the
       "Data ACK" field from the first data sequence number in the NR Gap
       Ack Block.

    5. INNA Consideration

       None

    6. Security Considerations

       Security considerations discussed in [RFC6887] are to be taken into
       account.

       Security considerations discussed in [RFC6824] are to be taken in to
       account when creating new TCP subflows.






    Deng, et al              Expires May 3, 2014                  [Page 7]

    Internet-Draft      Non-renegable SACK for MPTCP         December 2013


    7. References

    7.1. Normative References

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

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

       [3]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP
             Extensions for Multipath Operation with Multiple Addresses",RFC
             6824, January 2013.

       [4]  Natarajan P, Ekiz N, Yilmaz E, et al. Non-renegable selective
             acknowledgments (NR-SACKs) for SCTP[C]//Network Protocols, 2008.
             ICNP 2008. IEEE International Conference on. IEEE, 2008: 187-
             196.

    7.2. Informative References

       [5]  Dreibholz T, Becke M, Adhari H, et al. Evaluation of a new
             multipath congestion control scheme using the NetPerfMeter
             tool-chain[C]//Software, Telecommunications and Computer
             Networks (SoftCOM), 2011 19th International Conference on. IEEE,
             2011: 1-6.

       [6]  Ford A, Raiciu C, Handley M, et al. TCP Extensions for
             Multipath Operation with Multiple Addresses: draft-ietf-mptcp-
             multiaddressed-03[R]. Roke Manor, 2011.

       [7]  Barre S, Bonaventure O, Raiciu C, et al. Experimenting with
             multipath TCP[J]. ACM SIGCOMM Computer Communication Review,
             2010, 40(4): 443-444.

    8. Acknowledgments

       This Internet Draft is the result of a great deal of constructive
       discussion with several people, notably Yinlong Liu, Shoushou Ren,
       Yahui Hu and Song Ci.

       This document was prepared using 2-Word-v2.0.template.dot.






    Deng, et al              Expires May 3, 2014                  [Page 8]

    Internet-Draft      Non-renegable SACK for MPTCP         December 2013


    Authors' Addresses

       Zhenjie Deng
       UCAS
       Institute of Acoustics, North Fourth Ring Road,
       Haidian District, No. 21,Beijing 100190
       P.R. China

       Email: dengzhj@hpnl.ac.cn


       Yinlong Liu
       UCAS
       Institute of Acoustics, North Fourth Ring Road,
       Haidian District, No. 21,Beijing 100190
       P.R. China

       Email: Liuyl@hpnl.ac.cn
































    Deng, et al              Expires May 3, 2014                  [Page 9]