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

"Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <> Tue, 11 April 2017 14:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37CC51294AF for <>; Tue, 11 Apr 2017 07:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8hXNfpWifWtg for <>; Tue, 11 Apr 2017 07:04:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A24AA1294C9 for <>; Tue, 11 Apr 2017 07:04:21 -0700 (PDT)
X-Comment: SPF check N/A for local connections - client-ip=;;;
DKIM-Filter: OpenDKIM Filter v2.11.0 6118D4008DA3
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=letsgomars; t=1491919460; bh=ZTNZPDALQrkDBW7xMHdyWZ5cictV8xD7+4rJ0Juqmbg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=g+yIeRdNVfF1eJlVO7jytIYB16X168//1WnJrNIJlAapyqBE/75a0JEJbCH7CDxZz mJXLyzyP2847G8xND+UMKe4H0LPpcRY3OKwpdbayaQ1ByKefbtWn4uMJ3hJ4DogMeX EMx2GAtEW0/nsgGFftugA+1P5VL36qq3Bv2y1ZPz0/4qB7MUxjgUhzKm40KAP869d1 /bJY0a3TUGOA6HqI7IEmjur/AchHstmb3a5/vw0+F48swArOBQGuVO4ns8Qw0AKhD9 sun0O2IhRoSUzyU9wDsiKuwNwyvP8znpFS20WyF6WlB9Y0du3jxVAPc74H8oHgdEJB EiIQvUsn99s1A==
Received: from ( []) by (Postfix) with ESMTP id 6118D4008DA3; Tue, 11 Apr 2017 09:04:20 -0500 (CDT)
Received: from pps.filterd ( []) by ( with SMTP id v3BE0RFv020693; Tue, 11 Apr 2017 09:04:20 -0500
Received: from ( []) by with ESMTP id 29rxmwgh89-7; Tue, 11 Apr 2017 09:04:19 -0500
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 09:02:50 -0500
From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <>
To: Sayee Kompalli Chakravartula <>
CC: "" <>, "" <>
Thread-Topic: [multipathtcp] A question related to MPTCP control overhead
Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVgBBumyAAGYmpIAAJQxLgAA9u5OAAAEC/IA=
Date: Tue, 11 Apr 2017 14:02:50 +0000
Message-ID: <>
References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> <> <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs>
In-Reply-To: <5C068B455EB58047BBD492DA2B0829FA3763D266@blreml501-mbs>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-11_12:, , signatures=0
Archived-At: <>
Subject: Re: [multipathtcp] A question related to MPTCP control overhead
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Apr 2017 14:04:28 -0000

Hi Sayee,

I am not quite sure I understand how you are keeping sequence numbers straight for the case where you drop from 2 subflows to 1 subflow and want to stop using the DSS. Could you provide some details? What do you do when there is outstanding data on the subflow that goes away?


> On Apr 11, 2017, at 9:33 AM, Sayee Kompalli Chakravartula <> wrote:
> Dear Olivier,
> 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.
> 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. 
> 3. Regarding middlebox performing segment splitting or coalescing:
> This behaviour of middlebox poses as much risk to my way of doing things as it does to the existing MPTCP specification. Because the existing mitigation does not depend on whether we continue to support DSNs on MPTCP connection consisting of just one subflow, the same solution will continue to work whether or not we support DSS for MPTCP connection consisting of just one subflow.
> 4. ALG modifying the data stream by adding or removing bytes from the payload:
> This issue is relevant when a MPTCP option is included in a segment, and the same protocol behaviour will work in my case too.
> I haven't prepared a detailed write-up to share with IETF folks, which I will do once I am fairly confident that I have worked out all corner cases.
> Sayee