From nobody Mon Mar 6 07:17:29 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80E91294D1; Mon, 6 Mar 2017 07:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 zU09-gp_ggYt; Mon, 6 Mar 2017 07:17:26 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441DF1295DF; Mon, 6 Mar 2017 07:17:26 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id v198so36294391ywc.2; Mon, 06 Mar 2017 07:17:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=x6aNa6kStKiEEosk2XKAKrVlOB+twg0+9S11A+aMJYI=; b=brjtGA/yKGq+Z62jSEWnab/dxRN928VbsRcTCIRYaRJCUFyQ10z5fm3+i1aqNWMJQZ OK41pV+ka7yttlBJnTvoK0LlUWttTpmo4Hxh9LiHLVQGWJDiBC0Q1npJd3mW+0NfsNF/ FW/lF2dfX/WopgjfzHv9P7JND4i1ubI42BT30CZi+NtW58+iEfHK38kyN3eLfbMdceNB SEhy/HbsQ5kB/rfUtnyjp3GmPPKPP/MwgcIqaVC9HqF5mazbpoN+2pSUhxkXEP369dgV DK4EX+PJDz6DabTmE+lS49nlGBkXA7hAZ0NWTBGYavAxHGfV8a4MHeOu8BQY8uOTuoyR dUCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=x6aNa6kStKiEEosk2XKAKrVlOB+twg0+9S11A+aMJYI=; b=qdwb0ewyTJSdtli6qnrCIMAoSOQ22eUrfzLhXcXoXr7XpamJanfhzA0+R638MvMtck vnmEZA7NKHP3yS8Ojwf3Wjk05DmhNod7aXoXO1jKeFMidnnjI4tGZ9bnzfTp9cvGY8fl Wck/PtVi7yl1Bgc1y8AJJthE1yL0F6aWbkywvDlqamDXsqjs3nbL0NjkSgxfM/m7Iic0 doGxVjtav16S7RQRRdrf0ijaJtoDOL2eccryTY4Mvn+OwCdTcFSwM/K5jYF4+62hM/h3 aQeMYrvf7EBU05wvqScT4Et8+qwPFTDrMfj+OcznwfCicLcnqfetv9XZlhvIJAe5f4gQ PQyQ== X-Gm-Message-State: AMke39nSavkVJ9dQcwKPFNDXbAGdsCORZINW0lJnsBEhi6xTHT0zGctPO+Sg5+tbmNXL85rLZe+lFX9EnELAcw== X-Received: by 10.129.99.198 with SMTP id x189mr11338487ywb.242.1488813445403; Mon, 06 Mar 2017 07:17:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.77.197 with HTTP; Mon, 6 Mar 2017 07:17:25 -0800 (PST) From: Spencer Dawkins at IETF Date: Mon, 6 Mar 2017 09:17:25 -0600 Message-ID: Subject: TSV AD Office Hours at IETF 98 in Chicago To: "tsv-area@ietf.org >> tsv-area@ietf.org" Content-Type: multipart/alternative; boundary=001a11491fca8cdd2c054a11643d Archived-At: Cc: "tsv-chairs@ietf.org" , "tsv-ads@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 15:17:28 -0000 --001a11491fca8cdd2c054a11643d Content-Type: text/plain; charset=UTF-8 Mirja and I will be holding our usual TSV AD office hours, on Tuesday, March 28, from 1300-1430 (Afternoon I slot). We'll be in the IESG Breakout Room, which is BIANCO (3rd Floor). If you have a question that hasn't been answered or a topic that's gotten wedged, this is your best opportunity to corner both ADs in one place at the same time. This works best if we know that you're coming, and why, so we can prepare. We are, of course, in Chicago all week. If this slot doesn't work for you, please let us know, and we'll find a time that does work. Travel safely, and we'll see you in the Windy City soon. Spencer and Mirja --001a11491fca8cdd2c054a11643d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mirja and I will be holding our usual TSV AD office hours,= on Tuesday, March 28, from 1300-1430 (Afternoon I slot).=C2=A0

We'll be in the IESG Breakout Room, which is=C2=A0BIANCO (3rd Floor).

If you have a questio= n that hasn't been answered or a topic that's gotten wedged, this i= s your best opportunity to corner both ADs in one place at the same time.

This wor= ks best if we know that you're coming, and why, so we can prepare.

We are, of = course, in Chicago all week. If this slot doesn't work for you, please = let us know, and we'll find a time that does work.

Travel safely, and we'l= l see you in the Windy City soon.

Spencer and Mirja
--001a11491fca8cdd2c054a11643d-- From nobody Wed Mar 8 13:49:43 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4A21295EC for ; Wed, 8 Mar 2017 13:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 cS751MVm78nQ for ; Wed, 8 Mar 2017 13:49:39 -0800 (PST) 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 679001295D2 for ; Wed, 8 Mar 2017 13:49:39 -0800 (PST) Received: (qmail 30671 invoked from network); 8 Mar 2017 22:49:37 +0100 Received: from 178-83-155-34.dynamic.hispeed.ch (HELO ?192.168.220.145?) (178.83.155.34) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 Mar 2017 22:49:37 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Draft agenda uploaded From: "Mirja Kuehlewind (IETF)" In-Reply-To: <41397ABC-92F8-41B4-867A-60835DB3D38B@kuehlewind.net> Date: Wed, 8 Mar 2017 22:49:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8D22EC07-89AC-4346-9ACB-04C254C06E03@kuehlewind.net> References: <41397ABC-92F8-41B4-867A-60835DB3D38B@kuehlewind.net> To: tsv-area@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 21:49:42 -0000 Hi all, we now have a second meeting slot, right after our first slot on Monday = afternoon, as we have more things we would like to discuss with you! An = updated agenda has been uploaded: https://www.ietf.org/proceedings/98/agenda/agenda-98-tsvarea-01 --------- Session 2 --------- Monday, March 27, 2017 Afternoon session II 15:20-16:50 Room: Zurich E/F * eXpress Data Path (XDP) in the Linux networking stack - Tom Herbert 30 minutes * Discussion on Congestion Control work in the IETF - Praveen = Balasubramanian and Michael Welzl --- See you all in Chicago! Mirja & Spencer > Am 28.02.2017 um 19:29 schrieb Mirja Kuehlewind (IETF) = : >=20 > Hi all, >=20 > we are happy to announce that we just uploaded the draft agenda for = the tsv-area meeting and we have a number of very interesting talks this = time! See >=20 > https://www.ietf.org/proceedings/98/agenda/agenda-98-tsvarea-00 >=20 > =E2=80=94=E2=80=94 > TSVAREA @ IETF-98 (Chicago) >=20 > Monday, March 27, 2017 > Afternoon session I 13:00-15:00 > Room: Vevey 1/2 >=20 > * Administrativa - TSV ADs > - Note Well, Blue Sheets, Jabber Scribes, Agenda Bashing > - TSV Overview and status > 10 minutes >=20 > * Beneficial Functions of Middleboxes = (draft-dolson-plus-middlebox-benefits) - Dave Dolson > 10 minutes + 15 minutes Q&A >=20 > * Transport-Independent Path Layer State Management = (draft-trammell-plus-statefulness) - Brian Trammell, remote > 10 minutes + 15 minutes Q&A >=20 > * Tackling privacy and confidentiality of communications: EU's = ePrivacy Regulation - Diego Naranjo (European Digital Rights - = https://edri.org), remote > 15 minutes + 15 minutes Q&A >=20 > * Tor's Perspective on Privacy and Traffic Analysis Resistance for = Encrypted Protocols - Mike Perry=20 > 15 minutes + 15 minutes Q&A > =E2=80=94=E2=80=94 >=20 > As always both the scheduled slot as well as your agenda are only = preliminary. Especially we are still considering a way to add another = agenda item which might lead to some changes in the timing. >=20 > See you all in Chicago! > Your friendly transport ADs >=20 >=20 >=20 From nobody Thu Mar 9 11:25:49 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF981293E1 for ; Thu, 9 Mar 2017 11:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 DeN0Q5TE_HEs for ; Thu, 9 Mar 2017 11:25:46 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DFD126CD8 for ; Thu, 9 Mar 2017 11:25:46 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Mar 2017 14:25:44 -0500 From: Dave Dolson To: "tsv-area@ietf.org" Subject: FW: New Version Notification for draft-dolson-plus-middlebox-benefits-03.txt Thread-Topic: New Version Notification for draft-dolson-plus-middlebox-benefits-03.txt Thread-Index: AdKZCm4sNqMxvxKAR5e9VRHyasD6QA== Date: Thu, 9 Mar 2017 19:25:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Juho Snellman , Mohamed Boucadair , Christian Jacquenet X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:25:48 -0000 SSd2ZSBkb25lIGEgbWlub3IgdXBkYXRlIHRvIHRoaXMgZHJhZnQgdGhhdCBJIHdpbGwgYmUgcHJl c2VudGluZyBhdCB0c3ZhcmVhIG1lZXRpbmcgaW4gQ2hpY2Fnby4NCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAwOSwgMjAxNyAy OjIxIFBNDQpUbzogRGF2ZSBEb2xzb247IEp1aG8gU25lbGxtYW47IE1vaGFtZWQgQm91Y2FkYWly OyBDaHJpc3RpYW4gSmFjcXVlbmV0DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWRvbHNvbi1wbHVzLW1pZGRsZWJveC1iZW5lZml0cy0wMy50eHQNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZG9sc29uLXBsdXMtbWlkZGxlYm94LWJlbmVmaXRzLTAz LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEYXZpZCBEb2xzb24gYW5k IHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWRvbHNvbi1w bHVzLW1pZGRsZWJveC1iZW5lZml0cw0KUmV2aXNpb246CTAzDQpUaXRsZToJCUJlbmVmaWNpYWwg RnVuY3Rpb25zIG9mIE1pZGRsZWJveGVzDQpEb2N1bWVudCBkYXRlOgkyMDE3LTAzLTA5DQpHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxNw0KVVJMOiAgICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kb2xzb24tcGx1cy1taWRk bGVib3gtYmVuZWZpdHMtMDMudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZG9sc29uLXBsdXMtbWlkZGxlYm94LWJlbmVmaXRzLw0KSHRt bGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kb2xzb24tcGx1 cy1taWRkbGVib3gtYmVuZWZpdHMtMDMNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZG9sc29uLXBsdXMtbWlkZGxlYm94LWJlbmVmaXRzLTAz DQoNCkFic3RyYWN0Og0KICAgQXQgSUVURjk3LCBhdCBhIG1lZXRpbmcgcmVnYXJkaW5nIHRoZSBQ YXRoIExheWVyIFVEUCBTdWJzdHJhdGUgKFBMVVMpDQogICBwcm90b2NvbCwgYSByZXF1ZXN0IHdh cyBtYWRlIGZvciBkb2N1bWVudGF0aW9uIGFib3V0IHRoZSBiZW5lZml0cw0KICAgdGhhdCBtaWdo dCBiZSBwcm92aWRlZCBieSBwZXJtaXR0aW5nIG1pZGRsZWJveGVzIHRvIGhhdmUgc29tZQ0KICAg dmlzaWJpbGl0eSB0byB0cmFuc3BvcnQtbGF5ZXIgaW5mb3JtYXRpb24uDQoNCiAgIFRoaXMgZG9j dW1lbnQgc3VtbWFyaXplcyBiZW5lZml0cyBwcm92aWRlZCB0byB0aGUgSW50ZXJuZXQgYnkNCiAg IGludGVybWVkaWFyeSBkZXZpY2VzIHRoYXQgcHJvdmlkZSBmdW5jdGlvbnMgYXBhcnQgZnJvbSBu b3JtYWwgSVANCiAgIGZvcndhcmRpbmcuICBTdWNoIGludGVybWVkaWFyeSBkZXZpY2VzIGFyZSBv ZnRlbiBjYWxsZWQNCiAgICJtaWRkbGVib3hlcyIuDQoNCiAgIFJGQzMyMzQgZGVmaW5lcyBhIHRh eG9ub215IG9mIG1pZGRsZWJveGVzIGFuZCBpc3N1ZXMgaW4gdGhlIEludGVybmV0Lg0KICAgTW9z dCBvZiB0aG9zZSBtaWRkbGVib3hlcyB1dGlsaXplIG9yIG1vZGlmeSBhcHBsaWNhdGlvbi1sYXll ciBkYXRhLg0KICAgVGhpcyBkb2N1bWVudCBwcmltYXJpbHkgZm9jdXNlcyBvbiBkZXZpY2VzIHRo YXQgb2JzZXJ2ZSBhbmQgYWN0IG9uDQogICBpbmZvcm1hdGlvbiBjYXJyaWVkIGluIHRoZSB0cmFu c3BvcnQgbGF5ZXIsIGFuZCBlc3BlY2lhbGx5DQogICBpbmZvcm1hdGlvbiBjYXJyaWVkIGluIFRD UCBwYWNrZXRzLg0KDQogICBBIHByaW1hcnkgZ29hbCBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIHBy b3ZpZGUgaW5mb3JtYXRpb24gdG8gd29ya2luZw0KICAgZ3JvdXBzIGRldmVsb3BpbmcgbmV3IHRy YW5zcG9ydCBwcm90b2NvbHMsIGluIHBhcnRpY3VsYXIgdGhlIFBMVVMgYW5kDQogICBRVUlDIHdv cmtpbmcgZ3JvdXBzLCB0byBhaWQgdW5kZXJzdGFuZGluZyBvZiB3aGF0IG1pZ2h0IGJlIGdhaW5l ZCBvcg0KICAgbG9zdCBieSBkZXNpZ24gZGVjaXNpb25zIHRoYXQgbWF5IGFmZmVjdCAob3IgYmUg YWZmZWN0ZWQgYnkpDQogICBtaWRkbGVib3ggb3BlcmF0aW9uLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Mar 14 09:02:20 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37099127F0E for ; Tue, 14 Mar 2017 09:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 fimsTEsokssx for ; Tue, 14 Mar 2017 09:02:18 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50108.outbound.protection.outlook.com [40.107.5.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82B3127077 for ; Tue, 14 Mar 2017 09:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SPwMhezVJ4Bnc5JmxNJ/DtZzVLx5zfjPc1PrbzJ5aC0=; b=kB1KnL8B7ZUE3jqtpIUO2tJ/bMrpX3VwYTPrHAm/1OUFUjuN53/l4fpO2FxaAfDpvTO8UsvTgSRDjXWE0+XLhb9d9nzYd5XKWjV3R1JWQDGw4C1SRmBUAv3kwAEOso9QpggmiC7jTr52NCb4uWRHLkIfl/ZZkcQMdKFReHxVk7U= Received: from DB5PR07MB1399.eurprd07.prod.outlook.com (10.166.4.9) by DB5PR07MB1318.eurprd07.prod.outlook.com (10.164.42.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Tue, 14 Mar 2017 16:02:15 +0000 Received: from DB5PR07MB1399.eurprd07.prod.outlook.com ([fe80::58cc:39e5:ac27:c066]) by DB5PR07MB1399.eurprd07.prod.outlook.com ([fe80::58cc:39e5:ac27:c066%15]) with mapi id 15.01.0977.010; Tue, 14 Mar 2017 16:02:14 +0000 From: "Flinck, Hannu (Nokia - FI/Espoo)" To: "tsv-area@ietf.org" CC: "Black, David" , Andreas Terzis , Vijay Devarapalli , "Smith, Kevin, (R&D) Vodafone Group" , Ankur Jain , "Sprecher, Nurit (Nokia - IL/Hod HaSharon)" , "Arunachalam, Swaminathan (Nokia - US/Irving)" Subject: Time slot request for mobile throughput quidance Thread-Topic: Time slot request for mobile throughput quidance Thread-Index: AdKc24rbgboj+u1tRUGh5rtop5ntyg== Date: Tue, 14 Mar 2017 16:02:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [131.228.2.17] x-microsoft-exchange-diagnostics: 1; DB5PR07MB1318; 7:raDC1vBDZT9yAu/Rq0NceGMsTcKjbj4tFM1gCDOcD9fZNNiueAw/SZTuSS+Es1fnFF52jGioxaANDJnOR9u5Y12A44MFlTlmRjxADTfK+of+Vq86vte/FG4C17im3mNoAbAdLToTjOCX1Q9CyyJ5YHTF6OUBmeSjxgEpHXZoUZn+Oxw+St+EPm1MVlO1Oq5IOD6Cl2OIGzQuFxYjHAv/E6Z2GQXCL8MGplQxW1DklKT7XbmQ4M/p7J4B5ZLzWxZmskO/RV/cC6Wrpenh5sl46k+0I8aPiW3Nwp8lLA12tPjRY00HEoEUVKgjQtOcguMmZ5Wm1VTZoQlOOL6B3/M15g== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39850400002)(39860400002)(39840400002)(33656002)(2906002)(8676002)(3280700002)(81166006)(3660700001)(8936002)(86362001)(66066001)(189998001)(110136004)(4326008)(107886003)(53936002)(966004)(38730400002)(6506006)(5640700003)(50986999)(54356999)(6436002)(8666007)(54906002)(9686003)(99286003)(55016002)(6306002)(8656002)(7696004)(2501003)(6916009)(74316002)(5660300001)(6116002)(102836003)(7736002)(2900100001)(305945005)(3846002)(2351001)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1318; H:DB5PR07MB1399.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 831d87fb-3786-4cb5-b414-08d46af37b2b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DB5PR07MB1318; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558025)(6072148); SRVR:DB5PR07MB1318; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1318; x-forefront-prvs: 02462830BE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR07MB139905FF41A9FE3F3F26583D9B240DB5PR07MB1399eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 16:02:13.9489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1318 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 16:02:19 -0000 --_000_DB5PR07MB139905FF41A9FE3F3F26583D9B240DB5PR07MB1399eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello I would like to request a time slot to update the community about the progr= ess in mobile throughput guidance: draft-flinck-mobile-throughput-guidance-04 Namely simplified protocol structure and latest field trail result from a l= arge scale 3G mobile network. 10 min + subsequent discussion would be sufficient. Best regards Hannu --_000_DB5PR07MB139905FF41A9FE3F3F26583D9B240DB5PR07MB1399eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello
 
