Re: [multipathtcp] charter discussion

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Fri, 07 April 2017 19:04 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 332EC1295B3 for <multipathtcp@ietfa.amsl.com>; Fri, 7 Apr 2017 12:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.729
X-Spam-Level:
X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, 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 exb1QGOlDPPb for <multipathtcp@ietfa.amsl.com>; Fri, 7 Apr 2017 12:04:50 -0700 (PDT)
Received: from smtp6.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 360511287A7 for <multipathtcp@ietf.org>; Fri, 7 Apr 2017 12:04:44 -0700 (PDT)
Received: from [192.168.1.6] (unknown [87.66.240.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 6795B67DD39; Fri, 7 Apr 2017 20:59:08 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp6.sgsi.ucl.ac.be 6795B67DD39
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1491591548; bh=6WEM3Rq9uE94TQMYHcRJuq8lT9fz1ELz7DI60Q6Qpg8=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=FZCEGdBSgiNO5OwVL29gqkUE/HKO2OIpYk9RuwNXic6l9LYPUa0YBqy5hVxUsbkri Xg0gkM1mD06BEVb5AIMM2HnOMFjpjD5/ojhQW0kR8BSGj6W8iSqClmDIRUQ3UYfvVr iLEHGSU6r16khAjNsKEPNhkeSwktjg5khAJIMsnk=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.2 at smtp-6
Reply-To: Olivier.Bonaventure@uclouvain.be
References: <CAC8QAcewg+z+xcJ80yrPPt7KPuvMye-aNzOuHKCjsJspocQKYA@mail.gmail.com>
To: sarikaya@ieee.org
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <cdd4736c-992a-cef3-0f69-d2dc0d128c40@uclouvain.be>
Date: Fri, 7 Apr 2017 15:54:38 +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: <CAC8QAcewg+z+xcJ80yrPPt7KPuvMye-aNzOuHKCjsJspocQKYA@mail.gmail.com>
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: 6795B67DD39.A3563
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/JTeudsC9ehJGOuxdIvz_ddRAylM>
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 19:04:52 -0000

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.

> 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


Olivier