From nobody Mon Sep 4 10:55:40 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868071201F8 for ; Mon, 4 Sep 2017 10:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 NG4-BogEhNPb for ; Mon, 4 Sep 2017 10:55:37 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02A21241FC for ; Mon, 4 Sep 2017 10:55:36 -0700 (PDT) Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com [209.85.161.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id ECD0E27868D for ; Tue, 5 Sep 2017 02:55:32 +0900 (JST) Received: by mail-yw0-f180.google.com with SMTP id w204so4553333ywg.3 for ; Mon, 04 Sep 2017 10:55:32 -0700 (PDT) X-Gm-Message-State: AHPjjUiEcQveJsTfh0ZQY7k/Dzorls/iKBL143RFkIq/gfdF/wm9Enms BM5e4BdwzoNkdoN/O2rfhR4xi1YnTw== X-Google-Smtp-Source: ADKCNb4TUwSWZHKN8SfNoM25SbbJf6JT1gVXRtlNEryErT7yE7u2P/zMaW1fxB40GWqKefRrscPgTsexGeY1ft5l6MM= X-Received: by 10.129.122.131 with SMTP id v125mr1076134ywc.48.1504547731706; Mon, 04 Sep 2017 10:55:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.68.193 with HTTP; Mon, 4 Sep 2017 10:55:31 -0700 (PDT) From: Yoshifumi Nishida Date: Mon, 4 Sep 2017 10:55:31 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tcpm] write-up for draft-ietf-tcpm-cubic-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 17:55:39 -0000 Hello, I'm very sorry for the delay. I just have submmitted my write-up on the following URL: https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/shepherdwriteup/ Please point out If I missed or overlook something. Otherwise I will submit it by the end of this week. Thanks! -- Yoshi From nobody Wed Sep 13 08:01:49 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@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: , , 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: Subject: [tcpm] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group 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 jean-yves.leboudec@epfl.ch Thu Sep 14 09:23:32 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C28133045 for ; Thu, 14 Sep 2017 09:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x29NlZRffdW6 for ; Thu, 14 Sep 2017 09:23:30 -0700 (PDT) Received: from smtp0.epfl.ch (smtp0.epfl.ch [IPv6:2001:620:618:1e0:1:80b2:e058:1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E46F132D47 for ; Thu, 14 Sep 2017 09:23:29 -0700 (PDT) Received: (qmail 10996 invoked by uid 107); 14 Sep 2017 16:23:27 -0000 X-Virus-Scanned: ClamAV Received: from icsil1noteb199.epfl.ch (HELO [128.178.151.248]) (128.178.151.248) (TLS, ECDHE-RSA-AES256-GCM-SHA384 (X25519 curve) cipher) (authenticated) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTPSA; Thu, 14 Sep 2017 18:23:27 +0200 X-EPFL-Auth: NEeoqgqpL4FbN4v4U5sYn7uRG/mYw1WBx57C7OUZVKBbuBFpSzs= To: tcpm@ietf.org From: Le Boudec Jean-Yves Message-ID: Date: Thu, 14 Sep 2017 18:23:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------D112AC643C34097DD13E0057" Content-Language: en-US Archived-At: Subject: [tcpm] About Cubic when slow start exits with no loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 17:08:11 -0000 This is a multi-part message in MIME format. --------------D112AC643C34097DD13E0057 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, in draft-ietf-tcpm-cubic-05, I see that slow start is assumed, but I did not find what Cubic does if slow start ends with no loss. I guess congestion avoidance is entered, but then how does Cubic computes W_max and K when congestion avoidance is entered following slow start with no loss ? It seems reasonable to have K=0 and W_max set to a very large value, right ?  Did I miss anything ? JY --------------D112AC643C34097DD13E0057 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

in draft-ietf-tcpm-cubic-05, I see that slow start is assumed, but I did not find what Cubic does if slow start ends with no loss. I guess congestion avoidance is entered, but then how does Cubic computes W_max and K when congestion avoidance is entered following slow start with no loss ? It seems reasonable to have K=0 and W_max set to a very large value, right ?  Did I miss anything ?

JY