I would like to request a time slot to update the community about the = progress in mobile throughput guidance:
 
draft-flinck-mobile-throughput-guidance-04
 
Namely simplified protocol structure and latest field trail result fro= m a large scale 3G mobile network.
 
10 min + subsequent discussion would be sufficient.
 
 
Best regards
Hannu
 
 --_000_DB5PR07MB139905FF41A9FE3F3F26583D9B240DB5PR07MB1399eurp_-- From nobody Tue Mar 14 09:10:20 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C471C132935 for ; Tue, 14 Mar 2017 09:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 IggDsLU3sVFV for ; Tue, 14 Mar 2017 09:10:17 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F306613293B for ; Tue, 14 Mar 2017 09:10:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3vjKT26n8qzMrB2; Tue, 14 Mar 2017 17:10:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmMUZ7-sQ3hx; Tue, 14 Mar 2017 17:10:13 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC2824.dip0.t-ipconnect.de [93.236.40.36]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Tue, 14 Mar 2017 17:10:13 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Time slot request for mobile throughput quidance From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Tue, 14 Mar 2017 17:10:12 +0100 Cc: "tsv-area@ietf.org" , "Smith, Kevin, (R&D) Vodafone Group" , "Arunachalam, Swaminathan (Nokia - US/Irving)" , Vijay Devarapalli , Ankur Jain , Andreas Terzis , "Sprecher, Nurit (Nokia - IL/Hod HaSharon)" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Flinck, Hannu (Nokia - FI/Espoo)" X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 16:10:19 -0000 Hi Hannu, thanks for your request. However, the tsv-area agenda is already = finalized. Further, as tsv-area is not a working group, we usually = don=E2=80=99t facilitate discussions on drafts that could have a home = somewhere else in the tsv area or are looking for a home in the tsv = area. Mirja > Am 14.03.2017 um 17:02 schrieb Flinck, Hannu (Nokia - FI/Espoo) = : >=20 > Hello=20 > =20 > I would like to request a time slot to update the community about the = progress in mobile throughput guidance: > =20 > draft-flinck-mobile-throughput-guidance-04 > =20 > Namely simplified protocol structure and latest field trail result = from a large scale 3G mobile network. > =20 > 10 min + subsequent discussion would be sufficient. > =20 > =20 > Best regards > Hannu=20 From nobody Tue Mar 14 09:53:46 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A3A132953 for ; Tue, 14 Mar 2017 09:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 zn_Qc0lv_JRB for ; Tue, 14 Mar 2017 09:53:43 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 DBB0F13295C for ; Tue, 14 Mar 2017 09:53:42 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cnphZ-0002Mz-MO; Tue, 14 Mar 2017 17:53:37 +0100 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cnphY-0002H5-WA; Tue, 14 Mar 2017 17:53:37 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Time slot request for mobile throughput quidance From: Michael Welzl In-Reply-To: Date: Tue, 14 Mar 2017 17:53:44 +0100 Cc: "Flinck, Hannu (Nokia - FI/Espoo)" , "Smith, Kevin, (R&D) Vodafone Group" , "Arunachalam, Swaminathan (Nokia - US/Irving)" , Vijay Devarapalli , Ankur Jain , Andreas Terzis , "Sprecher, Nurit (Nokia - IL/Hod HaSharon)" , "tsv-area@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <78D33872-8CC5-4EC1-A1A6-B9C508884163@ifi.uio.no> References: To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 1 sum rcpts/h 10 sum msgs/h 2 total rcpts 52700 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.084, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 772613F24AFC0F38174B9D4F9E5A102B28CE9CE0 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1008 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 16:53:45 -0000 Dear Hannu, I suggest to let ICCRG be your home! Cheers, Michael (as ICCRG chair) > On Mar 14, 2017, at 5:10 PM, Mirja K=C3=BChlewind = wrote: >=20 > Hi Hannu, >=20 > thanks for your request. However, the tsv-area agenda is already = finalized. Further, as tsv-area is not a working group, we usually = don=E2=80=99t facilitate discussions on drafts that could have a home = somewhere else in the tsv area or are looking for a home in the tsv = area. >=20 > Mirja >=20 >=20 >> Am 14.03.2017 um 17:02 schrieb Flinck, Hannu (Nokia - FI/Espoo) = : >>=20 >> Hello=20 >>=20 >> I would like to request a time slot to update the community about the = progress in mobile throughput guidance: >>=20 >> draft-flinck-mobile-throughput-guidance-04 >>=20 >> Namely simplified protocol structure and latest field trail result = from a large scale 3G mobile network. >>=20 >> 10 min + subsequent discussion would be sufficient. >>=20 >>=20 >> Best regards >> Hannu=20 >=20 From nobody Fri Mar 17 14:56:51 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA2D12961E; Fri, 17 Mar 2017 14:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AwfqNDeAW8SS; Fri, 17 Mar 2017 14:56:35 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7CE129626; Fri, 17 Mar 2017 14:56:34 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id y76so75354600qkb.0; Fri, 17 Mar 2017 14:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aaDJaIdB3AmHu1Z0+1Tg1YVMA1lfCjrYd7zUyOJbwZs=; b=DQVLFA6zli2AgkEM9gDRGrhoGm8SjqiHqIoz23E5IdvxlrN0mf1k2Drlb/jhEQyEFq 686tqSwuS3/8mQnO74j5mXiWqjzT4GKT4f2dKN8G2Mgn0L2QuB2QUtaMi5hhmLySo59G /GKJwoFn8ESN45IqPc8a0yTcZy4FFvlUU1J9TxMOk86N8BKlEVvWXhQRAEBKRktjx/WM MKNHZRUVg5Re424+ry7tFthq+u/gxw9isYZflmdR6xqxmVjgqj1oju5FbrNoyhy+WSdU f7gA3Sq/o/nDc9rWf/MDBZ6WTQ1+hFW+5r4xgA0amcYJQH6qq04AjNQ/2VJAwHDJchWk 3Z9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=aaDJaIdB3AmHu1Z0+1Tg1YVMA1lfCjrYd7zUyOJbwZs=; b=VI0rG+Uiyds0uklVTFeLeInJeVX9Vyb+CBjPrlh7Y7TRM4MAq6Ysu5NxkcwkP3TtMs AUS79tG9IafDTL+Kity5kt6caG4qEpugYqTDok2v3ahQ6WU/zA2IOqTIeGRWn9ri99X7 91Goqd1vccqglhkJOma9vfQOD0G4RE3tgmGNylxEmPkJRJOhIMyxTbtwtVsyjzbYnXPX iYnvvDU0NVjZnRrR4xvjXFKJ8TT5PTyZrRlR6KlCY4V4tg0nSl3oja4KGUxJmwLV/nQS LWTjuETHWrjGqGmy1eQUUIzpp8dytWE18iCadCIdznOgLH2sskHYRCHvmomsHtqxl/Hq JDgQ== X-Gm-Message-State: AFeK/H2+gVr9eu8tiDqkaZUPwesoeSkCleYGR19WD6rhWfwwyBzP1ctqfKswEChMB2PsJw== X-Received: by 10.55.33.8 with SMTP id h8mr15192051qkh.223.1489787793386; Fri, 17 Mar 2017 14:56:33 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 44sm6840438qts.15.2017.03.17.14.56.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 14:56:31 -0700 (PDT) From: Bob Hinden Message-Id: <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E17C0248-7CD7-4F06-8996-DB275E127C05"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Date: Fri, 17 Mar 2017 14:56:28 -0700 In-Reply-To: <58A33D08.4090505@erg.abdn.ac.uk> Cc: Bob Hinden , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, IPv6 List , IETF , "draft-ietf-6man-rfc1981bis@ietf.org" To: gorry@erg.abdn.ac.uk References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 21:56:38 -0000 --Apple-Mail=_E17C0248-7CD7-4F06-8996-DB275E127C05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Gorry, Thanks for the detailed review. Several of the reviews have suggested significant changes to this = document. The working group was trying to make a few changes to bring = it into alignment with some changes to rfc2460bis (based on updating = documents). It was not attempting a major rewrite when advancing it to = Internet Standard. The alternative that the working group discussed was = to file errata on RFC1981 and leave it to a future document update. I don=E2=80=99t think many of these changes can be done and still = advance it to Internet Standard. If we can=E2=80=99t advance the current = document, then the w.g. may want to just do the errata and withdraw the = advancement request. Of course, if people want to work on a revision of = IPv6 Path MTU Discovery, it would be welcomed, but it won=E2=80=99t be = able to advanced to Internet Standard. Comments below. Thanks, Bob > On Feb 14, 2017, at 9:23 AM, Gorry Fairhurst = wrote: >=20 >=20 > I have some late transport comments on this ID. The update seems to = retain a lot of thinking that is really historical and I'd really = encourage people to look again to making the document uptodate. >=20 > Detailed comments follow. >=20 > Best wishes, >=20 > Gorry >=20 > ---- > The following text strikes me as a little odd in an update: > " Moreover, TCP implementations that follow the "slow- > start" congestion-avoidance algorithm [CONG] typically calculate and > cache several other values derived from the PMTU. It may be simpler > to receive asynchronous notification when the PMTU changes, so that > these variables may be updated.=E2=80=9D > - A modern TCP caches at least some path information in the TCB, why = start with this clause at all: > "Moreover, TCP implementations that follow the "slow start" = congestion-avoidance algorithm [CONG] typically calculate and=E2=80=9D > and simply replace this with something like: > "TCP implementations=E2=80=9D? > =E2=80=94=E2=80=94 To clarify, you are suggesting to replace it with: TCP implementations typically cache several other values derived from the PMTU. It may be simpler to receive asynchronous = notification when the PMTU changes, so that these variables may be updated. I think that is editorial, and OK to change. The paragraph will read: The TCP layer must track the PMTU for the path(s) in use by a connection; it should not send segments that would result in packets larger than the PMTU. A simple implementation could ask the IP layer for this value each time it created a new segment, but this could be inefficient. TCP implementation typically cache several other values derived from the PMTU. It may be simpler to receive asynchronous notification when the PMTU changes, so that these variables may be updated. >=20 > The following text also seems to not reflect a modern TCP stack: > " It is sufficient > to treat this as any other dropped segment, and wait until the > retransmission timer expires to cause retransmission of the = segment.=E2=80=9D > (and following 3 paras). > Could this be replaced by text that does not exclude modern = retransmission methods: > " It is sufficient > to treat this in the same way as any other dropped segment, and > will be recovered by normal retransmission methods.=E2=80=9D Yes, resulting in: When a Packet Too Big message is received, it implies that a packet was dropped by the node that sent the ICMP message. It is sufficient to treat this in the same way as any other dropped segment, and will be recovered by normal retransmission methods. If the Path MTU Discovery process requires several steps to find the PMTU of the full path, this could delay the connection by many round-trip times. > =E2=80=94 > There is a block of text that describes retransmission triggered by = ICMPv6. > Has this code been implemented in modern releases of TCP?: > " Alternatively, the retransmission could be done in immediate = response > to a notification that the Path MTU has changed, but only for the > specific connection specified by the Packet Too Big message.=E2=80=9D > - It seems to expose a number of attack vectors that really should not = be exposed!! Are you suggesting remove this text? Following this text, there are two = notes. > --- > The discussion of NFS may still be a reasonable historic example, but = to be current it should really refer also to NFSv4/TCP as utlising the = MTU discovery provided by TCP, since UDP-based NFS is no longer a key = application. > =E2=80=94 I was planning to update the reference to NFS to RFC7530. I could add = text that says something like: It is recommended that NFS running over TCP utilize the MTU discovery provided by TCP. Other suggestions? > There is no mention that paths including tunnels can eat ICMPv6 PTB = messages on the tunnel segment, blackholing them, which prevents = reaching the destination. As noted above, I think adding discussion about tunnels is out of scope = of this effort. > --- > I think the security consideration is naive! Suggestions? >=20 > This statement in particular seems to open DOS vulnerability: > " > When a node receives a Packet Too Big message, it MUST reduce its > estimate of the PMTU for the relevant path, based on the value of = the > MTU field in the message." > - Introdueces a significant vulnerability. A rogue PTB message that = reduces the PMTU to a minimum, can result in a path too small to carry = an encapsulated packet. (Recently noted by Fernando Gont). Suggestions? >=20 > Moreover, other layers view ICMP messages with suspicion and have long = noted the need to check ICMP payload and match only packets that relate = to actual 5-tuples in use (effectively reducing vulnerability to = off-path attacks). For example, the Guidelines for UDP, rfc5405bis, = state: >=20 > " Applications SHOULD appropriately validate the payload of ICMP > messages to ensure these are received in response to transmitted > traffic (i.e., a reported error condition that corresponds to a UDP > datagram actually sent by the application). =E2=80=A6=E2=80=9C > - clearly handling this in IP-layer tunnels can be troublesome, but = that's a problem that should be described, not obscured. I could add something like the following as a new second paragraph in = Section 4 Protocol Requirements: Protocols SHOULD appropriately validate the payload of ICMPv6 PTB messages to ensure these are received in response to transmitted traffic (i.e., a reported error condition that corresponds to a UDP datagram actually sent by the application). or similar. > =E2=80=94=E2=80=94 >=20 > I=E2=80=99d finally like to add my concerns about the understatement = of the value of PLPMTUD, which seems to not reflect the recommendations = to use this method: > =E2=80=9C It defines a method for Packetization Layer Path > MTU Discovery (PLPMTUD) designed for use over paths where delivery = of > ICMP messages to a host is not assured.=E2=80=9D > This seems under-stating the value and recommendations to deploy = PLMTUD, compared with current transport-area recommendations, for = instance, the UDP Guidelines provide much more on this important design = consideration: The w.g. spent a lot of time on this paragraph. The intent was to point = to it, but not into detail of how it worked, nor make it a new = requirement. There was some discussion that adding more detail about = the relationship between PTMUD and PLPMTUD in the ongoing update to IPv6 = Node Requirements would be helpful. >=20 > " Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does = not > rely upon network support for ICMP messages and is therefore > considered more robust than standard PMTUD. It is not susceptible = to > "black holing" of ICMP message. To operate, PLPMTUD requires = changes > to the way the transport is used, both to transmit probe packets, = and > to account for the loss or success of these probes. This updates = not > only the PMTU algorithm, it also impacts loss recovery, congestion > control, etc. These updated mechanisms can be implemented within a > connection-oriented transport (e.g., TCP, SCTP, DCCP), but are not a > part of UDP, but this type of feedback is not typically present for > unidirectional applications." >=20 > ---- >=20 > The examples used in the definition of "upper layer" and "link" also = makes this document appear as historic, rather than a new RFC! As noted above, I think there would be support for a rewrite if some = folks wanted to take that on. --Apple-Mail=_E17C0248-7CD7-4F06-8996-DB275E127C05 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYzFuNAAoJEK7rdBF357uojAUH/09MvHP44Q3jQZ/TCpw4SSrH 7iQwuddxtEiaK2x1aFXdxsxPw9y0S7RqPyfo2gbMs03zgmg7Jqz0S2LpvPM/Pql1 Pm64clbqKPaWSiMOW5m3Z34aF0uZ94PkhQn7OtKN304bdXpw2u+yCTsKmtiQjcX7 z7wAW6v9407CWbmA4ZeMEVYw0vul8sxad4IWGIXLRqLkfeMSSuOFZimSFg5CDNpR jGgUA+GpSQc3IjpmqgJ9hQb1u3PfTKBRT1hiTWwgt8W1uKvr5UQqvc0O8gne6bKK bMGpWmuwvzUkOFgJXCyy86N9BE/YLFidK3luUJ4cNKc0bFETCSmUhOs7B2TZ+wQ= =mCAV -----END PGP SIGNATURE----- --Apple-Mail=_E17C0248-7CD7-4F06-8996-DB275E127C05-- From nobody Fri Mar 24 16:05:50 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFB912762F; Fri, 24 Mar 2017 16:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RP_MATCHES_RCVD=-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 Gaew8qrTwwoA; Fri, 24 Mar 2017 16:05:27 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 57715120326; Fri, 24 Mar 2017 16:05:27 -0700 (PDT) Received: from Gs-MacBook-Pro.local (unknown [216.80.70.251]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 214791B017C3; Sat, 25 Mar 2017 01:02:41 +0000 (GMT) Message-ID: <58D518EA.5000508@erg.abdn.ac.uk> Date: Fri, 24 Mar 2017 13:02:34 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bob Hinden CC: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, IPv6 List , IETF , "draft-ietf-6man-rfc1981bis@ietf.org" Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com> In-Reply-To: <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 23:05:32 -0000 On 17/03/2017, 21:56, Bob Hinden wrote: > Gorry, > > Thanks for the detailed review. > > Several of the reviews have suggested significant changes to this document. The working group was trying to make a few changes to bring it into alignment with some changes to rfc2460bis (based on updating documents). It was not attempting a major rewrite when advancing it to Internet Standard. The alternative that the working group discussed was to file errata on RFC1981 and leave it to a future document update. > > I don’t think many of these changes can be done and still advance it to Internet Standard. If we can’t advance the current document, then the w.g. may want to just do the errata and withdraw the advancement request. Of course, if people want to work on a revision of IPv6 Path MTU Discovery, it would be welcomed, but it won’t be able to advanced to Internet Standard. > > Comments below. > > Thanks, > Bob Thanks Bob, I note the question of status, but in this case, there's a lot happened in the Internet since this PS was first published, and much of this was in the transport area. Please see replies to comments below. I'm happy to discuss or refine text, if this helps. Gorry >> On Feb 14, 2017, at 9:23 AM, Gorry Fairhurst wrote: >> >> >> I have some late transport comments on this ID. The update seems to retain a lot of thinking that is really historical and I'd really encourage people to look again to making the document uptodate. >> >> Detailed comments follow. >> >> Best wishes, >> >> Gorry >> >> ---- >> The following text strikes me as a little odd in an update: >> " Moreover, TCP implementations that follow the "slow- >> start" congestion-avoidance algorithm [CONG] typically calculate and >> cache several other values derived from the PMTU. It may be simpler >> to receive asynchronous notification when the PMTU changes, so that >> these variables may be updated.” >> - A modern TCP caches at least some path information in the TCB, why start with this clause at all: >> "Moreover, TCP implementations that follow the "slow start" congestion-avoidance algorithm [CONG] typically calculate and” >> and simply replace this with something like: >> "TCP implementations”? >> —— > To clarify, you are suggesting to replace it with: > > TCP implementations typically cache several other values derived > from the PMTU. It may be simpler to receive asynchronous notification when > the PMTU changes, so that these variables may be updated. > I think that is editorial, and OK to change. The paragraph will read: > > The TCP layer must track the PMTU for the path(s) in use by a > connection; it should not send segments that would result in packets > larger than the PMTU. A simple implementation could ask the IP layer > for this value each time it created a new segment, but this could be > inefficient. TCP implementation typically cache several other values > derived from the PMTU. It may be simpler to receive asynchronous > notification when the PMTU changes, so that these variables may be > updated. Thanks. Seems better, although I would suggest to revise this in this way: A packetization layer layer (e.g., TCP) must track the PMTU for the path(s) in use by a connection; it should not send segments that would result in packets larger than the PMTU, except to probe during PMTU discovery. A simple implementation could ask the IP layer for this value each time it created a new segment, but this could be inefficient. An implementation typically caches other values derived from the PMTU. It may be simpler to receive asynchronous notification when the PMTU changes, so that these variables may be also updated. - This would fix typos, and also make the text relevant to transport protocols, rather than only TCP. Which is I beleive the correct interpretation. >> The following text also seems to not reflect a modern TCP stack: >> " It is sufficient >> to treat this as any other dropped segment, and wait until the >> retransmission timer expires to cause retransmission of the segment.” >> (and following 3 paras). >> Could this be replaced by text that does not exclude modern retransmission methods: >> " It is sufficient >> to treat this in the same way as any other dropped segment, and >> will be recovered by normal retransmission methods.” > Yes, resulting in: > > When a Packet Too Big message is received, it implies that a packet > was dropped by the node that sent the ICMP message. It is sufficient > to treat this in the same way as any other dropped segment, and will > be recovered by normal retransmission methods. If the Path MTU > Discovery process requires several steps to find the PMTU of the full > path, this could delay the connection by many round-trip times. Good. Seems much better. > >> — >> There is a block of text that describes retransmission triggered by ICMPv6. >> Has this code been implemented in modern releases of TCP?: >> " Alternatively, the retransmission could be done in immediate response >> to a notification that the Path MTU has changed, but only for the >> specific connection specified by the Packet Too Big message.” >> - It seems to expose a number of attack vectors that really should not be exposed!! > Are you suggesting remove this text? Following this text, there are two notes. > I'd personally remove this and the notes (you decide) - more because it says think that it opens a can of worms about transport details that are largely beyond the scope of the document (such as whether to trust ICMPv6 as indications of actual loss, and how this interacts with re-packaging to a different segment size, congetsuon control, etc). If the WG thinks retaining some text is good, I'd say (as a cautious transport person) that we should call out a warning to people doing transmissions... OLD: If the new estimated PMTU is still wrong, the process repeats, and there is an exponential growth in the number of superfluous segments sent. NEW: If the new estimated PMTU is still wrong, the process repeats, and there is an exponential growth in the number of superfluous segments sent. Retransmissions can increase network load in response to congestion, worsening that congestion. Any packetization layer that uses retransmission is responsible for congestion control of its retransmissions. If you wish, cite RFC8085 and RFC4821 to let people figure this out? (these 2 sentences come directly from RFC8085). >> --- >> The discussion of NFS may still be a reasonable historic example, but to be current it should really refer also to NFSv4/TCP as utlising the MTU discovery provided by TCP, since UDP-based NFS is no longer a key application. >> — > I was planning to update the reference to NFS to RFC7530. I could add text that says something like: The protocol changed though - so it's not just a replacement reference. I think text should note that RFC7530 says NFS must be able to run over a congestion-controlled transport, such as TCP. > It is recommended that NFS running over TCP utilize the MTU discovery > provided by TCP. > > Other suggestions? Maybe, you could say something like: "RFC191 used NFS as an example of a UDP-based application that benefits from PMTU discovery. Since then RFC7530, states the supported transport layer between NFS and IP must be an IETF standardized transport protocol that is specified to avoid network congestion; such transports include TCP and the Stream Control Transmission Protocol (SCTP). In this case, the transport is itself responsible for determining and using an effective Path MTU, including implementing PMTU discovery when this is needed." RFC8085 may well be a good place to point to say what is needed/desirable for PMTU for UDP applications, if you wish to say something about UDP. >> There is no mention that paths including tunnels can eat ICMPv6 PTB messages on the tunnel segment, blackholing them, which prevents reaching the destination. > As noted above, I think adding discussion about tunnels is out of scope of this effort. I agree that new mechanisms are out of scope, I was hoping that a simple note on tunnels would be in the security considerations. RFC8085 or draft-ietf-intarea-tunnels could be pointed to describe the implications of tunnels. >> --- >> I think the security consideration is naive! > Suggestions? " In the first attack, the false message indicates a PMTU much smaller than reality. This should not entirely stop data flow, since the victim node should never set its PMTU estimate below the IPv6 minimum link MTU. It will, however, result in suboptimal performance." So... In the case of the first attack, I still question whether this choice of words misrepresents the attack. What if, the false message advertises ~1280 bytes, and the path uses a tunnel encapsulation transporting IPv6, then the PTB message can be basis for a straight DoS attack that does stop data flow? I would recommend revising the security considerations (at least to something like): " In the first attack, the false message indicates a PMTU much smaller than reality. In response, the victim node should never set its PMTU estimate below the IPv6 minimum link MTU. A sender that falsely reduces to this MTU would observe suboptimal performance." - Although this skirts the problem. >> This statement in particular seems to open DOS vulnerability: >> " >> When a node receives a Packet Too Big message, it MUST reduce its >> estimate of the PMTU for the relevant path, based on the value of the >> MTU field in the message." >> - Introdueces a significant vulnerability. A rogue PTB message that reduces the PMTU to a minimum, can result in a path too small to carry an encapsulated packet. (Recently noted by Fernando Gont). > Suggestions? See below - and above. >> Moreover, other layers view ICMP messages with suspicion and have long noted the need to check ICMP payload and match only packets that relate to actual 5-tuples in use (effectively reducing vulnerability to off-path attacks). For example, the Guidelines for UDP, rfc5405bis, state: >> >> " Applications SHOULD appropriately validate the payload of ICMP >> messages to ensure these are received in response to transmitted >> traffic (i.e., a reported error condition that corresponds to a UDP >> datagram actually sent by the application). …“ >> - clearly handling this in IP-layer tunnels can be troublesome, but that's a problem that should be described, not obscured. > I could add something like the following as a new second paragraph in Section 4 Protocol Requirements: > > Protocols SHOULD appropriately validate the payload of ICMPv6 PTB > messages to ensure these are received in response to transmitted > traffic (i.e., a reported error condition that corresponds to a UDP > datagram actually sent by the application). > > or similar. That certainly is a nod in what I think is really the correct direction. Probably /UDP/ should be /IPv6 packet/ given the context of this ID. > >> —— >> >> I’d finally like to add my concerns about the understatement of the value of PLPMTUD, which seems to not reflect the recommendations to use this method: >> “ It defines a method for Packetization Layer Path >> MTU Discovery (PLPMTUD) designed for use over paths where delivery of >> ICMP messages to a host is not assured.” >> This seems under-stating the value and recommendations to deploy PLMTUD, compared with current transport-area recommendations, for instance, the UDP Guidelines provide much more on this important design consideration: > > The w.g. spent a lot of time on this paragraph. The intent was to point to it, but not into detail of how it worked, nor make it a new requirement. There was some discussion that adding more detail about the relationship between PTMUD and PLPMTUD in the ongoing update to IPv6 Node Requirements would be helpful. I appreciate people have spent time trying to get the IPv6 specifications progressed to standards status. This is a good effort, but I think just adding a nod in the introduction is rather feeble for soemthing now recommended. I think at least the security considerations should motivate the benefits of this approach (see next). >> " Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not >> rely upon network support for ICMP messages and is therefore >> considered more robust than standard PMTUD. It is not susceptible to >> "black holing" of ICMP message. To operate, PLPMTUD requires changes >> to the way the transport is used, both to transmit probe packets, and >> to account for the loss or success of these probes. This updates not >> only the PMTU algorithm, it also impacts loss recovery, congestion >> control, etc. These updated mechanisms can be implemented within a >> connection-oriented transport (e.g., TCP, SCTP, DCCP), but are not a >> part of UDP, but this type of feedback is not typically present for >> unidirectional applications." >> >> ---- >> >> The examples used in the definition of "upper layer" and "link" also makes this document appear as historic, rather than a new RFC! > As noted above, I think there would be support for a rewrite if some folks wanted to take that on. Could the WG consider to also add the first two sentences to the security considerations? Gorry P.S. A few more out-dated statements abiut TCP, based on the way specific stacks work when the original was written: - The phrase below needs to be removed also, since not all TCP stacks behave in this way anymore: ", which is always a multiple of the segment size" - There was very specific detailis relating to 4.2BSD TCP implementations, which would have been better not being here. From nobody Sun Mar 26 14:23:17 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18840127871; Sun, 26 Mar 2017 14:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QJvoAqKwZy7z; Sun, 26 Mar 2017 14:23:00 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 60D3E126BF0; Sun, 26 Mar 2017 14:23:00 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id u1so30186156wra.2; Sun, 26 Mar 2017 14:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NLt274xY80wnDd8Lx3qrFJnF65/i8bPr1S8zWExwSVY=; b=Hp61IQgzzkepINfuBAkrwRlOqXMuwkUXyFVc5juv10ABPtoSL+LFKT8tiVMMAptJBC 8GdoFUJmsPfX0+1k+L72aN2t+YpaUsnLh3dT8YppdwsPrqpLObf5ayj/lAqFeJuPpctc MFAjLSMk3vVgohx84Cw2fcFK0hfRQqGVXjNlvfElEOpoPAKoofCdgaaEjwnuU5E+kGGD CL5eN9xnfSVb/7jZ1nlIDzRlGDumw8yIqGPbtC9lTr5JD4SXN0705p26yV+PhfCR4lts HYRNyws2+/kOIVqjN/7rFzwLlkibkijboGLTsDDLpEOfN34dRxZ1B2tUNb2VrhNVTF8S c+Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NLt274xY80wnDd8Lx3qrFJnF65/i8bPr1S8zWExwSVY=; b=cXLdc4yTtxgl8nfh7CHdpArBZp9FMurLS4ExTQgJKP+tYWlaTMe7BAEnqcGJZnSwJ2 pFQE0tioIDLhEoRQ6NlKvUzRtSTLyHb2kNx8Pj4CUGBW6pYCg4G6umUxweuDYSXR3+se NAOIxtWg01T0D83/Sso7TvZ8fZtFMNM8SasXam7De/vccvYnXqy8I9uri1XotlMMS56y wcJ3LSK5h6D77mmcmBEJ/E19nv/MpBiOBskrBZogxoPvypKqlS793DtxU1s8IQTrGF0X 1o1UUo4k8qIXUWWVC/uf/LowSAxGJK1NBgWGtOpDTpfyv2njAYzFWmEIFTo0StUcjADv MRsQ== X-Gm-Message-State: AFeK/H01xpv6CYhJeDqVEaba9gh0UiON/hiED9MCpBfPGbmo97hRQI0hJ+cULht650CM9Q== X-Received: by 10.28.11.130 with SMTP id 124mr6916926wml.3.1490563378478; Sun, 26 Mar 2017 14:22:58 -0700 (PDT) Received: from dhcp-9201.meeting.ietf.org (dhcp-9201.meeting.ietf.org. [31.133.146.1]) by smtp.gmail.com with ESMTPSA id l21sm12180619wrl.59.2017.03.26.14.22.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2017 14:22:56 -0700 (PDT) From: Bob Hinden Message-Id: <4BC1763E-9D76-4EAA-B0B4-35620421736B@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BA125144-D743-4BD9-923D-DD79D54571BC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Date: Sun, 26 Mar 2017 16:22:51 -0500 In-Reply-To: <58D518EA.5000508@erg.abdn.ac.uk> Cc: Bob Hinden , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, IPv6 List , IETF , "draft-ietf-6man-rfc1981bis@ietf.org" To: gorry@erg.abdn.ac.uk References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com> <58D518EA.5000508@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 21:23:03 -0000 --Apple-Mail=_BA125144-D743-4BD9-923D-DD79D54571BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Gorry, > On Mar 24, 2017, at 8:02 AM, Gorry Fairhurst = wrote: >=20 > On 17/03/2017, 21:56, Bob Hinden wrote: >> Gorry, >>=20 >> Thanks for the detailed review. >>=20 >> Several of the reviews have suggested significant changes to this = document. The working group was trying to make a few changes to bring = it into alignment with some changes to rfc2460bis (based on updating = documents). It was not attempting a major rewrite when advancing it to = Internet Standard. The alternative that the working group discussed was = to file errata on RFC1981 and leave it to a future document update. >>=20 >> I don=E2=80=99t think many of these changes can be done and still = advance it to Internet Standard. If we can=E2=80=99t advance the current = document, then the w.g. may want to just do the errata and withdraw the = advancement request. Of course, if people want to work on a revision of = IPv6 Path MTU Discovery, it would be welcomed, but it won=E2=80=99t be = able to advanced to Internet Standard. >>=20 >> Comments below. >>=20 >> Thanks, >> Bob > Thanks Bob, >=20 > I note the question of status, but in this case, there's a lot = happened in the Internet since this PS was first published, and much of = this was in the transport area. Please see replies to comments below. = I'm happy to discuss or refine text, if this helps. Comments below. Let=E2=80=99s get together and go over the document = while we are in Chicago. I want to make sure the changes are made = correctly and in context. Thanks, Bob >=20 > Gorry >>> On Feb 14, 2017, at 9:23 AM, Gorry Fairhurst = wrote: >>>=20 >>>=20 >>> I have some late transport comments on this ID. The update seems to = retain a lot of thinking that is really historical and I'd really = encourage people to look again to making the document uptodate. >>>=20 >>> Detailed comments follow. >>>=20 >>> Best wishes, >>>=20 >>> Gorry >>>=20 >>> ---- >>> The following text strikes me as a little odd in an update: >>> " Moreover, TCP implementations that follow the "slow- >>> start" congestion-avoidance algorithm [CONG] typically calculate = and >>> cache several other values derived from the PMTU. It may be = simpler >>> to receive asynchronous notification when the PMTU changes, so = that >>> these variables may be updated.=E2=80=9D >>> - A modern TCP caches at least some path information in the TCB, why = start with this clause at all: >>> "Moreover, TCP implementations that follow the "slow start" = congestion-avoidance algorithm [CONG] typically calculate and=E2=80=9D >>> and simply replace this with something like: >>> "TCP implementations=E2=80=9D? >>> =E2=80=94=E2=80=94 >> To clarify, you are suggesting to replace it with: >>=20 >> TCP implementations typically cache several other values derived >> from the PMTU. It may be simpler to receive asynchronous = notification when >> the PMTU changes, so that these variables may be updated. >> I think that is editorial, and OK to change. The paragraph will = read: >>=20 >> The TCP layer must track the PMTU for the path(s) in use by a >> connection; it should not send segments that would result in = packets >> larger than the PMTU. A simple implementation could ask the IP = layer >> for this value each time it created a new segment, but this could = be >> inefficient. TCP implementation typically cache several other = values >> derived from the PMTU. It may be simpler to receive asynchronous >> notification when the PMTU changes, so that these variables may be >> updated. > Thanks. Seems better, although I would suggest to revise this in this = way: >=20 > A packetization layer layer (e.g., TCP) must track the PMTU > for the path(s) in use by a > connection; it should not send segments that would result in packets > larger than the PMTU, except to probe during PMTU discovery. > A simple implementation could ask the IP layer > for this value each time it created a new segment, but this could be > inefficient. An implementation typically caches other values > derived from the PMTU. It may be simpler to receive asynchronous > notification when the PMTU changes, so that these variables may be > also updated. >=20 > - This would fix typos, and also make the text relevant to transport = protocols, > rather than only TCP. Which is I beleive the correct interpretation. I think that=E2=80=99s good. I will require some other changes to the = Section that is titled "TCP layer action=E2=80=9D, let=E2=80=99s discuss = this later. >=20 >>> The following text also seems to not reflect a modern TCP stack: >>> " It is sufficient >>> to treat this as any other dropped segment, and wait until the >>> retransmission timer expires to cause retransmission of the = segment.=E2=80=9D >>> (and following 3 paras). >>> Could this be replaced by text that does not exclude modern = retransmission methods: >>> " It is sufficient >>> to treat this in the same way as any other dropped segment, and >>> will be recovered by normal retransmission methods.=E2=80=9D >> Yes, resulting in: >>=20 >> When a Packet Too Big message is received, it implies that a = packet >> was dropped by the node that sent the ICMP message. It is = sufficient >> to treat this in the same way as any other dropped segment, and = will >> be recovered by normal retransmission methods. If the Path MTU >> Discovery process requires several steps to find the PMTU of the = full >> path, this could delay the connection by many round-trip times. > Good. Seems much better. Good. >>=20 >>> =E2=80=94 >>> There is a block of text that describes retransmission triggered by = ICMPv6. >>> Has this code been implemented in modern releases of TCP?: >>> " Alternatively, the retransmission could be done in immediate = response >>> to a notification that the Path MTU has changed, but only for the >>> specific connection specified by the Packet Too Big message.=E2=80=9D= >>> - It seems to expose a number of attack vectors that really should = not be exposed!! >> Are you suggesting remove this text? Following this text, there are = two notes. >>=20 > I'd personally remove this and the notes (you decide) - more because = it says think that it opens a can of worms about transport details that = are largely beyond the scope of the document (such as whether to trust = ICMPv6 as indications of actual loss, and how this interacts with = re-packaging to a different segment size, congetsuon control, etc). >=20 > If the WG thinks retaining some text is good, I'd say (as a cautious = transport person) that we should call out a warning to people doing = transmissions... >=20 > OLD: > If the new estimated PMTU is > still wrong, the process repeats, and there is an exponential > growth in the number of superfluous segments sent. > NEW: > If the new estimated PMTU is > still wrong, the process repeats, and there is an exponential > growth in the number of superfluous segments sent. > Retransmissions can increase network load in > response to congestion, worsening that congestion. Any > packetization layer that uses retransmission is responsible for > congestion control of its retransmissions. >=20 > If you wish, cite RFC8085 and RFC4821 to let people figure this out? = (these 2 sentences come directly from RFC8085). Ok, I think that works. >>> --- >>> The discussion of NFS may still be a reasonable historic example, = but to be current it should really refer also to NFSv4/TCP as utlising = the MTU discovery provided by TCP, since UDP-based NFS is no longer a = key application. >>> =E2=80=94 >> I was planning to update the reference to NFS to RFC7530. I could = add text that says something like: > The protocol changed though - so it's not just a replacement = reference. >=20 > I think text should note that RFC7530 says NFS must be able to run = over a congestion-controlled transport, such as TCP. >> It is recommended that NFS running over TCP utilize the MTU = discovery >> provided by TCP. >>=20 >> Other suggestions? > Maybe, you could say something like: > "RFC191 used NFS as an example of a UDP-based application that = benefits from PMTU discovery. Since then RFC7530, states the supported = transport layer between NFS > and IP must be an IETF standardized transport protocol that is = specified to avoid > network congestion; such transports include TCP and the Stream Control = Transmission Protocol (SCTP). In this case, the transport is itself = responsible for determining and using an effective Path MTU, including = implementing PMTU discovery when this is needed.=E2=80=9D >=20 > RFC8085 may well be a good place to point to say what is = needed/desirable for PMTU for UDP applications, if you wish to say = something about UDP. Thanks, I think that works. Not sure if the other paragraphs on NFS = should remain. >>> There is no mention that paths including tunnels can eat ICMPv6 PTB = messages on the tunnel segment, blackholing them, which prevents = reaching the destination. >> As noted above, I think adding discussion about tunnels is out of = scope of this effort. > I agree that new mechanisms are out of scope, I was hoping that a = simple note on tunnels would be in the security considerations. >=20 > RFC8085 or draft-ietf-intarea-tunnels could be pointed to describe the = implications of tunnels. >>> --- >>> I think the security consideration is naive! >> Suggestions? > " In the first attack, the false message indicates a PMTU much = smaller > than reality. This should not entirely stop data flow, since the > victim node should never set its PMTU estimate below the IPv6 = minimum > link MTU. It will, however, result in suboptimal performance." >=20 > So... In the case of the first attack, I still question whether this = choice of words misrepresents the attack. > What if, the false message advertises ~1280 bytes, and the path uses a = tunnel encapsulation transporting IPv6, then the PTB message can be = basis for a straight DoS attack that does stop data flow? >=20 > I would recommend revising the security considerations (at least to = something like): > " In the first attack, the false message indicates a PMTU much = smaller > than reality. In response, the > victim node should never set its PMTU estimate below the IPv6 = minimum > link MTU. A sender that falsely reduces to this MTU would observe = suboptimal performance." >=20 > - Although this skirts the problem. OK, I agree this is better. >>> This statement in particular seems to open DOS vulnerability: >>> " >>> When a node receives a Packet Too Big message, it MUST reduce its >>> estimate of the PMTU for the relevant path, based on the value of = the >>> MTU field in the message." >>> - Introdueces a significant vulnerability. A rogue PTB message that = reduces the PMTU to a minimum, can result in a path too small to carry = an encapsulated packet. (Recently noted by Fernando Gont). >> Suggestions? > See below - and above. >>> Moreover, other layers view ICMP messages with suspicion and have = long noted the need to check ICMP payload and match only packets that = relate to actual 5-tuples in use (effectively reducing vulnerability to = off-path attacks). For example, the Guidelines for UDP, rfc5405bis, = state: >>>=20 >>> " Applications SHOULD appropriately validate the payload of ICMP >>> messages to ensure these are received in response to transmitted >>> traffic (i.e., a reported error condition that corresponds to a = UDP >>> datagram actually sent by the application). =E2=80=A6=E2=80=9C >>> - clearly handling this in IP-layer tunnels can be troublesome, but = that's a problem that should be described, not obscured. >> I could add something like the following as a new second paragraph in = Section 4 Protocol Requirements: >>=20 >> Protocols SHOULD appropriately validate the payload of ICMPv6 PTB >> messages to ensure these are received in response to transmitted >> traffic (i.e., a reported error condition that corresponds to a UDP >> datagram actually sent by the application). >>=20 >> or similar. >=20 > That certainly is a nod in what I think is really the correct = direction. > Probably /UDP/ should be /IPv6 packet/ given the context of this ID. Good, I think that makes sense. >>=20 >>> =E2=80=94=E2=80=94 >>>=20 >>> I=E2=80=99d finally like to add my concerns about the = understatement of the value of PLPMTUD, which seems to not reflect the = recommendations to use this method: >>> =E2=80=9C It defines a method for Packetization Layer Path >>> MTU Discovery (PLPMTUD) designed for use over paths where delivery = of >>> ICMP messages to a host is not assured.=E2=80=9D >>> This seems under-stating the value and recommendations to deploy = PLMTUD, compared with current transport-area recommendations, for = instance, the UDP Guidelines provide much more on this important design = consideration: >>=20 >> The w.g. spent a lot of time on this paragraph. The intent was to = point to it, but not into detail of how it worked, nor make it a new = requirement. There was some discussion that adding more detail about = the relationship between PTMUD and PLPMTUD in the ongoing update to IPv6 = Node Requirements would be helpful. >=20 > I appreciate people have spent time trying to get the IPv6 = specifications progressed to standards status. This is a good effort, = but I think just adding a nod in the introduction is rather feeble for = soemthing now recommended. I think at least the security considerations = should motivate the benefits of this approach (see next). >>> " Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does = not >>> rely upon network support for ICMP messages and is therefore >>> considered more robust than standard PMTUD. It is not susceptible = to >>> "black holing" of ICMP message. To operate, PLPMTUD requires = changes >>> to the way the transport is used, both to transmit probe packets, = and >>> to account for the loss or success of these probes. This updates = not >>> only the PMTU algorithm, it also impacts loss recovery, congestion >>> control, etc. These updated mechanisms can be implemented within = a >>> connection-oriented transport (e.g., TCP, SCTP, DCCP), but are not = a >>> part of UDP, but this type of feedback is not typically present = for >>> unidirectional applications." >>>=20 >>> ---- >>>=20 >>> The examples used in the definition of "upper layer" and "link" = also makes this document appear as historic, rather than a new RFC! >> As noted above, I think there would be support for a rewrite if some = folks wanted to take that on. > Could the WG consider to also add the first two sentences to the = security considerations? Sorry, which two sentences? >=20 > Gorry >=20 > P.S. A few more out-dated statements abiut TCP, based on the way = specific stacks work when the original was written: >=20 > - The phrase below needs to be removed also, since not all TCP stacks = behave in this way anymore: > ", which is always a multiple of the segment size" >=20 > - There was very specific detailis relating to 4.2BSD TCP = implementations, which would have been better not being here. >=20 >=20 OK, I can remove both. --Apple-Mail=_BA125144-D743-4BD9-923D-DD79D54571BC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY2DEsAAoJEK7rdBF357uokT0H/2VCVMjQgoGMDl42peaiitp6 ZcL7MwA59BVUaHTv/fwR7FdHgSKZ5JwyQI/j2/fbriJSwxjb+FnPQO8194kkSSd4 mnrIpQnTxHfOczDRTwVuT1YLD5hNWj4R3sm8Ot+6qr7qm05DjjY4D32sj5LOq0eo QRfwAW1N6kZZEEwCrDtQe4fClj5V7287V7o6GnMvSKLM6XoKS6l+BRwxUmX7v6fk VFKpC7bqt1n4deud+dJKBuwP5lCBK3Ymij+tgn0NUh7kHD7c0uMBLsTngW9QsaFQ uLshSCMuj5jkS8ebdbJxtj5+xqEXQ/1wNwkjGrJPIr0/cYCEOJj+ioXXbucgkqU= =/Knx -----END PGP SIGNATURE----- --Apple-Mail=_BA125144-D743-4BD9-923D-DD79D54571BC-- From nobody Sun Mar 26 17:54:51 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D8C129441; Sun, 26 Mar 2017 17:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 cZNXDcE2cMEL; Sun, 26 Mar 2017 17:54:35 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBF3128E19; Sun, 26 Mar 2017 17:54:35 -0700 (PDT) Received: from Gs-MacBook-Pro.local (unknown [216.80.70.251]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 980F01B0173B; Mon, 27 Mar 2017 03:51:48 +0100 (BST) Message-ID: <58D862B2.5050607@erg.abdn.ac.uk> Date: Sun, 26 Mar 2017 19:54:10 -0500 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bob Hinden CC: "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, IPv6 List , IETF , "draft-ietf-6man-rfc1981bis@ietf.org" Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com> <58D518EA.5000508@erg.abdn.ac.uk> <4BC1763E-9D76-4EAA-B0B4-35620421736B@gmail.com> In-Reply-To: <4BC1763E-9D76-4EAA-B0B4-35620421736B@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 00:54:38 -0000 Thanks for those coments, which I cut, because I think they can now be turned to text. You asked a question about one comment, see below: GF: Could the WG consider to also add the first two sentences to the security considerations? Bob: Sorry, which two sentences? These were the two sentences, the rest of the para explained what PMTUD was, and probably could be left to the reader: "Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not rely upon network support for ICMP messages and is therefore considered more robust than standard PMTUD. It is not susceptible to "black holing" of ICMP message." Gorry From nobody Sun Mar 26 19:35:30 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4450E127735; Sun, 26 Mar 2017 19:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 iOTXrPFYo7U3; Sun, 26 Mar 2017 19:35:15 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 5DA331200A0; Sun, 26 Mar 2017 19:35:15 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id w11so23492324wrc.3; Sun, 26 Mar 2017 19:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Y14bXAoeZfUpvBy1Oe5b9AIwA4Yncv4zGU5sf9A9PfE=; b=XP4L7+9sC7lFhY/HDpg9PaPp1ujQMlt9veSfSxjzTMAeKc/OeIFtQkuj9laEAGers6 27rbwe+qpLtr4/5F0EMwPpmEAiuBUnPnwNjgjvrM5T+Sit46l/iAOuhmGS2Vz2uUFnTE gNEONUEyYzbbY7Ln+C1QskB9eQ3BGDpLSsnIzPJ+idFRBx3U9sECY4fprGsD9JTisTJk pyZGPRqP05pF8r4iOyKAONdcDbMQ1R3hAmYyIByT0vb5JHjmkenEXEnp6IRee5QmT9np Ll2CXzRKqvKRlkm+OVAx7W9lx2LCyz82OKEhGAl/uYWtUHo3WiBxn8JfaIscf+pVXKeK ltVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Y14bXAoeZfUpvBy1Oe5b9AIwA4Yncv4zGU5sf9A9PfE=; b=A9BoI5lD+uHVyq3D0+5427zGd3gpIl4zSHGvcCrSxy36xPDYXPKoNhdb6SGHEAW+df ELZ9ZfhLOa3FApxQMDi/RLnWBJeuCMfOv8KwnWyuDIgRO9TcU12QV02JoHDKos5tR8CX wIjUFrMWZbv7fNtuumc3GO4ReDJiixk+rdYdel6LDLuRONKCNwhuUsYTZQQRrBokHNBM no3NFe2KvtPWjsVb3+jSTWQURv4YVooOk0SBixG9YlZdYCcVUC0LovYfamKD3DEQfoqT 61SN3HEoblu+kl/gwOZTAGrhB0HNnej5YEJ6hSgRU0MngLeFk9Vb/UiI1IfSSRTDHZOY t/hg== X-Gm-Message-State: AFeK/H1FaWewkcSpWla76f8/6+oGyuoeQm2xSxpxPgGqF8NMmqPQNolcUUcsb6ttj1ytNg== X-Received: by 10.223.162.130 with SMTP id s2mr19298484wra.149.1490582113932; Sun, 26 Mar 2017 19:35:13 -0700 (PDT) Received: from dhcp-9201.meeting.ietf.org (dhcp-9201.meeting.ietf.org. [31.133.146.1]) by smtp.gmail.com with ESMTPSA id u145sm12442868wmu.1.2017.03.26.19.35.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2017 19:35:12 -0700 (PDT) From: Bob Hinden Message-Id: <18CAF7CE-FDC1-46AD-9857-D4475564F4FA@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4C8AF37D-719F-4B29-B836-FC94BA0F810E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Last Call: (Path MTU Discovery for IP version 6) to Internet Standard Date: Sun, 26 Mar 2017 21:35:08 -0500 In-Reply-To: <58D862B2.5050607@erg.abdn.ac.uk> Cc: Bob Hinden , "tsv-area@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, IPv6 List , IETF , "draft-ietf-6man-rfc1981bis@ietf.org" To: gorry@erg.abdn.ac.uk References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <58A33D08.4090505@erg.abdn.ac.uk> <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com> <58D518EA.5000508@erg.abdn.ac.uk> <4BC1763E-9D76-4EAA-B0B4-35620421736B@gmail.com> <58D862B2.5050607@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 02:35:17 -0000 --Apple-Mail=_4C8AF37D-719F-4B29-B836-FC94BA0F810E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Gorry, > On Mar 26, 2017, at 7:54 PM, Gorry Fairhurst = wrote: >=20 > Thanks for those coments, which I cut, because I think they can now be = turned to text. You asked a question about one comment, see below: >=20 > GF: > Could the WG consider to also add the first two sentences to the = security considerations? > Bob: > Sorry, which two sentences? >=20 > These were the two sentences, the rest of the para explained what = PMTUD was, and probably could be left to the reader: >=20 > "Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not > rely upon network support for ICMP messages and is therefore > considered more robust than standard PMTUD. It is not susceptible to > "black holing" of ICMP message.=E2=80=9D OK, I can add that. Thanks, Bob >=20 > Gorry >=20 --Apple-Mail=_4C8AF37D-719F-4B29-B836-FC94BA0F810E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY2HpcAAoJEK7rdBF357uoSVoH/iVdpGHz8JGR3UhiN/C3zWJK lulo/fQRKO3ITqwFnXa4zGNQbmkkNoVLaZ2M9nKHkqrpspoWwwMAGPvgTOKZt4sM 1WnUQadwbNW6Kyhr1YzxNXdQ/Ih5ifB81oagqLDNpbMK6mlPMq3GFcfCClr+Jofi YF4pUhPifVB58EufDHqdKMHtjVSqorAZCl9ePBcFyv4X37eyUrwTylPcH5qmVz3U aSeA8s96c8RVc6ZmgiyphGpsw3W6X93BIYwASUpH6uvzqk5cHSPIYw/9281KvCA1 3UrsE873C+qFJjmuMsnvl6sSb0DO7B2LNWR44XwtF6eoTf+Ocp8NFgaZ7H7v5D0= =G4Fz -----END PGP SIGNATURE----- --Apple-Mail=_4C8AF37D-719F-4B29-B836-FC94BA0F810E-- From nobody Mon Mar 27 12:56:29 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEC7129488 for ; Mon, 27 Mar 2017 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 4U1qt5toG6uY for ; Mon, 27 Mar 2017 12:56:25 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B017C1288B8 for ; Mon, 27 Mar 2017 12:56:24 -0700 (PDT) Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 27 Mar 2017 20:56:22 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 27 Mar 2017 20:56:22 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Mar 2017 20:56:00 +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.1210.000; Mon, 27 Mar 2017 20:56:00 +0100 From: To: Subject: tsvarea notes /minutes Thread-Topic: tsvarea notes /minutes Thread-Index: AdKnNCIdIhopElUYQlSo8GtfmW7fXQ== Date: Mon, 27 Mar 2017 19:56:00 +0000 Message-ID: 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.216.161.27] Content-Type: multipart/alternative; boundary="_000_f107dc15237f4565b0573e88fdbf5254rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 19:56:27 -0000 --_000_f107dc15237f4565b0573e88fdbf5254rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I took some rough notes during the tsvarea meeting (1-3pm Monday) Please correct & supplement as needed http://etherpad.tools.ietf.org:9000/p/notes-ietf-98-tsvarea thanks phil --_000_f107dc15237f4565b0573e88fdbf5254rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I took some rough notes during the tsvarea meeting (1-3pm Monday)<= o:p>

