Re: [multipathtcp] A question related to MPTCP control overhead

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Wed, 12 April 2017 07:16 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2751201FA for <multipathtcp@ietfa.amsl.com>; Wed, 12 Apr 2017 00:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTj9QPROrCMa for <multipathtcp@ietfa.amsl.com>; Wed, 12 Apr 2017 00:16:00 -0700 (PDT)
Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F2C124BFA for <multipathtcp@ietf.org>; Wed, 12 Apr 2017 00:16:00 -0700 (PDT)
Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 3FCB167DA39; Wed, 12 Apr 2017 09:15:48 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 3FCB167DA39
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1491981350; bh=18YGgX/4fiJD9wV46+udq0vG+2AcsBhODWPRVtx4k+0=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=T007A/QYReJ6KGroEJyQEN8FWfZ2JaY2/omzOTatRnpePYmP2FeSslqmkVKgrhPPy olyOyyhNBBtwyw4iISDaBFk/M+uHkKTSpc+rOsq58bH5F4Hmx7c0/6Ezgw9itRWq92 5LP/vP7kcsyGZcV0Sf6xkcszzgPe8RDrZdWO407I=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.2 at smtp-3
Reply-To: Olivier.Bonaventure@uclouvain.be
References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> <dbfc984c-e06e-b994-0503-c41abd334f31@uclouvain.be> <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs>
To: Sayee Kompalli Chakravartula <sayee.kompalli.chakravartula@huawei.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <73b2cd58-2b82-2245-1893-b26dbc8b30ed@uclouvain.be>
Date: Wed, 12 Apr 2017 09:15:48 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: 3FCB167DA39.A5553
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/hiIET95buZPTTImSLwUFQbkXKcU>
Subject: Re: [multipathtcp] A question related to MPTCP control overhead
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Apr 2017 07:16:03 -0000

Sayee,

> I read through the paper "Are TCP Extensions Middlebox-prrof?", and especially focused on the Section 3.3 on Multipath TCP and midleboxes. My comments are as follows:
>
> 1. Regarding middleboxes removing options from non-SYN segments:
> Currently, MPTCP handles this issue by attaching MPTCP option to every segment in the first window worth of data. An appropriate behaviour is defined for the sender and receiver to fallback to TCP in case middlebox removes the MPTCP option.
>
> In my proposal I say that, instead of appending MPTCP option to segments in the first window worth of data, we defer appending the MPTCP option to segments to a later time just before we establish the second flow and as described below.
>
> We will define an additional state variable DSS_RCV at both the sender and the receiver. At the beginning, this state variable will be initialized to false at both the ends. Now assume that the state variable NUM_SUBFLOW = 1 and DSS_RCV = false at the sender side and that the sender has send the DSS option for the first time. When DSS option is received with its state variable NUM_SUBFLOW = 1 and DSS_RCVD = false, the receiver will understand that the sender has decided to utilize the DSS option, and so it will update its state variable DSS_RCV = true and will ACK the segment that carried the DSS option with its own DSS option. When the sender receives ACK containing DSS option it will update its state variable DSS_RCV = true. Assuming that middlebox removes the DSS option included by the sender, the receiver will acknowledge the segment without DSS option. Because the ACK segment does carry DSS option the sender will fall back.

MPTCP as defined in RFC6824 supports both make-before-break and 
break-before-make, i.e. the
second subflow can be established at any time, either before or after 
the failure of the initial one. With your design, you force a 
make-before-break, this means that something has to be done (namely 
start uses DSS) before being able to create the second subflow. This is 
annoying because failover is one of the nice features of Multipath TCP.


> 2. To cope with sequence number randomizers:
> The same approach works with my proposal too, but with one little observation. Whenever the state variable NUM_SUBFLOW transitions from two to one, all the DSS related information is discarded, i.e., the space of DSNs and the mapping are removed from the protocol control block. But, when the state variable NUM_SUBFLOW again transitions from one to two, the space of DSNs will be created to establish mapping between SSS and DSS with one little difference: unlike when the MPTCP connection is established, for the subflow 1 we will not map the first DSN to subflow sequence zero but to the running subflow SN at that time.

I fear that a solution that tries to avoid DSS when there is a single
subflow and uses DSS as soon as there are two subflows would be very 
difficult to use. How do the client and the server agree that there are 
one or more subflows ? At a given time, they might have a different view 
of the state of the Multipath TCP connection.


Olivier