Re: [multipathtcp] charter discussion

<> Thu, 06 April 2017 09:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E9F31201FA for <>; Thu, 6 Apr 2017 02:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.396
X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xxbLdmdFZdNg for <>; Thu, 6 Apr 2017 02:06:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00FB51200FC for <>; Thu, 6 Apr 2017 02:06:11 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 6 Apr 2017 10:06:09 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 6 Apr 2017 10:06:09 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 10:06:08 +0100
Received: from ([fe80::d514:fe50:560c:401e]) by ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1210.000; Thu, 6 Apr 2017 10:06:08 +0100
Thread-Topic: charter discussion
Thread-Index: AQHSqjbkeB8hza43kkeFp7zv6Q4DoKG4ExUg
Date: Thu, 06 Apr 2017 09:06:07 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_814660b2aedf47efb66f671ef668f3e9rew09926dag03bdomain1sy_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] charter discussion
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: Thu, 06 Apr 2017 09:06:15 -0000


The slide was intended to be just a very high-level sketch. In both #1 and #2, the objective of the signalling is to get an endpoint’s IP address info into the ‘other’ proxy, so the proxy can do address mapping (translation) on subsequent packets (including the ACK) so that packets can travel between the endpoints. In both #1 and #2, the idea is that this signalling is done along with the TCP SYN, so that the connection via the proxies is set up with no delay (“0 RTT”)

Best wishes,

From: Behcet Sarikaya []
Sent: 31 March 2017 16:53
Cc: Eardley,PL,Philip,TUB8 R <>;; Joe Touch <>
Subject: charter discussion

Hi all,

Regarding the charter discussions that happened at the mptcp session on Thursday March 30, I asked a question but I could not understand the answer, let me ask it again.

In chairs slides page 12, TCP SYN shown in Option 1 and Option 2 actually were different although the slides seems to show that they are the same.

In Option 1, if the proxy sends TCP SYN than is it OK in a conversation the destination does not know who the source is?

In Option 2, if TCP SYN sent was the original TCP SYN from the source then

how come the TCP-ACK goes through the proxy?
A node sending a packet without its address as source address means it is router, right?