From nobody Mon Sep 11 01:15:21 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C378713301E for ; Mon, 11 Sep 2017 01:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 L6RMSbuMzwos for ; Mon, 11 Sep 2017 01:15:17 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72913132F49 for ; Mon, 11 Sep 2017 01:15:17 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 05224340C81 for ; Mon, 11 Sep 2017 10:15:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.12572); Mon, 11 Sep 2017 10:15:15 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Mon, 11 Sep 2017 10:15:15 +0200 (CEST) Received: from [192.33.93.168] (account ietf@trammell.ch HELO ict-networks-010-044-033-100.fwd-v4.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 29207929 for tsv-area@ietf.org; Mon, 11 Sep 2017 10:15:15 +0200 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_6CF5D98C-1C29-49D6-8C8C-586B1261EFE1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Fwd: [PANRG] IETF100: Call for agenda items Message-Id: References: To: tsv-area@ietf.org Date: Mon, 11 Sep 2017 10:15:14 +0200 X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 08:15:20 -0000 --Apple-Mail=_6CF5D98C-1C29-49D6-8C8C-586B1261EFE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, transport people, Since the proposed Path Aware Networking (PAN) research group touches on = themes we've grappled with recently (continuously?) in transport (see = https://datatracker.ietf.org/rg/panrg/about/ for our current charter = proposal), please consider proposing an agenda item for the PAN RG = meeting in Singapore! One specific suggestion from Mirja at the mic at the first RG meeting = Prague: there are a litany of transport-area proposals for getting = link-layer information, which is related to path properties as we = envision them in PAN, so even just a quick RG document enumerating ideas = we know don't work and why would be useful for scoping future work in = this RG. Thanks, cheers, Brian (PAN(P)RG co-chair) > Begin forwarded message: >=20 > From: Jen Linkova > Subject: [PANRG] IETF100: Call for agenda items > Date: 11 September 2017 at 06:02:25 GMT+2 > To: panrg@irtf.org > Cc: panrg-chairs@irtf.org >=20 > Hello, >=20 > IETF100 is just two months away. We have requested a 2hrs slot > for the PANRG session and now it's time to build the agenda. >=20 > If you'd like to present at PANRG sessions in Singapore > or just have any ideas/suggestion for the agenda items please contact > panrg-chairs@irtf.org before Oct 12th (the earlier the better = indeed!). >=20 > See you in Singapore! >=20 > --- > Jen Linkova on behalf of PANRG Chairs. >=20 > _______________________________________________ > Panrg mailing list > Panrg@irtf.org > https://www.irtf.org/mailman/listinfo/panrg --Apple-Mail=_6CF5D98C-1C29-49D6-8C8C-586B1261EFE1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZtkYTAAoJEIoSt78L6kajon4QAIhqqWzdQT/zoomHtBgyDZLm 79GbJvvagVo2vTSr0NbTxqmYH+i+lPfT+a+/8Hfbb0lye0ZQEuGBX1pfcM4v1l4k eV32SH8hNCUJETtncf24POFQEDBl5DXXf6pwhmHnjhVfGdix4lWcLNJQ7F3NBW3/ /HdQx8vEyTHHhCTnIjg1SnJVefW2G7nrfI8u6YHnLj9QKXrz8Ursd+PYns8aGHQq J3wBCX2shQvNxx8wcvUNqTAeL5bJiT8K3aHY0Caee+cj91k9DfCVFhF0RUbzsurx C0ebgCYWbVHGkNN0+rx3RIgvg0G+2HGlLrFju4obt3x3Sew5jqpEnULE/FdRyW0A 4Mm/Y6VV7Z7+aa7jZ6JwubhcsJdrTFiX9dUt+u0H6HR14e7yi1jz101c3FrQIvut xbQgPiA0DnVvvr5pkV7HS7kOVa6NycAQsa5NPE9mKMa6aYX5PXvW85sxdkYKdLPJ momwIoWLCgIhXhzCM2ToW90dgQGbQwlHXLslMEr4rQKqWr9DM0y2hz8sOymaVphZ aT31MLnbcFBo1gs/uDW9TBXy1f7yDxThjuBUFGfU+R4Q2cqVknxXZ7qm5QsxGSa4 pLC5Rfmp8PWe0A9OAIi/w12kdShDmCYJfjzNuNgqOIKB2ZsyM5Ck+WfkLyB4hi2/ r0ZFdUGC/NxMIlH0ea/q =915K -----END PGP SIGNATURE----- --Apple-Mail=_6CF5D98C-1C29-49D6-8C8C-586B1261EFE1-- From nobody Wed Sep 13 08:01:55 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F351326ED; Wed, 13 Sep 2017 08:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 8IiI74Q9DOwU; Wed, 13 Sep 2017 08:01:45 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8F01321C7; Wed, 13 Sep 2017 08:01:43 -0700 (PDT) Received: from EVHUB03-UKBR.domain1.systemhost.net (193.113.108.185) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 13 Sep 2017 16:01:28 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVHUB03-UKBR.domain1.systemhost.net (193.113.108.185) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Sep 2017 16:01:24 +0100 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.1293.2; Wed, 13 Sep 2017 16:01:22 +0100 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.1293.004; Wed, 13 Sep 2017 16:01:22 +0100 From: To: , , Subject: Progressing the MPTCP proxy work Thread-Topic: Progressing the MPTCP proxy work Thread-Index: AdMsoSjtjzHKadusSUOFh+9ZCBbgfw== Date: Wed, 13 Sep 2017 15:01:21 +0000 Message-ID: <2efd30edab0647dda78246734f89a3f1@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.233] Content-Type: multipart/alternative; boundary="_000_2efd30edab0647dda78246734f89a3f1rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:01:48 -0000 --_000_2efd30edab0647dda78246734f89a3f1rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At the IETF we discussed (in MPTCP WG) a new proposal on MPTCP proxy, "0-RT= T TCP converters" https://tools.ietf.org/html/draft-bonaventure-mptcp-conve= rters This seemed to get a good reception, and had taken on board the feed= back about the "plain mode" draft. We believe the next steps are: * WGs - TCPM & MPTCP - please send any further initial comments= , especially if you believe it hasn't dealt with technical concerns that we= re raised about the "plain mode" draft, or if you have fresh concerns * Authors - please rev the document to deal with comments so fa= r. Please include TCPM & tsvarea mailing lists. * Chairs - assuming these steps go well, we'll be looking to do= a consensus call on adopting as a WG doc (ADs to confirm MPTCP WG; TCPM is= the other possibility) Thanks, Best wishes, Phil & Yoshi --_000_2efd30edab0647dda78246734f89a3f1rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

At the IETF we discussed (in MPTCP WG) a new proposal on MPTCP pro= xy, “0-RTT TCP converters” https://tools.ietf.org/html/draft-bonaventure-mptcp-converters&n= bsp; This seemed to get a good reception, and had taken on board the feedba= ck about the “plain mode” draft.

We believe the next steps are:

•       =       WGs – TCPM & MPTCP - please send a= ny further initial comments, especially if you believe it hasn’t deal= t with technical concerns that were raised about the “plain mode̶= 1; draft, or if you have fresh concerns

•       =       Authors – please rev the document to d= eal with comments so far. Please include TCPM & tsvarea mailing lists.<= o:p>

•       =       Chairs – assuming these steps go well,= we’ll be looking to do a consensus call on adopting as a WG doc (ADs= to confirm MPTCP WG; TCPM is the other possibility)

Thanks,

Best wishes= ,

Phil & = Yoshi

 

--_000_2efd30edab0647dda78246734f89a3f1rew09926dag03bdomain1sy_-- From nobody Sat Sep 16 11:54:23 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077351326F3 for ; Sat, 16 Sep 2017 11:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 zz7L4sIvFdvb for ; Sat, 16 Sep 2017 11:54:13 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55962132076 for ; Sat, 16 Sep 2017 11:54:13 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id m35so4664352qte.1 for ; Sat, 16 Sep 2017 11:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MiWA1Lpc4m3x7BWeskfkPqELF/c9Isl3YW+Qpq1wV+8=; b=bsDitQMQvtmFpY5rSGc0Sdta/PvoTLQagfTBuFfpZUfifcPtPyNrPVE8apjaUPMwNu EgBOtB3cTnoVm+zNabgpT7FZscQCjJdx9JjORR1IXsXJhxtBHVGV/vncCxDPsR678Ye8 RamXNMm/MQFXNbEGmETJEB5YtqmJW+IDA9MSIHYMIGmek8N550SGNUDM4eKLPaTK+hh1 d5KO7nDw8enkfPH0a2u37FFdHwLwHxepzo+X8cliAKosE2o4qaYiyUHMhgRIkB/iaCQM VLEIC81TG/qNe8JYAmlG/KYdH763G3iJLGncWn+LOU4EXrJoOP4uSHUUNg5CogO+GPX9 tmMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MiWA1Lpc4m3x7BWeskfkPqELF/c9Isl3YW+Qpq1wV+8=; b=o2jDEYod1ZVskkxnzBv/GokdTesTGz5VNS2LmdnFW9WE9KwvBavlAdQBHXSWC5BhcQ iVqLExh8FuLt2TlK+5V6oIN6dgQu0Ko9cxa18Z9pSuaLTO5Zd/SNfQ2rcCm4ckl55h9x vCpzyxcB9VpD+RbBwjkEI7xQ4S/5ySQpeOO5ijQW7tK4u25UdwDCIoFvgIzcCP0aGRQC vrKMh80kQqA1AyO8JgT16D6URVG6UDOhE352Sbtd3avZavmIxlwFPzoY3k7XBuW8uX9e 4DhTH1Td6gB4MmI7HsXPewCxNgqArmcxO3S1RlJ8FyYZ4gmOBD3aNOU64Qu8ZNwvaZwT QSqg== X-Gm-Message-State: AHPjjUiTLotwh0HoEDRrohVS/tKUdQ9eiaDKItENLquDUAF1hR2d47LY dPhhcG4YNG/oXyRmvElwgcUd8mp3af/cZevUVImsJA== X-Google-Smtp-Source: AOwi7QB1KGyh98Y0rNEGVR+WVHKGYBKvSTje2B64qaHdcf2Ob2kJA3BSRUeJgFpAhoUMLX0g1P6UQSi8VOqJ4zb0DDU= X-Received: by 10.200.43.140 with SMTP id m12mr23128316qtm.58.1505588052155; Sat, 16 Sep 2017 11:54:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.61.196 with HTTP; Sat, 16 Sep 2017 11:54:11 -0700 (PDT) In-Reply-To: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> From: Tom Herbert Date: Sat, 16 Sep 2017 11:54:11 -0700 Message-ID: Subject: Re: Progressing the MPTCP proxy work To: philip.eardley@bt.com Cc: multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2017 18:54:16 -0000 On Wed, Sep 13, 2017 at 8:01 AM, wrote: > Hi, > > At the IETF we discussed (in MPTCP WG) a new proposal on MPTCP proxy, =E2= =80=9C0-RTT > TCP converters=E2=80=9D > https://tools.ietf.org/html/draft-bonaventure-mptcp-converters This seem= ed > to get a good reception, and had taken on board the feedback about the > =E2=80=9Cplain mode=E2=80=9D draft. > > We believe the next steps are: > > =E2=80=A2 WGs =E2=80=93 TCPM & MPTCP - please send any furthe= r initial comments, > especially if you believe it hasn=E2=80=99t dealt with technical concerns= that were > raised about the =E2=80=9Cplain mode=E2=80=9D draft, or if you have fresh= concerns > Hello, I have some concerns about both the motivation and solution described in the draft. The primary motivation stated for this protocol seems to be that "deploying those extensions on both a wide range of clients and servers remains difficult". That's a pretty general and subjective rationalization. The argument that things take too long to deploy can be applied to nearly any protocol; for instance, a similar argument was recently given in 6man to justify the need for IPv10 since IPv6 is taking too long to deploy. The typical problems with this argument are three fold: 1) it presumes that development and deployment of an interim solution will take less time than to deploy the protocol being fixed 2) it doesn't address the root cause of why a protocol is taking long to deploy in the first place 3) the interim solution likely creates new problems and incompatibilities that need to be dealt with. For this draft I think these should be considered in the specific context of MPTCP. For #1 the assumption, the key assertion in the draft is "There are some situations where the transport stack used on clients (resp. servers) can be upgraded at a faster pace than the transport stack running on servers (resp. clients)."-- I think the reality of this is quite debatable. Major content provider providers that make up the bulk Internet traffic, such as Google and Facebook, upgrade their front end web server software at a much faster rate than clients typically do. There a good examples, TFO for instance, where there was support for new TCP features on servers long before clients. The other part of this is that the solution assumes client support of MPTCP. AFAIK Android (which represents a huge number of clients) does not ship with an MPTCP implementation even though its been part of IOS since 2013. So, the real question that should be asked is why isn't MPTCP being deployed which leads to problem #2. I suspect a major reason that MPTCP is not deployed in Android or servers is that fact that upstream Linux has not adopted the implementation. There was an effort a while back to get it into the stack, however there was pushback because of the invasiveness of the code (it was 1000's of lines of core TCP code change). Unfortunately, the developers didn't followup and continue working on reducing the complexity of implementation. I think with enough persistence in addressing the feedback the code would eventually make it in. Even so, acceptance into Linux is not a requirement for deployment. Google and Facebook could be running MPTCP on their servers, and Android could shipped with MPTCP support. I suspect the reason they're not doing that is motivation. If they were convinced that MPTCP is a great value to users, they can make deployment happen quickly. For #3, the problems of the interim solution need to be elaborated. TCP is an end to end protocol, and we know that whenever a middlebox attempts to transparently process TCP some things will break. As section 5 states "The Converter protocol was designed to be used in networks that do not contain middleboxes that interfere with TCP." -- the irony of this statement is that the converter itself becomes a middlebox that interferes with TCP. The converter has many of the same issues of other middlebox solutions (proxies, firewalls) in the network that are invasive at the transport layer. For instance E2E security (e.g. TCP-AO) is likely broken. Also, I have to wonder about the case where the client and server support an option that is unknown to the converter-- say for instance that an experimental option is being used for a new feature such as we did with TFO. In this case I don't see how the converter can deal with the option, passing it through between MPTCP and non-MPTCP may or may not be correct. So probably the only reasonable behavior is to drop unknown options. But, then that means the endpoints would be bound to using only TCP options that the converter supports, so ultimately the converter is an obstacle not a facilitator for deploying new options. Perhaps the biggest irony of this proposal is that the converter is stateful for a connection, so all packets must flow through a single point in the network. Like stateful firewalls, this inevitably becomes a bottleneck and a single point of failure. I believe that is nearly the exact opposite of what MPTCP endeavors to provide. A few comments about the text: In several places the term "TCP extensions" is used, I think "TCP options" is the more correct term. In Section 2.1: The arguments that SOCKS can't be used are not entirely convincing to me. "the converter protocol leverages the TFO option [RFC7413] to place all its control information inside the SYN and SYN+ACK packets." I'm not sure what "control information" means here. Is this referring to TCP options, an inband control protocol, or something else? It seems to me that support for SOCKS to use TFO should be straightforward, in fact the draft even states that has been proposed for SOCKS. "A second difference is that the converter protocol takes the TCP extensions explicitly into account." Per #3 above, the converter can only take into account TCP options that it understands and it can't deal with options like TCP-AO that must be truly end to end. Given these limitations, and the fact that a SOCKS should be running on an modern TCP stack that supports all the common options, I'm not sure how much tangible value there is in this difference. The third argument may have merit, but I would point out that this difference applies to all proxies and they are ubiquitous in deployment. Also, we are adding kProxy (in kernel proxy) for the Linux stack which actually would allow SYN forwarding in proxies without finishing client side connection establishment to give the same effect of the solution in the draft. Tom From nobody Sun Sep 17 13:24:54 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20A2133343; Sun, 17 Sep 2017 13:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, URIBL_BLOCKED=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 QrTZ7dDgK0ut; Sun, 17 Sep 2017 13:24:48 -0700 (PDT) Received: from smtp1.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 21FB6133342; Sun, 17 Sep 2017 13:24:45 -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@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id B474C67DC38; Sun, 17 Sep 2017 22:24:29 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp1.sgsi.ucl.ac.be B474C67DC38 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1505679870; bh=FfVqVOsKbvTDmVjMw+gxo1B0gwc/DYXC8l+GlA8A9RI=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=H0zi98nTEg2y2+5HHfpu43ZeyQ74jfEXqlZ9UaVbHeA6PASSHzwuKNoFN2IkjZccb Dgkg4lp40p+yn4Wk1rItRSM6bxezjJcWEtVhnP4OvpFKzZjHd1xzE5eO8DnlF9t612 AwjycdxoArhp7Y48XzQsQ1mbiFQ5W6Ahtt3AfHjs= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-1 Reply-To: Olivier.Bonaventure@uclouvain.be Subject: Re: [multipathtcp] Progressing the MPTCP proxy work To: Tom Herbert , philip.eardley@bt.com Cc: multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> From: Olivier Bonaventure Message-ID: <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> Date: Sun, 17 Sep 2017 22:24:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: 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: B474C67DC38.A5FD9 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 20:24:53 -0000 Tom, Thanks for your comments. > For #1 the assumption, the key assertion in the draft is "There are > some situations where the transport stack used on clients (resp. > servers) can be upgraded at a faster pace than the transport stack > running on servers (resp. clients)."-- I think the reality of this is > quite debatable. Major content provider providers that make up the > bulk Internet traffic, such as Google and Facebook, upgrade their > front end web server software at a much faster rate than clients > typically do. Major content providers are one part of the Internet, but not the entire Internet. Many companies are still using old servers running Linux 2.x > There a good examples, TFO for instance, where there was > support for new TCP features on servers long before clients. Looking at TFO servers for example, a recent paper showed that TFO is enabled on only 0.1% of the web sites https://irtf.org/anrw/2017/anrw17-final16.pdf and 80% of these sites are part of Google's AS. > The other > part of this is that the solution assumes client support of MPTCP. > AFAIK Android (which represents a huge number of clients) does not > ship with an MPTCP implementation even though its been part of IOS > since 2013. So, the real question that should be asked is why isn't > MPTCP being deployed which leads to problem #2. In Korea, Samsung and LG have deployed MPTCP on various types of Android smartphones. > I suspect a major reason that MPTCP is not deployed in Android or > servers is that fact that upstream Linux has not adopted the > implementation. There was an effort a while back to get it into the > stack, however there was pushback because of the invasiveness of the > code (it was 1000's of lines of core TCP code change). Unfortunately, > the developers didn't followup and continue working on reducing the > complexity of implementation. I think with enough persistence in > addressing the feedback the code would eventually make it in. I agree, there is engineering effort to bring MPTCP in the mainline Linux kernel, but this is outside the scope of IETF. > Even so, > acceptance into Linux is not a requirement for deployment. Google and > Facebook could be running MPTCP on their servers, and Android could > shipped with MPTCP support. I suspect the reason they're not doing > that is motivation. If they were convinced that MPTCP is a great value > to users, they can make deployment happen quickly. Apple is using MPTCP on both their clients and their servers. Starting with iOS11, all applications will be able to use MPTCP. This is a reasonable deployment AFAIK. Korea is another example. > > For #3, the problems of the interim solution need to be elaborated. > TCP is an end to end protocol, and we know that whenever a middlebox > attempts to transparently process TCP some things will break. As > section 5 states "The Converter protocol was designed to be used in > networks that do not contain middleboxes that interfere with TCP." -- > the irony of this statement is that the converter itself becomes a > middlebox that interferes with TCP. The converter has many of the same > issues of other middlebox solutions (proxies, firewalls) in the > network that are invasive at the transport layer. Agreed, but note that the converter was designed to enable the client to detect when the server supports the required extension (e.g. MPTCP) so that it can stop using the converter to reach this particular server. This means that as a particular extension gets deployed, the utilisation of the converter will diminish. > For instance E2E > security (e.g. TCP-AO) is likely broken. If a client requests TCP-AO, then it's clear that this TCP connection should not go through a converter. > Also, I have to wonder about > the case where the client and server support an option that is unknown > to the converter-- say for instance that an experimental option is > being used for a new feature such as we did with TFO. In this case I > don't see how the converter can deal with the option, passing it > through between MPTCP and non-MPTCP may or may not be correct. So > probably the only reasonable behavior is to drop unknown options. The client can detect which options are supported by the converter. If the client wants to use an option that is not supported by a specific converter, it should not use this particular converter. > But, > then that means the endpoints would be bound to using only TCP options > that the converter supports, so ultimately the converter is an > obstacle not a facilitator for deploying new options. No because the client can decide to not use the converter. > Perhaps the > biggest irony of this proposal is that the converter is stateful for a > connection, so all packets must flow through a single point in the > network. Like stateful firewalls, this inevitably becomes a bottleneck > and a single point of failure. This is a drawback of using a converter, but one needs to compare this drawback with the benefits of using the option on a part of the end-to-end path. > I believe that is nearly the exact > opposite of what MPTCP endeavors to provide. It depends where the converter is located. If you consider a smartphone use case, a converter placed in an ISP backbone could enable its users to combine WiFi and 4G to reach any server with MPTCP. There is a real benefit in doing this as shown by the deployments in Korea, Turkey or Thailand. Hybrid access networks that combine xDSL and LTE are another example where the client benefits from combining different networks with MPTCP. > A few comments about the text: > > In several places the term "TCP extensions" is used, I think "TCP > options" is the more correct term. Thanks, I will reread the document again to catch those. > In Section 2.1: > > The arguments that SOCKS can't be used are not entirely convincing to me. > > "the converter protocol leverages the TFO option [RFC7413] to place > all its control information inside the SYN and SYN+ACK packets." > > I'm not sure what "control information" means here. Is this referring > to TCP options, an inband control protocol, or something else? This relates to the TLV messages of the converter protocol. > > It seems to me that support for SOCKS to use TFO should be > straightforward, in fact the draft even states that has been proposed > for SOCKS. > > "A second difference is that the converter protocol takes the TCP > extensions explicitly into account." > > Per #3 above, the converter can only take into account TCP options > that it understands and it can't deal with options like TCP-AO that > must be truly end to end. Given these limitations, and the fact that a > SOCKS should be running on an modern TCP stack that supports all the > common options, I'm not sure how much tangible value there is in this > difference. The converter enables the client to detect which options are supported by the final server so that the client can bypass the converter if the server supports the required options. > > The third argument may have merit, but I would point out that this > difference applies to all proxies and they are ubiquitous in > deployment. Also, we are adding kProxy (in kernel proxy) for the Linux > stack which actually would allow SYN forwarding in proxies without > finishing client side connection establishment to give the same effect > of the solution in the draft. Excellent Thanks Olivier From nobody Sun Sep 17 19:05:26 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCF913232C for ; Sun, 17 Sep 2017 19:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 IcBZyfD4g1Gn for ; Sun, 17 Sep 2017 19:05:16 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5567812EC30 for ; Sun, 17 Sep 2017 19:05:16 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id d70so6072638qkc.11 for ; Sun, 17 Sep 2017 19:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vPxj2YVDMLdfgEWtS/Ugo2b4QIPlD7eaTPr6/Myu7AE=; b=DSrBV5xdlGgOcb48sgvdwX6y+ff5PnOjU0mkzbbyZU8a+Fv3FbGJbbTk7MsztjQ/by /iQbLz9prSpGDSmSqimkvJZKAYBFjrzYbE4/XP/7ETJ7HsjwIA5rFJHGBZIdso55xO5G x480VK+Iaopv+nh5EzMQtPlyZ4QvwnhXu6IPX5+ka+HwSK85S+8GZo8puCTSw46UDXtL 4csHuX9xrtqCjnDT1xpye80RxBSByJa4NTWmPDK1sFR1ea9gjZSAlqF2sZrxXsTkBNzJ khak+TNd9p3hkMdgGVnjo70bZGfyv/0bBh74RKWiYsARh0GmWNjwAMYYarlPml/P0UTK B4sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vPxj2YVDMLdfgEWtS/Ugo2b4QIPlD7eaTPr6/Myu7AE=; b=rI4lmPx+Ie3apPbLrFpipeLhA2gZJ7Jmuo3pLTyLSv+PYqXOFqaNCDwq3nmSRDIEMF PVJkhI2hwV40giK4+m0PDV08Y9rmpVut1eEfkNPvYDcFXBhFJxnEG+5kzYu85ncFAO/4 G8E56j9YNrlIyVEkBbCVuYqNM/2pvGA+XYNr6xRK5OvlUSv6H2xGlvwXrrlpL/hhnli+ gax9B5HAluUfI+Ki2xjDmZ8o86N9QFI6H43LwJ8aod/70E8DR0Xoteo7Zs43+OP8k9Lg mzwCFMeUun1WWW9jxECm0SQaq2/ziO5ikAximqyv9PiIumMhPeGU1juCG+j+OrEbKc0q dowA== X-Gm-Message-State: AHPjjUgCQjtFTzX9ZJskH55OWgpOIywNeTg9jQk0kOkvnO9uwGHpdxyt ekObhb0D2zGZ/lo+QdhFSkshg/5vNQTJi5s3YBRdlA== X-Google-Smtp-Source: AOwi7QBrg354BKYKqe2yibMaQztH72stdPVnolk2Bdw4dhSzLqhVS/SqoYatVw3kmVX1QcnaoOfcq/4UODRKmG92KN8= X-Received: by 10.55.102.73 with SMTP id a70mr17188922qkc.345.1505700315280; Sun, 17 Sep 2017 19:05:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.61.196 with HTTP; Sun, 17 Sep 2017 19:05:14 -0700 (PDT) In-Reply-To: <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> From: Tom Herbert Date: Sun, 17 Sep 2017 19:05:14 -0700 Message-ID: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work To: Olivier.Bonaventure@uclouvain.be Cc: philip.eardley@bt.com, multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 02:05:19 -0000 On Sun, Sep 17, 2017 at 1:24 PM, Olivier Bonaventure wrote: > Tom, > > Thanks for your comments. > >> For #1 the assumption, the key assertion in the draft is "There are >> some situations where the transport stack used on clients (resp. >> servers) can be upgraded at a faster pace than the transport stack >> running on servers (resp. clients)."-- I think the reality of this is >> quite debatable. Major content provider providers that make up the >> bulk Internet traffic, such as Google and Facebook, upgrade their >> front end web server software at a much faster rate than clients >> typically do. > > > Major content providers are one part of the Internet, but not the entire > Internet. Many companies are still using old servers running Linux 2.x > >> There a good examples, TFO for instance, where there was >> support for new TCP features on servers long before clients. > > > Looking at TFO servers for example, a recent paper showed that TFO is > enabled on only 0.1% of the web sites > > https://irtf.org/anrw/2017/anrw17-final16.pdf > > and 80% of these sites are part of Google's AS. > >> The other >> part of this is that the solution assumes client support of MPTCP. >> AFAIK Android (which represents a huge number of clients) does not >> ship with an MPTCP implementation even though its been part of IOS >> since 2013. So, the real question that should be asked is why isn't >> MPTCP being deployed which leads to problem #2. > > > In Korea, Samsung and LG have deployed MPTCP on various types of Android > smartphones. > >> I suspect a major reason that MPTCP is not deployed in Android or >> servers is that fact that upstream Linux has not adopted the >> implementation. There was an effort a while back to get it into the >> stack, however there was pushback because of the invasiveness of the >> code (it was 1000's of lines of core TCP code change). Unfortunately, >> the developers didn't followup and continue working on reducing the >> complexity of implementation. I think with enough persistence in >> addressing the feedback the code would eventually make it in. > > > I agree, there is engineering effort to bring MPTCP in the mainline Linux > kernel, but this is outside the scope of IETF. > Oliver, I disagree, discussions about deployment and implementation are in scope. The primary argument for necessity that this draft makes is that MPTCP is being deployed too slowly. If we are to consider that argument then we need to understand _why_ deployment of MPTCP is slow, so the details about current deployment state and implementation are pertinent. Also, while there is significant engineering needed to get MPTCP into Linux or other systems, we cannot ignore the significant (possibly more) engineering effort to define, standardize, develop and deploy an interim solution on clients and converters. In the end, if the problem can be solved without creating a new complex and invasive protocol that is the better path forward. Tom >> Even so, >> acceptance into Linux is not a requirement for deployment. Google and >> Facebook could be running MPTCP on their servers, and Android could >> shipped with MPTCP support. I suspect the reason they're not doing >> that is motivation. If they were convinced that MPTCP is a great value >> to users, they can make deployment happen quickly. > > > Apple is using MPTCP on both their clients and their servers. Starting with > iOS11, all applications will be able to use MPTCP. This is a reasonable > deployment AFAIK. Korea is another example. >> >> >> For #3, the problems of the interim solution need to be elaborated. >> TCP is an end to end protocol, and we know that whenever a middlebox >> attempts to transparently process TCP some things will break. As >> section 5 states "The Converter protocol was designed to be used in >> networks that do not contain middleboxes that interfere with TCP." -- >> the irony of this statement is that the converter itself becomes a >> middlebox that interferes with TCP. The converter has many of the same >> issues of other middlebox solutions (proxies, firewalls) in the >> network that are invasive at the transport layer. > > > Agreed, but note that the converter was designed to enable the client to > detect when the server supports the required extension (e.g. MPTCP) so that > it can stop using the converter to reach this particular server. This means > that as a particular extension gets deployed, the utilisation of the > converter will diminish. > >> For instance E2E >> security (e.g. TCP-AO) is likely broken. > > > If a client requests TCP-AO, then it's clear that this TCP connection should > not go through a converter. > >> Also, I have to wonder about >> the case where the client and server support an option that is unknown >> to the converter-- say for instance that an experimental option is >> being used for a new feature such as we did with TFO. In this case I >> don't see how the converter can deal with the option, passing it >> through between MPTCP and non-MPTCP may or may not be correct. So >> probably the only reasonable behavior is to drop unknown options. > > > The client can detect which options are supported by the converter. If the > client wants to use an option that is not supported by a specific converter, > it should not use this particular converter. > >> But, >> then that means the endpoints would be bound to using only TCP options >> that the converter supports, so ultimately the converter is an >> obstacle not a facilitator for deploying new options. > > > No because the client can decide to not use the converter. > >> Perhaps the >> biggest irony of this proposal is that the converter is stateful for a >> connection, so all packets must flow through a single point in the >> network. Like stateful firewalls, this inevitably becomes a bottleneck >> and a single point of failure. > > > This is a drawback of using a converter, but one needs to compare this > drawback with the benefits of using the option on a part of the end-to-end > path. > >> I believe that is nearly the exact >> opposite of what MPTCP endeavors to provide. > > > It depends where the converter is located. If you consider a smartphone use > case, a converter placed in an ISP backbone could enable its users to > combine WiFi and 4G to reach any server with MPTCP. There is a real benefit > in doing this as shown by the deployments in Korea, Turkey or Thailand. > Hybrid access networks that combine xDSL and LTE are another example where > the client benefits from combining different networks with MPTCP. > >> A few comments about the text: >> >> In several places the term "TCP extensions" is used, I think "TCP >> options" is the more correct term. > > > Thanks, I will reread the document again to catch those. > >> In Section 2.1: >> >> The arguments that SOCKS can't be used are not entirely convincing to me. >> >> "the converter protocol leverages the TFO option [RFC7413] to place >> all its control information inside the SYN and SYN+ACK packets." >> >> I'm not sure what "control information" means here. Is this referring >> to TCP options, an inband control protocol, or something else? > > > This relates to the TLV messages of the converter protocol. >> >> >> It seems to me that support for SOCKS to use TFO should be >> straightforward, in fact the draft even states that has been proposed >> for SOCKS. >> >> "A second difference is that the converter protocol takes the TCP >> extensions explicitly into account." >> >> Per #3 above, the converter can only take into account TCP options >> that it understands and it can't deal with options like TCP-AO that >> must be truly end to end. Given these limitations, and the fact that a >> SOCKS should be running on an modern TCP stack that supports all the >> common options, I'm not sure how much tangible value there is in this >> difference. > > > The converter enables the client to detect which options are supported by > the final server so that the client can bypass the converter if the server > supports the required options. >> >> >> The third argument may have merit, but I would point out that this >> difference applies to all proxies and they are ubiquitous in >> deployment. Also, we are adding kProxy (in kernel proxy) for the Linux >> stack which actually would allow SYN forwarding in proxies without >> finishing client side connection establishment to give the same effect >> of the solution in the draft. > > > Excellent > > > Thanks > > > Olivier > From nobody Sun Sep 17 20:33:46 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FF3126B6E; Sun, 17 Sep 2017 20:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 OX5DSvsfJfwl; Sun, 17 Sep 2017 20:33:30 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B49132930; Sun, 17 Sep 2017 20:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5GQ/xH5qsoL6hZHc0R3cqRm1+oZFh+0eiI5EsNpHVzY=; b=Tol/octz7ybfC+27ui9q+rnnb UjohET9vfKhkCOf3ejPmsta1TLSa5zuSXUIQKoluRUhW9W8zv4EH8q/SgIHqH9XtoK4/4muTJnRnU yPnUxSrMsy6TI9yyUTcRSoTEYYzVuNjlxggiEUzQ5CqlftSYSq3eqieFlIGVoI2JEWJ0ZWrFZrdYT wFozGU2jN5gbJMGuj25HesukUiS5xQnkVlybTrPLAsMWGGx9+Uv6ATSqkge++h7HZhvomjJgHkLYn cOXLYdp12V9AYZjBQuSyrZI6nUOrWNfTyXhC6OnKKQGsn+pyA7SDVr7dPXHXZXaHkErCUTsVAZZT4 NQQznwnWw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58546 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dtmoK-000gNg-8L; Sun, 17 Sep 2017 23:33:28 -0400 Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work To: Tom Herbert , Olivier.Bonaventure@uclouvain.be Cc: multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> From: Joe Touch Message-ID: <32265da4-1694-7aff-6ffc-378bc6265d32@strayalpha.com> Date: Sun, 17 Sep 2017 20:33:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1E58ADB19747459EF73373DD" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 03:33:32 -0000 This is a multi-part message in MIME format. --------------1E58ADB19747459EF73373DD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 9/17/2017 7:05 PM, Tom Herbert wrote: >> I agree, there is engineering effort to bring MPTCP in the mainline Linux >> kernel, but this is outside the scope of IETF. >> > Oliver, > > I disagree, discussions about deployment and implementation are in > scope. The primary argument for necessity that this draft makes is > that MPTCP is being deployed too slowly. If we are to consider that > argument then we need to understand _why_ deployment of MPTCP is slow, > so the details about current deployment state and implementation are > pertinent. Also, while there is significant engineering needed to get > MPTCP into Linux or other systems, we cannot ignore the significant > (possibly more) engineering effort to define, standardize, develop and > deploy an interim solution on clients and converters. Additionally, this would leave in place a solution that complicates the design space for MPTCP for the future. That sort of cruft can be difficult to get rid of. > In the end, if > the problem can be solved without creating a new complex and invasive > protocol that is the better path forward. +1. There are no "urgent" problems in the IETF for which short-term solutions are needed, IMO. We need to take the long view of our actions. Joe > > Tom > --------------1E58ADB19747459EF73373DD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 9/17/2017 7:05 PM, Tom Herbert wrote:
I agree, there is engineering effort to bring MPTCP in the mainline Linux
kernel, but this is outside the scope of IETF.


Oliver,

I disagree, discussions about deployment and implementation are in
scope. The primary argument for necessity that this draft makes is
that MPTCP is being deployed too slowly. If we are to consider that
argument then we need to understand _why_ deployment of MPTCP is slow,
so the details about current deployment state and implementation are
pertinent. Also, while there is significant engineering needed to get
MPTCP into Linux or other systems, we cannot ignore the significant
(possibly more) engineering effort to define, standardize, develop and
deploy an interim solution on clients and converters.
Additionally, this would leave in place a solution that complicates the design space for MPTCP for the future. That sort of cruft can be difficult to get rid of.

In the end, if
the problem can be solved without creating a new complex and invasive
protocol that is the better path forward.
+1.

There are no "urgent" problems in the IETF for which short-term solutions are needed, IMO. We need to take the long view of our actions.

Joe


Tom

--------------1E58ADB19747459EF73373DD-- From nobody Mon Sep 18 02:18:43 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30631320CF; Mon, 18 Sep 2017 02:18:42 -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 DfAkQHZmXYUK; Mon, 18 Sep 2017 02:18:41 -0700 (PDT) Received: from smtp3.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 DD018126B6E; Mon, 18 Sep 2017 02:18:40 -0700 (PDT) Received: from mbpobo.local (unknown [130.104.228.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 7775667E0FC; Mon, 18 Sep 2017 11:18:29 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 7775667E0FC DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1505726309; bh=yw5mVO1ppzR4YueSr3BYCQuPNyQ2EUcUp6AZVbXQ/j8=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=q3vOCPe4DrIVQtyGPQarc9A3LbOyjsjZHDPNJpHHTpcD7PIhMKETkdQQzvUaDYLYT AQBidY+V2Jzav9aaFJc33ysuGE71ef0POFspuRpiNQOvr279RAS9WOGvO3xP+UvDXT Uo5aJePIi4cFDZJcMkf1C6FIFZ4jRolVYGkpZhxQ= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-3 Reply-To: Olivier.Bonaventure@uclouvain.be Subject: Re: [multipathtcp] Progressing the MPTCP proxy work To: Tom Herbert Cc: philip.eardley@bt.com, multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> From: Olivier Bonaventure Message-ID: <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> Date: Mon, 18 Sep 2017 11:18:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: 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: 7775667E0FC.A37AD X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 09:18:43 -0000 Tom, > > I disagree, discussions about deployment and implementation are in > scope. The primary argument for necessity that this draft makes is > that MPTCP is being deployed too slowly. The main argument of the draft is that deployment on client and servers does not go at the same pace. This is the motivation for having a converter. There *is* significant deployement of Multipath TCP today on clients and in some specific use cases. If we ignore the very large providers like Google or Facebook, deployment of new TCP features on servers takes more time. This does not depend only on the availability of a particular feature in the mainline Linux kernel but on many other factors. Server administrators are usually rather conservative and they favor stability and only deploy new features when they are strictly required. Looking at operating systems, they also tend to deploy stable releases that have been well tested and rarely deploy cutting edge features. Table 2 in https://irtf.org/anrw/2017/anrw17-final16.pdf shows that TFO has similar deployment issues than MPTCP. It has been enabled on client devices (Linux, iOS/Macos, soon Windows), but Brian Trammel and his colleagues could only find 578 servers (IP address) in Oct 2016 and 866 in Jan 2017 that negotiated TFO. Most of them where in a single AS. > If we are to consider that > argument then we need to understand _why_ deployment of MPTCP is slow, This is true for any TCP extension. Client and servers migrate at their own pace and it takes many years to deploy any TCP extension. MPTCP is not different from RFC1323, SACK or TFO > so the details about current deployment state and implementation are > pertinent. Also, while there is significant engineering needed to get > MPTCP into Linux or other systems, we cannot ignore the significant > (possibly more) engineering effort to define, standardize, develop and > deploy an interim solution on clients and converters. This cost will be on the devices that will benefit from the extension. The deployment of MPTCP in Korea to bond WiFi and LTE shows that there is a benefit for this type of service. > In the end, if > the problem can be solved without creating a new complex and invasive > protocol that is the better path forward. Olivier From nobody Mon Sep 18 09:22:29 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665C4132F2C for ; Mon, 18 Sep 2017 09:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 zAiFvbZkVpAJ for ; Mon, 18 Sep 2017 09:22:20 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE1A1320BD for ; Mon, 18 Sep 2017 09:22:20 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id 47so1084942qts.10 for ; Mon, 18 Sep 2017 09:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0TGIE0qTFQRODe/wtnq+Qa1EMxGUpK75eMe55i3W94s=; b=RDpxKlkxq95wplzbB22mHLumgbJQSirxwurPlsXCWrFzB9zBxaCrROG5LSstaFALza myV9v8HGqTxtgb/QSskKVed6ImYngaSht4nrAw6OTQk6ebD0yy7yZpfNEbhAaOYCkLKk x571FPcrGb1gidvi9OsnSkmLFcu7XJbNrgiPBz3m1bWyvyZAz5Qw+nL38aUBtfYn/wf8 Q5aW9eYIinrha01gUOOAaZyMhPi16Cf7mm5cFpMENoMpb5Bv+8/oBHR30fbs/XWoL3lM AmdRJXbg+hVBcxrZP8b2Ob2qV4N84UGiDDxYt8umzE/BPU4sS6c4j59xkDEyU7oPGBUe 8d/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0TGIE0qTFQRODe/wtnq+Qa1EMxGUpK75eMe55i3W94s=; b=b9VpPzu/mW4DyLn3Ej4ARKu0dyDV7rw3xbKYZ6mWD3OekaZDjtEjl3NTyXtZagZ6qH xs4NImtJ8xOmVrre4Qrdh8rllszPfndI+IKMJ72PS3ZHb4Mm3K5vimwKUDODMWCxphWq hfmGC+Az5qlR5TmH+u48sNRYbBVDDnhH7U4rCsYoQ6TKMnsoUKkzjPTaF9+/wOxBy6rV IEmZiIyYbo07HDt2y08m02MOqU5DQdQPMiHRFP30fJV7qdgVYUuv/txSLDOhlWRDuWr1 ImCb89lABwvC30UXTw0dwBikEQid0cIHuQpzSsHiE34tXWLrc5VY41DQBTBHEp9bBwjK uGuw== X-Gm-Message-State: AHPjjUhtNsxd1yIhDjyTvv8BODt3JUSLvd2jMGzAQuBWWabSsGMCv7Uk RWpBX3/R4KwiDdGC/l9JX3DmuDnh8IbnlkxSeS3AGQ== X-Google-Smtp-Source: AOwi7QDkXmvpCW+hRbXmJ6X23c57YEDXthQoa9u2qo3ZNcuRYAPLd5rJgMKRJZoLDeXn4IsPF4qx39wWjz+SFRNadYM= X-Received: by 10.237.59.221 with SMTP id s29mr52445750qte.27.1505751739198; Mon, 18 Sep 2017 09:22:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.61.196 with HTTP; Mon, 18 Sep 2017 09:22:18 -0700 (PDT) In-Reply-To: <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Tom Herbert Date: Mon, 18 Sep 2017 09:22:18 -0700 Message-ID: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work To: Olivier Bonaventure Cc: philip.eardley@bt.com, multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 16:22:23 -0000 On Mon, Sep 18, 2017 at 2:18 AM, Olivier Bonaventure wrote: > Tom, >> >> >> I disagree, discussions about deployment and implementation are in >> scope. The primary argument for necessity that this draft makes is >> that MPTCP is being deployed too slowly. > > > The main argument of the draft is that deployment on client and servers does > not go at the same pace. This is the motivation for having a converter. > There *is* significant deployement of Multipath TCP today on clients and in > some specific use cases. > > If we ignore the very large providers like Google or Facebook, deployment of Olivier, Why ignore the large content providers? If you want MPTCP to be a success, these (e.g. FANG) are exactly who you should be engaging. Once they're on board that covers a lot of user experience and others are likely to follow their lead. > new TCP features on servers takes more time. This does not depend only on > the availability of a particular feature in the mainline Linux kernel but on > many other factors. Server administrators are usually rather conservative > and they favor stability and only deploy new features when they are strictly > required. Looking at operating systems, they also tend to deploy stable > releases that have been well tested and rarely deploy cutting edge features. > Table 2 in > > https://irtf.org/anrw/2017/anrw17-final16.pdf > > shows that TFO has similar deployment issues than MPTCP. It has been enabled > on client devices (Linux, iOS/Macos, soon Windows), but Brian Trammel and > his colleagues could only find 578 servers (IP address) in Oct 2016 and 866 > in Jan 2017 that negotiated TFO. Most of them where in a single AS. > That says nothing about MPTCP. I think you're making broad generalizations about deployment based on a few select data points. Not all TCP features take a long time to get significant deployment (e.g., ICW=10, congestion avoidance improvements, retrans. improvements). And more than that, QUIC is entirely new transport protocol that has gotten significant deployment in a relatively short amount of time. The particulars of each protocol or feature need to be considered if a perceived deployment issue is to be addressed. TFO and MPTCP differ in some critical ways. TFO has good kernel support, but the server applications need to be fixed to support it. This dependency makes deployment longer. Also, TFO is a nice feature, but is only relevant at the beginning of a connection, and until zero-RTT TLS gets deployed it is of limited value. MPTCP does not currently have kernel support (i.e. not accepted by Linux), however shouldn't require server application layer changes-- the latter characteristic is an important simplification. This means if there were good kernel support then when the servers are updated (in cycles of 2-3 yrs. for a major content provider) they will get support and the value of MPTCP without additional work or action. Honestly, had the support gotten into Linux fours years ago when that was proposed we probably wouldn't be having this conversation! > >> If we are to consider that >> argument then we need to understand _why_ deployment of MPTCP is slow, > > > This is true for any TCP extension. Client and servers migrate at their own > pace and it takes many years to deploy any TCP extension. MPTCP is not > different from RFC1323, SACK or TFO > As I said above, the deployment and implementation characteristics of all of these is different and need to be considered for each feature. >> so the details about current deployment state and implementation are >> pertinent. Also, while there is significant engineering needed to get >> MPTCP into Linux or other systems, we cannot ignore the significant >> (possibly more) engineering effort to define, standardize, develop and >> deploy an interim solution on clients and converters. > > > This cost will be on the devices that will benefit from the extension. The > deployment of MPTCP in Korea to bond WiFi and LTE shows that there is a > benefit for this type of service. > Please elaborate on the cost of this solution. Specifically, please explain why the cost of doing this interim solution is less than the cost of figuring out how to get servers to support MPTCP. Also, the cost analysis should take into account any negative effects on nodes outside of the devices being touched-- this solution is not transparent to the outside world (similar to how NAT isn't really transparent to end hosts). Thanks, Tom From nobody Mon Sep 18 11:02:32 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC761342CB; Mon, 18 Sep 2017 11:02:11 -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 7dgaPLkXtnYi; Mon, 18 Sep 2017 11:02:04 -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 851BA133075; Mon, 18 Sep 2017 11:02:04 -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 87B7A67E075; Mon, 18 Sep 2017 20:01:55 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp4.sgsi.ucl.ac.be 87B7A67E075 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1505757715; bh=GGbl75DEWFNd29ZIHUWPS+uqi9ym9a65T6L/gjl9xm8=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=nMF35AmflWTK4lfjUSEJrrJurmJDuU+yiwoCPdTewS/z8PH6N27uynIU5jELoRvXl GKAAGE2dZ+jsrPgXUqXd5jBnKUzHkf5gZI0/C1Glb7ymR/w9UunLSpDzMP3NiHtQsd 3EMIkzLz1zwKSW/iNK7+vZoQR8HCYnDsJMZ7r1iw= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-4 Reply-To: Olivier.Bonaventure@uclouvain.be Subject: Re: [multipathtcp] Progressing the MPTCP proxy work To: Tom Herbert Cc: philip.eardley@bt.com, multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Olivier Bonaventure Message-ID: Date: Mon, 18 Sep 2017 20:01:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: 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: 87B7A67E075.A43D4 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 18:02:11 -0000 Tom, >>> >>> >>> I disagree, discussions about deployment and implementation are in >>> scope. The primary argument for necessity that this draft makes is >>> that MPTCP is being deployed too slowly. >> >> >> The main argument of the draft is that deployment on client and servers does >> not go at the same pace. This is the motivation for having a converter. >> There *is* significant deployement of Multipath TCP today on clients and in >> some specific use cases. >> >> If we ignore the very large providers like Google or Facebook, deployment of > > Olivier, > > Why ignore the large content providers? If you want MPTCP to be a > success, these (e.g. FANG) are exactly who you should be engaging. I don't ignore them. Apple uses MPTCP on iOS11 for all applications. > Once they're on board that covers a lot of user experience and others > are likely to follow their lead. With the availability of MPTCP on ios11 for any applications, we'll see a growth in usage of MPTCP on iphones. > >> new TCP features on servers takes more time. This does not depend only on >> the availability of a particular feature in the mainline Linux kernel but on >> many other factors. Server administrators are usually rather conservative >> and they favor stability and only deploy new features when they are strictly >> required. Looking at operating systems, they also tend to deploy stable >> releases that have been well tested and rarely deploy cutting edge features. >> Table 2 in >> >> https://irtf.org/anrw/2017/anrw17-final16.pdf >> >> shows that TFO has similar deployment issues than MPTCP. It has been enabled >> on client devices (Linux, iOS/Macos, soon Windows), but Brian Trammel and >> his colleagues could only find 578 servers (IP address) in Oct 2016 and 866 >> in Jan 2017 that negotiated TFO. Most of them where in a single AS. >> > That says nothing about MPTCP. I think you're making broad > generalizations about deployment based on a few select data points. I'm simply showing that the deployment of a recent TCP extension takes time. Another datapoint is https://link.springer.com/chapter/10.1007/978-3-642-20305-3_3 Figure 7 shows the evolution of the negotations of SACK, WSCALE and TIMESTAMP options over a decade of passive measurements. SACK, despite its clear benefits took almost ten years to be widely deployed In 2010, WSCALE and Timestamp were only supported by half of the observed TCP connections. > Not all TCP features take a long time to get significant deployment > (e.g., ICW=10, congestion avoidance improvements, retrans. > improvements). These are features that reside on a single host and do not require cooperation between client and server to be used. > And more than that, QUIC is entirely new transport > protocol that has gotten significant deployment in a relatively short > amount of time. The particulars of each protocol or feature need to be > considered if a perceived deployment issue is to be addressed. QUIC is a different beast. Coming back to TCP, extensions that provide benefits with a change on the sender or the receiver side only are easier to deploy because they provide immediate benefit on the stack that implements them. All the examples that you mention above are in this category. Congestion control algorithms are another example. Extensions that require a negotiation (SACK, WSCALE, TFO, MPTCP, ...) require support on both sender and receiver which takes much more time. I see that as a generic trend looking at the measurement papers that have studied this problem. I'd be interested in any measurement study that shows a new significant TCP option being quickly deployed on both clients and servers. > > TFO and MPTCP differ in some critical ways. TFO has good kernel > support, but the server applications need to be fixed to support it. > This dependency makes deployment longer. Also, TFO is a nice feature, > but is only relevant at the beginning of a connection, and until > zero-RTT TLS gets deployed it is of limited value. MPTCP does not > currently have kernel support The MPTCP patch released on http://www.multipath-tcp.org is well tested and stable. It is used in various deployments. > (i.e. not accepted by Linux), however > shouldn't require server application layer changes-- the latter > characteristic is an important simplification. This means if there > were good kernel support then when the servers are updated (in cycles > of 2-3 yrs. for a major content provider) they will get support and > the value of MPTCP without additional work or action. > Honestly, had > the support gotten into Linux fours years ago when that was proposed > we probably wouldn't be having this conversation! That's another story which mainly depends on the engineering ressources that the core MPTCP developpers could dedicate to refactoring the MPTCP patch to include it in the official Linux kernel. >> >>> If we are to consider that >>> argument then we need to understand _why_ deployment of MPTCP is slow, >> >> >> This is true for any TCP extension. Client and servers migrate at their own >> pace and it takes many years to deploy any TCP extension. MPTCP is not >> different from RFC1323, SACK or TFO >> > As I said above, the deployment and implementation characteristics of > all of these is different and need to be considered for each feature. A key concern is whether the extension must be negotiated during the three-way handshake. If yes, then deployment will be much more difficult than if there is no negotiation. >>> so the details about current deployment state and implementation are >>> pertinent. Also, while there is significant engineering needed to get >>> MPTCP into Linux or other systems, we cannot ignore the significant >>> (possibly more) engineering effort to define, standardize, develop and >>> deploy an interim solution on clients and converters. >> >> >> This cost will be on the devices that will benefit from the extension. The >> deployment of MPTCP in Korea to bond WiFi and LTE shows that there is a >> benefit for this type of service. >> > Please elaborate on the cost of this solution. Specifically, please > explain why the cost of doing this interim solution is less than the > cost of figuring out how to get servers to support MPTCP. There are different actors that have different incentives in the deployment of MPTCP. Let's consider the MPTCP deployment in Korea as an example. Their current solution is roughly to install a SOCKS client on MPTCP-enabled smartphones. Those smartphones interact with an MPTCP-enabled SOCKS server to reach remote servers. From the viewpoint of the enduser, there is a benefit in using MPTCP on her smartphone because she can combine LTE and WiFi to achieve higher bandwidth or have seamless handovers. From the viewpoint of the network operator, this is an added value service that they provide to their customers. If all Internet servers supported MPTCP, they would not have had to deploy and support the SOCKS servers in their network. > Also, the > cost analysis should take into account any negative effects on nodes > outside of the devices being touched-- this solution is not > transparent to the outside world (similar to how NAT isn't really > transparent to end hosts). The negative effect is that the smartphone needs to include MPTCP and the SOCKS client. The SOCKS server is a single-point of failure inside the ISP network. It is not totally transparent since the smartphone needs to be configured with a SOCKS server, but there are clear benefits since this kind of solution is deployed by several ISPs in several countries. Olivier From nobody Mon Sep 18 11:51:42 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B55133209 for ; Mon, 18 Sep 2017 11:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 h0p4QzTXSnJ9 for ; Mon, 18 Sep 2017 11:51:32 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52318132D4B for ; Mon, 18 Sep 2017 11:51:32 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id u67so1481952qkg.6 for ; Mon, 18 Sep 2017 11:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rr304Dvz7Q5pHyyiSzK0pmDBS8k5xWkiq8QXUqIXyvc=; b=PI5bLb5dIQ8Aux5Eh//L8UQC9Q9xT8bjJ8IozsDM5sRXfSItdUDt7y38qL0mn0h5iI SjjHz72O5rTJwqJ36M5C/ly6EId2/y2mTwBDssg7x7mnehadv6YhvKJVZxhPJL8MXuNu 343rELnbKznkSgvrxRV2iraJwsEFjUDb5s5QlkkpjLGFH+RmLJDJe/cmmp++sja0iBt9 cImolyrWplzIl9wwdJ7xTjpItf58ANCPhXVCfiAtNigeTXDwufuaJMTg7AatmH+zPaXl BGz6J/XPQ688LXYw+z4DuYSMMgUT8yNm4cWCIgIXKxklyE4xPqdkrgGqInd96L/NWH+S 8LHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rr304Dvz7Q5pHyyiSzK0pmDBS8k5xWkiq8QXUqIXyvc=; b=HK/M9UcVU9L4zSKvp7r/18MjKMSynocsiZPocEnlhOtopyhukFr3ODuM9SUbzxeW6A pQ88JscuOLqIxBTN8b7waYQJHxyr4Nrjdt/5Sv0gGb2G7hbYwKqSU1D1ZOXovsSN11aa HNX5kOnC+DCuNoZAm16ardc5ygNc9DNmwdKvrHQKuvWv2JmaX2A9+FRDdaLYOIo1g4xM x6aq8ewVeoj8BK7cbJYiNXk64MoQu2ZooYmecaffc4zw1f7YC7y3cIr7HNPVAxQa2V35 CizNVIxstUNSUqHSaIBOrxHb7+7DTh9ZQaGX9KRILG/FoeIk9y8KWXSnZymVQ7EOMat0 Xhww== X-Gm-Message-State: AHPjjUjqLwTNFYJ/Ud1lHq5caZwdbf95R9dwSfvofY3zWHivf5P+ydjt /HLPJUdFNjU51S9idDSTvPRM3ZmCgiH5xUY3YhWuPA== X-Google-Smtp-Source: AOwi7QDIdekd5bKh7gIqzWfRAdJQcCtuZJpjPdQj0eeWi7ksLqPKinozWHzUH8e3XpYoU2h994TDdZJ4hNueJXTIBxU= X-Received: by 10.55.167.135 with SMTP id q129mr21203453qke.311.1505760691306; Mon, 18 Sep 2017 11:51:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.61.196 with HTTP; Mon, 18 Sep 2017 11:51:30 -0700 (PDT) In-Reply-To: References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Tom Herbert Date: Mon, 18 Sep 2017 11:51:30 -0700 Message-ID: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work To: Olivier Bonaventure Cc: philip.eardley@bt.com, multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 18:51:34 -0000 > From the viewpoint of the enduser, there is a benefit in using MPTCP on her > smartphone because she can combine LTE and WiFi to achieve higher bandwidth > or have seamless handovers. From the viewpoint of the network operator, this > is an added value service that they provide to their customers. If all > Internet servers supported MPTCP, they would not have had to deploy and > support the SOCKS servers in their network. > Olivier, The benefits of using MPTCP are understood. The question is cost of this solution. As you mention above MPTCP requires client and server cooperation, but this solution requires cooperation between clients and middleboxes, and middlebox and server. The number of cooperating parties is not be reduced, and effectively turns TCP connection negotiation into a three-way negotiation. The server/middlebox interaction may be mostly transparent, but not the former. The clients and middlebox support requires new protocol which means new software needs to be deployed on clients and middleboxes. This takes time and engineering effort. And there are a lot more network carriers than there are significant content providers or client vendor, so that is more parties to deal with in deployment. Given this, please provide the details on why this path is going to be faster than working directly with the content providers to start support MPTCP. WIth the right motivation and effort, I believe that most major content providers could have good support for MPTCP within 3 years. What is your time and effort estimate for deploying this solution across all clients and bringing up the converter in a significant number of networks? Tom >> Also, the >> cost analysis should take into account any negative effects on nodes >> outside of the devices being touched-- this solution is not >> transparent to the outside world (similar to how NAT isn't really >> transparent to end hosts). > > > The negative effect is that the smartphone needs to include MPTCP and the > SOCKS client. The SOCKS server is a single-point of failure inside the ISP > network. It is not totally transparent since the smartphone needs to be > configured with a SOCKS server, but there are clear benefits since this kind > of solution is deployed by several ISPs in several countries. > > > Olivier From nobody Mon Sep 18 13:06:22 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A951321CB; Mon, 18 Sep 2017 13:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no 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 EN1JcLdG0Ie2; Mon, 18 Sep 2017 13:06:05 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C261E12421A; Mon, 18 Sep 2017 13:06:04 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.161.174]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5850827844A; Tue, 19 Sep 2017 05:06:02 +0900 (JST) Received: by mail-yw0-f174.google.com with SMTP id o143so1136889ywd.12; Mon, 18 Sep 2017 13:06:02 -0700 (PDT) X-Gm-Message-State: AHPjjUioPF5FC4sJTfVki2lgVq4GIcUvqky/t86zIvQGqv7zAKMOEomz uni9zXGAG3PW6ASamGv8QaEk1PD9sV6NWa4bm5U= X-Google-Smtp-Source: AOwi7QBLWLHKU4vC5PT0AMI7eeNTqOGVYecIjhHwPyNdEKm91ZJpdyASM3QXPmN6cfToyUi3VRsIiHJgOEaKSV10/2M= X-Received: by 10.37.220.72 with SMTP id y69mr27722662ybe.314.1505765160775; Mon, 18 Sep 2017 13:06:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.64.145 with HTTP; Mon, 18 Sep 2017 13:06:00 -0700 (PDT) In-Reply-To: References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Yoshifumi Nishida Date: Mon, 18 Sep 2017 13:06:00 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work To: Tom Herbert Cc: Olivier Bonaventure , multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org Content-Type: multipart/alternative; boundary="94eb2c18f38486119605597c453a" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 20:06:06 -0000 --94eb2c18f38486119605597c453a Content-Type: text/plain; charset="UTF-8" Hi Tom, Only a few companies can control both client and server sides. However, ISPs might be able to control the STB at the client side and the middleboxes in their networks. This may be a relatively easy way to deploy MPTCP technology rather than updating clients or servers. -- Yoshi On Mon, Sep 18, 2017 at 11:51 AM, Tom Herbert wrote: > > Olivier, > > The benefits of using MPTCP are understood. The question is cost of > this solution. As you mention above MPTCP requires client and server > cooperation, but this solution requires cooperation between clients > and middleboxes, and middlebox and server. The number of cooperating > parties is not be reduced, and effectively turns TCP connection > negotiation into a three-way negotiation. The server/middlebox > interaction may be mostly transparent, but not the former. The clients > and middlebox support requires new protocol which means new software > needs to be deployed on clients and middleboxes. This takes time and > engineering effort. And there are a lot more network carriers than > there are significant content providers or client vendor, so that is > more parties to deal with in deployment. Given this, please provide > the details on why this path is going to be faster than working > directly with the content providers to start support MPTCP. WIth the > right motivation and effort, I believe that most major content > providers could have good support for MPTCP within 3 years. What is > your time and effort estimate for deploying this solution across all > clients and bringing up the converter in a significant number of > networks? > > Tom > > >> Also, the > >> cost analysis should take into account any negative effects on nodes > >> outside of the devices being touched-- this solution is not > >> transparent to the outside world (similar to how NAT isn't really > >> transparent to end hosts). > > > > > > The negative effect is that the smartphone needs to include MPTCP and the > > SOCKS client. The SOCKS server is a single-point of failure inside the > ISP > > network. It is not totally transparent since the smartphone needs to be > > configured with a SOCKS server, but there are clear benefits since this > kind > > of solution is deployed by several ISPs in several countries. > > > > > > Olivier > > --94eb2c18f38486119605597c453a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

Only a few companies can contro= l both client and server sides.
However, ISPs might be able to co= ntrol the STB at the client side and the middleboxes in their networks.=C2= =A0
This may be a relatively easy way to deploy MPTCP technology = rather than updating clients or servers.
--
Yoshi
=

On Mon, Sep = 18, 2017 at 11:51 AM, Tom Herbert <tom@herbertland.com> wr= ote:

Olivier,

The benefits of using MPTCP are understood. The question is cost of
this solution. As you mention above MPTCP requires client and server
cooperation, but this solution requires cooperation between clients
and middleboxes, and middlebox and server. The number of cooperating
parties is not be reduced, and effectively turns TCP connection
negotiation into a three-way negotiation. The server/middlebox
interaction may be mostly transparent, but not the former. The clients
and middlebox support requires new protocol which means new software
needs to be deployed on clients and middleboxes. This takes time and
engineering effort. And there are a lot more network carriers than
there are significant content providers or client vendor, so that is
more parties to deal with in deployment. Given this, please provide
the details on why this path is going to be faster than working
directly with the content providers to start support MPTCP. WIth the
right motivation and effort, I believe that most major content
providers could have good support for MPTCP within 3 years. What is
your time and effort estimate for deploying this solution across all
clients and bringing up the converter in a significant number of
networks?

Tom

>> Also, the
>> cost analysis should take into account any negative effects on nod= es
>> outside of the devices being touched-- this solution is not
>> transparent to the outside world (similar to how NAT isn't rea= lly
>> transparent to end hosts).
>
>
> The negative effect is that the smartphone needs to include MPTCP and = the
> SOCKS client. The SOCKS server is a single-point of failure inside the= ISP
> network. It is not totally transparent since the smartphone needs to b= e
> configured with a SOCKS server, but there are clear benefits since thi= s kind
> of solution is deployed by several ISPs in several countries.
>
>
> Olivier


--94eb2c18f38486119605597c453a-- From nobody Mon Sep 18 13:43:58 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983CE132076 for ; Mon, 18 Sep 2017 13:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 3Kaki7ZeZrLa for ; Mon, 18 Sep 2017 13:43:49 -0700 (PDT) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5002F13301E for ; Mon, 18 Sep 2017 13:43:48 -0700 (PDT) Received: by mail-qt0-x244.google.com with SMTP id q8so1130868qtb.1 for ; Mon, 18 Sep 2017 13:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O+xtoIr8UErp23dMMasJlNhIVvbP6u/XpmUVNKFOCgs=; b=b/epWhFI0neWMaC62yQ8rc4DmkeqUjAh/vvDse3K4L410g4E1NeMR12I7p3TJKiA+c ttpsUTPSLtcM4TdUIWWUmZ9Rkq+Tj3nDFe6NyQWAwa9IELkPjtlyNyMxvGQ/rP3f+M4H Wh0hjUosjnW2O0Sgl2RIR6SkuebYNAW3a+lC+HKHK6Wq0ZZWXX/TUfLsKJnE8fUPitzJ uyswRUSqRugkmHupD0UKFstoBAtf3Ma/m1kWDrrmRPfs7MOPGG8wVQNESuznT2aahjo5 f1LH393h3PRLgJOfj0y7yQcm4eZfwleu4rWwTRngzdmvcBFuFko7vkj8wt7wfMLNY0J6 RcSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=O+xtoIr8UErp23dMMasJlNhIVvbP6u/XpmUVNKFOCgs=; b=cp4aA3/UEMmMQeaQ9Tno9mPFw/FZ1LfJU35IOf6taqJBZ7z7v3YwRuUF9J9w6C/2Rh cT5VPIqWOC8+HuV1V4DWD1y0I+khDMZHuCcF388UIlxnJqL83OccXqTAqUH706LA0p/1 B9v0YX1GrTGelFaIQQL7Zjt6Al+I9nOH7VYIPCOjarYBn03MZwer2g0DK51jlcFrmsxM Si3V2PWp69dA71WgxF7CmxrN26Y8qrgD/DtP7thpJ141FRDIigcYDITXcVG3e/JIPXXh Tttq3w9/oJZ1VBW/HXQfvnKWP2ajESNA8HTMVrFne/mKmnSMZMuqsIDY+mquN5OhKGlU GdMw== X-Gm-Message-State: AHPjjUgFugxTz5l/+izbY+cqvLQgfqi5+uZNO2+OotgZXjZbAzNxwKZ+ xQ4syMoYCkhyHDkH8nVPtIEVovgMC4jSD7QZ603zVA== X-Google-Smtp-Source: AOwi7QC4mJTZ0AMMtn3WbCAPTxzONR5UwKVnlp25Pk76HROmMJgyer/lEkRFizRziCF/38Ld2iSLq4kKHx69I5FyKjs= X-Received: by 10.200.35.247 with SMTP id r52mr38657201qtr.275.1505767427387; Mon, 18 Sep 2017 13:43:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.61.196 with HTTP; Mon, 18 Sep 2017 13:43:46 -0700 (PDT) In-Reply-To: References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Tom Herbert Date: Mon, 18 Sep 2017 13:43:46 -0700 Message-ID: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work To: Yoshifumi Nishida Cc: Olivier Bonaventure , multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 20:43:51 -0000 On Mon, Sep 18, 2017 at 1:06 PM, Yoshifumi Nishida wrote: > Hi Tom, > > Only a few companies can control both client and server sides. > However, ISPs might be able to control the STB at the client side and the > middleboxes in their networks. > This may be a relatively easy way to deploy MPTCP technology rather than > updating clients or servers. Yoshi, I think you're focusing too much on the benefits of this solution and not considering the cost. We've seen time and time again that when middleboxes get involved in transport layer operations they break the end to end nature of TCP and that leads to problems. Middlebox involvement in TCP is one of the major source of protocol ossification on the Internet. MPTCP is just one feature of TCP that we might want do deploy there are many others. If this solution hampers use and deployment of those, then I don't believe this is a reasonable tradeoff regardless of what the benefits are. Tom From nobody Mon Sep 18 17:17:04 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539B51252BA; Mon, 18 Sep 2017 17:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 20K3VFBlTyGC; Mon, 18 Sep 2017 17:16:45 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19957133229; Mon, 18 Sep 2017 17:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z9dqR+7M8+EcpFoQlwWAaGL/Bl8Bc2XQYLNbsYKiGFM=; b=6JndIJl5iQe7hWGi3oL06mgo8 F2vB0Yus3M/LchTaQtvdD7W9il6slFuLREnAA5QVpuIFuMyns8ctZyNWSk2RHw505XCeGeOk9A6J+ FntForprWA7DFNqmPEzvjP/9ccZeWeRr/GZw8SG1MqVumcecEYnYa0guTFUL0ag6FMvuhQSyhdoxW 6gKwm/xiO9ylRyFAmKF4g8crPwIQEl1y3UpCC3oSPm/Z9Wi/ZYFtGLqQCogQ/qrzhzFteSr5AtQ1g DtbL6PSiYSvMEiLj3nTBp2neYalnAA4D5lYTeCrgmClbdxlAA+VunfnzDBqDKeODjIB2Ae3nfWRtR 42bUp5VOw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:49825 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1du6DR-001Gv2-T6; Mon, 18 Sep 2017 20:16:42 -0400 Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work To: Yoshifumi Nishida , Tom Herbert Cc: multipathtcp , tsv-area@ietf.org, "tcpm@ietf.org" , Olivier Bonaventure References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Joe Touch Message-ID: <178edb8e-ab55-1019-48dc-e766ccb7ba07@strayalpha.com> Date: Mon, 18 Sep 2017 17:16:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BF17A9A92FBEE835345EF522" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 00:16:47 -0000 This is a multi-part message in MIME format. --------------BF17A9A92FBEE835345EF522 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit If you have a TCP solution that endpoints don't want but ISPs do, you do not have a good solution. Again, this seems like an interim fix that only complicates the landscape for everyone - it impedes deployment of security and could complicate every other option. Every attempt to address these issues seems like significant rationalization. Joe On 9/18/2017 1:06 PM, Yoshifumi Nishida wrote: > Hi Tom, > > Only a few companies can control both client and server sides. > However, ISPs might be able to control the STB at the client side and > the middleboxes in their networks.  > This may be a relatively easy way to deploy MPTCP technology rather > than updating clients or servers. > -- > Yoshi > > On Mon, Sep 18, 2017 at 11:51 AM, Tom Herbert > wrote: > > > Olivier, > > The benefits of using MPTCP are understood. The question is cost of > this solution. As you mention above MPTCP requires client and server > cooperation, but this solution requires cooperation between clients > and middleboxes, and middlebox and server. The number of cooperating > parties is not be reduced, and effectively turns TCP connection > negotiation into a three-way negotiation. The server/middlebox > interaction may be mostly transparent, but not the former. The clients > and middlebox support requires new protocol which means new software > needs to be deployed on clients and middleboxes. This takes time and > engineering effort. And there are a lot more network carriers than > there are significant content providers or client vendor, so that is > more parties to deal with in deployment. Given this, please provide > the details on why this path is going to be faster than working > directly with the content providers to start support MPTCP. WIth the > right motivation and effort, I believe that most major content > providers could have good support for MPTCP within 3 years. What is > your time and effort estimate for deploying this solution across all > clients and bringing up the converter in a significant number of > networks? > > Tom > > >> Also, the > >> cost analysis should take into account any negative effects on > nodes > >> outside of the devices being touched-- this solution is not > >> transparent to the outside world (similar to how NAT isn't really > >> transparent to end hosts). > > > > > > The negative effect is that the smartphone needs to include > MPTCP and the > > SOCKS client. The SOCKS server is a single-point of failure > inside the ISP > > network. It is not totally transparent since the smartphone > needs to be > > configured with a SOCKS server, but there are clear benefits > since this kind > > of solution is deployed by several ISPs in several countries. > > > > > > Olivier > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------BF17A9A92FBEE835345EF522 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

If you have a TCP solution that endpoints don't want but ISPs do, you do not have a good solution.

Again, this seems like an interim fix that only complicates the landscape for everyone - it impedes deployment of security and could complicate every other option.

Every attempt to address these issues seems like significant rationalization.

Joe


On 9/18/2017 1:06 PM, Yoshifumi Nishida wrote:
Hi Tom,

Only a few companies can control both client and server sides.
However, ISPs might be able to control the STB at the client side and the middleboxes in their networks. 
This may be a relatively easy way to deploy MPTCP technology rather than updating clients or servers.
--
Yoshi

On Mon, Sep 18, 2017 at 11:51 AM, Tom Herbert <tom@herbertland.com> wrote:

Olivier,

The benefits of using MPTCP are understood. The question is cost of
this solution. As you mention above MPTCP requires client and server
cooperation, but this solution requires cooperation between clients
and middleboxes, and middlebox and server. The number of cooperating
parties is not be reduced, and effectively turns TCP connection
negotiation into a three-way negotiation. The server/middlebox
interaction may be mostly transparent, but not the former. The clients
and middlebox support requires new protocol which means new software
needs to be deployed on clients and middleboxes. This takes time and
engineering effort. And there are a lot more network carriers than
there are significant content providers or client vendor, so that is
more parties to deal with in deployment. Given this, please provide
the details on why this path is going to be faster than working
directly with the content providers to start support MPTCP. WIth the
right motivation and effort, I believe that most major content
providers could have good support for MPTCP within 3 years. What is
your time and effort estimate for deploying this solution across all
clients and bringing up the converter in a significant number of
networks?

Tom

>> Also, the
>> cost analysis should take into account any negative effects on nodes
>> outside of the devices being touched-- this solution is not
>> transparent to the outside world (similar to how NAT isn't really
>> transparent to end hosts).
>
>
> The negative effect is that the smartphone needs to include MPTCP and the
> SOCKS client. The SOCKS server is a single-point of failure inside the ISP
> network. It is not totally transparent since the smartphone needs to be
> configured with a SOCKS server, but there are clear benefits since this kind
> of solution is deployed by several ISPs in several countries.
>
>
> Olivier




_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--------------BF17A9A92FBEE835345EF522-- From nobody Mon Sep 18 18:39:26 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A6013243A; Mon, 18 Sep 2017 18:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 EsTsPtlEV703; Mon, 18 Sep 2017 18:39:10 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDCE4132331; Mon, 18 Sep 2017 18:39:09 -0700 (PDT) Received: from mail-yw0-f177.google.com (mail-yw0-f177.google.com [209.85.161.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 87B292786F1; Tue, 19 Sep 2017 10:39:08 +0900 (JST) Received: by mail-yw0-f177.google.com with SMTP id w22so1556013ywa.13; Mon, 18 Sep 2017 18:39:08 -0700 (PDT) X-Gm-Message-State: AHPjjUh3nroVbMpev7PG0IzH4OMir3JFMOK6fLG3xcpnXxiXwaF8Dy9+ W+e44/+dnz1r3V3HFVNIqL8x0z1y17QsgbV92ho= X-Google-Smtp-Source: AOwi7QDW0LysonelXgV82mHNqF68Kr6WukPu5wF6w3KvtV8AxnbZnYJk2CPJvay0OHS+WlrD91CuUZYdS/tFbIODfNA= X-Received: by 10.129.87.12 with SMTP id l12mr1497157ywb.487.1505785146965; Mon, 18 Sep 2017 18:39:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.64.145 with HTTP; Mon, 18 Sep 2017 18:39:06 -0700 (PDT) In-Reply-To: References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Yoshifumi Nishida Date: Mon, 18 Sep 2017 18:39:06 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work To: Tom Herbert Cc: Yoshifumi Nishida , Olivier Bonaventure , multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org Content-Type: multipart/alternative; boundary="001a113ab0f2cb0592055980ecff" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 01:39:11 -0000 --001a113ab0f2cb0592055980ecff Content-Type: text/plain; charset="UTF-8" Hi Tom, On Mon, Sep 18, 2017 at 1:43 PM, Tom Herbert wrote: > On Mon, Sep 18, 2017 at 1:06 PM, Yoshifumi Nishida > wrote: > > Hi Tom, > > > > Only a few companies can control both client and server sides. > > However, ISPs might be able to control the STB at the client side and the > > middleboxes in their networks. > > This may be a relatively easy way to deploy MPTCP technology rather than > > updating clients or servers. > > Yoshi, > > I think you're focusing too much on the benefits of this solution and > not considering the cost. We've seen time and time again that when > middleboxes get involved in transport layer operations they break the > end to end nature of TCP and that leads to problems. Middlebox > involvement in TCP is one of the major source of protocol ossification > on the Internet. MPTCP is just one feature of TCP that we might want > do deploy there are many others. If this solution hampers use and > deployment of those, then I don't believe this is a reasonable > tradeoff regardless of what the benefits are. You might be right that I focus on the benefits too much. But, I personally don't think all middleboxes are bad. I think these ossifications are mainly caused by poorly designed middleboxes. If we can do things correctly, I think a middlebox might be able to intervene only when it can be beneficial otherwise stays away to not harm anything. I guess you don't want to throw away all load balancers, IDSs, firewalls from the Internet because they ossify protocols in some cases. -- Yoshi --001a113ab0f2cb0592055980ecff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

On Mon, Sep 18, 2017 at 1:43 PM, Tom Herbert &= lt;tom@herbertland= .com> wrote:
On Mon, = Sep 18, 2017 at 1:06 PM, Yoshifumi Nishida
<nishida@sfc= .wide.ad.jp> wrote:
> Hi Tom,
>
> Only a few companies can control both client and server sides.
> However, ISPs might be able to control the STB at the client side and = the
> middleboxes in their networks.
> This may be a relatively easy way to deploy MPTCP technology rather th= an
> updating clients or servers.

Yoshi,

I think you're focusing too much on the benefits of this solution and not considering the cost. We've seen time and time again that when
middleboxes get involved in transport layer operations they break the
end to end nature of TCP and that leads to problems. Middlebox
involvement in TCP is one of the major source of protocol ossification
on the Internet. MPTCP is just one feature of TCP that we might want
do deploy there are many others. If this solution hampers use and
deployment of those, then I don't believe this is a reasonable
tradeoff regardless of what the benefits are.

You might be right that I focus on the benefits too much.
But,= I personally don't think all middleboxes are bad. I think these ossifi= cations are mainly caused by poorly designed middleboxes.=C2=A0
I= f we can do things correctly, I think a middlebox might be able to interven= e only when it can be beneficial otherwise stays away to not harm anything.=
I guess you don't want to throw away all load balancers, IDS= s, firewalls from the Internet because they ossify protocols in some cases.=
--
Yoshi
=C2=A0

--001a113ab0f2cb0592055980ecff-- From nobody Tue Sep 19 09:16:55 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11680134289; Tue, 19 Sep 2017 09:16:44 -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 8TJSGYLJNQ3f; Tue, 19 Sep 2017 09:16:40 -0700 (PDT) Received: from smtp2.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 08AD7134281; Tue, 19 Sep 2017 09:16:40 -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@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 3518467E2A7; Tue, 19 Sep 2017 18:16:31 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be 3518467E2A7 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1505837791; bh=T7Onx5CQzhXFvqSJPNmjFQUbRPzJbMj2cFbUJzcjNpQ=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=Zn6WuM4Rk8MexOamA1qTNvtzQ2VS8MxYIpjKDACco40D1Gtf6KTSRrz+p78O1jlvA u3DKEjkM6HcHGaiDvyMh1h76tmXVSzBqbuL57qlCKPt0Jf2RsaXdCNJLqbz7ycpJss E4duI5gGG1DmnTxWVQqxC6P92O5QCr3O+8njulLI= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-2 Reply-To: Olivier.Bonaventure@uclouvain.be Subject: Re: [multipathtcp] Progressing the MPTCP proxy work To: Tom Herbert , Yoshifumi Nishida Cc: multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Olivier Bonaventure Message-ID: <49969822-1024-3811-9f87-f95f9d58837a@uclouvain.be> Date: Tue, 19 Sep 2017 18:16:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: 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: 3518467E2A7.A198F X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 16:16:44 -0000 Tom, >> >> Only a few companies can control both client and server sides. >> However, ISPs might be able to control the STB at the client side and the >> middleboxes in their networks. >> This may be a relatively easy way to deploy MPTCP technology rather than >> updating clients or servers. > > Yoshi, > > I think you're focusing too much on the benefits of this solution and > not considering the cost. We've seen time and time again that when > middleboxes get involved in transport layer operations they break the > end to end nature of TCP and that leads to problems. Middlebox > involvement in TCP is one of the major source of protocol ossification > on the Internet. We've spent a long time fighting with middleboxes during the design and implementation of MPTCP and I know the problems that they cause. Most of the problems we have with middleboxes today come from the fact that they are not explicit in the architecture. A client cannot explicitly request the creation of a TCP connection through a specific middlebox that would provide service to this client. All middleboxes are implictly deployed in the network and they process/interfere with traffic without the consent of the client. On servers, some middleboxes (e.g. load balancers) are part of the infrastructure and the server are informed about their presence. The proposed converters change this approach by making the conversion an explicit (opt-in) service that can be requested by the client. If the client does not request the conversion service, then there is no interference from the middlebox. This is a different approach which could in the long term provide new benefits that go beyond the simple conversion service. > MPTCP is just one feature of TCP that we might want > do deploy there are many others. If this solution hampers use and > deployment of those, then I don't believe this is a reasonable > tradeoff regardless of what the benefits are. Since the conversion service is explicitly requested by the clients, they can opt-out this service when it is not required anymore (e.g. MPTCP is supported on servers) or when they wish to use a feature that is not supported by the converter. Olivier From nobody Tue Sep 19 10:32:41 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4B8133342 for ; Tue, 19 Sep 2017 10:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 OzMhDLFxdRbF for ; Tue, 19 Sep 2017 10:32:26 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FDB1342A7 for ; Tue, 19 Sep 2017 10:32:24 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id u67so344505qkg.6 for ; Tue, 19 Sep 2017 10:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sfDJbj5n3pe5LQml50sxIFFCb0xGOzKUYojzsgDvp4E=; b=MMhDxFhNXeGur3a1zBEMtz1UsBKUZLD5jEH1QOgHkSHNBOmiwcJIvSXl+pipF7FEVc eb2AOdNYMeUY5hlznPPcegLrhezSVM1EFHzseQnLZwPrd7RC0AMlmen2333SiHrMWdKk gHDo+h9NXYb66dt9fBd2iMAq6DH2wq1wb3xNHDtlakhCZ2Oj3E7mX5nkAmXcH3FA0LZ3 WMB6pj3VljItmuhH99hYjh86hFoTK6rbW8aGCVI6KL3PkcsKm8WztAsI2l1t/AESu6Et 3j3oJmK312k34Kayni+rQhW/WhGsCDAGvN1MrNrHkX7sv1/zaMupR+ph8Sd7ThTpxeGQ 3GEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sfDJbj5n3pe5LQml50sxIFFCb0xGOzKUYojzsgDvp4E=; b=dENfHk3SzzO6VvMxTA/eKk5pNj36Rs6h3IA2IYgue6zEXFdsukJq4H3LsUO7QkJ/fO ZcbaKehXfv3mRehzb57KyLWJuXFMYNR2vAvJqzcXIvkgdxjxh461YzI3uJyBrTO6D/Gy gVFHmPCzSq3i7oG0xNpKNO2Bx+NlkeC0bAArj8yG27t5dO5Jf6qkEqc4iN0RbFtlz7QB bGn7v1w7eQYeaJGdAfrlnK5TPStn/4Y8RXejwMmU+c7Jtowq/r97BaNL9WbEuu/465g6 9iQ/d8CplGxuFQ1/LZ6JSPTlXuCoRU9FwJSuId40FzfdszQcOsPLmhURzyF1tyi4gelE 3mYw== X-Gm-Message-State: AHPjjUheaFK7+egn/UjRn1XfNrOqg4pc1Fm7Oe/BaPIpwFvEpIvtZJSR psZM2AiTRFZRu3yoX7hmlmK31u9o72i6ZI4CTyyiNg== X-Google-Smtp-Source: AOwi7QCGuKye21WCVf2kZcPoZa7oJ5vr25IrZ1kJ2uGL2q/tOgHnnDvVLFF8mKlJ9bkIq57uqiUG6T40a/y/6VST20Q= X-Received: by 10.55.109.131 with SMTP id i125mr2959705qkc.17.1505842343938; Tue, 19 Sep 2017 10:32:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.61.196 with HTTP; Tue, 19 Sep 2017 10:32:23 -0700 (PDT) In-Reply-To: References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Tom Herbert Date: Tue, 19 Sep 2017 10:32:23 -0700 Message-ID: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work To: Yoshifumi Nishida Cc: Olivier Bonaventure , multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 17:32:27 -0000 On Mon, Sep 18, 2017 at 6:39 PM, Yoshifumi Nishida wrote: > Hi Tom, > > On Mon, Sep 18, 2017 at 1:43 PM, Tom Herbert wrote: >> >> On Mon, Sep 18, 2017 at 1:06 PM, Yoshifumi Nishida >> wrote: >> > Hi Tom, >> > >> > Only a few companies can control both client and server sides. >> > However, ISPs might be able to control the STB at the client side and >> > the >> > middleboxes in their networks. >> > This may be a relatively easy way to deploy MPTCP technology rather than >> > updating clients or servers. >> >> Yoshi, >> >> I think you're focusing too much on the benefits of this solution and >> not considering the cost. We've seen time and time again that when >> middleboxes get involved in transport layer operations they break the >> end to end nature of TCP and that leads to problems. Middlebox >> involvement in TCP is one of the major source of protocol ossification >> on the Internet. MPTCP is just one feature of TCP that we might want >> do deploy there are many others. If this solution hampers use and >> deployment of those, then I don't believe this is a reasonable >> tradeoff regardless of what the benefits are. > > > You might be right that I focus on the benefits too much. > But, I personally don't think all middleboxes are bad. I think these > ossifications are mainly caused by poorly designed middleboxes. > If we can do things correctly, I think a middlebox might be able to > intervene only when it can be beneficial otherwise stays away to not harm > anything. > I guess you don't want to throw away all load balancers, IDSs, firewalls > from the Internet because they ossify protocols in some cases. It's a bit off topic, but, yes, I do want to eliminate these from the Internet. It's not just because of protocol ossification or their breaking of the end to end model (particularly for security). I believe they're becoming largely obsolete. Stateless load balancing can and ECMP can be accomplished with out DPI by including IPv6 flow label in a hash. The perimeter stateful firewall model is not relevant for cloud and multi-tenant environments and without IDS they don't give users much protection for modern threats. IDS on application layer protocols is great except for the fact that it's pretty much rendered useless in the presence of payload encryption (i.e. TLS). Besides that, I think were going to see more protocols like QUIC that purposely hide transport layer information from the network and hopefully more use of transport mode encryption for TCP to accomplish the same effect. The service that these devices provide (packet filtering, IDS, etc.) are still needed, but I believe we can get these without needing middleboxes in the data path and without breaking end to end model or end to end security. Tom > -- > Yoshi > >