--------------D112AC643C34097DD13E0057-- From nobody Thu Sep 14 11:10:31 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8541286C7 for ; Thu, 14 Sep 2017 11:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.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 SMX4dLmWAzTb for ; Thu, 14 Sep 2017 11:10:28 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0181.outbound.protection.outlook.com [216.32.180.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D08132D7B for ; Thu, 14 Sep 2017 11:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mkr0dC8VELdpWEzhemBhQgNsFYdfIWZujuuCoipDJ1c=; b=ZuBA/RL2ekJsfOGcgPcDFiz4ip0w+JcPgMajMVyX/7tqtx1xwhmwlt8DHNsEgsrL54JSuNPsXaPYbvlRnaXDoWqXyJOPrF6EVKNdN8UAmYRWTk39D2vqPSpYhQWJQs3pPmKTNqLd3bw6mUI2neopQb8/swkkwBozuomgi/TKiLg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [192.168.0.21] (97.98.140.59) by BN6PR08MB2754.namprd08.prod.outlook.com (10.175.189.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Thu, 14 Sep 2017 18:10:25 +0000 To: Le Boudec Jean-Yves , tcpm@ietf.org References: From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: Date: Thu, 14 Sep 2017 13:10:21 -0500 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="------------438CA4C327389C6B83D71F42" Content-Language: en-US X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: CY4PR15CA0010.namprd15.prod.outlook.com (10.172.74.20) To BN6PR08MB2754.namprd08.prod.outlook.com (10.175.189.136) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2e62619b-7651-43e4-6d51-08d4fb9bdfd0 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR08MB2754; X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2754; 3:OaBdjqQjxj1A9pOuzgZiYZkJrzESsGbjD4Z8Qfw/kUnQeLsSu0HSR5WuWaC4INxefRLjTKIVnukPFtH5FXg8oPRgVvMnj1+bg4YrnQiut57Esrbgt8qt9AR0jB4PrvKUaZ9y7IGv3Rdqfua6zCVC5J6XAplhoavyX8zneyq1A24mQLXKx0kDP3+sjrd3Ma0ZrrOZ2Om6deYruNlk60Y7cG+O2gu5qrDX9KU8DKPe0YifNetPKfTXlDOJ2U/o+SaX; 25:+00/6vHEvnFbipvbgg3njNQ8qFapv2qDJki1xBptkyqhJViEJYssSG8lL4nBbaaE+7lNdeenvbNMGLJ2EvwRJJpgsr9KTJh1RMjrQq64Qdg0lm2M6kw88iiDBCb0PC9NYoeZkR28f8kRfsCAsgdVJfE4Y59Qu4OG8bTl3TLr3k9eNJFWLjfvjkycIcMoB4XUW+I7MtjId9iNp44AKhmih2yFT/uSMbSJa7UpWx1hRy4CVPzcQvfXiMyIVQkeHuHR4p1+UJreL9fRHsCf30ZUQdP+MRYsj4z/3e0WcJUcJVHQucGl0aSukmgm3dylyXFvtNfxAmyFy/ZOUcuXsekSUg==; 31:bwyMiNiL/UJsaGRG3kwZKcXNbccuTLcKg/dict8AXZCpUcqFZ4vGf/422LPQSJRmyfiwHmcox5Gj9i/EmhlMO/aUJLOpq6tNPgslqWmHgHaoGExsyIbLQNeVQFkxaqXCclb1OjNvYDOEzEtBVKoLXfwMUTFCg1Azl6AHHpbMFpMwHa7JVGxf3nNbQ7bFohXgWW4nDsaovpgaJ7b414goilJO2H9eOuvQwJ3bXW6Avsc= X-MS-TrafficTypeDiagnostic: BN6PR08MB2754: X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2754; 20:UYc5a7osXkxjIG8L4XnItQXD1GmhQUxTiIdwZx4QZCx0F0uRR3wqdlMyARx/KTgRwQPVCYci62iT0RCWivkoN7Bop7Nc5ucN573TUI101+eokYk2tv4DkvYatOoxTADZJRSI10TPBXV7gzLqdPfaf/CJ8QK8mMxOk9NFYXyxIdOiR5HlbXRhsW3TL4occCD6J8BIwHxo3sf0SSrsnAttNhITXwmTc2GZvtm5j47pBLSul7w28dQGJnQvkVXcCcF/I5kjhyJ0/PC2Afnhl+1y0+0nSTCrh7OW3CqSi9O9CCYIlV2rbW2lPRV+dFzKCgnytm4JtbBr/+jRnJ8JFc5lNm+SWQbUxUiP09M58tMQekbQneDOMWGvSXLmxBYy8x6f6yBPqh20+DreLVoIoOMjGVP9hS4UtIBXya7tC+8Yz6sRqF1+AzBI8vXjoOHr6CQpp7jg0jEU0CYvdWFrlnB0sWmj0E4mxFEGyfu5AWXHJ9Hq16MUotJobGMXVwA9mDvd; 4:H6O4CqgypF5Ru5zzujpQapGnVPorvJLODA3Es9c/XpdT+2qQlayr+XenZ64oWmBh9w2n90vjdIKDUbTLtTSYcPTv90JSlJPFQ9E8XVQ/tzD5/wGSU3h/4h1QoJudIrrVg3EjKis34mDubJTtSDnQoLOjfgbZ65qqy/z0sCL9mGv9LLRFrE0p0zHUYQSGXrfn9iK3GYcsYFxpqs3GZfl3GjmOWMbzWQgXNKv/HQE3n7K+EXMzFfzInD3PLW+xUPJhOsaSvxGDroyWohxN/qwepgt8j8BY00lA2KUytSoRHJg= X-Exchange-Antispam-Report-Test: UriScan:(58145275503218); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR08MB2754; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR08MB2754; X-Forefront-PRVS: 0430FA5CB7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(376002)(346002)(199003)(377454003)(24454002)(189002)(6246003)(4001350100001)(53546010)(110136004)(105586002)(106356001)(6306002)(65806001)(53936002)(65956001)(606006)(66066001)(236005)(25786009)(117156002)(430100004)(75432002)(3260700006)(54896002)(966005)(413944005)(16586007)(6116002)(3846002)(478600001)(65826007)(2950100002)(6666003)(84326002)(77096006)(6486002)(86362001)(229853002)(2906002)(189998001)(76176999)(50986999)(54356999)(7736002)(83506001)(97736004)(68736007)(64126003)(5660300001)(31696002)(16576012)(88552002)(33646002)(36756003)(786003)(8936002)(31686004)(8676002)(316002)(90366009)(81166006)(81156014)(101416001)(16526017); DIR:OUT; SFP:1501; SCL:1; SRVR:BN6PR08MB2754; H:[192.168.0.21]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR08MB2754; 23:ExMPOECjg2VSKH6mWKuc5AxYLsiM8JN59cN1bSFO4?= =?us-ascii?Q?4tCfHfDHS09puzSj9xxS2RiC7A0vSQAERyMppW4uLDn13jEcf0IdpW9pX0/a?= =?us-ascii?Q?Jj+uadFFlMabQ9URxkPfgGOaAPCSmoUujadybu6EweyH6cUNllhIP3CLapnT?= =?us-ascii?Q?/mdAqill3sgQOVKp9Y1YeUB1ArPbf1uBziFiF4H9u0soLCVn0syzq3ukY+jG?= =?us-ascii?Q?+nIwFWy970mfUFQ+4e0FEjyM0FaazzaXTesgSelAnhDrgAFNGwpxFm0n/0ae?= =?us-ascii?Q?yoc3I91CVVduw5F7rzsWWlLFYWVnjlgpTpU45pgGFig20bNlP4lQjP8j9Zsw?= =?us-ascii?Q?mAUeqm81/jYFYSbLQHBwVGW878F3yrXgIgTaqiv3cW8xUegftMn4/bkoLRSR?= =?us-ascii?Q?SGGwCqoQqiALnpwO7kku34JsUGu+YMgGiCxO5kH/JzgeLo5Jfnk63mIOJ7FM?= =?us-ascii?Q?/R9o8p5ADn1z2IOMYvVQ4yDeeunHQB0W3xazRLVbnZernP4ATB1oHEHKv1XJ?= =?us-ascii?Q?cIRydIf07OmGQQaViLVDGeX3SHlpRDrOsaugw6ewaLtX8UD0+1llILiKgWzn?= =?us-ascii?Q?cAzkDwH3Yfhh9wW1QDofDgL+7o586z/QzHIq8dUunm8wgd9Dh/d9ozi7CplP?= =?us-ascii?Q?nInAF+hLDIreiptf1GEY+nS5+jUP56Iq/L2LCAswCz1C3QOH+fXz5GiXMWn1?= =?us-ascii?Q?zch5gKYhSwjwy+ee5NoxFMy+70N50YaBTO8cxvxtOii74Us4Ncand4LdBCyc?= =?us-ascii?Q?/irGT29reEehfY5fcerBuSUZyKM+w7DWYjr+wge9lbpsJI8JBOk8Qzdq3uDo?= =?us-ascii?Q?A3q3Jy/z1pnk94Wk9YA9t61bvjtL3vlHp8CFNfxFiL3fbExNTNXGiGElUvYG?= =?us-ascii?Q?pkGnnUan7KNiriztd1eqXe7Y4GC95BMlq3EsxymwmjGRXa4wu9vcfl3CWb4V?= =?us-ascii?Q?acoThVJ1H14T8EDcl9WQ3Lfb1jWiJfsiLdIQ8GMyfw/X3e3zYRlNcaRQbNHg?= =?us-ascii?Q?flLOp/igN0ha6F2yybQBQLfoJqV0aKECwimStpWWip/HVj1vTi7JKX82VZL5?= =?us-ascii?Q?M5+HU8kOcLjyFM7EESxw0Efc8aWc4JZI5bh2VYHKJ4fjlBaYTEn1Iiuy4OKW?= =?us-ascii?Q?yPFdDkk/NqqBU5iIKcsmKDFpQGV1edA7DyWUnIrcP1/DjQ9rSuQGZPGodLcG?= =?us-ascii?Q?eSICrp/doaP063FUdAIKQuOxcYek+BAkSrdt78YHwo1qFrvoAZwNqVL4ukBm?= =?us-ascii?Q?doF86SBkd2zYfFT5wFfoZnZaWr24sKyCZWNyX93zWdfZvu7o5rBvYSlewqRd?= =?us-ascii?Q?XoFSS+1lt3WRBZ0EZHse1VKjXDkIGl7h+iSzhevFt1EFWfwKVM/UkA8nmIZK?= =?us-ascii?Q?ibpNwU33rDrS/LZwjoenFWqz2Kqf2+kQlDFVmSUbkleepZByL3NFcdasgTcE?= =?us-ascii?Q?xZZH951PkcRVfAs1TpLuyxaQ091yyEuAkuonDw+51YXDVaC7vDz/6GR+r1hX?= =?us-ascii?Q?EOHxynfMppFd5Ifr0VtabWQD8Km8G8tj1A=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2754; 6:3GfqQkF1jaJiTiv+/Vb0CO0WN/rJZJrZF2imj0e7w87ccVj9EDO3j0L9rqtIyrTAd9++zl24XVPy2UAeyR3zqLZ6VjQ5ktDzTBbm6b1kujVxbnhIkC45YvsNOBEtirvoWmupx7MLsjHwcmuK4xQKigDGDbPwJ+v5wvM4Bf+CMDQmP9Fv0VIPz3Yia2K6qzraCjnHUPxr2lZx1xqqs0UEeFrvhD3bqjO0ShEBOTcMRiw42AIYyAglRCkg8n+fHA5mQk76vKjaRq6MWBcf0w1urDVO5ZtVCSASjchyyAqxqkmtpxiEgHv+Vvy3FOYQr6mTpZlmNFKuqjDXm77u3bERYQ==; 5:+hJqh9IuBak9JGA8P4BQciitINLOxWzkbd85x07M/y0O2j7JuOeqYPZLfPiJeTG9L7/rkaKoXYxUBE163Utc/Y1W0z9UdXgbRjMwEFVV+YwsWR6TVqb/exmDgvMiIrN5MLQvJeR2FvrvIcaS1NWEGg==; 24:vHwrAr6tXLy2B/YPue2GWl319IfivwubdW5ucd8y2lH40nuV232J/jKXFpqb7IWdRSFCe1ZWZ+4wF6SjdUCJQ0P/4Ozojd/sqnfZL18+yXc=; 7:wzqqAbW859XWq4qG7gVzWDkH4II3YX4XNI3Gki6rkoyBuBqHSv5yAjlacuCGzrUE0iTznQoPulyBYZ0vP7rvF/gRep9BtiTRXRyz39KgJUl9YuYwTMkUrW3iOWbzNOf1wQR/VwAtNVFdW4HFdKHBrCdOhBn681fLKR9jsH6EwPSn7Z9syE9LxHqcbn/vf7qqtNp2MM48Ad+ctFTH5R82QyP2lmCdiL3W4Qv9b2ficnM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2017 18:10:25.4876 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: fddb01ad-4983-436e-ab35-1af043b818c9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR08MB2754 Archived-At: Subject: Re: [tcpm] About Cubic when slow start exits with no loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 18:10:30 -0000 This is a multi-part message in MIME format. --------------438CA4C327389C6B83D71F42 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Jean-Yves, Yes, if the first slow start ends with no loss, Cubic enters congestion avoidance. In this case, both K (i.e., bic_K) and W_max (i.e., bic_last_max_cwnd) are still their initial values (i.e., 0), and the origin of the cubic function (i.e.,bic_origin_point) is set to the current congestion window size (i.e., cwnd). In addition, in this case, Cubic maintains a minimum cwnd increase speed of 5% per RTT (line 308-309 at http://elixir.free-electrons.com/linux/latest/source/net/ipv4/tcp_cubic.c). Thanks Lisong On 9/14/2017 11:23 AM, Le Boudec Jean-Yves wrote: > > Hi, > > in draft-ietf-tcpm-cubic-05, I see that slow start is assumed, but I > did not find what Cubic does if slow start ends with no loss. I guess > congestion avoidance is entered, but then how does Cubic computes > W_max and K when congestion avoidance is entered following slow start > with no loss ? It seems reasonable to have K=0 and W_max set to a very > large value, right ?  Did I miss anything ? > > JY > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------438CA4C327389C6B83D71F42 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear Jean-Yves,

Yes, if the first slow start ends with no loss, Cubic enters congestion avoidance. In this case, both K (i.e., bic_K) and W_max (i.e., bic_last_max_cwnd) are still their initial values (i.e., 0), and the origin of the cubic function (i.e.,bic_origin_point) is set to the current congestion window size (i.e., cwnd). In addition, in this case, Cubic maintains a minimum cwnd increase speed of 5% per RTT (line 308-309 at http://elixir.free-electrons.com/linux/latest/source/net/ipv4/tcp_cubic.c).

Thanks
Lisong

On 9/14/2017 11:23 AM, Le Boudec Jean-Yves wrote:

Hi,

in draft-ietf-tcpm-cubic-05, I see that slow start is assumed, but I did not find what Cubic does if slow start ends with no loss. I guess congestion avoidance is entered, but then how does Cubic computes W_max and K when congestion avoidance is entered following slow start with no loss ? It seems reasonable to have K=0 and W_max set to a very large value, right ?  Did I miss anything ?

JY



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

--------------438CA4C327389C6B83D71F42-- From nobody Thu Sep 14 23:57:25 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C425113235C for ; Thu, 14 Sep 2017 23:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 q8foggpdlCFQ for ; Thu, 14 Sep 2017 23:57:21 -0700 (PDT) Received: from smtp4.epfl.ch (smtp4.epfl.ch [IPv6:2001:620:618:1e0:1:80b2:e059:1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453B913218F for ; Thu, 14 Sep 2017 23:57:21 -0700 (PDT) Received: (qmail 25656 invoked by uid 107); 15 Sep 2017 06:57:19 -0000 X-Virus-Scanned: ClamAV Received: from icsil1noteb199.epfl.ch (HELO [128.178.151.248]) (128.178.151.248) (TLS, ECDHE-RSA-AES256-GCM-SHA384 (X25519 curve) cipher) (authenticated) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTPSA; Fri, 15 Sep 2017 08:57:19 +0200 X-EPFL-Auth: KwZMfy/kQZ333iUx4rNvzaKf/XwJxAYVfs/y+e8TW7OYmD9BbR8= To: Lisong Xu , tcpm@ietf.org References: From: Le Boudec Jean-Yves Message-ID: <78ed3ceb-9814-994c-e4ed-e0c8a145cfe3@epfl.ch> Date: Fri, 15 Sep 2017 08:57:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9E3363258B703AB023BC8A38" Content-Language: en-US Archived-At: Subject: Re: [tcpm] About Cubic when slow start exits with no loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 06:57:24 -0000 This is a multi-part message in MIME format. --------------9E3363258B703AB023BC8A38 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Lisong thanks for the pointer. Shouldn't that be also described in the ID ? Best, JY On 14.09.2017 20:10, Lisong Xu wrote: > > Dear Jean-Yves, > > Yes, if the first slow start ends with no loss, Cubic enters > congestion avoidance. In this case, both K (i.e., bic_K) and W_max > (i.e., bic_last_max_cwnd) are still their initial values (i.e., 0), > and the origin of the cubic function (i.e.,bic_origin_point) is set to > the current congestion window size (i.e., cwnd). In addition, in this > case, Cubic maintains a minimum cwnd increase speed of 5% per RTT > (line 308-309 at > http://elixir.free-electrons.com/linux/latest/source/net/ipv4/tcp_cubic.c). > > Thanks > Lisong > > On 9/14/2017 11:23 AM, Le Boudec Jean-Yves wrote: >> >> Hi, >> >> in draft-ietf-tcpm-cubic-05, I see that slow start is assumed, but I >> did not find what Cubic does if slow start ends with no loss. I guess >> congestion avoidance is entered, but then how does Cubic computes >> W_max and K when congestion avoidance is entered following slow start >> with no loss ? It seems reasonable to have K=0 and W_max set to a >> very large value, right ?  Did I miss anything ? >> >> JY >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > --------------9E3363258B703AB023BC8A38 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear Lisong

thanks for the pointer. Shouldn't that be also described in the ID ?

Best, JY


On 14.09.2017 20:10, Lisong Xu wrote:

Dear Jean-Yves,

Yes, if the first slow start ends with no loss, Cubic enters congestion avoidance. In this case, both K (i.e., bic_K) and W_max (i.e., bic_last_max_cwnd) are still their initial values (i.e., 0), and the origin of the cubic function (i.e.,bic_origin_point) is set to the current congestion window size (i.e., cwnd). In addition, in this case, Cubic maintains a minimum cwnd increase speed of 5% per RTT (line 308-309 at http://elixir.free-electrons.com/linux/latest/source/net/ipv4/tcp_cubic.c).

Thanks
Lisong

On 9/14/2017 11:23 AM, Le Boudec Jean-Yves wrote:

Hi,

in draft-ietf-tcpm-cubic-05, I see that slow start is assumed, but I did not find what Cubic does if slow start ends with no loss. I guess congestion avoidance is entered, but then how does Cubic computes W_max and K when congestion avoidance is entered following slow start with no loss ? It seems reasonable to have K=0 and W_max set to a very large value, right ?  Did I miss anything ?

JY



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


--------------9E3363258B703AB023BC8A38-- From nobody Fri Sep 15 00:44:17 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C742413247A for ; Fri, 15 Sep 2017 00:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Jg67vxNBxk-J for ; Fri, 15 Sep 2017 00:44:13 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 0F471129B7A for ; Fri, 15 Sep 2017 00:44:13 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dslII-000C9q-T9 for tcpm@ietf.org; Fri, 15 Sep 2017 09:44:10 +0200 Received: from [160.80.82.77] (helo=[172.16.42.8]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dslIH-0008Sc-So; Fri, 15 Sep 2017 09:44:10 +0200 From: Michael Welzl Message-Id: <807840A3-8F95-44FB-8037-87F92F64F747@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_5E6E6D1A-15E6-4A26-B851-74829893F592" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 15 Sep 2017 09:44:07 +0200 In-Reply-To: <78ed3ceb-9814-994c-e4ed-e0c8a145cfe3@epfl.ch> Cc: xu@unl.edu, tcpm@ietf.org To: Le Boudec Jean-Yves References: <78ed3ceb-9814-994c-e4ed-e0c8a145cfe3@epfl.ch> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 160.80.82.77 is neither permitted nor denied by domain of ifi.uio.no) client-ip=160.80.82.77; envelope-from=michawe@ifi.uio.no; helo=[172.16.42.8]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.000, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 19969FE061EF1355CAD21B98E3B459B549C4489A Archived-At: Subject: Re: [tcpm] About Cubic when slow start exits with no loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 07:44:16 -0000 --Apple-Mail=_5E6E6D1A-15E6-4A26-B851-74829893F592 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I give a +1 to this request: I remember searching an answer to the same = question, long (actually a few years) ago - I looked at the (old) I-D, = found nothing, and gave up after a bit of Linux code reading, at that = time. I should have remembered to request this being added when the Cubic = draft was picked up again - indeed this is an important thing to add, = IMO. Cheers, Michael > On Sep 15, 2017, at 8:57 AM, Le Boudec Jean-Yves = wrote: >=20 > Dear Lisong >=20 > thanks for the pointer. Shouldn't that be also described in the ID ?=20= > Best, JY >=20 > On 14.09.2017 20:10, Lisong Xu wrote: >> Dear Jean-Yves, >>=20 >> Yes, if the first slow start ends with no loss, Cubic enters = congestion avoidance. In this case, both K (i.e., bic_K) and W_max = (i.e., bic_last_max_cwnd) are still their initial values (i.e., 0), and = the origin of the cubic function (i.e.,bic_origin_point) is set to the = current congestion window size (i.e., cwnd). In addition, in this case, = Cubic maintains a minimum cwnd increase speed of 5% per RTT (line = 308-309 at = http://elixir.free-electrons.com/linux/latest/source/net/ipv4/tcp_cubic.c = ). >> Thanks >> Lisong >>=20 >> On 9/14/2017 11:23 AM, Le Boudec Jean-Yves wrote: >>> Hi, >>>=20 >>> in draft-ietf-tcpm-cubic-05, I see that slow start is assumed, but I = did not find what Cubic does if slow start ends with no loss. I guess = congestion avoidance is entered, but then how does Cubic computes W_max = and K when congestion avoidance is entered following slow start with no = loss ? It seems reasonable to have K=3D0 and W_max set to a very large = value, right ? Did I miss anything ? >>>=20 >>> JY >>>=20 >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm = >>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_5E6E6D1A-15E6-4A26-B851-74829893F592 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

I = give a +1 to this request: I remember searching an answer to the = same question, long (actually a few years) ago - I looked at the (old) = I-D, found nothing, and gave up after a bit of Linux code reading, at = that time.

I should = have remembered to request this being added when the Cubic draft was = picked up again - indeed this is an important thing to add, = IMO.

Cheers,
Michael



On = Sep 15, 2017, at 8:57 AM, Le Boudec Jean-Yves <jean-yves.leboudec@epfl.ch> wrote:

=20 =20

Dear = Lisong

thanks for the pointer. Shouldn't that be also = described in the ID ?

Best, JY


On 14.09.2017 20:10, Lisong Xu = wrote:

Dear Jean-Yves,

Yes, if the first slow start ends with no loss, Cubic enters congestion avoidance. In this case, both K (i.e., bic_K) and W_max (i.e., bic_last_max_cwnd) are still their initial values (i.e., 0), and the origin of the cubic function (i.e.,bic_origin_point) is set to the current congestion window size (i.e., cwnd). In addition, in this case, Cubic maintains a minimum cwnd increase speed of 5% per RTT (line 308-309 at http://elixir.free-electrons.com/linux/latest/sou= rce/net/ipv4/tcp_cubic.c).

Thanks
Lisong

On 9/14/2017 11:23 AM, Le Boudec Jean-Yves wrote:

Hi,

in draft-ietf-tcpm-cubic-05, I see that = slow start is assumed, but I did not find what Cubic does if slow start ends with no loss. I guess congestion avoidance is entered, but then how does Cubic computes W_max and K when congestion avoidance is entered following slow start with no loss ? It seems reasonable to have K=3D0 and W_max set to a very large value, right ?  Did I miss anything ?

JY



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


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

= --Apple-Mail=_5E6E6D1A-15E6-4A26-B851-74829893F592-- From nobody Fri Sep 15 02:27:02 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925BB13308B for ; Fri, 15 Sep 2017 02:27:00 -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 1YdJynmVMsDk for ; Fri, 15 Sep 2017 02:26:58 -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 75F8813306D for ; Fri, 15 Sep 2017 02:26:57 -0700 (PDT) Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6D54C2784C4 for ; Fri, 15 Sep 2017 18:26:55 +0900 (JST) Received: by mail-yw0-f176.google.com with SMTP id v137so1094510ywg.5 for ; Fri, 15 Sep 2017 02:26:55 -0700 (PDT) X-Gm-Message-State: AHPjjUi1yNytg678j9TnOPLhxo70X9/eVOTGv0jKZ8AbaQDE3MfYoPuq xVvUr/OVa14TmOfRvMa2IKOrVmnNx3q/50zCX18= X-Google-Smtp-Source: AOwi7QAjwGilpgkKN5bWjF6zoD+TGSk81E6xFD309aOjOk/Rt5lkzUe0TuxEXHh69H5E94JUqgF4ozpwHKl3T6KRtas= X-Received: by 10.37.221.135 with SMTP id u129mr20176780ybg.260.1505467613958; Fri, 15 Sep 2017 02:26:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.64.145 with HTTP; Fri, 15 Sep 2017 02:26:53 -0700 (PDT) In-Reply-To: <807840A3-8F95-44FB-8037-87F92F64F747@ifi.uio.no> References: <78ed3ceb-9814-994c-e4ed-e0c8a145cfe3@epfl.ch> <807840A3-8F95-44FB-8037-87F92F64F747@ifi.uio.no> From: Yoshifumi Nishida Date: Fri, 15 Sep 2017 02:26:53 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Michael Welzl Cc: Le Boudec Jean-Yves , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="001a114bc9d659dc06055936fe57" Archived-At: Subject: Re: [tcpm] About Cubic when slow start exits with no loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 09:27:01 -0000 --001a114bc9d659dc06055936fe57 Content-Type: text/plain; charset="UTF-8" I also agree. I believe it won't affect our consensus on the draft as it is a small additional tip. Although the doc already has been requested for publication several days ago, I prefer adding it to the draft if there's no problem for the procedure. I hope we still have a little time before IESG starts reviewing it. Thanks, -- Yoshi On Fri, Sep 15, 2017 at 12:44 AM, Michael Welzl wrote: > Hi, > > I give a +1 to this request: I remember searching an answer to the same > question, long (actually a few years) ago - I looked at the (old) I-D, found > nothing, and gave up after a bit of Linux code reading, at that time. > > I should have remembered to request this being added when the Cubic draft > was picked up again - indeed this is an important thing to add, IMO. > > Cheers, > Michael > > > > On Sep 15, 2017, at 8:57 AM, Le Boudec Jean-Yves > wrote: > > Dear Lisong > > thanks for the pointer. Shouldn't that be also described in the ID ? > > Best, JY > > > On 14.09.2017 20:10, Lisong Xu wrote: > > Dear Jean-Yves, > > Yes, if the first slow start ends with no loss, Cubic enters congestion > avoidance. In this case, both K (i.e., bic_K) and W_max (i.e., > bic_last_max_cwnd) are still their initial values (i.e., 0), and the origin > of the cubic function (i.e.,bic_origin_point) is set to the current > congestion window size (i.e., cwnd). In addition, in this case, Cubic > maintains a minimum cwnd increase speed of 5% per RTT (line 308-309 at > http://elixir.free-electrons.com/linux/latest/source/net/ipv4/tcp_cubic.c ). > > Thanks > Lisong > > On 9/14/2017 11:23 AM, Le Boudec Jean-Yves wrote: > > Hi, > > in draft-ietf-tcpm-cubic-05, I see that slow start is assumed, but I did not > find what Cubic does if slow start ends with no loss. I guess congestion > avoidance is entered, but then how does Cubic computes W_max and K when > congestion avoidance is entered following slow start with no loss ? It seems > reasonable to have K=0 and W_max set to a very large value, right ? Did I > miss anything ? > > JY > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a114bc9d659dc06055936fe57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also agree. I believe it won't affect our conse= nsus on the draft as it is a small additional tip.
Although the d= oc already has been requested for publication several days ago, I prefer ad= ding it to the draft if there's no problem for the procedure.=C2=A0
I hope we still have a little time before IESG starts reviewing it.<= /div>

Thanks,
--
Yoshi


On Fri, Sep 15, 2017 at 12:44 AM, Michael We= lzl <michawe@ifi= .uio.no> wrote:
> Hi,
>
> I give a +1 to this requ= est: I remember searching an answer to the same
> question, long (act= ually a few years) ago - I looked at the (old) I-D, found
> nothing, = and gave up after a bit of Linux code reading, at that time.
>
>= ; I should have remembered to request this being added when the Cubic draft=
> was picked up again - indeed this is an important thing to add, IM= O.
>
> Cheers,
> Michael
>
>
>
> = On Sep 15, 2017, at 8:57 AM, Le Boudec Jean-Yves
> <jean-yves.leboudec@epfl.c= h> wrote:
>
> Dear Lisong
>
> thanks for the= pointer. Shouldn't that be also described in the ID ?
>
> = Best, JY
>
>
> On 14.09.2017 20:10, Lisong Xu wrote:
&= gt;
> Dear Jean-Yves,
>
> Yes, if the first slow start en= ds with no loss, Cubic enters congestion
> avoidance. In this case, b= oth K (i.e., bic_K) and W_max (i.e.,
> bic_last_max_cwnd) are still t= heir initial values (i.e., 0), and the origin
> of the cubic function= (i.e.,bic_origin_point) is set to the current
> congestion window si= ze (i.e., cwnd). In addition, in this case, Cubic
> maintains a minim= um cwnd increase speed of 5% per RTT (line 308-309 at
> http://elixir.free-electrons.com/linux/latest/source/n= et/ipv4/tcp_cubic.c).
>
> Thanks
> Lisong
>= ;
> On 9/14/2017 11:23 AM, Le Boudec Jean-Yves wrote:
>
>= Hi,
>
> in draft-ietf-tcpm-cubic-05, I see that slow start is = assumed, but I did not
> find what Cubic does if slow start ends with= no loss. I guess congestion
> avoidance is entered, but then how doe= s Cubic computes W_max and K when
> congestion avoidance is entered f= ollowing slow start with no loss ? It seems
> reasonable to have K=3D= 0 and W_max set to a very large value, right ?=C2=A0 Did I
> miss any= thing ?
>
> JY
>
>
>
> ________________= _______________________________
> tcpm mailing list
> tcpm@ietf.org
> http= s://www.ietf.org/mailman/listinfo/tcpm
>
>
>
= > _______________________________________________
> tcpm mail= ing list
> tcpm@ie= tf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>= ;
>
>
> ____________________________________________= ___
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/tcpm
>

--001a114bc9d659dc06055936fe57-- From nobody Fri Sep 15 06:50:41 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC791332D7 for ; Fri, 15 Sep 2017 06:50:40 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=uofnelincoln.onmicrosoft.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 sot2-_VaRcBt for ; Fri, 15 Sep 2017 06:50:38 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0050.outbound.protection.outlook.com [207.46.163.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06930132396 for ; Fri, 15 Sep 2017 06:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KS6DKBM2neKNDWg9svbsco0sEgQFtt12vVh1HBmRCYQ=; b=n+lnww3lEBBxxMPLlIi87GigwrFhLp5uHKtRnNqhtts/B4FKDiBAcXZJ06blpDI7zvxR4SovHy9pqCy2ghNWXNfvv1ms0yZr/DrrUkVt2WQgzc75bv5vaIn6Tq1LFQHddeOyeVnxv1ipSDSFyimYU33nI6Kwll1mSf+P+OW2n9g= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [10.211.143.74] (129.93.4.28) by BN6PR08MB2755.namprd08.prod.outlook.com (10.175.189.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Fri, 15 Sep 2017 13:50:35 +0000 To: Yoshifumi Nishida , Michael Welzl Cc: "tcpm@ietf.org" , Le Boudec Jean-Yves References: <78ed3ceb-9814-994c-e4ed-e0c8a145cfe3@epfl.ch> <807840A3-8F95-44FB-8037-87F92F64F747@ifi.uio.no> From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: Date: Fri, 15 Sep 2017 08:50:32 -0500 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="------------3FACE7D001176620C64364C1" Content-Language: en-US X-Originating-IP: [129.93.4.28] X-ClientProxiedBy: DM5PR08CA0043.namprd08.prod.outlook.com (10.164.143.32) To BN6PR08MB2755.namprd08.prod.outlook.com (10.175.189.137) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 35247c71-dde5-4b3e-84b4-08d4fc40be16 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR08MB2755; X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2755; 3:jfxdRtn3Oa8VTDIrTRf2v4olTH7JGmAPQwU8g3TYlRvDRGvLlsMZLew2LgzUgMvSQhq2wUskEXmLVr6qPmsMbtj6ZMjv7J1fA8cAMWMd1vL6XHRrp+Ub9v5WQYfb8x0MCF3NGcaIFgfSpB9bBWAAnCdgc7+YoAF5E7Y6hjpMpXCWcYRqgmqboV7rQrT8HlI0UdJebrnywRCNomxqwA3N1Gs2840Il32qUktictLZSl4KOTbmaS9qzWArU3MBjjs8; 25:F5Oov56HcTqTxBSiqk/GlgMfPl0xuPXaIiqaD6p2ItdrjPVk+ZzT1m/FLj+cicZvJGNYngWlJ6ncy8I1N9c0caalbUpylFfR4KIPW5iiIT51WNO3MkhQ3PYb4v7k8xkWWHWfPEV4J3hSuj207Ue+vnEB31VW9FwLJ/KvY5B3mA6Jp4QuZ/bbKWBmcKd8ud89TZagmtsllOS5ekNOlvsj9mtD4l0Kxfr+89PHaQP180m0lRDda1NfxcbpagD7c9+47rSpkxz3CtRbfgWHg9siug+CAOMjHTz843IfgDaHtUnGa7y/iqdWVtJnALHzbktp2fSdoVbd72Vbb/kTTuVikQ==; 31:ng5nVM3EOxToQnT7Pkfi0gaTajL2xywMY/NljCA3WWEyhQ8Bdx5z3lmRv4/ytNy5zZqwEgSHXBUIJwSu2uEdAOZCAExHJbkVlHQtZvDZSJeYgcgSRo9qQPFYqWrjS/4x6JW0ic5Gu812j7uhAji+yXrG7jM/9nBoLwa/XjL+d6/DTiziCWk7N7JO6xJsCLvKvm3TaNjC/LkkiGDrJ/R4/GE3lUeuCRXQgGzYi6Jjk/4= X-MS-TrafficTypeDiagnostic: BN6PR08MB2755: X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2755; 20:6/eFyeq7+cqEaAeZ0d8QAlJMUVa/qsBTLaSwLTsgQm8+6QaK78dqdI7mZNOkcMx0lLkNBDNnU3UF3f1YsTpQUxqoo38uK4uo8WKNa0b3QfhuQ5tY/dfUIsEsnLMS3ukzkEWSAeRDM0xDxcYFHVLlVX5z81Fam+0JYhuDpelwhmyvNqujxi6s4Lqm8yqEH2ycpSN+UWPAgC0iTk/C/UUNNgqsaF9mqPj715wSezVylF039liZRvHAIl9Sy5AbUFQjFfb1ue/7MdYm9n5ihjtz1Z/nNRL+zUkCZ8PGyT2yNTm9rvkiKKiX62AnWP8WP0xVZO300h5kPs1bjMef3jsLx0N6a6td98BnSdWK0H6pHXyfGUrfz76Q9Hffsv91dq4sAeTjppKn/ZKL4ZA0R1GNGzJCavZrbVEsIqgjKiaesg7O6Gv3MY/R9jx/tP22iJP1XZGfvqecsZT/kxMhJ/zb4qCxniI41yZNhqTACeTBRKroIYDhkjNoAo7NbJBdFpfL; 4:rLjzw1TAWIVEw6bygxyR8YvT+ybdsionDvR+cgIfnS0rVIE7AC3fPR2ZyL7kQcYOIbqznAMuigPENsD7mLTJ2DxqRaTTqUjzcwXJTiLTUHdBpHJZ3xlLjjv08TsHuT9UD7kQ0tluIuQskxVn1/rXZ4ngGVCFwOWJdOpHU7MdW2c58yMELRB4YIogvreMVQjoUOQzljSpZWwhh06QCJpiye4PyYtwEAcevpiqOWUO8wt25BFZlJYT6XP1xkePnOKXE6/YtODnl6dMgipVZF2mY/BNAbWoh1ZD6+qNHf9FZULyTiY6CagA/MtQ9yitoJfztSiZRrBRjWtZX1oI9gnXCg== X-Exchange-Antispam-Report-Test: UriScan:(100405760836317)(58145275503218); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR08MB2755; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR08MB2755; X-Forefront-PRVS: 0431F981D8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(346002)(376002)(24454002)(51914003)(189002)(199003)(377454003)(76176999)(53546010)(65806001)(66066001)(50986999)(54356999)(65956001)(53936002)(478600001)(36756003)(31686004)(2906002)(3260700006)(25786009)(606006)(6486002)(101416001)(229853002)(90366009)(88552002)(2950100002)(7736002)(6306002)(3846002)(54896002)(54906002)(6116002)(236005)(8676002)(81156014)(81166006)(68736007)(97736004)(430100004)(16526017)(966005)(16586007)(33646002)(16576012)(64126003)(4326008)(86362001)(8936002)(83506001)(5660300001)(189998001)(105586002)(106356001)(65826007)(31696002)(16410355002)(77096006)(6666003)(93886005)(58126008)(316002)(84326002)(75432002)(786003)(6246003); DIR:OUT; SFP:1501; SCL:1; SRVR:BN6PR08MB2755; H:[10.211.143.74]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR08MB2755; 23:nY0nSa4kmBihTQ4XdHvsDNhg4DeoMzWNuvLrWOkis?= =?us-ascii?Q?UM7jNX4vchPhp+tR+QScBIYJSlcVEffUpq4g0fvBW+sa4sj/N/Qq96+B1hHV?= =?us-ascii?Q?QSyRXCs/V7Kt4N9USyKYrkX8YSJUsYSxZjuwwu28j16Zm5uY/n+lRFcR8eGE?= =?us-ascii?Q?5KeM6sluVKDudBTQhz9W53UTW4bAFv8kD36BVUAEW8NCvKBdNOUDQfTlNgfy?= =?us-ascii?Q?wKRUJcuB/tdfzXmuwGX8m+Z+Buj3dv0osydn3hdo9a2NGBOjYz7Z21eMO8dz?= =?us-ascii?Q?VnpQPhsnzrngLt+5mJErg1MBxc1Vn9LQFW9BhsnrEB507rvH9fxzUvehzbDd?= =?us-ascii?Q?XRoSIv2l3EzikSDhKkS5v7IAOMtcpK9sFppvPuPg40w59PHZTJxjNUQQJHA/?= =?us-ascii?Q?wf3tO9QXchGaoP4h17p5FhSuaQcYGC40tJk0QVzghc9MZ1mzGvqyVLG1GZ2Y?= =?us-ascii?Q?eFt7T3fynY9HiiutlPedl5CVAWDNrw2I1oMl/LdPcFV4FhzX4/kpJvHy0cBQ?= =?us-ascii?Q?HjdlvL5bLLtDWvPgGWw9+uV+UydO/1XbSn2ZTe7Y/ncV0JMiwBcILDuSgP95?= =?us-ascii?Q?NPDy+NodzOaEj/gJG/XETkx3cPSiYdEckztIPlPJBobMb+XF8BcjJ0OJ5Xcm?= =?us-ascii?Q?Br4z269JqdyeAmlKIhB4PIWZfCcyFRMUFl1FgTHb6vuRhUHL33NIhOctI5hS?= =?us-ascii?Q?Ytuuzbaec/CeDCx886+rqtsZmpqXn1os4fLRzFHOvmxDGgdOCtqNtbr/WmeU?= =?us-ascii?Q?jvNFdDm1NjxlBMKX4QAPuoLjaCI7Jx7jfxxVYP1vl3oEKMA5Z9cBZ+icaHur?= =?us-ascii?Q?MhcK4KH+0A6sE7wnMhnExtMZ2isQhNXLNaPaFHJYHBlSuYoyl31a5Ty44bmX?= =?us-ascii?Q?cAiMt7kD+r4trH3eqrpWOl6GQy4tGy3LAj6VmrH8Xcs0tiJ1p5r0BsoxjE3g?= =?us-ascii?Q?xqKUTIIP38AB8U0iNxbzt6S6bNARJv/LXabGoId6d5iLZnaJGPIzQLSEWkk1?= =?us-ascii?Q?L+omWALLK8OtTgpZQ/zKPcXleHCHIC2aPkRL33PuzIjp6iH6QAjOBMbpb/ZP?= =?us-ascii?Q?8SXx/a+Y8JnN6leD2FRkiezppqQtzgPpDRTZEd+cJf1vu0TCsvUcT0bL2/h5?= =?us-ascii?Q?CYdXtw/oe6BV1d0Z3vODgOHiwBE+OmCmKBFaULgmqS1xZVHll0nQ8OWB5zRE?= =?us-ascii?Q?8UiNqH51fNVrmCrNFbOgOV3WICtuL/qEoie4YDdWyKja61gqIfLU98o38T6/?= =?us-ascii?Q?VnYPAxB1zzmSVac6I4Ma8SY9pdNGTH3t6WlD8qToP0UhbQhD2NXxfgzFc4D5?= =?us-ascii?Q?JkifwoP1dKuZNXM782XTORg8YPip9zD5CIh4J+SZS4gtJ1kNE95O9upQ36RM?= =?us-ascii?Q?mo61xDhaaVl/ymR0ycpaRs50Qk2OFWBeSf4LlKGCdRJm0/qAkUuwrxwe5dw3?= =?us-ascii?Q?TgsGkVHoPLsxCLxjLC75rRqQAnEzlLLfGuQCq0iOFFHtJtOiRETiTVjXiDM9?= =?us-ascii?Q?otSYgHMDIeVWOVQ+pl17iX+TKTVxsd7sUem0hHWutZnU/tIMkR0SS7+?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR08MB2755; 6:V/Xfdb1sdka07OdFZGeAdMP6fqR24RgByRWVjasY71QzW7IYL7izoFAz9ewB2umdd0D/tvXMD1sFrvruS1jPCdlpVPPtniWjqeKhZ7TqanALfnacCTzzHIT8TxrYbgE/hrkTJAalWV33TuGHZ+l+L35bS67P3sqvKeMep1jkLOqqfl7oATxsgzwqCgRZ8O3maB9l1Jjgk4ZU86FsRmUtLbEgAKZgDSdNw94BpaBJ8RlGzeS/cwi5jECy2BmKObIWgH1Xqj44wVqMzba1t6R+ZBk2G02SmRc0nRIZ1r86GdFQuoFaWJWNPWz4ovywD6RoLdfrNOocI7/7TGg7yvTYig==; 5:/PRTQF2OfoMEVsjF0EKkXuS8f+C/mb2M+dCjJEYJe/Rt3mlblzoBR2Hxi+K9iN/obAuTBUvrGvtfO95oU9wdxP9cHHeaP5vLpi0Tqae8TYvLx+yssZU4uFchOmIchMph2fJfqh6C75OXqm25npnBpQ==; 24:gTcDNjcFZGGXYQO5s1IJblu6nr4ydKvg1Y0ikjyGlsi3uhEUaOA0N0artTAMMKs54YiK+rDGRPvRoFmYsU5DXjNmftBiMcTXnalWy46AOms=; 7:zr0akNT4MIwljyXM8I5GCDlM6uoKejmWu1bZuPTzhD9lgt43WUMwa+1k+Ha7QH/c2wOr59pT7yLGUO3vZPVbSZKBN89UqweTQn9cAVm7IOV3EJcb8rGvRD64pCFhfPV76Ec17/ZH5E9attBA/mPWMn5MZjUUN4RXSrFVR+veZWtvydE5gdF1zeNKb6WzHxBrPzZkkGB+qUg8h0ZedJWhoDxFyMeW8kq95231XH2LDcw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2017 13:50:35.8648 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: fddb01ad-4983-436e-ab35-1af043b818c9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR08MB2755 Archived-At: Subject: Re: [tcpm] About Cubic when slow start exits with no loss X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 13:50:41 -0000 This is a multi-part message in MIME format. --------------3FACE7D001176620C64364C1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thank you all. We will add it to the draft in one or two days. Thanks Lisong On 9/15/2017 4:26 AM, Yoshifumi Nishida wrote: > I also agree. I believe it won't affect our consensus on the draft as > it is a small additional tip. > Although the doc already has been requested for publication several > days ago, I prefer adding it to the draft if there's no problem for > the procedure. > I hope we still have a little time before IESG starts reviewing it. > > Thanks, > -- > Yoshi > > > > On Fri, Sep 15, 2017 at 12:44 AM, Michael Welzl > wrote: > > Hi, > > > > I give a +1 to this request: I remember searching an answer to the same > > question, long (actually a few years) ago - I looked at the (old) > I-D, found > > nothing, and gave up after a bit of Linux code reading, at that time. > > > > I should have remembered to request this being added when the Cubic > draft > > was picked up again - indeed this is an important thing to add, IMO. > > > > Cheers, > > Michael > > > > > > > > On Sep 15, 2017, at 8:57 AM, Le Boudec Jean-Yves > > > wrote: > > > > Dear Lisong > > > > thanks for the pointer. Shouldn't that be also described in the ID ? > > > > Best, JY > > > > > > On 14.09.2017 20:10, Lisong Xu wrote: > > > > Dear Jean-Yves, > > > > Yes, if the first slow start ends with no loss, Cubic enters congestion > > avoidance. In this case, both K (i.e., bic_K) and W_max (i.e., > > bic_last_max_cwnd) are still their initial values (i.e., 0), and the > origin > > of the cubic function (i.e.,bic_origin_point) is set to the current > > congestion window size (i.e., cwnd). In addition, in this case, Cubic > > maintains a minimum cwnd increase speed of 5% per RTT (line 308-309 at > > > http://elixir.free-electrons.com/linux/latest/source/net/ipv4/tcp_cubic.c > ). > > > > Thanks > > Lisong > > > > On 9/14/2017 11:23 AM, Le Boudec Jean-Yves wrote: > > > > Hi, > > > > in draft-ietf-tcpm-cubic-05, I see that slow start is assumed, but I > did not > > find what Cubic does if slow start ends with no loss. I guess congestion > > avoidance is entered, but then how does Cubic computes W_max and K when > > congestion avoidance is entered following slow start with no loss ? > It seems > > reasonable to have K=0 and W_max set to a very large value, right ?  > Did I > > miss anything ? > > > > JY > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------3FACE7D001176620C64364C1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thank you all. We will add it to the draft in one or two days.

Thanks

Lisong


On 9/15/2017 4:26 AM, Yoshifumi Nishida wrote:
I also agree. I believe it won't affect our consensus on the draft as it is a small additional tip.
Although the doc already has been requested for publication several days ago, I prefer adding it to the draft if there's no problem for the procedure. 
I hope we still have a little time before IESG starts reviewing it.

Thanks,
--
Yoshi



On Fri, Sep 15, 2017 at 12:44 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
> Hi,
>
> I give a +1 to this request: I remember searching an answer to the same
> question, long (actually a few years) ago - I looked at the (old) I-D, found
> nothing, and gave up after a bit of Linux code reading, at that time.
>
> I should have remembered to request this being added when the Cubic draft
> was picked up again - indeed this is an important thing to add, IMO.
>
> Cheers,
> Michael
>
>
>
> On Sep 15, 2017, at 8:57 AM, Le Boudec Jean-Yves
> <jean-yves.leboudec@epfl.ch> wrote:
>
> Dear Lisong
>
> thanks for the pointer. Shouldn't that be also described in the ID ?
>
> Best, JY
>
>
> On 14.09.2017 20:10, Lisong Xu wrote:
>
> Dear Jean-Yves,
>
> Yes, if the first slow start ends with no loss, Cubic enters congestion
> avoidance. In this case, both K (i.e., bic_K) and W_max (i.e.,
> bic_last_max_cwnd) are still their initial values (i.e., 0), and the origin
> of the cubic function (i.e.,bic_origin_point) is set to the current
> congestion window size (i.e., cwnd). In addition, in this case, Cubic
> maintains a minimum cwnd increase speed of 5% per RTT (line 308-309 at
> http://elixir.free-electrons.com/linux/latest/source/net/ipv4/tcp_cubic.c).
>
> Thanks
> Lisong
>
> On 9/14/2017 11:23 AM, Le Boudec Jean-Yves wrote:
>
> Hi,
>
> in draft-ietf-tcpm-cubic-05, I see that slow start is assumed, but I did not
> find what Cubic does if slow start ends with no loss. I guess congestion
> avoidance is entered, but then how does Cubic computes W_max and K when
> congestion avoidance is entered following slow start with no loss ? It seems
> reasonable to have K=0 and W_max set to a very large value, right ?  Did I
> miss anything ?
>
> JY
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>



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

--------------3FACE7D001176620C64364C1-- From nobody Fri Sep 15 10:46:43 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5994C133039; Fri, 15 Sep 2017 10:46:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , tcpm@ietf.org, Michael Scharf , michael.scharf@nokia.com, draft-ietf-tcpm-dctcp@ietf.org, ietf@kuehlewind.net, rfc-editor@rfc-editor.org, tcpm-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <150549759536.2346.14388327891906408427.idtracker@ietfa.amsl.com> Date: Fri, 15 Sep 2017 10:46:35 -0700 Archived-At: Subject: [tcpm] Document Action: 'Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters' to Informational RFC (draft-ietf-tcpm-dctcp-10.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:46:35 -0000 The IESG has approved the following document: - 'Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters' (draft-ietf-tcpm-dctcp-10.txt) as Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ Technical Summary This informational memo describes Datacenter TCP (DCTCP). DCTCP is an improvement to TCP congestion control for datacenter traffic that uses Explicit Congestion Notification (ECN). DCTCP as described in this draft is applicable to deployments in controlled environments like datacenters, but it must not be deployed over the public Internet without additional measures. The document is published to document an implementation in the Microsoft Windows Server 2012 operating system. The Linux and FreeBSD operating systems have also implemented support for DCTCP. Working Group Summary The TCPM working group has reviewed the document regarding clarity and comprehensiveness of the protocol specification, e.g. in corner cases. The document has been discussed multiple times in the working group without any major controversy. During the working group last call there have been several detailed reviews, and those comments have been addressed in the most recent version. All in all, there is very strong consensus in the TCPM working group that this document should be published. Document Quality The document describes DCTCP as implemented in Microsoft Windows Server 2012. Since the publication of the first versions of the document, the Linux and FreeBSD operating systems have also implemented support for DCTCP. The specification should also enable implementation in other TCP stacks. The objective of this informational memo is to document an alternative TCP congestion control algorithm that is known to be widely deployed. It is consensus in the TCPM working group that a DCTCP standard would require further work. A precise documentation of running code enables follow-up experimental or standards track RFCs. Personnel The document shepherd is Michael Scharf . The responsible Area Director is Mirja Kuehlewind . From nobody Sat Sep 16 11:54:17 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A121713305A for ; Sat, 16 Sep 2017 11:54:15 -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=ham 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 yFTcZCzITv9P for ; Sat, 16 Sep 2017 11:54:13 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 559F91326F3 for ; Sat, 16 Sep 2017 11:54:13 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id f15so4644895qtf.7 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=DbJl7LIjo01P2/fbop7T0D6+sS54eSU9AorvPnj1rJ5Tsk7YmvHeTUZvPeQNxxO282 oGWLMuWsyvVjnHoDeV6Y9Zz4dFckES0pBe301Pvnc0d+0SMZe/ZuQ+P/My9fwuZ4iVpj oxGK9l0nWj/hP3L3QLo85XtXWarj3jFu7/nSyKq7CFOHHMrYKR0myKjIjQTQeLs7fmby //oVTLOYe2hGthYrYgkwuut8nJdMjjyPZNZFCuSA+lQkXt0VVsnK2rKOt5VscL0UdjmA O/fxMhANvO8G/eIYFWk4TtePb3AfOh3bEWf3Ce4btaYpVKslS9M4A8NsS5FofWs77MSg ENuw== X-Gm-Message-State: AHPjjUhwOXcvRiwHRkxKfKfixqmSRUJByjDlFnG6Qp7vPkIK0gr9WJAr 1onZX47O8k712dOX2/yQqnN3zrW8i4kjKj0fZhqzXg== 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: 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: Subject: Re: [tcpm] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2017 18:54:15 -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:25:06 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@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 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: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group 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 18:18:30 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0261321A1; Sun, 17 Sep 2017 18:18:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150569750307.729.17924524531580620840@ietfa.amsl.com> Date: Sun, 17 Sep 2017 18:18:23 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-cubic-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 01:18:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : CUBIC for Fast Long-Distance Networks Authors : Injong Rhee Lisong Xu Sangtae Ha Alexander Zimmermann Lars Eggert Richard Scheffenegger Filename : draft-ietf-tcpm-cubic-06.txt Pages : 17 Date : 2017-09-17 Abstract: CUBIC is an extension to the current TCP standards. The protocol differs from the current TCP standards only in the congestion window adjustment function in the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long distance networks. CUBIC and its predecessor algorithm have been adopted as default by Linux and have been used for many years. This document provides a specification of CUBIC to enable third party implementation and to solicit the community feedback through experimentation on the performance of CUBIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-cubic-06 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-cubic-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-cubic-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 17 18:32:31 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E90132EA7; Sun, 17 Sep 2017 18:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uofnelincoln.onmicrosoft.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 99AGpvQr-Jcr; Sun, 17 Sep 2017 18:32:27 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0120.outbound.protection.outlook.com [207.46.163.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596F912426E; Sun, 17 Sep 2017 18:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uofnelincoln.onmicrosoft.com; s=selector1-unl-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/gLl1EEqRzWsz4hriZkytH3AFe43Nnj1vw5RksrKmTA=; b=qp9U/f89kF2s1+Zmlt4JNfIe0z4o+5Dg2bsBzADqCGZLpNJGF4vRxlxlymDn9BNx4UpFxOJaqMT6AVL2pQqF/Lwb5g7anqEYuY1jvxvvLzOOcaWz6RdrqtZ8+2PYKjBHQM76Ut7hPQszpOo02MVnRhHhLImlY7956i5WR99DIO8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=xu@unl.edu; Received: from [192.168.0.21] (97.98.140.59) by MWHPR08MB2766.namprd08.prod.outlook.com (10.173.239.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.11; Mon, 18 Sep 2017 01:32:25 +0000 To: tcpm@ietf.org, draft-ietf-tcpm-cubic@ietf.org Cc: tcpm-chairs@ietf.org, nishida@sfc.wide.ad.jp, jean-yves.leboudec@epfl.ch, michawe@ifi.uio.no From: Lisong Xu Organization: University of Nebraska-Lincoln Message-ID: Date: Sun, 17 Sep 2017 20:32:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [97.98.140.59] X-ClientProxiedBy: DM5PR15CA0036.namprd15.prod.outlook.com (10.174.245.150) To MWHPR08MB2766.namprd08.prod.outlook.com (10.173.239.8) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d3e3a5d9-6545-4c5a-0f3c-08d4fe351e0f X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR08MB2766; X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2766; 3:3JdtEH5eExiKIJuASXGfqLomwRhewIASFAGt2VY/wYgnFQXSNB7+5tDSSHOx2ydeBSHK+G/ocMIHuZoeat1VNl3BXziKh/tnbwdgO21whcbV1svSIA34/GnIMlBYi6CO18Dbzq4TP5wEJTCVTpDQG2YL452TvgMBlZDoaKvVvzs2nSvhdZoyLgUThzvW5OoMQt9YOfLUVjlYMELRYT4OAzgc0tidHLpEehfX1Gmpn6Igf1CdR8fBRzYqmCkZICTm; 25:cqX9VSZ0DQqogqeH1RpF1fAtG3i4qWQKzWl3xcVKaMbGMaAKSvZt1FeG+Gia7ynpEz3GCZGbYavgatnbVYWFYKMwnFFaJSkJSskF9oeWRnfKyBms6/0kX2+tqlknH/5GnQAJmQgnnNQxcGgFb6s5VR6n/8z3uOTO2v+OhDFY9wKesbtuZr9v/1GMM4MbLXFWx+a2SIl7C/CatLTtkjhUzNCVt9zJE5fzxPAU9GBDdjOe1DAUH0g90X+ILA/eKhP7b+RT2GAw4ObnEnKvEBLr3wKkVxewgaXTvZ1B//ikaiaOpfhtbwfrIiM8bGXGKpJrKnJWXbDRA466YZy5udpQjA==; 31:b539MbH5fLpN0pGzaaY8gshoKsodIJr3W+NbWJOrO0nq518QP85oXShOQ//I0ICUhKWumy7UJ5fgTthqOKR5Hw1IogOSPwmWisc4evXOZykU/oAJETvFjHC9VEkzn1p5FMBdB7NWYzEOr/EgF+4JBWgeaAcnYHWe/UiFhu/JGuQ3LatS5gehZF2xJJQlVtosdDRtWdNf8T5HEcaDMKfTspCO16eveKql0+CwkLfE4WA= X-MS-TrafficTypeDiagnostic: MWHPR08MB2766: X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2766; 20:aaTx+YQl8+WtxY1OWiFZPTh8GLDB1b3VYajVlUwBASe9QKjkIv5P7EJ4DGVsVkDodyoMRnjdP00R8fub6vIkdWlgA/j7Ebcd48iYQiJTtvq+ZdpSYnNMS53KPUpYMMmd0eeDrH3Yu+yeiluBHtuIfbwx6haCpOo5BHtyaodnxJ0bcpdqf1d0NJ4xRV/urZ9a09kwyNSREc++8bcRClh1PCucCqxbU6Y4+IBNkGpPOfoR2VBpPZPgodXc0DLPKu+OjdNl+Xrp6jn6jnyKuHkI7bu4XOvD1HN1g+ci8zzLsjONLkNK5Kt3fMobfGYKkPIqiRfSOfBhj2rFmIXTbp0TE2e28L5ROE+mgtF6K1eB98KUpQXrfdahjcoMjDmZ5wS4d4QoAQcFdwaw+QJ7/9PXC+wCm8SJmcicOkONAgWt/e4Zmk7TJR2CN2V27xmSfF/EDYoi8MQrJ9GZU65owE4SnbOIG3fxC1XhMZwb+p8zckOKSCCp1VnQ/E0oqTYzRP2U; 4:QdHR4vKYiCdaDzrIXGhlI++RPa0gWyFV7+SDklnCDxmN6wCJVA7tXvlX5hLx9C1M8vkp6elaYtl0fKd3m2MP/d4XbdmI0HkOvOLuwCkPByrvJe7PDnyq1jBc6FvlH6R++zTDoEeSwygU4OjgyAQT5sV2eyGtsDYfrm/vL16HGKZ2E8/z33Bnr5gN5FHqPT/mKXhSLWRaKTSxEk3KYF3hDHBbLltkxAElHthEwgjADXynoTWgVR4bBThgfPwYlE+VN9NVTYqBlxaKaiBDWAktUgjQedbS5p9w8/GUBXy4iAE= X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR08MB2766; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR08MB2766; X-Forefront-PRVS: 04347F8039 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(346002)(376002)(199003)(189002)(45984002)(65826007)(7736002)(81166006)(81156014)(2906002)(8676002)(31696002)(5660300001)(6666003)(6306002)(88552002)(54356999)(36756003)(110136004)(50986999)(305945005)(4326008)(33646002)(966005)(101416001)(23676002)(31686004)(66066001)(65806001)(47776003)(68736007)(105586002)(478600001)(8936002)(65956001)(53936002)(106356001)(50466002)(316002)(786003)(16526017)(16576012)(83506001)(64126003)(97736004)(6486002)(90366009)(430100004)(3260700006)(189998001)(58126008)(25786009)(77096006)(86362001)(75432002)(230700001)(117156002)(6116002)(3846002); DIR:OUT; SFP:1501; SCL:1; SRVR:MWHPR08MB2766; H:[192.168.0.21]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: unl.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjA4TUIyNzY2OzIzOnZBbTFBbC9Pay9JYVR2eUMwMnNyLzFqTGo4?= =?utf-8?B?MC8zdGdyYVNpSlFFN1JXcFdjNEZETmtqK2ZIQ2ozUUdMOEhuamUwdGdSQkdo?= =?utf-8?B?V2U4V1NoUkFFdGZaWDNlN0dMcXBhV3hjaGtRNVNidmNwNlRJZ3FMWmdmeWU2?= =?utf-8?B?Ty9tK3QvMEpldzRSN09NVXZKMHZPc28wK1RQbDg5TXJFUHptVVQvRTFOVCtG?= =?utf-8?B?Q1dzOUdBYUYzWG1jam0wVHA1QUJDdDFPOGZ6aitwLzlFUVV4Tk0ySjlmNmFY?= =?utf-8?B?ZkJtSnArTk0vcnlWRlVkSm42Q3hMWG4rSGdqcS8vUlBCTy9heUxkbDZtVmMw?= =?utf-8?B?WmU0blZNZlRRQ0JUTWRYV0x1OWw2SDAwT1krbE1Bc3ZSTGNsWjZKZFN2NXV4?= =?utf-8?B?RWZhSlJTaXJuVklobC90clc5a2pScXV3UXlnMWFodmxhRlRUOTFqdGF0ZnNa?= =?utf-8?B?dXNpODZpQXhTRE9ib1h4dDl4OFJwamFWb0lBOUp2UXczeVJXSThPN1RhbDBH?= =?utf-8?B?cDR4Z05VR3BRdm9CMEUzZ2hHQ1JlZWVBdXVaUTlsUG9EQ2pPMmVMdjlCeWNi?= =?utf-8?B?U3Jla2tEZldaY05Tc2RQU3M0Sk5yc3paTHJ5TVJ6OTExS1h5MjZHZlUxMUpP?= =?utf-8?B?MnliK3VVNGtOTE1PNjEyanphTFlrOU1yZVo4MXZsU21DQzEva0ZuS2o3b2Fi?= =?utf-8?B?anR2eVpvVG9NTHd3N2ZTNmxRWCtNT1JCZnlzamJ3TWkrS2FUWHp5T0tuNFBy?= =?utf-8?B?SWwvMkJRYVY4ejhBYXVvaW9qcDBYK01MODhYR3Q4RndPRHlTZ2huMXNVelFW?= =?utf-8?B?d3VLSkoyd3VONVB6ZXl0dWVSalJWRlZVZldyQ0Y1UzAwVDcvcGRVclVvK1hh?= =?utf-8?B?N1pQV0UwVDEzZ2g2Tkx2ekRYb1I5d2UzNmNBSW4ycC9lUFJUT1o2dFpoT0o4?= =?utf-8?B?TCtoMWxqNWxyWmFlaktPaktOTllNUEJyLy9EUkZpajFiR1k3TnM2OWwvKzJ2?= =?utf-8?B?MjBNSThHQzk1TlNpL2ZhT2YzNHc3OXZEejNZdy8zYzZhWi9jWXZockoxa3Jq?= =?utf-8?B?dkRRVUR0eGhteVVSNEUrSlZDSnA2ODdrZFhXbkEydWdLaEpHaDdVWjJwWUpk?= =?utf-8?B?N1dZZEJkRFpyTDZNaTd2RW94OXFBWHptM3FoVFQvK0lPcmFVSlptOS9EK2VL?= =?utf-8?B?clVVTzd1M04xYk8yNkdSYlovZG01VEFuZVdFc0V0U25iencvOWJGQnFzcDVq?= =?utf-8?B?ZzZ0Vll1dHJQcHcvWm9ncEhURm41bXV6MXlqVXlwR1plNy9jWjNkREt2VDRO?= =?utf-8?B?V2xmYWJWbGJLYUVCTkFYVGR0eFBtaTVGYm5WZkFaQjhoUjJBR2I4ZkVQNnBo?= =?utf-8?B?c0FIOUFqRWFXd2QzTEJ6Q2FyQWNaOUFQa3RkY1Nha3ZrOFhnb2tSciswYTkx?= =?utf-8?B?SEFielQzMnFSbGF3SXFUN3BCVjJRV0RYQUdnRm9YWmNycklPZzdJRklyR2xw?= =?utf-8?B?TlFhTWJHRHZSZi80cjE5aTF6YVV5Z2dpMlpidGhITHVjZ1p5MW9WT1hoZE1L?= =?utf-8?B?Y0lTbkVocXYvd2VYdXVmbDJvY1Z0cVgyM3dSTHZHSVA1NGFNcUdPcUYyM2Yz?= =?utf-8?B?Tmd0ck1OYnEyUm5aZnV6bXljdFBVSDZwc1J3dTBHTUZmUzErcFQ0aDFQVktX?= =?utf-8?B?QnlxYnVSMzBDRS93ZXlzdmtCd0p3bnBVT1VneXU1clg0UGl6SlZhQXM3Nzdy?= =?utf-8?B?R1hidkJlcHBwN0lqU0ZiYVo5OE16N2t2S3B4b3dFWHVXMmxUc01JTHlqYWxS?= =?utf-8?B?RkNHb1FMeEpYWk9WTmNhdDBNSmxkSXkxZDJ5VUkzZkw3c1RkbmxnSTdNa1dG?= =?utf-8?Q?E1R4Yj/RLCi1KnmA0O2oJ9czkm/RqJIY?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR08MB2766; 6:LSERrY5Rsu+LBv5J8dMCcbBMpuNU6WUkyq4o/Fms05yjIUXs0ezuXynEO+dahDRMAycEyIptQWLOJphXl5CLHcSqfHnjoGtqhpPKyqq+j7Ab6TjUISi3t3fvd+pJiwwMHhudJ40gtnBbRkqYZcvWTcucv1TI8N+BZqeS7k+uY21tV1GXKeqk6h/YsVtPxNPYIojOWoQRjGL8wDERVUH/PFRP3WCBLoBR86Rv8Cootq8hWnsSqpb5zBvNVHwaq1lDeYjmY7dRtp5aXNwHgg4FzQEOY1h0gJaMo0+B/3z8mty2R5wDQL7vhhMYbJ/aGdNvOu0B1nzbJjne/syhTpJhLQ==; 5:Zkhqx2BB3qYtQUrsvVKaMsVj1xf4Nc+85MVNxeQmktzhLQg1Mw0leL2m2nvEKCaVYBXO7mLVlVtHlAoeMMtq0+LHVl55h1kNoKqAU7djoWZh32J0Grx6tHa1ocst9R3A4h5lTo1isORF/IZGoJVfAg==; 24:IvDZzNTB7UqtGvrvFGGJVlq+X0wg159huialWIbmj1fpfayGhZ4hDMcggBq/ghTP85RbE0SKuwqvNARvOj1lw1x76XPRTK7adBKhK7DHzh8=; 7:fORru1x2WAsUTh03tND0PABo51lQG/XqRsuEGTY3BzJsfHTQ880ER1V1o4yOsKYFGaJJ2oAoPTl9k95aMwO4C/kWPYZkqcYNXe6coEHn/4AScJ29vgn9Hmq/n7GC2Q1+evET71T7zoI0RkZaxufUp3a1wBpyrsSPq+H73C0mSxQI+5FR5C29cuIrMUEUXU8l9fwBWm2h7W2rdue54VIyrcwc/8kqy6MyaqnrPOynMEk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: unl.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2017 01:32:25.0545 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: fddb01ad-4983-436e-ab35-1af043b818c9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2766 Archived-At: Subject: [tcpm] A new Internet draft for TCP Cubic - Version 06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 01:32:29 -0000 Greetings, We just submitted a new Internet draft (Version 06) for TCP CUBIC, which is available at the following link https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ In this version, we made the following changes based on the comments of Jean-Yves Le Boudec, Michael Welzl, and Yoshifumi Nishida in September 2017. Thank you very much for all your comments! * Section 4.2: Revised to more clearly describe the TCP-friendly region of CUBIC, and to be consistent with the Linux implementation of CUBIC. * Section 4.8: Revised to describe the behavior of CUBIC in the special case when the hybrid slow start ends without incurring any packet loss. Thank you! Lisong From nobody Sun Sep 17 19:05:36 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539E912EC30 for ; Sun, 17 Sep 2017 19:05:20 -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 l5spQwuFV1E2 for ; Sun, 17 Sep 2017 19:05:19 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 5574113219F for ; Sun, 17 Sep 2017 19:05:16 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id b23so6078348qkg.1 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=OGhk4ibcWWeKRzI2nMu2WHWfMQqxUF620wXDJFOrtumnF6+afwttRiC+5bZL0yP1nD CCFObJAsn71hDFAlAZ1zSdkvDgZb4DK23WcvzSAjzwKU0qRU8FucP/CKFmO8iBHYgrVX 3IJ6jEmw1VMUaCU6oGlUjjXe3qD42l6QqSbftCMemxFmhaEtIlVWfuLrrTDjNgXQKA6C U3hXO+1katRzT6Slfsu1JzMbG5JA+c0Tf2iDT9sCe7CsjfiVhpH+Wd+aM99ogO6R+Hab Pey5v2vW1b2H+NtqG/beBGB9FRh97PvLK30BHpwXF0JKTqRG5NE7lerv5QUi2Zp53O75 l1sg== X-Gm-Message-State: AHPjjUhyUIOjV0NW4hg7kh0HVju31WveRgZ6LkVGmMLZ7juE6Xms2nNB PYf2lQV+dM42+1D1pPcyjvEBoeydXTGiFl0FItALrw== 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: 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: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 02:05:20 -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:39 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@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 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: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group 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:49 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@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 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: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group 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 06:59:58 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8195E13217D; Mon, 18 Sep 2017 06:59:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk CC: tcpm@ietf.org, nishida@sfc.wide.ad.jp, ietf@kuehlewind.net, Yoshifumi Nishida , draft-ietf-tcpm-cubic@ietf.org, tcpm-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150574319148.15632.13575896531948320480.idtracker@ietfa.amsl.com> Date: Mon, 18 Sep 2017 06:59:51 -0700 Archived-At: Subject: [tcpm] Last Call: (CUBIC for Fast Long-Distance Networks) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 13:59:52 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'CUBIC for Fast Long-Distance Networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-10-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract CUBIC is an extension to the current TCP standards. The protocol differs from the current TCP standards only in the congestion window adjustment function in the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long distance networks. CUBIC and its predecessor algorithm have been adopted as default by Linux and have been used for many years. This document provides a specification of CUBIC to enable third party implementation and to solicit the community feedback through experimentation on the performance of CUBIC. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Sep 18 09:22:23 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885D8133018 for ; Mon, 18 Sep 2017 09:22:22 -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=ham 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 conYibOxR2fE for ; Mon, 18 Sep 2017 09:22:20 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 2DF12132F2C for ; Mon, 18 Sep 2017 09:22:20 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id x54so1080851qth.12 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=ldpdWhNt2jUHNr/EKyDqPgAEM2YTUEI7vWWiIGlB6tg2VsP80xNOnYj1DakBoGOBq6 e44CJEPPr/IRLfAQ6l4cGd5R5NfEdp+o1AaQ1si+5mqJEX9raumeg+bqoY/aoXAhSgKa BSjin+DNk8AHyMHj/jD1THR8Z42KBa8UO4QheOy3kNX9SKQISmpTomPI7vTChdx8NplD y1Op3/ZBU8/7ynozGLGgDEcmovW2Xd+M8bpDitnriwOh2rkmxAOoK+vxTJdek3ad7kL+ qgQ969/f+rfcJBr+VdB5P7zQ5Kp0/dbseUXShfI6injytOlXm3IHpZGTKz5U58+stLHI rl1g== X-Gm-Message-State: AHPjjUgZFzaS32s6VOdgS6XXZESv94kJlVN6TQuxnOnNSJsDjcOu+vO+ xSh7Pr1gFACizJfZTcF/7SoFzITD70f63+D+QU5Sjw== 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: 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: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 16:22:22 -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:26 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@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 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: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group 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:36 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CCC133209 for ; Mon, 18 Sep 2017 11:51:33 -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=ham 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 X_tKnMz58nbE for ; Mon, 18 Sep 2017 11:51:32 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 4591C1241F3 for ; Mon, 18 Sep 2017 11:51:32 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id b23so1489317qkg.1 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=YBvoGXNOPwW7EhPE2A2xEheMK4LTzYG2gXdHkifEECWIcU9iY4SuMU6sG0wTOCxrl1 JpHH/htVQaVHQlrvpfDHeSglziQowgwOjsba+GWjLhyZobcV+lhOtdUVDC+RaUoXXMID Z6kgFKDJvQcLjd/P3ABPKg4sQ+c29I4qEMZvcJbYmDsDCZaufpplZ8kDbiptT98/oaDx jUGPQd+u+QCbd+1JxCNooGjf+mKECaaZEJZuoFqkuxfmChq+iknHjcntwnqvLbOfC8wN 016Xy5L+RTbOA4d5wLzggApWIqj9xdLfuXLgez2NkOwEDS7zZh04n4BKlf0a76GLW1Qi 2wMw== X-Gm-Message-State: AHPjjUiSinj2yNDpiQwfBB4ynABp7jZJqPW+7aXzbOpaoaW0LdZobEqb +ECVXC0V0P9FXrAp+y/4osI5uv+fZNr/crJF3d+wCw== 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: 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: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group 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:07 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@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: To: Tom Herbert Cc: Olivier Bonaventure , multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org Content-Type: multipart/alternative; boundary="94eb2c18f38486119605597c453a" Archived-At: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group 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:51 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28D9132076 for ; Mon, 18 Sep 2017 13:43:49 -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=ham 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 r12bM3NDXNrr for ; Mon, 18 Sep 2017 13:43:48 -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 4FFB4132F65 for ; Mon, 18 Sep 2017 13:43:48 -0700 (PDT) Received: by mail-qt0-x244.google.com with SMTP id t46so1127949qtj.3 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=Gkqv2y/ex/EQQsE9Yuw10E5XsjlTZv4Ww20thVqQOpFfo8OoeuDnnuooo960K5TddJ FHkn1jHaZohEcnlZKFpt9b6lLhGg7ep3CNA7BNj1E3kgG5wbLhe2ibMXxDyGEsBC7Wj0 /raNHVVbivo+NjybeBJeTDkBD94am/KGNlMpAYwCQCPvVN99a8tI04S3Yjg98svMMqbS 4po9547H5h4umj+NLwr3Dkk0NR6IjiResf2Au0cGtBwk2d02NK0adFWzZnj0l7G+FQ4K am12/rn3/S+3ACLWTJF6vY1Vn1Ur1OKCYBGp7CJyzMTJx6IGfItcbj9fZerdF1M5uHCN xIkA== X-Gm-Message-State: AHPjjUjuiS/4LO/+WZc4+WnpLeDjRyBzn/usO+NFO0b9U6RzGAW7lRen hSJue60mhBqY1+FRFJ2GPx/Mp3rBg1GcPYP1jwgZ9Q== 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: To: Yoshifumi Nishida Cc: Olivier Bonaventure , multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 20:43:50 -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:16:55 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@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 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: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group 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:13 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@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: To: Tom Herbert Cc: Yoshifumi Nishida , Olivier Bonaventure , multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org Content-Type: multipart/alternative; boundary="001a113ab0f2cb0592055980ecff" Archived-At: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group 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 00:45:23 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FED613320B; Tue, 19 Sep 2017 00:45:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150580711238.11732.7468167141205766204@ietfa.amsl.com> Date: Tue, 19 Sep 2017 00:45:12 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-generalized-ecn-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 07:45:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets Authors : Marcelo Bagnulo Bob Briscoe Filename : draft-ietf-tcpm-generalized-ecn-00.txt Pages : 33 Date : 2017-09-18 Abstract: This document describes an experimental modification to ECN when used with TCP. It allows the use of ECN on the following TCP packets: SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-00 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 19 09:16:46 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@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 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: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group 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:27 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5081342AC for ; Tue, 19 Sep 2017 10:32:26 -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=ham 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 Tc5YtE69_qsr for ; Tue, 19 Sep 2017 10:32:25 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 ED43D134299 for ; Tue, 19 Sep 2017 10:32:24 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id u7so321954qku.13 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=SKsvUgCXtVf2QewmcFNZTsB/ItPlexWnUErVA9k8qG5whyWAWPxWVGg9loIcvwYySP 82M5zWWdYLYn1V6+sBAZbV+Pu/zfumZu2vW0DAfAnqLVmrvtIE121juGTqW8ntyHUH6L 6/r1XkHm9qoDyx6CpI8/x32W51Y2OfRZIRJLDY4cCia8mipgCXuR66ZfeeCOZpL+4j2X 2d9c6UR+U/mT+Wqp7oukxhZFKOp3bUF27qFF69+5I4+yQyK7avTEXC1mtFm9gdK1LWXq 5onTthTipWdvyAShQab3rce6gZJorvtoKHxIIeLOJXHrGLcytd12klJluuy+yVy986hh ApMw== X-Gm-Message-State: AHPjjUj6HoBxCAbvUBmdovf+DDGAGgQse8+96AytwD3r4mNL6F+V0YeR ws2ziaDx/nMthddv6A7no2bZTT715aR1FYwJeRTzOw== 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: To: Yoshifumi Nishida Cc: Olivier Bonaventure , multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 17:32:26 -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 > > From nobody Fri Sep 22 12:01:38 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED811345AB; Fri, 22 Sep 2017 12:01:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: tcpm@ietf.org, ietf@ietf.org, draft-ietf-tcpm-cubic.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150610688453.16831.3652838434219802004@ietfa.amsl.com> Date: Fri, 22 Sep 2017 12:01:24 -0700 Archived-At: Subject: [tcpm] Genart last call review of draft-ietf-tcpm-cubic-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 19:01:25 -0000 Reviewer: Joel Halpern Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tcpm-cubic-06 Reviewer: Joel Halpern Review Date: 2017-09-22 IETF LC End Date: 2017-10-02 IESG Telechat date: 2017-10-12 Summary: This Document is ready for publication as an Informational RFC. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Tue Sep 26 07:15:24 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56170120724; Tue, 26 Sep 2017 07:15:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Sean Turner To: Cc: tcpm@ietf.org, ietf@ietf.org, draft-ietf-tcpm-cubic.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150643532230.20822.2899916825960257300@ietfa.amsl.com> Date: Tue, 26 Sep 2017 07:15:22 -0700 Archived-At: Subject: [tcpm] Secdir last call review of draft-ietf-tcpm-cubic-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 14:15:22 -0000 Reviewer: Sean Turner Review result: Has Nits Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies a TCP congestion control algorithm. It uses a cubic function instead of linear window increase function. It is the default function for Linux. It's ready with nits - basically a couple of more words the security considerations and maybe a reference or two and you’re done. Note: I know next to nothing about congestion control functions so I'm going to trust the function is properly specified and reflects what's actually implemented. The security considerations were a little bit terse. So here's a couple of questions that came to mind while searching around for where to refer: 1. I get that since CUBIC just changes the congestion window adjustment function on the sender side that it makes "no changes" to the underlying security of TCP. But, I kinda had to guess where the underlying security of TCP are documented - so how about adding "[RFC5681]" to end the sentence assuming that's where the security considerations for TCP are documented. 2. I think the answer is yes here, but wanted to check: In RFC5681's security considerations, there's some text about how to deal with the "ACK division attack" by: ... increasing the congestion window based on the number of bytes newly acknowledged in each arriving ACK rather than by a particular constant on each arriving ACK (as outlined in section 3.1). CUBIC has protections against this attack because it MUST support slowstart? Like I said, I think it's yes because s3.1 in RFC5681 is all about slowstart. WRT s5.1: In (quickly) reviewing SACK it refers to RFC5961 (aka dealing with the blind in-window attack), does CUBIC protect against this attack? If it does or doesn't it might be worth an informative reference to RFC5961 in s5.1 because it was published after RFC5681. From nobody Tue Sep 26 11:19:46 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C92C1342EE for ; Tue, 26 Sep 2017 11:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 ISC66NA5AHKn for ; Tue, 26 Sep 2017 11:19:42 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EEEF1342D1 for ; Tue, 26 Sep 2017 11:19:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=MjHBUPQGjD7n3yZ92wnkae51tWryUGHMhlxuGCkCEYKQ6iJIT5Qzcnr1hgj5Jy0M1kmCNObLjsvtGL9+9h0dqMIfyVGJoRdichuwXYwPPnbC+WDKoTx99KTPzIVhoU7b+5yzK24T8HpIFVUslNWdMoOlf25o/Dtndp2k9n4AM84=; h=Received:Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 8078 invoked from network); 26 Sep 2017 20:19:39 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 26 Sep 2017 20:19:39 +0200 To: Sean Turner , secdir@ietf.org Cc: tcpm@ietf.org, ietf@ietf.org, draft-ietf-tcpm-cubic.all@ietf.org References: <150643532230.20822.2899916825960257300@ietfa.amsl.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Tue, 26 Sep 2017 20:19:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150643532230.20822.2899916825960257300@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170926181939.8070.26405@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [tcpm] Secdir last call review of draft-ietf-tcpm-cubic-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 18:19:44 -0000 Hi Sean, thanks a lot for your review. These are good thoughts but after all mostly independent of cubic. Basically all that cubic does it that is provides an alternative for equation 3 in RFC5681 while all the rest of RFC5681 still applies and need to be implemented to have a working TCP implementation. Moe specifically also, the ACK division attack is actually not a problem for cubic because it does not use SMSS in any of its equation. In summary, while it probably doesn't hurt to point to the security considerations of RFC5681, I don't think it is absolutely necessary. Mirja On 26.09.2017 16:15, Sean Turner wrote: > Reviewer: Sean Turner > Review result: Has Nits > > Do not be alarmed. I have reviewed this document as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily > for the benefit of the security area directors. Document editors and > WG chairs should treat these comments just like any other last call > comments. > > This document specifies a TCP congestion control algorithm. It > uses a cubic function instead of linear window increase function. > It is the default function for Linux. > > It's ready with nits - basically a couple of more words the security > considerations and maybe a reference or two and you’re done. > > Note: I know next to nothing about congestion control functions > so I'm going to trust the function is properly specified and reflects > what's actually implemented. > > The security considerations were a little bit terse. So here's a couple > of questions that came to mind while searching around for where > to refer: > > 1. I get that since CUBIC just changes the congestion window > adjustment function on the sender side that it makes "no > changes" to the underlying security of TCP. But, I kinda had to > guess where the underlying security of TCP are documented - > so how about adding "[RFC5681]" to end the sentence assuming > that's where the security considerations for TCP are documented. > > 2. I think the answer is yes here, but wanted to check: > In RFC5681's security considerations, there's some text > about how to deal with the "ACK division attack" by: > > ... increasing the congestion window based on the > number of bytes newly acknowledged in each arriving ACK > rather than by a particular constant on each arriving ACK (as > outlined in section 3.1). > > CUBIC has protections against this attack because it MUST > support slowstart? Like I said, I think it's yes because s3.1 in > RFC5681 is all about slowstart. > > WRT s5.1: In (quickly) reviewing SACK it refers to RFC5961 > (aka dealing with the blind in-window attack), does CUBIC > protect against this attack? If it does or doesn't it might be > worth an informative reference to RFC5961 in s5.1 because > it was published after RFC5681. > From nobody Fri Sep 29 04:38:29 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3954E1344EC for ; Fri, 29 Sep 2017 04:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.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 MNK70lRy6NLc for ; Fri, 29 Sep 2017 04:38:24 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 0CD91132C2A for ; Fri, 29 Sep 2017 04:38:24 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id q132so2710714wmd.2 for ; Fri, 29 Sep 2017 04:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=ZBlorS+nr3r78PWR09jaV2os83VLYUQjWU7mIQiRAFQ=; b=uiD854yjwopPMlL1FTQLeREkkvJ+MvwuNnP8X2Bb2agCwiKPVcVL4Ijb2MC7Zm0Xa2 SwM3scpG5Ipd6wVXB6vmnrK5DemGmzOeuWH5PpK8CVQ3QGRAs7I1Y6FfymdkhobI+G3A y1MvGW6faR5MUTNzVGjJ8m54xir6v8AQrqDnTlIlUeCzv3/PXbriDDnLzQ45uDblut9R Q/D4NCgZivxek6fQp4GcTpuQagf9MHIPgzE6g9cWWn79KD0p1vy0ErDmLddXiY8SBsQv VtZnAoi09NhB8wLqNtd+D3Z3wkECV2Ub/TfuiAsORaeG475AUXNg5aeEKagUEChZHXCF m/tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZBlorS+nr3r78PWR09jaV2os83VLYUQjWU7mIQiRAFQ=; b=Axlw0Ox7oywreabtdaUYtrvxKJrSjHQiRsSNwXojWRPg3KixqS0VVovll8nefzEQyd /ssvRn96b25U74K9n9k9wfJ2/zkF8yJWqucDQNTLDWG8hpvONz9izq9NrWCz/NGT8qHZ VYBiuC4dMNbuBZwl+gX7CJQTe5iBuhbTAlQhSALi9vo1glZ+YfRFQw2TzENellRMQL0j mDHyPaSifOkHRPPJNrC07KaCO4z9fVBPuvxgHxSXATCrxZqC8laH2PI629oUSintwbUa 29EMraG/q3Czq5ZwHjbPdGIOQGsnvB+ldgA1NMcCXUkajn/7TAWgZxIGM/HSJltQlvE9 TtGA== X-Gm-Message-State: AMCzsaUJduZ5PiV9T44MXxU8HAXNI7wrEhWe9nqwmtMVV1QFBuUrn6G0 x4PmopYatnMGtuavgLrckGbUJjIH X-Google-Smtp-Source: AOwi7QChJgKGK+ThvNlYJf6LvhkSLcfA922MCRxNtS21BsDOs8Oix6o8MNf3qtApa/wytRpphrOz7Q== X-Received: by 10.28.57.215 with SMTP id g206mr4147407wma.117.1506685102227; Fri, 29 Sep 2017 04:38:22 -0700 (PDT) Received: from Macintosh-6.local ([2001:720:410:1010:d4d7:fa82:69b6:670f]) by smtp.gmail.com with ESMTPSA id z39sm977745wrz.80.2017.09.29.04.38.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Sep 2017 04:38:21 -0700 (PDT) References: <150668301072.14229.5390126824513728458@ietfa.amsl.com> To: tcpm IETF list From: marcelo bagnulo braun X-Forwarded-Message-Id: <150668301072.14229.5390126824513728458@ietfa.amsl.com> Message-ID: <7a3736f8-d58f-b94c-e2cf-3b4d2ce5372a@it.uc3m.es> Date: Fri, 29 Sep 2017 13:38:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <150668301072.14229.5390126824513728458@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-esn-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 11:38:27 -0000 Hi, We submitted a draft exploring the possibility of extending the TCP sequence number using the TS option. The draft considers different design alternatives and proposes some discussion. Comments are appreciated. Regards, marcelo -------- Mensaje reenviado -------- Asunto: I-D Action: draft-bagnulo-tcpm-esn-00.txt Fecha: Fri, 29 Sep 2017 04:03:30 -0700 De: internet-drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TCP ESN: Extended Sequence Numbers for TCP Authors : Marcelo Bagnulo Yoshifumi Nishida Filename : draft-bagnulo-tcpm-esn-00.txt Pages : 10 Date : 2017-09-29 Abstract: This note defines the Extended Sequence Number (ESN) experimental modification to TCP to increase TCP's sequence number using the TimeStamp (TS) option. It also modifies the Window Scale (WS) option to support larger receiver window enable by the extended sequence number space. At this stage, the purpose of this document is to discuss different design choices to generate discussion about the approach to follow. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-esn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-bagnulo-tcpm-esn-00 https://datatracker.ietf.org/doc/html/draft-bagnulo-tcpm-esn-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Sep 29 10:13:54 2017 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E9F132705; Fri, 29 Sep 2017 10:13:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150670523327.14229.14277724730809935274@ietfa.amsl.com> Date: Fri, 29 Sep 2017 10:13:53 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-generalized-ecn-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 17:13:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets Authors : Marcelo Bagnulo Bob Briscoe Filename : draft-ietf-tcpm-generalized-ecn-01.txt Pages : 37 Date : 2017-09-28 Abstract: This document describes an experimental modification to ECN when used with TCP. It allows the use of ECN on the following TCP packets: SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-01 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-generalized-ecn-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 29 10:19:32 2017 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6B0132D44 for ; Fri, 29 Sep 2017 10:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cablelabs.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 UeFqSz6k3uB7 for ; Fri, 29 Sep 2017 10:19:28 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0110.outbound.protection.outlook.com [104.47.41.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B9013207A for ; Fri, 29 Sep 2017 10:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KPQ2P7I7QonujavVpCAjBGUQ7s8N9SM+JuI2MoEtAIo=; b=CqpE6ybdRRma7g7GCZxF3032DmTDStM+SaHisOBjY5Q4nkAVpTrZCs4rXNSc9Ayqilja+QltHy1e+aEiQDtx2pC5elJDiabzQfY3RRvGec6vh1QvD+c6gFf3EHe1okw+SHq0cienWYlNfbBWj1rZNgiaQ0vpdu3Eik9fZhwJ5A4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=B.Briscoe-contractor@cablelabs.com; Received: from [192.168.0.7] (87.114.115.18) by SN4PR0601MB3632.namprd06.prod.outlook.com (2603:10b6:803:4b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 29 Sep 2017 17:19:24 +0000 From: Bob Briscoe To: Padma Bhooma , Gorry Fairhurst Cc: tcpm IETF list Message-ID: <1badf9ba-a030-b92c-dd26-d7ed429b2361@cablelabs.com> Date: Fri, 29 Sep 2017 18:19:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------1BE910D83389015EE6BDB084" Content-Language: en-GB X-Originating-IP: [87.114.115.18] X-ClientProxiedBy: AM4PR07CA0026.eurprd07.prod.outlook.com (2603:10a6:205:1::39) To SN4PR0601MB3632.namprd06.prod.outlook.com (2603:10b6:803:4b::14) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 10481f72-6f7a-454f-17e4-08d5075e3bb2 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:SN4PR0601MB3632; X-Microsoft-Exchange-Diagnostics: 1; SN4PR0601MB3632; 3:CF+DukoTdiO06DrfgVS5FSSNIbtfvknMATIwjdo0p+7iffyKXDEixcalVJ7gNracL2szWPgZnTQDviHhuzVCzrFjyMrx1wvZg26bxC7KFdSouZEFkfC3Yxc914XnsHPFXH+GsW09pFlBNGLmo0p6E/XLleflVOA+KpKJw+9TUl0THu8BozX1RE0G8CoqrSwe7JJ5z5BEVuI3hWgjLCZRKuIN+kOHEfds6kfhv1xWg6+of4Zf/u14HNz37JcDKfmQ; 25:FIfELiIwDIqHKv72Rhk00sr7x9TF1ffmSXXlBu+T/Gn2xJ6cf0awccFPuZnAU4URVIu91CNASLWOq1laC0bFDI+wY5IHooFKTLppIdOwXYBNXnRH5l4s7FvlGWNxLsIkmY3Whf/hyN3kHDgI3/h+F6xYsquXS6ndtafTnH/eY8QjvXUyDcQ/NbgA4s/0kXRpStQn/o89bNyiVbw0sPRc2IVStZTZSuB60+y7yE9arlLk1UpUxgd3k9R6huV9STKL2hCVCahyqXau8JoK2Oe1lZwtAY12rfHKhkQwPn7k+BpVHe40oXm1aLg7YFObi12n82Umtk+UTYK2v+vsV7CxoQ==; 31:RoEaZLayXwJTINP0P0xCdiFI4FyXGItgIUvBE0zD/myDzdR9ajqbALPHjxxdjpkqjQCec5JTuhcswP7AaCv33TO0pb4jgq9ojyy5FL3aVxcbxCxjP20qZG6Y710aNkqGF+1afUxnWYEcm5Hf0s5Gfdyy8tivVNbS/dr4hezKTZF4hUdZ2LUL0RRs/WC7ZaUkO53750nAjcZrdX489Wx/1TQs9rPL6ib9VmMoPAaj5Es= X-MS-TrafficTypeDiagnostic: SN4PR0601MB3632: X-Microsoft-Exchange-Diagnostics: 1; SN4PR0601MB3632; 20:8sn5QuoLDkhrhRO77ndf+BtNasuwSqYYiNruTuKsX9VVn+UCOOEPUKQfFRdy1vcOhk/+Ob7UXUfexYHiNeTZOVg9Ydm27PkphmK9pqQXSI2pfWB//QKgqs/jmy/rr9M19lx4DsnkAxBtV3ZjtQgRks2Ek41MJbFVh6vEA1o/0TRRPdvLzbfCX8lQH1upLKZEqMl4jrwqy1ja7I1JYjWsq5TfddfXA3EfEXTe6VfaRyEdIa9FaG1bOW6SfRjMp5VIYqXGb6jtc4iMk65D+2E/7OgZgbOs0QGWdzHYg08aUSqBx6/gnNUAUDAF+ox819P1TOYfOkR0EiIjzDoipQ8TYQ+9n8fRWyNbEStG8LcWa06XvVFmmCWnnOgrIDN5UpgOrwlldXziX0pepCbdrUdqyEyXQcBh8eMmWzM9sjM8OQsXdVlY9i0AKWOuFo/NJWrzb7JvlNsS8cyFFiGDnmToyP+qtt1Uf6iglBPOUrsde8CvouqSrhvDM7QbIaIEDyGl; 4:bDhbUYkl7hkrMmX8UoZ4nwLo2AQ5YQQE6F3uBCzkwl07s4wKn0Rdsh5wfdu0YDYoQcWOtziB2oc8N6s4sNRf5qCrZFa38cchKmke8XLa0kLHOuVKpL2gOXxfdv4GLtFil5U6H1doyAOcu49gIju1nXKCNEpSNCgRnqchZDdniFfkPzc3U86HnA+xLzA1UjJXhHsfyMrB5LOJRnvtNCQRUMQnxAdoYs57PlxWxxdA01FZJstrmPpwl4FxuF6tXxmFrUVztL4FKxJtTbSfElWZcHAPbbySO08Be0yWzNOcj84= X-Exchange-Antispam-Report-Test: UriScan:(131327999870524); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN4PR0601MB3632; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN4PR0601MB3632; X-Forefront-PRVS: 0445A82F82 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(376002)(346002)(189002)(199003)(33646002)(77096006)(6666003)(106356001)(189998001)(6306002)(8936002)(31686004)(236005)(81166006)(64126003)(8666007)(606006)(117156002)(86362001)(4326008)(230783001)(81156014)(66066001)(53936002)(68736007)(8676002)(31696002)(58126008)(966005)(5660300001)(37036004)(16586007)(65806001)(65826007)(50986999)(105586002)(316002)(16576012)(54896002)(83506001)(110136005)(84326002)(54356999)(72206003)(65956001)(7736002)(6486002)(2906002)(270700001)(3846002)(101416001)(25786009)(97736004)(36756003)(478600001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN4PR0601MB3632; H:[192.168.0.7]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cablelabs.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN4PR0601MB3632; 23:jyIzMyDytM1ylvnqLxSXFnjCNr5Q3tUmkRHE6bu?= =?us-ascii?Q?iJdMXAFsFAXmY7zc2qZU6S4IWhCYevT5KR9daXarQCoLUoT4C2qr7gmN1EBh?= =?us-ascii?Q?rlt+XzDkckggATXScU5MvfRYCEQXqr5+hJtd6O2UAdMVJMpNHczdKwTswwJC?= =?us-ascii?Q?V89wqKAqmEu1Zwb/299jVuMiRBNqp2A5DWUqFATgsDTcxQBuHvhWh5oe4evL?= =?us-ascii?Q?JHTPl1BdjshBswofNmE6lyCx0y/454yPqCG+7TIzL3l28W0OMEJbxjLhCEut?= =?us-ascii?Q?ySffD31/LZn/63cGI359Psv//1t8CDBx5+sCUqROy95baljJB5O/K1klQuCA?= =?us-ascii?Q?nUBfBXv1QzGJMBx9afhtQawbYIYDQlNgn/Hz7zTT9QIHjWYkpOOCCulVv/Jv?= =?us-ascii?Q?g48+a1k3A0/YaIbUYHH//a5BwoZx6K5t9Y9ojOBFX71lvS9vK4637rywj04o?= =?us-ascii?Q?lLLmw+LO4SHUpDOZfVj5wasHZh5p7u0sh1pyjV3kCJ065dihmX0VsCHgmSK6?= =?us-ascii?Q?+DJuYUquunduAxztfjqB4oebOYFpRT8895FmGrSzC0BVuxPuTXC5waQ5dD9C?= =?us-ascii?Q?6fM3dhk8Dd5t6ci4bFlAr93wnPi8V4B2gVhMo3ACH97jm9JJWHpGvcisXPZ5?= =?us-ascii?Q?k4ZtcSo0sACX+mDFjp6u8X7fstWDofWj7E7WfRycLmoMmdKMvzZos+fJQpQI?= =?us-ascii?Q?7fTLljmhwIQ6+P5OAJVSXCVMRJK+Wyhk/TnaMOc9+2oy4uGRUZMxJqlJqgx1?= =?us-ascii?Q?XNw1wWZ/XpQmHTdcWQ/w+wF+YX/6YKBk/uw4U1v1rfyh7OgEJB/zHfk7/x3T?= =?us-ascii?Q?3tgVx3mhpvvqjDLQ+k+HjOUKnQdDzLzVBbfn4aWaemyUZPxNFZahSu604Cxt?= =?us-ascii?Q?eXPB8eTyxUzMhNUE7ZcQZ2JTX4emy3StJNSwyOEE2gyQv39Ko5rPADnyMuis?= =?us-ascii?Q?6MglwZ4f+WoN+FItxutSKj1QQCCaVcIBWuUGiIBBmlR61Uk3oTJongTqoni+?= =?us-ascii?Q?kaM048r8Z3lY+ZJlMCA++cNc09ATaq8n4GNrHu92HPgK0K4OsT5cAFsGjOJH?= =?us-ascii?Q?2DEsuN7nllS1z9iEzYePiodWiP3nexhvhOGgvZSUJlj53ZPEEwt9o3J3rqr8?= =?us-ascii?Q?X/g0gev5YLX5TsOeXwX6Eue4vszUzF3ahiFJhubCzDEFPc9BqHZqNSTYVGIZ?= =?us-ascii?Q?p5SLK/an2A2KMODvjCV3VsoglHLetSYi1lhLVBMgbgtXIf9jcgdGAaLv6Q7z?= =?us-ascii?Q?2qwie7tU72SUnTmo5EalGqds6AnANvIJMZU+ulz6f02SUzP7EG9aJJo/wVFU?= =?us-ascii?Q?DyA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN4PR0601MB3632; 6:1zEUZA4BZH0gnWSSYoNufW7oNB3nv5Vypyy2ALcVlv+C/DWhKCDdTcAive2NOvXbEbTlkpDpiJRbOWs6f7thfg5smMhvnQWFu4GU0Q2qCZWLqiw1djoAvOAB+dflmmp8z+UIw2OOq0hXTM4axODNdmidQu8wImKo+biUCZAXxVvphQPGCGd+7DZAcYW+E9WuELj0wE1042QsxDkGEwPl+FJwxeAtqhITTU4YFmygXcs2tPkIn3IxocaOiQ7X4SiElJFQ/2zixAR1eBMsU0l5MYbjlK5hgn1QCr6sm+YwzW4SJalr9aUr7ns0Fc6gef3JBKi77e5LE8QIFve2MPU4Rg==; 5:gSUzWYZc/Ti0UGkFKAIb3MEzRrKHfNzjkP4+pQOa9D2P+OaRtEU+dSgfvfjPr6Qcx9MpXi5i1p6OCT7o4zQLWhvhKLYES8T3imnLx6WKjoUz35ArpogR/8yuvkBfSx7PVOYSBT3rYf4fRxKjDDg91Fc+Nv8rvTylURoRGbUTyRw=; 24:INqSl/okC/Aza36I+JqnHkOKUk3hyAa7iewcB5+RibF+y5aM3qxX23Wf6JDdUmRrMZY3bapQkGS3spRceANk8CjR9NGVvkNT6J6yH1fqrFM=; 7:Ayj1vw4M5sl67BqX0ZFmbkI+m3iyP5UsKGtFoZWTscX+4q6JAne7CNnYwG6vN8tP5PcY6N7ZzrQqWIN1Cf3ROEaGbaHWHd9MI/XWZN2ct6ZGGK5EBxKItQ7eU1RXlAIFmZIIfemsKhiSqElap17slIuvADC9Iclzx8cvWTvGWfS/fygzP6H3wsDbKW/1YIgJz0JgB6s4+6etcvexHf/NFptVUmIv/gyAnsPfVwG1iCA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cablelabs.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2017 17:19:24.2015 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0601MB3632 Archived-At: Subject: [tcpm] ECN++: addressed your reviews? draft-ietf-tcpm-generalized-ecn-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 17:19:30 -0000 This is a multi-part message in MIME format. --------------1BE910D83389015EE6BDB084 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Padma, Gorry, Now that ECN++ has been adopted as TCPM work, we posted * draft-ietf-tcpm-generalized-ecn-00 (10 days ago) without any changes other than filename. * draft-ietf-tcpm-generalized-ecn-01 (just now) to address your review concerns (actually mostly written last July) Can you check whether -01 is OK? We (the co-authors) have discussed how to deal with the congestion response to CE on Pure ACKs. We want to put our ideas to the list before committing to new text. So we have just tagged the Pure ACK section with a ToDo note for now. Here's an overview of the changes (or you can use the links to Diffs at https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-01 ). *Changes that one or both of you requested:** * * switches -> network elements (e.g. routers, switches) * Improved overview at the end of the Intro about where this doc sits in relation to other latency-related TCP drafts and RFCs (e.g. AccECN, ecn-experimentation, TFO, IW10, L4S) * Motivation: Made it clear that the DCTCP scenario is not for the public Internet * Clarified that ECN++ deployment needs no network changes * Added "Mobile hosts MAY maintain a cache entry per access network to record lack of AccECN support by proxies (see Section 4.2.1)." and described an example mechanism in 4.2.1. * Explained relationship between congestion response to CE on window probes and Congestion Window Validation (New CWV) * Added "Fall-back measures for blockage of ECT on other TCP control packets MAY be implemented. However they are not specified here given the lack of any evidence they will be needed. [The new] Section 4.9 justifies this advice in more detail." * Altered discussion of ECN in SCTP to make it just one in a list of examples of TCP-derivative transports (including QUIC) that could adopt a similar approach to the ECN++ experiment in TCP. * Cited appropriate QUIC refs. *Changes that we initiated:** * * Stated that this EXP doc obsoletes RFC5562 (which is also EXP), and added 5562 to the "Obsoletes:" header. * More focused "MEASUREMENT NEEDED" text in places * If no response following ECT on SYN or SYN-ACK, "SHOULD" only fall-back after 2 attempts (was 1, but experiments show no evidence of middlebox interference, so loss will more likely be due to other causes like congestion or radio interference). * Added client-based alternative to server-based caching of failed connection attempts with ECT set (Section 4.3.2) * General improvements for clarity * Updated refs * Changed Bob's affiliation to CableLabs Cheers Bob & Marcelo --------------1BE910D83389015EE6BDB084 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Padma, Gorry,

Now that ECN++ has been adopted as TCPM work, we posted
* draft-ietf-tcpm-generalized-ecn-00 (10 days ago) without any changes other than filename.
* draft-ietf-tcpm-generalized-ecn-01 (just now) to address your review concerns (actually mostly written last July)

Can you check whether -01 is OK?

We (the co-authors) have discussed how to deal with the congestion response to CE on Pure ACKs. We want to put our ideas to the list before committing to new text. So we have just tagged the Pure ACK section with a ToDo note for now.

Here's an overview of the changes (or you can use the links to Diffs at https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-01 ).

Changes that one or both of you requested:

* switches -> network elements (e.g. routers, switches)
* Improved overview at the end of the Intro about where this doc sits in relation to other latency-related TCP drafts and RFCs (e.g. AccECN, ecn-experimentation, TFO, IW10, L4S)
* Motivation: Made it clear that the DCTCP scenario is not for the public Internet
* Clarified that ECN++ deployment needs no network changes
* Added "Mobile hosts MAY maintain   
                a cache entry per access network to record lack of AccECN support by   
                proxies (see Section 4.2.1)."
  and described an example mechanism in 4.2.1.
* Explained relationship between congestion response to CE on window probes and Congestion Window Validation (New CWV)
* Added "Fall-back measures for blockage of ECT on other TCP control packets   
                MAY be implemented.  However they are not specified here given the   
                lack of any evidence they will be needed.  [The new] Section 4.9 justifies this   
                advice in more detail."
* Altered discussion of ECN in SCTP to make it just one in a list of examples of TCP-derivative transports (including QUIC) that could adopt a similar approach to the ECN++ experiment in TCP.
* Cited appropriate QUIC refs.

Changes that we initiated:

* Stated that this EXP doc obsoletes RFC5562 (which is also EXP), and added 5562 to the "Obsoletes:" header.
* More focused "MEASUREMENT NEEDED" text in places
* If no response following ECT on SYN or SYN-ACK, "SHOULD" only fall-back after 2 attempts (was 1, but experiments show no evidence of middlebox interference, so loss will more likely be due to other causes like congestion or radio interference).
* Added client-based alternative to server-based caching of failed connection attempts with ECT set (Section 4.3.2)
* General improvements for clarity
* Updated refs
* Changed Bob's affiliation to CableLabs

Cheers


Bob & Marcelo

--------------1BE910D83389015EE6BDB084--