Re: [multipathtcp] charter discussion

Behcet Sarikaya <sarikaya2012@gmail.com> Fri, 07 April 2017 20:19 UTC

Return-Path: <sarikaya2012@gmail.com>
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 902E51289B0 for <multipathtcp@ietfa.amsl.com>; Fri, 7 Apr 2017 13:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 MaUCfNLAnrX9 for <multipathtcp@ietfa.amsl.com>; Fri, 7 Apr 2017 13:19:06 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C21B1243FE for <multipathtcp@ietf.org>; Fri, 7 Apr 2017 13:19:06 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id u2so341351wmu.0 for <multipathtcp@ietf.org>; Fri, 07 Apr 2017 13:19:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.28.143.135 with SMTP id r129mr865896wmd.54.1491596344802; Fri, 07 Apr 2017 13:19:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.169.228 with HTTP; Fri, 7 Apr 2017 13:19:04 -0700 (PDT)
Reply-To: sarikaya@ieee.org
In-Reply-To: <cdd4736c-992a-cef3-0f69-d2dc0d128c40@uclouvain.be>
References: <CAC8QAcewg+z+xcJ80yrPPt7KPuvMye-aNzOuHKCjsJspocQKYA@mail.gmail.com> <cdd4736c-992a-cef3-0f69-d2dc0d128c40@uclouvain.be>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Fri, 7 Apr 2017 15:19:04 -0500
Message-ID: <CAC8QAcdYRPCWnCc=s1XM1er1T5jxUDto+u0cg8uu6qd9_yV_hQ@mail.gmail.com>
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary=001a1145b59e47e071054c9956b6
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/xxL4jUteMIgAN2w0ImIW8-KWHdQ>
Subject: Re: [multipathtcp] charter discussion
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: Fri, 07 Apr 2017 20:19:09 -0000

On Fri, Apr 7, 2017 at 8:54 AM, Olivier Bonaventure <
Olivier.Bonaventure@uclouvain.be> 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
tunneled.

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.

Regards,

Behcet


>
> Olivier
>