Re: [multipathtcp] towards a potential work item on two-ended proxy

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Wed, 27 July 2016 08:43 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 BEC5B12DD72 for <multipathtcp@ietfa.amsl.com>; Wed, 27 Jul 2016 01:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
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, 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 Vy4WE__ksRVE for <multipathtcp@ietfa.amsl.com>; Wed, 27 Jul 2016 01:43:01 -0700 (PDT)
Received: from smtp4.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 192AB12DD6E for <multipathtcp@ietf.org>; Wed, 27 Jul 2016 01:43:01 -0700 (PDT)
Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 9CCB367E06A; Wed, 27 Jul 2016 10:42:53 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp4.sgsi.ucl.ac.be 9CCB367E06A
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1469608973; bh=Rp0abNgeC3tsvB8PmcFf7YnLVF00P9tZzm9RTqGl+2I=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=eiDiCDuHfsP/j0unufgx+GKyo+MvQhS14ZUWjTH95SNgOKwwnmky80LzQoSS+ij41 10AWcIveXl6MfsNb7pcbV9NSspqAZAP13ieVLqYMJjZ7X+HxuDBlKN+YSIbaI3xCDd 61zC62zzZ1ZF5uraYb3kqaohMIgkjglYJ3hTjKKU=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-4
References: <b779dd12f1bb412c96c800eddaaf0247@rew09926dag03b.domain1.systemhost.net> <e2aa6ac517194af4b8c25c07f8e469fb@rew09926dag03b.domain1.systemhost.net>
To: philip.eardley@bt.com, multipathtcp@ietf.org
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <9cafc779-502e-cc7f-676c-f6659e207c81@uclouvain.be>
Date: Wed, 27 Jul 2016 10:43:14 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <e2aa6ac517194af4b8c25c07f8e469fb@rew09926dag03b.domain1.systemhost.net>
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: 9CCB367E06A.A53C6
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/qlPNrx6o-wqazm4U0vX-ZEvgkHk>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Olivier.Bonaventure@uclouvain.be
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: Wed, 27 Jul 2016 08:43:03 -0000

Phil,

> So far this discussion has made me a bit confused. Let me ask a specific
> question:-
>
> Why do we need both transparent and plain mode? If these are addressing
> different usage scenarios, please explain them (in a paragraph?)

The two modes address different deployment scenarios.

In the transparent mode, the HAG resides on the path to/from the client. 
There are many ways in current networks to ensure that the HAG is on the 
path of the clients that it serves. The transparent mode requires one 
option to distinguish between end-to-end MPTCP connections (directly 
established by the client using an MPTCP stack) and proxied connections. 
During IETF96, the authors of plain-mode and transparent-mode agreed 
that the transparent-mode draft would use an emply plain mode option to 
indicate that a connection has been proxied.

In the plain-mode, the HAG does not need to be on the path to/from the 
client. The plain-mode option is used to signal the original 
source/destination address of the connection depending on the usage.




Olivier