Re: [multipathtcp] charter discussion

Behcet Sarikaya <> Fri, 07 April 2017 20:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 902E51289B0 for <>; Fri, 7 Apr 2017 13:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 MaUCfNLAnrX9 for <>; Fri, 7 Apr 2017 13:19:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C21B1243FE for <>; Fri, 7 Apr 2017 13:19:06 -0700 (PDT)
Received: by with SMTP id u2so341351wmu.0 for <>; Fri, 07 Apr 2017 13:19:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XaTC75Xp3JQxLDrPlCr9/1b5jedjamySDNWA+b78Wg0=; b=ZBZ3mCEUE+cZ5fy8yf+41IZ/gzIjV93/ETqTAcqma8FWJu+NX/64vxqMtTEl3ERyik LD9wdDdx2tBwQm+CiS7NKmIiMptf3Q07InZGggCewI0X8OOndjIdAByfw+WMHaUEBz+T zuF1xPBBKuwm8WBx2IBnBODBn8wxHHCM0N3JKFux9dB5gEen0rbv7L674GPuqlAPVC2A e/ykUoWFjcg0gXLbhyvOr+MqPR0juUylkgAN8+fOpYaanuSJqwiZkph2b617nkj7Z243 rOjMGwfmMrM6nmgu8dXnrTmVj3AsuCt/XbhZRQ1jhuc1Y3Q9FPXsDITKJKkgNysMR3aY DSYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=XaTC75Xp3JQxLDrPlCr9/1b5jedjamySDNWA+b78Wg0=; b=Iu9mkYan51kHBht4UfsEQqvHdwCO0OLHUV68vckxUOEzuF8LEMa2ATR3mx3uttqXVg XDm1D7db4vKb4N0p65LSIG8AwSqF6KCLT7lT0bHwKYkb64dDKyNZBkIJEYvfzMXC3xcr qBaeY3HHJOwFbyS/8hGqj2huL1OgobRv3kiyxpzKpki0X7oTZKQ4UrO+hswPDH+fBX2j asr5Lfl2COQkAz/6IF07b2j+PmvaPTq+aonW0sAifUsyiz2TStwiF2VltdcLpKhMbcnd tMWTm0M/yXiUyYM/MYViY3m/N2pnXEb0vTmUn6l73zju2ukWiSYBniUQdEGOnucgfZ1O M1bg==
X-Gm-Message-State: AN3rC/68A/3zD8/Xf/aA1olrPcShmfJwSK9Z1mwUzgT8am8OPl/vrsu+rCvIkiw0COUoine8+dmh6lBYuViwLQ==
X-Received: by with SMTP id r129mr865896wmd.54.1491596344802; Fri, 07 Apr 2017 13:19:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 7 Apr 2017 13:19:04 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Behcet Sarikaya <>
Date: Fri, 7 Apr 2017 15:19:04 -0500
Message-ID: <>
To: Olivier Bonaventure <>
Cc: "" <>
Content-Type: multipart/alternative; boundary=001a1145b59e47e071054c9956b6
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: Fri, 07 Apr 2017 20:19:09 -0000

On Fri, Apr 7, 2017 at 8:54 AM, Olivier Bonaventure <> wrote:

> Behcet,
>> 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.
> Option 2 is SOCKS. Option 1 places control information in the SYN and
> SYN+AC while SOCKS places this information in the bytestream.
> 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?
> This is common with proxies. SOCKS and HTTP proxies for example often use
> their own address to contact
> remote servers and not the client address. draft-plain-mode proposes a
> method to allow the proxy to learn the client address and thus use it to
> reach the final detaintion
> 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?
> Option 2 is SOCKS, thus the proxy uses its own address as a source to
> contact the final server.
So both Option 1 and Option 2 sends out TCP SYN with proxy own address
as the source. I thought the two TCP SYN s were different?

> A node sending a packet without its address as source address means it
>> is router, right?
> The node could have a pool of addresses like a CG-NAT
The way I understand is TCP SYN from each user (possibly many per user) is
effectively tunneled to the proxy using different mechanisms in Option 1
and Option 2, actually Option 2 makes it more implicit.
It seems like not only TCP SYN but all three-way TCP handshake needs to be

CPE has to deal with many parallel MPTCP connections to the same endpoint,
the proxy. I think that HTTP proxy does not have this type of problem.

This is my evaluation.



> Olivier