Please correct & supplement as needed

http://etherpa= d.tools.ietf.org:9000/p/notes-ietf-98-tsvarea

thanks=

phil

 

--_000_f107dc15237f4565b0573e88fdbf5254rew09926dag03bdomain1sy_-- From nobody Tue Mar 28 10:47:46 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75A5129704; Tue, 28 Mar 2017 10:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 ONTwHnsQ0g_J; Tue, 28 Mar 2017 10:47:43 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 34FD612971E; Tue, 28 Mar 2017 10:47:42 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id v76so58775305ywg.0; Tue, 28 Mar 2017 10:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=O8Zf+EhWacRVIErv56yXG0otBz18OdZzlRwZmd+u6ro=; b=Q8Un7PU9NMtTwRn7VtBqcFUA/iEOrt3Wm8M6aFRfFiPPMItX2CiRtFAQMZOCcTXI/c C1tqOIgWsBn0jItvDfhOhzyBfcj6mkBk/Kgvs6NaeUK8r+D/XR32peYVi5XWizLw1zgU Aynb/icnzPTyBtoU8o0uhu1xGR7FMavY0HqEb2m3a5yb28TlT5tErkCMLxHp6SasVUVF zrOod/Libnepjs8miBJmrSyAalAfc/mwnGA3rrjHEkC35V8Mqy4A5ykpJRvP3pdA6fWQ YZi1kKmPQpmowKuGgPzFhuS+nWuxVUu/6PetPnYBPGYnI+clupOdpWl4ut+kKzLVlfS+ pmUA== 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; bh=O8Zf+EhWacRVIErv56yXG0otBz18OdZzlRwZmd+u6ro=; b=ImwhFlgg9PiyC33onm3sQQtxBrffu2Nh5I4PpQjhdKSr+1bK6StVvB4POyZ4xn554h B6JZvYegCfn/D+SVi0L7DkZwmGhVhr19pUWHK5JZl64ZqzOdBm6TFV6eLQwDpLgDgpCd 5hP/Fq5L2Rlg7P2fp7e/W+HOfQUNHRCVNPlyamCIObklVCjUPhyWuypbfeyycrPBEgIw ir3b+fYDMNgigO4bfoliaz/hSFzTMFCVesD/0XAzsX1AH31QfTlZlXjq7rrguLqK7YdP 9mJKtIV3tC+XShtosKhsjFAiwxyg3bh8Dc+xSDAG1E4isM22dQTXPBSvbyX1pJxSZLb4 +GMg== X-Gm-Message-State: AFeK/H0988PTA26wWapf/k4a9hSgOCcug9iLPY1ukwIXJOePqH/HwcmFz/QSpjOi0KU+9entaFRRYR2qiUj2YA== X-Received: by 10.37.64.20 with SMTP id n20mr21760080yba.198.1490723256475; Tue, 28 Mar 2017 10:47:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Tue, 28 Mar 2017 10:47:36 -0700 (PDT) Received: by 10.37.73.129 with HTTP; Tue, 28 Mar 2017 10:47:36 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Tue, 28 Mar 2017 12:47:36 -0500 Message-ID: Subject: Re: TSV AD office hours at IETF 97 To: "tsv-area@ietf.org >> \"tsv-area@ietf.org\"" , tsv-chairs@ietf.org Content-Type: multipart/alternative; boundary=001a11c029b2292b7e054bce0e1b Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 17:47:45 -0000 --001a11c029b2292b7e054bce0e1b Content-Type: text/plain; charset=UTF-8 Just to let people know - the TSV AD office hours are at 1300 today, in the Bianco room, on the third floor of the Swissotel. You can't get there via elevator from the conference center where most of the IETF meeting rooms are - go to the hotel lobby and use the hotel elevators. (Funny story - Mirja and I made the reservation so long ago that the IESG wiki still had IETF 97 room assignments - sorry!!!) Spencer and Mirja On Oct 21, 2016 1:50 PM, "Spencer Dawkins at IETF" < spencerdawkins.ietf@gmail.com> wrote: > Just to let people know, Mirja and I will be available to talk about > things that require TSV AD attention at 11:10-12:10 on Thursday Morning > (session II). > > We have reserved Park Ballroom 3 for this. > > If you'd like to talk with us, please let us know that you're coming, and > what you'd like to talk about (this time, we've reserved an hour, but can > schedule other times if we need to). > > Thanks, > > Spencer and Mirja > > --001a11c029b2292b7e054bce0e1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to let people know - the TSV AD office hours are at = 1300 today, in the Bianco room, on the third floor of the Swissotel.=C2=A0<= div dir=3D"auto">
You can't get there via el= evator from the conference center where most of the IETF meeting rooms are = - go to the hotel lobby and use the hotel elevators.

(Funny story - Mirja and I made the reservatio= n so long ago that the IESG wiki still had IETF 97 room assignments - sorry= !!!)

Spencer and Mirja

On Oct = 21, 2016 1:50 PM, "Spencer Dawkins at IETF" <spencerdawkins.ietf@gmail= .com> wrote:
Just to let people know, Mirja and I will be availabl= e to talk about things that require TSV AD attention at=C2=A011:10-12:10 on Thursday Morning (session II).
We ha= ve reserved Park Ballroom 3 for this.
=
If you'd like to talk with us= , please let us know that you're coming, and what you'd like to tal= k about (this time, we've reserved an hour, but can schedule other time= s if we need to).

