IETF Logo Mail Archive

[multipathtcp] Questions on https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09

<philip.eardley@bt.com> Thu, 10 November 2016 11:42 UTC

Return-Path: <philip.eardley@bt.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 9436412957B for <multipathtcp@ietfa.amsl.com>; Thu, 10 Nov 2016 03:42:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.098
X-Spam-Level:
X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 7V1UoxzwoEKY for <multipathtcp@ietfa.amsl.com>; Thu, 10 Nov 2016 03:42:12 -0800 (PST)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728CB129600 for <multipathtcp@ietf.org>; Thu, 10 Nov 2016 03:42:11 -0800 (PST)
Received: from EVCAS16-UKBR.domain1.systemhost.net (193.113.108.107) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 10 Nov 2016 11:42:03 +0000
Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVCAS16-UKBR.domain1.systemhost.net (193.113.108.107) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 10 Nov 2016 11:40:14 +0000
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 10 Nov 2016 11:40:13 +0000
Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1210.000; Thu, 10 Nov 2016 11:40:13 +0000
From: philip.eardley@bt.com
To: multipathtcp@ietf.org
Thread-Topic: Questions on https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09
Thread-Index: AdI7RtWPXAJrxKOvRqmf0uDPFFIgTg==
Date: Thu, 10 Nov 2016 11:40:12 +0000
Message-ID: <aad12c71ad5748368c31385e1d099d60@rew09926dag03b.domain1.systemhost.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.202.242]
Content-Type: multipart/alternative; boundary="_000_aad12c71ad5748368c31385e1d099d60rew09926dag03bdomain1sy_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/3go6iNYjdU9Snyt9WnMr4R55KKU>
Subject: [multipathtcp] Questions on https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-09
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 10 Nov 2016 11:42:14 -0000

A few questions

Sections 4 & 5 discuss operation with a single-ended proxy, ie one end host is MPTCP-enabled and the other end host is 'legacy' TCP. The figures and discussion seem to assume the MPTCP-enabled end host initiates the connection. Is the case also covered where the TCP end host initiates the connection?

In Sections 4 & 5, the MPTCP-enabled end host is assumed to know the address of the TCP end host. I assume this is through existing techniques. It may mean that an operator has to be careful, for instance if they're doing caching at the edge of the network and the proxy is more central. from the point of view of the path packets take, this seems the same drawback as if tunnelling is present - not sure if there could be unpleasant mptcp protocol interactions?

In section 6, two-ended MPTCP proxy (neither end host is MPTCP-enabled)

<<  If the downstream MCP is deployed on-path, it only terminates MPTCP
   connections that carry an empty MP_CONVERT option inside their SYN
   (i.e., no address is conveyed).  If the MCP receives a SYN segment
   that contains the MP_CAPABLE option but no MP_CONVERT option, it MUST
   forward the SYN to its final destination without any modification.
>>
Comment: I found the description confusing. Not sure what downstream and upstream mean, as the figure shows bi-directional communications. Off path and on path I also found confusing.

If I get it right, on path means that you guarantee the first subflow goes through the proxy - what happens if it doesn't?

what benefit does having this extra on-path (implicit mode) mechanism bring? (I know there's been some discussion on this, is there a summary of the conclusion?)

How does the first proxy know the address of the most appropriate second proxy (ie the proxy nearest the other end host)?

The mechanism mentions a token, is this a re-use of one of the existing tokens in https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ or a new one?

Thanks
phil

v2.23.0 | Report a Bug | By Email