Re: [multipathtcp] q about draft-bonaventure-mptcp-converters
Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Wed, 19 July 2017 07:59 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 D11B3131C1D for <multipathtcp@ietfa.amsl.com>; Wed, 19 Jul 2017 00:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 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, 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 Mav86SXBzff7 for <multipathtcp@ietfa.amsl.com>; Wed, 19 Jul 2017 00:59:54 -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 F421A131C08 for <multipathtcp@ietf.org>; Wed, 19 Jul 2017 00:59:53 -0700 (PDT)
Received: from mbpobo.local (unknown [80.188.36.206]) (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 F105267DAD4; Wed, 19 Jul 2017 09:59:43 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp4.sgsi.ucl.ac.be F105267DAD4
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1500451184; bh=eZwRIKcb1USj/M8Hnz3VpNCTnFEirgLwRkWKGWkQ3sY=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=NjpnIWZBzZBjM0SdsMlmnvDxwtS7I8iSbP13CPBxPalB+MXovSAv25AS2zMFnFLDW Xh82nUW8QWbinSxiJ59FS9uqeE6Kne/hk7hMYIMr7mFWFjxtnhB7fB+yQkCa+8ozOG CS273PKLh0v95T93stm56Wx2uS4m3LVbclNsq4t8=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.2 at smtp-4
Reply-To: Olivier.Bonaventure@uclouvain.be
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, multipathtcp <multipathtcp@ietf.org>
References: <CAO249yfHWHpvboUoPhSN4RU+pVD29juiPMYETsUgb=rUmvGyqw@mail.gmail.com>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <0d42fc28-07ec-15c1-d8ac-ae88849a154d@uclouvain.be>
Date: Wed, 19 Jul 2017 09:59:42 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAO249yfHWHpvboUoPhSN4RU+pVD29juiPMYETsUgb=rUmvGyqw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr-classic
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: F105267DAD4.A0FED
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/H0wd1YsL6Sy9_y1ZphrrdQupkWE>
Subject: Re: [multipathtcp] q about draft-bonaventure-mptcp-converters
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: Wed, 19 Jul 2017 07:59:57 -0000
Yoshifumi,
>
> I am sorry that my question was not clear during the meeting.
> I think one use case we had before was a client which doesn't support
> mptcp can still utilize mptcp in some part of the path.
> Could you explain how to handle this case?
Thanks for the clarification. The situation is typically the following :
client -- cpe -- net 1 --- converter ---- server
+---- net 2 ------+
In this case, the cpe runs a transparent TCP proxy that intercepts the
TCP connection established by the client. This TCP proxy implements the
converter protocol and interacts with the converter through net1 and/or
net2.
The transparent TCP proxy running on the cpe does not need to be
standardised and various forms of such proxies are deployed. What needs
to the standardised is the format of the messages that the cpe exchanges
with the converter and this is what the draft proposes.
Olivier
- [multipathtcp] q about draft-bonaventure-mptcp-co… Yoshifumi Nishida
- Re: [multipathtcp] q about draft-bonaventure-mptc… Olivier Bonaventure