Thanks,

Spencer and Mirja

--001a11c029b2292b7e054bce0e1b-- From nobody Fri Mar 31 06:41:18 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105431296A1; Fri, 31 Mar 2017 06:41:11 -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, RCVD_IN_DNSWL_MED=-2.3, 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 A_k-sTe4106X; Fri, 31 Mar 2017 06:41:08 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 3BBD91296B9; Fri, 31 Mar 2017 06:41:07 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1ctwnZ-0002jO-1Z; Fri, 31 Mar 2017 15:41:05 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id EF061B003E4; Fri, 31 Mar 2017 15:41:04 +0200 (CEST) To: tsv-area@ietf.org, "iccrg@irtf.org" From: "Bless, Roland (TM)" Subject: Bufferbloat and Congestion Control Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> Date: Fri, 31 Mar 2017 15:41:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1490967665.128229005 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 13:41:11 -0000 Hi, thanks to the session recordings I just listened to the very interesting ICCRG related discussion in the tsvarea meeting from Monday. Lars Eggert said something like: "Bufferbloat is something that a congestion controller can't really do anything about anyway... it's not necessarily a congestion control problem." I believe that this statement is not correct. A large buffer will not be filled completely by a delay-based congestion control (e.g., Vegas was a very early one). Thus even if the buffer is large, the queuing delay doesn't increase dramatically and we wouldn't see that bufferbloat effect so prominently (as in slide 3 of https://www.ietf.org/proceedings/98/slides/slides-98-tsvarea-sessb-reflections-on-congestion-control-praveen-balasubramanian-00.pdf). So if _everyone_ would use such a delay-based variant, we wouldn't have the bufferbloat problem. However, since we have more loss-based congestion control variants deployed, which will fill a tail-drop buffer completely, such delay-based variants get suppressed and cannot get a reasonable share of the bottleneck bandwidth. Therefore, several variants have a fallback to a more aggressive mode in order to get a reasonable share (I think Christian Huitema also referred to this by the different modes). What could help is some kind of co-existence mechanism that separates queue-filling TCP CC variants from delay-based variants (e.g., see http://ieeexplore.ieee.org/document/7796842/ for details). So IMHO getting rid of the queue filling variants would be useful, but is probably hard in practice, i.e., replacing them isn't easy due to the co-existence problem. Consequently, fighting against bufferbloat could be done in the network using AQMs (enforcing shorter queues) or by using a different congestion control algorithm (trying to limit inflicted queuing delay), or even by a combination of both. However, what delay and throughput performance can be achieved with AQMs is limited, so better performance in both metrics requires eventually a better congestion control algorithm. Regards, Roland From nobody Fri Mar 31 07:02:11 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127021297F1 for ; Fri, 31 Mar 2017 07:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 F1kUDPU5Kbz0 for ; Fri, 31 Mar 2017 07:02:06 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 189CB1296A4 for ; Fri, 31 Mar 2017 07:02:06 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctx7s-0000Yo-Et for tsv-area@ietf.org; Fri, 31 Mar 2017 16:02:04 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctx7r-000BMv-L1; Fri, 31 Mar 2017 16:02:04 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [iccrg] Bufferbloat and Congestion Control From: Michael Welzl In-Reply-To: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> Date: Fri, 31 Mar 2017 09:02:00 -0500 Cc: tsv-area@ietf.org, "iccrg@irtf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> To: "Bless, Roland (TM)" X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 6 sum msgs/h 3 total rcpts 53421 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.036, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AAE6BC9A661B9E548316145130387E7720BBB207 X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 122 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:02:09 -0000 Hi Roland, I agree with everything, except in your email below, everywhere: s/delay/delay or ECN I state this because it=E2=80=99s my opinion but also to hopefully = prevent a flood of long emails related to ECN=E2=80=A6 Cheers, Michael > On Mar 31, 2017, at 8:41 AM, Bless, Roland (TM) = wrote: >=20 > Hi, >=20 > thanks to the session recordings I just listened to the very > interesting ICCRG related discussion in the tsvarea meeting from > Monday. >=20 > Lars Eggert said something like: > "Bufferbloat is something that a congestion controller > can't really do anything about anyway... > it's not necessarily a congestion control problem." >=20 > I believe that this statement is not correct. > A large buffer will not be filled completely by a delay-based > congestion control (e.g., Vegas was a very early > one). Thus even if the buffer is large, the queuing > delay doesn't increase dramatically and we wouldn't > see that bufferbloat effect so prominently (as in slide 3 of > = https://www.ietf.org/proceedings/98/slides/slides-98-tsvarea-sessb-reflect= ions-on-congestion-control-praveen-balasubramanian-00.pdf). >=20 > So if _everyone_ would use such a delay-based variant, we wouldn't > have the bufferbloat problem. >=20 > However, since we have more loss-based congestion control variants > deployed, which will fill a tail-drop buffer completely, such > delay-based variants get suppressed and cannot get a reasonable share > of the bottleneck bandwidth. Therefore, several variants have a > fallback to a more aggressive mode in order to get a reasonable > share (I think Christian Huitema also referred to this by the = different > modes). What could help is some kind of co-existence mechanism that > separates queue-filling TCP CC variants from delay-based variants > (e.g., see http://ieeexplore.ieee.org/document/7796842/ for details). > So IMHO getting rid of the queue filling variants would be useful, > but is probably hard in practice, i.e., replacing them isn't easy > due to the co-existence problem. >=20 > Consequently, fighting against bufferbloat could be done in the = network > using AQMs (enforcing shorter queues) or by using a different > congestion control algorithm (trying to limit inflicted queuing = delay), > or even by a combination of both. However, what delay and throughput > performance can be achieved with AQMs is limited, so better = performance > in both metrics requires eventually a better congestion control = algorithm. >=20 > Regards, > Roland >=20 > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg From nobody Fri Mar 31 07:25:26 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B87127A97 for ; Fri, 31 Mar 2017 07:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 V4dpY6Y3TkV6 for ; Fri, 31 Mar 2017 07:25:16 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 C86FD1294EE for ; Fri, 31 Mar 2017 07:25:16 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id b187so62043274oif.0 for ; Fri, 31 Mar 2017 07:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LSilJEUzmYPMlfnyyxXqTx/hUBGQghKY4cz4adRqtEo=; b=gkRKmrAR5Qz6Vl1u89VQ4akTCF40iFnFGi9WiK7S9DMA+TzPBQuXYwYzDDyrCR5X5P Xj5rRD/a5+GVYIPqdqsgLf0jagBBxDM8UzMCtKitWiQzh6mHZ3IgBVEl1uKH7KV5gvfs ce3iKQtH3v4Pk6XHZcC6oXWpdSE11gAyh/NzECHHVBKZUKKDTlp9GXve85qhLvlI/2QR i4ZW/eojtDkcxLblM4O1OSBae/tRYdsq5o696K7BvA8J4VobG8egu+8Ayk71kbWdm4mR qSPYQWuELbmQgk8gsYygBmHvDfP11UI137LoEz/kODl8w75Z7OQ5N7cnlKrX/WbRNLsk Eg4Q== 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=LSilJEUzmYPMlfnyyxXqTx/hUBGQghKY4cz4adRqtEo=; b=AwpTwRptOalPfrohEzbOQHL1P1vUVE2wu+Y0+wnk471Dh/GUali1fi2cA3uaau2vMn 6FBu+GRUkJmGEpcZZEBrOpLf1NyL7tbXIRDrjXaCOgCBeITqfUw8iFQ6HEk+DXHcrl8/ N/0a37GGKY4Z/YqwEW1knlOeWJuFJs/MuUQYzK+HXsj4PTQgM1Qwx0zEKNhADwKwrSCF d8Pmv2u3NsMdcANyLfqvPVxp8apAvcR2uNYPHwST8PaKZQhz70Bb0wZCFBUC3ddzmtzI 0hinreMTdeJHe3q5vDTI2a8kee8GORg3CzFdBedRpy+uYEfPLxrbAYknJTNsX5KDSNLi At6g== X-Gm-Message-State: AFeK/H2yqFaPrxQ0Ea5tnLpnqoarOx2tKe5AOljPMsSfVZz0lXjLEKnKalrvlP5+Xxsz0w4nHaGSTKV4BODPqVBu X-Received: by 10.202.78.10 with SMTP id c10mr1737288oib.189.1490970315835; Fri, 31 Mar 2017 07:25:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.81.84 with HTTP; Fri, 31 Mar 2017 07:24:45 -0700 (PDT) In-Reply-To: References: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> From: Neal Cardwell Date: Fri, 31 Mar 2017 10:24:45 -0400 Message-ID: Subject: Re: [iccrg] Bufferbloat and Congestion Control To: Michael Welzl Cc: "Bless, Roland (TM)" , "iccrg@irtf.org" , tsv-area@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:25:19 -0000 I would agree the bufferbloat is susceptible to mitigation by congestion control at the sender. One relevant alternative I have not seen mentioned in this thread is BBR congestion control. (For BBR info, including the CACM paper and links to the BBR talks at the last 2 ICCRG sessions, see: https://groups.google.com/d/forum/bbr-dev ) Defeating bufferbloat was one of the core goals of BBR, and our experience deploying it for YouTube shows it achieves this goal. BBR flows sharing with other BBR flows avoid filling bloated buffers, and instead maintain a reasonable-sized queue. But when BBR flows share a bottleneck with a loss-based CC like Reno or CUBIC, the model of the path used by the BBR flows adapts to the standing queue created by the loss-based flows, scaling up cwnd so that the BBR flows are not starved (as delay-based schemes like Vegas are starved in such scenarios). If the loss-based flows leave the bottleneck, BBR will quickly converge back to its preferred operating regime of small queues. BBR is deployed for YouTube and Google TCP traffic, and available in Linux TCP and QUIC, and work is under way at Netflix to implement it for FreeBSD TCP. Folks concerned about bufferbloat should keep it in mind as an available alternative. neal ps: AQMs are also good. On Fri, Mar 31, 2017 at 10:02 AM, Michael Welzl wrote: > Hi Roland, > > I agree with everything, except in your email below, everywhere: > > s/delay/delay or ECN > > I state this because it=E2=80=99s my opinion but also to hopefully preven= t a flood of long emails related to ECN=E2=80=A6 > > Cheers, > Michael > > >> On Mar 31, 2017, at 8:41 AM, Bless, Roland (TM) w= rote: >> >> Hi, >> >> thanks to the session recordings I just listened to the very >> interesting ICCRG related discussion in the tsvarea meeting from >> Monday. >> >> Lars Eggert said something like: >> "Bufferbloat is something that a congestion controller >> can't really do anything about anyway... >> it's not necessarily a congestion control problem." >> >> I believe that this statement is not correct. >> A large buffer will not be filled completely by a delay-based >> congestion control (e.g., Vegas was a very early >> one). Thus even if the buffer is large, the queuing >> delay doesn't increase dramatically and we wouldn't >> see that bufferbloat effect so prominently (as in slide 3 of >> https://www.ietf.org/proceedings/98/slides/slides-98-tsvarea-sessb-refle= ctions-on-congestion-control-praveen-balasubramanian-00.pdf). >> >> So if _everyone_ would use such a delay-based variant, we wouldn't >> have the bufferbloat problem. >> >> However, since we have more loss-based congestion control variants >> deployed, which will fill a tail-drop buffer completely, such >> delay-based variants get suppressed and cannot get a reasonable share >> of the bottleneck bandwidth. Therefore, several variants have a >> fallback to a more aggressive mode in order to get a reasonable >> share (I think Christian Huitema also referred to this by the different >> modes). What could help is some kind of co-existence mechanism that >> separates queue-filling TCP CC variants from delay-based variants >> (e.g., see http://ieeexplore.ieee.org/document/7796842/ for details). >> So IMHO getting rid of the queue filling variants would be useful, >> but is probably hard in practice, i.e., replacing them isn't easy >> due to the co-existence problem. >> >> Consequently, fighting against bufferbloat could be done in the network >> using AQMs (enforcing shorter queues) or by using a different >> congestion control algorithm (trying to limit inflicted queuing delay), >> or even by a combination of both. However, what delay and throughput >> performance can be achieved with AQMs is limited, so better performance >> in both metrics requires eventually a better congestion control algorith= m. >> >> Regards, >> Roland >> >> _______________________________________________ >> iccrg mailing list >> iccrg@irtf.org >> https://www.irtf.org/mailman/listinfo/iccrg > > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg From nobody Fri Mar 31 07:46:34 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9A312987B for ; Fri, 31 Mar 2017 07:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qdCe9WgBu4bu for ; Fri, 31 Mar 2017 07:46:25 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 05C351298D2 for ; Fri, 31 Mar 2017 07:46:24 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctxoj-0000Xg-Qt; Fri, 31 Mar 2017 16:46:21 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctxoi-0003sL-K5; Fri, 31 Mar 2017 16:46:21 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [iccrg] Bufferbloat and Congestion Control From: Michael Welzl In-Reply-To: Date: Fri, 31 Mar 2017 09:46:18 -0500 Cc: "Bless, Roland (TM)" , tsv-area@ietf.org, "iccrg@irtf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <87BB71A5-C1E7-4E36-B16E-54B0A525D4A5@ifi.uio.no> References: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> To: Neal Cardwell X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 3 sum rcpts/h 13 sum msgs/h 5 total rcpts 53428 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.035, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 083B756A8962106EDAE46A45745F2DF6C5DC213F X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 124 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:46:28 -0000 Hi, As a researcher with possible interest in evaluating BBR, my question = would be: what is =E2=80=9Cit=E2=80=9D ? My understanding is that we have: - 2 IETF presentations - A paper in ACM Queue - Linux code and none of these three things are really equal. ( Sorry if I=E2=80=99m = wrong! Maybe it=E2=80=99s only the ACM Queue paper that doesn=E2=80=99t = quite match the rest? ) If this is true, it would be good to try to write the whole thing up in = a draft so we could have a reference description of what BBR really is. Else, what would you consider the most important reference among the = three items above? The Linux code, I guess? Cheers, Michael > On Mar 31, 2017, at 9:24 AM, Neal Cardwell = wrote: >=20 > I would agree the bufferbloat is susceptible to mitigation by > congestion control at the sender. >=20 > One relevant alternative I have not seen mentioned in this thread is > BBR congestion control. (For BBR info, including the CACM paper and > links to the BBR talks at the last 2 ICCRG sessions, see: > https://groups.google.com/d/forum/bbr-dev ) >=20 > Defeating bufferbloat was one of the core goals of BBR, and our > experience deploying it for YouTube shows it achieves this goal. BBR > flows sharing with other BBR flows avoid filling bloated buffers, and > instead maintain a reasonable-sized queue. But when BBR flows share a > bottleneck with a loss-based CC like Reno or CUBIC, the model of the > path used by the BBR flows adapts to the standing queue created by the > loss-based flows, scaling up cwnd so that the BBR flows are not > starved (as delay-based schemes like Vegas are starved in such > scenarios). If the loss-based flows leave the bottleneck, BBR will > quickly converge back to its preferred operating regime of small > queues. >=20 > BBR is deployed for YouTube and Google TCP traffic, and available in > Linux TCP and QUIC, and work is under way at Netflix to implement it > for FreeBSD TCP. Folks concerned about bufferbloat should keep it in > mind as an available alternative. >=20 > neal >=20 > ps: AQMs are also good. >=20 >=20 >=20 >=20 > On Fri, Mar 31, 2017 at 10:02 AM, Michael Welzl = wrote: >> Hi Roland, >>=20 >> I agree with everything, except in your email below, everywhere: >>=20 >> s/delay/delay or ECN >>=20 >> I state this because it=E2=80=99s my opinion but also to hopefully = prevent a flood of long emails related to ECN=E2=80=A6 >>=20 >> Cheers, >> Michael >>=20 >>=20 >>> On Mar 31, 2017, at 8:41 AM, Bless, Roland (TM) = wrote: >>>=20 >>> Hi, >>>=20 >>> thanks to the session recordings I just listened to the very >>> interesting ICCRG related discussion in the tsvarea meeting from >>> Monday. >>>=20 >>> Lars Eggert said something like: >>> "Bufferbloat is something that a congestion controller >>> can't really do anything about anyway... >>> it's not necessarily a congestion control problem." >>>=20 >>> I believe that this statement is not correct. >>> A large buffer will not be filled completely by a delay-based >>> congestion control (e.g., Vegas was a very early >>> one). Thus even if the buffer is large, the queuing >>> delay doesn't increase dramatically and we wouldn't >>> see that bufferbloat effect so prominently (as in slide 3 of >>> = https://www.ietf.org/proceedings/98/slides/slides-98-tsvarea-sessb-reflect= ions-on-congestion-control-praveen-balasubramanian-00.pdf). >>>=20 >>> So if _everyone_ would use such a delay-based variant, we wouldn't >>> have the bufferbloat problem. >>>=20 >>> However, since we have more loss-based congestion control variants >>> deployed, which will fill a tail-drop buffer completely, such >>> delay-based variants get suppressed and cannot get a reasonable = share >>> of the bottleneck bandwidth. Therefore, several variants have a >>> fallback to a more aggressive mode in order to get a reasonable >>> share (I think Christian Huitema also referred to this by the = different >>> modes). What could help is some kind of co-existence mechanism that >>> separates queue-filling TCP CC variants from delay-based variants >>> (e.g., see http://ieeexplore.ieee.org/document/7796842/ for = details). >>> So IMHO getting rid of the queue filling variants would be useful, >>> but is probably hard in practice, i.e., replacing them isn't easy >>> due to the co-existence problem. >>>=20 >>> Consequently, fighting against bufferbloat could be done in the = network >>> using AQMs (enforcing shorter queues) or by using a different >>> congestion control algorithm (trying to limit inflicted queuing = delay), >>> or even by a combination of both. However, what delay and throughput >>> performance can be achieved with AQMs is limited, so better = performance >>> in both metrics requires eventually a better congestion control = algorithm. >>>=20 >>> Regards, >>> Roland >>>=20 >>> _______________________________________________ >>> iccrg mailing list >>> iccrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/iccrg >>=20 >> _______________________________________________ >> iccrg mailing list >> iccrg@irtf.org >> https://www.irtf.org/mailman/listinfo/iccrg >=20 > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg From nobody Fri Mar 31 07:47:30 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38EC126B7F for ; Fri, 31 Mar 2017 07:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 050vgHNiRu5c for ; Fri, 31 Mar 2017 07:47:26 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (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 74A90129991 for ; Fri, 31 Mar 2017 07:47:24 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id b187so9380834oif.3 for ; Fri, 31 Mar 2017 07:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=io3NbP5pgLnsgV8v7zn9jcKXXcGWGaY2BG5qORxSbF0=; b=Dqo+F5la7Lxc6dxk+B31t95vkJX2kw7ypNHbg/AcjxBnXZOygWJsTJF/sxK3ZOnzEk biviFNXpDMA+OR5BsZXMYsZ9UqpXWV7Fv6doPL99rtQfuHXF2jLZITvh/7VI2i+8x+UK 3Jd4OO6TKPJ1dy2tsMKNN4CmKQAWws7qlFMXXaoXz6i6NGQZm90mLcFFzwDQ6vG4s1y8 /dtCQUcTmRy0eKie4+ZX7NYHiTUNb2ZPdAQBeDHkxEV98ESwc4TH3MC/yd9+uyD9upqV QgBtBDJwBdTv+W0fvWffrwd0P3ri6YcaGIOQEfG0Z4jkLrcsPEKSjlZoZGyoGLjYcGBj l9Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=io3NbP5pgLnsgV8v7zn9jcKXXcGWGaY2BG5qORxSbF0=; b=N3oOZ5Xzv89v9phidfWEFjwy8LowaLy6RZSzYzTHtqdQkCIw7Y3tigR9OsuKxEd6W3 WTo9g5wsLePHBTKTZlgy81LtS3C905VDY+GNG8WC4UPD0baOVMVZ3lPZNcElExupMORX O8CogLPQED9OeT+qFjt8EHwHjhEIkwPDDEvM7Ig2bb0YYkcQLqjk5BVl9uwPwZCQ1n5r zRfbdsEhDfYcDlxCTaTcwAJx29j72F7hAChaqP3cpccJN42umpttdzZG5P7TfDDTcNdO DWjd64jkUAmMrGZbdyVphKQs4dqYlXVMtiAVgEAaGAyuxjI5JIgN0dVDXXiICnvGRiMU /8QA== X-Gm-Message-State: AFeK/H3N7mVdlix/smoM9f58Bn4VgTafSU9ORe+8I9xztQjqJPRbjuDLBHagFvQLBe3csBaJzVDDUEghTwqNiA== X-Received: by 10.202.66.131 with SMTP id p125mr1847483oia.57.1490971643648; Fri, 31 Mar 2017 07:47:23 -0700 (PDT) MIME-Version: 1.0 Sender: gettysjim@gmail.com Received: by 10.74.142.129 with HTTP; Fri, 31 Mar 2017 07:47:23 -0700 (PDT) In-Reply-To: References: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> From: Jim Gettys Date: Fri, 31 Mar 2017 10:47:23 -0400 X-Google-Sender-Auth: ACQfJBCUx0ZjNHh_DGkrn6Q8BDM Message-ID: Subject: Re: [iccrg] Bufferbloat and Congestion Control To: Neal Cardwell Cc: Michael Welzl , "Bless, Roland (TM)" , "tsv-area@ietf.org" , "iccrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:47:29 -0000 17 at 10:24 AM, Neal Cardwell wrote: > I would agree the bufferbloat is susceptible to mitigation by > congestion control at the sender. > > One relevant alternative I have not seen mentioned in this thread is > BBR congestion control. (For BBR info, including the CACM paper and > links to the BBR talks at the last 2 ICCRG sessions, see: > https://groups.google.com/d/forum/bbr-dev ) > > Defeating bufferbloat was one of the core goals of BBR, and our > experience deploying it for YouTube shows it achieves this goal. BBR > flows sharing with other BBR flows avoid filling bloated buffers, and > instead maintain a reasonable-sized queue. But when BBR flows share a > bottleneck with a loss-based CC like Reno or CUBIC, the model of the > path used by the BBR flows adapts to the standing queue created by the > loss-based flows, scaling up cwnd so that the BBR flows are not > starved (as delay-based schemes like Vegas are starved in such > scenarios). If the loss-based flows leave the bottleneck, BBR will > quickly converge back to its preferred operating regime of small > queues. > > BBR is deployed for YouTube and Google TCP traffic, and available in > Linux TCP and QUIC, and work is under way at Netflix to implement it > for FreeBSD TCP. Folks concerned about bufferbloat should keep it in > mind as an available alternative. > > neal > > ps: AQMs are also good. There are other issues that people need to keep in mind: Packet scheduling is *really* important. You really don't want to have a burst of packets monopolize your bottleneck link, particularly when that bottleneck may be small bandwidth. For example, my brother suffers on a DSL line, with something like 384K up and a megabit or two down. One full size packet @ 1mbps =3D=3D 13 milliseconds. Two of those packets is already human perceptible latency for some applications (and gamers and stock traders will tell you that even a single 13ms delay to their application is a significant disadvantage). On his line, even one packet upbound is of order 40ms. So while congestion avoidance is key to keeping TCP's behavior sane, it is *not* sufficient to keep latency to where it needs to be for many applications that share the bottleneck. Wonderful as BBR is (and I'm a great fan), it still can induce more than a BDP of queue: over continental paths, that's of order 100ms and more over intercontinental paths. And even one flow of something other than BBR can ruin your whole day completely. Getting everyone to convert to a delay based congestion system ain't ever going to happen as they don't compete properly, so finally having an algorithm like BBR that can be deployed is wonderful. In short, BBR will reduce the fraction of time latencies are out completely of control, but no TCP congestion control system by itself can get latencies to where they need to be for many applications. Jim On Fri, Mar 31, 20 > > > > > On Fri, Mar 31, 2017 at 10:02 AM, Michael Welzl wrot= e: >> Hi Roland, >> >> I agree with everything, except in your email below, everywhere: >> >> s/delay/delay or ECN >> >> I state this because it=E2=80=99s my opinion but also to hopefully preve= nt a flood of long emails related to ECN=E2=80=A6 >> >> Cheers, >> Michael >> >> >>> On Mar 31, 2017, at 8:41 AM, Bless, Roland (TM) = wrote: >>> >>> Hi, >>> >>> thanks to the session recordings I just listened to the very >>> interesting ICCRG related discussion in the tsvarea meeting from >>> Monday. >>> >>> Lars Eggert said something like: >>> "Bufferbloat is something that a congestion controller >>> can't really do anything about anyway... >>> it's not necessarily a congestion control problem." >>> >>> I believe that this statement is not correct. >>> A large buffer will not be filled completely by a delay-based >>> congestion control (e.g., Vegas was a very early >>> one). Thus even if the buffer is large, the queuing >>> delay doesn't increase dramatically and we wouldn't >>> see that bufferbloat effect so prominently (as in slide 3 of >>> https://www.ietf.org/proceedings/98/slides/slides-98-tsvarea-sessb-refl= ections-on-congestion-control-praveen-balasubramanian-00.pdf). >>> >>> So if _everyone_ would use such a delay-based variant, we wouldn't >>> have the bufferbloat problem. >>> >>> However, since we have more loss-based congestion control variants >>> deployed, which will fill a tail-drop buffer completely, such >>> delay-based variants get suppressed and cannot get a reasonable share >>> of the bottleneck bandwidth. Therefore, several variants have a >>> fallback to a more aggressive mode in order to get a reasonable >>> share (I think Christian Huitema also referred to this by the different >>> modes). What could help is some kind of co-existence mechanism that >>> separates queue-filling TCP CC variants from delay-based variants >>> (e.g., see http://ieeexplore.ieee.org/document/7796842/ for details). >>> So IMHO getting rid of the queue filling variants would be useful, >>> but is probably hard in practice, i.e., replacing them isn't easy >>> due to the co-existence problem. >>> >>> Consequently, fighting against bufferbloat could be done in the network >>> using AQMs (enforcing shorter queues) or by using a different >>> congestion control algorithm (trying to limit inflicted queuing delay), >>> or even by a combination of both. However, what delay and throughput >>> performance can be achieved with AQMs is limited, so better performance >>> in both metrics requires eventually a better congestion control algorit= hm. >>> >>> Regards, >>> Roland >>> >>> _______________________________________________ >>> iccrg mailing list >>> iccrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/iccrg >> >> _______________________________________________ >> iccrg mailing list >> iccrg@irtf.org >> https://www.irtf.org/mailman/listinfo/iccrg > > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg From nobody Fri Mar 31 08:00:20 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E174E12995F for ; Fri, 31 Mar 2017 08:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xoedp0E5HAE3 for ; Fri, 31 Mar 2017 08:00:17 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 B56551299D7 for ; Fri, 31 Mar 2017 08:00:16 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id b187so63241461oif.0 for ; Fri, 31 Mar 2017 08:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/6K8n4MCUPvRO1Ndm4TLfs2SHKkEibChXrb83DhQag8=; b=gV/mfgQwugAf2PqJGrbUNpQOle8J5sGrKQCqQA5J77TH1sLPLsBCNJhOdT9mYOX4DK JdDDSzwzj3RGiO0nbWZU89N1Lh7KzIEWIMErwTn+1Z/zf+KCU2YH7AZXGGCdzn5qPfpk QBHgmOHn+dufYVhUJR5QafJk3E3H8LAsIELSvu1/75Eoenrblyqr6tGVlnA8f8ZLmvFo Oy8CLdvk54REOiHW52VpP3R9LDz6+xKuECAzIR9x/UyxdqjjjE/f9ZoO5ouc5wG1j8vt yH+fIKAR8Mdhljz7nJMfWQqb9kbpbpZC1NcZgPCJNm1vz+TVCdUB7Jkw2kTT2xzIfS6x 164A== 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=/6K8n4MCUPvRO1Ndm4TLfs2SHKkEibChXrb83DhQag8=; b=sEc1zhvHtGbmam1VysdLKWxA4U+GSQOVEeg0JJcX/29FBiH5zvlMUhs+QpHOiAlPYa aeVyxopa23kPCIYXLekErl3ppl3rdIbL4MKDhuMwCGFaQkf8vnJ3m3n5d+yo1Af5zp64 8u/h5FkH2gkcncRA31UrcGyI8eneoGDMN/DetR4DpRuA3eU+8neWE7zhpu/aPbsgtRuf ksd+8JsovwPU8kJY2jboXOKGNJ+H+a4M/Oaq7LvB4s6jnZQqj8+3d0w7P1HS1V4Boxyt qJ2CLdhNEeMNPMguBYBfX4k46G/2+mdX0IGxx0m8kR6gyfWz+qkoT4ZrgqZBF08rUgyQ 8TSg== X-Gm-Message-State: AFeK/H31BWJ+z6PyF9ATKtOzTh+ZkpdgNG8s9ZHYjOM6VQsNBsiTf6xvvm5Qy6TZufzIt02TSsBH/Alsv7EU5bcw X-Received: by 10.202.50.131 with SMTP id y125mr71043oiy.105.1490972415834; Fri, 31 Mar 2017 08:00:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.172.87 with HTTP; Fri, 31 Mar 2017 07:59:45 -0700 (PDT) In-Reply-To: <87BB71A5-C1E7-4E36-B16E-54B0A525D4A5@ifi.uio.no> References: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> <87BB71A5-C1E7-4E36-B16E-54B0A525D4A5@ifi.uio.no> From: Neal Cardwell Date: Fri, 31 Mar 2017 10:59:45 -0400 Message-ID: Subject: Re: [iccrg] Bufferbloat and Congestion Control To: Michael Welzl Cc: "Bless, Roland (TM)" , tsv-area@ietf.org, "iccrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:00:19 -0000 On Fri, Mar 31, 2017 at 10:46 AM, Michael Welzl wrote: > Hi, > > As a researcher with possible interest in evaluating BBR, my question wou= ld be: what is =E2=80=9Cit=E2=80=9D ? > > My understanding is that we have: > - 2 IETF presentations > - A paper in ACM Queue > - Linux code > > and none of these three things are really equal. ( Sorry if I=E2=80=99m = wrong! Maybe it=E2=80=99s only the ACM Queue paper that doesn=E2=80=99t qu= ite match the rest? ) > If this is true, it would be good to try to write the whole thing up in a= draft so we could have a reference description of what BBR really is. > > Else, what would you consider the most important reference among the thre= e items above? The Linux code, I guess? Yes, the Linux TCP code would be the most important reference, since that's the most precise, and it's what's actually controlling YouTube and google.com TCP. That said, the Linux TCP code should very closely match the CACM/Queue paper. I can think of only one or two details in the gain cycling code that were added to the code in the middle of the paper editing process, and thus were not captured in the paper. And in turn, the ICCRG presentations should also very closely match the code and paper (except for the parts marked "experiments", eg the IETF 98 ICCRG slides 14-19). Please let us know if there are specific places where there are confusing divergences. We are working on writing a draft or similar prose spec for those who would prefer to use that as a reference. thanks, neal From nobody Fri Mar 31 08:44:14 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D6F1294DF for ; Fri, 31 Mar 2017 08:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 5Sp3B4T89OiQ for ; Fri, 31 Mar 2017 08:44:04 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 4E50612950A for ; Fri, 31 Mar 2017 08:44:03 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctyiX-00081L-Mm; Fri, 31 Mar 2017 17:44:01 +0200 Received: from swissotel07.s.subnet.rcn.com ([216.80.61.6] helo=[172.20.3.190]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ctyiW-0002f9-LL; Fri, 31 Mar 2017 17:44:01 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [iccrg] Bufferbloat and Congestion Control From: Michael Welzl In-Reply-To: Date: Fri, 31 Mar 2017 10:43:57 -0500 Cc: "Bless, Roland (TM)" , tsv-area@ietf.org, "iccrg@irtf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <142994F9-A927-4672-BFD4-C99ED3F685AB@ifi.uio.no> References: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> <87BB71A5-C1E7-4E36-B16E-54B0A525D4A5@ifi.uio.no> To: Neal Cardwell X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 216.80.61.6 is neither permitted nor denied by domain of ifi.uio.no) client-ip=216.80.61.6; envelope-from=michawe@ifi.uio.no; helo=[172.20.3.190]; X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 11 sum msgs/h 4 total rcpts 53433 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.010, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 38EEC29F6B72C1814A13E0CD540463942964B346 X-UiO-SPAM-Test: remote_host: 216.80.61.6 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 126 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:44:07 -0000 Hi, In line: > On Mar 31, 2017, at 9:59 AM, Neal Cardwell = wrote: >=20 > On Fri, Mar 31, 2017 at 10:46 AM, Michael Welzl = wrote: >> Hi, >>=20 >> As a researcher with possible interest in evaluating BBR, my question = would be: what is =E2=80=9Cit=E2=80=9D ? >>=20 >> My understanding is that we have: >> - 2 IETF presentations >> - A paper in ACM Queue >> - Linux code >>=20 >> and none of these three things are really equal. ( Sorry if I=E2=80=99= m wrong! Maybe it=E2=80=99s only the ACM Queue paper that doesn=E2=80=99t= quite match the rest? ) >> If this is true, it would be good to try to write the whole thing up = in a draft so we could have a reference description of what BBR really = is. >>=20 >> Else, what would you consider the most important reference among the = three items above? The Linux code, I guess? >=20 > Yes, the Linux TCP code would be the most important reference, since > that's the most precise, and it's what's actually controlling YouTube > and google.com TCP. >=20 > That said, the Linux TCP code should very closely match the CACM/Queue > paper. I can think of only one or two details in the gain cycling code > that were added to the code in the middle of the paper editing > process, and thus were not captured in the paper. And in turn, the > ICCRG presentations should also very closely match the code and paper > (except for the parts marked "experiments", eg the IETF 98 ICCRG > slides 14-19). Please let us know if there are specific places where > there are confusing divergences. That=E2=80=99s great to hear - my impression of differences was a mix of = =E2=80=9Cimpression from looking at things=E2=80=9D and =E2=80=9Cimpressio= n from what people say=E2=80=9D - so this confirmation that things = don=E2=80=99t really diverge so much is very useful, thanks! > We are working on writing a draft or similar prose spec for those who > would prefer to use that as a reference. Wonderful ! Thanks for that too! Cheers, Michael From nobody Fri Mar 31 10:20:52 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08405129613 for ; Fri, 31 Mar 2017 10:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 rQ8d2BVJGw1f for ; Fri, 31 Mar 2017 10:20:46 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 5E363129551 for ; Fri, 31 Mar 2017 10:20:46 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id b187so67977244oif.0 for ; Fri, 31 Mar 2017 10:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x1dfkHee2NZLEUESbTbnLGfOU4vg38a5bO/o6UTEdXA=; b=kK9WKcNcsGXM4NDRx5f1XM7Zq9tiQoxJ0muTmXBH6lbWP15OAis+k5h/BytSHYE9gH SJCZ1Sci8ftRWUVdw3ygHCFp1jq7GqHikZc4m6sfKWj+lionIHMYHdQe7iy5NkI2mB0R WO70syE5xidqeEyatFtl3a5DoUN6TWRD4TpPhW7QZNk01hiwEhu+4mMOw+9ouu0oahdn scBdGDzN3cmHqNraEEOdCLUNyJEG9W45oHhuCsiUsUhq+eLWq8NmegyTGg4bwUnx+c/M o590dO7UvwQPQVRzHpn5fgDV02xa5I2NNsXmb+ngW9exnYpKAdnBdNf7ZFq8isv64q6P Ku3Q== 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=x1dfkHee2NZLEUESbTbnLGfOU4vg38a5bO/o6UTEdXA=; b=PbBCWBhmh/3Tto8G8SV65h+z6ZG4QyMmdZ42oNAmRd6fsvDCpHUBeqtSDPJ1SL2GT1 8EjjU8qy3t/3Az8mjG1uFuGPGWXTRA/ACqoYt0oCe4vn5p0tXYSNoshNNpNjWTNZ4Dou 5RR+fDCFXePbXYfDL5jCnkIbb7P99KsE3KefExkhuzHDNhQoBCYi9BSOqPG5xAxQm99D 2HHDsbvjNcbHVqEEo6D028B+5anaUJO20BVxsVkl/70M3vf5uTgNdA4bJU1AGgB6TS1p I/+Yae85McKOZ9sC4bp8oqwsq/55i+dQKrt0aS2CrLbOzeTfDGWpChqYT20VJiYTwQpN C00w== X-Gm-Message-State: AFeK/H0SaQqRdCzP5cRLowQrsba/m6KzB3c8BrPVz9Gki8UAaIplMq7xUAJaYuNPXysitQC5eW0YWqH8VEo2Dwp1 X-Received: by 10.157.41.36 with SMTP id d33mr1323084otb.24.1490980845465; Fri, 31 Mar 2017 10:20:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.172.87 with HTTP; Fri, 31 Mar 2017 10:20:14 -0700 (PDT) In-Reply-To: References: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> From: Neal Cardwell Date: Fri, 31 Mar 2017 13:20:14 -0400 Message-ID: Subject: Re: [iccrg] Bufferbloat and Congestion Control To: Jim Gettys Cc: Michael Welzl , "Bless, Roland (TM)" , "tsv-area@ietf.org" , "iccrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 17:20:51 -0000 On Fri, Mar 31, 2017 at 10:47 AM, Jim Gettys wrote: > There are other issues that people need to keep in mind: > > Packet scheduling is *really* important. You really don't want to > have a burst of packets monopolize your bottleneck link, particularly > when that bottleneck may be small bandwidth. > > For example, my brother suffers on a DSL line, with something like > 384K up and a megabit or two down. > > One full size packet @ 1mbps == 13 milliseconds. Two of those packets > is already human perceptible latency for some applications (and gamers > and stock traders will tell you that even a single 13ms delay to their > application is a significant disadvantage). On his line, even one > packet upbound is of order 40ms. Yes, this is a great point. In the BBR team we are very conscious of the latency issues in low-bandwidth links, and this is something we focus on. For example, this consideration you mention is exactly why Linux TCP BBR chooses a TSO burst size of 1 packet (instead of the Linux TCP default of 2 packets) for bandwidths below 1.2Mbps. > So while congestion avoidance is key to keeping TCP's behavior sane, > it is *not* sufficient to keep latency to where it needs to be for > many applications that share the bottleneck. Wonderful as BBR is (and > I'm a great fan), it still can induce more than a BDP of queue: over > continental paths, that's of order 100ms and more over > intercontinental paths. The queue levels you mention can indeed be seen when there are multiple flows sharing a bottleneck and using the current version of BBR. There is nothing inherent about the BBR approach or framework that requires that particular level of queue, so one of our big focuses right now is testing some tweaks to the algorithm to reduce the degree of queuing in such scenarios. We discussed some of the experiments in pages 14-19 of this week's BBR talk: https://www.ietf.org/proceedings/98/slides/slides-98-iccrg-an-update-on-bbr-congestion-control-00.pdf > And even one flow of something other than BBR can ruin your whole day > completely. Getting everyone to convert to a delay based congestion > system ain't ever going to happen as they don't compete properly, so > finally having an algorithm like BBR that can be deployed is > wonderful. Thanks. It is also our sense that BBR provides performance and behavior that makes it deployable on today's Internet. > In short, BBR will reduce the fraction of time latencies are out > completely of control, but no TCP congestion control system by itself > can get latencies to where they need to be for many applications. Indeed, some very demanding latency-sensitive apps may need changes in the network to work well. Until those changes are widely deployed, and even afterward, my sense is that it's worth pushing congestion control to be as good as it can be. thanks, neal From nobody Fri Mar 31 10:36:35 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A787012996E for ; Fri, 31 Mar 2017 10:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uslVKkJMt2q1 for ; Fri, 31 Mar 2017 10:36:31 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 824E1129869 for ; Fri, 31 Mar 2017 10:36:31 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id b187so68456728oif.0 for ; Fri, 31 Mar 2017 10:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=s6K12bdI68ihnAcYfhUT296BE6u3AcBtQJgMRahXUYA=; b=mmhoMptEQGNJafgYI2rjlVuTTFccV7JTg2bJCznpMGOH9i7cXz3BbHoehgSg/dTYU+ 5aZsZQnPu1nEeoTqdlo0W5NoWvUuTfGGRT8WxzRb+dljj8HwBSiFm5qLNwFH2mKNFQAV KbB8DCaIorkPxGeZyXhLGGgtCYW4YlpVrKrdCJunIyzBV4h0Lex/wYWZ+hWktpJZ2KIB WOoAq+m5rOKIm3Tgq7wkYE6505EUQwWs8XiFw0plKK6RYGbFoY1yVJd+lh3d71aUhnc2 M5sXmp24OPbpqgaiCFpB2PsZHo59J4wHP5DMsw/J0pLRsEpiLJxnSOJZA0zHKk1BKrwS AJHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=s6K12bdI68ihnAcYfhUT296BE6u3AcBtQJgMRahXUYA=; b=GjX2OBYjziUcNHEm9Yb+X92kjGbZOsd26snZ2wqI/E9FYY/2PFDh5n7Le4aFzDDksI azziCt5k9MdGM8cnykhNl262hAjGFQbr/aXGzq2qjsuyUIFMrczbIf9c53isv/JuK88i 0qa8sEEzxVfCJD+HJRDEy4kZfEjalnuuTSZmGKtWzQCMsw0Ckj4OK8baYs4NoSXYFm/F Ak36CajNbK2akof0HAx+oBS9QbK2NQs+rzEimYAPJ7c9Qal1wWSbQ9ibN3hwtDDWUh22 XMYT+mGMPoPdqBycxJn1vEbj7ctP/uqIUk8YoX4y1rDzPbDe+79gPakuWRRAt9b7ZgF0 Ruhw== X-Gm-Message-State: AFeK/H289IBj4EeqLIiQ9ff+jYL+ETkx+hSlieCLxM1mgYkHGWFuCZHR0Gnk3DQ0oVvo7REd24+7cMCHGDNjdA== X-Received: by 10.157.10.197 with SMTP id 63mr2575920otq.211.1490981790685; Fri, 31 Mar 2017 10:36:30 -0700 (PDT) MIME-Version: 1.0 Sender: gettysjim@gmail.com Received: by 10.74.142.129 with HTTP; Fri, 31 Mar 2017 10:36:30 -0700 (PDT) In-Reply-To: References: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> From: Jim Gettys Date: Fri, 31 Mar 2017 13:36:30 -0400 X-Google-Sender-Auth: SvVgLmF-tT_M30iHMJu1WLnfzgg Message-ID: Subject: Re: [iccrg] Bufferbloat and Congestion Control To: Neal Cardwell Cc: "Bless, Roland (TM)" , "tsv-area@ietf.org" , "iccrg@irtf.org" , Michael Welzl Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 17:36:34 -0000 On Fri, Mar 31, 2017 at 1:20 PM, Neal Cardwell wrote: > On Fri, Mar 31, 2017 at 10:47 AM, Jim Gettys wrote: >> There are other issues that people need to keep in mind: >> >> Packet scheduling is *really* important. You really don't want to >> have a burst of packets monopolize your bottleneck link, particularly >> when that bottleneck may be small bandwidth. >> >> For example, my brother suffers on a DSL line, with something like >> 384K up and a megabit or two down. >> >> One full size packet @ 1mbps == 13 milliseconds. Two of those packets >> is already human perceptible latency for some applications (and gamers >> and stock traders will tell you that even a single 13ms delay to their >> application is a significant disadvantage). On his line, even one >> packet upbound is of order 40ms. > > Yes, this is a great point. In the BBR team we are very conscious of > the latency issues in low-bandwidth links, and this is something we > focus on. For example, this consideration you mention is exactly why > Linux TCP BBR chooses a TSO burst size of 1 packet (instead of the > Linux TCP default of 2 packets) for bandwidths below 1.2Mbps. > >> So while congestion avoidance is key to keeping TCP's behavior sane, >> it is *not* sufficient to keep latency to where it needs to be for >> many applications that share the bottleneck. Wonderful as BBR is (and >> I'm a great fan), it still can induce more than a BDP of queue: over >> continental paths, that's of order 100ms and more over >> intercontinental paths. > > The queue levels you mention can indeed be seen when there are > multiple flows sharing a bottleneck and using the current version of > BBR. There is nothing inherent about the BBR approach or framework > that requires that particular level of queue, so one of our big > focuses right now is testing some tweaks to the algorithm to reduce > the degree of queuing in such scenarios. We discussed some of the > experiments in pages 14-19 of this week's BBR talk: > > https://www.ietf.org/proceedings/98/slides/slides-98-iccrg-an-update-on-bbr-congestion-control-00.pdf > >> And even one flow of something other than BBR can ruin your whole day >> completely. Getting everyone to convert to a delay based congestion >> system ain't ever going to happen as they don't compete properly, so >> finally having an algorithm like BBR that can be deployed is >> wonderful. > > Thanks. It is also our sense that BBR provides performance and > behavior that makes it deployable on today's Internet. > >> In short, BBR will reduce the fraction of time latencies are out >> completely of control, but no TCP congestion control system by itself >> can get latencies to where they need to be for many applications. > > Indeed, some very demanding latency-sensitive apps may need changes in > the network to work well. Until those changes are widely deployed, and > even afterward, my sense is that it's worth pushing congestion control > to be as good as it can be. I think we have to push from all directions to drain this global swamp. We're getting some fq_codel uptake in commercial consumer devices at this date, and finally have running code to deal with WiFi for the first time (out the door in the new LEDE release: try it, you'll like it!). It's time to put market forces to work, as it can be a major competitive advantage, and playing one vendor off against the other is an effective way to get motion in the market. Very early in tilting at the bufferbloat windmill, Dave Clark told me: "Don't yell fire in the theater until the exits are marked". It think it is time for us all to yell "fire". "FIRE!" - Jim > > thanks, > neal > > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg From nobody Fri Mar 31 15:18:34 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90183126DCA; Fri, 31 Mar 2017 15:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 6pKLLS3DNlxv; Fri, 31 Mar 2017 15:18:28 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 52D341201F2; Fri, 31 Mar 2017 15:18:28 -0700 (PDT) Received: from [128.9.184.172] ([128.9.184.172]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v2VMICeA004630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Mar 2017 15:18:14 -0700 (PDT) Subject: Re: [iccrg] Bufferbloat and Congestion Control To: Jim Gettys , Neal Cardwell References: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> Cc: "tsv-area@ietf.org" , "iccrg@irtf.org" From: Joe Touch Message-ID: <35bca3fc-a7ca-dfe3-6b1f-fb13a02e6a86@isi.edu> Date: Fri, 31 Mar 2017 15:18:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 22:18:30 -0000 On 3/31/2017 7:47 AM, Jim Gettys wrote: > One full size packet @ 1mbps == 13 milliseconds. That sort of blocking is its own problem and the only solution is to use smaller packets. It can be solved at TCP by pushing the MSS down, but for UDP that's another good reason for considering UDP options as a TSVWG WG item! Joe From nobody Fri Mar 31 16:31:00 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A5D129480 for ; Fri, 31 Mar 2017 16:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 b8lwW0SxZI98 for ; Fri, 31 Mar 2017 16:30:56 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 A2A9C1293E3 for ; Fri, 31 Mar 2017 16:30:56 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id r203so77076423oib.3 for ; Fri, 31 Mar 2017 16:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ALaQPFV+2v061JRUChetTeYjfMGN3y4A/pPaXXK8SVY=; b=JwBBLIVFH657l9Nwxz4ZRUlp2Lj6pmil6niHBVvryxCl2mHdOequxrQaquJ1L4Siik yXbjimNSoC6zOQWAIKJW1lQpGgUWuMU0U1rie3DHnZOkPaWxEod8mYm+Mr+qmQs162pQ OmGdIxy0uHkjOA/hwo4fpbrDv8u+lXi6ZYD0W1K8xinS4Oh7VCs5iK6wND74soTO2SIC zvrTRmU0Llc66Zc0W6lIihoNT6MEugvUZb5Lc1YAcyNQtS8X/8v/qIX4pwNZ5j28mz4z Rws9KHrfsxuebSEWEHrO146T7wCLjsiOAYVr+Lr56aBes22rZHOb04kwVIlB6vz/RmWE AU2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ALaQPFV+2v061JRUChetTeYjfMGN3y4A/pPaXXK8SVY=; b=aEixp0dGZA0j8U1Z2H7l3VY38SAEUcFcObOpbumfrlLNgn2wAW+j0HVuDLyPWk0l1r hz4tsYvhIo3xxPlQUCN4ZubuYsL5ado6zvq1nvw3Fx5P7TpSs9oGQrK4vm3Be12tFf4j ANMR/i5fH1J/PDy6PQpHGLq4pm3wew2tRPcA8XfDYGiR/r0KxPgH3ohVwcJKal3AWM/V exUg/KFW2EbYqOEtKbIJO0P7AwPa7UMd20zi33y97WqQlfNqGAfGBcbx+duEmS47wOs+ H1XTCGlQEqhUZRKcphKLdQ5xq/NvM/5lUKHqj0zsnbTUghXT+f99qvfrTfG9wdLd1dOF 30XQ== X-Gm-Message-State: AFeK/H0iKVJd4UT2jD5eZ+LPfNvoHcGAYsZo6FJGmMSevU012KSIPK65/1y1ngJNLHgv6PLi9KmP4Uqqi8SKEg== X-Received: by 10.202.49.86 with SMTP id x83mr3445853oix.18.1491003056036; Fri, 31 Mar 2017 16:30:56 -0700 (PDT) MIME-Version: 1.0 Sender: gettysjim@gmail.com Received: by 10.74.142.129 with HTTP; Fri, 31 Mar 2017 16:30:55 -0700 (PDT) In-Reply-To: <35bca3fc-a7ca-dfe3-6b1f-fb13a02e6a86@isi.edu> References: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> <35bca3fc-a7ca-dfe3-6b1f-fb13a02e6a86@isi.edu> From: Jim Gettys Date: Fri, 31 Mar 2017 19:30:55 -0400 X-Google-Sender-Auth: 2ZeqBO4SWejas6c1ZOg5WlGDTHM Message-ID: Subject: Re: [iccrg] Bufferbloat and Congestion Control To: Joe Touch Cc: Neal Cardwell , "iccrg@irtf.org" , "tsv-area@ietf.org" Content-Type: multipart/alternative; boundary=001a113bb9da83a4c6054c0f330d Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 23:30:59 -0000 --001a113bb9da83a4c6054c0f330d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 31, 2017 at 6:18 PM, Joe Touch wrote: > > > On 3/31/2017 7:47 AM, Jim Gettys wrote: > > One full size packet @ 1mbps =3D=3D 13 milliseconds. > That sort of blocking is its own problem and the only solution is to use > smaller packets. > > It can be solved at TCP by pushing the MSS down, but for UDP that's > another good reason for considering UDP options as a TSVWG WG item! > =E2=80=8BYes, but without better packet scheduling such as fq_codel at the bottleneck, it won't help. But I'm decently optimistic that =E2=80=8Bthat fq_codel/cake/other things will be deploying widely, since we're seeing fq_codel appear in commercial products at this date. - Jim > Joe > > _______________________________________________ > iccrg mailing list > iccrg@irtf.org > https://www.irtf.org/mailman/listinfo/iccrg > --001a113bb9da83a4c6054c0f330d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Ma= r 31, 2017 at 6:18 PM, Joe Touch <touch@isi.edu> wrote:


On 3/31/2017 7:47 AM, Jim Gettys wrote:
> One full size packet @ 1mbps =3D=3D 13 milliseconds.
That sort of blocking is its own problem and the only solution is to= use
smaller packets.

It can be solved at TCP by pushing the MSS down, but for UDP that's
another good reason for considering UDP options as a TSVWG WG item!

=E2=80=8BYes, but without better packet scheduling such as fq_codel at = the bottleneck, it won't help.=C2=A0 But I'm decently optimistic th= at =E2=80=8Bthat fq_codel/cake/other things will be deploying widely, since= we're seeing fq_codel appear in commercial products at this date.
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Jim


Joe

_______________________________________________
iccrg mailing list
iccrg@irtf.org
https://www.irtf.org/mailman/listinfo/iccrg

--001a113bb9da83a4c6054c0f330d-- From nobody Fri Mar 31 16:41:50 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D846A12947E for ; Fri, 31 Mar 2017 16:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 l5gOKvuak5A9 for ; Fri, 31 Mar 2017 16:41:46 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 378711288B8 for ; Fri, 31 Mar 2017 16:41:46 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id b187so77307340oif.0 for ; Fri, 31 Mar 2017 16:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=sUg2VYoXPSsOh+4ryH9djUn+dOD5pTOkRHaY3wla7Q4=; b=Ym9IyNQQ7mqtKZupKxoHvJLaVy0LLTqO9lpyceX8zmGriNplV8QW/OpqTgwXVmJNp1 rKg0Bv0RFNNah2V9OATI+1RM6PfPFNFYYfrn1yLiVKze5bAB1VO0+sRvSO+PUzkLlMsa y8j3OWrP0195VNuGByWrDsZWH0KN1hZ9np3N1Qm7XoeBsDZptPplIZSGHOE9Xth9T8tq 8pBceQ2+A14fkK3g6ZzhUlgnMurCLAB9Q4T91iVUE1miHPoNHTtTPfG2Ot8+UadQVALM K5MfcInk9VWnmdsyO72hYUce3ASbg4LgVEW9lqq8ALuVa4MZJ2POsDZvaWcJEhV1xYRc eo8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=sUg2VYoXPSsOh+4ryH9djUn+dOD5pTOkRHaY3wla7Q4=; b=rMKwuDtk80Jbu3paZkpYmmnbE3j5SbRoqYdGqLjEsplFfJNNYVXGWlzVfs/EVViTgI j6894pC/h19nFdgqlUsIB4q2NhcyEy4ZN9XsUP2rqXIwL/++YTGoojJEy+KVspHzDgFU Auplzee8PntHdOWO/xxPDbDInUijKBNPxhm8TpKvFTYCUEsxqZ6CBcwCKPaQX5Istbe0 je4+wuvOd0oFtsxbL+fZbVotImAupnjEfXuZTiEf38tG3acD9WTS315M5aaUcMbpx9DC zlA/X/Nl+M6RJwmsmGq6YDFj7jqaqmyxhl8DzVY27m1LHPQT65bSzkPBqx7LZDMXw6Rb TCyg== X-Gm-Message-State: AFeK/H1v50hRSfgUOuWzdSyEUFVhrui0Pl/2/yCmv+X6wzr1orbbOyrpIoU3X9ZfacKYSOfE0xHHxP3S1jWBsA== X-Received: by 10.157.50.16 with SMTP id t16mr3386290otc.266.1491003705646; Fri, 31 Mar 2017 16:41:45 -0700 (PDT) MIME-Version: 1.0 Sender: gettysjim@gmail.com Received: by 10.74.142.129 with HTTP; Fri, 31 Mar 2017 16:41:45 -0700 (PDT) In-Reply-To: References: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> <35bca3fc-a7ca-dfe3-6b1f-fb13a02e6a86@isi.edu> From: Jim Gettys Date: Fri, 31 Mar 2017 19:41:45 -0400 X-Google-Sender-Auth: 6lhtMBbQi42a6b_bYRgtVkdk_sY Message-ID: Subject: Re: [iccrg] Bufferbloat and Congestion Control To: Joe Touch Cc: Neal Cardwell , "iccrg@irtf.org" , "tsv-area@ietf.org" Content-Type: multipart/alternative; boundary=f4030435c11c3be4a9054c0f5a99 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 23:41:49 -0000 --f4030435c11c3be4a9054c0f5a99 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 31, 2017 at 7:30 PM, Jim Gettys wrote: > > > On Fri, Mar 31, 2017 at 6:18 PM, Joe Touch wrote: > >> >> >> On 3/31/2017 7:47 AM, Jim Gettys wrote: >> > One full size packet @ 1mbps =3D=3D 13 milliseconds. >> That sort of blocking is its own problem and the only solution is to use >> smaller packets. >> >> It can be solved at TCP by pushing the MSS down, but for UDP that's >> another good reason for considering UDP options as a TSVWG WG item! >> > > =E2=80=8BYes, but without better packet scheduling such as fq_codel at th= e > bottleneck, it won't help. But I'm decently optimistic that =E2=80=8Btha= t > fq_codel/cake/other things will be deploying widely, since we're seeing > fq_codel appear in commercial products at this date. > =E2=80=8BOh, I forgot: I wrote this piece recently. It may be useful to peo= ple, and let me know if there are products you think should be added to the list. https://gettys.wordpress.com/2017/02/02/home-products-that-fixmitigate-buff= erbloat/ The Evenroute router is particularly good if you need a "plug and play" home router, and/or one that can deal with ISP's that under provision their network and deliver variable bandwidth, such as my brother's DSL line. I need to check if the latest Evenroute supports the new WiFi code; that is stunningly good. My Ubiquiti Picostation running LEDE keeps latency around 40ms or less even under load :-). I've just installed a DOCSIS 3.1 modem yesterday, and will probably run some tests on it versus what SQM does in the next week. That should be interesting. It's particularly frustrating that major vendors "bait and switch" their customers=E2=80=8B with trade names. Said vendor(s) will get no endorsemen= t from me, despite the fact it's enough of the market to be "interesting". Would be nice to get pacing into the new WiFi code and fq_codel so we can use BBR with it on clients (Linux/Android). Any volunteers for an adventure? - Jim > > >> Joe >> >> _______________________________________________ >> iccrg mailing list >> iccrg@irtf.org >> https://www.irtf.org/mailman/listinfo/iccrg >> > > --f4030435c11c3be4a9054c0f5a99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Ma= r 31, 2017 at 7:30 PM, Jim Gettys <jg@freedesktop.org> wrot= e:


On Fri, Mar 31, 2017 at 6:18 P= M, Joe Touch <touch@isi.edu> wrote:


On 3/31/2017 7:47 AM, Jim Gettys wrote:
> One full size packet @ 1mbps =3D=3D 13 milliseconds.
That sort of blocking is its own problem and the only solution is to= use
smaller packets.

It can be solved at TCP by pushing the MSS down, but for UDP that's
another good reason for considering UDP options as a TSVWG WG item!

=E2=80=8BYes,= but without better packet scheduling such as fq_codel at the bottleneck, i= t won't help.=C2=A0 But I'm decently optimistic that =E2=80=8Bthat = fq_codel/cake/other things will be deploying widely, since we're seeing= fq_codel appear in commercial products at this date.

=E2=80=8BOh, I forgot: I wrote this piece recently. It may be use= ful to people, and let me know if there are products you think should be ad= ded to the list.

https://gettys.wordpress.com/2017/02/02/home-products-that-fi= xmitigate-bufferbloat/

The Evenroute router is particularly good if you need a "plug and pl= ay" home router, and/or one that can deal with ISP's that under pr= ovision their network and deliver variable bandwidth, such as my brother= 9;s DSL line. I need to check if the latest Evenroute supports the new WiFi= code; that is stunningly good.=C2=A0 My Ubiquiti Picostation running LEDE = keeps latency around 40ms or less even under load :-).

I've just installed a DOCSIS 3.1 modem ye= sterday, and will probably run some tests on it versus what SQM does in the= next week.=C2=A0 That should be interesting.

It's particularly frustrating that major vendors &= quot;bait and switch" their customers=E2=80=8B with trade names.=C2=A0= Said vendor(s) will get no endorsement from me, despite the fact it's = enough of the market to be "interesting".

Would be nice to get pacing into the new WiFi co= de and fq_codel so we can use BBR with it on clients (Linux/Android).=C2=A0= Any volunteers for an adventure?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Jim

=
=
Joe

_______________________________________________
iccrg mailing list
iccrg@irtf.org
https://www.irtf.org/mailman/listinfo/iccrg


--f4030435c11c3be4a9054c0f5a99-- From nobody Fri Mar 31 19:51:51 2017 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1851271DF; Fri, 31 Mar 2017 19:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 rJpODQKBvQLk; Fri, 31 Mar 2017 19:51:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 5E5D5128959; Fri, 31 Mar 2017 19:51:41 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v312pJtW018598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Mar 2017 19:51:20 -0700 (PDT) Subject: Re: [iccrg] Bufferbloat and Congestion Control To: Jim Gettys References: <20510c04-ec82-9c2f-8900-c99ec5abcecb@kit.edu> <35bca3fc-a7ca-dfe3-6b1f-fb13a02e6a86@isi.edu> Cc: Neal Cardwell , "iccrg@irtf.org" , "tsv-area@ietf.org" From: Joe Touch Message-ID: Date: Fri, 31 Mar 2017 19:51:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5ED058BB906CAC89A4DD9919" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 02:51:44 -0000 This is a multi-part message in MIME format. --------------5ED058BB906CAC89A4DD9919 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 3/31/2017 4:30 PM, Jim Gettys wrote: > > > On Fri, Mar 31, 2017 at 6:18 PM, Joe Touch > wrote: > > > > On 3/31/2017 7:47 AM, Jim Gettys wrote: > > One full size packet @ 1mbps == 13 milliseconds. > That sort of blocking is its own problem and the only solution is > to use > smaller packets. > > It can be solved at TCP by pushing the MSS down, but for UDP that's > another good reason for considering UDP options as a TSVWG WG item! > > > ​Yes, but without better packet scheduling such as fq_codel at the > bottleneck, it won't help. But I'm decently optimistic that ​that > fq_codel/cake/other things will be deploying widely, since we're > seeing fq_codel appear in commercial products at this date. No amount of scheduling overcomes a limit on the unit of scheduling - the packet size, which has increasing impact as link bandwidth decreases. Better scheduling is important necessary too, but by itself insufficient. Joe --------------5ED058BB906CAC89A4DD9919 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 3/31/2017 4:30 PM, Jim Gettys wrote:


On Fri, Mar 31, 2017 at 6:18 PM, Joe Touch <touch@isi.edu> wrote:


On 3/31/2017 7:47 AM, Jim Gettys wrote:
> One full size packet @ 1mbps == 13 milliseconds.
That sort of blocking is its own problem and the only solution is to use
smaller packets.

It can be solved at TCP by pushing the MSS down, but for UDP that's
another good reason for considering UDP options as a TSVWG WG item!

​Yes, but without better packet scheduling such as fq_codel at the bottleneck, it won't help.  But I'm decently optimistic that ​that fq_codel/cake/other things will be deploying widely, since we're seeing fq_codel appear in commercial products at this date.

No amount of scheduling overcomes a limit on the unit of scheduling - the packet size, which has increasing impact as link bandwidth decreases.

Better scheduling is important necessary too, but by itself insufficient.

Joe
--------------5ED058BB906CAC89A4DD9919--