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

Olivier Bonaventure <> Wed, 27 July 2016 08:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEC5B12DD72 for <>; Wed, 27 Jul 2016 01:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vy4WE__ksRVE for <>; Wed, 27 Jul 2016 01:43:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 192AB12DD6E for <>; Wed, 27 Jul 2016 01:43:01 -0700 (PDT)
Received: from mbpobo.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 9CCB367E06A; Wed, 27 Jul 2016 10:42:53 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 9CCB367E06A
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; 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: <> <>
From: Olivier Bonaventure <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: 9CCB367E06A.A53C6
X-SGSI-MailScanner: Found to be clean
X-SGSI-Spam-Status: No
Archived-At: <>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Jul 2016 08:43:03 -0000


> 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.