From nobody Wed Jul 1 05:16:17 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419011A1BFF for ; Wed, 1 Jul 2015 05:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 cLKE1ZY1Dvux for ; Wed, 1 Jul 2015 05:16:16 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id 1409A1A1BCC for ; Wed, 1 Jul 2015 05:16:16 -0700 (PDT) Received: from [172.20.10.3] (93.106.11.224) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 552B87C904F0B0EB for tcpm@ietf.org; Wed, 1 Jul 2015 15:16:15 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <9322_1434292058_557D8F5A_9322_652_1_D778B522-94C0-43D8-996F-3949B8AAAF3B@iki.fi> Date: Wed, 1 Jul 2015 15:16:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9322_1434292058_557D8F5A_9322_652_1_D778B522-94C0-43D8-996F-3949B8AAAF3B@iki.fi> To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [tcpm] Agenda requests for TCPM at IETF-93 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 12:16:17 -0000 Hi, Below are the agenda requests we have got so far. If you want to present = something, but are not yet on the list, please let us chairs know soon. = We plan to submit the draft agenda on Friday. Few of the requested presentations do not yet have drafts, so please = submit the drafts ASAP, and announce them on the mailing list. Thanks! - Pasi =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TCPM meeting, IETF-93, Prague, Czech Republic Wednesday, July 22, 13:00 - 15:30 WG Status --------- Time: 5 minutes Working Group Items ------------------- * TCP Extended Data Offset Option draft-ietf-tcpm-tcp-edo Speaker: chairs for the authors Time: 5 minutes * RFC793bis draft-ietf-tcpm-rfc793bis Speaker: chairs for authors Time: 20 minutes Other Items ----------- * The TCP Echo and TCP Echo Reply Options draft-zimmermann-tcpm-echo-option Speaker: Alex Zimmermann Time: 10 minutes * Using the TCP Echo Option for Spurious Retransmission Detection Speaker: Alex Zimmermann Time: 10 minutes * "TCP send buffer advertising" Speaker: Costin Raiciu Time: 15 minutes * Fast Open IPv6 extension Speaker: Mohammed HAWARI Time: 10 minutes From nobody Fri Jul 3 01:58:46 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4371ACD6B for ; Fri, 3 Jul 2015 01:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 3f4KDo74WdbB for ; Fri, 3 Jul 2015 01:58:43 -0700 (PDT) Received: from vps27536.dedimax.com (hawari.fr [176.31.211.215]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733D41ACD4D for ; Fri, 3 Jul 2015 01:58:43 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: momohawari) by vps27536.dedimax.com (Postfix) with ESMTPSA id 375F4EE60AC for ; Fri, 3 Jul 2015 10:59:19 +0200 (CEST) Received: by wibdq8 with SMTP id dq8so94411037wib.1 for ; Fri, 03 Jul 2015 01:58:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.52.105 with SMTP id s9mr18607137wjo.53.1435913891700; Fri, 03 Jul 2015 01:58:11 -0700 (PDT) Received: by 10.27.226.68 with HTTP; Fri, 3 Jul 2015 01:58:11 -0700 (PDT) In-Reply-To: <20150703073347.7027.37216.idtracker@ietfa.amsl.com> References: <20150703073347.7027.37216.idtracker@ietfa.amsl.com> Date: Fri, 3 Jul 2015 10:58:11 +0200 Message-ID: From: Mohammed HAWARI To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=047d7ba97a0e71697a0519f4c175 Archived-At: Cc: Mark Townsley Subject: [tcpm] Fwd: New Version Notification for draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 08:58:45 -0000 --047d7ba97a0e71697a0519f4c175 Content-Type: text/plain; charset=UTF-8 Dear all, I am currently a master's student at Ecole Polytechnique, France and and an intern at Cisco. As part of my research internship, I have written an Internet Draft that specifies an extension to TCP Fast Open. It enables a TCP Fast Open Cookie to be used for a whole IPv6 prefix instead of a single address. Your comments on this draft are very welcome :) I will be at IETF 93 for further discussion too. Best Regards, Mohammed Hawari ---------- Forwarded message ---------- From: Date: 2015-07-03 9:33 GMT+02:00 Subject: New Version Notification for draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt To: Mohammed HAWARI A new version of I-D, draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt has been successfully submitted by Mohammed HAWARI and posted to the IETF repository. Name: draft-hawari-tcpm-tfo-ipv6-prefixes Revision: 00 Title: TCP Fast Open Cookie for IPv6 prefixes Document date: 2015-07-03 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt Status: https://datatracker.ietf.org/doc/draft-hawari-tcpm-tfo-ipv6-prefixes/ Htmlized: https://tools.ietf.org/html/draft-hawari-tcpm-tfo-ipv6-prefixes-00 Abstract: In order to support applications that require a large number of addresses or address space, a host may be assigned an aggregate IPv6 prefix rather than one or more discrete IPv6 addresses. This document briefly describes cases where this may occur, and specifies an extension to TCP Fast Open [RFC7413] to allow a client to use a single TCP Fast Open cookie for an IPv6 prefix. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --047d7ba97a0e71697a0519f4c175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

I am currently a master's student at Ecole Po= lytechnique, France and and an intern at Cisco. As part of my research inte= rnship, I have written an Internet Draft that specifies an extension to TCP= Fast Open. It enables a TCP Fast Open Cookie to be used for a whole IPv6 p= refix instead of a single address.

Your comment= s on this draft are very welcome :) I will be at IETF 93 for further discus= sion too.

Best Regards,

Mohammed Hawari

<= /div>
---------- Forwarded message ----------
= From: <internet-drafts@ietf.org>
= Date: 2015-07-03 9:33 GMT+02:00
Subject: New Version Notification for dr= aft-hawari-tcpm-tfo-ipv6-prefixes-00.txt
To: Mohammed HAWARI <mohammed@hawari.fr>



A new version of I-D, draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt
has been successfully submitted by Mohammed HAWARI and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hawari-tcpm-tfo-ipv6-pr= efixes
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TCP Fast Open Cookie for IPv6 pref= ixes
Document date:=C2=A0 2015-07-03
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hawari-= tcpm-tfo-ipv6-prefixes-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hawari-tcpm-tfo-ipv6-pre= fixes/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hawari-tcpm-tfo-ipv6-prefixes-00

Abstract:
=C2=A0 =C2=A0In order to support applications that require a large number o= f
=C2=A0 =C2=A0addresses or address space, a host may be assigned an aggregat= e IPv6
=C2=A0 =C2=A0prefix rather than one or more discrete IPv6 addresses.=C2=A0 = This
=C2=A0 =C2=A0document briefly describes cases where this may occur, and spe= cifies
=C2=A0 =C2=A0an extension to TCP Fast Open [RFC7413] to allow a client to u= se a
=C2=A0 =C2=A0single TCP Fast Open cookie for an IPv6 prefix.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--047d7ba97a0e71697a0519f4c175-- From nobody Sun Jul 5 09:58:41 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4528A1A19F8 for ; Sun, 5 Jul 2015 09:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gCYp4WTgT2g2 for ; Sun, 5 Jul 2015 09:58:37 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 6EE2B1A07BC for ; Sun, 5 Jul 2015 09:58:36 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 84A6DD36424C3; Sun, 5 Jul 2015 16:58:31 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t65GwYGM010435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Jul 2015 18:58:34 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sun, 5 Jul 2015 18:58:34 +0200 From: "Scharf, Michael (Michael)" To: Per Hurtig , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-08.txt Thread-Index: AQHQqZUoCulPC57hYUi/oanPlNU5Sp2xt+eAgBt8HCA= Date: Sun, 5 Jul 2015 16:58:33 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48416B64@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20150618070508.25994.92595.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 16:58:39 -0000 SXQgaXMgbXkgdW5kZXJzdGFuZGluZyB0aGF0IGFsbCByYWlzZWQgV0dMQyBpc3N1ZXMgYXJlIGFk ZHJlc3NlZCBieSAtMDguIFRodXMsIHdlJ2xsIHByb2NlZWQgd2l0aCBwdWJsaWNhdGlvbi4NCg0K TWljaGFlbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGNwbSBb bWFpbHRvOnRjcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBlciBIdXJ0aWcNCj4g U2VudDogVGh1cnNkYXksIEp1bmUgMTgsIDIwMTUgOToxNCBBTQ0KPiBUbzogdGNwbUBpZXRmLm9y ZyBFeHRlbnNpb25zDQo+IENjOiB0Y3BtLWNoYWlyc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W3RjcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdGNwbS1ydG9yZXN0YXJ0LTA4LnR4dA0KPiAN Cj4gSGkgYWxsLA0KPiANCj4gd2XigJl2ZSBub3cgYWRkcmVzc2VkIGFsbCB0aGUgY29tbWVudHMg d2XigJl2ZSByZWNlaXZlZCBkdXJpbmcgV0dMQywNCj4gaW5jbHVkaW5nOg0KPiANCj4gKiBDbGFy aWZpZWQsIGF0IG11bHRpcGxlIHBsYWNlcyBpbiB0aGUgZG9jdW1lbnQsIHRoYXQgdGhlIG1vZGlm aWNhdGlvbg0KPiBvbmx5DQo+ICAgIGNhdXNlcyB0aGUgZWZmZWN0aXZlIFJUTyB0byBiZSBtb3Jl IGFnZ3Jlc3NpdmUsIG5vdCB0aGUgYWN0dWFsIFJUTy4NCj4gDQo+ICogUmVtb3ZlZCBpbmZvcm1h dGlvbiBpbiB0aGUgaW50cm9kdWN0aW9uIHRoYXQgd2FzIHRvbyBkZXRhaWxlZCwgaS5lLiwNCj4g ICAgbWF0ZXJpYWwgdGhhdCBpcyBoYXJkIHRvIHVuZGVyc3RhbmQgd2l0aG91dCBrbm93aW5nIGRl dGFpbHMgb2YgdGhlDQo+ICAgIGFsZ29yaXRobS4NCj4gDQo+ICogQ2hhbmdlZCB0aGUgbmFtZSBv ZiBTZWN0aW9uIDMgdG8gbW9yZSBjb3JyZWN0bHkgY2FwdHVyZSB0aGUgYWN0dWFsDQo+ICAgIGNv bnRlbnRzIG9mIHRoZSBzZWN0aW9uLg0KPiANCj4gKiBSZS1hcnJhbmdlZCB0aGUgdGV4dCBpbiBT ZWN0aW9uIDMgdG8gaGF2ZSBhIG1vcmUgbG9naWNhbCBzdHJ1Y3R1cmUuDQo+IA0KPiAqIE1vdmVk IHRleHQgZnJvbSB0aGUgYWxnb3JpdGhtIGRlc2NyaXB0aW9uIChTZWN0aW9uIDQpIHRvIHRoZQ0K PiAgICBpbnRyb2R1Y3Rpb24gb2YgdGhlIGRpc2N1c3Npb24gc2VjdGlvbiAoU2VjdGlvbiA1KS4g IFRoZSB0ZXh0IHdhcw0KPiAgICBkaXNjdXNzaW5nIHRoZSBwb3NzaWJsZSBlZmZlY3RzIG9mIHRo ZSBhbGdvcml0aG0gbW9yZSB0aGFuDQo+ICAgIGRlc2NyaWJpbmcgdGhlIGFjdHVhbCBhbGdvcml0 aG0uDQo+IA0KPiAqIENsYXJpZmllZCB3aHkgdGhlIFJFQ09NTUVOREVEIHZhbHVlIG9mIHJydGhy ZXNoIGlzIGZvdXIuDQo+IA0KPiAqIFJld29ya2VkIHRoZSBpbnRyb2R1Y3Rpb24gdG8gYmUgc3Vp dGFibGUgZm9yIGJvdGggVENQIGFuZCBTQ1RQLg0KPiANCj4gDQo+IENoZWVycywNCj4gUGVyDQo+ ID4gT24gMTggSnVuIDIwMTUsIGF0IDA5OjA1LCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3Jv dGU6DQo+ID4NCj4gPg0KPiA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4NCj4gPiBUaGlzIGRy YWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUQ1AgTWFpbnRlbmFuY2UgYW5kIE1pbm9yIEV4dGVu c2lvbnMNCj4gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4gPg0KPiA+ICAgICAgICBUaXRs ZSAgICAgICAgICAgOiBUQ1AgYW5kIFNDVFAgUlRPIFJlc3RhcnQNCj4gPiAgICAgICAgQXV0aG9y cyAgICAgICAgIDogUGVyIEh1cnRpZw0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICBBbm5h IEJydW5zdHJvbQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICBBbmRyZWFzIFBldGx1bmQN Cj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgTWljaGFlbCBXZWx6bA0KPiA+IAlGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1pZXRmLXRjcG0tcnRvcmVzdGFydC0wOC50eHQNCj4gPiAJUGFnZXMg ICAgICAgICAgIDogMTYNCj4gPiAJRGF0ZSAgICAgICAgICAgIDogMjAxNS0wNi0xOA0KPiA+DQo+ ID4gQWJzdHJhY3Q6DQo+ID4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1vZGlmaWVkIHNl bmRlci1zaWRlIGFsZ29yaXRobSBmb3INCj4gbWFuYWdpbmcNCj4gPiAgIHRoZSBUQ1AgYW5kIFND VFAgcmV0cmFuc21pc3Npb24gdGltZXJzIHRoYXQgcHJvdmlkZXMgZmFzdGVyIGxvc3MNCj4gPiAg IHJlY292ZXJ5IHdoZW4gdGhlcmUgaXMgYSBzbWFsbCBhbW91bnQgb2Ygb3V0c3RhbmRpbmcgZGF0 YSBmb3IgYQ0KPiA+ICAgY29ubmVjdGlvbi4gIFRoZSBtb2RpZmljYXRpb24sIFJUTyBSZXN0YXJ0 IChSVE9SKSwgYWxsb3dzIHRoZQ0KPiA+ICAgdHJhbnNwb3J0IHRvIHJlc3RhcnQgaXRzIHJldHJh bnNtaXNzaW9uIHRpbWVyIHNvIHRoYXQgdGhlIGVmZmVjdGl2ZQ0KPiA+ICAgUlRPIGJlY29tZXMg bW9yZSBhZ2dyZXNzaXZlIGluIHNpdHVhdGlvbnMgd2hlcmUgZmFzdCByZXRyYW5zbWl0DQo+ID4g ICBjYW5ub3QgYmUgdXNlZC4gIFRoaXMgZW5hYmxlcyBmYXN0ZXIgbG9zcyBkZXRlY3Rpb24gYW5k IHJlY292ZXJ5DQo+IGZvcg0KPiA+ICAgY29ubmVjdGlvbnMgdGhhdCBhcmUgc2hvcnQtbGl2ZWQg b3IgYXBwbGljYXRpb24tbGltaXRlZC4NCj4gPg0KPiA+DQo+ID4gVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10Y3BtLXJ0b3Jlc3RhcnQvDQo+ID4NCj4gPiBUaGVy ZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLXJ0b3Jlc3RhcnQtMDgNCj4gPg0KPiA+ IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10Y3BtLXJ0b3Jlc3Rh cnQtMDgNCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbg0KPiA+IHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQo+ID4NCj4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQo+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gPiB0Y3BtQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQoNCg== From nobody Mon Jul 6 17:21:08 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C80C1A6EF2 for ; Mon, 6 Jul 2015 17:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 oT-gUfOGegmh for ; Mon, 6 Jul 2015 17:21:05 -0700 (PDT) Received: from mail-vn0-x22c.google.com (mail-vn0-x22c.google.com [IPv6:2607:f8b0:400c:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D571A1AF6 for ; Mon, 6 Jul 2015 17:21:05 -0700 (PDT) Received: by vnbf190 with SMTP id f190so9452034vnb.6 for ; Mon, 06 Jul 2015 17:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p6+ceyFllVALIQvVNhEOEhMWFPmfsQRSU/ptHSumacI=; b=Q5icqEjZBF6WwGcaFVJHw0LQtWRVha9hXdNGb4+SGAGrOKjOolfdsFmpYIl8zJ8iFp BQVsmcOSqPKB3wSsFL9gJSMunudMBC1L7QjzIzZ58bUd5A1BMk+46XFL8gOJq6u5RDRd UX7w+cxXTMQN+0GixM5aqh0m050nECFVutMrqY81Vw9zJfd+s6zbe3wieWusgcwZG2y0 E2rm6PmKZTD9cZjOmJ0UHGoyNsAo6qgZni9uWanApBB7BfTkhWRT1amqw8T2B5mtGogs YmF/FgWlKUT8jUIo2ZHmnNWVkJiYV/OzV9sR73u+tt/FBFl+bseKP2fubS1wMfi7+bcg ZjmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p6+ceyFllVALIQvVNhEOEhMWFPmfsQRSU/ptHSumacI=; b=NHquSTBLMMoYPAbzWid5IwgmUjEZG5Gi1VPHmhstljDXIKr4zvveDr0QOJPQToudUF nk1+twsM0eDM3oUdpzgnM15GOK1nXrfAnCmiuQkgzw3t3Fx+4Fu97U/L2PqA/IfzGeOy o1rxK76HknkTI1gjISc6+9yeYq1UrKMUNLPqRYHrT3RepOg0ML5THia2RaanMAq6d54V DXm5i/khqaqEmCAQfW5G/MegdFIXvnSBbFw58KCK4crnRu9hMyOydmSDSrG2JDkBk0Fa ywyPXs+Lj5CvoPhSyAlDDRQxGgSnCmtKEPe5U2NGlrzhYLFjf8ex72RolLsLnbUYrUy5 b1Lw== X-Gm-Message-State: ALoCoQn6IPXfu3xJBEFjFaEs4cfzAsNBKouPqPRzAfuKuvNj9eXKCpnllAk8Rphbz3cQmvEZ7y8g X-Received: by 10.52.176.131 with SMTP id ci3mr1714530vdc.72.1436228464212; Mon, 06 Jul 2015 17:21:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.96.17 with HTTP; Mon, 6 Jul 2015 17:20:22 -0700 (PDT) In-Reply-To: References: <20150703073347.7027.37216.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Mon, 6 Jul 2015 17:20:22 -0700 Message-ID: To: Mohammed HAWARI Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org Extensions" , Mark Townsley Subject: Re: [tcpm] Fwd: New Version Notification for draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 00:21:06 -0000 On Fri, Jul 3, 2015 at 1:58 AM, Mohammed HAWARI wrote: > Dear all, > > I am currently a master's student at Ecole Polytechnique, France and and an > intern at Cisco. As part of my research internship, I have written an > Internet Draft that specifies an extension to TCP Fast Open. It enables a > TCP Fast Open Cookie to be used for a whole IPv6 prefix instead of a single > address. > > Your comments on this draft are very welcome :) I will be at IETF 93 for > further discussion too. Was the motivation to reduce cookie storage for v6 clients? getting the cookie is a one-time operation. it's not clear to me this worth another TCP option. I don't understand the second motivation... " Another application of this extension appears in the context of a DNS-load-balanced cluster of servers. In this case, one server of the cluster will provide the client with a TFO cookie which is valid for the whole cluster, thus reducing the number of three way handshakes. " If only some special application needs this, why not just change the server to generate cookies base on v6-addr/64 (on its own risk)? > > Best Regards, > > Mohammed Hawari > > ---------- Forwarded message ---------- > From: > Date: 2015-07-03 9:33 GMT+02:00 > Subject: New Version Notification for > draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt > To: Mohammed HAWARI > > > > A new version of I-D, draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt > has been successfully submitted by Mohammed HAWARI and posted to the > IETF repository. > > Name: draft-hawari-tcpm-tfo-ipv6-prefixes > Revision: 00 > Title: TCP Fast Open Cookie for IPv6 prefixes > Document date: 2015-07-03 > Group: Individual Submission > Pages: 5 > URL: > https://www.ietf.org/internet-drafts/draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt > Status: > https://datatracker.ietf.org/doc/draft-hawari-tcpm-tfo-ipv6-prefixes/ > Htmlized: > https://tools.ietf.org/html/draft-hawari-tcpm-tfo-ipv6-prefixes-00 > > > Abstract: > In order to support applications that require a large number of > addresses or address space, a host may be assigned an aggregate IPv6 > prefix rather than one or more discrete IPv6 addresses. This > document briefly describes cases where this may occur, and specifies > an extension to TCP Fast Open [RFC7413] to allow a client to use a > single TCP Fast Open cookie for an IPv6 prefix. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue Jul 7 14:50:26 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4451A1AD272 for ; Tue, 7 Jul 2015 14:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.357 X-Spam-Level: X-Spam-Status: No, score=-1.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ZphG6F0RNImi for ; Tue, 7 Jul 2015 14:50:22 -0700 (PDT) Received: from vps27536.dedimax.com (hawari.fr [176.31.211.215]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0AB1AD213 for ; Tue, 7 Jul 2015 14:50:22 -0700 (PDT) Received: from [10.30.220.156] (unknown [193.52.24.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: momohawari) by vps27536.dedimax.com (Postfix) with ESMTPSA id 527A2EE60AC; Tue, 7 Jul 2015 23:51:35 +0200 (CEST) Message-ID: <559C4995.1090303@hawari.fr> Date: Tue, 07 Jul 2015 23:50:13 +0200 From: Mohammed HAWARI User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yuchung Cheng , Mohammed HAWARI References: <20150703073347.7027.37216.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tcpm@ietf.org Extensions" , Mark Townsley Subject: Re: [tcpm] Fwd: New Version Notification for draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 21:50:24 -0000 Le 07/07/2015 02:20, Yuchung Cheng a crit : Hi, > On Fri, Jul 3, 2015 at 1:58 AM, Mohammed HAWARI wrote: >> Dear all, >> >> I am currently a master's student at Ecole Polytechnique, France and and an >> intern at Cisco. As part of my research internship, I have written an >> Internet Draft that specifies an extension to TCP Fast Open. It enables a >> TCP Fast Open Cookie to be used for a whole IPv6 prefix instead of a single >> address. >> >> Your comments on this draft are very welcome :) I will be at IETF 93 for >> further discussion too. > Was the motivation to reduce cookie storage for v6 clients? > getting the cookie is a one-time operation. it's not clear to me this > worth another TCP option. Well, it is partly a problem of storage (potentially 2^prefix_length cookies stored by the client) but not only. For example if a server has a /64 from which each of the addresses represents a chunk of data (or any other applicative concept), these addresses might be accessed very sparsely. It is even possible that one address of that /64 would never be accessed twice by the client. You will do this one-time operation very often and will gain no benefit from using TFO. > I don't understand the second motivation... > " Another application of this extension appears in the context of a > DNS-load-balanced cluster of servers. In this case, one server of > the cluster will provide the client with a TFO cookie which is valid > for the whole cluster, thus reducing the number of three way > handshakes. > " > > If only some special application needs this, why not just > change the server to generate cookies base on v6-addr/64 (on its own risk)? This cluster of servers could be a cluster of web servers and I might be wrong, but web traffic is still a source of highly transactional traffic. This is not really a special application. If I understand it well,the solution you describe forces the application (client-side and server-side) to be aware of the prefix-length for which a cookie is valid. This might not be possible and is definitely not flexible (/64 sounds quite arbitrary). >> Best Regards, >> >> Mohammed Hawari >> >> ---------- Forwarded message ---------- >> From: >> Date: 2015-07-03 9:33 GMT+02:00 >> Subject: New Version Notification for >> draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt >> To: Mohammed HAWARI >> >> >> >> A new version of I-D, draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt >> has been successfully submitted by Mohammed HAWARI and posted to the >> IETF repository. >> >> Name: draft-hawari-tcpm-tfo-ipv6-prefixes >> Revision: 00 >> Title: TCP Fast Open Cookie for IPv6 prefixes >> Document date: 2015-07-03 >> Group: Individual Submission >> Pages: 5 >> URL: >> https://www.ietf.org/internet-drafts/draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-hawari-tcpm-tfo-ipv6-prefixes/ >> Htmlized: >> https://tools.ietf.org/html/draft-hawari-tcpm-tfo-ipv6-prefixes-00 >> >> >> Abstract: >> In order to support applications that require a large number of >> addresses or address space, a host may be assigned an aggregate IPv6 >> prefix rather than one or more discrete IPv6 addresses. This >> document briefly describes cases where this may occur, and specifies >> an extension to TCP Fast Open [RFC7413] to allow a client to use a >> single TCP Fast Open cookie for an IPv6 prefix. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jul 10 09:15:07 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6211B2CE2 for ; Fri, 10 Jul 2015 09:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 Q4MEbRPbKQCk for ; Fri, 10 Jul 2015 09:15:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A611B2CB5 for ; Fri, 10 Jul 2015 09:15:02 -0700 (PDT) Received: from BN1PR03MB008.namprd03.prod.outlook.com (10.255.224.38) by BN1PR03MB023.namprd03.prod.outlook.com (10.255.224.41) with Microsoft SMTP Server (TLS) id 15.1.213.10; Fri, 10 Jul 2015 16:14:42 +0000 Received: from BN1PR03MB008.namprd03.prod.outlook.com ([169.254.7.111]) by BN1PR03MB008.namprd03.prod.outlook.com ([169.254.7.111]) with mapi id 15.01.0213.000; Fri, 10 Jul 2015 16:14:41 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "Eggert, Lars" , Dave Thaler , Stephen Bensley Thread-Topic: [tcpm] Review of draft-bensley-tcpm-dctcp-03 Thread-Index: AQHQqcskaeSYI99oC06rW5EqZt3bHZ2yRY6AgCKuDuA= Date: Fri, 10 Jul 2015 16:14:41 +0000 Message-ID: References: <031D67EB-0676-4398-B5DF-E2F73D174E58@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tik.ee.ethz.ch; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-exchange-diagnostics: 1; BN1PR03MB023; 5:pqpgqzt2FMXKGneb1NJO83rhek5dHIK8Y9nIqlDy+y1Cy1hFWnID2pJXcS2pWxZnHxtRVi5AkrAnOXgvlJUzDNdbqbZIB7gxFRjcYCy0QV8kvpoNq7n54zdJc4ET9x302nW9oRneNdQoW/DXnkgkRg==; 24:hPzTSfpXnm5Mtg36xPU9cgxh1QNDcjF8c49VITFiIwdCqEQ1xnkfg/bb8HHPxTj34HG/0BPMhbbAZpcwsQ5fPYLXxIgclcLJFW2nQ/rmNrM=; 20:Lu+KnV3XksR2Qi1buF7Z+1vtfMY9L40ZXsyfh5qIR2K9CxkSI5mHqM+1Ebzm50lxDs8LeljE6ABWdc9W0FWnzw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR03MB023; bn1pr03mb023: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BN1PR03MB023; BCL:0; PCL:0; RULEID:; SRVR:BN1PR03MB023; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(53754006)(122556002)(2421001)(19580395003)(19580405001)(92566002)(62966003)(77156002)(46102003)(40100003)(189998001)(5002640100001)(76576001)(74316001)(5003600100002)(2950100001)(5001960100002)(15975445007)(102836002)(1511001)(5001770100001)(2900100001)(33656002)(2561002)(76176999)(230783001)(106116001)(54356999)(86362001)(50986999)(87936001)(2656002)(3826002)(4001450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB023; H:BN1PR03MB008.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2015 16:14:41.1024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR03MB023 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Review of draft-bensley-tcpm-dctcp-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:15:05 -0000 SGkgTWlyamENCg0KV2UgaGF2ZSBwdWJsaXNoZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlbnNsZXktdGNwbS1kY3RjcC0wNSB3 aGljaCBhZGRyZXNzZXMgbWFueSBvZiB5b3VyIGNvbmNlcm5zLiBJbmxpbmUgYXJlIHNvbWUgcmVz cG9uc2VzIHRvIGluZGl2aWR1YWwgZmVlZGJhY2suDQoNClRoYW5rcw0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogdGNwbSBbbWFpbHRvOnRjcG0tYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1pcmphIEvDvGhsZXdpbmQNClNlbnQ6IFRodXJzZGF5LCBKdW5lIDE4LCAy MDE1IDY6NDIgQU0NClRvOiBFZ2dlcnQsIExhcnM7IERhdmUgVGhhbGVyOyBTdGVwaGVuIEJlbnNs ZXkNCkNjOiB0Y3BtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RjcG1dIFJldmlldyBvZiBkcmFm dC1iZW5zbGV5LXRjcG0tZGN0Y3AtMDMNCg0KT25lIG1vcmUgcXVpY2sgcG9pbnQsIGFuIGFuYWx5 c2lzIG9mIHRoZSBwcm9ibGVtIG9mIHRoZSB1c2VkIEVDTiBmZWVkYmFjayBzY2hlbWUgb2YgRENU Q1AgaXMgYWxzbyBnaXZlbiBpbiB0aGUgQWNjRUNOIHJlcXVpcmVtZW50cyBkcmFmdCAoc29vbiBS RkM3NTYwKSB3aGljaCBtYXliZSBjb3VsZCBiZSByZWZlcnJlZCBoZXJlLg0KDQpNaXJqYQ0KDQoN Cj4gQW0gMTguMDYuMjAxNSB1bSAxNTozMSBzY2hyaWViIE1pcmphIEvDvGhsZXdpbmQgPG1pcmph Lmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+Og0KPiANCj4gSGkgYWxsLA0KPiANCj4gYXMgSSB0 aGluayBkcmFmdC1iZW5zbGV5LXRjcG0tZGN0Y3Agc2hvdWxkIGJlIGFuIHRjcG0gd29ya2luZyBn cm91cCBkb2N1bWVudCBhbmQgYmVjYXVzZSBJ4oCZbSBpbnRlcmVzdGVkIGluIERDVENQLCBJ4oCZ dmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudC4gVGhpcyBkcmFmdCBkb2N1bWVudHMgRENUQ1AgYXMg aW1wbGVtZW50ZWQgaW4gTWljcm9zb2Z0IGFuZCBpcyB2ZXJ5LXdlbGwgd3JpdHRlbiBhbmQgZWFz eSB0byB1bmRlcnN0YW5kLCB0aGVyZWZvcmUgSSB0aGluayBpZiBhZG9wdGVkIGJ5IHRjcG0gaXMg Y2FuIGJlIHByb2Nlc3NlZCBxdWlja2x5Lg0KPiANCj4gSSBoYXZlIHR3byBjb21tZW50cyB3aGlj aCBJIHdvdWxkIGxpa2UgdG8gc2VlIGFkZHJlc3NlZDsgYW5kIGEgZmV3IG1vcmUgc21hbGxlciBj b21tZW50cyB3aGljaCBtaWdodCBoZWxwIHRvIGV2ZW4gZnVydGhlciBpbXByb3ZlIHRoZSBkb2N1 bWVudCBhbmQgbWlnaHQgYmUgYWRkcmVzc2VkIG9yIG5vdDoNCj4gDQo+IDEpIEkgd291bGQgbGlr ZSB0byBzZWUgdGhlIHBvaW50IHRoYXQgRENUUCBpcyAqb25seSogaW5kZW50ZWQgdG8gYmUgdXNl ZCBpbiBkYXRhIGNlbnRlciBtYWRlIG1vcmUgc3Ryb25nbHkgYW5kIGV4cGxpY2l0IGluIHRoaXMg ZG9jdW1lbnQgYnkgYWRkaW5nIG9uZSBtb3JlIHNtYWxsIHBhcmFncmFwaCBpbiB0aGUgaW50cm8g b3IgZXZlbiBvbmUgbW9yZSBzZW50ZW5jZSBpbiB0aGUgYWJzdHJhY3QuIFRoZXJlIGFyZSB0d28g cmVhc29uIHdoeSBJIHRoaW5rIHRoaXMgaXMgdmVyeSBpbXBvcnRhbnQgdG8gc2F5IG1vcmUgZXhw bGljaXRseTogYSkgdGhlcmUgaXMgbm8gbmVnb3RpYXRpb24gdGhhdCBkZXRlY3RzIGlmIERDVENQ IGlzIGFsc28gaW1wbGVtZW50ZWQgYnkgdGhlIG90aGVyIGVuZCAodGhpcyBpcyBtYWlubHkgaW1w b3J0YW50IGZvciB0aGUgRUNOIGZlZWRiYWNrKS4gQW5kIGIpIGlmIERDVFAgaXMgdXNlZCBpbiBw YXJhbGxlbCB0byDigJp0cmFkaXRpb25hbOKAmCAobWF5YmUgZXZlbiBsb3NzLWJhc2VkKSBjb25n ZXN0aW9uIGNvbnRyb2wsIGl0IHdpbGwgc3RhcnZlIHRoaXMgY29tcGV0aW5nIHRyYWZmaWM7IEkg ZG9u4oCZdCB0aGluayB0aGlzIHBvaW50IGlzIG1lbnRpb25lZCBhbnl3aGVyZSBidXQgcHJvYmFi bHkgc2hvdWxkLCBhdCBsZWFzdCB2ZXJ5IGJyaWVmbHkuDQoNCj4+IEZpcnN0IGNvbW1lbnQgaXMg YWRkcmVzc2VkIGluIHRoZSBzZWN0aW9uIDEgKEludHJvZHVjdGlvbikuIFNlY29uZCBjb21tZW50 IG9mIGNvZXhpc3RlbmNlIHdpdGggbm9uLURDVENQIHZhcmlhbnRzIG9mIFRDUCBpcyBhZGRyZXNz ZWQgaW4gc2VjdGlvbiA1IChEZXBsb3ltZW50IGlzc3VlcykuDQoNCg0KPiANCj4gMikgVGhpcyBk b2N1bWVudCBkb2VzIG5vdCBkZXNjcmliZSB3aGF0IHRoZSBNaWNyb3NvZnQgaW1wbGVtZW50YXRp b24gZG9lcyBpZiBsb3NzIGlzIGRldGVjdGVkLiBJIHRoaW5rIG5vcm1hbGx5IHRoZSBhc3N1bXB0 aW9uIGlzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG5vIChjb25nZXN0aW9uLWJhc2VkKSBsb3NzIGFu eW1vcmUgaW4gYSBkYXRhIGNlbnRlciB3aGVyZSBhbGwgdHJhZmZpYyBpcyB1c2luZyBEQ1RDUC4g SG93ZXZlciwgdGhlIGRyYWZ0IHNob3VsZCBzdGlsbCBzYXkgd2hhdCB0byBkbyBpZiBsb3NzIG9j Y3Vycy4gSWYgSSByZW1lbWJlciBjb3JyZWN0bHkgdGhlIExpbnV4IGltcGxlbWVudGF0aW9uIGhh cyBhIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVyIHRvIGRlY2lkZSBpZiBhIGxvc3Mgc2hvdWxkIGJl IGlnbm9yZWQgb3IgdGhlIHdpbmRvdyBzaG91bGQgYmUgaGFsdmVkLiBNYXliZSB5b3UgY2FuIGFn YWluIGNsYXJpZnkgd2l0aCBEYW5pZWwgQm9ya21hbm4gd2hvIGltcGxlbWVudGVkIHRoaXMgaW4g TGludXg7IEkga25vdyBoZSBoYXMgcmVhZCB0aGUgZHJhZnQgYW5kIGlzIHByb2JhYmx5IHdpbGxp bmcgdG8gcmV2aWV3IGFnYWluIG9yIGV2ZW4gcHJvdmlkZSBzb21lIHRleHQgb24gdGhpcyBpZiBu ZWVkZWQuDQo+IA0KDQo+PiBXaW5kb3dzIFNlcnZlciBkb2VzIG5vdCBhZGp1c3QgdGhlIHZhbHVl IG9mIEFscGhhIGZvciB0aGUgcm91bmQgaWYgbG9zcyBpcyBkZXRlY3RlZC4gV2UgYXJlIHVuZGVy IGRpc2N1c3Npb24gd2l0aCBEYW5pZWwgYWJvdXQgYWRkcmVzc2luZyB0aGlzIGluIHRoZSBuZXh0 IHJldmlzaW9uIG9mIHRoZSBkcmFmdCB1bmRlciBJbXBsZW1lbnRhdGlvbiBpc3N1ZXMgc2VjdGlv bi4NCg0KDQo+IE90aGVyIG1pbm9yIGNvbW1lbnRzOg0KPiANCj4gMSkgSSB3b3VsZCBsaWtlIHRv IHNlZSBtZW50aW9uZWQgaW4gdGhlIGFic3RyYWN0IGFzIHdlbGwgYXMgaW4gdGhlIGludHJvIHRo YXQgdGhlIGdhaW4gaW4gbG93ZXIgbGF0ZW5jeSBpcyBhY2hpZXZlZCBieSB1c2luZyBhIHZlcnkg bG93IG1hcmtpbmcgdGhyZXNob2xkIG9mIHRoZSBBUU0uIFRoaXMgZG9jdW1lbnQgaXMgd3JpdHRl biB0byBtYWlubHkgZGVzY3JpYmUgb25seSB0aGUgZW5kcG9pbnQgY2hhbmdlcyBhbmQgc2VlbSB0 byBzdWdnZXN0IHRoYXQgRENUQ1AgY291bGQgd29yayB3aXRoIGFueSBFQ04tZW5hYmxlZCBBUU0u IFRoYXQgbWlnaHQgYmUgdHJ1ZSBvciBub3Q7IGF0IGxlYXN0IEkgaGF2ZSBub3Qgc2VlbXMgYW55 IGV2YWx1YXRpb24gcmVzdWx0cyB3aGVyZSBkaWZmZXJlbnQgQVFNIHNjaGVtZXMgYXJlIHVzZWQu IEkgcGVyc29uYWxseSB3b3VsZCBwcmVmZXIgdG8gZGVzY3JpYmUgRENUQ1AgYXMgYSB3aG9sZSBz eXN0ZW0gdGhhdCBpbXBsZW1lbnRzIGEgY2VydGFpbiBjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1l IChhbmQgRUNOIGZlZWRiYWNrKSBhcyB3ZWxsIGFzIGFzc3VtZXMgYSBzcGVjaWZpYyBwYXJhbWV0 ZXJpemF0aW9uIGluIHRoZSBib3R0bGVuZWNr4oCZcyBBUU0uIEkgZG9u4oCZdCB0aGluayB0aGF0 4oCZcyBhIHByb2JsZW0gdG8gZGVzY3JpYmUgaXQgdGhhdCB3YXksIGJlY2F1c2UgRENUQ1AgaXMg Y2xlYXIgb25seSBpbnRlbmRlZCB0byBiZSB1c2VkIGluIGRhdGEgY2VudGVycyB3aGVyZSBhbGwg ZW5kcG9pbnQgYW5kIG5ldHdvcmsgbm9kZXMgYXJlIHVuZGVyIHRoZSBjb250cm9sIG9mIG9uZSBl bnRpdHkuIEFjdHVhbGx5IGl0IHNob3VsZCBldmVuIGJlIG1lbnRpb25lZCB0aGF0IHRoZSBwcm9w b3NlZCBwYXJhbWV0ZXJpemF0aW9uIGNhbiBlYXNpbHkgYmUgY29uZmlndXJlZCB3aXRoIGFsbCBz d2l0Y2hlcyB0aGF0IGltcGxlbWVudCBSRUQuIA0KDQo+PiBUaGlzIGlzIGNvcnJlY3Qgd2hlbiBs b29raW5nIGF0IHRoZSBzeXN0ZW0gYXMgYSB3aG9sZSBidXQgdGhlIHByaW1hcnkgZ29hbCBpcyB0 byBwcm92aWRlIGd1aWRlbGluZXMgYXJvdW5kIGVuZCBob3N0IGltcGxlbWVudGF0aW9uIHdoaWNo IHNob3VsZCBub3QgYmUgYXdhcmUgb3IgZGVwZW5kZW50IG9uIGFueSBwYXJ0aWN1bGFyIEFRTSBz Y2hlbWUuIFNvbWUgdGV4dCB0byBhZGRyZXNzIFJFRCBpcyBhZGRlZCBpbiBTZWN0aW9uIDUgKERl cGxveW1lbnQgaXNzdWVzKS4NCg0KPiANCj4gMikgVGhlIHNlY29uZCBwb2ludCBnb2VzIGluIHRo ZSBzYW1lIGRpcmVjdGlvbjogc2VjdGlvbiAzLjEgc2F5czoNCj4gIkhvd2V2ZXIsIHRoZSBhY3R1 YWwNCj4gICBhbGdvcml0aG0gZm9yIG1hcmtpbmcgY29uZ2VzdGlvbiBpcyBhbiBpbXBsZW1lbnRh dGlvbiBkZXRhaWwgb2YgdGhlDQo+ICAgc3dpdGNoIGFuZCB3aWxsIGdlbmVyYWxseSBub3QgYmUg a25vd24gdG8gdGhlIHNlbmRlciBhbmQgcmVjZWl2ZXIuDQo+ICAgVGhlcmVmb3JlLCBzZW5kZXIg YW5kIHJlY2VpdmVyIE1VU1QgTk9UIGFzc3VtZSB0aGF0IGEgcGFydGljdWxhcg0KPiAgIG1hcmtp bmcgYWxnb3JpdGhtIGlzIGltcGxlbWVudGVkIGJ5IHRoZSBzd2l0Y2hpbmcgZmFicmljLuKAnCBG aXJzdCBvZiANCj4gYWxsLCB0aGlzIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgc2hvdWxkIG5vdCB1 c2Ugbm9ybWF0aXZlIGxhbmd1YWdlIGhlcmUuIEFuZCBzZWNvbmQsIGlmIERDVENQIGlzIHVzZWQg YW5kIHRlc3RlZCBieSBNaWNyb3NvZnQgb25seSB3aXRoIGEgY2VydGFpbiBjb25maWd1cmF0aW9u LCBJIHdvdWxkIHJlbW92ZSB0aGlzIHNlbnRlbmNlIGFuZCB3cml0ZSByYXRoZXIgc29tZXRoaW5n IGxpa2U6DQo+IOKAnkV2ZW4gdGhvdWdoIHRoZSBhY3R1YWwNCj4gICBhbGdvcml0aG0gZm9yIG1h cmtpbmcgY29uZ2VzdGlvbiBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwgb2YgdGhlDQo+ICAg c3dpdGNoIGFuZCB3aWxsIGdlbmVyYWxseSBub3QgYmUga25vd24gdG8gdGhlIHNlbmRlciBhbmQg cmVjZWl2ZSwgDQo+ICAgRENUQ1AgaGFzIGJlZW4gZGVzaWduIGFuZCBldmFsdWF0ZWQgdG8gYmUg dXNlZCB3aXRoIHRoZSANCj4gY29uZmlndXJhdGlvbiBkZXNjcmliZSBhYm92ZS7igJwNCj4gDQo+ IDMpIEZpcnN0IHBhcmFncmFwaCBpbiB0aGUgaW50cm8gc2F5cyB0aGF0IHRoZSBwcm9ibGVtIHdp dGggbG93IGNvc3Qgc3dpdGNoZXMgaXMgaGlnaCBsb3NzLiBJIGFjdHVhbGx5IHRob3VnaCB0aGF0 IHRoZSBwcm9ibGVtIHdpdGggdGhlIHN0YW5kYXJkIGNvbmZpZyBvZiBsb3cgY29zdCBzd2l0Y2hl cyBpcyBoaWdoIGRlbGF5IGJlY2F1c2UgdGhlcmUgaXMgdG9vIG11Y2ggYnVmZmVyaW5n4oCmIGNh biB5b3UgY29tbWVudCBvbiB0aGlzPw0KDQo+PiBMb3cgY29zdCBzd2l0Y2hlcyBoYXZlIHNoYWxs b3cgYnVmZmVycyBzbyBidXJzdCBsb3NzZXMgYXJlIGEgcHJvYmxlbS4gDQoNCj4gDQo+IDQpIFNl Y29uZCBwYXJhZ3JhcGggc2F5cyAid29ya2VyIG5vZGVzIGNvbXBsZXRlIGF0IGFwcHJveGltYXRl bHkgdGhlIHNhbWUgdGltZeKAnC4gSSB0aG91Z2h0IHRoYXQgdGhleSB3b3VsZCBldmVuIGNvbXBs ZXRlIGF0IGV4YWN0bHkgdGhlIHNhbWUgdGltZSBiZWNhdXNlIHRoZXkgb2Z0ZW4gaGF2ZSBhIHRp bWVvdXQuLj8gQ2FuIHlvdSBjb21tZW50IGhlcmUgYXMgd2VsbD8gTWF5YmUgYWxzbyByZWZlciB0 aGUgRENUQ1AgcGFwZXIgaGVyZSBiZWNhdXNlIGl0IGNvbnRhaW5zIGEgZ29vZCBhbmFseXNpcyBv ZiBpbmNhc3QuDQo+IA0KDQo+PiBUaGUgd29ya2xvYWRzIGFyZSBwYXJ0aXRpb25lZCB0byB0aGUg c2FtZSBzaXplIGRhdGFzZXRzIGFuZCBhc3N1bWluZyBhIHVuaWZvcm0gbmV0d29yayBhbmQgc2Vy dmVyIGNvbmZpZ3VyYXRpb24gdGhlIHRhc2tzIGNvbXBsZXRpbmcgYXQgdGhlIHNhbWUgdGltZSBp cyBoaWdobHkgbGlrZWx5LiANCg0KDQo+IDUpIFBhcmFncmFwaCBvbiBFQ04gaW4gdGhlIGludHJv IHNheXMNCj4gIkluIHRoZSBwcmVzZW5jZSBvZiBtaWxkIGNvbmdlc3Rpb24sIGl0IHJlZHVjZXMg dGhlIFRDUCBjb25nZXN0aW9uIHdpbmRvdyB0b28NCj4gICBhZ2dyZXNzaXZlbHnigKYiDQo+IOKA mkl04oCYIHJlZmVycyBoZXJlIHRvIHRoZSBFQ04gbWVjaGFuaXNtIG9mIHJmYzMxNjguIEhvd2V2 ZXIsIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgcmVkdWNlcyB0aGUgd2luZG93LiBUaGVyZWZvcmUg dGhlIHNlbnRlbmNlIHNob3VsZCByYXRoZXIgYmU6DQo+ICJJbiB0aGUgcHJlc2VuY2Ugb2YgbWls ZCBjb25nZXN0aW9uLCB0cmFkaXRpb25hbCBUQ1AgY29uZ2VzdGlvbiANCj4gY29udHJvbCByZWR1 Y2VzIHRoZSBUQ1AgY29uZ2VzdGlvbiB3aW5kb3cgdG9vIGFnZ3Jlc3NpdmVseeKApuKAnA0KPiAN Cg0KPj4gV2UgZml4ZWQgc29tZSB0ZXh0IGluIHRoZSBpbnRyb2R1Y3Rpb24uIFBsZWFzZSByZXZp ZXcuDQoNCj4gNikgQWJzdHJhY3QgYW5kIGludHJvIGJvdGggc2F5IOKAnkRDVENQIGVuaGFuY2Vz IEVDTuKApuKAnDsgSSByZWFsbHkgZG9u4oCZdCB0aGluayDigJplbmhhbmNlJyBjYW4gYmUgdXNl ZCBoZXJlIHNvIGdlbmVyYWxseTsgaWYgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBvbmx5IG5lZWRz IG9uZSBmZWVkYmFjayBzaWduYWwgcGVyIFJUVCwgdGhlcmUgaXMgbm8gZW5oYW5jZW1lbnQuIE1h eWJlIHNheSDigJpjaGFuZ2XigJggb3Ig4oCaaW1wcm92ZXMgdGhlIGFjY3VyYWN5IG9mIHRoZSBF Q04gZmVlZGJhY2sgc2lnbmFsIGJ5IHNpZ25hbCBub3Qgb25seSB0aGUgb2NjdXJyZW5jZSBvZiBj b25nZXN0aW9uIGJ1dCBhbHNvIGl0cyBleHRlbmTigJjigKYgb3Igc29tZXRoaW5nIGxpa2UgdGhp cy4NCj4gDQoNCj4+IFdlIGFsdGVyZWQgdGhlIGxhbmd1YWdlIHNvbWV3aGF0IHRvIG1ha2UgdGhp cyBjbGVhcmVyICIgRGF0YWNlbnRlciBUQ1AgKERDVENQKSBpbXByb3Zpc2VzIHVwb24gdHJhZGl0 aW9uYWwgRUNOIHByb2Nlc3NpbmcgYnkgLi4uIi4NCg0KPiA3KSBBcyBhbHNvIG1lbnRpb25lZCBh Ym92ZSwgSSB0aGluayB0aGUgaW50cm8gc2hvdWxkIHNheSB0aGF0IHRoZSBtb3JlIGFnZ3Jlc3Np dmUgY29uZ2VzdGlvbiBjb250cm9sIG9mIERDVENQIHNob3VsZCBub3QgYmUgdXNlZCBpbiBwYXJh bGxlbCB3aXRoIHRyYWRpdGlvbmFsIGNvbmdlc3Rpb24gYXMgaXQgd2lsbCBzdGFydmUgdGhpcyB0 cmFmZmljLg0KPiANCg0KPj4gQWRkcmVzc2VkIGluIHNlY3Rpb24gNSAoRGVwbG95bWVudCBpc3N1 ZXMpDQoNCj4gOCkgSeKAmWQgbGlrZSB0byBwcm9wb3NlIHRvIHVzZSB0aGUgbGlzdCBnaXZlbiBp biBzZWN0aW9uIDMgbm90IG9ubHkgdG8gc2F5IHdoaWNoIGVsZW1lbnRzIGFyZSDigJppbnZvbHZl ZOKAmCBidXQgYWxzbyB2ZXJ5IGJyaWVmbHkgc2F5IHdoYXQgd2FzIOKAmm1vZGlmaWVk4oCYLCBl LmcuDQo+IA0KPiAiVGhlcmUgYXJlIHRocmVlIGNvbXBvbmVudHMgdGhhdCBuZWVkcyB0byBiZSBt b2RpZmllZCB0byB1c2UgRENUQ1A6DQo+IA0KPiAgIG8gIFRoZSBzd2l0Y2ggKG9yIG90aGVyIGlu dGVybWVkaWF0ZSBkZXZpY2Ugb24gdGhlIG5ldHdvcmspIGRldGVjdHMNCj4gICAgICBjb25nZXN0 aW9uIGFuZCBzZXRzIHRoZSBDb25nZXN0aW9uIEV4cGVyaWVuY2VkIChDRSkgY29kZXBvaW50IGlu DQo+ICAgICAgdGhlIElQIGhlYWRlciBhbHJlYWR5IHdoZW4gYSB2ZXJ5IHNob3J0IHF1ZXVlIGJ1 aWxkcyB1cC4gDQo+IA0KPiAgIG8gIFRoZSByZWNlaXZlciBlY2hvZXMgZWFjaCBvY2N1cnJlbmNl IG9mIGEgdGhlIENvbmdlc3Rpb24gRXhwZXJpZW5jZWQgKENFKSBtYXJrDQo+ICAgICAgYmFjayB0 byB0aGUgc2VuZGVyIHVzaW5nIHRoZSBFQ04tRWNobyAoRUNFKSBmbGFnIGluIHRoZSBUQ1AgaGVh ZGVyLg0KPiANCj4gICBvICBUaGUgc2VuZGVyIHJlYWN0cyB0byB0aGUgY29uZ2VzdGlvbiBpbmRp Y2F0aW9uIGJ5IHJlZHVjaW5nIHRoZSBUQ1ANCj4gICAgICBjb25nZXN0aW9uIHdpbmRvdyAoY3du ZCkgYmFzZWQgb24gdGhlIGV4dGVuZCBvZiBjb25nZXN0aW9uIA0KPiBleHBlcmllbmNlZCBpbiB0 aGUgbGFzdCBSVFQu4oCcDQo+IA0KPiBJIHRoaW5rIHRoaXMgZ2l2ZW4gYSBuaWNlIGhpZ2gtbGV2 ZWwgb3ZlcnZpZXcgYW5kIGhlbHBzIHRoZSByZWFkZXIgdG8gZWFzaWVyIHVuZGVyc3RhbmQgdGhl IHJlc3QuDQo+IA0KPiA5KSBNYXliZSBhZGQgIHRvIHNlY3Rpb24gMy4yIHRoZSBzdGF0ZSBtYWNo aW5lIGltYWdlIGFzIHByb3ZpZGVkIGluIA0KPiB0aGUgcGFwZXIuIEkgcGVyc29uYWxseSB3b3Vs ZCwgIGluIGFuIFJGQywgYWxzbyBkZXNjcmliZSB0aGUgYWxnbyANCj4gZmlyc3QgYW5kIHRoZW4g Z2l2ZSB0aGUgcmVhc29uaW5nIGJ1dCB0aGF04oCZcyBhIG1hdHRlciBvZiB3aGljaCBzdHlsZSAN Cj4gaXMgcHJlZmVycmVk4oCmDQo+IA0KDQo+PiBPdGhlciBpbXBsZW1lbnRhdGlvbnMgc2VlbSB0 byBoYXZlIGdvdCB0aGUgYWxnb3JpdGhtIGNvcnJlY3Qgd2l0aG91dCBuZWVkaW5nIG1vcmUgZXhw bGFuYXRpb24gaGVyZS4gSWYgeW91IHRoaW5rIGl0J3Mgbm90IGNsZWFyIGVub3VnaCwgd2Ugd2ls bCByZXZpc2l0IGFkZGluZyBtb3JlIGRldGFpbHMgaW4gbmV4dCByZXZpc2lvbi4gDQoNCj4gMTAp IFNlY3Rpb24gMy4zOiBRdWljayBxdWVzdGlvbjogV2h5IGlzIHRoZSBmcmFjdGlvbiBvZiBtYXJr ZWQgcGFja2V0cyBjYWxsZWQgTSBpbiB0aGUgZHJhZnQgd2hpbGUgaXTigJlzIEYgaW4gdGhlIHBh cGVyPw0KPiANCg0KPj4gVGhlcmUgaGFzIGJlZW4gbm8gYXR0ZW1wdCB0byByZWNvbmNpbGUgdGhl IGRyYWZ0IHdpdGggdGhlIHBhcGVyIHRvIHVzZSB0aGUgc2FtZSB0ZXJtaW5vbG9neS4gDQoNCj4g MTEpIEFnYWluIFNlY3Rpb24gMy4zOiBNYXliZSBtZW50aW9uIHNvbWV3aGVyZSB0aGF0IHRoZSBT QUNLIGluZm9ybWF0aW9uIGFyZSBub3QgdXNlZCB0byBjYWxjdWxhdGUgQnl0ZXNBY2tlZCBiZWNh dXNlIHVzdWFsbHkgaXTigJlzIGFzc3VtZWQgdG8gaGF2ZSBubyBsb3NzIHdpdGggdGhlIHVzZSBv ZiBEQ1RDUC4gSG93ZXZlciwgSSBndWVzcyBpZiBhIGNhbGN1bGF0aW9uIGFzIGdpdmVuIGluIFJG QzY5MzcgKFBSUikgZm9yIERlbGl2ZXJlZERhdGEgaXMgdXNlZCwgdGhhdCBpcyBwcm9iYWJseSBv a2F5IGFzIHdlbGwgYW5kIHNob3VsZCBub3QgYmUgYSBwcm9ibGVtLCByaWdodD8NCj4gDQoNCj4+ IFRoYXQncyBjb3JyZWN0LiBMb3NzIGhhbmRsaW5nIHdpbGwgaGF2ZSB0byBiZSBhZGRyZXNzZWQg aW4gYSBmdXR1cmUgcmV2aXNpb24uIFRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uIGRvZXMgbm90 IHVzZSBTQUNLIGluZm9ybWF0aW9uLg0KDQo+IDEyKSBGdXJ0aGVyIHNlY3Rpb24gMy4zIHNheXMg IndoZW4gdGhlIHNlbmRlciByZWNlaXZlcyBhbiBpbmRpY2F0aW9uIG9mIGNvbmdlc3Rpb27igJwu IENhbiB5b3UgbWF5YmUgYmUgYSBsaXR0bGUgbW9yZSBzcGVjaWZ5IGhlcmUgYW5kIHNheSDigJ5p ZiB0aGUgZmlyc3QgRUNFIGlzIHJlY2VpdmVkIGluIGEgUlRU4oCcIG9yIHNvbWV0aGluZyBsaWtl IHRoaXMuIFBsZWFzZSBhbHNvIG5vdGUgdGhhdCB0aGlzIGJlaGF2aW9yIHdpbGwgcmVkdWNlIHRo ZSBjb25nZXN0aW9uIHdpbmRvdyB3aGVuIHRoZSBtYXJraW5nIGZyYWN0aW9uIGlzIGxvdyBiZWNh dXNlIGlmIHdpbGwgcmVkdWNlIHdpdGggdGhlIGZpcnN0IG9jY3VycmVuY2Ugb2YgRUNFIGFuZCBh bGwgb3RoZXIgRUNFIG1hcmtpbmdzIHdpbGwgb2NjdXIgaW4gdGhlIGZvbGxvd2luZyBSVFQgd2hl cmUgdGhlIHdpbmRvdyBpcyBub3QgZnVydGhlciByZWR1Y2VkLiBUaGVyZWZvcmUgdGhlIHdpbmRv dyB3aWxsIG9ubHkgcmVhbGx5IGJlIHJlZHVjZWQgaWYgdGhlIGNvbmdlc3Rpb24gc3RheXMgZm9y IG1vcmUgdGhhbiBvbiBSVFQgKHRoYXQgZGVsYXlzIHRoZSByZWFjdGlvbiB0byBjb25nZXN0aW9u IGEgbGl0dGxlKS4gVGhhdOKAmXMgb2theSBiZWNhdXNlIHRoaXMgYWxsb3dzIHRvIG5vdCByZWFj dCB0byBzaG9ydC1idXJzdHMgb2YgY29uZ2VzdGlvbi4gSG93ZXZlciwgSSB0aGluayB0aGlzIHNo b3VsZCBiZSBtZW50aW9uZWQvZGlzY3Vzc2VkIGFzIGl0IG1pZ2h0IG5vdCBiZSBvYnZpb3VzIHdo ZW4gcmVhZGluZyB0aGUgZHJhZnQuDQo+IA0KDQo+PiBXZSBmaXhlZCBzb21lIHRleHQgaGVyZSBz byBwbGVhc2UgcmV2aWV3IGFnYWluLg0KDQo+IDEzKSBOZXh0IHNlbnRlbmNlIGlzDQo+ICJUaHVz LCB3aGVuIG5vIHNlbnQgYnl0ZSBleHBlcmllbmNlZCBjb25nZXN0aW9uLCBEQ1RDUC5BbHBoYSBl cXVhbHMNCj4gICB6ZXJvLCBhbmQgY3duZCBpcyBsZWZ0IHVuY2hhbmdlZC7igJwNCj4gSSB0aGlu ayB0aGlzIHNlbnRlbmNlIGlzIG5vbnNlbnNpY2FsIGFzIHRoZSBwcmV2aW91cyBzZW50ZW5jZSBz YXlzIHRoZSANCj4gY29uZ2VzdGlvbiB3aW5kb3cgd2lsbCBvbmx5IGJlIHJlZHVjZXMgaWYgY29u Z2VzdGlvbiBpcyBzaWduYWxlZOKApg0KPiANCg0KPj4gV2UgZml4ZWQgc29tZSB0ZXh0IGhlcmUg c28gcGxlYXNlIHJldmlldyBhZ2Fpbi4NCg0KPiAxNCkgQXMgYWxyZWFkeSBtZW50aW9uLCBzZWN0 aW9uIDUgc2hvdWxkIGFsc28gbWVudGlvbiBkZXBsb3ltZW50IHByb2JsZW1zIGlmIHVzZWQgaW4g cGFyYWxsZWwgdG8gdHJhZGl0aW9uYWwgVENQIGNvbmdlc3Rpb24gY29udHJvbC4NCj4gDQoNCj4+ IFllcyBhbHJlYWR5IGFkZHJlc3NlZA0KDQo+IDE1KSBTZWN0aW9uIDYgc2F5czoNCj4gIkhvd2V2 ZXIsIGlmIGFuDQo+ICAgQUNLIHBhY2tldCBpcyBkcm9wcGVkLCBpdCdzIHBvc3NpYmxlIHRoYXQg YSBzdWJzZXF1ZW50IEFDSyB3aWxsDQo+ICAgaW5kZWVkIGFja25vd2xlZGdlIGEgbWl4IG9mIENF IGFuZCBub24tQ0Ugc2VnbWVudHMu4oCcIEVpdGhlciBJIGRvbuKAmXQgDQo+IHVuZGVyc3RhbmQg dGhpcyBzZW50ZW5jZSBvciBpdCBpcyBub3QgdHJ1ZS4gVG8gbXkgdW5kZXJzdGFuZGluZyBhbiBB Q0sgaXMgZWl0aGVyIEVDRSBzZXQgb3Igbm90IGFuZCB0aGVyZWZvcmUgbWlnaHQgYWNrIENFIG1h cmtzIG9yIG5vdC4gSG93ZXZlciBpZiBlLmcuIG9ubHkgb25lIEFDSyBpcyBFQ0UgbWFya2VkIGFu ZCB0aGlzIGFjayBnZXRzIGxvc3QsIHRoZSBmb2xsb3dpbmcgbm9uLUVDRSBtYXJrZWQgQUNLIHdp bGwgYWNjdW11bGF0aXZlbHkgYWNrIGFsbCBwYWNrZXRzIGFzIG5vdC1DRSBtYXJrZWQgYW5kIHRo aXMgaW5mb3JtYXRpb24gaXMgY29tcGxldGVseSBsb3N0Lg0KPiANCg0KPj4gWWVzIHRoZXJlIGlz IGluZm9ybWF0aW9uIGxvc3MgZHVlIHRvIEFDSyBsb3NzIGFuZCB0aGF0IGlzIHdoYXQgc2VjdGlv biA2IGlzIGF0dGVtcHRpbmcgdG8gZXhwbGFpbi4gRG8geW91IGhhdmUgYW55IHN1Z2dlc3Rpb25z IGZvciBiZXR0ZXIgdGV4dD8NCg0KPiBUaGFua3MgYWdhaW4gZm9yIHdyaXRpbmcgdGhpcyBkb2N1 bWVudC4gSSBob3BlIGl0IGNhbiBiZSBwdWJsaXNoZWQgc29vbiENCj4gDQo+IE1pcmphDQo+IA0K PiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IHRjcG0gbWFpbGluZyBsaXN0DQo+IHRjcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQp0Y3BtIG1haWxpbmcgbGlzdA0KdGNwbUBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo= From nobody Mon Jul 13 04:24:23 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B809D1A7009 for ; Mon, 13 Jul 2015 04:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gebawb-jwHtI for ; Mon, 13 Jul 2015 04:24:18 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A1C1A876E for ; Mon, 13 Jul 2015 04:24:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B15DAD9305; Mon, 13 Jul 2015 13:24:15 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ImfjDLu4ITpO; Mon, 13 Jul 2015 13:24:15 +0200 (MEST) Received: from [192.168.178.33] (x4d02d263.dyn.telefonica.de [77.2.210.99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 073C2D9302; Mon, 13 Jul 2015 13:24:14 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 13 Jul 2015 13:24:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031D67EB-0676-4398-B5DF-E2F73D174E58@tik.ee.ethz.ch> To: Praveen Balasubramanian X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tcpm@ietf.org" , Dave Thaler Subject: Re: [tcpm] Review of draft-bensley-tcpm-dctcp-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 11:24:21 -0000 Hi Praveen, thanks for updating. See a few comments/responses below. Mirja >=20 >>=20 >> 2) This document does not describe what the Microsoft implementation = does if loss is detected. I think normally the assumption is that there = should be no (congestion-based) loss anymore in a data center where all = traffic is using DCTCP. However, the draft should still say what to do = if loss occurs. If I remember correctly the Linux implementation has a = configuration parameter to decide if a loss should be ignored or the = window should be halved. Maybe you can again clarify with Daniel = Borkmann who implemented this in Linux; I know he has read the draft and = is probably willing to review again or even provide some text on this if = needed. >>=20 >=20 >>> Windows Server does not adjust the value of Alpha for the round if = loss is detected. We are under discussion with Daniel about addressing = this in the next revision of the draft under Implementation issues = section. Great! I really would like to see loss handling addressed! >=20 >>=20 >> 2) The second point goes in the same direction: section 3.1 says: >> "However, the actual >> algorithm for marking congestion is an implementation detail of the >> switch and will generally not be known to the sender and receiver. >> Therefore, sender and receiver MUST NOT assume that a particular >> marking algorithm is implemented by the switching fabric.=E2=80=9C = First of=20 >> all, this informational document should not use normative language = here. And second, if DCTCP is used and tested by Microsoft only with a = certain configuration, I would remove this sentence and write rather = something like: >> =E2=80=9EEven though the actual >> algorithm for marking congestion is an implementation detail of the >> switch and will generally not be known to the sender and receive,=20 >> DCTCP has been design and evaluated to be used with the=20 >> configuration describe above.=E2=80=9C I=E2=80=99d like to add here that in a datacenter the AQM config might = actually be known and that=E2=80=99s the primary use case/deployment = scenario of DCTCP. So I don=E2=80=99t really say see why it is so = important for you to say that DCTCP works with different kind of AQM. If = it is design to be used in datacenters and you have tested it = extensively with one AQM config, why don=E2=80=99t you remember this = config? >=20 >>=20 >> 4) Second paragraph says "worker nodes complete at approximately the = same time=E2=80=9C. I thought that they would even complete at exactly = the same time because they often have a timeout..? Can you comment here = as well? Maybe also refer the DCTCP paper here because it contains a = good analysis of incast. >>=20 >=20 >>> The workloads are partitioned to the same size datasets and assuming = a uniform network and server configuration the tasks completing at the = same time is highly likely.=20 I was basically saying that you could make this point even stronger and = say e.g. =E2=80=9Eworks nodes are very likely to complete at the same = time=E2=80=9C and remove the =E2=80=9Aapproximately=E2=80=98. But in = fact that doesn=E2=80=99t really matter=E2=80=A6 >=20 >> 6) Abstract and intro both say =E2=80=9EDCTCP enhances ECN=E2=80=A6=E2=80= =9C; I really don=E2=80=99t think =E2=80=9Aenhance' can be used here so = generally; if the congestion control only needs one feedback signal per = RTT, there is no enhancement. Maybe say =E2=80=9Achange=E2=80=98 or = =E2=80=9Aimproves the accuracy of the ECN feedback signal by signal not = only the occurrence of congestion but also its extend=E2=80=98=E2=80=A6 = or something like this. >>=20 >=20 >>> We altered the language somewhat to make this clearer " Datacenter = TCP (DCTCP) improvises upon traditional ECN processing by =E2=80=A6". Not sure if improvises it the best word=E2=80=A6 maybe just say = =E2=80=9Aextends=E2=80=98=E2=80=A6? >=20 >> 8) I=E2=80=99d like to propose to use the list given in section 3 not = only to say which elements are =E2=80=9Ainvolved=E2=80=98 but also very = briefly say what was =E2=80=9Amodified=E2=80=98, e.g. >>=20 >> "There are three components that needs to be modified to use DCTCP: >>=20 >> o The switch (or other intermediate device on the network) detects >> congestion and sets the Congestion Experienced (CE) codepoint in >> the IP header already when a very short queue builds up.=20 >>=20 >> o The receiver echoes each occurrence of a the Congestion = Experienced (CE) mark >> back to the sender using the ECN-Echo (ECE) flag in the TCP = header. >>=20 >> o The sender reacts to the congestion indication by reducing the = TCP >> congestion window (cwnd) based on the extend of congestion=20 >> experienced in the last RTT.=E2=80=9C >>=20 >> I think this given a nice high-level overview and helps the reader to = easier understand the rest. >>=20 >> 9) Maybe add to section 3.2 the state machine image as provided in=20= >> the paper. I personally would, in an RFC, also describe the algo=20 >> first and then give the reasoning but that=E2=80=99s a matter of = which style=20 >> is preferred=E2=80=A6 >>=20 >=20 >>> Other implementations seem to have got the algorithm correct without = needing more explanation here. If you think it's not clear enough, we = will revisit adding more details in next revision.=20 I=E2=80=99ve been mention this because I=E2=80=99ve been playing around = with the DCTCP implementation provided by Stanford a while ago. At that = point of time I was using the DCTCP paper as a reference and I found the = diagram super helpful. I know having graphics in ASCII art is not super = nice but I guess the state machine would be easy to draw (also it might = be possible in future to at real graphic to RFC=E2=80=A6). >=20 >> 10) Section 3.3: Quick question: Why is the fraction of marked = packets called M in the draft while it=E2=80=99s F in the paper? >>=20 >=20 >>> There has been no attempt to reconcile the draft with the paper to = use the same terminology.=20 >=20 >> 11) Again Section 3.3: Maybe mention somewhere that the SACK = information are not used to calculate BytesAcked because usually it=E2=80=99= s assumed to have no loss with the use of DCTCP. However, I guess if a = calculation as given in RFC6937 (PRR) for DeliveredData is used, that is = probably okay as well and should not be a problem, right? >>=20 >=20 >>> That's correct. Loss handling will have to be addressed in a future = revision. The current implementation does not use SACK information. Maybe just add one sentence saying =E2=80=9ESACK information is not used = as it is assumed that there will be no losses if DCTCP is used in a = datacenter for all traffic.=E2=80=9C However, if you actually plan to = used the SACK information in a future revision that=E2=80=99s fine as = well. >=20 >> 12) Further section 3.3 says "when the sender receives an indication = of congestion=E2=80=9C. Can you maybe be a little more specify here and = say =E2=80=9Eif the first ECE is received in a RTT=E2=80=9C or something = like this. Please also note that this behavior will reduce the = congestion window when the marking fraction is low because if will = reduce with the first occurrence of ECE and all other ECE markings will = occur in the following RTT where the window is not further reduced. = Therefore the window will only really be reduced if the congestion stays = for more than on RTT (that delays the reaction to congestion a little). = That=E2=80=99s okay because this allows to not react to short-bursts of = congestion. However, I think this should be mentioned/discussed as it = might not be obvious when reading the draft. >>=20 >=20 >>> We fixed some text here so please review again. If I=E2=80=99ve seen this correctly, you=E2=80=99ve only added the ECE = in brackets? Maybe even say "when the sender receives the first indication of congestion (ECE) with = in one RTT=E2=80=9C ..? Further I=E2=80=99d like to see some more text (1-2 sentences) stating = what I was saying above. With the reception of the first ECE, alpha is = usually low (maybe even zero) and only if the congestion stays for more = than one RTT it will be updated and reduced more. Maybe you also want to = check this in measurements/simulations. Would be interesting to see more = data here. But that=E2=80=99s what we=E2=80=99ve seen when we did our = first experiments with DCTCP. >=20 >> 13) Next sentence is >> "Thus, when no sent byte experienced congestion, DCTCP.Alpha equals >> zero, and cwnd is left unchanged.=E2=80=9C >> I think this sentence is nonsensical as the previous sentence says = the=20 >> congestion window will only be reduces if congestion is signaled=E2=80=A6= >>=20 >=20 >>> We fixed some text here so please review again. Maybe just say=20 =E2=80=9EIf congestion is very low and DCTCP.Alpha equals zero, and cwnd = is left unchanged.=E2=80=9C Because there must be at least one ECE and therefore it can not be the = case that 'no sent byte experienced congestion=E2=80=98. >=20 >> 14) As already mention, section 5 should also mention deployment = problems if used in parallel to traditional TCP congestion control. >>=20 >=20 >>> Yes already addressed Thanks! >=20 >> 15) Section 6 says: >> "However, if an >> ACK packet is dropped, it's possible that a subsequent ACK will >> indeed acknowledge a mix of CE and non-CE segments.=E2=80=9C Either = I don=E2=80=99t=20 >> understand this sentence or it is not true. To my understanding an = ACK is either ECE set or not and therefore might ack CE marks or not. = However if e.g. only one ACK is ECE marked and this ack gets lost, the = following non-ECE marked ACK will accumulatively ack all packets as = not-CE marked and this information is completely lost. >>=20 >=20 >>> Yes there is information loss due to ACK loss and that is what = section 6 is attempting to explain. Do you have any suggestions for = better text? I=E2=80=99d suggest the following sentence instead to make it more = clear: =E2=80=9EHowever, if an ACK is dropped and the lost ACK was carrying a = different marking that the subsequent accumulative ACK, the marking = information will be lost.=E2=80=9C >=20 >> Thanks again for writing this document. I hope it can be published = soon! >>=20 >> Mirja >>=20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Jul 13 08:49:01 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEE51B2BD5 for ; Mon, 13 Jul 2015 08:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Bf1VnRCPAvJo for ; Mon, 13 Jul 2015 08:48:59 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::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 CFE321ACEF0 for ; Mon, 13 Jul 2015 08:48:58 -0700 (PDT) Received: by widjy10 with SMTP id jy10so73601135wid.1 for ; Mon, 13 Jul 2015 08:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=+r9CSTVYsgSoE4l+yhR/huCOz9B0aWbiq9y8etBnRn4=; b=nsJ1SRdQqYuf//BtKYvHiaUI9tBmIJZvXoDAlyBI7wp42vO4pivwnJC7+sLGGZGL3n +ZzwwiiwGSWXdER8svHTYBkOcu060SqFelqq3Dc5OOcoUZLw1bPvFlESTRD77ligQFWZ F0wT0GTVxsTRWGUWNCmHKGHnG4yycBJC0uwKmfZqYlVl8NrPU5wbF5fyWobkWyw5FlZm AC010kK+yfzKpBHSvIWihiya5nDl903U+CbZG33G956Pynqas7ekmoO6Bbj/i6P8C0E3 PPO/lnGwZyHAZ1z+zxONjck+Xfjlv0tuHsx2Zjf0bk1XPdx7tmbM0Ia6CnIOQiBsOtve xBPQ== MIME-Version: 1.0 X-Received: by 10.180.84.194 with SMTP id b2mr23111532wiz.36.1436802537560; Mon, 13 Jul 2015 08:48:57 -0700 (PDT) Received: by 10.27.15.20 with HTTP; Mon, 13 Jul 2015 08:48:57 -0700 (PDT) Date: Mon, 13 Jul 2015 17:48:57 +0200 Message-ID: From: Naeem Khademi To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=f46d04426b98dd1f45051ac3a8c3 Archived-At: Cc: Michael Welzl Subject: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 15:49:00 -0000 --f46d04426b98dd1f45051ac3a8c3 Content-Type: text/plain; charset=UTF-8 Hi all Please note the new Internet draft "TCP Alternative Backoff with ECN (ABE)" on https://tools.ietf.org/html/draft-khademi-alternativebackoff-ecn-00 We have been working to get better than current ECN and thus providing a path for ECN deployment using a very simple sender-side modification (this is not intended to compete with work on Accurate ECN) and only the existing router ECN marking with the AQM mechanisms being deployed today. Please read the draft, and send comments and questions to the list. Also note that a technical report on ABE's evaluation is available at: http://caia.swin.edu.au/reports/150710A/CAIA-TR-150710A.pdf Cheers, Naeem --f46d04426b98dd1f45051ac3a8c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all=C2=A0

Please note the new Intern= et draft "TCP Alternative Backoff with ECN (ABE)" on https:/= /tools.ietf.org/html/draft-khademi-alternativebackoff-ecn-00
=
We have been working to get better than current ECN and= thus providing a path for ECN deployment using a very simple sender-side m= odification (this is not intended to compete with work on Accurate ECN) and= only the existing router ECN marking with the AQM mechanisms being deploye= d today.

Please read the draft, and send comments = and questions to the list. Also note that a technical report on ABE's e= valuation is available at: http://caia.swin.edu.au/reports/150710A/CAIA-TR-150= 710A.pdf

Cheers,
Naeem=C2=A0
=C2=A0=C2=A0
--f46d04426b98dd1f45051ac3a8c3-- From nobody Mon Jul 13 11:19:42 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057971A86FD for ; Mon, 13 Jul 2015 11:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 KBBD3AyBhGGi for ; Mon, 13 Jul 2015 11:19:39 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AC31B2D2E for ; Mon, 13 Jul 2015 11:19:08 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id t6DIJ5ke001744; Mon, 13 Jul 2015 11:19:05 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 01BA71C0AFD6; Mon, 13 Jul 2015 14:19:03 -0400 (EDT) To: Naeem Khademi From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Mexicali Blues X-URL-0: http://www.icir.org/mallman-files/Document70841.jpg X-URL-1: http://www.icir.org/mallman-files/Document71390.html X-URL-2: http://www.icir.org/mallman-files/Document31259.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 13 Jul 2015 14:19:02 -0400 Message-ID: <34234.1436811542@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 18:19:41 -0000 --=-------459435943823349593450 Content-Type: text/plain > Please note the new Internet draft "TCP Alternative Backoff with ECN > (ABE)" on > https://tools.ietf.org/html/draft-khademi-alternativebackoff-ecn-00 I read this draft. It doesn't hurt that the list of authors is the biggest section in the document! :) I have two thoughts ... - Rather than saying the backoff should be 0.8, why not just say the reaction should be whatever the reaction to loss is? I.e., why specify some number here? The spirit of the original spec is that an ECN mark is the network saying "I should have dropped your packet, but I am being nice" and so the reaction should be the exact same as a loss. The RFC doesn't exactly say that because at the time there was only one reaction and yeah I guess we should have had better foresight with the words, but we didn't. But, why now not just leave it as "just as loss" and elide the specifics and hence avoid the mistake a second time? - Maybe instead of saying the backoff has to be just as it is for a loss, why not say the multiplier is (oh I dunno) 1.1 * loss_multiplier. So, if the backoff is usually cwnd *= 0.7 on a loss then on an CE mark it is cwnd *= 0.77. That provides a tangible incentive to use ECN (rather than the nebulous and dubious incentives in the original version). Just two quick thoughts ... FWIW ... allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlWkARQACgkQWyrrWs4yIs50HwCdHZs0+T64kw/7iArk+EFOO7ed DrsAn3IMaiARDmjd5WlIoEbP1t8+i1XY =dCH3 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Jul 13 11:39:30 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB9E1A8740 for ; Mon, 13 Jul 2015 11:39:28 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 6S8fu_1VaDE2 for ; Mon, 13 Jul 2015 11:39:22 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::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 6CF311A8767 for ; Mon, 13 Jul 2015 11:39:22 -0700 (PDT) Received: by wgkl9 with SMTP id l9so32881359wgk.1 for ; Mon, 13 Jul 2015 11:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n2Yy4/hnyuMC7feqwSfeT+lF5R0TFap7vLm/Pb62NhY=; b=zYvdKXWMbo72feDPvtisR+TEFnjYWJNZulrgqpLDkB8IRcHhGB8PuUH91XebXpQcyr RDxtZ6KuY2GKIrSj+pRclaNQiNcSW6ZIVb1x7YjXm38+hYrblSWzbtJpIdMj07rtVOTr jaEiTh4KXiHI8j2CpjptCpqFY33FDd+A9if0WJEl+uupAQVTBelBOoYiJgFWPYQDD62j br4RY1SnLyikULijBjV8mtYrFUodTbJ0qvqDSZDGUmAt9uAgFVEJGQ2EAxVe0zlvCHRF lgMo0W2Cd7y456Nyp0YOjyQao0zqOsXH7ANIiAcIqHO/N3hu6ALN8+iEYOK1QG9Gn0Os cF5g== MIME-Version: 1.0 X-Received: by 10.180.10.163 with SMTP id j3mr25556702wib.34.1436812761194; Mon, 13 Jul 2015 11:39:21 -0700 (PDT) Received: by 10.27.15.20 with HTTP; Mon, 13 Jul 2015 11:39:21 -0700 (PDT) In-Reply-To: <34234.1436811542@lawyers.icir.org> References: <34234.1436811542@lawyers.icir.org> Date: Mon, 13 Jul 2015 20:39:21 +0200 Message-ID: From: Naeem Khademi To: mallman@icir.org Content-Type: multipart/alternative; boundary=001a11c260143d6601051ac60ac1 Archived-At: Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 18:39:28 -0000 --001a11c260143d6601051ac60ac1 Content-Type: text/plain; charset=UTF-8 Hi Mark Please see inline: On Mon, Jul 13, 2015 at 8:19 PM, Mark Allman wrote: > > > Please note the new Internet draft "TCP Alternative Backoff with ECN > > (ABE)" on > > https://tools.ietf.org/html/draft-khademi-alternativebackoff-ecn-00 > > I read this draft. It doesn't hurt that the list of authors is the > biggest section in the document! :) > > I have two thoughts ... > > - Rather than saying the backoff should be 0.8, why not just say > the reaction should be whatever the reaction to loss is? I.e., > why specify some number here? The spirit of the original spec > is that an ECN mark is the network saying "I should have dropped > your packet, but I am being nice" and so the reaction should be > the exact same as a loss. The RFC doesn't exactly say that > because at the time there was only one reaction and yeah I guess > we should have had better foresight with the words, but we > didn't. But, why now not just leave it as "just as loss" and > elide the specifics and hence avoid the mistake a second time? > An ECN mark is an *explicit* indication of an AQM presence on the bottleneck link, whereas a packet loss simply is not! ECN in term of routers doing CE-marking has not been used since its introduction approx. 15 years ago, therefore a CE-mark today on the Internet would *most likely* to indicate the presence of an AQM that is trying to keep the latency low (in order of 5ms~20ms on the average for (FQ_)CoDel and PIE as shipped) and therefore a beta_{ecn}=0.5 is too conservative for such low thresholds. With a packet loss that's not the case since packet loss may have been caused by many other factors such as tail-loss, channel errors, etc. > > - Maybe instead of saying the backoff has to be just as it is for > a loss, why not say the multiplier is (oh I dunno) > 1.1 * loss_multiplier. So, if the backoff is usually cwnd *= > 0.7 on a loss then on an CE mark it is cwnd *= 0.77. That > provides a tangible incentive to use ECN (rather than the > nebulous and dubious incentives in the original version). > Assuming tail-loss, the maximum size of the buffer (which produces tail-loss) has little to do with the AQM threshold being deployed on that buffer so they are quite unrelated. We have (almost) clear indications of where (at which thresholds) CE-marking happens with the current AQMs. With loss, that indication isn't present whether the loss is a tail-loss or caused by other factors. > > Just two quick thoughts ... FWIW ... > I hope that answers your comments clearly. > > allman > > > Cheers, Naeem --001a11c260143d6601051ac60ac1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mark=C2=A0

Please see inline:= =C2=A0


On Mon, Jul 13, 2015 at 8:19 PM, Mark Allman <mallman@icir.or= g> wrote:
=
> Please note the new Internet draft "TCP Alternative Backoff with = ECN
> (ABE)" on
> https://tools.ietf.org/html/= draft-khademi-alternativebackoff-ecn-00

I read this draft.=C2=A0 It doesn't hurt that the list of author= s is the
biggest section in the document! :)

I have two thoughts ...

=C2=A0 - Rather than saying the backoff should be 0.8, why not just say
=C2=A0 =C2=A0 the reaction should be whatever the reaction to loss is?=C2= =A0 I.e.,
=C2=A0 =C2=A0 why specify some number here?=C2=A0 The spirit of the origina= l spec
=C2=A0 =C2=A0 is that an ECN mark is the network saying "I should have= dropped
=C2=A0 =C2=A0 your packet, but I am being nice" and so the reaction sh= ould be
=C2=A0 =C2=A0 the exact same as a loss.=C2=A0 The RFC doesn't exactly s= ay that
=C2=A0 =C2=A0 because at the time there was only one reaction and yeah I gu= ess
=C2=A0 =C2=A0 we should have had better foresight with the words, but we =C2=A0 =C2=A0 didn't.=C2=A0 But, why now not just leave it as "jus= t as loss" and
=C2=A0 =C2=A0 elide the specifics and hence avoid the mistake a second time= ?

An ECN mark is an *explicit* indicati= on of an AQM presence on the bottleneck link, whereas a packet loss simply = is not!=C2=A0

ECN in term of routers doing CE-mark= ing has not been used since its introduction approx. 15 years ago, therefor= e a CE-mark today on the Internet would *most likely* to indicate the prese= nce of an AQM that is trying to keep the latency low (in order of 5ms~20ms = on the average for (FQ_)CoDel and PIE as shipped) and therefore a beta_{ecn= }=3D0.5 is too conservative for such low thresholds. With a packet loss tha= t's not the case since packet loss may have been caused by many other f= actors such as tail-loss, channel errors, etc.
=C2=A0 =C2=A0
<= /div>
=C2=A0

=C2=A0 - Maybe instead of saying the backoff has to be just as it is for =C2=A0 =C2=A0 a loss, why not say the multiplier is (oh I dunno)
=C2=A0 =C2=A0 1.1 * loss_multiplier.=C2=A0 So, if the backoff is usually cw= nd *=3D
=C2=A0 =C2=A0 0.7 on a loss then on an CE mark it is cwnd *=3D 0.77.=C2=A0 = That
=C2=A0 =C2=A0 provides a tangible incentive to use ECN (rather than the
=C2=A0 =C2=A0 nebulous and dubious incentives in the original version).
=

Assuming tail-loss, the maximum size of th= e buffer (which produces tail-loss) has little to do with the AQM threshold= being deployed on that buffer so they are quite unrelated. We have (almost= ) clear indications of where (at which thresholds) CE-marking happens with = the current AQMs. With loss, that indication isn't present whether the = loss is a tail-loss or caused by other factors.=C2=A0
=C2=A0

Just two quick thoughts ... FWIW ...

I = hope that answers your comments clearly.=C2=A0
=C2=A0

allman



Cheers,
Naeem<= /div>
=C2=A0

--001a11c260143d6601051ac60ac1-- From nobody Mon Jul 13 11:58:20 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37AB1B2D45 for ; Mon, 13 Jul 2015 11:58:18 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ho4qNMTLVw-e for ; Mon, 13 Jul 2015 11:58:17 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F361B2D41 for ; Mon, 13 Jul 2015 11:58:17 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id t6DIwDPv008318; Mon, 13 Jul 2015 11:58:14 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id ED2241C0BAD3; Mon, 13 Jul 2015 14:58:10 -0400 (EDT) To: Naeem Khademi From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Mexicali Blues X-URL-0: http://www.icir.org/mallman-files/Document96516.doc X-URL-1: http://www.icir.org/mallman-files/Document13278.pdf X-URL-2: http://www.icir.org/mallman-files/Document7247.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 13 Jul 2015 14:58:10 -0400 Message-ID: <40962.1436813890@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 18:58:19 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > - Rather than saying the backoff should be 0.8, why not just say > the reaction should be whatever the reaction to loss is? I.e., > why specify some number here? The spirit of the original spec > is that an ECN mark is the network saying "I should have > dropped your packet, but I am being nice" and so the reaction > should be the exact same as a loss. The RFC doesn't exactly > say that because at the time there was only one reaction and > yeah I guess we should have had better foresight with the > words, but we didn't. But, why now not just leave it as "just > as loss" and elide the specifics and hence avoid the mistake a > second time? >=20 > An ECN mark is an *explicit* indication of an AQM presence on the > bottleneck link, whereas a packet loss simply is not! Sure. > ECN in term of routers doing CE-marking has not been used since > its introduction approx. 15 years ago, therefore a CE-mark today > on the Internet would *most likely* to indicate the presence of an > AQM that is trying to keep the latency low (in order of 5ms~20ms > on the average for (FQ_)CoDel and PIE as shipped) and therefore a > beta_ {ecn}=3D0.5 is too conservative for such low thresholds. With > a packet loss that's not the case since packet loss may have been > caused by many other factors such as tail-loss, channel errors, > etc. So, my take was that your 0.8 backoff is "do what CUBIC does" whereas the original ECN is "do what 5681 does". Except in both cases it is specified as what CUBIC or 5681 does and not as a pointer to those documents. And, my suggestion is to not re-specify the CC response, but instead say "do what the underlying CC does" so we don't have to write another document for each CC response we might ever see. Now, above it seems you are saying 0.5 is simply inappropriate as a response when we know we are responding to congestion in a place that is using some sort of AQM (what kind of course TCP doesn't know). Perhaps that is correct. So, why is 0.8 appropriate? When I read the draft I thought you were rooting 0.8 in CUBIC's response. But, if you are not then you have to tell me why 0.8 (or whatever you choose) is reasonable. > - Maybe instead of saying the backoff has to be just as it is > for > a loss, why not say the multiplier is (oh I dunno) > 1.1 * loss_multiplier. So, if the backoff is usually cwnd *=3D > 0.7 on a loss then on an CE mark it is cwnd *=3D 0.77. That > provides a tangible incentive to use ECN (rather than the > nebulous and dubious incentives in the original version). >=20 > Assuming tail-loss, the maximum size of the buffer (which produces > tail-loss) has little to do with the AQM threshold being deployed > on that buffer so they are quite unrelated. We have (almost) clear > indications of where (at which thresholds) CE-marking happens with > the current AQMs. With loss, that indication isn't present whether > the loss is a tail-loss or caused by other factors. I don't have any idea what any of that means or how it speaks to my point. All I am saying is that perhaps we incentivize ECN deployment by making the response softer than the response to loss as a general principle. I.e., as you note, a CE is an explicit indication of AQM and hence that the link is not completely full and so perhaps we don't have to backoff as dramatically. If ECN deployment is a chicken and egg problem then perhaps this helps us break free from that. (And, in fact, perhaps this provides an actual reason to deploy ECN ... because when ECN marks are the same as loss there isn't really much point in ECN at all relative to the costs. As evidence, I would point you at ... reality! :) ) allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlWkCkIACgkQWyrrWs4yIs7aqgCfQD3Er91hCMxShMQRawpss4cW fiEAn0PVkxmW2Ibx9otWP6Wj3+KZVQa1 =scOm -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Jul 13 14:42:24 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799051A1A2E for ; Mon, 13 Jul 2015 14:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CL5iuB9vSsNv for ; Mon, 13 Jul 2015 14:42:20 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 578F71A0A6A for ; Mon, 13 Jul 2015 14:42:20 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZElUP-0002ya-N2; Mon, 13 Jul 2015 23:42:17 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZElUP-0005fY-1t; Mon, 13 Jul 2015 23:42:17 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <40962.1436813890@lawyers.icir.org> Date: Mon, 13 Jul 2015 23:42:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B393016-C4A1-4502-8F37-6656B13AD8A6@ifi.uio.no> References: <40962.1436813890@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 3 total rcpts 30928 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0137A33315DCD6B24B840CB35781B554B4524F6C X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1290 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 21:42:23 -0000 > On 13. jul. 2015, at 20.58, Mark Allman wrote: >=20 >=20 >> - Rather than saying the backoff should be 0.8, why not just say >> the reaction should be whatever the reaction to loss is? I.e., >> why specify some number here? The spirit of the original spec >> is that an ECN mark is the network saying "I should have >> dropped your packet, but I am being nice" and so the reaction >> should be the exact same as a loss. The RFC doesn't exactly >> say that because at the time there was only one reaction and >> yeah I guess we should have had better foresight with the >> words, but we didn't. But, why now not just leave it as "just >> as loss" and elide the specifics and hence avoid the mistake a >> second time? >>=20 >> An ECN mark is an *explicit* indication of an AQM presence on the >> bottleneck link, whereas a packet loss simply is not! >=20 > Sure. >=20 >> ECN in term of routers doing CE-marking has not been used since >> its introduction approx. 15 years ago, therefore a CE-mark today >> on the Internet would *most likely* to indicate the presence of an >> AQM that is trying to keep the latency low (in order of 5ms~20ms >> on the average for (FQ_)CoDel and PIE as shipped) and therefore a >> beta_ {ecn}=3D0.5 is too conservative for such low thresholds. With >> a packet loss that's not the case since packet loss may have been >> caused by many other factors such as tail-loss, channel errors, >> etc. >=20 > So, my take was that your 0.8 backoff is "do what CUBIC does" > whereas the original ECN is "do what 5681 does". Except in both > cases it is specified as what CUBIC or 5681 does and not as a > pointer to those documents. And, my suggestion is to not re-specify > the CC response, but instead say "do what the underlying CC does" so > we don't have to write another document for each CC response we > might ever see. >=20 > Now, above it seems you are saying 0.5 is simply inappropriate as a > response when we know we are responding to congestion in a place > that is using some sort of AQM (what kind of course TCP doesn't > know). Perhaps that is correct. So, why is 0.8 appropriate? When > I read the draft I thought you were rooting 0.8 in CUBIC's response. > But, if you are not then you have to tell me why 0.8 (or whatever > you choose) is reasonable. CUBIC went from 0.8 to 0.7 at some point, god knows why. Anyway, indeed = CUBIC isn't our reason for choosing 0.8; for a BDP worth of queuing, 0.7 = is too much too - but then, who knows how large queues really are these = days... we're not debating that point, just the fact that the signal = from AQM comes from a shorter queue As for the reasoning for 0.8, I'm sorry that it wasn't available until = now, but here it is, at last: http://caia.swin.edu.au/reports/150710A/CAIA-TR-150710A.pdf >> - Maybe instead of saying the backoff has to be just as it is >> for >> a loss, why not say the multiplier is (oh I dunno) >> 1.1 * loss_multiplier. So, if the backoff is usually cwnd *=3D >> 0.7 on a loss then on an CE mark it is cwnd *=3D 0.77. That >> provides a tangible incentive to use ECN (rather than the >> nebulous and dubious incentives in the original version). >>=20 >> Assuming tail-loss, the maximum size of the buffer (which produces >> tail-loss) has little to do with the AQM threshold being deployed >> on that buffer so they are quite unrelated. We have (almost) clear >> indications of where (at which thresholds) CE-marking happens with >> the current AQMs. With loss, that indication isn't present whether >> the loss is a tail-loss or caused by other factors. >=20 > I don't have any idea what any of that means or how it speaks to my > point. >=20 > All I am saying is that perhaps we incentivize ECN deployment by > making the response softer than the response to loss as a general > principle. I.e., as you note, a CE is an explicit indication of AQM > and hence that the link is not completely full and so perhaps we > don't have to backoff as dramatically. If ECN deployment is a > chicken and egg problem then perhaps this helps us break free from > that. (And, in fact, perhaps this provides an actual reason to > deploy ECN ... because when ECN marks are the same as loss there > isn't really much point in ECN at all relative to the costs. As > evidence, I would point you at ... reality! :) ) Yes! Cheers, Michael From nobody Mon Jul 13 15:36:46 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0801A854B for ; Mon, 13 Jul 2015 15:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CCOqbanmunRM for ; Mon, 13 Jul 2015 15:36:43 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B894C1A8547 for ; Mon, 13 Jul 2015 15:36:42 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 458D4C94C6; Mon, 13 Jul 2015 18:36:37 -0400 (EDT) Date: Mon, 13 Jul 2015 18:36:37 -0400 From: John Leslie To: Mark Allman Message-ID: <20150713223637.GA54621@verdi> References: <40962.1436813890@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <40962.1436813890@lawyers.icir.org> User-Agent: Mutt/1.4.1i Archived-At: Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 22:36:44 -0000 Mark Allman wrote: > [Naeem Khademi wrote] >>=20 >> An ECN mark is an *explicit* indication of an AQM presence on the >> bottleneck link, whereas a packet loss simply is not! >=20 > Sure. >=20 >>... a CE-mark today on the Internet would *most likely* to indicate >> the presence of an AQM that is trying to keep the latency low... >=20 > So, my take was that your 0.8 backoff is "do what CUBIC does" > whereas the original ECN is "do what 5681 does". Except in both > cases it is specified as what CUBIC or 5681 does and not as a > pointer to those documents. And, my suggestion is to not re-specify > the CC response, but instead say "do what the underlying CC does" so > we don't have to write another document for each CC response we > might ever see. Indeed, we should specify and justify what we mean to do. No reader should have to guess at what we mean. > Now, above it seems you are saying 0.5 is simply inappropriate as a > response when we know we are responding to congestion in a place > that is using some sort of AQM (what kind of course TCP doesn't > know). Indeed: we can only know "some sort of AQM". But IMHO, we can say that ECN-CE _should_ indicate an AQM as opposed to tail-drop. Also IMHO, we should say somewhere that ECN-CE _should_not_ be used when the buffer is essentially full. > Perhaps that is correct. So, why is 0.8 appropriate? When > I read the draft I thought you were rooting 0.8 in CUBIC's response. > But, if you are not then you have to tell me why 0.8 (or whatever > you choose) is reasonable. I agree. (And I look at the issue quite differently and wouldn't recommend simply "s/0.5/0.8/") >> Assuming tail-loss, the maximum size of the buffer (which produces >> tail-loss) has little to do with the AQM threshold being deployed >> on that buffer so they are quite unrelated. We have (almost) clear >> indications of where (at which thresholds) CE-marking happens with >> the current AQMs. With loss, that indication isn't present whether >> the loss is a tail-loss or caused by other factors. >=20 > I don't have any idea what any of that means or how it speaks to my > point. I also have trouble understanding it: it sounds as if the sender is supposed to guess what the AQM is doing; and I don't see why the sender has enough information to make a good guess. It appears to be arguing that this is safe to deploy because CUBIC has been doing it for years and is widely deployed. The weakness of that argument is that CUBIC _also_ does things to make sure the sending rate doesn't grow back as quickly as RENO does. We can't pick and choose just a few pieces of a congestion control scheme. > All I am saying is that perhaps we incentivize ECN deployment by > making the response softer than the response to loss as a general > principle. I.e., as you note, a CE is an explicit indication of AQM > and hence that the link is not completely full and so perhaps we > don't have to backoff as dramatically. We know that's true -- but if that's all we graft on, folks will claim that ECN gets an unfair share. We also need an argument that our ECN scheme won't grow sending rate as fast as RENO -- at least for a little while. > If ECN deployment is a chicken and egg problem then perhaps this > helps us break free from that. (And, in fact, perhaps this provides > an actual reason to deploy ECN ... More deployment is good... -- John Leslie From nobody Mon Jul 13 22:03:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B8A1A00CF for ; Mon, 13 Jul 2015 22:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8yYakJx5CAEu for ; Mon, 13 Jul 2015 22:03:35 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9EF91A00D6 for ; Mon, 13 Jul 2015 22:03:34 -0700 (PDT) Received: from 5-12-82-72.residential.rdsnet.ro ([5.12.82.72] helo=[192.168.0.100]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (C.Raiciu authenticated) (Exim 4.54) id 1ZEsNM-00033b-PC for tcpm@ietf.org; Tue, 14 Jul 2015 06:03:28 +0100 From: Costin Raiciu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9DB8FC9C-62C1-46A3-AE60-FE38B6233DC1@cs.ucl.ac.uk> Date: Tue, 14 Jul 2015 08:04:06 +0300 To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [tcpm] TCP sendbuffer advertising X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 05:03:38 -0000 Dear all, We have been working on a simple extension to TCP that encode the amount = of backlogged bytes in each TCP segment. This information can be used by = the network or the receiver for various optimizations. I will be present our work during the TCPM working group in Prague. This = email is a heads-up for those interested in hearing more about the work = before it is presented. We have written a draft on the encoding, but unfortunately we have = missed the Prague cutoff. You can download the draft from my webpage at = http://nets.cs.pub.ro/~costin/files/draft-agache-tcpm-sndbufadv.txt We will submit it properly as soon as the I-D submission tool reopens on = saturday. We also have a workshop paper in HotClout 2015 on the various use-cases = of send buffer advertising, and our prototype implementation, that you = can find at: http://nets.cs.pub.ro/~costin/files/sndbuf.pdf We are looking forward to your comments. Best. Costin ---------------------------------------------- Costin Raiciu Associate Professor Homepage: http://nets.cs.pub.ro/~costin/ CS Department University Politehnica of Bucharest= From nobody Mon Jul 13 22:26:57 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1071A014B for ; Mon, 13 Jul 2015 22:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LccJnhY_e0Dr for ; Mon, 13 Jul 2015 22:26:53 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 C77BB1A0149 for ; Mon, 13 Jul 2015 22:26:52 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZEsjw-0005Rk-Ft; Tue, 14 Jul 2015 07:26:48 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZEsjv-0004eH-S1; Tue, 14 Jul 2015 07:26:48 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <20150713223637.GA54621@verdi> Date: Tue, 14 Jul 2015 07:26:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2B50F773-874C-43BA-9275-4323EFABC3EA@ifi.uio.no> References: <40962.1436813890@lawyers.icir.org> <20150713223637.GA54621@verdi> To: John Leslie X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 6 sum msgs/h 1 total rcpts 30932 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D3E59F8C41ADB67F5DDD06B45EA32A2513C11DB2 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1291 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tcpm@ietf.org, Mark Allman Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 05:26:56 -0000 Hi all, Sorry for the confusion that was apparently caused by: 1) the draft being very short 2) the technical report with results ( = http://caia.swin.edu.au/reports/150710A/CAIA-TR-150710A.pdf ) appearing = with a bit of delay As I wrote in my response to Mark, CUBIC wasn't our reason for picking = 0.8, the choice is based on the results in the technical report. About = the lack of detail in the draft (item 1), our intention was simply to = start minimal and gradually add information that people request. So, about the choice of 0.8, our technical report concludes: *** Setting =CE=B2ecn =E2=88=88 [0.7, 0.85] for NewReno and =CE=B2ecn =E2=89=88= 0.85 for CUBIC seems to provide reasonable trade-offs between latency, = throughput and fairness across a wide range of scenarios. *** ...and we picked 0.8 out of this interval for no other reason than: it's = a middle ground but leaning more towards the upper ( =3D more effect ) = end. We could also generally recommend 0.85, for instance, and I guess = none of us authors has strong feelings about a particular choice of = value from the interval above. Look at it as a parameter change. RFC 6928 changes IW from 3 to 10 (for = 1500-byte packets), we suggest to change the backoff factor from 0.5 to = 0.8 for the ECN response. Cheers, Michael > On 14. jul. 2015, at 00.36, John Leslie wrote: >=20 > Mark Allman wrote: >> [Naeem Khademi wrote] >>>=20 >>> An ECN mark is an *explicit* indication of an AQM presence on the >>> bottleneck link, whereas a packet loss simply is not! >>=20 >> Sure. >>=20 >>> ... a CE-mark today on the Internet would *most likely* to indicate >>> the presence of an AQM that is trying to keep the latency low... >>=20 >> So, my take was that your 0.8 backoff is "do what CUBIC does" >> whereas the original ECN is "do what 5681 does". Except in both >> cases it is specified as what CUBIC or 5681 does and not as a >> pointer to those documents. And, my suggestion is to not re-specify >> the CC response, but instead say "do what the underlying CC does" so >> we don't have to write another document for each CC response we >> might ever see. >=20 > Indeed, we should specify and justify what we mean to do. No reader > should have to guess at what we mean. >=20 >> Now, above it seems you are saying 0.5 is simply inappropriate as a >> response when we know we are responding to congestion in a place >> that is using some sort of AQM (what kind of course TCP doesn't >> know). >=20 > Indeed: we can only know "some sort of AQM". But IMHO, we can say > that ECN-CE _should_ indicate an AQM as opposed to tail-drop. Also = IMHO, > we should say somewhere that ECN-CE _should_not_ be used when the = buffer > is essentially full. >=20 >> Perhaps that is correct. So, why is 0.8 appropriate? When >> I read the draft I thought you were rooting 0.8 in CUBIC's response. >> But, if you are not then you have to tell me why 0.8 (or whatever >> you choose) is reasonable. >=20 > I agree. (And I look at the issue quite differently and wouldn't > recommend simply "s/0.5/0.8/") >=20 >>> Assuming tail-loss, the maximum size of the buffer (which produces >>> tail-loss) has little to do with the AQM threshold being deployed >>> on that buffer so they are quite unrelated. We have (almost) clear >>> indications of where (at which thresholds) CE-marking happens with >>> the current AQMs. With loss, that indication isn't present whether >>> the loss is a tail-loss or caused by other factors. >>=20 >> I don't have any idea what any of that means or how it speaks to my >> point. >=20 > I also have trouble understanding it: it sounds as if the sender > is supposed to guess what the AQM is doing; and I don't see why the > sender has enough information to make a good guess. >=20 > It appears to be arguing that this is safe to deploy because CUBIC > has been doing it for years and is widely deployed. The weakness of > that argument is that CUBIC _also_ does things to make sure the > sending rate doesn't grow back as quickly as RENO does. We can't pick > and choose just a few pieces of a congestion control scheme. >=20 >> All I am saying is that perhaps we incentivize ECN deployment by >> making the response softer than the response to loss as a general >> principle. I.e., as you note, a CE is an explicit indication of AQM >> and hence that the link is not completely full and so perhaps we >> don't have to backoff as dramatically. >=20 > We know that's true -- but if that's all we graft on, folks will > claim that ECN gets an unfair share. We also need an argument that > our ECN scheme won't grow sending rate as fast as RENO -- at least > for a little while. >=20 >> If ECN deployment is a chicken and egg problem then perhaps this >> helps us break free from that. (And, in fact, perhaps this provides >> an actual reason to deploy ECN ... >=20 > More deployment is good... >=20 > -- > John Leslie From nobody Tue Jul 14 08:43:20 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D2D1A8886 for ; Mon, 13 Jul 2015 13:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.173 X-Spam-Level: X-Spam-Status: No, score=-0.173 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_RO=1.235, HOST_EQ_RO=0.904, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Lwk3pUQ5mSow for ; Mon, 13 Jul 2015 13:24:15 -0700 (PDT) Received: from vmail.cs.pub.ro (fml.cs.pub.ro [141.85.227.188]) by ietfa.amsl.com (Postfix) with ESMTP id 56BA81A8845 for ; Mon, 13 Jul 2015 13:24:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 83FDF1A600C7; Mon, 13 Jul 2015 23:24:12 +0300 (EEST) X-Virus-Scanned: amavisd-new at cs.pub.ro Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFhtrb824G8N; Mon, 13 Jul 2015 23:24:12 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 5B1391A600D6; Mon, 13 Jul 2015 23:24:12 +0300 (EEST) X-Virus-Scanned: amavisd-new at cs.pub.ro Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mS89NVgMVLh2; Mon, 13 Jul 2015 23:24:12 +0300 (EEST) Received: from [192.168.0.102] (5-12-82-72.residential.rdsnet.ro [5.12.82.72]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id 317161A600C7; Mon, 13 Jul 2015 23:24:12 +0300 (EEST) From: Costin Raiciu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2015 23:24:46 +0300 Message-Id: <721EA345-FB24-45D1-9ADF-D028F216365F@cs.pub.ro> To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: X-Mailman-Approved-At: Tue, 14 Jul 2015 08:43:18 -0700 Subject: [tcpm] TCP sendbuffer advertising X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 20:24:18 -0000 Dear all, We have been working on a simple extension to TCP that encode the amount = of backlogged bytes in each TCP segment. This information can be used by = the network or the receiver for various optimizations. I will be present our work during the TCPM working group in Prague. This = email is a heads-up for those interested in hearing more about the work = before it is presented. We have written a draft on the encoding, but unfortunately we have = missed the Prague cutoff. You can download the draft from my webpage at = http://nets.cs.pub.ro/~costin/files/draft-agache-tcpm-sndbufadv.txt We will submit it properly as soon as the I-D submission tool reopens on = saturday. We also have a workshop paper in HotClout 2015 on the various use-cases = of send buffer advertising, and our prototype implementation, that you = can find at: http://nets.cs.pub.ro/~costin/files/sndbuf.pdf We are looking forward to your comments. Best. Costin ---------------------------------------------- Costin Raiciu Associate Professor Homepage: http://nets.cs.pub.ro/~costin/ CS Department University Politehnica of Bucharest From nobody Tue Jul 14 09:52:11 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA921A8A48 for ; Tue, 14 Jul 2015 09:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 4dStJFtlB0hQ for ; Tue, 14 Jul 2015 09:52:10 -0700 (PDT) Received: from mail-vn0-x22e.google.com (mail-vn0-x22e.google.com [IPv6:2607:f8b0:400c:c0f::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 C54451A8A0F for ; Tue, 14 Jul 2015 09:52:09 -0700 (PDT) Received: by vnbg7 with SMTP id g7so1684283vnb.12 for ; Tue, 14 Jul 2015 09:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PQn0oP7RyP93z/KGuPRNvTpVQNbO305cn/sdnePVkQ8=; b=i0BEbtm8DjpPXLPzOdY2ECzVTiy1gdIaWwjIV8vaWqa4CFI7YfyHTg2UC8W000BmdS ysCFG5hcxXQ46hqdL/mMc5/TWMuDB2qx1eDSemyNjT7QqTvPCJdK1/V/ELek1Gx/LAS6 /N8jLU7qxaoEuNyqqdVw+HwhKIMKG2nCuPBkSkn9ySqC0YcpyxDDcSvL8Nwpid6fTWcV Uy1G9PaSOgU17KdABglzCEUA9rdPDDUllw6QszBh/647VakT09BuahjkE8t4TlW85JAD 1v0goCdo12RypGpdZfRCFTzYvaVLOJrBuuMJMHQ5e9s1/cHS5MReiprPrQ/Jo2nqsU9s W8nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PQn0oP7RyP93z/KGuPRNvTpVQNbO305cn/sdnePVkQ8=; b=C1qBf2KNNgFJF/i06V8t+if7004LF4kIMOI8g+vSBYs/AMI4gNabjkfBWWu5ZCtKHR vJm81s+5SHtryEsCnBdTuLB/kbPsyrr6ECgbDMzwv7xh3eAt3AJ/LCrqhmRAdMBNJAnr D0I8TXd4vZKBZtcIGo1PMApc+GGpdWBcwBo12DVHwHPl+bJdyZjXSCzhQIxm0oKYYcze ieCL5doEucOIgQJ5E+nnQtPEMcUk1LL1xdYH8y3NILpjtbJr+y6RwUxUYARiC0voSHlC FiXp+nfIgDus4fEvF8aTp726bK8CHCbOZaEu2pnPKsazBMCx6/jPAtSzcl6I2OIMn3Wb x/TA== X-Gm-Message-State: ALoCoQlto+u238785Sw5y9IHQ7HKcOGJ75RjQu2naIeHxyMwLBKAPAVJjPXn9a8qJKDWdBQcAG2G X-Received: by 10.52.115.68 with SMTP id jm4mr27684641vdb.21.1436892728997; Tue, 14 Jul 2015 09:52:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.83 with HTTP; Tue, 14 Jul 2015 09:51:29 -0700 (PDT) In-Reply-To: <721EA345-FB24-45D1-9ADF-D028F216365F@cs.pub.ro> References: <721EA345-FB24-45D1-9ADF-D028F216365F@cs.pub.ro> From: Yuchung Cheng Date: Tue, 14 Jul 2015 09:51:29 -0700 Message-ID: To: Costin Raiciu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP sendbuffer advertising X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 16:52:11 -0000 On Mon, Jul 13, 2015 at 1:24 PM, Costin Raiciu wrote: > > Dear all, > > We have been working on a simple extension to TCP that encode the amount of backlogged bytes in each TCP segment. This information can be used by the network or the receiver for various optimizations. > > I will be present our work during the TCPM working group in Prague. This email is a heads-up for those interested in hearing more about the work before it is presented. > > We have written a draft on the encoding, but unfortunately we have missed the Prague cutoff. You can download the draft from my webpage at http://nets.cs.pub.ro/~costin/files/draft-agache-tcpm-sndbufadv.txt > We will submit it properly as soon as the I-D submission tool reopens on saturday. > > We also have a workshop paper in HotClout 2015 on the various use-cases of send buffer advertising, and our prototype implementation, that you can find at: http://nets.cs.pub.ro/~costin/files/sndbuf.pdf > > We are looking forward to your comments. Some quick thoughts: 1) what happens when the backlog / sendbuf > 65536B? 2) announcing the backlog may help larger incast when the response > cwnd (i.e., taking multiple round trips to deliver). but many incast patterns I know of fit entirely in the first cwnd. For example 1000 senders write 2 packets each to a single receiver. ECN/dctcp has the same limitation on such type of incast. 3) some application prefer late-binding and delays writing data into the socket with features like TCP_NOTSENT_LOWAT (https://lwn.net/Articles/560082/). Thus the sendbuf remains low while app backlog may be very large. The react function that uses the sendbuf info should not assume sendbuf == app backlog. 4) for HTTP/2 often the conversation is bi-directional: the server may be responding to a HTTP/2 request while actively acking other new client requests. The receiver window of the packets will alternate between sendbuf or receiver window. hence the sendbuf info may be missing intermittently. but I think this is an interesting feature worth exploring! > > Best. > Costin > ---------------------------------------------- > Costin Raiciu > Associate Professor > Homepage: http://nets.cs.pub.ro/~costin/ > CS Department > University Politehnica of Bucharest > > > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jul 14 10:22:30 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE8B1ACE0E for ; Tue, 14 Jul 2015 10:22:29 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 8nSb1HmexEkh for ; Tue, 14 Jul 2015 10:22:23 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C5A1ACEAB for ; Tue, 14 Jul 2015 10:22:03 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id t6EHLxuC003429; Tue, 14 Jul 2015 10:21:59 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1B1691C49CE0; Tue, 14 Jul 2015 13:21:59 -0400 (EDT) To: John Leslie From: Mark Allman In-Reply-To: <20150713223637.GA54621@verdi> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Money X-URL-0: http://www.icir.org/mallman-files/Document89688.jpg X-URL-1: http://www.icir.org/mallman-files/Document57557.doc X-URL-2: http://www.icir.org/mallman-files/Document87938.docx X-URL-3: http://www.icir.org/mallman-files/Document11204.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 14 Jul 2015 13:21:59 -0400 Message-ID: <24907.1436894519@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 17:22:29 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > Indeed: we can only know "some sort of AQM". But IMHO, we can say > that ECN-CE _should_ indicate an AQM as opposed to tail-drop. Also > IMHO, we should say somewhere that ECN-CE _should_not_ be used > when the buffer is essentially full. Well, I agree with the sentiment, but you'd have to come up with some better guidelines than that. I am reminded of the old gentle version of RED that AQM-ed all the way until it couldn't anymore and had to tail drop because there was no queue space. So, when should that stop marking and start dropping? > > All I am saying is that perhaps we incentivize ECN deployment by > > making the response softer than the response to loss as a > > general principle. I.e., as you note, a CE is an explicit > > indication of AQM and hence that the link is not completely full > > and so perhaps we don't have to backoff as dramatically. >=20 > We know that's true -- but if that's all we graft on, folks will > claim that ECN gets an unfair share. So what? Two things ... - As I framed it I was talking about a *bit* less multiplicative decrease. E.g., cwnd *=3D 0.55 instead of cwnd *=3D 0.50 for a mark vs. a loss. That was a complete WAG. But, something like that provides some incentive without going massively overboard, if you ask me. - And, so what if it gets an "unfair share". We have to show some judgment for sure, but if we keep doing what we're doing just because old crap exists then we can never make any progress. SACK allows a TCP to recover from multiple losses more rapidly and without the RTO (in many case) and hence gets an "unfair share" compared with non-SACK TCP. That doesn't mean we decided that SACK was somehow not worthwhile. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlWlRTQACgkQWyrrWs4yIs71KgCbBkaVovHQforQH+V+ozivdBCG 6mcAn1Y0L/AHlp1KObvLGvvtiqsu0CbI =32yT -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Tue Jul 14 10:31:02 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95C71ACEC4 for ; Tue, 14 Jul 2015 10:31:00 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 01gYyy3Mdn_4 for ; Tue, 14 Jul 2015 10:31:00 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4261A8A6B for ; Tue, 14 Jul 2015 10:30:59 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id t6EHUu0o005159; Tue, 14 Jul 2015 10:30:57 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B64C71C4A339; Tue, 14 Jul 2015 13:30:56 -0400 (EDT) To: Michael Welzl From: Mark Allman In-Reply-To: <2B50F773-874C-43BA-9275-4323EFABC3EA@ifi.uio.no> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Money X-URL-0: http://www.icir.org/mallman-files/Document4830.pdf X-URL-1: http://www.icir.org/mallman-files/Document91132.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 14 Jul 2015 13:30:56 -0400 Message-ID: <26672.1436895056@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 17:31:01 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > our > intention was simply to start minimal and gradually add > information that people request.=20 That's annoying. Why don't you take a stab at answering some of the obvious questions someone reading that would have? > Look at it as a parameter change. RFC 6928 changes IW from 3 to 10 > (for 1500-byte packets), we suggest to change the backoff factor > from 0.5 to 0.8 for the ECN response. In broad terms I think I agree. That is, leveraging the additional fact that a congested queue is not full seems useful to me. A parameter change that is (a) a big change from the standard parameter and (b) is based on simulations of two AQM variants seems like it might be a bit much. I.e., sure the queue isn't full and dropping packets, but it is congested. But, I do like the general idea.=20 allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlWlR1AACgkQWyrrWs4yIs7LUACfYGttjm7SdmQi+Jd8ZY2hJTYF kYcAn2LhE6d0b86frCXFBkgtGd/S1q+m =S7w/ -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Tue Jul 14 11:34:07 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB3A1B29FA for ; Tue, 14 Jul 2015 11:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5kqA0ns7WfUg for ; Tue, 14 Jul 2015 11:33:54 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 DB0561B2A09 for ; Tue, 14 Jul 2015 11:33:44 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZF51R-0002j8-8Z; Tue, 14 Jul 2015 20:33:41 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZF51Q-0006jW-QH; Tue, 14 Jul 2015 20:33:41 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <26672.1436895056@lawyers.icir.org> Date: Tue, 14 Jul 2015 20:33:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <26672.1436895056@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 8 sum msgs/h 2 total rcpts 30957 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 678F72354465D0A1849524391E8BD7C9F8155A65 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1292 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:34:02 -0000 > On 14. jul. 2015, at 19.30, Mark Allman wrote: >=20 >=20 >> our >> intention was simply to start minimal and gradually add >> information that people request.=20 >=20 > That's annoying. Why don't you take a stab at answering some of the > obvious questions someone reading that would have? Much is in the technical report, which we intended to make available at = the same time. There was a 1 week delay which we're sorry about - it was = a holidays / draft deadline situation. Yes the tech.rep. is a long = document but I believe it's well organized and clearly written, so I = guess it won't take you long to find your answers there. I just thought = starting this way is more efficient. I may be wrong, now you tell us = it's annoying - well ok, I'll take that as a vote to include more next = time. >> Look at it as a parameter change. RFC 6928 changes IW from 3 to 10 >> (for 1500-byte packets), we suggest to change the backoff factor >> from 0.5 to 0.8 for the ECN response. >=20 > In broad terms I think I agree. That is, leveraging the additional > fact that a congested queue is not full seems useful to me. A > parameter change that is (a) a big change from the standard > parameter and (b) is based on simulations of two AQM variants seems > like it might be a bit much. I.e., sure the queue isn't full and > dropping packets, but it is congested. But, I do like the general > idea.=20 About (a): okay, I offer 0.75. About (b): many real life tests, not just simulations. Only two AQM = variants, yes. Cheers, Michael From nobody Tue Jul 14 11:39:21 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBCB1B2A39 for ; Tue, 14 Jul 2015 11:39:20 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wg4zoD1A7zNN for ; Tue, 14 Jul 2015 11:39:19 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7869B1B2A2C for ; Tue, 14 Jul 2015 11:39:19 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id t6EIdAt4019523; Tue, 14 Jul 2015 11:39:10 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2EE381C4B72F; Tue, 14 Jul 2015 14:39:10 -0400 (EDT) To: Michael Welzl From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Money X-URL-0: http://www.icir.org/mallman-files/Document8893.html X-URL-1: http://www.icir.org/mallman-files/Document94240.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 14 Jul 2015 14:39:10 -0400 Message-ID: <38330.1436899150@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:39:20 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > > A parameter change that is (a) a big change from the standard > > parameter and (b) is based on simulations of two AQM variants > > seems like it might be a bit much. I.e., sure the queue isn't > > full and dropping packets, but it is congested. But, I do like > > the general idea. >=20 > About (a): okay, I offer 0.75. I will have to better understand the tests. That seems like a significant change to me. > About (b): many real life tests, not just simulations. Only two > AQM variants, yes.=20 Apologies. I only skimmed very quickly. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlWlV00ACgkQWyrrWs4yIs7UmwCeIKxfoQBwBxaxb8YHlSGt4eo/ LkMAnAnJio/si/aGHbyfkW0+CLed09/T =umqk -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Tue Jul 14 11:52:13 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395B41B2A2A for ; Tue, 14 Jul 2015 11:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 iUf1XodK7KcT for ; Tue, 14 Jul 2015 11:52:10 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 E95A81ACEE1 for ; Tue, 14 Jul 2015 11:52:09 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZF5JI-0003RN-Is; Tue, 14 Jul 2015 20:52:08 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1ZF5JI-0003EQ-2K; Tue, 14 Jul 2015 20:52:08 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <38330.1436899150@lawyers.icir.org> Date: Tue, 14 Jul 2015 20:52:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38330.1436899150@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 3 sum rcpts/h 13 sum msgs/h 4 total rcpts 30962 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AB56414926FB4E81EBE4AC3BC8633195E6257915 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1294 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:52:11 -0000 > On 14. jul. 2015, at 20.39, Mark Allman wrote: >=20 >=20 >>> A parameter change that is (a) a big change from the standard >>> parameter and (b) is based on simulations of two AQM variants >>> seems like it might be a bit much. I.e., sure the queue isn't >>> full and dropping packets, but it is congested. But, I do like >>> the general idea. >>=20 >> About (a): okay, I offer 0.75. >=20 > I will have to better understand the tests. That seems like a > significant change to me. Okay - but - while we haven't used CUBIC as an argument before, I feel = like doing it now: the Internet has survived CUBIC, which - in response = to loss, i.e. in response to potentially much larger queues - first used = 0.8, then 0.7 ( I'd be quite curious about why that downward change was = made, but found nothing ). 0.75 or 0.8 seemed to be pretty good values in our tests and using this = in response to ECN is much less drastic than CUBIC's general behavior as = it's only going to kick in when you get an ECN signal and then standard = TCP doesn't increase as fast as CUBIC does, too. Cheers, Michael From nobody Tue Jul 14 13:45:35 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5029D1A88A1 for ; Tue, 14 Jul 2015 13:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 t_s-ya4i1ClV for ; Tue, 14 Jul 2015 13:45:33 -0700 (PDT) Received: from mail-vn0-x233.google.com (mail-vn0-x233.google.com [IPv6:2607:f8b0:400c:c0f::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 24E511A889D for ; Tue, 14 Jul 2015 13:45:33 -0700 (PDT) Received: by vnbf7 with SMTP id f7so2381901vnb.0 for ; Tue, 14 Jul 2015 13:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Vn+vD0zx5bDobTiL1S1u0/p8QJPoSCG8tWK1AlFxCM4=; b=cQmUEuCi0zT3AC7vtJ0LRFCiPISzm8rk+r2/vlB5Hfna8TlmAmAU06jw6YiJr/Z127 7lTznvQ8ZNiptTZN26bwfIOEgaSj6lqBLQN9nwFH4hoxiEh+qZ0UZ7z81XGIU6PBeIw8 d73b6GTZvSkaLx0C5czEDJgy7v7zm7U/7L1ejceptQJNpMETUaZhfRA07oxfekcyvBF2 GsfPNzIPHMMdsvWIGKmf0rPp5Lmk+3N5Uygk1QIbIrASQCN9WjAeRHW1LTgjIGsDN4gK /7xFStDLDTVg9PxHNOBAvUl/pf/aS25aKW1v49yq1LqoSzebVXXK6gqe5Bbbs/RjoUxO dGmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Vn+vD0zx5bDobTiL1S1u0/p8QJPoSCG8tWK1AlFxCM4=; b=a92kTWJBPAUetI+yDRnvRvbZC56LmxZ6WYXVU8lAEEHtEfJjXDe7DxrTVKAE9tye3D aiN5a9Oba7hkZv5wSkPAsgtHC4Wylk7lBWOfhK0BlUJaUelQ0tYLEIg7T/XsU689/6/l wp49ALNjyTNGLwOQR1NlIaXAJLj9MkSBzZ6pz6TMraRIglllcUc9ni2vYhauabfAsm1v zcyOYKaSVFPG7KhbKZAAl9/g81OPpnjGhzlHSQrJdpXPvN+eVp01M3dSYhqreRqTxZdE F+OcaXI470qqMsAigz0uwFt7v9AlCaYhQW/v1dsc00w8dTt5UB/QLMYYw+tEcUQbwjv9 EecQ== X-Gm-Message-State: ALoCoQn35TtCVvZBTepDCw1AZN5aXHYlCwA0zxQmzxs4ukK5oUEhiK1jOouA0pJeQH1ZfANQMRCe X-Received: by 10.52.13.198 with SMTP id j6mr576747vdc.94.1436906732281; Tue, 14 Jul 2015 13:45:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.83 with HTTP; Tue, 14 Jul 2015 13:44:52 -0700 (PDT) In-Reply-To: References: <38330.1436899150@lawyers.icir.org> From: Yuchung Cheng Date: Tue, 14 Jul 2015 13:44:52 -0700 Message-ID: To: Michael Welzl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org Extensions" , "mallman@icir.org" Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 20:45:34 -0000 On Tue, Jul 14, 2015 at 11:52 AM, Michael Welzl wrote: > >> On 14. jul. 2015, at 20.39, Mark Allman wrote: >> >> >>>> A parameter change that is (a) a big change from the standard >>>> parameter and (b) is based on simulations of two AQM variants >>>> seems like it might be a bit much. I.e., sure the queue isn't >>>> full and dropping packets, but it is congested. But, I do like >>>> the general idea. >>> >>> About (a): okay, I offer 0.75. >> >> I will have to better understand the tests. That seems like a >> significant change to me. > > Okay - but - while we haven't used CUBIC as an argument before, I feel li= ke doing it now: the Internet has survived CUBIC, which - in response to l= oss, i.e. in response to potentially much larger queues - first used 0.8, t= hen 0.7 ( I'd be quite curious about why that downward change was made, but= found nothing ). This email conversation may help. On Wed, Sep 5, 2012 at 3:29 PM, Sangtae Ha wrote: > Hi Yuchung, > > We used the beta parameter of BIC (0.8) for CUBIC until that time. But we > decided to give more room for other flows to ramp up for better convergen= ce. > We also removed the window increase limit of smax to probe an available > bandwidth rather aggressively when there is no known capacity > (last_max_cwnd) of the link. > The following summary may be useful. > > BIC: beta (0.8) and the window increase is limited to smax (which is an > issue when the smax is relatively small compared to the BDP of a path) > CUBIC: beta (0.7) and the window increase is governed by the cubic functi= on > itself. > > Let me know if you have any more questions. > > Have a good day! > > Best Regards, > Sangtae > > > On Wed, Sep 5, 2012 at 5:27 PM, Yuchung Cheng wrote: >> >> Hi Santae, >> >> I noticed the beta of cubic is changed from 0.8 (as in the paper) to >> 0.7 in this commit. From nobody Wed Jul 15 00:04:45 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3070E1A8773 for ; Wed, 15 Jul 2015 00:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0Rlpnx1Ujyff for ; Wed, 15 Jul 2015 00:04:42 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 558511A8760 for ; Wed, 15 Jul 2015 00:04:41 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 2864529654364; Wed, 15 Jul 2015 07:04:38 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6F74TER008453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Jul 2015 09:04:39 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 15 Jul 2015 09:04:27 +0200 From: "Scharf, Michael (Michael)" To: "draft-ietf-tcpm-cubic@tools.ietf.org" Thread-Topic: CUBIC backoff Thread-Index: AQHQvsx81vpgV5xk6EWsEbS0D4Z0qg== Date: Wed, 15 Jul 2015 07:04:26 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4842651F@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <38330.1436899150@lawyers.icir.org> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: [tcpm] CUBIC backoff X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 07:04:44 -0000 I really think Yuchungs's explanation below should be considered in draft-i= etf-tcpm-cubic... Thanks Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng > Sent: Tuesday, July 14, 2015 10:45 PM > To: Michael Welzl > Cc: tcpm@ietf.org Extensions; mallman@icir.org > Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft- > khademi-alternativebackoff-ecn) >=20 > On Tue, Jul 14, 2015 at 11:52 AM, Michael Welzl > wrote: > > > >> On 14. jul. 2015, at 20.39, Mark Allman wrote: > >> > >> > >>>> A parameter change that is (a) a big change from the standard > >>>> parameter and (b) is based on simulations of two AQM variants > >>>> seems like it might be a bit much. I.e., sure the queue isn't > >>>> full and dropping packets, but it is congested. But, I do like > >>>> the general idea. > >>> > >>> About (a): okay, I offer 0.75. > >> > >> I will have to better understand the tests. That seems like a > >> significant change to me. > > > > Okay - but - while we haven't used CUBIC as an argument before, I > feel like doing it now: the Internet has survived CUBIC, which - in > response to loss, i.e. in response to potentially much larger queues - > first used 0.8, then 0.7 ( I'd be quite curious about why that downward > change was made, but found nothing ). >=20 > This email conversation may help. >=20 > On Wed, Sep 5, 2012 at 3:29 PM, Sangtae Ha > wrote: > > Hi Yuchung, > > > > We used the beta parameter of BIC (0.8) for CUBIC until that time. > But we > > decided to give more room for other flows to ramp up for better > convergence. > > We also removed the window increase limit of smax to probe an > available > > bandwidth rather aggressively when there is no known capacity > > (last_max_cwnd) of the link. > > The following summary may be useful. > > > > BIC: beta (0.8) and the window increase is limited to smax (which is > an > > issue when the smax is relatively small compared to the BDP of a > path) > > CUBIC: beta (0.7) and the window increase is governed by the cubic > function > > itself. > > > > Let me know if you have any more questions. > > > > Have a good day! > > > > Best Regards, > > Sangtae > > > > > > On Wed, Sep 5, 2012 at 5:27 PM, Yuchung Cheng > wrote: > >> > >> Hi Santae, > >> > >> I noticed the beta of cubic is changed from 0.8 (as in the paper) to > >> 0.7 in this commit. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 15 00:38:37 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3104E1A8840 for ; Wed, 15 Jul 2015 00:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ExRdmsOJehVB for ; Wed, 15 Jul 2015 00:38:33 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 960531A883D for ; Wed, 15 Jul 2015 00:38:32 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZFHGt-0001wf-Jk; Wed, 15 Jul 2015 09:38:27 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZFHGt-0002Ux-2B; Wed, 15 Jul 2015 09:38:27 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <655C07320163294895BBADA28372AF5D4842651F@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Wed, 15 Jul 2015 09:38:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65E86DC7-7FFA-4A32-B2FE-F87712E3EA1B@ifi.uio.no> References: <38330.1436899150@lawyers.icir.org> <655C07320163294895BBADA28372AF5D4842651F@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 30973 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7FAEAFCE6E4BB57EB903AA283AB94480D576EAE0 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 7408 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tcpm@ietf.org Extensions" , "draft-ietf-tcpm-cubic@tools.ietf.org" Subject: Re: [tcpm] CUBIC backoff X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 07:38:36 -0000 +1 ! this is great information from Yuchung, thanks! > On 15 Jul 2015, at 09:04, Scharf, Michael (Michael) = wrote: >=20 > I really think Yuchungs's explanation below should be considered in = draft-ietf-tcpm-cubic... >=20 > Thanks >=20 > Michael >=20 >=20 >=20 >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng >> Sent: Tuesday, July 14, 2015 10:45 PM >> To: Michael Welzl >> Cc: tcpm@ietf.org Extensions; mallman@icir.org >> Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN = (draft- >> khademi-alternativebackoff-ecn) >>=20 >> On Tue, Jul 14, 2015 at 11:52 AM, Michael Welzl >> wrote: >>>=20 >>>> On 14. jul. 2015, at 20.39, Mark Allman wrote: >>>>=20 >>>>=20 >>>>>> A parameter change that is (a) a big change from the standard >>>>>> parameter and (b) is based on simulations of two AQM variants >>>>>> seems like it might be a bit much. I.e., sure the queue isn't >>>>>> full and dropping packets, but it is congested. But, I do like >>>>>> the general idea. >>>>>=20 >>>>> About (a): okay, I offer 0.75. >>>>=20 >>>> I will have to better understand the tests. That seems like a >>>> significant change to me. >>>=20 >>> Okay - but - while we haven't used CUBIC as an argument before, I >> feel like doing it now: the Internet has survived CUBIC, which - in >> response to loss, i.e. in response to potentially much larger queues = - >> first used 0.8, then 0.7 ( I'd be quite curious about why that = downward >> change was made, but found nothing ). >>=20 >> This email conversation may help. >>=20 >> On Wed, Sep 5, 2012 at 3:29 PM, Sangtae Ha >> wrote: >>> Hi Yuchung, >>>=20 >>> We used the beta parameter of BIC (0.8) for CUBIC until that time. >> But we >>> decided to give more room for other flows to ramp up for better >> convergence. >>> We also removed the window increase limit of smax to probe an >> available >>> bandwidth rather aggressively when there is no known capacity >>> (last_max_cwnd) of the link. >>> The following summary may be useful. >>>=20 >>> BIC: beta (0.8) and the window increase is limited to smax (which is >> an >>> issue when the smax is relatively small compared to the BDP of a >> path) >>> CUBIC: beta (0.7) and the window increase is governed by the cubic >> function >>> itself. >>>=20 >>> Let me know if you have any more questions. >>>=20 >>> Have a good day! >>>=20 >>> Best Regards, >>> Sangtae >>>=20 >>>=20 >>> On Wed, Sep 5, 2012 at 5:27 PM, Yuchung Cheng >> wrote: >>>>=20 >>>> Hi Santae, >>>>=20 >>>> I noticed the beta of cubic is changed from 0.8 (as in the paper) = to >>>> 0.7 in this commit. >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 15 09:40:20 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1B51A1B76 for ; Wed, 15 Jul 2015 09:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 YjDIMqBwiStg for ; Wed, 15 Jul 2015 09:40:16 -0700 (PDT) Received: from mail-vn0-x22b.google.com (mail-vn0-x22b.google.com [IPv6:2607:f8b0:400c:c0f::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 5D6A21A1B72 for ; Wed, 15 Jul 2015 09:40:16 -0700 (PDT) Received: by vnbg129 with SMTP id g129so5153757vnb.11 for ; Wed, 15 Jul 2015 09:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=LnylcUDNrWt09E0Kyaw+etjyxSXD6Zf0h1e1qYDH0aU=; b=Xyr83n7Riwgwo/+DooLSlzPnLrtzM7BWLs+t8Datl/U67I4ly3Lpk75jvIdLnf5mQY QM3pV5Cm5Tbqdtziqlk41J7o/CqahvX+D5ggr9KvLd+oIjLXO+M127c124V/z1flLT5H 9WghO1+Ud3pz/VrVuB8ThKMK1ERt23DjImiL4YprhhNb6Dn7RMyJ2Fw+zxxz4KKtzrcj npONv17pGd8yy3AjnhzrxGSM9eItjfccbgbtgiDPY3E3gPl3VxfCncyaLluWyrBg5zBb CzLsNl7tlNV3TfDj1QE3Ow11jh75FIYFkDWEe9tLB6yo9kadAkpTuXk2NTUR/eoJR8Ek M6Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=LnylcUDNrWt09E0Kyaw+etjyxSXD6Zf0h1e1qYDH0aU=; b=TcV7Kl2qDT5+hmc/ey5AO0mXtNBwU+ssULHBWMRqRVR3Dc3eBYkRIytfCChtuXLO+f C+7Ux0oEHBWMoBFKBXY4Oc2ZoVW9DCkincf9x3zPTumwgWANLzpFmE5fO1XAh2XDueTV 1Zl76OCeOv6LwVQsUJ9UNKXA5TVWxUB7bknLoBhvqdztVE8nEGFg0y0ir2x//WbFKvi3 D4M/AAL2B7yubiRBR7EvOsdWmqD3opyC/qc/qJtXxFETuit48W8ImRaq14XysT7MG7W5 8FeRJCFOSDmEDsrDCIuYghNnKbs2DDNnvm/YNIosyyzYa9TGUa4TP+ss+gwlKjLYAfaX 8Neg== X-Gm-Message-State: ALoCoQmYozSMDFSe/lUwXXzMZSgl6hOreJSPVwDM55zm8j8VYmaWoxKSZufegHZCaQ8ckjZeyzr4 X-Received: by 10.52.13.198 with SMTP id j6mr5277644vdc.94.1436978415488; Wed, 15 Jul 2015 09:40:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.83 with HTTP; Wed, 15 Jul 2015 09:39:36 -0700 (PDT) In-Reply-To: <559C4995.1090303@hawari.fr> References: <20150703073347.7027.37216.idtracker@ietfa.amsl.com> <559C4995.1090303@hawari.fr> From: Yuchung Cheng Date: Wed, 15 Jul 2015 09:39:36 -0700 Message-ID: To: Mohammed HAWARI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org Extensions" , Mark Townsley Subject: Re: [tcpm] Fwd: New Version Notification for draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 16:40:18 -0000 On Tue, Jul 7, 2015 at 2:50 PM, Mohammed HAWARI wrote: > > > Le 07/07/2015 02:20, Yuchung Cheng a =C3=A9crit : > Hi, >> On Fri, Jul 3, 2015 at 1:58 AM, Mohammed HAWARI wro= te: >>> Dear all, >>> >>> I am currently a master's student at Ecole Polytechnique, France and an= d an >>> intern at Cisco. As part of my research internship, I have written an >>> Internet Draft that specifies an extension to TCP Fast Open. It enables= a >>> TCP Fast Open Cookie to be used for a whole IPv6 prefix instead of a si= ngle >>> address. >>> >>> Your comments on this draft are very welcome :) I will be at IETF 93 fo= r >>> further discussion too. >> Was the motivation to reduce cookie storage for v6 clients? >> getting the cookie is a one-time operation. it's not clear to me this >> worth another TCP option. > Well, it is partly a problem of storage (potentially 2^prefix_length > cookies stored by the client) but not only. For example if a server has > a /64 from which each of the addresses represents a chunk of data (or > any other applicative concept), these addresses might be accessed very > sparsely. It is even possible that one address of that /64 would never > be accessed twice by the client. You will do this one-time operation > very often and will gain no benefit from using TFO. >> I don't understand the second motivation... >> " Another application of this extension appears in the context of a >> DNS-load-balanced cluster of servers. In this case, one server of >> the cluster will provide the client with a TFO cookie which is valid >> for the whole cluster, thus reducing the number of three way >> handshakes. >> " >> >> If only some special application needs this, why not just >> change the server to generate cookies base on v6-addr/64 (on its own ris= k)? > This cluster of servers could be a cluster of web servers and I might be > wrong, but web traffic is still a source of highly transactional > traffic. This is not really a special application. > If I understand it well,the solution you describe forces the application > (client-side and server-side) to be aware of the prefix-length for which > a cookie is valid. This might not be possible and is definitely not > flexible (/64 sounds quite arbitrary). The cookie is opaque to the client so the client does not need to change. I am saying if the intent is to treat v6/64 as a host, just have the server use the prefix to generate the cookie. that's a 2-liner change on the server side. syn option space is very tight so it's not worth another option for small things like this. >>> Best Regards, >>> >>> Mohammed Hawari >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: 2015-07-03 9:33 GMT+02:00 >>> Subject: New Version Notification for >>> draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt >>> To: Mohammed HAWARI >>> >>> >>> >>> A new version of I-D, draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt >>> has been successfully submitted by Mohammed HAWARI and posted to the >>> IETF repository. >>> >>> Name: draft-hawari-tcpm-tfo-ipv6-prefixes >>> Revision: 00 >>> Title: TCP Fast Open Cookie for IPv6 prefixes >>> Document date: 2015-07-03 >>> Group: Individual Submission >>> Pages: 5 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-hawari-tcpm-tfo-ipv6-prefixe= s-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-hawari-tcpm-tfo-ipv6-prefixes/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-hawari-tcpm-tfo-ipv6-prefixes-00 >>> >>> >>> Abstract: >>> In order to support applications that require a large number of >>> addresses or address space, a host may be assigned an aggregate IPv6 >>> prefix rather than one or more discrete IPv6 addresses. This >>> document briefly describes cases where this may occur, and specifies >>> an extension to TCP Fast Open [RFC7413] to allow a client to use a >>> single TCP Fast Open cookie for an IPv6 prefix. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Jul 15 12:21:58 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071EA1B34A4 for ; Wed, 15 Jul 2015 12:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.823 X-Spam-Level: X-Spam-Status: No, score=0.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_FUCK2=3.434, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 dQb44gsG42iy for ; Wed, 15 Jul 2015 12:21:55 -0700 (PDT) Received: from mta-us-west-01.viasat.com (mta-us-west-01.viasat.com [8.37.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCB81B349F for ; Wed, 15 Jul 2015 12:21:55 -0700 (PDT) Received: from pps.filterd (VCASPAM01.hq.corp.viasat.com [127.0.0.1]) by VCASPAM01.hq.corp.viasat.com (8.14.5/8.14.5) with SMTP id t6FJLact001066; Wed, 15 Jul 2015 19:21:53 GMT From: "Agarwal, Anil" To: Michael Welzl , Naeem Khademi , "mallman@icir.org" Thread-Topic: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) Thread-Index: AQHQvmRfAV9Fl3EhLkO1LsYJjmCaXp3btCmAgAExpzA= Date: Wed, 15 Jul 2015 19:21:51 +0000 Message-ID: <7A2801D5E40DD64A85E38DF22117852C70ADBEF1@wdc1exchmbxp05.hq.corp.viasat.com> References: <38330.1436899150@lawyers.icir.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-15_07:2015-07-15,2015-07-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507150262 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 19:21:57 -0000 Michael, Naeem, 1. Would be useful if the draft rfc could describe the interaction between = the alternative and the "standard" backoff schemes for new-RENO. What are the fairness properties, when connections of each type are pre= sent in the network? How long does it take for cwnd to reach its steady-state value for conn= ections starting at different times? - For mixed connections with standard and alternative backoff factor= s. - As well as for connections that use the alternative backoff factor= only. - For different RTT values. 2. Would be useful if the simulations were complemented with some analysis,= =20 showing properties of the new backoff factor. 3. How does the suggested backoff factor of 0.8 affect queue size and delay= s for connections in slow start? Let's take a simple example - Assume a single TCP connection and a link with bandwidth-delay product = =3D W bytes. The connection will begin in slow-start and double its cwnd every RTT. Let's assume that the AQM marks a packet with ECN soon after cwnd reach= es W. The ECN-echo is received by the sender one RTT later. At that time cwnd =3D 2W. Using the cwnd reduction factor of 0.8, cwnd will be reduced to 1.6W. This is still too high. So, one RTT later, it will be further reduced t= o 1.28W. This is still too high. So, one RTT later, it will be further reduced t= o 1.024W. This is still too high. So, one RTT later, it will be further reduced t= o 0.82W. Hence, for 4 RTTs, cwnd is above W, causing substantial queue build-up = at the bottleneck. ECN will probably be received for a few more RTT because of the queue b= uild-up; alternatively, tail-drop might kick in. Part of the problem, I think, is a weakness in the TCP cwnd reduction alg= orithm - it reduces the current cwnd by a constant factor (cwnd =3D cwnd * f) on congestion detection; id= eally, it should reduce cwnd to its value **one RTT earlier** multiplied by the constant factor. What this implies is that during slow-start cwnd should get reduced as cw= nd =3D cwnd * 0.5 * f. During congestion avoidance, cwnd should get reduced as cwnd =3D (cwnd - = MSS) * f, which is close to cwnd * f anyways. (We have been using this scheme within our geo-satellite network segment = with TCP-PEPs for a long time to good effect. We have also been using f =3D 0.67 with = ECN). If it makes sense, we could suggest this in the rfc as well, perhaps afte= r you evaluate it in your testbeds. Regards, Anil -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Michael Welzl Sent: Tuesday, July 14, 2015 2:52 PM To: mallman@icir.org Cc: tcpm@ietf.org Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khad= emi-alternativebackoff-ecn) > On 14. jul. 2015, at 20.39, Mark Allman wrote: >=20 >=20 >>> A parameter change that is (a) a big change from the standard=20 >>> parameter and (b) is based on simulations of two AQM variants seems=20 >>> like it might be a bit much. I.e., sure the queue isn't full and=20 >>> dropping packets, but it is congested. But, I do like the general=20 >>> idea. >>=20 >> About (a): okay, I offer 0.75. >=20 > I will have to better understand the tests. That seems like a=20 > significant change to me. Okay - but - while we haven't used CUBIC as an argument before, I feel like= doing it now: the Internet has survived CUBIC, which - in response to los= s, i.e. in response to potentially much larger queues - first used 0.8, the= n 0.7 ( I'd be quite curious about why that downward change was made, but f= ound nothing ). 0.75 or 0.8 seemed to be pretty good values in our tests and using this in = response to ECN is much less drastic than CUBIC's general behavior as it's = only going to kick in when you get an ECN signal and then standard TCP does= n't increase as fast as CUBIC does, too. Cheers, Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tcpm&d=3DAwICAg&c=3Djcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r= =3DFyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=3DqyGZB6w2Tt1WdYgoDX6uzUCs= fiqK0vBlqF_CyzdrDZ0&s=3DC4SVZsO-w0cXlOOpKnu-8b3Ma3adPsHHQY_xRtg9urI&e=3D=20 From nobody Wed Jul 15 15:20:59 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9499A1B3517 for ; Wed, 15 Jul 2015 15:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 kKQUHzVremL8 for ; Wed, 15 Jul 2015 15:20:55 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 679631B351E for ; Wed, 15 Jul 2015 15:20:55 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZFV2o-0005zi-K8; Thu, 16 Jul 2015 00:20:50 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZFV2n-00010o-U2; Thu, 16 Jul 2015 00:20:50 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <7A2801D5E40DD64A85E38DF22117852C70ADBEF1@wdc1exchmbxp05.hq.corp.viasat.com> Date: Thu, 16 Jul 2015 00:20:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C832B4A-5C1D-4617-9D17-C853D324A968@ifi.uio.no> References: <38330.1436899150@lawyers.icir.org> <7A2801D5E40DD64A85E38DF22117852C70ADBEF1@wdc1exchmbxp05.hq.corp.viasat.com> To: "Agarwal, Anil" X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 7 sum msgs/h 1 total rcpts 31010 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FCEB8122AA0420966140558C1BE1408D62167AD9 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1299 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 22:20:58 -0000 Hi Anil, Thanks for your interest! You'll find that the technical report at = http://caia.swin.edu.au/reports/150710A/CAIA-TR-150710A.pdf answers most of your questions. More below: > On 15. jul. 2015, at 21.21, Agarwal, Anil = wrote: >=20 > Michael, Naeem, >=20 > 1. Would be useful if the draft rfc could describe the interaction = between the alternative and > the "standard" backoff schemes for new-RENO. > What are the fairness properties, when connections of each type are = present in the network? Page 9, Figures 14/15. Real life tests. Short answer: ratio of roughly = 2:1, no starvation. > How long does it take for cwnd to reach its steady-state value for = connections starting at different times? > - For mixed connections with standard and alternative backoff = factors. We did not evaluate this because the convergence with similar backoff = factors was not significantly and consistently harmed by increasing the = backoff factor. > - As well as for connections that use the alternative backoff = factor only. Pages 8/9, figures 12/13, real life tests. > - For different RTT values. We did not document this in the paper because convergence is already = hard to understand with similar RTT values, and changing beta did = neither consistently improve nor worsen the situation. Some point tests = showed that convergence of TCP with backoff factor 0.5 does by itself = not show a clear trend as a result of the RTT ratio, and the same is = true for a different beta factor. In other words, we're sometimes better = and sometimes worse than 0.5, which by itself is sometimes better and = sometimes worse, depending on RTT ratios. > 2. Would be useful if the simulations were complemented with some = analysis,=20 > showing properties of the new backoff factor. A rather simple model is presented on page 3. Equation 6 gives you the = long-term average throughput in congestion avoidance as a function of a = DropTail queue's buffer size (or marking ratio of at least CoDel, as = Fig. 4 on the next page shows (simulations here) ), the capacity, the = BDP and the backoff factor. Figure 2 gives a simple overview of the = buffer size / backoff factor / throughput relationship. > 3. How does the suggested backoff factor of 0.8 affect queue size and = delays for connections in slow start? > Let's take a simple example - > Assume a single TCP connection and a link with bandwidth-delay = product =3D W bytes. > The connection will begin in slow-start and double its cwnd every = RTT. > Let's assume that the AQM marks a packet with ECN soon after cwnd = reaches W. > The ECN-echo is received by the sender one RTT later. > At that time cwnd =3D 2W. > Using the cwnd reduction factor of 0.8, cwnd will be reduced to = 1.6W. > This is still too high. So, one RTT later, it will be further = reduced to 1.28W. > This is still too high. So, one RTT later, it will be further = reduced to 1.024W. > This is still too high. So, one RTT later, it will be further = reduced to 0.82W. > Hence, for 4 RTTs, cwnd is above W, causing substantial queue = build-up at the bottleneck. > ECN will probably be received for a few more RTT because of the = queue build-up; alternatively, tail-drop > might kick in. This is illustrated by Fig. 6 on page 6 and explained in Section 3 A = (page 5). Section 4 D (pages 10-11) evaluates flow completion times of = short flows in detail. These were simulations. Short answer: you're = right, one can get unlucky and it can turn out like you describe, but = one can also be luckier - it depends on the amount by which we overshot = the capacity+queue limit in the first place. What you describe has a = negative effect (for a limited time but for 0.8 it was outweighed by the = positive effect (the "lucky" case). The number of RTTs this can take is = bounded by log_backoffFactor (0.5) (see page 5). > Part of the problem, I think, is a weakness in the TCP cwnd reduction = algorithm - it reduces the current > cwnd by a constant factor (cwnd =3D cwnd * f) on congestion = detection; ideally, it should reduce cwnd > to its value **one RTT earlier** multiplied by the constant factor. > What this implies is that during slow-start cwnd should get reduced = as cwnd =3D cwnd * 0.5 * f. > During congestion avoidance, cwnd should get reduced as cwnd =3D = (cwnd - MSS) * f, > which is close to cwnd * f anyways. > (We have been using this scheme within our geo-satellite network = segment with TCP-PEPs > for a long time to good effect. We have also been using f =3D 0.67 = with ECN). > If it makes sense, we could suggest this in the rfc as well, perhaps = after you evaluate it in your testbeds. =46rom our results and the explanations in Section 3 A, this strikes me = as too conservative. I hope this helps, cheers, Michael From nobody Wed Jul 15 15:35:51 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73811B34E9 for ; Wed, 15 Jul 2015 15:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 hYPrR7YPC3Rg for ; Wed, 15 Jul 2015 15:35:48 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::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 AA6C11B356B for ; Wed, 15 Jul 2015 15:35:31 -0700 (PDT) Received: by vnbf7 with SMTP id f7so6174434vnb.0 for ; Wed, 15 Jul 2015 15:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dJL6uXvztnCyrIp2WQkeRVyycgyvi2cXn57d61Uh6eM=; b=NYuanC24Omgvf805+34zQ43tq3WNKWBdOe2Di+lk9ZDKS8oN0/2aRuaupJeXWkPk4B 389s4aVzYT10Fof/WuduyU5Z2iwdF39NWNERkMdhPIO9ptDvta6K2rALXpYdGcDbeaUI tJPA/Yc7PzRtMGiStBSasLBHOmEKM6utqQo2vAAZZDJiZqEUSkIKMJV4JPyT9ViusKfg l/BjLAiG+xXAOpkRHDil95V5KQZyAcFKxtWBj1am/lDZAim5T8kHnee/dd6tdtbUQx6R GsTbJCT4r/CF6k+Cp/7Glji7uQnc0FVqcEi+0fWHZbe/uRHjDP13Pc66e4WN637fBOE0 Tz8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=dJL6uXvztnCyrIp2WQkeRVyycgyvi2cXn57d61Uh6eM=; b=F6PhPlGICZIIyIJeWTd/IveXbKzdpygZVSjwJUX5QXO9Z84fPXriDRxQczqdA5kN0b OS2YVW31SdRlUNpp95UeK9/4Jw0qmxdTgLd3z2/CEbikJhkIMWcXmhWjnbJHO3z5hP6A OpxW2G9tuQCg5sjz09kGgBCGV2vXDvgrBuTKUNqfswTpPobON/4l+Jjhefc/tFONOXba XF0MVaesEJkvXOZcEgtyc9G2tUP6DFMplODCIrpAKN/pabjV3SWBqJNcrY7ZwCa0OdBW Krvzc8G8c9sCocgwdbRwP/kfmyjGNBWyhjVSDvnvF8+ir5CDDDj0oeJFF3pYJj+EeQGN EX1g== X-Gm-Message-State: ALoCoQm6HR0Dd1LewD3D20n3bQarf9mNtKvNFxTtvxbWfFk0HyVzfOxNZLfRdCGVbJ4XYVq9GxDr X-Received: by 10.52.180.3 with SMTP id dk3mr6917765vdc.32.1436999730767; Wed, 15 Jul 2015 15:35:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.83 with HTTP; Wed, 15 Jul 2015 15:34:51 -0700 (PDT) In-Reply-To: <8C832B4A-5C1D-4617-9D17-C853D324A968@ifi.uio.no> References: <38330.1436899150@lawyers.icir.org> <7A2801D5E40DD64A85E38DF22117852C70ADBEF1@wdc1exchmbxp05.hq.corp.viasat.com> <8C832B4A-5C1D-4617-9D17-C853D324A968@ifi.uio.no> From: Yuchung Cheng Date: Wed, 15 Jul 2015 15:34:51 -0700 Message-ID: To: Michael Welzl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] New Draft: TCP Alternative Backoff with ECN (draft-khademi-alternativebackoff-ecn) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 22:35:49 -0000 On Wed, Jul 15, 2015 at 3:20 PM, Michael Welzl wrote: > Hi Anil, > > Thanks for your interest! > > You'll find that the technical report at http://caia.swin.edu.au/reports/= 150710A/CAIA-TR-150710A.pdf > answers most of your questions. More below: > > >> On 15. jul. 2015, at 21.21, Agarwal, Anil wrot= e: >> >> Michael, Naeem, >> >> 1. Would be useful if the draft rfc could describe the interaction betwe= en the alternative and >> the "standard" backoff schemes for new-RENO. Kinda unrelated to the discussion, but I can't help to point out a misnomer that many people even networking experts get it wrong. NewReno (RFC6582) is NOT really a congestion control. It's just a small enhancement on fast recovery in the absence of SACK. For example, Linux uses NewReno on non-sack connections to send fast-retransmit. It works with any congestion control (cubic, dctcp, xxx). But it's kinda irrelevant b/c 99.9% conns use SACK. Reno is the AIMD we know. There is not a new version of it called NewReno := ) >> What are the fairness properties, when connections of each type are p= resent in the network? > > Page 9, Figures 14/15. Real life tests. Short answer: ratio of roughly 2:= 1, no starvation. > > >> How long does it take for cwnd to reach its steady-state value for co= nnections starting at different times? >> - For mixed connections with standard and alternative backoff fact= ors. > > We did not evaluate this because the convergence with similar backoff fac= tors was not significantly and consistently harmed by increasing the backof= f factor. > > >> - As well as for connections that use the alternative backoff fact= or only. > > Pages 8/9, figures 12/13, real life tests. > > >> - For different RTT values. > > We did not document this in the paper because convergence is already hard= to understand with similar RTT values, and changing beta did neither consi= stently improve nor worsen the situation. Some point tests showed that conv= ergence of TCP with backoff factor 0.5 does by itself not show a clear tren= d as a result of the RTT ratio, and the same is true for a different beta f= actor. In other words, we're sometimes better and sometimes worse than 0.5,= which by itself is sometimes better and sometimes worse, depending on RTT = ratios. > > >> 2. Would be useful if the simulations were complemented with some analys= is, >> showing properties of the new backoff factor. > > A rather simple model is presented on page 3. Equation 6 gives you the lo= ng-term average throughput in congestion avoidance as a function of a DropT= ail queue's buffer size (or marking ratio of at least CoDel, as Fig. 4 on t= he next page shows (simulations here) ), the capacity, the BDP and the back= off factor. Figure 2 gives a simple overview of the buffer size / backoff f= actor / throughput relationship. > > >> 3. How does the suggested backoff factor of 0.8 affect queue size and de= lays for connections in slow start? >> Let's take a simple example - >> Assume a single TCP connection and a link with bandwidth-delay produc= t =3D W bytes. >> The connection will begin in slow-start and double its cwnd every RTT= . >> Let's assume that the AQM marks a packet with ECN soon after cwnd rea= ches W. >> The ECN-echo is received by the sender one RTT later. >> At that time cwnd =3D 2W. >> Using the cwnd reduction factor of 0.8, cwnd will be reduced to 1.6W. >> This is still too high. So, one RTT later, it will be further reduced= to 1.28W. >> This is still too high. So, one RTT later, it will be further reduced= to 1.024W. >> This is still too high. So, one RTT later, it will be further reduced= to 0.82W. >> Hence, for 4 RTTs, cwnd is above W, causing substantial queue build-u= p at the bottleneck. >> ECN will probably be received for a few more RTT because of the queue= build-up; alternatively, tail-drop >> might kick in. > > This is illustrated by Fig. 6 on page 6 and explained in Section 3 A (pag= e 5). Section 4 D (pages 10-11) evaluates flow completion times of short fl= ows in detail. These were simulations. Short answer: you're right, one can = get unlucky and it can turn out like you describe, but one can also be luck= ier - it depends on the amount by which we overshot the capacity+queue limi= t in the first place. What you describe has a negative effect (for a limite= d time but for 0.8 it was outweighed by the positive effect (the "lucky" ca= se). The number of RTTs this can take is bounded by log_backoffFactor (0.5)= (see page 5). > > >> Part of the problem, I think, is a weakness in the TCP cwnd reduction a= lgorithm - it reduces the current >> cwnd by a constant factor (cwnd =3D cwnd * f) on congestion detection; = ideally, it should reduce cwnd >> to its value **one RTT earlier** multiplied by the constant factor. >> What this implies is that during slow-start cwnd should get reduced as = cwnd =3D cwnd * 0.5 * f. >> During congestion avoidance, cwnd should get reduced as cwnd =3D (cwnd = - MSS) * f, >> which is close to cwnd * f anyways. >> (We have been using this scheme within our geo-satellite network segmen= t with TCP-PEPs >> for a long time to good effect. We have also been using f =3D 0.67 wit= h ECN). >> If it makes sense, we could suggest this in the rfc as well, perhaps af= ter you evaluate it in your testbeds. > > From our results and the explanations in Section 3 A, this strikes me as = too conservative. > > I hope this helps, > > cheers, > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 15 22:25:29 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6311B30E1 for ; Wed, 15 Jul 2015 22:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IGpbFE50O457 for ; Wed, 15 Jul 2015 22:25:25 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41DB61A01F4 for ; Wed, 15 Jul 2015 22:25:25 -0700 (PDT) Received: from 5-12-82-72.residential.rdsnet.ro ([5.12.82.72] helo=[192.168.0.101]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (C.Raiciu authenticated) (Exim 4.54) id 1ZFbfR-0005dZ-8I; Thu, 16 Jul 2015 06:25:09 +0100 From: Costin Raiciu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jul 2015 08:25:57 +0300 Message-Id: To: "tcpm@ietf.org (tcpm@ietf.org)" , Yuchung Cheng Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [tcpm] TCP sendbuffer advertising X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 05:25:27 -0000 Yuchung,=20 Thanks for your comments. Below are answers to your questions. > 1) what happens when the backlog / sendbuf > 65536B? Probably simply advertise the maximum you can encode, or use some sort = of scaling.=20 However, we have 4 bytes available for the encoding in packs (or in = options, if you can spare the space), so you should be able to advertise = a 4GB backlog, which is plenty. > 2) announcing the backlog may help larger incast when the response > > cwnd (i.e., taking multiple round trips to deliver). but many incast > patterns I know of fit entirely in the first cwnd. For example 1000 > senders write 2 packets each to a single receiver. ECN/dctcp has the > same limitation on such type of incast. Sendbuffer advertising does not help here, agreed - all the advertised = values will be zero. > 3) some application prefer late-binding and delays writing data into > the socket with features like TCP_NOTSENT_LOWAT > (https://lwn.net/Articles/560082/). Thus the sendbuf remains low while > app backlog may be very large. The react function that uses the > sendbuf info should not assume sendbuf =3D=3D app backlog. The backlog will still be non-zero most often even in this case, = otherwise the applications are underutilizing their network. This should = still indicate to the network that the app is backlogged. The amount of = backlogged data is not as important as the fact that there is a = persistent backlog. > 4) for HTTP/2 often the conversation is bi-directional: the server may > be responding to a HTTP/2 request while actively acking other new > client requests. > The receiver window of the packets will alternate between sendbuf or > receiver window. hence the sendbuf info may be missing intermittently. Agreed. We just need to apply our patch and measure this. Will come back = with answers when we have them. > but I think this is an interesting feature worth exploring! Glad you like it. We beilieve it=E2=80=99s quite useful too; that=E2=80=99= s why we=E2=80=99re bringing it to TCPM. Best. Costin >=20 >>=20 >> Best. >> Costin >> ---------------------------------------------- >> Costin Raiciu >> Associate Professor >> Homepage: http://nets.cs.pub.ro/~costin/ >> CS Department >> University Politehnica of Bucharest >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jul 16 04:24:03 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1A41B39E7 for ; Thu, 16 Jul 2015 04:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 yD2bXwHuLcOW for ; Thu, 16 Jul 2015 04:24:00 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.229]) by ietfa.amsl.com (Postfix) with ESMTP id 06D051B39E6 for ; Thu, 16 Jul 2015 04:24:00 -0700 (PDT) Received: from t40700-la020.org.aalto.fi (130.233.145.15) by jenni1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 5511FF580794CB07 for tcpm@ietf.org; Thu, 16 Jul 2015 14:23:58 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 16 Jul 2015 14:24:00 +0300 To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [tcpm] TCPM agenda for IETF-93 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 11:24:02 -0000 Hi, Here is the agenda for TCPM meeting in IETF-93, slightly revised from = the previous version I sent. Hope to see many of you in Prague! - Pasi =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TCPM meeting, IETF-93, Prague, Czech Republic Wednesday, July 22, 13:00 - 15:30 WG Status --------- Time: 5 minutes Working Group Items ------------------- * TCP Extended Data Offset Option draft-ietf-tcpm-tcp-edo Speaker: chairs for the authors Time: 5 minutes * Analysis of the TCP EDO option Speaker: Olivier Bonaventure Time: 10 minutes * RFC793bis draft-ietf-tcpm-rfc793bis Speaker: chairs for authors Time: 20 minutes Other Items ----------- * Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters draft-bensley-tcpm-dctcp Speaker: Praveen Balasubramanian / Lars Eggert Time: 10 minutes * The TCP Echo and TCP Echo Reply Options draft-zimmermann-tcpm-echo-option Speaker: Alex Zimmermann Time: 10 minutes * Using the TCP Echo Option for Spurious Retransmission Detection Speaker: Alex Zimmermann Time: 10 minutes * Fast Open IPv6 extension draft-hawari-tcpm-tfo-ipv6-prefixes Speaker: Mohammed HAWARI Time: 10 minutes * TCP Alternative Backoff with ECN (ABE) draft-khademi-alternativebackoff-ecn Speaker: Naeem Khademi Time: 20 minutes * TCP Sendbuffer Advertising Speaker: Costin Raiciu Time: 15 minutes From nobody Thu Jul 16 16:28:29 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4741AD05D for ; Thu, 16 Jul 2015 16:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zcov3FaISAGk for ; Thu, 16 Jul 2015 16:28:25 -0700 (PDT) Received: from maxwell.palermo.edu (maxwell.palermo.edu [200.69.213.7]) by ietfa.amsl.com (Postfix) with ESMTP id DA6A81AD055 for ; Thu, 16 Jul 2015 16:28:23 -0700 (PDT) X-Authorization-Id: how= who= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=palermo.edu; s=default; t=1437088813; bh=SCmmSaJ1z+NRsLgCeQau2HCZIDJXRPaaOt+T023GQek=; h=References:From:To:Date:In-Reply-To:Subject; b=Fp9gCAr78Zz+Rdf/8ScOOsOPJlvCGvBJn/vRkwxzxka2blLx8DIOWVdHrNKp4rtyp +pFGvW+FS+7dti0v2sU9TV9YiGyCRB5g0XroGYAjaXM0A4M6EyHfl+wqURgYSiUmkP YOMJwIpEt/cu4xMkOHWtjNBJnRTCNZREE9LeSlbQ= Received: from maxwell.palermo.edu (localhost [127.0.0.1]) by maxwell.palermo.edu (8.14.4/8.14.4) with ESMTP id t6GNKCQt011075; Thu, 16 Jul 2015 20:20:13 -0300 Received: from [10.10.30.100] ( [10.10.30.100]) by maxwell.palermo.edu with ESMTP id G1FTYPGA.2561854.0 References: <721EA345-FB24-45D1-9ADF-D028F216365F@cs.pub.ro> From: Alejandro Popovsky To: tcpm@ietf.org, costin.raiciu@cs.pub.ro Message-ID: <55A83E0F.3010301@palermo.edu> Date: Thu, 16 Jul 2015 20:28:15 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <721EA345-FB24-45D1-9ADF-D028F216365F@cs.pub.ro> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Host: 10.10.30.100 Archived-At: Subject: Re: [tcpm] TCP sendbuffer advertising X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 23:28:28 -0000 Hi Costin, Sender buffer info would be useful to check if the flow is network limited (NL), data-generation limited (DG), or flow control limited (FC). But a one bit field might be enough. I'll comment the draft below: > A key information needed by networks is whether a connection is > limited by the network or by the application. This information > is very difficult to accurately infer by passive measurements. We are currently doing that without this extra buffer info for all connections between ISP's flowing through the IXP's of the Argentine Chamber of Internet (CABASE), by following all connections state using UpPerfomanceAnalyzer. This analysis is used to evaluate real time end-user performance and end-to-end capacity. > This information enables network boxes and receivers to easily > identify connections that need more capacity.... It might be dangerous to use it to assign capacity in network boxes, because end users could just lie about their backlogged data in order to steal capacity from neighbor connections. > ...to estimate the sender congestion window and to accurately > monitor flight-size.... > ...having SND.NXT smaller than WRITE.SEQ indicates that the > congestion window is not large enough, so the connection is > network limited at that point in time. It is not absolutely necessary to estimate sender congestion window size in order to check Network Limitation (NL). When senders hit their congestion window top, they become ack-clocked and this can be detected at the monitor point by checking both the data and ack flow timings. Filling the congestion window is also not necessarily an indication of Network Limitation (NL), because the congestion window may be smaller than the current bandwidth delay product at the time. In such case the sender is ack clocked but the data segment pace is still a burst per round trip time. Anyhow, it would simplify the limitation analysis to have a bit at the end of each burst indicating if transmission was stopped by the window or by the lack of data to send. > As long as the receive window is not a bottleneck... Filling the receiver window is again not always an indication of flow control limitation (FC) limitation. If receiver window is bigger than the bandwidth delay product (BDP), the sender can still reach the available capacity. It can be observed in some of the chamber ISP's with old tcp stacks in their cache-boxes, with many connections reaching their available capacity even with their rcvd window full. All this said, including info about the sender buffer looks positive, and would help limitation analysis to be less demanding. Although one bit field might suffice, something similar to the push bit, or a small change to it. Best regards, Alejandro Popovsky. On 13/07/2015 05:24 p.m., Costin Raiciu wrote: > Dear all, > > We have been working on a simple extension to TCP that encode the amount of backlogged bytes in each TCP segment. This information can be used by the network or the receiver for various optimizations. > > I will be present our work during the TCPM working group in Prague. This email is a heads-up for those interested in hearing more about the work before it is presented. > > We have written a draft on the encoding, but unfortunately we have missed the Prague cutoff. You can download the draft from my webpage at http://nets.cs.pub.ro/~costin/files/draft-agache-tcpm-sndbufadv.txt > We will submit it properly as soon as the I-D submission tool reopens on saturday. > > We also have a workshop paper in HotClout 2015 on the various use-cases of send buffer advertising, and our prototype implementation, that you can find at: http://nets.cs.pub.ro/~costin/files/sndbuf.pdf > > We are looking forward to your comments. > > Best. > Costin > ---------------------------------------------- > Costin Raiciu > Associate Professor > Homepage: http://nets.cs.pub.ro/~costin/ > CS Department > University Politehnica of Bucharest > > > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jul 17 02:54:50 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B1F1B3239 for ; Fri, 17 Jul 2015 02:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VEW__HRYcDWd for ; Fri, 17 Jul 2015 02:54:46 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F2D1B3119 for ; Fri, 17 Jul 2015 02:54:46 -0700 (PDT) Received: from 5-12-82-72.residential.rdsnet.ro ([5.12.82.72] helo=[192.168.0.101]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (C.Raiciu authenticated) (Exim 4.54) id 1ZG2Lm-0007Ft-N7; Fri, 17 Jul 2015 10:54:38 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Costin Raiciu In-Reply-To: <55A83E0F.3010301@palermo.edu> Date: Fri, 17 Jul 2015 12:55:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7F2A1ADD-7580-473E-8401-0A58A7BF65CA@cs.ucl.ac.uk> References: <721EA345-FB24-45D1-9ADF-D028F216365F@cs.pub.ro> <55A83E0F.3010301@palermo.edu> To: Alejandro Popovsky X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] TCP sendbuffer advertising X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 09:54:49 -0000 > Hi Costin, >=20 > Sender buffer info would be useful to check if the flow is network = limited > (NL), data-generation limited (DG), or flow control limited (FC). But = a one > bit field might be enough. I'll comment the draft below: For most scenarios, a one bit field is enough, I agree. There are = however some use cases where knowing the amount of backlogged data might = help (e.g. in our HotCloud paper we can infer losses=20 even if we sample packets 1:100 just by looking at cwnd information!). >> A key information needed by networks is whether a connection is >> limited by the network or by the application. This information >> is very difficult to accurately infer by passive measurements. >=20 > We are currently doing that without this extra buffer info for all = connections > between ISP's flowing through the IXP's of the Argentine Chamber of = Internet > (CABASE), by following all connections state using = UpPerfomanceAnalyzer. This > analysis is used to evaluate real time end-user performance and = end-to-end > capacity. Cool, I=92d like to hear more about the operation of this box - however = it sounds pretty expensive :). >> This information enables network boxes and receivers to easily >> identify connections that need more capacity.... >=20 > It might be dangerous to use it to assign capacity in network boxes, > because end users could just lie about their backlogged data in order = to steal > capacity from neighbor connections. You are spot on here - this is an open question. >> ...to estimate the sender congestion window and to accurately >> monitor flight-size.... >=20 >> ...having SND.NXT smaller than WRITE.SEQ indicates that the >> congestion window is not large enough, so the connection is >> network limited at that point in time. >=20 > It is not absolutely necessary to estimate sender congestion window = size in order > to check Network Limitation (NL). When senders hit their congestion = window > top, they become ack-clocked and this can be detected at the monitor = point > by checking both the data and ack flow timings. You are right, but I would think you need to be close to the source to = accurately detect packets released by the ACK clock.=20 Surely measurements become quite noisy when you are close to the = receiver, ACKs can get lost, etc Even so, this solution is rather expensive as it needs to see most (if = not all packets in both directions) - am I right? We are proposing a = cheaper, always on option. > Filling the congestion window is also not necessarily an indication of > Network Limitation (NL), because the congestion window may be smaller > than the current bandwidth delay product at the time. In such case the = sender > is ack clocked but the data segment pace is still a burst per round = trip time. > Anyhow, it would simplify the limitation analysis to have a bit at the = end of > each burst indicating if transmission was stopped by the window or by = the > lack of data to send. Sure, but if you average the send buffer information across enough RTTs = you can understand fairly accurately if the network is the limiting = factor or the app. >> As long as the receive window is not a bottleneck... >=20 > Filling the receiver window is again not always an indication of flow = control > limitation (FC) limitation. If receiver window is bigger than the = bandwidth > delay product (BDP), the sender can still reach the available = capacity. It can > be observed in some of the chamber ISP's with old tcp stacks in their > cache-boxes, with many connections reaching their available capacity > even with their rcvd window full. Agreed. > All this said, including info about the sender buffer looks positive, > and would help limitation analysis to be less demanding. Although > one bit field might suffice, something similar to the push bit, > or a small change to it. Thanks a lot for your comments.=20 Costin >=20 > Best regards, Alejandro Popovsky. >=20 >=20 > On 13/07/2015 05:24 p.m., Costin Raiciu wrote: >> Dear all, >>=20 >> We have been working on a simple extension to TCP that encode the = amount of backlogged bytes in each TCP segment. This information can be = used by the network or the receiver for various optimizations. >>=20 >> I will be present our work during the TCPM working group in Prague. = This email is a heads-up for those interested in hearing more about the = work before it is presented. >>=20 >> We have written a draft on the encoding, but unfortunately we have = missed the Prague cutoff. You can download the draft from my webpage at = http://nets.cs.pub.ro/~costin/files/draft-agache-tcpm-sndbufadv.txt >> We will submit it properly as soon as the I-D submission tool reopens = on saturday. >>=20 >> We also have a workshop paper in HotClout 2015 on the various = use-cases of send buffer advertising, and our prototype implementation, = that you can find at: http://nets.cs.pub.ro/~costin/files/sndbuf.pdf >>=20 >> We are looking forward to your comments. >>=20 >> Best. >> Costin >> ---------------------------------------------- >> Costin Raiciu >> Associate Professor >> Homepage: http://nets.cs.pub.ro/~costin/ >> CS Department >> University Politehnica of Bucharest >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 From nobody Sat Jul 18 04:40:04 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD76C1B2B93 for ; Sat, 18 Jul 2015 04:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 DJqsH8rm4boc for ; Sat, 18 Jul 2015 04:39:59 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id A595A1B2A78 for ; Sat, 18 Jul 2015 04:39:57 -0700 (PDT) Received: from t40700-la020.lan (80.223.92.46) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 552B87C905138F15 for tcpm@ietf.org; Sat, 18 Jul 2015 14:39:56 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <10474_1437045855_55A7945F_10474_8350_1_AD740AC7-1843-4622-94FF-56C0E992209C@iki.fi> Date: Sat, 18 Jul 2015 14:39:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <84825990-F6B8-431D-A66D-09D7518DE1F3@iki.fi> References: <10474_1437045855_55A7945F_10474_8350_1_AD740AC7-1843-4622-94FF-56C0E992209C@iki.fi> To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [tcpm] IETF-93 speakers: slides by Tuesday noon X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 11:40:01 -0000 TCPM speakers, Please send your slides by Tuesday noon (the local meeting time) to = tcpm-chairs. pdf is the preferred format, but ppt works as well. Please = also number the pages. - Pasi On 16 Jul 2015, at 14:24, Pasi Sarolahti wrote: > Hi, >=20 > Here is the agenda for TCPM meeting in IETF-93, slightly revised from = the previous version I sent. Hope to see many of you in Prague! >=20 > - Pasi >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > TCPM meeting, IETF-93, Prague, Czech Republic > Wednesday, July 22, 13:00 - 15:30 >=20 > WG Status > --------- > Time: 5 minutes >=20 > Working Group Items > ------------------- >=20 > * TCP Extended Data Offset Option > draft-ietf-tcpm-tcp-edo > Speaker: chairs for the authors > Time: 5 minutes >=20 > * Analysis of the TCP EDO option > Speaker: Olivier Bonaventure > Time: 10 minutes >=20 > * RFC793bis > draft-ietf-tcpm-rfc793bis > Speaker: chairs for authors > Time: 20 minutes >=20 > Other Items > ----------- >=20 > * Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters > draft-bensley-tcpm-dctcp > Speaker: Praveen Balasubramanian / Lars Eggert > Time: 10 minutes >=20 > * The TCP Echo and TCP Echo Reply Options > draft-zimmermann-tcpm-echo-option > Speaker: Alex Zimmermann > Time: 10 minutes >=20 > * Using the TCP Echo Option for Spurious Retransmission Detection > Speaker: Alex Zimmermann > Time: 10 minutes >=20 > * Fast Open IPv6 extension > draft-hawari-tcpm-tfo-ipv6-prefixes > Speaker: Mohammed HAWARI > Time: 10 minutes >=20 > * TCP Alternative Backoff with ECN (ABE) > draft-khademi-alternativebackoff-ecn > Speaker: Naeem Khademi > Time: 20 minutes >=20 > * TCP Sendbuffer Advertising > Speaker: Costin Raiciu > Time: 15 minutes >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sat Jul 18 21:46:38 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E66B1A1A8B for ; Sat, 18 Jul 2015 21:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 z-FPy2ytbZ1u for ; Sat, 18 Jul 2015 21:46:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2CC1A1A6D for ; Sat, 18 Jul 2015 21:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wXT8FnWElUc+78JtITHWTnTjK3cIyX5vtBONpK6IoMc=; b=WnbiaParcHhuaM7aOG+bxfnuekAugfMq72KQwRZ5Zv/dkeDHER8eYDByApOBVImDuDf69ZLtTzO/h5zcKHhoFpLZhZ04kiNzgLsImLMbgjxewLEgP/t4Jmw9xB6Qa1tDbrngHYUrHYCbsKBU41ka6n00Om6W2TiFCFFsOXpVPmM= Received: from BN1PR03MB008.namprd03.prod.outlook.com (10.255.224.38) by BN1PR03MB023.namprd03.prod.outlook.com (10.255.224.41) with Microsoft SMTP Server (TLS) id 15.1.213.10; Sun, 19 Jul 2015 04:45:55 +0000 Received: from BN1PR03MB008.namprd03.prod.outlook.com ([169.254.7.139]) by BN1PR03MB008.namprd03.prod.outlook.com ([169.254.7.139]) with mapi id 15.01.0213.021; Sun, 19 Jul 2015 04:45:55 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [tcpm] Review of draft-bensley-tcpm-dctcp-03 Thread-Index: AQHQqcskaeSYI99oC06rW5EqZt3bHZ2yRY6AgCKuDuCABHWyAIAI+vwA Date: Sun, 19 Jul 2015 04:45:54 +0000 Message-ID: References: <031D67EB-0676-4398-B5DF-E2F73D174E58@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tik.ee.ethz.ch; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:4::584] x-microsoft-exchange-diagnostics: 1; BN1PR03MB023; 5:P0pr5BsQu3XstrjeYjdnlaIdgit08sVl7SgYP1Hm9+0wGp0opWvTNiLJSXf9VeaIQ0lOAh94bS0oEDP024PyXXJjRowFV079r4JDG9ymcdZPkaBKDKSEw1/E1S5b7f+EfSBYLcCXf9NrDq/1O1ydrw==; 24:5xOUd21BePsjF+7dkmHfyVmuzHIrRH+L/XO0nqaNA/Xw2fjLNTlx9AM85kGRUHycRI+Wr0/Xtdeds5CtYWj4HQ3OfFEmnVNuRNPDS+RH8fA=; 20:jiqR2ko+UgWGfECUHqkPJjH+YOnrpEJGDcOgennkFHOPVMbPuiRmHFdPTfL6LdIEg04IJNNPS7N6MNb01w/JoQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BN1PR03MB023; bn1pr03mb023: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BN1PR03MB023; BCL:0; PCL:0; RULEID:; SRVR:BN1PR03MB023; x-forefront-prvs: 0642A5E7BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(43784003)(377454003)(52604005)(33656002)(77156002)(2950100001)(2900100001)(15975445007)(40100003)(2656002)(122556002)(19580405001)(110136002)(230783001)(106116001)(74316001)(5003600100002)(5001960100002)(86362001)(102836002)(76176999)(19580395003)(50986999)(92566002)(93886004)(5001920100001)(54356999)(87936001)(62966003)(189998001)(46102003)(5002640100001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB023; H:BN1PR03MB008.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2015 04:45:54.4877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR03MB023 Archived-At: Cc: "tcpm@ietf.org" , Dave Thaler Subject: Re: [tcpm] Review of draft-bensley-tcpm-dctcp-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 04:46:38 -0000 VGhhbmtzIE1pcmphLiBTb21lIHJlc3BvbnNlcyBpbmxpbmUgcHJlZml4ZWQgd2l0aCBbUEJdLiBX ZSBwbGFuIHRvIHByZXNlbnQgdGhlIGN1cnJlbnQgZHJhZnQgcmV2aXNpb24gMDUgaW4gdGNwbSBi dXQgd2Ugd2lsbCBtYWtlIHN1cmUgdGhlIHJlbWFpbmluZyBmZWVkYmFjayBpcyBhZGRyZXNzZWQg aW4gdGhlIG5leHQgcmV2aXNpb24uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBNaXJqYSBLw7xobGV3aW5kIFttYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5j aF0gDQpTZW50OiBNb25kYXksIEp1bHkgMTMsIDIwMTUgNDoyNCBBTQ0KVG86IFByYXZlZW4gQmFs YXN1YnJhbWFuaWFuDQpDYzogRWdnZXJ0LCBMYXJzOyBEYXZlIFRoYWxlcjsgU3RlcGhlbiBCZW5z bGV5OyB0Y3BtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RjcG1dIFJldmlldyBvZiBkcmFmdC1i ZW5zbGV5LXRjcG0tZGN0Y3AtMDMNCg0KSGkgUHJhdmVlbiwNCg0KdGhhbmtzIGZvciB1cGRhdGlu Zy4gU2VlIGEgZmV3IGNvbW1lbnRzL3Jlc3BvbnNlcyBiZWxvdy4NCg0KTWlyamENCg0KPiANCj4+ IA0KPj4gMikgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZXNjcmliZSB3aGF0IHRoZSBNaWNyb3Nv ZnQgaW1wbGVtZW50YXRpb24gZG9lcyBpZiBsb3NzIGlzIGRldGVjdGVkLiBJIHRoaW5rIG5vcm1h bGx5IHRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG5vIChjb25nZXN0aW9u LWJhc2VkKSBsb3NzIGFueW1vcmUgaW4gYSBkYXRhIGNlbnRlciB3aGVyZSBhbGwgdHJhZmZpYyBp cyB1c2luZyBEQ1RDUC4gSG93ZXZlciwgdGhlIGRyYWZ0IHNob3VsZCBzdGlsbCBzYXkgd2hhdCB0 byBkbyBpZiBsb3NzIG9jY3Vycy4gSWYgSSByZW1lbWJlciBjb3JyZWN0bHkgdGhlIExpbnV4IGlt cGxlbWVudGF0aW9uIGhhcyBhIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVyIHRvIGRlY2lkZSBpZiBh IGxvc3Mgc2hvdWxkIGJlIGlnbm9yZWQgb3IgdGhlIHdpbmRvdyBzaG91bGQgYmUgaGFsdmVkLiBN YXliZSB5b3UgY2FuIGFnYWluIGNsYXJpZnkgd2l0aCBEYW5pZWwgQm9ya21hbm4gd2hvIGltcGxl bWVudGVkIHRoaXMgaW4gTGludXg7IEkga25vdyBoZSBoYXMgcmVhZCB0aGUgZHJhZnQgYW5kIGlz IHByb2JhYmx5IHdpbGxpbmcgdG8gcmV2aWV3IGFnYWluIG9yIGV2ZW4gcHJvdmlkZSBzb21lIHRl eHQgb24gdGhpcyBpZiBuZWVkZWQuDQo+PiANCj4gDQo+Pj4gV2luZG93cyBTZXJ2ZXIgZG9lcyBu b3QgYWRqdXN0IHRoZSB2YWx1ZSBvZiBBbHBoYSBmb3IgdGhlIHJvdW5kIGlmIGxvc3MgaXMgZGV0 ZWN0ZWQuIFdlIGFyZSB1bmRlciBkaXNjdXNzaW9uIHdpdGggRGFuaWVsIGFib3V0IGFkZHJlc3Np bmcgdGhpcyBpbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQgdW5kZXIgSW1wbGVtZW50 YXRpb24gaXNzdWVzIHNlY3Rpb24uDQoNCkdyZWF0ISBJIHJlYWxseSB3b3VsZCBsaWtlIHRvIHNl ZSBsb3NzIGhhbmRsaW5nIGFkZHJlc3NlZCENCg0KW1BCXSBMb29rcyBsaWtlIHdlIGRpZCBhZGQg YSBjb21tZW50IGFib3V0IHRoaXMgaW4gaW1wbGVtZW50YXRpb24gc2VjdGlvbi4gV2Ugd291bGQg ZXhwYW5kIHVwb24gdGhpcyBhIGJpdCBtb3JlIGluIHRoZSBuZXh0IHJldmlzaW9uLiANCg0KPiAN Cj4+IA0KPj4gMikgVGhlIHNlY29uZCBwb2ludCBnb2VzIGluIHRoZSBzYW1lIGRpcmVjdGlvbjog c2VjdGlvbiAzLjEgc2F5czoNCj4+ICJIb3dldmVyLCB0aGUgYWN0dWFsDQo+PiAgYWxnb3JpdGht IGZvciBtYXJraW5nIGNvbmdlc3Rpb24gaXMgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsIG9mIHRo ZSAgDQo+PiBzd2l0Y2ggYW5kIHdpbGwgZ2VuZXJhbGx5IG5vdCBiZSBrbm93biB0byB0aGUgc2Vu ZGVyIGFuZCByZWNlaXZlci4NCj4+ICBUaGVyZWZvcmUsIHNlbmRlciBhbmQgcmVjZWl2ZXIgTVVT VCBOT1QgYXNzdW1lIHRoYXQgYSBwYXJ0aWN1bGFyICANCj4+IG1hcmtpbmcgYWxnb3JpdGhtIGlz IGltcGxlbWVudGVkIGJ5IHRoZSBzd2l0Y2hpbmcgZmFicmljLuKAnCBGaXJzdCBvZiANCj4+IGFs bCwgdGhpcyBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IHNob3VsZCBub3QgdXNlIG5vcm1hdGl2ZSBs YW5ndWFnZSBoZXJlLiBBbmQgc2Vjb25kLCBpZiBEQ1RDUCBpcyB1c2VkIGFuZCB0ZXN0ZWQgYnkg TWljcm9zb2Z0IG9ubHkgd2l0aCBhIGNlcnRhaW4gY29uZmlndXJhdGlvbiwgSSB3b3VsZCByZW1v dmUgdGhpcyBzZW50ZW5jZSBhbmQgd3JpdGUgcmF0aGVyIHNvbWV0aGluZyBsaWtlOg0KPj4g4oCe RXZlbiB0aG91Z2ggdGhlIGFjdHVhbA0KPj4gIGFsZ29yaXRobSBmb3IgbWFya2luZyBjb25nZXN0 aW9uIGlzIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbCBvZiB0aGUgIA0KPj4gc3dpdGNoIGFuZCB3 aWxsIGdlbmVyYWxseSBub3QgYmUga25vd24gdG8gdGhlIHNlbmRlciBhbmQgcmVjZWl2ZSwgIA0K Pj4gRENUQ1AgaGFzIGJlZW4gZGVzaWduIGFuZCBldmFsdWF0ZWQgdG8gYmUgdXNlZCB3aXRoIHRo ZSBjb25maWd1cmF0aW9uIA0KPj4gZGVzY3JpYmUgYWJvdmUu4oCcDQoNCknigJlkIGxpa2UgdG8g YWRkIGhlcmUgdGhhdCBpbiBhIGRhdGFjZW50ZXIgdGhlIEFRTSBjb25maWcgbWlnaHQgYWN0dWFs bHkgYmUga25vd24gYW5kIHRoYXTigJlzIHRoZSBwcmltYXJ5IHVzZSBjYXNlL2RlcGxveW1lbnQg c2NlbmFyaW8gb2YgRENUQ1AuIFNvIEkgZG9u4oCZdCByZWFsbHkgc2F5IHNlZSB3aHkgaXQgaXMg c28gaW1wb3J0YW50IGZvciB5b3UgdG8gc2F5IHRoYXQgRENUQ1Agd29ya3Mgd2l0aCBkaWZmZXJl bnQga2luZCBvZiBBUU0uIElmIGl0IGlzIGRlc2lnbiB0byBiZSB1c2VkIGluIGRhdGFjZW50ZXJz IGFuZCB5b3UgaGF2ZSB0ZXN0ZWQgaXQgZXh0ZW5zaXZlbHkgd2l0aCBvbmUgQVFNIGNvbmZpZywg d2h5IGRvbuKAmXQgeW91IHJlbWVtYmVyIHRoaXMgY29uZmlnPw0KDQpbUEJdIEl0IGlzIGltcG9y dGFudCBiZWNhdXNlIERDVENQIGNhbiB3b3JrIHdpdGggb3RoZXIgZm9ybXMgb2YgQVFNLiBBUU0g c3VwcG9ydCBtYXkgYmUgZGlmZmVyZW50IGluIGRpZmZlcmVudCBjb21tb2RpdHkgc3dpdGNoZXMu IFRoZSBwcmltYXJ5IGdvYWwgaXMgdG8gZG9jdW1lbnQgdGhlIGNoYW5nZXMgZm9yIHRoZSBUQ1Ag cHJvdG9jb2wgb24gdGhlIHNlbmRlciBhbmQgcmVjZWl2ZXIgc28gd2UgY2FuIGFjaGlldmUgaW50 ZXJvcCBiZXR3ZWVuIG11bHRpcGxlIGltcGxlbWVudGF0aW9ucyBvZiBEQ1RDUC4gR29pbmcgZm9y d2FyZCB0aGlzIHdvdWxkIGJlIGltcG9ydGFudCBhcyBJYWFTIGNhdGNoZXMgb24gYW5kIGRhdGFj ZW50ZXJzIHJ1biBhIG1peCBvZiBtdWx0aXBsZSBPU3MuDQoNCj4gDQo+PiANCj4+IDQpIFNlY29u ZCBwYXJhZ3JhcGggc2F5cyAid29ya2VyIG5vZGVzIGNvbXBsZXRlIGF0IGFwcHJveGltYXRlbHkg dGhlIHNhbWUgdGltZeKAnC4gSSB0aG91Z2h0IHRoYXQgdGhleSB3b3VsZCBldmVuIGNvbXBsZXRl IGF0IGV4YWN0bHkgdGhlIHNhbWUgdGltZSBiZWNhdXNlIHRoZXkgb2Z0ZW4gaGF2ZSBhIHRpbWVv dXQuLj8gQ2FuIHlvdSBjb21tZW50IGhlcmUgYXMgd2VsbD8gTWF5YmUgYWxzbyByZWZlciB0aGUg RENUQ1AgcGFwZXIgaGVyZSBiZWNhdXNlIGl0IGNvbnRhaW5zIGEgZ29vZCBhbmFseXNpcyBvZiBp bmNhc3QuDQo+PiANCj4gDQo+Pj4gVGhlIHdvcmtsb2FkcyBhcmUgcGFydGl0aW9uZWQgdG8gdGhl IHNhbWUgc2l6ZSBkYXRhc2V0cyBhbmQgYXNzdW1pbmcgYSB1bmlmb3JtIG5ldHdvcmsgYW5kIHNl cnZlciBjb25maWd1cmF0aW9uIHRoZSB0YXNrcyBjb21wbGV0aW5nIGF0IHRoZSBzYW1lIHRpbWUg aXMgaGlnaGx5IGxpa2VseS4gDQoNCkkgd2FzIGJhc2ljYWxseSBzYXlpbmcgdGhhdCB5b3UgY291 bGQgbWFrZSB0aGlzIHBvaW50IGV2ZW4gc3Ryb25nZXIgYW5kIHNheSBlLmcuIOKAnndvcmtzIG5v ZGVzIGFyZSB2ZXJ5IGxpa2VseSB0byBjb21wbGV0ZSBhdCB0aGUgc2FtZSB0aW1l4oCcIGFuZCBy ZW1vdmUgdGhlIOKAmmFwcHJveGltYXRlbHnigJguIEJ1dCBpbiBmYWN0IHRoYXQgZG9lc27igJl0 IHJlYWxseSBtYXR0ZXLigKYNCg0KPiANCj4+IDYpIEFic3RyYWN0IGFuZCBpbnRybyBib3RoIHNh eSDigJ5EQ1RDUCBlbmhhbmNlcyBFQ07igKbigJw7IEkgcmVhbGx5IGRvbuKAmXQgdGhpbmsg4oCa ZW5oYW5jZScgY2FuIGJlIHVzZWQgaGVyZSBzbyBnZW5lcmFsbHk7IGlmIHRoZSBjb25nZXN0aW9u IGNvbnRyb2wgb25seSBuZWVkcyBvbmUgZmVlZGJhY2sgc2lnbmFsIHBlciBSVFQsIHRoZXJlIGlz IG5vIGVuaGFuY2VtZW50LiBNYXliZSBzYXkg4oCaY2hhbmdl4oCYIG9yIOKAmmltcHJvdmVzIHRo ZSBhY2N1cmFjeSBvZiB0aGUgRUNOIGZlZWRiYWNrIHNpZ25hbCBieSBzaWduYWwgbm90IG9ubHkg dGhlIG9jY3VycmVuY2Ugb2YgY29uZ2VzdGlvbiBidXQgYWxzbyBpdHMgZXh0ZW5k4oCY4oCmIG9y IHNvbWV0aGluZyBsaWtlIHRoaXMuDQo+PiANCj4gDQo+Pj4gV2UgYWx0ZXJlZCB0aGUgbGFuZ3Vh Z2Ugc29tZXdoYXQgdG8gbWFrZSB0aGlzIGNsZWFyZXIgIiBEYXRhY2VudGVyIFRDUCAoRENUQ1Ap IGltcHJvdmlzZXMgdXBvbiB0cmFkaXRpb25hbCBFQ04gcHJvY2Vzc2luZyBieSDigKYiLg0KDQpO b3Qgc3VyZSBpZiBpbXByb3Zpc2VzIGl0IHRoZSBiZXN0IHdvcmTigKYgbWF5YmUganVzdCBzYXkg 4oCaZXh0ZW5kc+KAmOKApj8NCg0KW1BCXSBPa2F5IHdlIHdpbGwgY2hhbmdlIHRoaXMgaW4gdGhl IG5leHQgcmV2aXNpb24uIEdvdCB0aGUgc2FtZSBmZWVkYmFjayBmcm9tIFJpY2hhcmQuDQoNCj4g DQo+PiA4KSBJ4oCZZCBsaWtlIHRvIHByb3Bvc2UgdG8gdXNlIHRoZSBsaXN0IGdpdmVuIGluIHNl Y3Rpb24gMyBub3Qgb25seSB0byBzYXkgd2hpY2ggZWxlbWVudHMgYXJlIOKAmmludm9sdmVk4oCY IGJ1dCBhbHNvIHZlcnkgYnJpZWZseSBzYXkgd2hhdCB3YXMg4oCabW9kaWZpZWTigJgsIGUuZy4N Cj4+IA0KPj4gIlRoZXJlIGFyZSB0aHJlZSBjb21wb25lbnRzIHRoYXQgbmVlZHMgdG8gYmUgbW9k aWZpZWQgdG8gdXNlIERDVENQOg0KPj4gDQo+PiAgbyAgVGhlIHN3aXRjaCAob3Igb3RoZXIgaW50 ZXJtZWRpYXRlIGRldmljZSBvbiB0aGUgbmV0d29yaykgZGV0ZWN0cw0KPj4gICAgIGNvbmdlc3Rp b24gYW5kIHNldHMgdGhlIENvbmdlc3Rpb24gRXhwZXJpZW5jZWQgKENFKSBjb2RlcG9pbnQgaW4N Cj4+ICAgICB0aGUgSVAgaGVhZGVyIGFscmVhZHkgd2hlbiBhIHZlcnkgc2hvcnQgcXVldWUgYnVp bGRzIHVwLiANCj4+IA0KPj4gIG8gIFRoZSByZWNlaXZlciBlY2hvZXMgZWFjaCBvY2N1cnJlbmNl IG9mIGEgdGhlIENvbmdlc3Rpb24gRXhwZXJpZW5jZWQgKENFKSBtYXJrDQo+PiAgICAgYmFjayB0 byB0aGUgc2VuZGVyIHVzaW5nIHRoZSBFQ04tRWNobyAoRUNFKSBmbGFnIGluIHRoZSBUQ1AgaGVh ZGVyLg0KPj4gDQo+PiAgbyAgVGhlIHNlbmRlciByZWFjdHMgdG8gdGhlIGNvbmdlc3Rpb24gaW5k aWNhdGlvbiBieSByZWR1Y2luZyB0aGUgVENQDQo+PiAgICAgY29uZ2VzdGlvbiB3aW5kb3cgKGN3 bmQpIGJhc2VkIG9uIHRoZSBleHRlbmQgb2YgY29uZ2VzdGlvbiANCj4+IGV4cGVyaWVuY2VkIGlu IHRoZSBsYXN0IFJUVC7igJwNCj4+IA0KPj4gSSB0aGluayB0aGlzIGdpdmVuIGEgbmljZSBoaWdo LWxldmVsIG92ZXJ2aWV3IGFuZCBoZWxwcyB0aGUgcmVhZGVyIHRvIGVhc2llciB1bmRlcnN0YW5k IHRoZSByZXN0Lg0KPj4gDQo+PiA5KSBNYXliZSBhZGQgIHRvIHNlY3Rpb24gMy4yIHRoZSBzdGF0 ZSBtYWNoaW5lIGltYWdlIGFzIHByb3ZpZGVkIGluIA0KPj4gdGhlIHBhcGVyLiBJIHBlcnNvbmFs bHkgd291bGQsICBpbiBhbiBSRkMsIGFsc28gZGVzY3JpYmUgdGhlIGFsZ28gDQo+PiBmaXJzdCBh bmQgdGhlbiBnaXZlIHRoZSByZWFzb25pbmcgYnV0IHRoYXTigJlzIGEgbWF0dGVyIG9mIHdoaWNo IHN0eWxlIA0KPj4gaXMgcHJlZmVycmVk4oCmDQo+PiANCj4gDQo+Pj4gT3RoZXIgaW1wbGVtZW50 YXRpb25zIHNlZW0gdG8gaGF2ZSBnb3QgdGhlIGFsZ29yaXRobSBjb3JyZWN0IHdpdGhvdXQgbmVl ZGluZyBtb3JlIGV4cGxhbmF0aW9uIGhlcmUuIElmIHlvdSB0aGluayBpdCdzIG5vdCBjbGVhciBl bm91Z2gsIHdlIHdpbGwgcmV2aXNpdCBhZGRpbmcgbW9yZSBkZXRhaWxzIGluIG5leHQgcmV2aXNp b24uIA0KDQpJ4oCZdmUgYmVlbiBtZW50aW9uIHRoaXMgYmVjYXVzZSBJ4oCZdmUgYmVlbiBwbGF5 aW5nIGFyb3VuZCB3aXRoIHRoZSBEQ1RDUCBpbXBsZW1lbnRhdGlvbiBwcm92aWRlZCBieSBTdGFu Zm9yZCBhIHdoaWxlIGFnby4gQXQgdGhhdCBwb2ludCBvZiB0aW1lIEkgd2FzIHVzaW5nIHRoZSBE Q1RDUCBwYXBlciBhcyBhIHJlZmVyZW5jZSBhbmQgSSBmb3VuZCB0aGUgZGlhZ3JhbSBzdXBlciBo ZWxwZnVsLiBJIGtub3cgaGF2aW5nIGdyYXBoaWNzIGluIEFTQ0lJIGFydCBpcyBub3Qgc3VwZXIg bmljZSBidXQgSSBndWVzcyB0aGUgc3RhdGUgbWFjaGluZSB3b3VsZCBiZSBlYXN5IHRvIGRyYXcg KGFsc28gaXQgbWlnaHQgYmUgcG9zc2libGUgaW4gZnV0dXJlIHRvIGF0IHJlYWwgZ3JhcGhpYyB0 byBSRkPigKYpLg0KDQp7UEJdIEZhaXIgZW5vdWdoLCB3ZSB3aWxsIGFkZCB0aGUgZGlhZ3JhbSBp biB0aGUgbmV4dCByZXZpc2lvbi4NCg0KPiANCj4+IDEwKSBTZWN0aW9uIDMuMzogUXVpY2sgcXVl c3Rpb246IFdoeSBpcyB0aGUgZnJhY3Rpb24gb2YgbWFya2VkIHBhY2tldHMgY2FsbGVkIE0gaW4g dGhlIGRyYWZ0IHdoaWxlIGl04oCZcyBGIGluIHRoZSBwYXBlcj8NCj4+IA0KPiANCj4+PiBUaGVy ZSBoYXMgYmVlbiBubyBhdHRlbXB0IHRvIHJlY29uY2lsZSB0aGUgZHJhZnQgd2l0aCB0aGUgcGFw ZXIgdG8gdXNlIHRoZSBzYW1lIHRlcm1pbm9sb2d5LiANCj4gDQo+PiAxMSkgQWdhaW4gU2VjdGlv biAzLjM6IE1heWJlIG1lbnRpb24gc29tZXdoZXJlIHRoYXQgdGhlIFNBQ0sgaW5mb3JtYXRpb24g YXJlIG5vdCB1c2VkIHRvIGNhbGN1bGF0ZSBCeXRlc0Fja2VkIGJlY2F1c2UgdXN1YWxseSBpdOKA mXMgYXNzdW1lZCB0byBoYXZlIG5vIGxvc3Mgd2l0aCB0aGUgdXNlIG9mIERDVENQLiBIb3dldmVy LCBJIGd1ZXNzIGlmIGEgY2FsY3VsYXRpb24gYXMgZ2l2ZW4gaW4gUkZDNjkzNyAoUFJSKSBmb3Ig RGVsaXZlcmVkRGF0YSBpcyB1c2VkLCB0aGF0IGlzIHByb2JhYmx5IG9rYXkgYXMgd2VsbCBhbmQg c2hvdWxkIG5vdCBiZSBhIHByb2JsZW0sIHJpZ2h0Pw0KPj4gDQo+IA0KPj4+IFRoYXQncyBjb3Jy ZWN0LiBMb3NzIGhhbmRsaW5nIHdpbGwgaGF2ZSB0byBiZSBhZGRyZXNzZWQgaW4gYSBmdXR1cmUg cmV2aXNpb24uIFRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uIGRvZXMgbm90IHVzZSBTQUNLIGlu Zm9ybWF0aW9uLg0KDQpNYXliZSBqdXN0IGFkZCBvbmUgc2VudGVuY2Ugc2F5aW5nIOKAnlNBQ0sg aW5mb3JtYXRpb24gaXMgbm90IHVzZWQgYXMgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZXJlIHdpbGwg YmUgbm8gbG9zc2VzIGlmIERDVENQIGlzIHVzZWQgaW4gYSBkYXRhY2VudGVyIGZvciBhbGwgdHJh ZmZpYy7igJwgSG93ZXZlciwgaWYgeW91IGFjdHVhbGx5IHBsYW4gdG8gdXNlZCB0aGUgU0FDSyBp bmZvcm1hdGlvbiBpbiBhIGZ1dHVyZSByZXZpc2lvbiB0aGF04oCZcyBmaW5lIGFzIHdlbGwuDQoN CltQQl0gVGhpcyBpcyBUQkQgYXMgSSBtZW50aW9uZWQgYWJvdmUuIElmIERDVENQIGlzIHNlZ3Jl Z2F0ZWQgZnJvbSB0cmFkaXRpb25hbCBUQ1AsIGxvc3Mgc2hvdWxkIG9ubHkgaGFwcGVuIGluIGNh c2Ugb2Ygb3ZlcnN1YnNjcmlwdGlvbiBzdWNoIHRoYXQgYnVyc3RzIGZyb20gbXVsdGlwbGUgZmxv d3MgY2FuIG92ZXJydW4gdGhlIGJ1ZmZlciBldmVuIGJlZm9yZSB0aGUgc2VuZGVycyBjYW4gcmVh Y3QgaW4gYSByb3VuZC4gDQoNCj4gDQo+PiAxMikgRnVydGhlciBzZWN0aW9uIDMuMyBzYXlzICJ3 aGVuIHRoZSBzZW5kZXIgcmVjZWl2ZXMgYW4gaW5kaWNhdGlvbiBvZiBjb25nZXN0aW9u4oCcLiBD YW4geW91IG1heWJlIGJlIGEgbGl0dGxlIG1vcmUgc3BlY2lmeSBoZXJlIGFuZCBzYXkg4oCeaWYg dGhlIGZpcnN0IEVDRSBpcyByZWNlaXZlZCBpbiBhIFJUVOKAnCBvciBzb21ldGhpbmcgbGlrZSB0 aGlzLiBQbGVhc2UgYWxzbyBub3RlIHRoYXQgdGhpcyBiZWhhdmlvciB3aWxsIHJlZHVjZSB0aGUg Y29uZ2VzdGlvbiB3aW5kb3cgd2hlbiB0aGUgbWFya2luZyBmcmFjdGlvbiBpcyBsb3cgYmVjYXVz ZSBpZiB3aWxsIHJlZHVjZSB3aXRoIHRoZSBmaXJzdCBvY2N1cnJlbmNlIG9mIEVDRSBhbmQgYWxs IG90aGVyIEVDRSBtYXJraW5ncyB3aWxsIG9jY3VyIGluIHRoZSBmb2xsb3dpbmcgUlRUIHdoZXJl IHRoZSB3aW5kb3cgaXMgbm90IGZ1cnRoZXIgcmVkdWNlZC4gVGhlcmVmb3JlIHRoZSB3aW5kb3cg d2lsbCBvbmx5IHJlYWxseSBiZSByZWR1Y2VkIGlmIHRoZSBjb25nZXN0aW9uIHN0YXlzIGZvciBt b3JlIHRoYW4gb24gUlRUICh0aGF0IGRlbGF5cyB0aGUgcmVhY3Rpb24gdG8gY29uZ2VzdGlvbiBh IGxpdHRsZSkuIFRoYXTigJlzIG9rYXkgYmVjYXVzZSB0aGlzIGFsbG93cyB0byBub3QgcmVhY3Qg dG8gc2hvcnQtYnVyc3RzIG9mIGNvbmdlc3Rpb24uIEhvd2V2ZXIsIEkgdGhpbmsgdGhpcyBzaG91 bGQgYmUgbWVudGlvbmVkL2Rpc2N1c3NlZCBhcyBpdCBtaWdodCBub3QgYmUgb2J2aW91cyB3aGVu IHJlYWRpbmcgdGhlIGRyYWZ0Lg0KPj4gDQo+IA0KPj4+IFdlIGZpeGVkIHNvbWUgdGV4dCBoZXJl IHNvIHBsZWFzZSByZXZpZXcgYWdhaW4uDQoNCg0KSWYgSeKAmXZlIHNlZW4gdGhpcyBjb3JyZWN0 bHksIHlvdeKAmXZlIG9ubHkgYWRkZWQgdGhlIEVDRSBpbiBicmFja2V0cz8gTWF5YmUgZXZlbiBz YXkgIndoZW4gdGhlIHNlbmRlciByZWNlaXZlcyB0aGUgZmlyc3QgaW5kaWNhdGlvbiBvZiBjb25n ZXN0aW9uIChFQ0UpIHdpdGggaW4gb25lIFJUVOKAnCAuLj8NCg0KRnVydGhlciBJ4oCZZCBsaWtl IHRvIHNlZSBzb21lIG1vcmUgdGV4dCAoMS0yIHNlbnRlbmNlcykgc3RhdGluZyB3aGF0IEkgd2Fz IHNheWluZyBhYm92ZS4gV2l0aCB0aGUgcmVjZXB0aW9uIG9mIHRoZSBmaXJzdCBFQ0UsIGFscGhh IGlzIHVzdWFsbHkgbG93IChtYXliZSBldmVuIHplcm8pIGFuZCBvbmx5IGlmIHRoZSBjb25nZXN0 aW9uIHN0YXlzIGZvciBtb3JlIHRoYW4gb25lIFJUVCBpdCB3aWxsIGJlIHVwZGF0ZWQgYW5kIHJl ZHVjZWQgbW9yZS4gTWF5YmUgeW91IGFsc28gd2FudCB0byBjaGVjayB0aGlzIGluIG1lYXN1cmVt ZW50cy9zaW11bGF0aW9ucy4gV291bGQgYmUgaW50ZXJlc3RpbmcgdG8gc2VlIG1vcmUgZGF0YSBo ZXJlLiBCdXQgdGhhdOKAmXMgd2hhdCB3ZeKAmXZlIHNlZW4gd2hlbiB3ZSBkaWQgb3VyIGZpcnN0 IGV4cGVyaW1lbnRzIHdpdGggRENUQ1AuDQoNCj4gDQo+PiAxMykgTmV4dCBzZW50ZW5jZSBpcw0K Pj4gIlRodXMsIHdoZW4gbm8gc2VudCBieXRlIGV4cGVyaWVuY2VkIGNvbmdlc3Rpb24sIERDVENQ LkFscGhhIGVxdWFscyAgDQo+PiB6ZXJvLCBhbmQgY3duZCBpcyBsZWZ0IHVuY2hhbmdlZC7igJwg SSB0aGluayB0aGlzIHNlbnRlbmNlIGlzIA0KPj4gbm9uc2Vuc2ljYWwgYXMgdGhlIHByZXZpb3Vz IHNlbnRlbmNlIHNheXMgdGhlIGNvbmdlc3Rpb24gd2luZG93IHdpbGwgDQo+PiBvbmx5IGJlIHJl ZHVjZXMgaWYgY29uZ2VzdGlvbiBpcyBzaWduYWxlZOKApg0KPj4gDQo+IA0KPj4+IFdlIGZpeGVk IHNvbWUgdGV4dCBoZXJlIHNvIHBsZWFzZSByZXZpZXcgYWdhaW4uDQoNCk1heWJlIGp1c3Qgc2F5 DQrigJ5JZiBjb25nZXN0aW9uIGlzIHZlcnkgbG93IGFuZCBEQ1RDUC5BbHBoYSBlcXVhbHMgemVy bywgYW5kIGN3bmQgaXMgbGVmdCB1bmNoYW5nZWQu4oCcDQoNCkJlY2F1c2UgdGhlcmUgbXVzdCBi ZSBhdCBsZWFzdCBvbmUgRUNFIGFuZCB0aGVyZWZvcmUgaXQgY2FuIG5vdCBiZSB0aGUgY2FzZSB0 aGF0ICdubyBzZW50IGJ5dGUgZXhwZXJpZW5jZWQgY29uZ2VzdGlvbuKAmC4NCg0KPiANCj4+IDE0 KSBBcyBhbHJlYWR5IG1lbnRpb24sIHNlY3Rpb24gNSBzaG91bGQgYWxzbyBtZW50aW9uIGRlcGxv eW1lbnQgcHJvYmxlbXMgaWYgdXNlZCBpbiBwYXJhbGxlbCB0byB0cmFkaXRpb25hbCBUQ1AgY29u Z2VzdGlvbiBjb250cm9sLg0KPj4gDQo+IA0KPj4+IFllcyBhbHJlYWR5IGFkZHJlc3NlZA0KDQpU aGFua3MhDQoNCj4gDQo+PiAxNSkgU2VjdGlvbiA2IHNheXM6DQo+PiAiSG93ZXZlciwgaWYgYW4N Cj4+ICBBQ0sgcGFja2V0IGlzIGRyb3BwZWQsIGl0J3MgcG9zc2libGUgdGhhdCBhIHN1YnNlcXVl bnQgQUNLIHdpbGwgIA0KPj4gaW5kZWVkIGFja25vd2xlZGdlIGEgbWl4IG9mIENFIGFuZCBub24t Q0Ugc2VnbWVudHMu4oCcIEVpdGhlciBJIGRvbuKAmXQgDQo+PiB1bmRlcnN0YW5kIHRoaXMgc2Vu dGVuY2Ugb3IgaXQgaXMgbm90IHRydWUuIFRvIG15IHVuZGVyc3RhbmRpbmcgYW4gQUNLIGlzIGVp dGhlciBFQ0Ugc2V0IG9yIG5vdCBhbmQgdGhlcmVmb3JlIG1pZ2h0IGFjayBDRSBtYXJrcyBvciBu b3QuIEhvd2V2ZXIgaWYgZS5nLiBvbmx5IG9uZSBBQ0sgaXMgRUNFIG1hcmtlZCBhbmQgdGhpcyBh Y2sgZ2V0cyBsb3N0LCB0aGUgZm9sbG93aW5nIG5vbi1FQ0UgbWFya2VkIEFDSyB3aWxsIGFjY3Vt dWxhdGl2ZWx5IGFjayBhbGwgcGFja2V0cyBhcyBub3QtQ0UgbWFya2VkIGFuZCB0aGlzIGluZm9y bWF0aW9uIGlzIGNvbXBsZXRlbHkgbG9zdC4NCj4+IA0KPiANCj4+PiBZZXMgdGhlcmUgaXMgaW5m b3JtYXRpb24gbG9zcyBkdWUgdG8gQUNLIGxvc3MgYW5kIHRoYXQgaXMgd2hhdCBzZWN0aW9uIDYg aXMgYXR0ZW1wdGluZyB0byBleHBsYWluLiBEbyB5b3UgaGF2ZSBhbnkgc3VnZ2VzdGlvbnMgZm9y IGJldHRlciB0ZXh0Pw0KDQoNCknigJlkIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBp bnN0ZWFkIHRvIG1ha2UgaXQgbW9yZSBjbGVhcjoNCg0K4oCeSG93ZXZlciwgaWYgYW4gQUNLIGlz IGRyb3BwZWQgYW5kIHRoZSBsb3N0IEFDSyB3YXMgY2FycnlpbmcgYSBkaWZmZXJlbnQgbWFya2lu ZyB0aGF0IHRoZSBzdWJzZXF1ZW50IGFjY3VtdWxhdGl2ZSBBQ0ssIHRoZSBtYXJraW5nIGluZm9y bWF0aW9uIHdpbGwgYmUgbG9zdC7igJwNCg0KDQoNCj4gDQo+PiBUaGFua3MgYWdhaW4gZm9yIHdy aXRpbmcgdGhpcyBkb2N1bWVudC4gSSBob3BlIGl0IGNhbiBiZSBwdWJsaXNoZWQgc29vbiENCj4+ IA0KPj4gTWlyamENCj4+IA0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiB0Y3BtIG1haWxpbmcgbGlzdA0KPj4gdGNwbUBpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB0Y3Bt IG1haWxpbmcgbGlzdA0KPiB0Y3BtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGNwbQ0KDQo= From nobody Sun Jul 19 20:43:35 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98A31B2F42 for ; Sun, 19 Jul 2015 20:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oOZ0YfXtP1Xl for ; Sun, 19 Jul 2015 20:43:32 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565B21B2F41 for ; Sun, 19 Jul 2015 20:43:31 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: acceptlanguage:Content-Type:Content-Transfer-Encoding: MIME-Version:Return-Path; b=y9cHtQl6DMOxbtU04JBABRZ9omtJVfkKfYMaptotUuCjlQDaw62gOCrw Nak9FG7MLY7OnijwBMFJh9CNPJE6mIbApI1Wm2i79zxaL3pM8Xu4/ud+r nE1kjIGpNaNJF5i8QV74rUFpJvCHMRvDMJxUD+cWMIeSyciYj8pqtNO18 w=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1437363813; x=1468899813; h=from:to:cc:date:subject:message-id: content-transfer-encoding:mime-version; bh=pKqtdVRaFPM9DI53zFt7rw8ljRS+ieVDnTu9g5/VZqw=; b=ZSLNUMP1YWYqJbB21X8/jg7jjN30Gcop3vYZexdRMjKyM9ECDiFgBd/R Is0u0hm8K++XJkqoxUqRBBwNnHmLZCwcHPc0gz3JgpxxExZAC9NqhjvDU kQ+BPCeZQIfJuAphaAFcgFzS4pdMqKw0ptiNE8uHUfr81wTwEKC3xDeuf k=; X-LoopCount0: from 10.170.28.41 X-IronPort-AV: E=Sophos;i="5.15,506,1432616400"; d="scan'208";a="708115556" From: To: Date: Mon, 20 Jul 2015 09:13:05 +0530 Thread-Topic: New Draft for Lively TCP Connection Failure Notifications Thread-Index: AQHQwp4vZldQ/D07EEKTTC/hML1jEw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Shathish_Venkatesan@Dell.com Subject: [tcpm] New Draft for Lively TCP Connection Failure Notifications X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 03:43:33 -0000 Hi All, We have proposed a new draft on Lively TCP Connection Failure Notifications= .=20 Name: draft-aravind-tcpm-lively-failure-notifications Revision: 00 Title: Lively TCP Connection Failure Notifications Document date: 2015-07-20 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-aravind-tcpm-liv= ely-failure-notifications-00.txt Status: https://datatracker.ietf.org/doc/draft-aravind-tcpm-lively-= failure-notifications/ Htmlized: https://tools.ietf.org/html/draft-aravind-tcpm-lively-failu= re-notifications-00 Abstract: This document proposes a mechanism to provide lively notifications of TCP Connection Failures in Network. We would love to hear your reviews and comments. Cheers, S. Aravind Prasad= From nobody Mon Jul 20 00:08:56 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C771A00D8 for ; Mon, 20 Jul 2015 00:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 lu8AOFGHLo-m for ; Mon, 20 Jul 2015 00:08:54 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23851A00D4 for ; Mon, 20 Jul 2015 00:08:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,507,1432623600"; d="scan'208";a="54923606" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx142-out.netapp.com with ESMTP; 20 Jul 2015 00:03:33 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 20 Jul 2015 00:03:33 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::1438:d6b8:afb:4959%21]) with mapi id 15.00.1076.000; Mon, 20 Jul 2015 00:03:33 -0700 From: "Scheffenegger, Richard" To: "Aravind_Sridharan@Dell.com" , "tcpm@ietf.org" Thread-Topic: New Draft for Lively TCP Connection Failure Notifications Thread-Index: AQHQwp4vZldQ/D07EEKTTC/hML1jE53j7qTQ Date: Mon, 20 Jul 2015 07:03:32 +0000 Message-ID: <0952744b9aa24cba87938f84410ab44f@hioexcmbx05-prd.hq.netapp.com> References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Shathish_Venkatesan@Dell.com" Subject: Re: [tcpm] New Draft for Lively TCP Connection Failure Notifications X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 07:08:55 -0000 Hi, Isn't this the reason for ICMP (Host) unreachable?=20 Why terminate the TCP sessions - reading the text, it appears that the topo= logy below assumes L3 forwarding devices; Shouldn't there be sufficient red= undancy in the regular case to re-route around failed links? Best regards, Richard From nobody Mon Jul 20 01:04:30 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94C71A037B for ; Mon, 20 Jul 2015 01:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CuYMLl0m_sMv for ; Mon, 20 Jul 2015 01:04:27 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 2353C1A0364 for ; Mon, 20 Jul 2015 01:04:27 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 433AB1BCACD2F for ; Mon, 20 Jul 2015 08:04:23 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6K84KSW004062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jul 2015 10:04:25 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 10:04:23 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org Extensions" Thread-Topic: Publication has been requested for draft-ietf-tcpm-rtorestart-08 Thread-Index: AQHQwsIR0csKd2NemkyQqbXyEz78QZ3j/5nQ Date: Mon, 20 Jul 2015 08:04:22 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48433127@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [tcpm] FW: Publication has been requested for draft-ietf-tcpm-rtorestart-08 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 08:04:28 -0000 RllJDQoNCk1pY2hhZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pY2hh ZWwgU2NoYXJmIFttYWlsdG86bWljaGFlbC5zY2hhcmZAYWxjYXRlbC1sdWNlbnQuY29tXSANClNl bnQ6IE1vbmRheSwgSnVseSAyMCwgMjAxNSAxMDowMCBBTQ0KVG86IG1scy5pZXRmQGdtYWlsLmNv bQ0KQ2M6IHRjcG0tY2hhaXJzQHRvb2xzLmlldGYub3JnOyBpZXNnLXNlY3JldGFyeUBpZXRmLm9y ZzsgU2NoYXJmLCBNaWNoYWVsIChNaWNoYWVsKQ0KU3ViamVjdDogUHVibGljYXRpb24gaGFzIGJl ZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1pZXRmLXRjcG0tcnRvcmVzdGFydC0wOA0KDQpNaWNoYWVs IFNjaGFyZiBoYXMgcmVxdWVzdGVkIHB1YmxpY2F0aW9uIG9mIGRyYWZ0LWlldGYtdGNwbS1ydG9y ZXN0YXJ0LTA4IGFzIEV4cGVyaW1lbnRhbCBvbiBiZWhhbGYgb2YgdGhlIFRDUE0gd29ya2luZyBn cm91cC4NCg0KUGxlYXNlIHZlcmlmeSB0aGUgZG9jdW1lbnQncyBzdGF0ZSBhdCBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRjcG0tcnRvcmVzdGFydC8NCg0K From nobody Mon Jul 20 01:12:25 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAC61A0404 for ; Mon, 20 Jul 2015 01:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 dsEJmfrFXM96 for ; Mon, 20 Jul 2015 01:12:08 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id A16291A037F for ; Mon, 20 Jul 2015 01:12:07 -0700 (PDT) Received: from dhcp-b0e3.meeting.ietf.org (31.133.176.227) by jenni1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 5511FF58079CC7AB for tcpm@ietf.org; Mon, 20 Jul 2015 11:12:06 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 20 Jul 2015 10:12:08 +0200 To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [tcpm] Comments on draft-zimmermann-tcpm-echo-option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 08:12:10 -0000 Hi, I gave a quick look at draft-zimmermann-tcpm-echo-option-00, so here are = a few thoughts (as individual IETF participant, of course). * it would be nice to have a few examples in the intro about how this = could be used. I gather you are planning a separate document for = spurious timeouts, and separate document is good, but some motivating = examples also here would not harm. * It is required that at most one Echo option is included per segment. = Is there any reason to limit the number of options? I couldn=92t = immediately see why having multiple instances of the option would cause = problems, or could it? * "A TCP sender MAY send an empty TCP Echo option with Length=3D2 on the = SYN=85=94 =97 this would not have to be limited just to SYNs, right? = Can=92t think of any useful reason for sending empty echo pings = mid-connection (some sort of diagnostics, perhaps?), but can=92t see any = reason to disallow that either. Also, it might be helpful clarification = to note that when ExID is used, length will be different. * "it is NOT RECOMMENDED to send easily decipherable data in the clear = as data in the TCP Echo option=85=94 =97 I don=92t think this = recommendation is necessary. Depends on the intended use, I guess. There = are other ways for encrypting TCP header when that is needed. Will send some additional editorial nits to authors directly... - Pasi From nobody Mon Jul 20 02:50:32 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F651A1A34 for ; Mon, 20 Jul 2015 02:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GI6LGbh00M5f for ; Mon, 20 Jul 2015 02:50:29 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6ED21A1A55 for ; Mon, 20 Jul 2015 02:50:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,507,1432623600"; d="scan'208";a="57810434" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx141-out.netapp.com with ESMTP; 20 Jul 2015 02:49:29 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 20 Jul 2015 02:49:29 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::1438:d6b8:afb:4959%21]) with mapi id 15.00.1076.000; Mon, 20 Jul 2015 02:49:29 -0700 From: "Scheffenegger, Richard" To: Pasi Sarolahti , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] Comments on draft-zimmermann-tcpm-echo-option Thread-Index: AQHQwsPSkjkK11efxkqPFxzwQJzibp3kGyJw Date: Mon, 20 Jul 2015 09:49:28 +0000 Message-ID: <553710a93aa94ff19a5fb28eac42168a@hioexcmbx05-prd.hq.netapp.com> References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 09:50:31 -0000 Hi, > * it would be nice to have a few examples in the intro about how this > could be used. I gather you are planning a separate document for spurious > timeouts, and separate document is good, but some motivating examples als= o > here would not harm. Certainly; SYN Cookies (drafted by Bob) is another example that needs the d= ifferent semantics. > * It is required that at most one Echo option is included per segment. Is > there any reason to limit the number of options? I couldn't immediately > see why having multiple instances of the option would cause problems, or > could it? Yes, there are issues with that, and they are plentiful. The easy way out w= as to side-step this, and only allow (just as with every other TCP option s= o far) only a single instance of the option, and only reflect the option mo= st recently observed by the receiver. Issues include, but are not limited to o) semantics o) ordering o) meddleboxes o) receiver state o) implementation issues > * "A TCP sender MAY send an empty TCP Echo option with Length=3D2 on the > SYN..." - this would not have to be limited just to SYNs, right? Can't th= ink > of any useful reason for sending empty echo pings mid-connection (some > sort of diagnostics, perhaps?), but can't see any reason to disallow that > either. Also, it might be helpful clarification to note that when ExID is > used, length will be different. We did not want this document to specify a full in-session negotiation prot= ocol - as that problem has been discussed on the list earlier, it's a hard = issue and beyond the scope of what we want to achive with this draft. > * "it is NOT RECOMMENDED to send easily decipherable data in the clear as > data in the TCP Echo option..." - I don't think this recommendation is > necessary. Depends on the intended use, I guess. There are other ways for > encrypting TCP header when that is needed. Even when only the receiver can decode (or make educated guesses about) the= contents of a field that is supposed to be immutable, it has shown issues = in the past (reference early cubic implementations, that could be persuaded= to give very large shares of bandwidth to a receiver that slightly modifie= s the TCP timestamp echo value). We also believe that this recommendation (= not even a SHOULD or MUST) is in-line with RFC7258.=20 =20 > Will send some additional editorial nits to authors directly... Thanks, we'll fix these in the next revision. Best regards, Richard From nobody Mon Jul 20 03:41:35 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61931A1B25 for ; Mon, 20 Jul 2015 03:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 cNJKXgT5hxvy for ; Mon, 20 Jul 2015 03:41:25 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.229]) by ietfa.amsl.com (Postfix) with ESMTP id 18EEF1A1B2A for ; Mon, 20 Jul 2015 03:41:25 -0700 (PDT) Received: from dhcp-8902.meeting.ietf.org (31.133.139.2) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 552B87C905178615; Mon, 20 Jul 2015 13:41:21 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <553710a93aa94ff19a5fb28eac42168a@hioexcmbx05-prd.hq.netapp.com> Date: Mon, 20 Jul 2015 12:41:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <118DE6D7-6863-4859-8A25-1CA086B3002C@iki.fi> References: <553710a93aa94ff19a5fb28eac42168a@hioexcmbx05-prd.hq.netapp.com> To: Richard Scheffenegger X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 10:41:29 -0000 On 20 Jul 2015, at 11:49, Scheffenegger, Richard wrote: >> * It is required that at most one Echo option is included per = segment. Is >> there any reason to limit the number of options? I couldn't = immediately >> see why having multiple instances of the option would cause problems, = or >> could it? >=20 > Yes, there are issues with that, and they are plentiful. The easy way = out was to side-step this, and only allow (just as with every other TCP = option so far) only a single instance of the option, and only reflect = the option most recently observed by the receiver. >=20 > Issues include, but are not limited to > o) semantics > o) ordering > o) meddleboxes > o) receiver state > o) implementation issues Ok. I thought that =93just echo what you saw in latest segment=94 might = have been sufficient, perhaps in the same order than in incoming packet. = Middleboxes might have issues even with single option. So if there were multiple different uses for this mechanism, one would = need to make a choice, or bundle the data somehow. The semantics of what to echo seems difficult question even with single = option: if the first segment includes the option and second does not, = and ACK is sent only after the second segment, is it correct to echo the = option from the first segment? This is pretty difficult to answer = without knowing what the intended uses are. It could be that different = uses need different semantics. >> * "A TCP sender MAY send an empty TCP Echo option with Length=3D2 on = the >> SYN..." - this would not have to be limited just to SYNs, right? = Can't think >> of any useful reason for sending empty echo pings mid-connection = (some >> sort of diagnostics, perhaps?), but can't see any reason to disallow = that >> either. Also, it might be helpful clarification to note that when = ExID is >> used, length will be different. >=20 > We did not want this document to specify a full in-session negotiation = protocol - as that problem has been discussed on the list earlier, it's = a hard issue and beyond the scope of what we want to achive with this = draft. I did not propose in-session negation, but only asked if it is possible = to send a zero-payload Echo option? Might be silly, but does not seem = harmful. Now that I better read the draft, it seems to allow this in = earlier text, which is ok, I guess. >> * "it is NOT RECOMMENDED to send easily decipherable data in the = clear as >> data in the TCP Echo option..." - I don't think this recommendation = is >> necessary. Depends on the intended use, I guess. There are other ways = for >> encrypting TCP header when that is needed. >=20 > Even when only the receiver can decode (or make educated guesses = about) the contents of a field that is supposed to be immutable, it has = shown issues in the past (reference early cubic implementations, that = could be persuaded to give very large shares of bandwidth to a receiver = that slightly modifies the TCP timestamp echo value). We also believe = that this recommendation (not even a SHOULD or MUST) is in-line with = RFC7258.=20 Fine, it may be necessary to protect against cheating receivers, = depending on what the option is used for. Ideally RFC 7258 should be = addressed with a common solution so that one does not need to obfuscate = each protocol field or option separately. But as you say, the language = here is not too restrictive. - Pasi From nobody Mon Jul 20 04:20:06 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92391A1EE8 for ; Mon, 20 Jul 2015 04:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 LyUqK0BS-EP8 for ; Mon, 20 Jul 2015 04:20:03 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (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 6B68B1A1BA9 for ; Mon, 20 Jul 2015 04:20:03 -0700 (PDT) Received: by wibud3 with SMTP id ud3so93751103wib.0 for ; Mon, 20 Jul 2015 04:20:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=EhJEQB6HHfmdRTL/RVpYQw+y6hVQC/c3MUxMh2ob8u8=; b=NiC6ELwAT7tByW3hbjEQrrf+9/RZQPK5+KnC8wDixw4A3OVkwe128pLhnSnIw6LD1j aPJAoVrlmGVfw48BEHgzQjy4bpV3H8hbnDYGCn60luKzMgicwLszHf5U2t0QetD2yMDl KLr7EfM60KBmBj3/Yhcs6qefzUi8rRbdRasE38GTZ0aRX1Emu/Sc1beYbMXes7cC1YGi 68/N0t6bYbFIaVO1QTLv+1PP+XfmalnuV6766U2S4oJ6kFwoT+Ocv1Qx7ERdeBXaDEeH kolaTQFDZbQTYJWZoNXy1qYhu/fSNnKjLHrP3DAaUAB4aVzzVzjRb4V2pjP9MBhyavEq RZoQ== X-Gm-Message-State: ALoCoQmUMnlpZ67veI396tBAq8R8OYb7fGBm49vwsi+B2ByGsrNHT1DzTLtztX9GfEl5ZVBjqESr MIME-Version: 1.0 X-Received: by 10.180.80.138 with SMTP id r10mr20079069wix.18.1437391201991; Mon, 20 Jul 2015 04:20:01 -0700 (PDT) Received: by 10.194.23.102 with HTTP; Mon, 20 Jul 2015 04:20:01 -0700 (PDT) Date: Mon, 20 Jul 2015 13:20:01 +0200 Message-ID: From: Olivier Bonaventure To: "tcpm@ietf.org (tcpm@ietf.org)" Content-Type: multipart/alternative; boundary=f46d0444038aff9bb3051b4cb724 Archived-At: Subject: [tcpm] Analysis of the TCP EDO option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:20:05 -0000 --f46d0444038aff9bb3051b4cb724 Content-Type: text/plain; charset=UTF-8 Hello, Last week after discussion with the TCPM chairs, we wrote a quick draft that analyses the EDO proposal under discussion.The draft has now been posted, see below Olivier A new version of I-D, draft-bonaventure-tcpm-edo-analysis-00.txt has been successfully submitted by Olivier Bonaventure and posted to the IETF repository. Name: draft-bonaventure-tcpm-edo-analysis Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-bonaventure-tcpm-edo-analysis-00.txt Status: https://datatracker.ietf.org/doc/draft-bonaventure-tcpm-edo-analysis/ Htmlized: https://tools.ietf.org/html/draft-bonaventure-tcpm-edo-analysis-00 Abstract: This document analyses how the proposed TCP EDO option copes with various types of middlebox interference. --f46d0444038aff9bb3051b4cb724 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Last week after discu= ssion with the TCPM chairs, we wrote a quick draft that analyses the EDO pr= oposal under discussion.The draft has now been posted, see below
=

Olivier

A new versio= n of I-D, draft-bonaventure-tcpm-edo-analysis-00.txt
has been suc= cessfully submitted by Olivier Bonaventure and posted to the
IETF= repository.

Name: draft-bonaventure-tcpm-edo-analysis
Pages: 20

Abstract:
=C2=A0 This document analys= es how the proposed TCP EDO option copes with
=C2=A0 various type= s of middlebox interference.

--f46d0444038aff9bb3051b4cb724-- From nobody Mon Jul 20 09:47:30 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1C41ACE55 for ; Mon, 20 Jul 2015 09:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EIVnJIPzLAUw for ; Mon, 20 Jul 2015 09:47:28 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 725831ACE58 for ; Mon, 20 Jul 2015 09:46:54 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id D7EEA1ECB2EC3; Mon, 20 Jul 2015 16:46:49 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6KGkqmO031882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jul 2015 18:46:52 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 18:46:52 +0200 From: "Scharf, Michael (Michael)" To: Wesley Eddy Thread-Topic: Section 3.7.1 draft-ietf-tcpm-rfc793bis Thread-Index: AdDDC6iQ/bVpxgdkStiWI5Utphxftg== Date: Mon, 20 Jul 2015 16:46:51 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48433CE4@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: [tcpm] Section 3.7.1 draft-ietf-tcpm-rfc793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 16:47:29 -0000 Hi Wes, A small nit regarding draft-ietf-tcpm-rfc793bis-00 page 30: If an MSS option is not received at connection setup, TCP MUST assume a default send MSS of 536 (576-40) for IPv4 or 1220 (1280 - 40) for IPv6. In my understanding, the IPv6 value of 1220 is correct, but probably the ma= th should be changed into 1280 - 40 - 20... (I just CC TCPM in order to encourage further reviews of this section.) Michael From nobody Mon Jul 20 10:03:25 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590501B2C64 for ; Mon, 20 Jul 2015 10:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nlqo1Q_TcN2I for ; Mon, 20 Jul 2015 10:03:23 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EAA51B2C5D for ; Mon, 20 Jul 2015 10:03:23 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6KH2Plr009040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 10:02:26 -0700 (PDT) Message-ID: <55AD29A1.5060506@isi.edu> Date: Mon, 20 Jul 2015 10:02:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Olivier Bonaventure , "tcpm@ietf.org (tcpm@ietf.org)" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [tcpm] Analysis of the TCP EDO option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 17:03:24 -0000 Oliver, This issue is already covered in Section 7 of draft-ietf-tcpm-tcp-edo-03, excepting only: 1. blindly reflecting new options This is a hazard of all new options, and should be covered by a single test option rather than being built into every new option. 2. how to handle detection of middlebox tampering of Segment_Length the doc already notes that such events should be noticed the simplest solution would be to stop using EDO in the other direction, and to change the rule about what to do when non-EDO segments are received, e.g., to make them cause EDO to be dropped on the connection and the user to be signalled These both could have been handled with an email, as I have done. Joe On 7/20/2015 4:20 AM, Olivier Bonaventure wrote: > Hello, > > Last week after discussion with the TCPM chairs, we wrote a quick draft > that analyses the EDO proposal under discussion.The draft has now been > posted, see below > > > Olivier > > A new version of I-D, draft-bonaventure-tcpm-edo-analysis-00.txt > has been successfully submitted by Olivier Bonaventure and posted to the > IETF repository. > > Name:draft-bonaventure-tcpm-edo-analysis > Pages:20 > URL: > https://www.ietf.org/internet-drafts/draft-bonaventure-tcpm-edo-analysis-00.txt > Status: > https://datatracker.ietf.org/doc/draft-bonaventure-tcpm-edo-analysis/ > Htmlized: https://tools.ietf.org/html/draft-bonaventure-tcpm-edo-analysis-00 > > > Abstract: > This document analyses how the proposed TCP EDO option copes with > various types of middlebox interference. > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Jul 20 10:05:54 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998B61AD09B for ; Mon, 20 Jul 2015 10:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MBJZF5L3YfBV for ; Mon, 20 Jul 2015 10:05:52 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8435A1B2C72 for ; Mon, 20 Jul 2015 10:05:40 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6KH50DX009457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 10:05:01 -0700 (PDT) Message-ID: <55AD2A3C.9070407@isi.edu> Date: Mon, 20 Jul 2015 10:05:00 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , Wesley Eddy References: <655C07320163294895BBADA28372AF5D48433CE4@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48433CE4@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org Extensions" , touch@isi.edu Subject: Re: [tcpm] Section 3.7.1 draft-ietf-tcpm-rfc793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 17:05:53 -0000 Michael, On 7/20/2015 9:46 AM, Scharf, Michael (Michael) wrote: > Hi Wes, > > A small nit regarding draft-ietf-tcpm-rfc793bis-00 page 30: > > If an MSS option is not received at connection setup, TCP MUST assume > a default send MSS of 536 (576-40) for IPv4 or 1220 (1280 - 40) for > IPv6. > > In my understanding, the IPv6 value of 1220 is correct, but probably the math should be changed into 1280 - 40 - 20... The answer lies in RFC 6691, and yes, you should subtract the fixed portions of the IP and TCP headers. Joe From nobody Mon Jul 20 10:37:25 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD701B2D16 for ; Mon, 20 Jul 2015 10:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 QpP4O5nEcGto for ; Mon, 20 Jul 2015 10:37:23 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 F367C1B2D0F for ; Mon, 20 Jul 2015 10:37:22 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so98193984wib.0 for ; Mon, 20 Jul 2015 10:37:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Sb5q/4Lwlg9h80Xg1eNLShMp3CucaJt1JfUVIHBCTx4=; b=ahhqKhA2ziaBSodsSn3+J10ehB+h6GdtEAkvdYJd/SIF6PfGEfKG1R7OUrDM2Oi+FG Sa2pY28Kk7O9LhgnpIFZhjmTysrmF7uJGvU6fs1fBGuHJshJ3Wz+bdwilJHr/L35mmr9 zKYMDJkzHEWrSXArJDQyHhVnJvOgQh0fAv1jFt7gO2ltNCDsSE1sn3ofIRdN3WzrSoN1 dlhu8wgS0AKsDkCI4cccWfb+6U/fWxuHmLnK9ML3BFlji3H5eSPxEwP8If4c2CAeAQae UVJmFnNZBWjWYsqbAWrnK3/oZON9plr+k6XwBEctabKevOcJI+q2OHCbqOX3iWobskCa RlxA== X-Gm-Message-State: ALoCoQmrperXGEEU28sfsIi2jV9h4FDi+KCems8RZVfrpMuRX20ABGldzaVF9j9XveLi8RGunYij MIME-Version: 1.0 X-Received: by 10.194.176.201 with SMTP id ck9mr58071772wjc.108.1437413841615; Mon, 20 Jul 2015 10:37:21 -0700 (PDT) Received: by 10.194.23.102 with HTTP; Mon, 20 Jul 2015 10:37:21 -0700 (PDT) In-Reply-To: <55AD29A1.5060506@isi.edu> References: <55AD29A1.5060506@isi.edu> Date: Mon, 20 Jul 2015 19:37:21 +0200 Message-ID: From: Olivier Bonaventure To: Joe Touch Content-Type: multipart/alternative; boundary=089e013d1eb46cd195051b51fd4f Archived-At: Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] Analysis of the TCP EDO option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 17:37:24 -0000 --089e013d1eb46cd195051b51fd4f Content-Type: text/plain; charset=UTF-8 > > Joe, > > This issue is already covered in Section 7 of > draft-ietf-tcpm-tcp-edo-03, excepting only: > > 1. blindly reflecting new options > This is a hazard of all new options, and should be covered > by a single test option rather than being built into every > new option > I remember that this was solved in the previous version of the draft. This is not a severe limitation, but it is worth being mentioned in the document. > 2. how to handle detection of middlebox tampering of Segment_Length > the doc already notes that such events should be noticed > When reading the draft, I could not find how a receiver had to really react upon reception of such an invalid segment. It should be better explained in the draft. > > the simplest solution would be to stop using EDO in the > other direction, and to change the rule about what to do > when non-EDO segments are received, e.g., to make them > cause EDO to be dropped on the connection and the user to be > signalled > This solution should be documented precisely in the draft so that implementors know what is the fallback mechanism. In the current EDO, there is no feedback from the receiver to the sender and this can create problems where the two hosts may stop to communicate. This fallback mechanism is key to preserve the connectivity in case of middlebox interference > These both could have been handled with an email, as I have done. > If the TCPM working group wants to have a safe mechanism to extend the TCP header, then this mechanism must be evaluated in details. Our draft is a contribution in the validation/improvement of EDO. We have also spent quite some time to implement the proposed EDO in tracebox so that we could start measurements to verify how EDO passes through existing middleboxes. I think that such an experiment makes sense before adopting any solution to extend the TCP header. Such an extension must be safe before it can be deployed. Olivier --089e013d1eb46cd195051b51fd4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Joe,

This issue is already covered in Section 7 of
draft-ietf-tcpm-tcp-edo-03, excepting only:

1. blindly reflecting new options
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is a hazard of all new options, and should= be covered
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by a single test option rather than being built= into every
=C2=A0 =C2=A0 =C2=A0 =C2=A0 new option

= I remember that this was solved in the previous version of the draft. This = is not a severe limitation, but it is worth being mentioned in the document= .
=C2=A0
2. how to handle detection of middlebox tampering of Segment_Length
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the doc already notes that such events should b= e noticed

When reading the draft, I cou= ld not find how a receiver had to really react upon reception of such an in= valid segment. It should be better explained in the draft.
=C2=A0=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the simplest solution would be to stop using ED= O in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other direction, and to change the rule about w= hat to do
=C2=A0 =C2=A0 =C2=A0 =C2=A0 when non-EDO segments are received, e.g., to ma= ke them
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cause EDO to be dropped on the connection and t= he user to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 signalled

T= his solution should be documented precisely in the draft so that implemento= rs know what is the fallback mechanism. In the current EDO, there is no fee= dback from the receiver to the sender and this can create problems where th= e two hosts may stop to communicate. This fallback mechanism is key to pres= erve the connectivity in case of middlebox interference
=C2=A0
These both could have been handled with an email, as I have done.

If the TCPM working group wants to have a safe m= echanism to extend the TCP header, then this mechanism must be evaluated in= details. Our draft is a contribution in the validation/improvement of EDO.= We have also spent quite some time to implement the proposed EDO in traceb= ox so that we could start measurements to verify how EDO passes through exi= sting middleboxes. I think that such an experiment makes sense before adopt= ing any solution to extend the TCP header. Such an extension must be safe b= efore it can be deployed.

Olivier=C2=A0
--089e013d1eb46cd195051b51fd4f-- From nobody Mon Jul 20 10:46:23 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E0C1B2D1F for ; Mon, 20 Jul 2015 10:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 G3XMC1hZGSzJ for ; Mon, 20 Jul 2015 10:46:20 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701DE1B2A2A for ; Mon, 20 Jul 2015 10:46:20 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6KHjQrN015372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 10:45:26 -0700 (PDT) Message-ID: <55AD33B6.9060907@isi.edu> Date: Mon, 20 Jul 2015 10:45:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Olivier Bonaventure References: <55AD29A1.5060506@isi.edu> 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: Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" , touch@isi.edu Subject: Re: [tcpm] Analysis of the TCP EDO option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 17:46:22 -0000 On 7/20/2015 10:37 AM, Olivier Bonaventure wrote: > Joe, > > This issue is already covered in Section 7 of > draft-ietf-tcpm-tcp-edo-03, excepting only: > > 1. blindly reflecting new options > This is a hazard of all new options, and should be covered > by a single test option rather than being built into every > new option > > > I remember that this was solved in the previous version of the draft. > This is not a severe limitation, but it is worth being mentioned in the > document. Agreed. > 2. how to handle detection of middlebox tampering of Segment_Length > the doc already notes that such events should be noticed > > > When reading the draft, I could not find how a receiver had to really > react upon reception of such an invalid segment. It should be better > explained in the draft. Handling of segments with incorrect Segment_Length is explained in Section 5.3. > the simplest solution would be to stop using EDO in the > other direction, and to change the rule about what to do > when non-EDO segments are received, e.g., to make them > cause EDO to be dropped on the connection and the user to be > signalled > > This solution should be documented precisely in the draft so that > implementors know what is the fallback mechanism. It would be a change to the document, but could be a reasonable one. > In the current EDO, > there is no feedback from the receiver to the sender and this can create > problems where the two hosts may stop to communicate. This fallback > mechanism is key to preserve the connectivity in case of middlebox > interference Agreed. > These both could have been handled with an email, as I have done. > > If the TCPM working group wants to have a safe mechanism to extend the > TCP header, then this mechanism must be evaluated in details. Our draft > is a contribution in the validation/improvement of EDO. It could (and IMO should) have been done with an email. I'm fairly responsive to emails posted where they should be. No, TCPM doesn't track vague messages announcing a long set of documents to other WGs (MPTCP, in particular, where these issues originated). If you're discussing a WG doc, it's always more effective to do so on that WG's mailing list. > We have also > spent quite some time to implement the proposed EDO in tracebox so that > we could start measurements to verify how EDO passes through existing > middleboxes. I think that such an experiment makes sense before adopting > any solution to extend the TCP header. Such an extension must be safe > before it can be deployed. Certainly, but we also need more than anecdotal evidence. There's always a middlebox somewhere that does something odd. We cannot possibly design protocol extensions that pass though every possible contortion of what every possible middlebox will do. IMO, when you find something like this, you really ought to try to also find out where the box is and post those details. Bugs need to be fixed, not danced around. Joe From nobody Tue Jul 21 02:07:58 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CBF1B2C1F for ; Tue, 21 Jul 2015 02:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FYUrc8aMLeM4 for ; Tue, 21 Jul 2015 02:07:54 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF181B2C0C for ; Tue, 21 Jul 2015 02:07:53 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator: x-tituslabs-classifications-30:x-titus-version: x-tituslabs-classificationhash-30:x-titusconfig: acceptlanguage:Content-Type:MIME-Version:Return-Path; b=LgReUrivF9q6QdxyZZxlkM62gNHhwkiEECq6Pd3qu9zlzGxQVLl1KbP4 PGZ+r1Xk/KYHLh8d//4JoJK5jsn38txVZ+baCo3XHOFY4RAlPtf5zpTxM c//Y6XelyfL1da6Z3NSh7lWyg5dLoQzlvDmzQDLVRsEK8NzIn01ZQ35Cw Q=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1437469673; x=1469005673; h=from:to:cc:date:subject:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=CLzVo6+VssL3YdIISxNAAncLHLs9CAb3VKBdrYoyPiI=; b=LYnlizRYUKajSK/TYsN5SyYSkQLivqysdPJ0qr5NiTMQxoZWfRerKVJ4 0RJi2RvwzSPPJb6IFBzYVKC6+gQvO0uXfM0oYjndZ9z+VFhfqYgPYHvX9 oe4nv1Rz5TrXTbbAkWlF1nLHNveeWBo5J6XmIYF6Ko0gi7r6eCJ2177Zm o=; X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="5.15,514,1432616400"; d="scan'208,217";a="680083175" From: To: , Date: Tue, 21 Jul 2015 14:35:26 +0530 Thread-Topic: New Draft for Lively TCP Connection Failure Notifications Thread-Index: AQHQwp4vZldQ/D07EEKTTC/hML1jE53j7qTQgAG0VFA= Message-ID: References: <0952744b9aa24cba87938f84410ab44f@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: <0952744b9aa24cba87938f84410ab44f@hioexcmbx05-prd.hq.netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Dell;Classification=Internal Use;External=No;Sublabels=; x-titus-version: 3.5.29.3 x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IuYkznEmM2/5Wz7BuRIannSoIJODWGWpSpvkC1Tsr+Y1TfpAvhnen+ZUCJLHgFh+88EPey3ZPSoCprlWW089Pp6TMSj83RvPjxInJKq6GOlqjIZebJmt232tpzOwVqIX9PaHFaCBdKfsz68lRW99x+SHjgoybn0W4IeYiMcOEjKl9zCEVoWrOZolHNkSYZ9mdlba1w1jXVAjnGg24MFi1LHOBaCmpckrT/uOrjOPsCKVHpJxHm7yiTFNlHdve90Piw== x-titusconfig: 1.4APJ acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D5A6F3355F664C40AFB65BB1277D8D45040E59FFDDMAAX7MCDC101A_" MIME-Version: 1.0 Archived-At: Cc: Shathish_Venkatesan@Dell.com Subject: Re: [tcpm] New Draft for Lively TCP Connection Failure Notifications X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 09:07:57 -0000 --_000_D5A6F3355F664C40AFB65BB1277D8D45040E59FFDDMAAX7MCDC101A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dell - Internal Use - Confidential Hi, Thanks for the review comment. Isn't this the reason for ICMP (Host) unreachable? Actually, only for active TCP sessions, ICMP unreachable message would be r= eceived. In case of Inactive TCP sessions, there is no possibility of recei= ving ICMP message. Our proposal is more applicable to Inactive TCP sessions= . Further, according to RFC 1122 Section 4.2.3.9 - TCP must not close the c= onnection based on ICMP Destination unreachable (codes 0,1,5) messages. Hen= ce, the core idea is to proactively track the loss of network level connec= tivity to a subnet and inform the Server regarding the same. Why terminate the TCP sessions - reading the text, it appears that the top= ology below assumes L3 forwarding devices; Shouldn't there be sufficient re= dundancy in the regular case to re-route around failed links? Actually, our proposed mechanism is more suitable at TORs which are the ent= ry points to Network/Internet for Servers. In TORs, when the network connec= tivity to a particular subnet is lost (during network failures, routing pro= tocols in network would converge and update the TOR's IP Table), it basical= ly indicates loss of network connectivity to TCP sessions established at Se= rver. Hence, in the case of inactive TCP sessions, the TOR can proactively = initiate a TCP RST Message to Server informing it to tear down the correspo= nding session so that unnecessary wastage of kernel resources could be avoi= ded. Kindly let us know your comments. Thanks, S. Aravind Prasad -----Original Message----- From: Scheffenegger, Richard [mailto:rs@netapp.com] Sent: Monday, July 20, 2015 12:34 PM To: Sridharan, Aravind; tcpm@ietf.org Cc: Venkatesan, Shathish Subject: RE: New Draft for Lively TCP Connection Failure Notifications Hi, Isn't this the reason for ICMP (Host) unreachable? Why terminate the TCP sessions - reading the text, it appears that the topo= logy below assumes L3 forwarding devices; Shouldn't there be sufficient red= undancy in the regular case to re-route around failed links? Best regards, Richard --_000_D5A6F3355F664C40AFB65BB1277D8D45040E59FFDDMAAX7MCDC101A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dell - Interna= l Use - Confidential

Hi,

 

T= hanks for the review comment.

&nbs= p;

Isn't this t= he reason for ICMP (Host) unreachable?
Actually, only for active= TCP sessions, ICMP unreachable message would be received. In case of Inact= ive TCP sessions, there is no possibility of receiving ICMP message. Our pr= oposal is more applicable to Inactive TCP sessions. Further, according to R= FC 1122 Section 4.2.3.9 – TCP must not close the connection based on = ICMP Destination unreachable (codes 0,1,5) messages. Hence, the core idea i= s to proactively track the loss of  network level connectivity to a su= bnet and inform the Server regarding the same.

 

 Why terminate the TCP sessions - reading the text, it appe= ars that the topology below assumes L3 forwarding devices; Shouldn't there = be sufficient redundancy in the regular case to re-route around failed link= s?

Actually, our proposed mechani= sm is more suitable at TORs which are the entry points to Network/Internet = for Servers. In TORs, when the network connectivity to a particular subnet = is lost (during network failures, routing protocols in network would conver= ge and update the TOR’s IP Table), it basically indicates loss of net= work connectivity to TCP sessions established at Server. Hence, in the case= of inactive TCP sessions, the TOR can proactively initiate a TCP RST Messa= ge to Server informing it to tear down the corresponding session so that un= necessary wastage of kernel resources could be avoided.

 

Kindly let us kno= w your comments.

Thanks,S. Aravind Prasad

-----Original Message-----
From: Scheffenegger= , Richard [mailto:rs@netapp.com]
Sent: Monday, July 20, 2015 12:34 PMTo: Sridharan, Aravind; tcpm@ietf.org
Cc: Venkatesan, Shathish
Subj= ect: RE: New Draft for Lively TCP Connection Failure Notifications

<= br>Hi,

Isn't this the reason for ICMP (Host) unreachable?

Wh= y terminate the TCP sessions - reading the text, it appears that the topolo= gy below assumes L3 forwarding devices; Shouldn't there be sufficient redun= dancy in the regular case to re-route around failed links?

Best rega= rds,
Richard

= --_000_D5A6F3355F664C40AFB65BB1277D8D45040E59FFDDMAAX7MCDC101A_-- From nobody Tue Jul 21 07:12:21 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EF71A8872 for ; Tue, 21 Jul 2015 07:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nYeFoELqXb1K for ; Tue, 21 Jul 2015 07:12:16 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269521A8858 for ; Tue, 21 Jul 2015 07:12:16 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.15,516,1432623600"; d="scan'208,217"; a="58096585" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx141-out.netapp.com with ESMTP; 21 Jul 2015 07:11:37 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 21 Jul 2015 07:11:37 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::1438:d6b8:afb:4959%21]) with mapi id 15.00.1076.000; Tue, 21 Jul 2015 07:11:37 -0700 From: "Scheffenegger, Richard" To: Olivier Bonaventure , Joe Touch Thread-Topic: [tcpm] Analysis of the TCP EDO option Thread-Index: AQHQwt4NZjpPGyqgZUG9eqsM1MdX9J3lC1CAgAAJwoCAAOLIUA== Date: Tue, 21 Jul 2015 14:11:37 +0000 Message-ID: References: <55AD29A1.5060506@isi.edu> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/alternative; boundary="_000_c9d2e540790c4be4b4332fed7bac2959hioexcmbx05prdhqnetappc_" MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] Analysis of the TCP EDO option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:12:20 -0000 --_000_c9d2e540790c4be4b4332fed7bac2959hioexcmbx05prdhqnetappc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgT2xpdmllciwNCg0KdGhlIE9wdGlvbiBJbmplY3Rpb24gY2FzZSwgd291bGRu4oCZdCB0aGF0 IGJlIHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIGFkZHJlc3NlZCBieSBzZXR0aW5nIERPID0gbWlu KGxlbih0Y3Aub3B0aW9ucyksIG1heC50Y3Aub3B0aW9uLmxlbik7IEVETyA9IGxlbih0Y3Aub3B0 aW9ucykuDQoNClRoYXQgaXMgdG8gc2F5LCB0byBrZWVwIERPIGFuZCBFRE8gZXF1YWwgaWYgbm8g ZXh0ZW5kZWQgc3BhY2UgaXMgbmVlZGVkLCBhbmQgc2V0dGluZyBETyB0byBpdOKAmXMgbWF4aW11 bSBpZiBtb3JlIG9wdGlvbiBzcGFjZSBpcyB1c2VkPw0KDQpJIGFzc3VtZSwgdGhhdCBtZWRkbGVi b3hlcyBpbnNlcnRpbmcgb3B0aW9ucyB3b3VsZCByZWZyYWluIGZyb20gZG9pbmcgc28gaWYgdGhl cmUgaXMgbm8gc3BhY2UgbGVmdCBpbiB0aGUgRE8gcGFydCwgbm90Pw0KDQpCZXN0IHJlZ2FyZHMs DQogIFJpY2hhcmQNCg0KDQpGcm9tOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgT2xpdmllciBCb25hdmVudHVyZQ0KU2VudDogTW9udGFnLCAyMC4gSnVs aSAyMDE1IDE5OjM3DQpUbzogSm9lIFRvdWNoDQpDYzogdGNwbUBpZXRmLm9yZyAodGNwbUBpZXRm Lm9yZykNClN1YmplY3Q6IFJlOiBbdGNwbV0gQW5hbHlzaXMgb2YgdGhlIFRDUCBFRE8gb3B0aW9u DQoNCkpvZSwNCg0KVGhpcyBpc3N1ZSBpcyBhbHJlYWR5IGNvdmVyZWQgaW4gU2VjdGlvbiA3IG9m DQpkcmFmdC1pZXRmLXRjcG0tdGNwLWVkby0wMywgZXhjZXB0aW5nIG9ubHk6DQoNCjEuIGJsaW5k bHkgcmVmbGVjdGluZyBuZXcgb3B0aW9ucw0KICAgICAgICBUaGlzIGlzIGEgaGF6YXJkIG9mIGFs bCBuZXcgb3B0aW9ucywgYW5kIHNob3VsZCBiZSBjb3ZlcmVkDQogICAgICAgIGJ5IGEgc2luZ2xl IHRlc3Qgb3B0aW9uIHJhdGhlciB0aGFuIGJlaW5nIGJ1aWx0IGludG8gZXZlcnkNCiAgICAgICAg bmV3IG9wdGlvbg0KDQpJIHJlbWVtYmVyIHRoYXQgdGhpcyB3YXMgc29sdmVkIGluIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gVGhpcyBpcyBub3QgYSBzZXZlcmUgbGltaXRhdGlv biwgYnV0IGl0IGlzIHdvcnRoIGJlaW5nIG1lbnRpb25lZCBpbiB0aGUgZG9jdW1lbnQuDQoNCjIu IGhvdyB0byBoYW5kbGUgZGV0ZWN0aW9uIG9mIG1pZGRsZWJveCB0YW1wZXJpbmcgb2YgU2VnbWVu dF9MZW5ndGgNCiAgICAgICAgdGhlIGRvYyBhbHJlYWR5IG5vdGVzIHRoYXQgc3VjaCBldmVudHMg c2hvdWxkIGJlIG5vdGljZWQNCg0KV2hlbiByZWFkaW5nIHRoZSBkcmFmdCwgSSBjb3VsZCBub3Qg ZmluZCBob3cgYSByZWNlaXZlciBoYWQgdG8gcmVhbGx5IHJlYWN0IHVwb24gcmVjZXB0aW9uIG9m IHN1Y2ggYW4gaW52YWxpZCBzZWdtZW50LiBJdCBzaG91bGQgYmUgYmV0dGVyIGV4cGxhaW5lZCBp biB0aGUgZHJhZnQuDQoNCg0KICAgICAgICB0aGUgc2ltcGxlc3Qgc29sdXRpb24gd291bGQgYmUg dG8gc3RvcCB1c2luZyBFRE8gaW4gdGhlDQogICAgICAgIG90aGVyIGRpcmVjdGlvbiwgYW5kIHRv IGNoYW5nZSB0aGUgcnVsZSBhYm91dCB3aGF0IHRvIGRvDQogICAgICAgIHdoZW4gbm9uLUVETyBz ZWdtZW50cyBhcmUgcmVjZWl2ZWQsIGUuZy4sIHRvIG1ha2UgdGhlbQ0KICAgICAgICBjYXVzZSBF RE8gdG8gYmUgZHJvcHBlZCBvbiB0aGUgY29ubmVjdGlvbiBhbmQgdGhlIHVzZXIgdG8gYmUNCiAg ICAgICAgc2lnbmFsbGVkDQoNClRoaXMgc29sdXRpb24gc2hvdWxkIGJlIGRvY3VtZW50ZWQgcHJl Y2lzZWx5IGluIHRoZSBkcmFmdCBzbyB0aGF0IGltcGxlbWVudG9ycyBrbm93IHdoYXQgaXMgdGhl IGZhbGxiYWNrIG1lY2hhbmlzbS4gSW4gdGhlIGN1cnJlbnQgRURPLCB0aGVyZSBpcyBubyBmZWVk YmFjayBmcm9tIHRoZSByZWNlaXZlciB0byB0aGUgc2VuZGVyIGFuZCB0aGlzIGNhbiBjcmVhdGUg cHJvYmxlbXMgd2hlcmUgdGhlIHR3byBob3N0cyBtYXkgc3RvcCB0byBjb21tdW5pY2F0ZS4gVGhp cyBmYWxsYmFjayBtZWNoYW5pc20gaXMga2V5IHRvIHByZXNlcnZlIHRoZSBjb25uZWN0aXZpdHkg aW4gY2FzZSBvZiBtaWRkbGVib3ggaW50ZXJmZXJlbmNlDQoNClRoZXNlIGJvdGggY291bGQgaGF2 ZSBiZWVuIGhhbmRsZWQgd2l0aCBhbiBlbWFpbCwgYXMgSSBoYXZlIGRvbmUuDQoNCklmIHRoZSBU Q1BNIHdvcmtpbmcgZ3JvdXAgd2FudHMgdG8gaGF2ZSBhIHNhZmUgbWVjaGFuaXNtIHRvIGV4dGVu ZCB0aGUgVENQIGhlYWRlciwgdGhlbiB0aGlzIG1lY2hhbmlzbSBtdXN0IGJlIGV2YWx1YXRlZCBp biBkZXRhaWxzLiBPdXIgZHJhZnQgaXMgYSBjb250cmlidXRpb24gaW4gdGhlIHZhbGlkYXRpb24v aW1wcm92ZW1lbnQgb2YgRURPLiBXZSBoYXZlIGFsc28gc3BlbnQgcXVpdGUgc29tZSB0aW1lIHRv IGltcGxlbWVudCB0aGUgcHJvcG9zZWQgRURPIGluIHRyYWNlYm94IHNvIHRoYXQgd2UgY291bGQg c3RhcnQgbWVhc3VyZW1lbnRzIHRvIHZlcmlmeSBob3cgRURPIHBhc3NlcyB0aHJvdWdoIGV4aXN0 aW5nIG1pZGRsZWJveGVzLiBJIHRoaW5rIHRoYXQgc3VjaCBhbiBleHBlcmltZW50IG1ha2VzIHNl bnNlIGJlZm9yZSBhZG9wdGluZyBhbnkgc29sdXRpb24gdG8gZXh0ZW5kIHRoZSBUQ1AgaGVhZGVy LiBTdWNoIGFuIGV4dGVuc2lvbiBtdXN0IGJlIHNhZmUgYmVmb3JlIGl0IGNhbiBiZSBkZXBsb3ll ZC4NCg0KT2xpdmllcg0K --_000_c9d2e540790c4be4b4332fed7bac2959hioexcmbx05prdhqnetappc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkRFLUFUIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgT2xpdmllciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij50aGUgT3B0aW9uIEluamVjdGlvbiBjYXNlLCB3b3VsZG7igJl0IHRoYXQgYmUgc29tZXRoaW5n IHRoYXQgY291bGQgYmUgYWRkcmVzc2VkIGJ5IHNldHRpbmcgRE8gPSBtaW4obGVuKHRjcC5vcHRp b25zKSwgbWF4LnRjcC5vcHRpb24ubGVuKTsgRURPID0NCiBsZW4odGNwLm9wdGlvbnMpLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGF0IGlzIHRvIHNheSwgdG8ga2VlcCBE TyBhbmQgRURPIGVxdWFsIGlmIG5vIGV4dGVuZGVkIHNwYWNlIGlzIG5lZWRlZCwgYW5kIHNldHRp bmcgRE8gdG8gaXTigJlzIG1heGltdW0gaWYgbW9yZSBvcHRpb24gc3BhY2UgaXMgdXNlZD8NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFzc3VtZSwgdGhhdCBtZWRkbGVi b3hlcyBpbnNlcnRpbmcgb3B0aW9ucyB3b3VsZCByZWZyYWluIGZyb20gZG9pbmcgc28gaWYgdGhl cmUgaXMgbm8gc3BhY2UgbGVmdCBpbiB0aGUgRE8gcGFydCwgbm90PzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsgUmljaGFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRj cG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk9s aXZpZXIgQm9uYXZlbnR1cmU8YnI+DQo8Yj5TZW50OjwvYj4gTW9udGFnLCAyMC4gSnVsaSAyMDE1 IDE5OjM3PGJyPg0KPGI+VG86PC9iPiBKb2UgVG91Y2g8YnI+DQo8Yj5DYzo8L2I+IHRjcG1AaWV0 Zi5vcmcgKHRjcG1AaWV0Zi5vcmcpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdGNwbV0gQW5h bHlzaXMgb2YgdGhlIFRDUCBFRE8gb3B0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvZSw8 YnI+DQo8YnI+DQpUaGlzIGlzc3VlIGlzIGFscmVhZHkgY292ZXJlZCBpbiBTZWN0aW9uIDcgb2Y8 YnI+DQpkcmFmdC1pZXRmLXRjcG0tdGNwLWVkby0wMywgZXhjZXB0aW5nIG9ubHk6PGJyPg0KPGJy Pg0KMS4gYmxpbmRseSByZWZsZWN0aW5nIG5ldyBvcHRpb25zPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFRoaXMgaXMgYSBoYXphcmQgb2YgYWxsIG5ldyBvcHRpb25zLCBhbmQgc2hv dWxkIGJlIGNvdmVyZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYnkgYSBzaW5n bGUgdGVzdCBvcHRpb24gcmF0aGVyIHRoYW4gYmVpbmcgYnVpbHQgaW50byBldmVyeTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBuZXcgb3B0aW9uPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHJlbWVtYmVyIHRoYXQg dGhpcyB3YXMgc29sdmVkIGluIHRoZSBwcmV2aW91cyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gVGhp cyBpcyBub3QgYSBzZXZlcmUgbGltaXRhdGlvbiwgYnV0IGl0IGlzIHdvcnRoIGJlaW5nIG1lbnRp b25lZCBpbiB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIGhvdyB0byBoYW5kbGUgZGV0ZWN0aW9uIG9mIG1p ZGRsZWJveCB0YW1wZXJpbmcgb2YgU2VnbWVudF9MZW5ndGg8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgdGhlIGRvYyBhbHJlYWR5IG5vdGVzIHRoYXQgc3VjaCBldmVudHMgc2hvdWxk IGJlIG5vdGljZWQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldoZW4gcmVhZGluZyB0aGUgZHJhZnQsIEkgY291bGQgbm90IGZpbmQg aG93IGEgcmVjZWl2ZXIgaGFkIHRvIHJlYWxseSByZWFjdCB1cG9uIHJlY2VwdGlvbiBvZiBzdWNo IGFuIGludmFsaWQgc2VnbWVudC4gSXQgc2hvdWxkIGJlIGJldHRlciBleHBsYWluZWQgaW4gdGhl IGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIHNpbXBsZXN0 IHNvbHV0aW9uIHdvdWxkIGJlIHRvIHN0b3AgdXNpbmcgRURPIGluIHRoZTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBvdGhlciBkaXJlY3Rpb24sIGFuZCB0byBjaGFuZ2UgdGhlIHJ1 bGUgYWJvdXQgd2hhdCB0byBkbzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3aGVu IG5vbi1FRE8gc2VnbWVudHMgYXJlIHJlY2VpdmVkLCBlLmcuLCB0byBtYWtlIHRoZW08YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2F1c2UgRURPIHRvIGJlIGRyb3BwZWQgb24gdGhl IGNvbm5lY3Rpb24gYW5kIHRoZSB1c2VyIHRvIGJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHNpZ25hbGxlZDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzb2x1dGlvbiBzaG91bGQgYmUgZG9jdW1lbnRlZCBw cmVjaXNlbHkgaW4gdGhlIGRyYWZ0IHNvIHRoYXQgaW1wbGVtZW50b3JzIGtub3cgd2hhdCBpcyB0 aGUgZmFsbGJhY2sgbWVjaGFuaXNtLiBJbiB0aGUgY3VycmVudCBFRE8sIHRoZXJlIGlzIG5vIGZl ZWRiYWNrIGZyb20gdGhlIHJlY2VpdmVyIHRvIHRoZSBzZW5kZXIgYW5kIHRoaXMgY2FuIGNyZWF0 ZSBwcm9ibGVtcyB3aGVyZSB0aGUgdHdvIGhvc3RzDQogbWF5IHN0b3AgdG8gY29tbXVuaWNhdGUu IFRoaXMgZmFsbGJhY2sgbWVjaGFuaXNtIGlzIGtleSB0byBwcmVzZXJ2ZSB0aGUgY29ubmVjdGl2 aXR5IGluIGNhc2Ugb2YgbWlkZGxlYm94IGludGVyZmVyZW5jZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVzZSBib3RoIGNvdWxk IGhhdmUgYmVlbiBoYW5kbGVkIHdpdGggYW4gZW1haWwsIGFzIEkgaGF2ZSBkb25lLjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYg dGhlIFRDUE0gd29ya2luZyBncm91cCB3YW50cyB0byBoYXZlIGEgc2FmZSBtZWNoYW5pc20gdG8g ZXh0ZW5kIHRoZSBUQ1AgaGVhZGVyLCB0aGVuIHRoaXMgbWVjaGFuaXNtIG11c3QgYmUgZXZhbHVh dGVkIGluIGRldGFpbHMuIE91ciBkcmFmdCBpcyBhIGNvbnRyaWJ1dGlvbiBpbiB0aGUgdmFsaWRh dGlvbi9pbXByb3ZlbWVudCBvZiBFRE8uIFdlIGhhdmUgYWxzbyBzcGVudCBxdWl0ZSBzb21lIHRp bWUgdG8NCiBpbXBsZW1lbnQgdGhlIHByb3Bvc2VkIEVETyBpbiB0cmFjZWJveCBzbyB0aGF0IHdl IGNvdWxkIHN0YXJ0IG1lYXN1cmVtZW50cyB0byB2ZXJpZnkgaG93IEVETyBwYXNzZXMgdGhyb3Vn aCBleGlzdGluZyBtaWRkbGVib3hlcy4gSSB0aGluayB0aGF0IHN1Y2ggYW4gZXhwZXJpbWVudCBt YWtlcyBzZW5zZSBiZWZvcmUgYWRvcHRpbmcgYW55IHNvbHV0aW9uIHRvIGV4dGVuZCB0aGUgVENQ IGhlYWRlci4gU3VjaCBhbiBleHRlbnNpb24gbXVzdCBiZSBzYWZlDQogYmVmb3JlIGl0IGNhbiBi ZSBkZXBsb3llZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T2xpdmllciZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_c9d2e540790c4be4b4332fed7bac2959hioexcmbx05prdhqnetappc_-- From nobody Tue Jul 21 08:26:22 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449ED1A8A08 for ; Tue, 21 Jul 2015 08:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zyzyTk3x-_Re for ; Tue, 21 Jul 2015 08:26:19 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D18F1B2E85 for ; Tue, 21 Jul 2015 08:24:40 -0700 (PDT) Received: from [192.168.1.4] (pool-71-108-120-69.lsanca.dsl-w.verizon.net [71.108.120.69]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t6LFO55T014516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jul 2015 08:24:07 -0700 (PDT) References: <55AD29A1.5060506@isi.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-6B2FA0B8-0DC5-4F20-B765-17B8B9E9613A Message-Id: X-Mailer: iPad Mail (12H143) From: Joe Touch Date: Tue, 21 Jul 2015 08:24:04 -0700 To: "Scheffenegger, Richard" X-MailScanner-ID: t6LFO55T014516 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org \(tcpm@ietf.org\)" Subject: Re: [tcpm] Analysis of the TCP EDO option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 15:26:21 -0000 --Apple-Mail-6B2FA0B8-0DC5-4F20-B765-17B8B9E9613A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Why are we trying to solve a hypothetical that's also a violation of Rfc793?= Besides, injection is already detected by the seg_length field. Joe > On Jul 21, 2015, at 7:11 AM, Scheffenegger, Richard wrote:= >=20 > Hi Olivier, > =20 > the Option Injection case, wouldn=E2=80=99t that be something that could b= e addressed by setting DO =3D min(len(tcp.options), max.tcp.option.len); EDO= =3D len(tcp.options). > =20 > That is to say, to keep DO and EDO equal if no extended space is needed, a= nd setting DO to it=E2=80=99s maximum if more option space is used? > =20 > I assume, that meddleboxes inserting options would refrain from doing so i= f there is no space left in the DO part, not? > =20 > Best regards, > Richard > =20 > =20 > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Olivier Bonaventure= > Sent: Montag, 20. Juli 2015 19:37 > To: Joe Touch > Cc: tcpm@ietf.org (tcpm@ietf.org) > Subject: Re: [tcpm] Analysis of the TCP EDO option > =20 > Joe, >=20 > This issue is already covered in Section 7 of > draft-ietf-tcpm-tcp-edo-03, excepting only: >=20 > 1. blindly reflecting new options > This is a hazard of all new options, and should be covered > by a single test option rather than being built into every > new option > =20 > I remember that this was solved in the previous version of the draft. This= is not a severe limitation, but it is worth being mentioned in the document= . > =20 > 2. how to handle detection of middlebox tampering of Segment_Length > the doc already notes that such events should be noticed > =20 > When reading the draft, I could not find how a receiver had to really reac= t upon reception of such an invalid segment. It should be better explained i= n the draft. > =20 >=20 > the simplest solution would be to stop using EDO in the > other direction, and to change the rule about what to do > when non-EDO segments are received, e.g., to make them > cause EDO to be dropped on the connection and the user to be > signalled > =20 > This solution should be documented precisely in the draft so that implemen= tors know what is the fallback mechanism. In the current EDO, there is no fe= edback from the receiver to the sender and this can create problems where th= e two hosts may stop to communicate. This fallback mechanism is key to prese= rve the connectivity in case of middlebox interference > =20 > These both could have been handled with an email, as I have done. > =20 > If the TCPM working group wants to have a safe mechanism to extend the TCP= header, then this mechanism must be evaluated in details. Our draft is a co= ntribution in the validation/improvement of EDO. We have also spent quite so= me time to implement the proposed EDO in tracebox so that we could start mea= surements to verify how EDO passes through existing middleboxes. I think tha= t such an experiment makes sense before adopting any solution to extend the T= CP header. Such an extension must be safe before it can be deployed. > =20 > Olivier=20 --Apple-Mail-6B2FA0B8-0DC5-4F20-B765-17B8B9E9613A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Why are we trying to solve a= hypothetical that's also a violation of Rfc793?

Be= sides, injection is already detected by the seg_length field.

=
Joe

On Jul 21, 2015, at 7:11 AM, Scheffenegger, Ric= hard <rs@netapp.com> wrote:

Hi Olivier,

 

the Option I= njection case, wouldn=E2=80=99t that be something that could be addressed by= setting DO =3D min(len(tcp.options), max.tcp.option.len); EDO =3D len(tcp.options).

 <= /o:p>

That is to s= ay, to keep DO and EDO equal if no extended space is needed, and setting DO t= o it=E2=80=99s maximum if more option space is used?

 <= /o:p>

I assume, th= at meddleboxes inserting options would refrain from doing so if there is no s= pace left in the DO part, not?

 <= /o:p>

Best regards= ,

  Richa= rd

 <= /o:p>

 <= /o:p>

From: tcpm [mailto:tcp= m-bounces@ietf.org] On Behalf Of Olivier Bonaventure
Sent: Montag, 20. Juli 2015 19:37
To: Joe Touch
Cc: tcpm@ietf.org (tcpm@ietf.org)
Subject: Re: [tcpm] Analysis of the TCP EDO option<= /p>

 

Joe,

This issue is already covered in Section 7 of
draft-ietf-tcpm-tcp-edo-03, excepting only:

1. blindly reflecting new options
        This is a hazard of all new options, and should b= e covered
        by a single test option rather than being built i= nto every
        new option

 

I remember that this was solved in the previous versi= on of the draft. This is not a severe limitation, but it is worth being ment= ioned in the document.

 

2. how to handle detection of middlebox tampering of S= egment_Length
        the doc already notes that such events should be= noticed

 

When reading the draft, I could not find how a receiv= er had to really react upon reception of such an invalid segment. It should b= e better explained in the draft.

 


        the simplest solution would be to stop using EDO= in the
        other direction, and to change the rule about wh= at to do
        when non-EDO segments are received, e.g., to mak= e them
        cause EDO to be dropped on the connection and th= e user to be
        signalled

 

This solution should be documented precisely in the d= raft so that implementors know what is the fallback mechanism. In the curren= t EDO, there is no feedback from the receiver to the sender and this can cre= ate problems where the two hosts may stop to communicate. This fallback mechanism is key to preserve the con= nectivity in case of middlebox interference

 

These both could have been handled with an email, as I= have done.

 

If the TCPM working group wants to have a safe mechan= ism to extend the TCP header, then this mechanism must be evaluated in detai= ls. Our draft is a contribution in the validation/improvement of EDO. We hav= e also spent quite some time to implement the proposed EDO in tracebox so that we could start measurements t= o verify how EDO passes through existing middleboxes. I think that such an e= xperiment makes sense before adopting any solution to extend the TCP header.= Such an extension must be safe before it can be deployed.

 

Olivier 

= --Apple-Mail-6B2FA0B8-0DC5-4F20-B765-17B8B9E9613A-- From nobody Tue Jul 21 11:22:53 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEE31A8A9B for ; Tue, 21 Jul 2015 11:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 uUtmfsPca19w for ; Tue, 21 Jul 2015 11:22:50 -0700 (PDT) Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 872731A8788 for ; Tue, 21 Jul 2015 11:22:50 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t6LIMn4U024678 for ; Tue, 21 Jul 2015 14:22:49 -0400 Received: (qmail 591 invoked by uid 0); 21 Jul 2015 18:22:49 -0000 X-TCPREMOTEIP: 198.119.56.43 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?10.1.29.117?) (wes@mti-systems.com@198.119.56.43) by 0 with ESMTPA; 21 Jul 2015 18:22:48 -0000 To: "Scharf, Michael (Michael)" References: <655C07320163294895BBADA28372AF5D48433CE4@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Wesley Eddy X-Enigmail-Draft-Status: N1110 Organization: MTI Systems Message-ID: <55AE8DF6.2000400@mti-systems.com> Date: Tue, 21 Jul 2015 14:22:46 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <655C07320163294895BBADA28372AF5D48433CE4@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Section 3.7.1 draft-ietf-tcpm-rfc793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 18:22:52 -0000 On 7/20/2015 12:46 PM, Scharf, Michael (Michael) wrote: > Hi Wes, > > A small nit regarding draft-ietf-tcpm-rfc793bis-00 page 30: > > If an MSS option is not received at connection setup, TCP MUST assume > a default send MSS of 536 (576-40) for IPv4 or 1220 (1280 - 40) for > IPv6. > > In my understanding, the IPv6 value of 1220 is correct, but probably the math should be changed into 1280 - 40 - 20... > Thanks, you're right that the 40 for IPv4 should be 60 for IPv6. This is now staged to be fixed in the next revision: https://bitbucket.org/weddy/rfc793bis/commits/9640da2339e9e198d2a0cbae118eb24abd7ee946 -- Wes Eddy MTI Systems From nobody Tue Jul 21 15:34:51 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C311B2B20 for ; Tue, 21 Jul 2015 15:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rWLyUitQI0Me for ; Tue, 21 Jul 2015 15:34:48 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56CB31A1BF8 for ; Tue, 21 Jul 2015 15:34:48 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t6LMXtUo027133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Jul 2015 15:33:56 -0700 (PDT) To: Aravind_Sridharan@Dell.com, tcpm@ietf.org References: From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55AEC8D3.7040709@isi.edu> Date: Tue, 21 Jul 2015 15:33:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MailScanner-ID: t6LMXtUo027133 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Shathish_Venkatesan@Dell.com, touch@isi.edu Subject: Re: [tcpm] New Draft for Lively TCP Connection Failure Notifications X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 22:34:50 -0000 FWIW, we've been around this block a few times, including in TERNLI and TRIGTRAN. As has already been observed: - endpoints indicate failure using ICMP dest unreachable (some are soft errors, some hard) - routers indicate failure usings ICMP time/parameter (mostly soft because of the potential for alternate paths, as Richard noted) You're basically proposing to: a) make an L2 switch issue TCP-level errors at best, it might issue ICMP errors, except that it can't because *it doesn't exist at the IP layer* b) issue forced hard errors for behaviors that RFC1122 ` already very clearly defines as soft (by issuing RSTs instead of ICMPs) c) spoof RSTs (see RFC4953), which won't work if the sources use TCP protection (RFC5961), IPsec (RFC4301), or TCP-AO (RFC5925) You're making the system unpredictably fragile and ignoring the fact that L2 might have alternate paths too (e.g., TRILL, multi-spanning-tree, etc.). Some other notes: - HTTP had persistent connections before 1.1: V. Padmanabhan, J. Mogul, Improving HTTP latency, Proc. 2nd Int. World Wide Web Conf., Oct. 1994. - inactive TCP connections may still be sending keepalives (this is often needed to prevent orphan connections from consuming server state), so they might still end up receiving ICMP errors and that's the right place to decide whether state needs to be cleaned up or not, frankly - TOR entry points can make their own decisions if they run out of state and need to do a cleanup, they could simply delete state for paths that they consider stale. until TCP sends a new message, they should not be doing anything to that TCP connection. when the new message arrives, either by a keepalive or becoming active, it would generate the necessary ICMP - You need not cite all the component RFCs associated with HTTP, and you really do need to cite the RFCs I indicate above. - And provide a convincing reason that this is both safe and necessary. Joe On 7/19/2015 8:43 PM, Aravind_Sridharan@Dell.com wrote: > Hi All, > > We have proposed a new draft on Lively TCP Connection Failure Notifications. > > Name: draft-aravind-tcpm-lively-failure-notifications > Revision: 00 > Title: Lively TCP Connection Failure Notifications > Document date: 2015-07-20 > Group: Individual Submission > Pages: 4 > URL: https://www.ietf.org/internet-drafts/draft-aravind-tcpm-lively-failure-notifications-00.txt > Status: https://datatracker.ietf.org/doc/draft-aravind-tcpm-lively-failure-notifications/ > Htmlized: https://tools.ietf.org/html/draft-aravind-tcpm-lively-failure-notifications-00 > > > Abstract: > This document proposes a mechanism to provide lively notifications of > TCP Connection Failures in Network. > > We would love to hear your reviews and comments. > > Cheers, > S. Aravind Prasad > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue Jul 21 22:23:02 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEB31A8BB7 for ; Tue, 21 Jul 2015 22:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Rw3mEASDN3rl for ; Tue, 21 Jul 2015 22:22:59 -0700 (PDT) Received: from mail-vn0-x235.google.com (mail-vn0-x235.google.com [IPv6:2607:f8b0:400c:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71ADB1A8A8F for ; Tue, 21 Jul 2015 22:22:59 -0700 (PDT) Received: by vnav141 with SMTP id v141so44208356vna.0 for ; Tue, 21 Jul 2015 22:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=RBtzgDlm6RF8rLhH4PE1o9H+qUj51RZsIOPEdFao9Dc=; b=o+7wNm7C1sj3jtB4Jdl7RYEk8gLheau65gzaop6ii8pKriCD9qZuyXhTKFYgctCp4E xyXda4754uQ+GjoPSBy4ZVMkABUbFGyUFsi9V9/Ni4NAq8fA/AriCXVH+T+ItTJgVwFq eLjfkeifp04ZTgO9ld3mFTXoU07ITjGkRIbvWaFYL8u/1Pt4hjOFuNp5cW4GtltvJgQJ 5D/j0hXA4qfHjxcXNz4Jedqy4voyQ6LU8NoJJ1yiyyEMUbHsbsrB0h5uy0FgrXzCVM3E A5Ey9Bg6H9tf1cMXa42gWTnOhlVVO+fGJgh3o7Z6IwuRoSnBTuY2L6e8j7dL2JZW84HJ aPPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=RBtzgDlm6RF8rLhH4PE1o9H+qUj51RZsIOPEdFao9Dc=; b=LWoo8nM5FYXvymQ7h+TjiIRalzGFubW1Qn83r9UQsoYtrLHOTpD6f7JSFEF/wj7u9H UV/8SLGilqmvRAWoSp2cRQRjmksILD+tuDgsG36Ev4Mj16FV993hvcPS2KdswmYkMkOx clxRBPP5gn/FEs0f7U/XhGDVSGLn0lGgGw4k3a1mZBqq4ivvOpMfdwzqq87dl9KLpo1Y LIPvOPwmsDFcEfIRuYlz2Fle5i1ipYKC00KtPKrwpc00OhpwAK9NajvVr0219TSa+GJN RbHXfveaysGVQ84UWF7Qwh7Lqwa4JkNMiDKV+L9h6T9hfhcBpno8zTAHvBL+Rgrgwu1l 29IA== X-Gm-Message-State: ALoCoQknHD4K56p673DTRlJ8dmujkuF3rdL43lcidFd0JONu4dmf98FWcXoSPJLzXu+XyorE54D/ X-Received: by 10.52.115.68 with SMTP id jm4mr803825vdb.21.1437542578495; Tue, 21 Jul 2015 22:22:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.83 with HTTP; Tue, 21 Jul 2015 22:22:19 -0700 (PDT) In-Reply-To: <55AEC8D3.7040709@isi.edu> References: <55AEC8D3.7040709@isi.edu> From: Yuchung Cheng Date: Tue, 21 Jul 2015 22:22:19 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Aravind_Sridharan@dell.com, "tcpm@ietf.org Extensions" , Shathish_Venkatesan@dell.com Subject: Re: [tcpm] New Draft for Lively TCP Connection Failure Notifications X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 05:23:01 -0000 I have similar concerns and find the proposal scary. Linux implements RFC5961 so your device would have to keep per flow state if the hosts/VMs are careful. On Tue, Jul 21, 2015 at 3:33 PM, Joe Touch wrote: > FWIW, we've been around this block a few times, including in TERNLI and > TRIGTRAN. > > As has already been observed: > > - endpoints indicate failure using ICMP dest unreachable > (some are soft errors, some hard) > > - routers indicate failure usings ICMP time/parameter > (mostly soft because of the potential for alternate paths, > as Richard noted) > > You're basically proposing to: > > a) make an L2 switch issue TCP-level errors > at best, it might issue ICMP errors, except that > it can't because *it doesn't exist at the IP layer* > > b) issue forced hard errors for behaviors that RFC1122 > ` already very clearly defines as soft (by issuing RSTs > instead of ICMPs) > > c) spoof RSTs (see RFC4953), which won't work if > the sources use TCP protection (RFC5961), IPsec (RFC4301), > or TCP-AO (RFC5925) > > You're making the system unpredictably fragile and ignoring the fact > that L2 might have alternate paths too (e.g., TRILL, > multi-spanning-tree, etc.). > > Some other notes: > > - HTTP had persistent connections before 1.1: > V. Padmanabhan, J. Mogul, =E2=80=9CImproving HTTP latency,=E2=80= =9D > Proc. 2nd Int. World Wide Web Conf., Oct. 1994. > > - inactive TCP connections may still be sending keepalives (this is > often needed to prevent orphan connections from consuming server state), > so they might still end up receiving ICMP errors > > and that's the right place to decide whether state needs to > be cleaned up or not, frankly > > - TOR entry points can make their own decisions > > if they run out of state and need to do a cleanup, they could > simply delete state for paths that they consider stale. until > TCP sends a new message, they should not be doing anything to > that TCP connection. when the new message arrives, either > by a keepalive or becoming active, it would generate the > necessary ICMP > > - You need not cite all the component RFCs associated with HTTP, and you > really do need to cite the RFCs I indicate above. > > - And provide a convincing reason that this is both safe and necessary. > > Joe > > On 7/19/2015 8:43 PM, Aravind_Sridharan@Dell.com wrote: >> Hi All, >> >> We have proposed a new draft on Lively TCP Connection Failure Notificati= ons. >> >> Name: draft-aravind-tcpm-lively-failure-notifications >> Revision: 00 >> Title: Lively TCP Connection Failure Notifications >> Document date: 2015-07-20 >> Group: Individual Submission >> Pages: 4 >> URL: https://www.ietf.org/internet-drafts/draft-aravind-tcpm-= lively-failure-notifications-00.txt >> Status: https://datatracker.ietf.org/doc/draft-aravind-tcpm-live= ly-failure-notifications/ >> Htmlized: https://tools.ietf.org/html/draft-aravind-tcpm-lively-fa= ilure-notifications-00 >> >> >> Abstract: >> This document proposes a mechanism to provide lively notifications of >> TCP Connection Failures in Network. >> >> We would love to hear your reviews and comments. >> >> Cheers, >> S. Aravind Prasad >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jul 21 22:46:31 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B89B1ACD30 for ; Tue, 21 Jul 2015 22:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 hS90ITMC70jP for ; Tue, 21 Jul 2015 22:46:28 -0700 (PDT) Received: from mail-vn0-x22e.google.com (mail-vn0-x22e.google.com [IPv6:2607:f8b0:400c:c0f::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 1D9301ACCEF for ; Tue, 21 Jul 2015 22:46:28 -0700 (PDT) Received: by vnds125 with SMTP id s125so44283994vnd.1 for ; Tue, 21 Jul 2015 22:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cRDRsKe2JJ/xa+3avPGi4XBYs92T9NrtWQXAyOzBNoA=; b=lXGBUfUYGQxQ0EaGX6q6i7p9T2xUCznB8pOzUk9WFdxz/uk432sVS18Q/r6FDwQ/8y hXCUo5I8Sp1iruVbRKdD2oncquih+V1ja23y22B4BoD5L1Ym3Jy32R3WdhOcW1IzIPqH r4SBSPk0tvScZx+Augsx+eYp5xLIDF8bjj3DLyCnfNnngQAIpeQwGVWm5VQzx64Y9Qeu yDOilHSpbl+uEr1z78PFK8XN3d5t1nTC9fJiVnHzu2xoCVPW9aW1viUB/4w4H4l9Tjsz 2ObPcHsAiOkObWqIbZHCVsvZuZNEqlCwbP206MHq2Nz0WkMfkmP1/XbFmUVcVqf4pNv/ p8qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cRDRsKe2JJ/xa+3avPGi4XBYs92T9NrtWQXAyOzBNoA=; b=ZVPk8q5Y1uzcB/qk4ZirBuHbkSb5sWRjL1wf4f+TtRDXhWUxIMFzXXWHlWKO2bSNnZ EPHjTmwtI0SPtON/7KNzsuQF41A6eAsaRnHBF44G1Z9rMFEwth1/bdS2Sbdcf0pECGX5 NuEk6hEISWlGwuhPW+lNHfUngUmyXVdyRUgfPxBtntl88/rypqMRo6P7en09nHQYaXBq NohT4DimrwH2p01gKVJFTTHGTcu2qHROhU/kUApzkrSQSKF/mNAHNHo1+h/I9/I3JoMs KGE66/0oY71YKqxrvbaUrh0n9Fkz7GWt8QkzHZpLyellgHeb1pshnBQdQd8d2sTus/kZ 5w5w== X-Gm-Message-State: ALoCoQkLFcwbv/zCPxxcSbXPMYNbKkC/rgtNzRJLxLXYJSybDpDbUIPhT9ZzhtwYv2RPStA85CFL X-Received: by 10.52.115.68 with SMTP id jm4mr896987vdb.21.1437543987352; Tue, 21 Jul 2015 22:46:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.83 with HTTP; Tue, 21 Jul 2015 22:45:48 -0700 (PDT) In-Reply-To: <118DE6D7-6863-4859-8A25-1CA086B3002C@iki.fi> References: <553710a93aa94ff19a5fb28eac42168a@hioexcmbx05-prd.hq.netapp.com> <118DE6D7-6863-4859-8A25-1CA086B3002C@iki.fi> From: Yuchung Cheng Date: Tue, 21 Jul 2015 22:45:48 -0700 Message-ID: To: Pasi Sarolahti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 05:46:30 -0000 How does echo option work with TSO / GRO or stretched ACKs. They are all common cases now. TCP Efiel works very well already with TCP timestmaps (which unfortunately takes 12 bytes option space). It's not clear if this new option provide substantial benefit? Sure having a packet sequence field improves identifying spurious re-transmission, reordering, RTT estimation. But the benefits are too minor to justify a new option. From nobody Wed Jul 22 04:16:24 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AF61B2AA8 for ; Wed, 22 Jul 2015 04:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 POht10QP-vXq for ; Wed, 22 Jul 2015 04:16:17 -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 571691B2A70 for ; Wed, 22 Jul 2015 04:16:17 -0700 (PDT) Received: from dhcp-9b03.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:436:da58:fc87:7169]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 820761B00205 for ; Wed, 22 Jul 2015 12:16:10 +0100 (BST) Message-ID: <55AF7B7E.6010900@erg.abdn.ac.uk> Date: Wed, 22 Jul 2015 13:16:14 +0200 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] Heads-up to TCPM: TCP-Stealth discussion will be in TSVWG. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:16:18 -0000 This is a little note to say the following presentation will be taken in the TSVWG Agenda today: https://www.ietf.org/proceedings/93/slides/slides-93-tsvwg-10.pdf I expect this will describe port-scanning and the TCP Stealth draft: https://datatracker.ietf.org/doc/draft-kirsch-ietf-tcp-stealth/ Gorry From nobody Wed Jul 22 04:32:23 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724A11B2C62 for ; Wed, 22 Jul 2015 04:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zfTmRhSIqX9e for ; Wed, 22 Jul 2015 04:32:20 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E841B2BFE for ; Wed, 22 Jul 2015 04:32:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,523,1432623600"; d="scan'208";a="57571787" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx144-out.netapp.com with ESMTP; 22 Jul 2015 04:27:15 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 22 Jul 2015 04:27:15 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::1438:d6b8:afb:4959%21]) with mapi id 15.00.1076.000; Wed, 22 Jul 2015 04:27:15 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng , Pasi Sarolahti Thread-Topic: [tcpm] Comments on draft-zimmermann-tcpm-echo-option Thread-Index: AQHQwsPSkjkK11efxkqPFxzwQJzibp3kGyJwgACF6QCAAtIXAP//6Cbw Date: Wed, 22 Jul 2015 11:27:14 +0000 Message-ID: <1256ea42509c42e980dc2d4da9143f90@hioexcmbx05-prd.hq.netapp.com> References: <553710a93aa94ff19a5fb28eac42168a@hioexcmbx05-prd.hq.netapp.com> <118DE6D7-6863-4859-8A25-1CA086B3002C@iki.fi> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:32:22 -0000 Hi Yuchung, The echo option is one part (providing new semantics, useful for a lot of c= ases, as for example SYN cookies); The Spurious retransmission detection facility builds on top of the new sem= antics, yielding detection capability under more (arguable, corner) cases t= han TSopt - at lower overhead, while enabling further uses (which are parti= ally in Linux TCP already, agreed, but not standardized).=20 The interaction with TSO should be benign, as in the design for SRD we keep= the same Echo option until the sender enters loss recovery; thus copying t= he option over into any header is the expected behavior. On GRO, a chance in the tcp options should trigger the hand off to TCP alre= ady, and we don't expect this to run significantly different, as for SRD, t= he Echo option changes when there is a reordering / non-consecutive packet = received, which should be treated by GRO already (but Joe's finding seem to= indicate that GRO is sometimes broken with options, from the EDO slildes p= resented just now). Finally, after a hallway conversation with Matt, I think that the Echo Opti= on, in the design for SRD, could also be used for PAWS - taking away anothe= r exclusive use case for timestamps - replacing that with a smaller (wire o= verhead) option. But I would have to think about this more.... Best regards, Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng > Sent: Mittwoch, 22. Juli 2015 07:46 > To: Pasi Sarolahti > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option >=20 > How does echo option work with TSO / GRO or stretched ACKs. They are all > common cases now. >=20 > TCP Efiel works very well already with TCP timestmaps (which unfortunatel= y > takes 12 bytes option space). It's not clear if this new option provide > substantial benefit? Sure having a packet sequence field improves > identifying spurious re-transmission, reordering, RTT estimation. But the > benefits are too minor to justify a new option. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 22 04:37:58 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D6B1B2BF6 for ; Wed, 22 Jul 2015 04:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 B5_nyu2XjV9g for ; Wed, 22 Jul 2015 04:37:56 -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 84D031B2AF3 for ; Wed, 22 Jul 2015 04:37:56 -0700 (PDT) Received: from dhcp-9b03.meeting.ietf.org (dhcp-9b03.meeting.ietf.org [31.133.155.3]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id F2CC71B00205 for ; Wed, 22 Jul 2015 12:37:50 +0100 (BST) Message-ID: <55AF8092.3020306@erg.abdn.ac.uk> Date: Wed, 22 Jul 2015 13:37:54 +0200 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] Some text on updating what "RFC 793 says that the Reserved fields" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:37:57 -0000 If the group thinks that TCP reserved fields need to be handled in the normal IETF protocol way, there is a standards-track RFC that would kindof support this: RFC3360: Inappropriate TCP Resets Considered Harmful (BCP: 60) from 2002, see "2.1. The TCP Reserved Field": RFC 793 says that the Reserved field in the TCP header is reserved for future use, and must be zero. A rephrasing more consistent with the rest of the document would have been to say that the Reserved field should be zero when sent and ignored when received, unless specified otherwise by future standards actions. However, the phrasing in RFC 793 does not permit sending resets in response to TCP packets with a non-zero Reserved field, as is explained in the section above. Gorry From nobody Wed Jul 22 11:31:32 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6D41A3BA2 for ; Wed, 22 Jul 2015 11:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oxXEnNkTM_7l for ; Wed, 22 Jul 2015 11:31:29 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107E51A3BA0 for ; Wed, 22 Jul 2015 11:31:29 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t6MIVAef019350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 11:31:11 -0700 (PDT) To: "Scheffenegger, Richard" , Yuchung Cheng , Pasi Sarolahti References: <553710a93aa94ff19a5fb28eac42168a@hioexcmbx05-prd.hq.netapp.com> <118DE6D7-6863-4859-8A25-1CA086B3002C@iki.fi> <1256ea42509c42e980dc2d4da9143f90@hioexcmbx05-prd.hq.netapp.com> From: Joe Touch Message-ID: <55AFE16E.204@isi.edu> Date: Wed, 22 Jul 2015 11:31:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <1256ea42509c42e980dc2d4da9143f90@hioexcmbx05-prd.hq.netapp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t6MIVAef019350 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org Extensions" , touch@isi.edu Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 18:31:30 -0000 FWIW, I really wish this option could find a way to use one TCP Kind codepoint. What's the reason for not doing so? It seems consistent with the other requirements indicated in the document. (and no, I don't consider "detecting blind unknown-option reflectors a valid reason; TCP isn't designed as a diagnostic tool for byzantine failures) Joe On 7/22/2015 4:27 AM, Scheffenegger, Richard wrote: > > Hi Yuchung, > > The echo option is one part (providing new semantics, useful for a lot of cases, as for example SYN cookies); > > The Spurious retransmission detection facility builds on top of the new semantics, yielding detection capability under more (arguable, corner) cases than TSopt - at lower overhead, while enabling further uses (which are partially in Linux TCP already, agreed, but not standardized). > > The interaction with TSO should be benign, as in the design for SRD we keep the same Echo option until the sender enters loss recovery; thus copying the option over into any header is the expected behavior. > > On GRO, a chance in the tcp options should trigger the hand off to TCP already, and we don't expect this to run significantly different, as for SRD, the Echo option changes when there is a reordering / non-consecutive packet received, which should be treated by GRO already (but Joe's finding seem to indicate that GRO is sometimes broken with options, from the EDO slildes presented just now). > > Finally, after a hallway conversation with Matt, I think that the Echo Option, in the design for SRD, could also be used for PAWS - taking away another exclusive use case for timestamps - replacing that with a smaller (wire overhead) option. But I would have to think about this more.... > > > Best regards, > Richard > > >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng >> Sent: Mittwoch, 22. Juli 2015 07:46 >> To: Pasi Sarolahti >> Cc: tcpm@ietf.org Extensions >> Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option >> >> How does echo option work with TSO / GRO or stretched ACKs. They are all >> common cases now. >> >> TCP Efiel works very well already with TCP timestmaps (which unfortunately >> takes 12 bytes option space). It's not clear if this new option provide >> substantial benefit? Sure having a packet sequence field improves >> identifying spurious re-transmission, reordering, RTT estimation. But the >> benefits are too minor to justify a new option. >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Jul 22 12:21:07 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EC81A90AD for ; Wed, 22 Jul 2015 12:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 I45DyDtTQ232 for ; Wed, 22 Jul 2015 12:21:04 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A021A8715 for ; Wed, 22 Jul 2015 12:21:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,524,1432623600"; d="scan'208";a="58445178" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx141-out.netapp.com with ESMTP; 22 Jul 2015 12:20:03 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 22 Jul 2015 12:20:03 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::1438:d6b8:afb:4959%21]) with mapi id 15.00.1076.000; Wed, 22 Jul 2015 12:20:03 -0700 From: "Scheffenegger, Richard" To: Joe Touch Thread-Topic: [tcpm] Comments on draft-zimmermann-tcpm-echo-option Thread-Index: AQHQwsPSkjkK11efxkqPFxzwQJzibp3kGyJwgACF6QCAAtIXAP//6CbwgADtsgD//5hP9A== Date: Wed, 22 Jul 2015 19:20:03 +0000 Message-ID: <2FCF61CB-F1AB-475B-9F49-203E69C70959@netapp.com> References: <553710a93aa94ff19a5fb28eac42168a@hioexcmbx05-prd.hq.netapp.com> <118DE6D7-6863-4859-8A25-1CA086B3002C@iki.fi> <1256ea42509c42e980dc2d4da9143f90@hioexcmbx05-prd.hq.netapp.com>, <55AFE16E.204@isi.edu> In-Reply-To: <55AFE16E.204@isi.edu> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 19:21:06 -0000 Today in the presetation there was also a comment to have the same mechanis= m for symetric data transport using only a single tcp option codepoint. For our specific use case, the counter for srd does not need to be very lar= ge - reducing it to 6 bit and using 2 bits of the first byte to signal some= thing like this would work in our use case... Is this would you were thinking of? Best regards, Richard Scheffenegger > Am 22.07.2015 um 20:31 schrieb "Joe Touch" : >=20 > FWIW, I really wish this option could find a way to use one TCP Kind > codepoint. What's the reason for not doing so? It seems consistent with > the other requirements indicated in the document. >=20 > (and no, I don't consider "detecting blind unknown-option reflectors a > valid reason; TCP isn't designed as a diagnostic tool for byzantine > failures) >=20 > Joe >=20 >> On 7/22/2015 4:27 AM, Scheffenegger, Richard wrote: >>=20 >> Hi Yuchung, >>=20 >> The echo option is one part (providing new semantics, useful for a lot o= f cases, as for example SYN cookies); >>=20 >> The Spurious retransmission detection facility builds on top of the new = semantics, yielding detection capability under more (arguable, corner) case= s than TSopt - at lower overhead, while enabling further uses (which are pa= rtially in Linux TCP already, agreed, but not standardized).=20 >>=20 >> The interaction with TSO should be benign, as in the design for SRD we k= eep the same Echo option until the sender enters loss recovery; thus copyin= g the option over into any header is the expected behavior. >>=20 >> On GRO, a chance in the tcp options should trigger the hand off to TCP a= lready, and we don't expect this to run significantly different, as for SRD= , the Echo option changes when there is a reordering / non-consecutive pack= et received, which should be treated by GRO already (but Joe's finding seem= to indicate that GRO is sometimes broken with options, from the EDO slilde= s presented just now). >>=20 >> Finally, after a hallway conversation with Matt, I think that the Echo O= ption, in the design for SRD, could also be used for PAWS - taking away ano= ther exclusive use case for timestamps - replacing that with a smaller (wir= e overhead) option. But I would have to think about this more.... >>=20 >>=20 >> Best regards, >> Richard >>=20 >>=20 >>> -----Original Message----- >>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng >>> Sent: Mittwoch, 22. Juli 2015 07:46 >>> To: Pasi Sarolahti >>> Cc: tcpm@ietf.org Extensions >>> Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option >>>=20 >>> How does echo option work with TSO / GRO or stretched ACKs. They are al= l >>> common cases now. >>>=20 >>> TCP Efiel works very well already with TCP timestmaps (which unfortunat= ely >>> takes 12 bytes option space). It's not clear if this new option provide >>> substantial benefit? Sure having a packet sequence field improves >>> identifying spurious re-transmission, reordering, RTT estimation. But t= he >>> benefits are too minor to justify a new option. >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 22 12:44:01 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F091A1BD7 for ; Wed, 22 Jul 2015 12:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 kPqpkCwsREl8 for ; Wed, 22 Jul 2015 12:43:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343331A8974 for ; Wed, 22 Jul 2015 12:43:58 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t6MJhbZv000909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 12:43:39 -0700 (PDT) To: "Scheffenegger, Richard" References: <553710a93aa94ff19a5fb28eac42168a@hioexcmbx05-prd.hq.netapp.com> <118DE6D7-6863-4859-8A25-1CA086B3002C@iki.fi> <1256ea42509c42e980dc2d4da9143f90@hioexcmbx05-prd.hq.netapp.com> <55AFE16E.204@isi.edu> <2FCF61CB-F1AB-475B-9F49-203E69C70959@netapp.com> From: Joe Touch Message-ID: <55AFF269.3010700@isi.edu> Date: Wed, 22 Jul 2015 12:43:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <2FCF61CB-F1AB-475B-9F49-203E69C70959@netapp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org Extensions" , touch@isi.edu Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 19:44:00 -0000 On 7/22/2015 12:20 PM, Scheffenegger, Richard wrote: > Today in the presetation there was also a comment to have the same mechanism for symetric data transport using only a single tcp option codepoint. > > For our specific use case, the counter for srd does not need to be very large - reducing it to 6 bit and using 2 bits of the first byte to signal something like this would work in our use case... > > Is this would you were thinking of? Yup. (also, have you considered whether you can reuse the original Echo codepoint? if you flip a bit in the response, you would always know the difference) Joe > > Best regards, > Richard Scheffenegger > >> Am 22.07.2015 um 20:31 schrieb "Joe Touch" : >> >> FWIW, I really wish this option could find a way to use one TCP Kind >> codepoint. What's the reason for not doing so? It seems consistent with >> the other requirements indicated in the document. >> >> (and no, I don't consider "detecting blind unknown-option reflectors a >> valid reason; TCP isn't designed as a diagnostic tool for byzantine >> failures) >> >> Joe >> >>> On 7/22/2015 4:27 AM, Scheffenegger, Richard wrote: >>> >>> Hi Yuchung, >>> >>> The echo option is one part (providing new semantics, useful for a lot of cases, as for example SYN cookies); >>> >>> The Spurious retransmission detection facility builds on top of the new semantics, yielding detection capability under more (arguable, corner) cases than TSopt - at lower overhead, while enabling further uses (which are partially in Linux TCP already, agreed, but not standardized). >>> >>> The interaction with TSO should be benign, as in the design for SRD we keep the same Echo option until the sender enters loss recovery; thus copying the option over into any header is the expected behavior. >>> >>> On GRO, a chance in the tcp options should trigger the hand off to TCP already, and we don't expect this to run significantly different, as for SRD, the Echo option changes when there is a reordering / non-consecutive packet received, which should be treated by GRO already (but Joe's finding seem to indicate that GRO is sometimes broken with options, from the EDO slildes presented just now). >>> >>> Finally, after a hallway conversation with Matt, I think that the Echo Option, in the design for SRD, could also be used for PAWS - taking away another exclusive use case for timestamps - replacing that with a smaller (wire overhead) option. But I would have to think about this more.... >>> >>> >>> Best regards, >>> Richard >>> >>> >>>> -----Original Message----- >>>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng >>>> Sent: Mittwoch, 22. Juli 2015 07:46 >>>> To: Pasi Sarolahti >>>> Cc: tcpm@ietf.org Extensions >>>> Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option >>>> >>>> How does echo option work with TSO / GRO or stretched ACKs. They are all >>>> common cases now. >>>> >>>> TCP Efiel works very well already with TCP timestmaps (which unfortunately >>>> takes 12 bytes option space). It's not clear if this new option provide >>>> substantial benefit? Sure having a packet sequence field improves >>>> identifying spurious re-transmission, reordering, RTT estimation. But the >>>> benefits are too minor to justify a new option. >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 22 13:02:42 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC69E1B2C72 for ; Wed, 22 Jul 2015 13:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TAvO3-Zfqiw3 for ; Wed, 22 Jul 2015 13:02:39 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491CF1B2C75 for ; Wed, 22 Jul 2015 13:01:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,525,1432623600"; d="scan'208";a="58451447" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx141-out.netapp.com with ESMTP; 22 Jul 2015 13:00:50 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 22 Jul 2015 13:00:50 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::1438:d6b8:afb:4959%21]) with mapi id 15.00.1076.000; Wed, 22 Jul 2015 13:00:50 -0700 From: "Scheffenegger, Richard" To: Joe Touch Thread-Topic: [tcpm] Comments on draft-zimmermann-tcpm-echo-option Thread-Index: AQHQwsPSkjkK11efxkqPFxzwQJzibp3kGyJwgACF6QCAAtIXAP//6CbwgADtsgD//5hP9IAAe++A//+PdjI= Date: Wed, 22 Jul 2015 20:00:49 +0000 Message-ID: <4001A31B-DC1F-4CDF-BBF4-EC70F747B9F6@netapp.com> References: <553710a93aa94ff19a5fb28eac42168a@hioexcmbx05-prd.hq.netapp.com> <118DE6D7-6863-4859-8A25-1CA086B3002C@iki.fi> <1256ea42509c42e980dc2d4da9143f90@hioexcmbx05-prd.hq.netapp.com> <55AFE16E.204@isi.edu> <2FCF61CB-F1AB-475B-9F49-203E69C70959@netapp.com>,<55AFF269.3010700@isi.edu> In-Reply-To: <55AFF269.3010700@isi.edu> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 20:02:41 -0000 Hi Joe, We can certainly ask IANA to reuse that codepoint if and when we pass the s= ignaling draft, even though the semantics are different than in the old spe= c - but there is no use of the echo option that i know of (happy to hear ab= out that though). Thanks! Best regards, Richard Scheffenegger > Am 22.07.2015 um 21:44 schrieb "Joe Touch" : >=20 >=20 >=20 >> On 7/22/2015 12:20 PM, Scheffenegger, Richard wrote: >> Today in the presetation there was also a comment to have the same mecha= nism for symetric data transport using only a single tcp option codepoint. >>=20 >> For our specific use case, the counter for srd does not need to be very = large - reducing it to 6 bit and using 2 bits of the first byte to signal s= omething like this would work in our use case... >>=20 >> Is this would you were thinking of? >=20 > Yup. >=20 > (also, have you considered whether you can reuse the original Echo > codepoint? if you flip a bit in the response, you would always know the > difference) >=20 > Joe >=20 >>=20 >> Best regards, >> Richard Scheffenegger >>=20 >>> Am 22.07.2015 um 20:31 schrieb "Joe Touch" : >>>=20 >>> FWIW, I really wish this option could find a way to use one TCP Kind >>> codepoint. What's the reason for not doing so? It seems consistent with >>> the other requirements indicated in the document. >>>=20 >>> (and no, I don't consider "detecting blind unknown-option reflectors a >>> valid reason; TCP isn't designed as a diagnostic tool for byzantine >>> failures) >>>=20 >>> Joe >>>=20 >>>> On 7/22/2015 4:27 AM, Scheffenegger, Richard wrote: >>>>=20 >>>> Hi Yuchung, >>>>=20 >>>> The echo option is one part (providing new semantics, useful for a lot= of cases, as for example SYN cookies); >>>>=20 >>>> The Spurious retransmission detection facility builds on top of the ne= w semantics, yielding detection capability under more (arguable, corner) ca= ses than TSopt - at lower overhead, while enabling further uses (which are = partially in Linux TCP already, agreed, but not standardized).=20 >>>>=20 >>>> The interaction with TSO should be benign, as in the design for SRD we= keep the same Echo option until the sender enters loss recovery; thus copy= ing the option over into any header is the expected behavior. >>>>=20 >>>> On GRO, a chance in the tcp options should trigger the hand off to TCP= already, and we don't expect this to run significantly different, as for S= RD, the Echo option changes when there is a reordering / non-consecutive pa= cket received, which should be treated by GRO already (but Joe's finding se= em to indicate that GRO is sometimes broken with options, from the EDO slil= des presented just now). >>>>=20 >>>> Finally, after a hallway conversation with Matt, I think that the Echo= Option, in the design for SRD, could also be used for PAWS - taking away a= nother exclusive use case for timestamps - replacing that with a smaller (w= ire overhead) option. But I would have to think about this more.... >>>>=20 >>>>=20 >>>> Best regards, >>>> Richard >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng >>>>> Sent: Mittwoch, 22. Juli 2015 07:46 >>>>> To: Pasi Sarolahti >>>>> Cc: tcpm@ietf.org Extensions >>>>> Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option >>>>>=20 >>>>> How does echo option work with TSO / GRO or stretched ACKs. They are = all >>>>> common cases now. >>>>>=20 >>>>> TCP Efiel works very well already with TCP timestmaps (which unfortun= ately >>>>> takes 12 bytes option space). It's not clear if this new option provi= de >>>>> substantial benefit? Sure having a packet sequence field improves >>>>> identifying spurious re-transmission, reordering, RTT estimation. But= the >>>>> benefits are too minor to justify a new option. >>>>>=20 >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 22 18:19:31 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED701A1A2E for ; Wed, 22 Jul 2015 18:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 eHLWRM2VuutY for ; Wed, 22 Jul 2015 18:19:28 -0700 (PDT) Received: from mail-vn0-x232.google.com (mail-vn0-x232.google.com [IPv6:2607:f8b0:400c:c0f::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 9DE2B1A1A29 for ; Wed, 22 Jul 2015 18:19:28 -0700 (PDT) Received: by vnaa140 with SMTP id a140so54930977vna.2 for ; Wed, 22 Jul 2015 18:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=bkKl4U2tJ8M02y9LmFmGejNhuBQw0Uqokb35c5+ilrw=; b=doS/LKMaYTNdeAYe04FNSL8eVosTPPVnPgt668H+9YRkpIHTpymZNofNiriYTmt98S 316WzNhouOKFjntV47bWGtYKtR7Oko/nRmYzXUJ+oqHw1AlHOyYqmOMVwTfAKYrsVfSk rckSka5xj0CvMiQfBaFynXYa4zNjlBCvYuMlfWwUdLd6I+828OvJUwtW3PN5/Ll5KyyQ Z+oRm5PDq1tKGBmniH2SkPvYWaRfEnllMNhMhKaXTsj+Gpe8JDv6jWNLFDK7kgdPEtEA tS7d5aS3BfOJrJoGKYgiyPLCzT3Qh5daGPOkb61OhTCON371CfC9LuXHcBDbRdJ4SJcl 3gpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=bkKl4U2tJ8M02y9LmFmGejNhuBQw0Uqokb35c5+ilrw=; b=ap5I3bgUukOO5l2gtkTKdIByUf6wUSa9815cyAmWM3RsW4N9/dsFdNmblK26BwYYc8 yOjyneDMSXx9bsCRvyxcdsSMoAyL44e09dZ5/MM6f0XfGlnOX6Zac+Cpx0dXjF+Q+wTz GoqNdrUgjBywimgarOXsVeEvDXmZy7gCXrnleYvqjohSBgtg+iMDyL/g2/TkiV+JQ1jH xDCXLnQdSZQ+HYIcQq+R+Y+KyObwKvaL/4vAKBJZszhqrvsx/bQkttJtq+tZvcuGZ4ts /vt8A/ut/BScS6HDFG0i1jKA+S+mmduk/WBQYB8eCGiSsLb6Y0Ru9xk+dhBqU/lrLacz UD8w== X-Gm-Message-State: ALoCoQkiosho9m42IEKOeZT1PTdB4/HVwpe08uBk9VIm1EVkU8YiQY74g78TohFadix/K6XLS3eY X-Received: by 10.52.181.167 with SMTP id dx7mr6895102vdc.91.1437614367862; Wed, 22 Jul 2015 18:19:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.83 with HTTP; Wed, 22 Jul 2015 18:18:48 -0700 (PDT) In-Reply-To: <1256ea42509c42e980dc2d4da9143f90@hioexcmbx05-prd.hq.netapp.com> References: <553710a93aa94ff19a5fb28eac42168a@hioexcmbx05-prd.hq.netapp.com> <118DE6D7-6863-4859-8A25-1CA086B3002C@iki.fi> <1256ea42509c42e980dc2d4da9143f90@hioexcmbx05-prd.hq.netapp.com> From: Yuchung Cheng Date: Wed, 22 Jul 2015 18:18:48 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 01:19:30 -0000 On Wed, Jul 22, 2015 at 4:27 AM, Scheffenegger, Richard wro= te: > > Hi Yuchung, > > The echo option is one part (providing new semantics, useful for a lot of= cases, as for example SYN cookies); What problems does echo solve that syn-cookies don't? not mentioned in draf= t. > > The Spurious retransmission detection facility builds on top of the new s= emantics, yielding detection capability under more (arguable, corner) cases= than TSopt - at lower overhead, while enabling further uses (which are par= tially in Linux TCP already, agreed, but not standardized). which features are you talking about here? (again not clear from draft) > > The interaction with TSO should be benign, as in the design for SRD we ke= ep the same Echo option until the sender enters loss recovery; thus copying= the option over into any header is the expected behavior. Is echo option length fixated throughout the connection? > > On GRO, a chance in the tcp options should trigger the hand off to TCP al= ready, and we don't expect this to run significantly different, as for SRD,= the Echo option changes when there is a reordering / non-consecutive packe= t received, which should be treated by GRO already (but Joe's finding seem = to indicate that GRO is sometimes broken with options, from the EDO slildes= presented just now). > > Finally, after a hallway conversation with Matt, I think that the Echo Op= tion, in the design for SRD, could also be used for PAWS - taking away anot= her exclusive use case for timestamps - replacing that with a smaller (wire= overhead) option. But I would have to think about this more.... > > > Best regards, > Richard > > >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng >> Sent: Mittwoch, 22. Juli 2015 07:46 >> To: Pasi Sarolahti >> Cc: tcpm@ietf.org Extensions >> Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option >> >> How does echo option work with TSO / GRO or stretched ACKs. They are all >> common cases now. >> >> TCP Efiel works very well already with TCP timestmaps (which unfortunate= ly >> takes 12 bytes option space). It's not clear if this new option provide >> substantial benefit? Sure having a packet sequence field improves >> identifying spurious re-transmission, reordering, RTT estimation. But th= e >> benefits are too minor to justify a new option. >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 22 23:38:20 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57831A8788 for ; Wed, 22 Jul 2015 23:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3XLoNjD_Oubk for ; Wed, 22 Jul 2015 23:38:16 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939CE1A8771 for ; Wed, 22 Jul 2015 23:38:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,528,1432623600"; d="scan'208";a="56446821" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx143-out.netapp.com with ESMTP; 22 Jul 2015 23:37:16 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 22 Jul 2015 23:37:15 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::1438:d6b8:afb:4959%21]) with mapi id 15.00.1076.000; Wed, 22 Jul 2015 23:37:15 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng Thread-Topic: [tcpm] Comments on draft-zimmermann-tcpm-echo-option Thread-Index: AQHQwsPSkjkK11efxkqPFxzwQJzibp3kGyJwgACF6QCAAtIXAP//6CbwgAFflgD//9+FAA== Date: Thu, 23 Jul 2015 06:37:14 +0000 Message-ID: References: <553710a93aa94ff19a5fb28eac42168a@hioexcmbx05-prd.hq.netapp.com> <118DE6D7-6863-4859-8A25-1CA086B3002C@iki.fi> <1256ea42509c42e980dc2d4da9143f90@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 06:38:18 -0000 Hi Yuchung, > -----Original Message----- > > The echo option is one part (providing new semantics, useful for a lot > > of cases, as for example SYN cookies); > > What problems does echo solve that syn-cookies don't? not mentioned in > draft. I was referring to Bob's SYN Cookie proposal, not the traditional syn cooki= e in ISN/TSval - https://tools.ietf.org/html/draft-briscoe-tcpm-echo-cookie= -00. The traditional approach is limited in the number of bits you can "sto= re" in-flight, while the echo option would allow larger hashes, thus more s= tate to be exchanged (limited by the available option bytes, after accounti= ng for the needed options in the SYN). > > The Spurious retransmission detection facility builds on top of the new > semantics, yielding detection capability under more (arguable, corner) > cases than TSopt - at lower overhead, while enabling further uses (which > are partially in Linux TCP already, agreed, but not standardized). > > which features are you talking about here? (again not clear from draft) In the SRD case, the echo option can be thought of as an abbreviated contro= l stream sequence counter; I understand that in QUIC, as also in SCTP, you = have two independent counters, one for the sequence of segments, and one fo= r the ordering of payload bytes. Whatever that enables, can be enabled with= the Echo option (I am interested in improved loss recovery, lost retransmi= ssion detection/recovery; Alex approach was from the reordering side / spur= ious retransmission detection). With other words, using that you can fully = separate the "what" from "when" to send, within TCP. > > The interaction with TSO should be benign, as in the design for SRD we > keep the same Echo option until the sender enters loss recovery; thus > copying the option over into any header is the expected behavior. >=20 > Is echo option length fixated throughout the connection? No, the option is of variable length - and can be omitted if the sender is = so inclined. The current thinking is, that whatever is present (the omissio= n by itself is also a signal) in a segment that triggers an ACK, is being r= eflected back. Between the signaling protocol (TCP Echo opt) and the uses t= here is a distinction - a mechanism such as SRD would basically send an ech= o option on every transmitted (data) segment, for a constant feedback. Another mechanism such as https://tools.ietf.org/html/draft-briscoe-tcpm-ec= ho-cookie-00 would use the echo option only during 3WHS... And still other mechanisms may sporadically send out some data, but none at= other times (with an empty, len=3D2, echo option during SYN) Best regards, Richard =20 From nobody Thu Jul 23 00:24:08 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AD11A1B63; Thu, 23 Jul 2015 00:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 UFe1iKn4pFI8; Thu, 23 Jul 2015 00:24:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FE31A88A1; Thu, 23 Jul 2015 00:24:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.1.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150723072401.22369.88179.idtracker@ietfa.amsl.com> Date: Thu, 23 Jul 2015 00:24:01 -0700 Archived-At: Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Document Action: 'Updating TCP to support Rate-Limited Traffic' to Experimental RFC (draft-ietf-tcpm-newcwv-13.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 07:24:05 -0000 The IESG has approved the following document: - 'Updating TCP to support Rate-Limited Traffic' (draft-ietf-tcpm-newcwv-13.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ Technical Summary This document describes an experimental proposal to allow TCP senders to restart data transfer quickly following an idle or less active period. This approach is expected to benefit applications that unable to send at the maximum rate permitted by the congestion window for some reasons. As a result, it aims to provide incentives for long-lived connections and to remove ad-hoc tweaks in some applications that try to maintain a large cwnd for future data transmissions. The approach can be viewed as an updated version of RFC2861 and it obsoletes RFC2861. Working Group Summary The draft has been discussed for around 4 years. There has been explicit support for the draft since the beginning. Main discussion points were some detailed mechanisms in the logic that are related to estimating path capacity and preserving congestion window size during applications are idle or less active. The initial intended status of the draft was PS, but it has been changed to Experimental as a result of the discussions. Linux kernel has the codes which address the same issue. Their algorithms are slightly different from the document. There had been discussions between the linux kernel implementers and the document authors; however, they haven't reached the consensus to replace the existing kernel codes until more solid evidences are found. The WG's conclusion is to publish the draft as an experimental and explore its efficiency and feasibility of this approach. Document Quality The document has been reviewed and discussed by multiple participants in the WG. Some discussions points raised by reviewers are listed in Section 9.1. The patches to FreeBSD and Linux kernel have been made by the efforts from the authors and other group. Personnel Yoshifumi Nishida is the Document Shepherd for this document. The Responsible Area Director is Martin Stiemerling From nobody Thu Jul 23 04:42:58 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A10E1A8A8B for ; Thu, 23 Jul 2015 04:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 q78JSFen0KDS for ; Thu, 23 Jul 2015 04:42:54 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 8C9B91A89B3 for ; Thu, 23 Jul 2015 04:42:54 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id C0A5B7FAD3AC for ; Thu, 23 Jul 2015 11:42:50 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6NBgqWj008256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Jul 2015 13:42:52 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 13:42:52 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org Extensions" Thread-Topic: [ipr-announce] IPR Disclosure Michael Scharf's Statement about IPR related to draft-zimmermann-tcpm-spurious-rxmit belonging to Ericsson Thread-Index: AQHQxTl6KEDS7Q+90k+Rv0OlDtvGMZ3o6Spw Date: Thu, 23 Jul 2015 11:42:51 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48437BDA@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] FW: [ipr-announce] IPR Disclosure Michael Scharf's Statement about IPR related to draft-zimmermann-tcpm-spurious-rxmit belonging to Ericsson X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 11:42:56 -0000 Some background: During my Master Thesis many years ago, I have followed th= e IETF discussions on RFC 3522. Even after many years, I recall that encodi= ngs other than timestamps have been proposed at that time. Based on that wh= at I recall it seems very likely to me that the authors of RFC 3522 were al= so aware of alternative to timestamps encoding. I have been told that formally I have to submit an IPR disclosure to comply= to the "Note Well" statement, even if I had not specifically looked at the= IPR. Obviously, I am not a lawyer and I do not know whether that IPR indeed appl= ies to draft-zimmermann-tcpm-spurious-rxmit. Michael -----Original Message----- From: ipr-announce [mailto:ipr-announce-bounces@ietf.org] On Behalf Of IETF= Secretariat Sent: Thursday, July 23, 2015 1:20 PM To: alexander.zimmermann@netapp.com; rs@netapp.com Cc: jari.arkko@piuha.net; ipr-announce@ietf.org Subject: [ipr-announce] IPR Disclosure Michael Scharf's Statement about IPR= related to draft-zimmermann-tcpm-spurious-rxmit belonging to Ericsson Dear Alexander Zimmermann, Richard Scheffenegger: An IPR disclosure that pertains to your Internet-Draft entitled "Using the TCP Echo Option for Spurious Retransmission Detection" (draft-zimmermann-tcpm-spurious-rxmit) was submitted to the IETF Secretaria= t on=20 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2637/). The title of the IPR disclosure is "Michael Scharf's Statement about IPR related to draft-zimmermann-tcpm-spurious-rxmit belonging to Ericsson" Thank you IETF Secretariat _______________________________________________ ipr-announce mailing list ipr-announce@ietf.org https://www.ietf.org/mailman/listinfo/ipr-announce From nobody Thu Jul 23 04:51:34 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084B01A9154 for ; Thu, 23 Jul 2015 04:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tQp0IKWb9EOb for ; Thu, 23 Jul 2015 04:51:26 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4335B1A9168 for ; Thu, 23 Jul 2015 04:51:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,530,1432623600"; d="scan'208";a="56487000" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx143-out.netapp.com with ESMTP; 23 Jul 2015 04:51:04 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 23 Jul 2015 04:51:04 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::dc1c:7054:32f6:3f6b%21]) with mapi id 15.00.1076.000; Thu, 23 Jul 2015 04:51:04 -0700 From: "Eggert, Lars" To: "Scharf, Michael (Michael)" Thread-Topic: [tcpm] [ipr-announce] IPR Disclosure Michael Scharf's Statement about IPR related to draft-zimmermann-tcpm-spurious-rxmit belonging to Ericsson Thread-Index: AQHQxTl68vtjk9kE+UuvTLYgvIb8SJ3o6SpwgAB9b4A= Date: Thu, 23 Jul 2015 11:51:04 +0000 Message-ID: <09EF8012-FC34-4CB5-AC04-CC88E23F9A68@netapp.com> References: <655C07320163294895BBADA28372AF5D48437BDA@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48437BDA@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2102) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [ipr-announce] IPR Disclosure Michael Scharf's Statement about IPR related to draft-zimmermann-tcpm-spurious-rxmit belonging to Ericsson X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 11:51:28 -0000 On 2015-7-23, at 13:42, Scharf, Michael (Michael) wrote: > I have been told that formally I have to submit an IPR disclosure to comp= ly to the "Note Well" statement, even if I had not specifically looked at t= he IPR. Just for the record: You are never *required* to make a third party disclos= ure. It is however *requested*, and thank you for doing so. Lars= From nobody Thu Jul 23 04:58:49 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B886D1A9237 for ; Thu, 23 Jul 2015 04:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3kw3Z-8HUBFD for ; Thu, 23 Jul 2015 04:58:47 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8610E1A92B0 for ; Thu, 23 Jul 2015 04:58:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,530,1432623600"; d="asc'?scan'208";a="56487677" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx143-out.netapp.com with ESMTP; 23 Jul 2015 04:57:53 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 23 Jul 2015 04:57:53 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::dc1c:7054:32f6:3f6b%21]) with mapi id 15.00.1076.000; Thu, 23 Jul 2015 04:57:53 -0700 From: "Eggert, Lars" To: "Scharf, Michael (Michael)" Thread-Topic: [tcpm] [ipr-announce] IPR Disclosure Michael Scharf's Statement about IPR related to draft-zimmermann-tcpm-spurious-rxmit belonging to Ericsson Thread-Index: AQHQxTl68vtjk9kE+UuvTLYgvIb8SJ3o6SpwgAB9b4CAAAHnAA== Date: Thu, 23 Jul 2015 11:57:52 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D48437BDA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <09EF8012-FC34-4CB5-AC04-CC88E23F9A68@netapp.com> In-Reply-To: <09EF8012-FC34-4CB5-AC04-CC88E23F9A68@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2102) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_5315BD8F-7B60-45B1-85F1-578EBB77B8C8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [ipr-announce] IPR Disclosure Michael Scharf's Statement about IPR related to draft-zimmermann-tcpm-spurious-rxmit belonging to Ericsson X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 11:58:48 -0000 --Apple-Mail=_5315BD8F-7B60-45B1-85F1-578EBB77B8C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2015-7-23, at 13:51, Eggert, Lars wrote: > On 2015-7-23, at 13:42, Scharf, Michael (Michael) = wrote: >> I have been told that formally I have to submit an IPR disclosure to = comply to the "Note Well" statement, even if I had not specifically = looked at the IPR. >=20 > Just for the record: You are never *required* to make a third party = disclosure. It is however *requested*, and thank you for doing so. I should probably have stressed the "third party disclosure" part, = because it matters. If a contributor or their employer are the ones = holding IPR, a disclosure *is* required. (But then it wouldn't be a = third party one.) Lars --Apple-Mail=_5315BD8F-7B60-45B1-85F1-578EBB77B8C8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlWw1sAACgkQIWcjmsUTWRq/mACfVKGpHuF1JG2E0vbgZG1whrO2 ezEAnRW84tIkqTbrN2Y9RCECHc4G83fH =HUPx -----END PGP SIGNATURE----- --Apple-Mail=_5315BD8F-7B60-45B1-85F1-578EBB77B8C8-- From nobody Thu Jul 23 05:03:46 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080C51A92EC for ; Thu, 23 Jul 2015 05:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 kFxyGhjHBKJN for ; Thu, 23 Jul 2015 05:03:43 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 43EA31A9250 for ; Thu, 23 Jul 2015 05:03:39 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 33D74881A5CB5; Thu, 23 Jul 2015 12:03:35 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6NC3P0N022812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jul 2015 14:03:35 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 14:03:01 +0200 From: "Scharf, Michael (Michael)" To: "Eggert, Lars" Thread-Topic: [tcpm] [ipr-announce] IPR Disclosure Michael Scharf's Statement about IPR related to draft-zimmermann-tcpm-spurious-rxmit belonging to Ericsson Thread-Index: AQHQxTl6KEDS7Q+90k+Rv0OlDtvGMZ3o6Spw///mkACAAAHmAIAAIfaA Date: Thu, 23 Jul 2015 12:03:00 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48437CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D48437BDA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <09EF8012-FC34-4CB5-AC04-CC88E23F9A68@netapp.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [ipr-announce] IPR Disclosure Michael Scharf's Statement about IPR related to draft-zimmermann-tcpm-spurious-rxmit belonging to Ericsson X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 12:03:45 -0000 No matter whether the formal advice I received was correct or not, I think = that the IPR issue has to be considered in the WG, e.g., during a potential= adoption discussion. Michael > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: Thursday, July 23, 2015 1:58 PM > To: Scharf, Michael (Michael) > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] [ipr-announce] IPR Disclosure Michael Scharf's > Statement about IPR related to draft-zimmermann-tcpm-spurious-rxmit > belonging to Ericsson >=20 > On 2015-7-23, at 13:51, Eggert, Lars wrote: > > On 2015-7-23, at 13:42, Scharf, Michael (Michael) > wrote: > >> I have been told that formally I have to submit an IPR disclosure to > comply to the "Note Well" statement, even if I had not specifically > looked at the IPR. > > > > Just for the record: You are never *required* to make a third party > disclosure. It is however *requested*, and thank you for doing so. >=20 > I should probably have stressed the "third party disclosure" part, > because it matters. If a contributor or their employer are the ones > holding IPR, a disclosure *is* required. (But then it wouldn't be a > third party one.) >=20 > Lars From nobody Thu Jul 23 05:09:08 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2E41A92DC for ; Thu, 23 Jul 2015 05:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 E0Pmm4SbISoe for ; Thu, 23 Jul 2015 05:09:04 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DFA1A90C6 for ; Thu, 23 Jul 2015 05:09:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,530,1432623600"; d="asc'?scan'208";a="58605165" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx141-out.netapp.com with ESMTP; 23 Jul 2015 05:08:48 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 23 Jul 2015 05:08:47 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::dc1c:7054:32f6:3f6b%21]) with mapi id 15.00.1076.000; Thu, 23 Jul 2015 05:08:47 -0700 From: "Eggert, Lars" To: "Scharf, Michael (Michael)" Thread-Topic: [tcpm] [ipr-announce] IPR Disclosure Michael Scharf's Statement about IPR related to draft-zimmermann-tcpm-spurious-rxmit belonging to Ericsson Thread-Index: AQHQxTl68vtjk9kE+UuvTLYgvIb8SJ3o6SpwgAB9b4CAAAHnAIAAAW8AgAABnQA= Date: Thu, 23 Jul 2015 12:08:47 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D48437BDA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <09EF8012-FC34-4CB5-AC04-CC88E23F9A68@netapp.com> <655C07320163294895BBADA28372AF5D48437CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48437CE5@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2102) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_09E836A8-DF98-42A7-B93A-4FB8B90DF391"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] [ipr-announce] IPR Disclosure Michael Scharf's Statement about IPR related to draft-zimmermann-tcpm-spurious-rxmit belonging to Ericsson X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 12:09:07 -0000 --Apple-Mail=_09E836A8-DF98-42A7-B93A-4FB8B90DF391 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2015-7-23, at 14:03, Scharf, Michael (Michael) = wrote: > No matter whether the formal advice I received was correct or not, I = think that the IPR issue has to be considered in the WG, e.g., during a = potential adoption discussion. Completely agree. Lars --Apple-Mail=_09E836A8-DF98-42A7-B93A-4FB8B90DF391 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlWw2U4ACgkQIWcjmsUTWRq+lwCg8mRTrV2XjT/p1ylMvfGLv110 +2QAnijQYAUOKRCLiMOvVbtL7xgnsH1e =leKc -----END PGP SIGNATURE----- --Apple-Mail=_09E836A8-DF98-42A7-B93A-4FB8B90DF391-- From nobody Thu Jul 23 05:40:37 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EF51A1A58 for ; Thu, 23 Jul 2015 05:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 v8YiotlTNRkx for ; Thu, 23 Jul 2015 05:40:33 -0700 (PDT) Received: from johanna4.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4881A00BF for ; Thu, 23 Jul 2015 05:40:30 -0700 (PDT) RazorGate-KAS: Status: not_detected RazorGate-KAS: Rate: 0 RazorGate-KAS: Envelope from: RazorGate-KAS: Version: 5.5.3 RazorGate-KAS: LuaCore: 215 2015-05-29_17-31-22 60ae4a1b4d01d14f868b20a55aced8d7df7b2e28 RazorGate-KAS: Lua profiles 78662 [Jun 02 2015] RazorGate-KAS: Method: none Received: from dhcp-b33c.meeting.ietf.org (31.133.179.60) by johanna4.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as saropa-1) id 557E8F8A036DE1D9 for tcpm@ietf.org; Thu, 23 Jul 2015 15:40:29 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 23 Jul 2015 14:40:29 +0200 To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [tcpm] IETF-93 Meeting minutes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 12:40:35 -0000 Hi, Minutes from yesterday=92s TCPM meeting are at = https://www.ietf.org/proceedings/93/minutes/minutes-93-tcpm . Many = thanks to Andrew McGregor and Michael Welzl for taking notes! Please let me (or co-chairs) know of any corrections that are needed. - Pasi From nobody Thu Jul 23 14:01:42 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104281A1A1D for ; Thu, 23 Jul 2015 14:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 duThpXhwUTn3 for ; Thu, 23 Jul 2015 14:01:39 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979AF1A03A3 for ; Thu, 23 Jul 2015 14:01:39 -0700 (PDT) Received: from [128.9.184.135] ([128.9.184.135]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t6NL14bF002555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Jul 2015 14:01:04 -0700 (PDT) From: Joe Touch To: "tcpm@ietf.org" References: <55A811B2.2080302@isi.edu> Message-ID: <55B15610.1020300@isi.edu> Date: Thu, 23 Jul 2015 14:01:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <55A811B2.2080302@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t6NL14bF002555 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [tcpm] draft-bonaventure-mptcp-long-options-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 21:01:41 -0000 Hi, all, The above draft discusses several concerns with EDO, of which most have already been addressed in Section 7.3 of the EDO-03 draft. As it notes, EDO is for more than just MPTCP. Other observations below. Joe In summary, there are 5 cases: 2 of which are hypothetical only 1 of which was fixed with the original EDO variant but breaks when the space isn't used in the SYN-ACK (i.e., when the option is reflected), but is very easy to fix 1 of which is byzantine and IMO should not be fixed (and for which even in-band would require extreme measures) all others of which EDO already fixes with the Seg_Length field (the only issue is how to handle seg_length failures, and that too is easy to fix) I raised concerns with in-band options when MPTCP was being proposed in Stockholm. It's worrisome that it's gone back to including that because it decouples TCP signaling from the segment boundaries, only creates mutual escalation (once middleboxes understand it they'll surely tamper with it) and invites "TCP over TCP" ultimately. Many of the assertions of what works and does not through middleboxes is from the Honda IMC11 paper, which we already know failed to confirm many of the issues claimed in this summary. Joe --- Of the issues raised: 1. blindly echoing SYN options already applies to other widely-deployed options (SACK, WSCALE) trivial to address by flipping at least one bit in the EDO-capable option response 2. modified SYN-ACK we don't use EDO until both sides confirm after the TWHS for this reason 3. blind removal despite no citation for seeing this in the wild, the most recent EDO includes a segment_length field that will detect such tampering 4. splitting IMC11 explicitly stated that although middleboxes do split and coalesce segments, none did so while passing unknown options despite no citation for seeing this in the wild, this would be detected by the segment_length field 5. coalescing see (4) 6. modifying the data this would interfere with in-band mechanisms as well ---- From nobody Thu Jul 23 21:13:11 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A21A1B2D77 for ; Thu, 23 Jul 2015 21:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.514 X-Spam-Level: * X-Spam-Status: No, score=1.514 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 CagdMRKJ6en3 for ; Thu, 23 Jul 2015 21:13:08 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B092C1B2D76 for ; Thu, 23 Jul 2015 21:13:08 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A3E02278167 for ; Fri, 24 Jul 2015 13:13:06 +0900 (JST) Received: by obbop1 with SMTP id op1so9442491obb.2 for ; Thu, 23 Jul 2015 21:13:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.65.1 with SMTP id t1mr12817986oes.31.1437711185175; Thu, 23 Jul 2015 21:13:05 -0700 (PDT) Received: by 10.202.177.193 with HTTP; Thu, 23 Jul 2015 21:13:05 -0700 (PDT) In-Reply-To: <55B15610.1020300@isi.edu> References: <55A811B2.2080302@isi.edu> <55B15610.1020300@isi.edu> Date: Thu, 23 Jul 2015 21:13:05 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-bonaventure-mptcp-long-options-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 04:13:10 -0000 Hi Joe, One question. The IMC paper you mentioned describes TSO cases that copied the options to all the split segments. Can't we count it into "seeing this in the wild"? Thanks, -- Yoshi On Thu, Jul 23, 2015 at 2:01 PM, Joe Touch wrote: > Hi, all, > > The above draft discusses several concerns with EDO, of which most have > already been addressed in Section 7.3 of the EDO-03 draft. > > As it notes, EDO is for more than just MPTCP. > > Other observations below. > > Joe > > In summary, there are 5 cases: > > 2 of which are hypothetical only > > 1 of which was fixed with the original EDO variant > but breaks when the space isn't used in the SYN-ACK > (i.e., when the option is reflected), but is very easy to fix > > 1 of which is byzantine and IMO should not be fixed > (and for which even in-band would require extreme measures) > > all others of which EDO already fixes with the Seg_Length field > (the only issue is how to handle seg_length failures, and that > too is easy to fix) > > I raised concerns with in-band options when MPTCP was being proposed in > Stockholm. It's worrisome that it's gone back to including that because > it decouples TCP signaling from the segment boundaries, only creates > mutual escalation (once middleboxes understand it they'll surely tamper > with it) and invites "TCP over TCP" ultimately. > > Many of the assertions of what works and does not through middleboxes is > from the Honda IMC11 paper, which we already know failed to confirm many > of the issues claimed in this summary. > > Joe > > --- > > Of the issues raised: > > 1. blindly echoing SYN options > already applies to other widely-deployed options (SACK, WSCALE) > trivial to address by flipping at least one bit in the > EDO-capable option response > > 2. modified SYN-ACK > we don't use EDO until both sides confirm after the TWHS > for this reason > > 3. blind removal > despite no citation for seeing this in the wild, > the most recent EDO includes a segment_length field that > will detect such tampering > > 4. splitting > IMC11 explicitly stated that although middleboxes do split > and coalesce segments, none did so while passing unknown > options > > despite no citation for seeing this in the wild, > this would be detected by the segment_length field > > 5. coalescing > see (4) > > 6. modifying the data > this would interfere with in-band mechanisms as well > > ---- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jul 24 03:05:28 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D3C1A87E8 for ; Fri, 24 Jul 2015 03:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-mEBWi6o3Rv for ; Fri, 24 Jul 2015 03:05:24 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 603951A8761 for ; Fri, 24 Jul 2015 03:05:24 -0700 (PDT) Received: by wibud3 with SMTP id ud3so20838206wib.0 for ; Fri, 24 Jul 2015 03:05:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oXov7jxAPwbnhEUIpA9VYEYtXcMY+pxZKT0BcsAzM/w=; b=HftERt6JZPNMk+nRSKdugpDm3ntQLq90eaSLsGtn+iGHyoZvuyXyq9kfuRbkDbZ+aj 5x3e+wSMTUjybeb6N278cO65+fXAfS+ASR8UtZawMEzfU8veOK292/H1R3b0Gisza5VW fGwfwrMiKjuDKBBr9mXtlg1iF4D0x5y43cWVUVbqfZ90IIq7VKxd08fcQFg8waA2OP1X KqCqOa96Dl869MEudnp3ZUmouiLjMqhqywPHYtRBW5H8yo7BC9yNKbr6Rizt1JUB/cPV aqbqXFmZskG5uRotaJeI1G92hcmBz7hXpIJmS+8fLElVrLXbK/yNgJNHoD4lu7p1DgOw gWbw== X-Gm-Message-State: ALoCoQmYy7QT7tOSMHNTguWoJ9NqbFQZOl0tPaj9C+tkeRnE+6cf7LhBbIT/xy0Q/4gQa3vZQfxK MIME-Version: 1.0 X-Received: by 10.180.9.168 with SMTP id a8mr5735994wib.77.1437732322996; Fri, 24 Jul 2015 03:05:22 -0700 (PDT) Received: by 10.194.23.102 with HTTP; Fri, 24 Jul 2015 03:05:22 -0700 (PDT) In-Reply-To: <55B15610.1020300@isi.edu> References: <55A811B2.2080302@isi.edu> <55B15610.1020300@isi.edu> Date: Fri, 24 Jul 2015 12:05:22 +0200 Message-ID: From: Olivier Bonaventure To: Joe Touch Content-Type: multipart/alternative; boundary=001a11c24750650399051b9c2455 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-bonaventure-mptcp-long-options-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:05:26 -0000 --001a11c24750650399051b9c2455 Content-Type: text/plain; charset=UTF-8 Joe, > I raised concerns with in-band options when MPTCP was being proposed in > Stockholm. It's worrisome that it's gone back to including that because > it decouples TCP signaling from the segment boundaries, only creates > mutual escalation (once middleboxes understand it they'll surely tamper > with it) and invites "TCP over TCP" ultimately. The growing deployment of MPTCP shows that this decision was not too bad from a deployment viewpoint.. > Many of the assertions of what works and does not through middleboxes is > from the Honda IMC11 paper, which we already know failed to confirm many > of the issues claimed in this summary. > > Joe > > --- > > Of the issues raised: > > 1. blindly echoing SYN options > already applies to other widely-deployed options (SACK, WSCALE) > trivial to address by flipping at least one bit in the > EDO-capable option response > There is a difference between known options and new options. Middleboxes do not treat them in the same manner. > > 2. modified SYN-ACK > we don't use EDO until both sides confirm after the TWHS > for this reason > > 3. blind removal > despite no citation for seeing this in the wild, > the most recent EDO includes a segment_length field that > will detect such tampering > As an example, consider the configuration of one deployed TCP normalizer http://www.cisco.com/c/en/us/td/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/security/guide/securgd/tcpipnrm.html#wp1010795 Clearly, it could reject packets with some options or clear the option based on their type. This is because of this type of configuration that MPTCP has opted for a single option type and different suboptions. EDO uses two different option types and there is thus a risk that EDORequest passes in the SYN but not EDO in the data segments. Note that it is common for middleboxes to replace unsupported options by NOP. > 4. splitting > IMC11 explicitly stated that although middleboxes do split > and coalesce segments, none did so while passing unknown > options > > despite no citation for seeing this in the wild, > this would be detected by the segment_length field > But TSO usually copies the options to all packets that are segmented. > > 5. coalescing > see (4) > > 6. modifying the data > this would interfere with in-band mechanisms as well > > > This is part of most NAT implementations that are deployed Olivier --001a11c24750650399051b9c2455 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Joe,


I raised concerns with in-band options when MPTCP was being proposed in
Stockholm. It's worrisome that it's gone back to including that bec= ause
it decouples TCP signaling from the segment boundaries, only creates
mutual escalation (once middleboxes understand it they'll surely tamper=
with it) and invites "TCP over TCP" ultimately.
=
The growing deployment of MPTCP shows that this decision was= not too bad from a deployment viewpoint..
=C2=A0
Many of the assertions of what works and does not through middleboxes is from the Honda IMC11 paper, which we already know failed to confirm many of the issues claimed in this summary.

Joe

---

Of the issues raised:

1. blindly echoing SYN options
=C2=A0 =C2=A0 =C2=A0 =C2=A0 already applies to other widely-deployed option= s (SACK, WSCALE)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 trivial to address by flipping at least one bit= in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 EDO-capable option response

There is a difference between known options and new option= s. Middleboxes do not treat them in the same manner.
=C2=A0
=

2. modified SYN-ACK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 we don't use EDO until both sides confirm a= fter the TWHS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for this reason

3. blind removal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 despite no citation for seeing this in the wild= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the most recent EDO includes a segment_length f= ield that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 will detect such tampering

As an example, consider the configuration of one deployed T= CP normalizer


Clearly, it could reject packets with so= me options or clear the option based on their type. This is because of this= type of configuration that MPTCP has opted for a single option type and di= fferent suboptions. EDO uses two different option types and there is thus a= risk that EDORequest passes in the SYN but not EDO in the data segments. N= ote that it is common for middleboxes to replace unsupported options by NOP= .
=C2=A0
4. splitting
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IMC11 explicitly stated that although middlebox= es do split
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and coalesce segments, none did so while passin= g unknown
=C2=A0 =C2=A0 =C2=A0 =C2=A0 options

=C2=A0 =C2=A0 =C2=A0 =C2=A0 despite no citation for seeing this in the wild= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this would be detected by the segment_length fi= eld

But TSO usually copies the options = to all packets that are segmented.
=C2=A0

5. coalescing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 see (4)

6. modifying the data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this would interfere with in-band mechanisms as= well



This is part of most NAT implement= ations that are deployed


Olivier=C2= =A0

--001a11c24750650399051b9c2455-- From nobody Fri Jul 24 04:39:57 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4F61A90E9 for ; Fri, 24 Jul 2015 04:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3Br4MXgYBPaZ for ; Fri, 24 Jul 2015 04:39:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 5A17B1A9034 for ; Fri, 24 Jul 2015 04:39:53 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id DC4F1100D696F for ; Fri, 24 Jul 2015 11:39:48 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6OBdpwG014497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 24 Jul 2015 13:39:51 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 24 Jul 2015 13:39:51 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: WG acceptance of draft-bensley-tcpm-dctcp Thread-Index: AdDGBXHBGm9udrRFSKiDGmxBaNoikw== Date: Fri, 24 Jul 2015 11:39:50 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48439C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] WG acceptance of draft-bensley-tcpm-dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 11:39:55 -0000 Hi all, In the meeting on Wednesday, we had unanimous support for accepting draft-b= ensley-tcpm-dctcp as new informational document in TCPM, and we had strong = consensus that the document should have the title "Datacenter TCP (DCTCP): = TCP Congestion Control for Datacenters". The scope is to accurately documen= t the protocol that has been implemented and deployed. This e-mail intends to confirm that it is consensus in the TCPM community t= o work on this document and to add a corresponding new milestone to the TCP= M charter. My suggestion for the charter milestone would be:=20 Apr 2016 Submit document on Datacenter TCP (DCTCP) to the IESG for public= ation as Informational RFC If you have any feedback or suggestions, please speak up in the next two we= eks. Thanks Michael From nobody Fri Jul 24 09:58:59 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0E61A0004 for ; Fri, 24 Jul 2015 09:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IuoLF19YHx6L for ; Fri, 24 Jul 2015 09:58:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335801A002F for ; Fri, 24 Jul 2015 09:58:56 -0700 (PDT) Received: from [128.9.184.135] ([128.9.184.135]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6OGwJNE004580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Jul 2015 09:58:20 -0700 (PDT) To: Yoshifumi Nishida References: <55A811B2.2080302@isi.edu> <55B15610.1020300@isi.edu> From: Joe Touch Message-ID: <55B26EAB.7010900@isi.edu> Date: Fri, 24 Jul 2015 09:58:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 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: Cc: "tcpm@ietf.org" , touch@isi.edu Subject: Re: [tcpm] draft-bonaventure-mptcp-long-options-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 16:58:58 -0000 On 7/23/2015 9:13 PM, Yoshifumi Nishida wrote: > Hi Joe, > > One question. > The IMC paper you mentioned describes TSO cases that copied the > options to all the split segments. To quote from the discussion of that issue in that paper: "None passed options to the split segments". > Can't we count it into "seeing this in the wild"? It's not that splitting or coalescing isn't seen in the wild; it's that in all cases reported from the wild in that paper either: - unknown options are not reflected in the SYN-ACK - options are not copied to the split segments Joe From nobody Fri Jul 24 10:48:57 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755BC1A86F6 for ; Fri, 24 Jul 2015 10:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 O6NPSmLI54P0 for ; Fri, 24 Jul 2015 10:48:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51F71A86F5 for ; Fri, 24 Jul 2015 10:48:53 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6OHmDmv012758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Jul 2015 10:48:16 -0700 (PDT) To: Olivier Bonaventure References: <55A811B2.2080302@isi.edu> <55B15610.1020300@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55B27A5D.9040902@isi.edu> Date: Fri, 24 Jul 2015 10:48:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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: Cc: "tcpm@ietf.org" , touch@isi.edu Subject: Re: [tcpm] draft-bonaventure-mptcp-long-options-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 17:48:55 -0000 On 7/24/2015 3:05 AM, Olivier Bonaventure wrote: > Joe, > > > I raised concerns with in-band options when MPTCP was being proposed in > Stockholm. It's worrisome that it's gone back to including that because > it decouples TCP signaling from the segment boundaries, only creates > mutual escalation (once middleboxes understand it they'll surely tamper > with it) and invites "TCP over TCP" ultimately. > > The growing deployment of MPTCP shows that this decision was not too bad > from a deployment viewpoint.. You cannot draw that conclusion from one data point over this short period of time. ... > --- > > Of the issues raised: > > 1. blindly echoing SYN options > already applies to other widely-deployed options (SACK, WSCALE) > trivial to address by flipping at least one bit in the > EDO-capable option response > > There is a difference between known options and new options. Middleboxes > do not treat them in the same manner. Blind implies new, at least to the middlebox. > 2. modified SYN-ACK > we don't use EDO until both sides confirm after the TWHS > for this reason > > 3. blind removal > despite no citation for seeing this in the wild, > the most recent EDO includes a segment_length field that > will detect such tampering > > As an example, consider the configuration of one deployed TCP normalizer > > http://www.cisco.com/c/en/us/td/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/security/guide/securgd/tcpipnrm.html#wp1010795 > > Clearly, it could reject packets with some options or clear the option > based on their type. It could also change TCP into UDP. > This is because of this type of configuration that > MPTCP has opted for a single option type and different suboptions. I recall only the need to conserve TCP options for that decision. > EDO > uses two different option types It uses one codepoint with a variable length. We refer to them as different options in the text but the difference is determined by the length only. > and there is thus a risk that EDORequest > passes in the SYN but not EDO in the data segments. Note that it is > common for middleboxes to replace unsupported options by NOP. That would be detected during the SYN-ACK and EDO would not be used on the connection - again, because we're using only one codepoint throughout. > 4. splitting > IMC11 explicitly stated that although middleboxes do split > and coalesce segments, none did so while passing unknown > options > > despite no citation for seeing this in the wild, > this would be detected by the segment_length field > > But TSO usually copies the options to all packets that are segmented. The IMC11 paper noted that no options were copied to the split segment. That would be detected by EDO as a failure because EDO is required on all segments once negotiated. > 5. coalescing > see (4) > > 6. modifying the data > this would interfere with in-band mechanisms as well > > This is part of most NAT implementations that are deployed For only a very small set of protocols where the contents refer to the endpoint addresses in-band, e.g., some teleconferencing and active FTP. Depending on the extent of the translation, that could corrupt any in-band information (including the protocol the NAT is trying to help through translation). Joe From nobody Fri Jul 24 13:48:01 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8575C1A883A for ; Fri, 24 Jul 2015 13:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 49kVjpHx64hf for ; Fri, 24 Jul 2015 13:47:59 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 794101A88CE for ; Fri, 24 Jul 2015 13:47:57 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6OKlNcU007793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Jul 2015 13:47:24 -0700 (PDT) To: gorry@erg.abdn.ac.uk, tcpm@ietf.org References: <55AF8092.3020306@erg.abdn.ac.uk> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55B2A45B.60403@isi.edu> Date: Fri, 24 Jul 2015 13:47:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55AF8092.3020306@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [tcpm] Some text on updating what "RFC 793 says that the Reserved fields" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 20:48:00 -0000 Hi, Gorry, On 7/22/2015 4:37 AM, Gorry Fairhurst wrote: > If the group thinks that TCP reserved fields need to be handled in the > normal IETF protocol way, there is a standards-track RFC that would > kindof support this: > > RFC3360: Inappropriate TCP Resets Considered Harmful (BCP: 60) from > 2002, see "2.1. The TCP Reserved Field": > ... > ...However, the > phrasing in RFC 793 does not permit sending resets in response to TCP > packets with a non-zero Reserved field, as is explained in the > section above. This RFC basically gives a good reason NOT to handle this in a "normal IETF protocol way" - you've basically doomed the connection to failing to generate RSTs for legacy code, which means it's not safe. There is an exception, which would be: MUST NOT use those bits until support for them has been confirmed via the TWHS However, once negotiated, the point of "ignore if not supported" becomes irrelevant. AFAICT, there's thus no useful way to update RFC793 on how these bits are interpreted if not supported. Joe From nobody Fri Jul 24 13:58:49 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB311A8868 for ; Fri, 24 Jul 2015 13:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VhlEi7E0lxDx for ; Fri, 24 Jul 2015 13:58:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18FA1A8A60 for ; Fri, 24 Jul 2015 13:58:42 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6OKvlSg009480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Jul 2015 13:57:49 -0700 (PDT) To: gorry@erg.abdn.ac.uk, tcpm@ietf.org References: <55AF8092.3020306@erg.abdn.ac.uk> <55B2A45B.60403@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55B2A6CB.7060701@isi.edu> Date: Fri, 24 Jul 2015 13:57:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55B2A45B.60403@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [tcpm] Some text on updating what "RFC 793 says that the Reserved fields" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 20:58:48 -0000 Hi, all, Going back to RFC3360 in more detail, let me correct my previous note and clarify: - I misinterpreted RFC3360 to say that "it wasn't possible to send RSTs on connections with Reserved bits set" it says that TCP should not send a RST *only because* those bits are set - IMO, it's OK to define these fields as sender MUST zero if not supported receiver MUST ignore if not supported HOWEVER that also implies that these bits would only be useful for optional capabilities with silent failure. I.e., considering the possibilities when it comes to unused fields: QUIET) sender MUST zero if not supported receiver MUST ignore if not supported LOUD) sender MUST zero if not supported receiver MUST tell the sender if not zero ` and not supported that error can be "SOFT" or "HARD" SOFT - ignore the segment, but tell the sender HARD - kill the connection (which should inform the sender too) RFC3360 allows for QUIET errors but not LOUD ones. QUIET errors support soft, unidirectional signals only. If use of these bits is negotiated in advance (e.g., as with ECN), then none of this matters. Those bits can be defined as QUIET, LOUD/HARD or LOUD/SOFT at negotiation time. I.e., I don't mind updating RFC793 if needed, but I think it's a bit more complex than just "set to zero/ignore if not supported". Joe On 7/24/2015 1:47 PM, Joe Touch wrote: > Hi, Gorry, > > On 7/22/2015 4:37 AM, Gorry Fairhurst wrote: >> If the group thinks that TCP reserved fields need to be handled in the >> normal IETF protocol way, there is a standards-track RFC that would >> kindof support this: >> >> RFC3360: Inappropriate TCP Resets Considered Harmful (BCP: 60) from >> 2002, see "2.1. The TCP Reserved Field": >> > ... >> ...However, the >> phrasing in RFC 793 does not permit sending resets in response to TCP >> packets with a non-zero Reserved field, as is explained in the >> section above. > > This RFC basically gives a good reason NOT to handle this in a "normal > IETF protocol way" - you've basically doomed the connection to failing > to generate RSTs for legacy code, which means it's not safe. > > There is an exception, which would be: > > MUST NOT use those bits until support for them has been > confirmed via the TWHS > > However, once negotiated, the point of "ignore if not supported" becomes > irrelevant. > > AFAICT, there's thus no useful way to update RFC793 on how these bits > are interpreted if not supported. > > Joe > From nobody Sat Jul 25 05:55:20 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C158D1B2DF6 for ; Sat, 25 Jul 2015 05:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 snRUC-zqQMrr for ; Sat, 25 Jul 2015 05:55:15 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07311B2DEF for ; Sat, 25 Jul 2015 05:55:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,542,1432623600"; d="scan'208";a="58255767" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx144-out.netapp.com with ESMTP; 25 Jul 2015 05:50:13 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sat, 25 Jul 2015 05:50:13 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::1438:d6b8:afb:4959%21]) with mapi id 15.00.1076.000; Sat, 25 Jul 2015 05:50:12 -0700 From: "Scheffenegger, Richard" To: Joe Touch , "gorry@erg.abdn.ac.uk" , "tcpm@ietf.org" Thread-Topic: [tcpm] Some text on updating what "RFC 793 says that the Reserved fields" Thread-Index: AQHQxlIK2tyl5vIS2Ui3PDz28oy6Ip3rj36AgACTZ8A= Date: Sat, 25 Jul 2015 12:50:11 +0000 Message-ID: <55da585cafa14579ad16ed5c82c2fd96@hioexcmbx05-prd.hq.netapp.com> References: <55AF8092.3020306@erg.abdn.ac.uk> <55B2A45B.60403@isi.edu> <55B2A6CB.7060701@isi.edu> In-Reply-To: <55B2A6CB.7060701@isi.edu> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Some text on updating what "RFC 793 says that the Reserved fields" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 12:55:17 -0000 Hi Joe, I think it warrants clarification with 2119 wording in an update in any cas= e - including during SYN. Even for the ECN bits (ECE, CWR; NS) we observed behaviors of QUIET (majori= ty) and LOUD/HARD (minority) in the wild, for SYNs, when ECN is not support= ed; And to be more exact, that affects both sets [ECE,CWR] and [NS] indepen= dently from each other... More clarity for an implementer is needed. Best regards, Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Freitag, 24. Juli 2015 22:58 > To: gorry@erg.abdn.ac.uk; tcpm@ietf.org > Cc: touch@isi.edu > Subject: Re: [tcpm] Some text on updating what "RFC 793 says that the > Reserved fields" >=20 > Hi, all, >=20 > Going back to RFC3360 in more detail, let me correct my previous note > and clarify: >=20 > - I misinterpreted RFC3360 to say that "it wasn't possible to send RSTs > on connections with Reserved bits set" > it says that TCP should not send a RST *only because* those > bits are set >=20 > - IMO, it's OK to define these fields as > sender MUST zero if not supported > receiver MUST ignore if not supported >=20 > HOWEVER that also implies that these bits would only be useful > for optional capabilities with silent failure. >=20 > I.e., considering the possibilities when it comes to unused fields: >=20 > QUIET) > sender MUST zero if not supported > receiver MUST ignore if not supported >=20 > LOUD) > sender MUST zero if not supported > receiver MUST tell the sender if not zero > ` and not supported >=20 > that error can be "SOFT" or "HARD" > SOFT - ignore the segment, but tell the sender > HARD - kill the connection (which should inform > the sender too) >=20 > RFC3360 allows for QUIET errors but not LOUD ones. QUIET errors support > soft, unidirectional signals only. >=20 > If use of these bits is negotiated in advance (e.g., as with ECN), then > none of this matters. Those bits can be defined as QUIET, LOUD/HARD or > LOUD/SOFT at negotiation time. >=20 > I.e., I don't mind updating RFC793 if needed, but I think it's a bit > more complex than just "set to zero/ignore if not supported". >=20 > Joe >=20 > On 7/24/2015 1:47 PM, Joe Touch wrote: > > Hi, Gorry, > > > > On 7/22/2015 4:37 AM, Gorry Fairhurst wrote: > >> If the group thinks that TCP reserved fields need to be handled in the > >> normal IETF protocol way, there is a standards-track RFC that would > >> kindof support this: > >> > >> RFC3360: Inappropriate TCP Resets Considered Harmful (BCP: 60) from > >> 2002, see "2.1. The TCP Reserved Field": > >> > > ... > >> ...However, the > >> phrasing in RFC 793 does not permit sending resets in response to > TCP > >> packets with a non-zero Reserved field, as is explained in the > >> section above. > > > > This RFC basically gives a good reason NOT to handle this in a "normal > > IETF protocol way" - you've basically doomed the connection to failing > > to generate RSTs for legacy code, which means it's not safe. > > > > There is an exception, which would be: > > > > MUST NOT use those bits until support for them has been > > confirmed via the TWHS > > > > However, once negotiated, the point of "ignore if not supported" become= s > > irrelevant. > > > > AFAICT, there's thus no useful way to update RFC793 on how these bits > > are interpreted if not supported. > > > > Joe > > >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Jul 26 22:26:27 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598811A8978 for ; Sun, 26 Jul 2015 22:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.22 X-Spam-Level: * X-Spam-Status: No, score=1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Ox5VLSim2k18 for ; Sun, 26 Jul 2015 22:26:25 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046E21A896F for ; Sun, 26 Jul 2015 22:26:24 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5628C278117 for ; Mon, 27 Jul 2015 14:26:23 +0900 (JST) Received: by oihq81 with SMTP id q81so46074081oih.2 for ; Sun, 26 Jul 2015 22:26:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.78.21 with SMTP id c21mr10994889oib.76.1437974781886; Sun, 26 Jul 2015 22:26:21 -0700 (PDT) Received: by 10.202.177.193 with HTTP; Sun, 26 Jul 2015 22:26:21 -0700 (PDT) In-Reply-To: <55B26EAB.7010900@isi.edu> References: <55A811B2.2080302@isi.edu> <55B15610.1020300@isi.edu> <55B26EAB.7010900@isi.edu> Date: Sun, 26 Jul 2015 22:26:21 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-bonaventure-mptcp-long-options-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 05:26:26 -0000 Hi Joe, On Fri, Jul 24, 2015 at 9:58 AM, Joe Touch wrote: > > > On 7/23/2015 9:13 PM, Yoshifumi Nishida wrote: >> Hi Joe, >> >> One question. >> The IMC paper you mentioned describes TSO cases that copied the >> options to all the split segments. > > To quote from the discussion of that issue in that paper: > > "None passed options to the split segments". > >> Can't we count it into "seeing this in the wild"? > > It's not that splitting or coalescing isn't seen in the wild; it's that > in all cases reported from the wild in that paper either: > > - unknown options are not reflected in the SYN-ACK > - options are not copied to the split segments> Well, if we don't think about TSO, the above sentences are right. However, If EDO needs to support TSO/LRO, I'm not sure if we can ignore the NIC behavior that have been observed. Thanks, -- Yoshi From nobody Mon Jul 27 13:39:50 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEAC1B33B9 for ; Mon, 27 Jul 2015 13:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 844Ed94tXvLn for ; Mon, 27 Jul 2015 13:39:48 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9BA1B33B1 for ; Mon, 27 Jul 2015 13:39:48 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t6RKd23H011220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jul 2015 13:39:10 -0700 (PDT) To: Yoshifumi Nishida References: <55A811B2.2080302@isi.edu> <55B15610.1020300@isi.edu> <55B26EAB.7010900@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55B696E6.1090105@isi.edu> Date: Mon, 27 Jul 2015 13:39:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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: Cc: "tcpm@ietf.org" , touch@isi.edu Subject: Re: [tcpm] draft-bonaventure-mptcp-long-options-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 20:39:50 -0000 On 7/26/2015 10:26 PM, Yoshifumi Nishida wrote: > Hi Joe, > > On Fri, Jul 24, 2015 at 9:58 AM, Joe Touch wrote: >> >> >> On 7/23/2015 9:13 PM, Yoshifumi Nishida wrote: >>> Hi Joe, >>> >>> One question. >>> The IMC paper you mentioned describes TSO cases that copied the >>> options to all the split segments. >> >> To quote from the discussion of that issue in that paper: >> >> "None passed options to the split segments". >> >>> Can't we count it into "seeing this in the wild"? >> >> It's not that splitting or coalescing isn't seen in the wild; it's that >> in all cases reported from the wild in that paper either: >> >> - unknown options are not reflected in the SYN-ACK >> - options are not copied to the split segments> > > Well, if we don't think about TSO, the above sentences are right. > However, If EDO needs to support TSO/LRO, Let's please be very clear: TSO/LRO needs to be compliant with TCP > I'm not sure if we can > ignore the NIC behavior that have been observed. If it's in direct contradiction to the software's documentation, isn't it very clearly a bug? Finally, TSO/LRO is an optimization that is intended to work with TCP. If TCP already knows there's a problem using TSO/LRO it can and should be disabled for that connection. When we did so, we saw no measurable impact on either TCP performance or CPU load. Which raises significant concerns as to whether TSO/LRO is even needed in many cases. Joe From nobody Tue Jul 28 06:01:55 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D901A8AA8 for ; Tue, 28 Jul 2015 06:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cUiNPsSInZCc for ; Tue, 28 Jul 2015 06:01:39 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F181A8ABA for ; Tue, 28 Jul 2015 06:01:39 -0700 (PDT) Received: from [141.85.37.157] (helo=[10.10.1.6]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (C.Raiciu authenticated) (Exim 4.54) id 1ZK4Vb-000MDo-VI; Tue, 28 Jul 2015 14:01:28 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Costin Raiciu In-Reply-To: <55B696E6.1090105@isi.edu> Date: Tue, 28 Jul 2015 16:01:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <84A0731D-B6D2-45D3-A207-A929A0664C68@cs.ucl.ac.uk> References: <55A811B2.2080302@isi.edu> <55B15610.1020300@isi.edu> <55B26EAB.7010900@isi.edu> <55B696E6.1090105@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-bonaventure-mptcp-long-options-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 13:01:46 -0000 > Finally, TSO/LRO is an optimization that is intended to work with TCP. > If TCP already knows there's a problem using TSO/LRO it can and should > be disabled for that connection. >=20 > When we did so, we saw no measurable impact on either TCP performance = or > CPU load. Which raises significant concerns as to whether TSO/LRO is > even needed in many cases. You can=E2=80=99t just disable TSO/LRO for 10Gbps NICs. With TSO, a = single TCP connection easily reaches 10Gbps; without it you only get = 4Gbps, and you max out one CPU core - as my student=E2=80=99s tests = show. If there=E2=80=99s anything we have learnt from trying to get MPTCP = upstreamed in the Linux kernel, is that it can=E2=80=99t affect the = performance of the TCP stack. If MPTCP is compiled in and not used, the = TCP stack should work exactly as it did before. For EDO, in particular, = this means that no-one will ever enable it because the performance hit = for servers is terrible. You can always scream abuse at TSO/LRO, but this won=E2=80=99t change = anything I am afraid - even if NIC vendors change their TSO = implementation, having a concerted hardware upgrade seems highly = unlikely. You can, however, achieve 10Gbps with software segmentation offloading / = coalescing at slightly higher CPU costs than hardware offloading. This = is called GSO/GRO in linux, see details here: = http://www.linuxfoundation.org/collaborate/workgroups/networking/gso. If = you really want to use EDO in its current form, changing GSO/LRO support = and upstreaming it is the best bet. However, this deployment path is = also difficult - unless everyone upgrades their kernel at the same, you = will either have a) fraction of servers with EDO support but broken by = TSO or b) EDO servers that are dead slow. So, my advice would also be to redesign EDO to play nice with TSO/LRO - = that=E2=80=99s the only hope for adoption. Cheers. Costin >=20 > Joe >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jul 28 07:31:36 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28C61AC39E for ; Tue, 28 Jul 2015 07:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VqeK5UAf7-Vr for ; Tue, 28 Jul 2015 07:31:33 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844231A92E5 for ; Tue, 28 Jul 2015 07:31:33 -0700 (PDT) Received: from [141.85.37.157] (helo=[10.10.1.6]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (C.Raiciu authenticated) (Exim 4.54) id 1ZK5ug-000MKi-Bw for tcpm@ietf.org; Tue, 28 Jul 2015 15:31:26 +0100 From: Costin Raiciu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 28 Jul 2015 17:31:29 +0300 To: "tcpm@ietf.org (tcpm@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [tcpm] Next steps for sednbuffer advertising X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 14:31:34 -0000 Dear all, In Prague I presented a proposal for TCP to include sendbuffer = information in every segment (the amount of backlogged bytes) to help = networks and receivers with various optimizations.=20 As sendbuffer advertising is a sender-only modification, we have argued = it needs no negotiation in the three way handshake. Once it is turned = on, the relevant information will be added to outgoing data segments, = and the receiver or the network can use that information if they know = about sendbuffer advertising. Otherwise, they should not be impacted at = all. We have proposed two ways of encoding sendbuffer information:=20 - in a TCP option on data segments, opportunistically when there is = space in the options field - this option is for Internet deployment.=09 - by scavenging the ACK field and/or the receive window field, and by = defining a new =E2=80=9CSendbuffer advertisting flag=E2=80=9D - this = option is targeted for datacenter deployment. My slot was the next to last in TCPM and there was not enough time for = discussions. That is I would like to ask TCPM-ers: 1) do you find sendbuffer advertising useful - should something like = this be standardised? 2) do you agree/like/dislike the encoding(s) we have proposed, or do you = have beter alternatives? Thanks. Costin= From nobody Tue Jul 28 08:34:44 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040AD1ACD07 for ; Tue, 28 Jul 2015 08:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.221 X-Spam-Level: * X-Spam-Status: No, score=1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 XnLEtZLKpMfU for ; Tue, 28 Jul 2015 08:34:40 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261591ACCFB for ; Tue, 28 Jul 2015 08:34:39 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 03767278117 for ; Wed, 29 Jul 2015 00:34:38 +0900 (JST) Received: by obbop1 with SMTP id op1so86984348obb.2 for ; Tue, 28 Jul 2015 08:34:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.215.226 with SMTP id ol2mr34410436obc.56.1438097676500; Tue, 28 Jul 2015 08:34:36 -0700 (PDT) Received: by 10.202.104.15 with HTTP; Tue, 28 Jul 2015 08:34:36 -0700 (PDT) In-Reply-To: <55B696E6.1090105@isi.edu> References: <55A811B2.2080302@isi.edu> <55B15610.1020300@isi.edu> <55B26EAB.7010900@isi.edu> <55B696E6.1090105@isi.edu> Date: Tue, 28 Jul 2015 08:34:36 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=001a11c2b06e2907e8051bf13520 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-bonaventure-mptcp-long-options-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 15:34:42 -0000 --001a11c2b06e2907e8051bf13520 Content-Type: text/plain; charset=UTF-8 Hi Joe, On Mon, Jul 27, 2015 at 1:39 PM, Joe Touch wrote: > > > On 7/26/2015 10:26 PM, Yoshifumi Nishida wrote: >> Hi Joe, >> >> On Fri, Jul 24, 2015 at 9:58 AM, Joe Touch wrote: >>> >>> >>> On 7/23/2015 9:13 PM, Yoshifumi Nishida wrote: >>>> Hi Joe, >>>> >>>> One question. >>>> The IMC paper you mentioned describes TSO cases that copied the >>>> options to all the split segments. >>> >>> To quote from the discussion of that issue in that paper: >>> >>> "None passed options to the split segments". >>> >>>> Can't we count it into "seeing this in the wild"? >>> >>> It's not that splitting or coalescing isn't seen in the wild; it's that >>> in all cases reported from the wild in that paper either: >>> >>> - unknown options are not reflected in the SYN-ACK >>> - options are not copied to the split segments> >> >> Well, if we don't think about TSO, the above sentences are right. >> However, If EDO needs to support TSO/LRO, > > Let's please be very clear: > > TSO/LRO needs to be compliant with TCP > >> I'm not sure if we can >> ignore the NIC behavior that have been observed. > > If it's in direct contradiction to the software's documentation, isn't > it very clearly a bug? Hmm. But, I'm not sure which document you are referring.. Could you point it out? Thanks, -- Yoshi --001a11c2b06e2907e8051bf13520 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Mon, Jul 27, 2015 at 1:39 PM, Joe Touch= <touch@isi.edu&g= t; wrote:
>
>
> On 7/26/2015 10:26 PM, Yoshifumi Nishida = wrote:
>> Hi Joe,
>>
>> On Fri, Jul 24, 2015 at = 9:58 AM, Joe Touch <t= ouch@isi.edu> wrote:
>>>
>>>
>>>= On 7/23/2015 9:13 PM, Yoshifumi Nishida wrote:
>>>> Hi Joe,=
>>>>
>>>> One question.
>>>> = The IMC paper you mentioned describes TSO cases that copied the
>>= >> options to all the split segments.
>>>
>>>= To quote from the discussion of that issue in that paper:
>>><= br>>>> "None passed options to the split segments".
&= gt;>>
>>>> Can't we count it into "seeing thi= s in the wild"?
>>>
>>> It's not that spli= tting or coalescing isn't seen in the wild; it's that
>>&g= t; in all cases reported from the wild in that paper either:
>>>= ;
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 - unknown options are not ref= lected in the SYN-ACK
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 - options= are not copied to the split segments>
>>
>> Well, if = we don't think about TSO, the above sentences are right.
>> Ho= wever, If EDO needs to support TSO/LRO,
>
> Let's please be= very clear:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 TSO/LRO needs to b= e compliant with TCP
>
>> I'm not sure if = we can
>> ignore the NIC behavior that have been observed.
>=
> If it's in direct contradiction to the software's document= ation, isn't
> it very clearly a bug?

Hm= m. But, I'm not sure which document you are referring.. Could you point= it out?

Thanks,
--
Yoshi


--001a11c2b06e2907e8051bf13520-- From nobody Tue Jul 28 10:24:38 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514881B2C8F for ; Tue, 28 Jul 2015 10:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ubOK1X6vxSdm for ; Tue, 28 Jul 2015 10:24:35 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196ED1B2C8E for ; Tue, 28 Jul 2015 10:24:35 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t6SHNW3u001494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2015 10:23:33 -0700 (PDT) To: Costin Raiciu References: <55A811B2.2080302@isi.edu> <55B15610.1020300@isi.edu> <55B26EAB.7010900@isi.edu> <55B696E6.1090105@isi.edu> <84A0731D-B6D2-45D3-A207-A929A0664C68@cs.ucl.ac.uk> From: Joe Touch Message-ID: <55B7BA94.4030305@isi.edu> Date: Tue, 28 Jul 2015 10:23:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <84A0731D-B6D2-45D3-A207-A929A0664C68@cs.ucl.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" , touch@isi.edu Subject: Re: [tcpm] draft-bonaventure-mptcp-long-options-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 17:24:37 -0000 I think we're in agreement. Here is a summary: - don't use optimizations when you don't actually need them (they represent unnecessary complexity and make assumptions that might be false) - fix bugs in the optimizations that are needed I completely agree that TCP and offload engines need better coordination and the offload engines need to make only the most conservative of assumptions possible. Again, for the case we saw for Linux, we're continuing to look into it this fall. Joe On 7/28/2015 6:01 AM, Costin Raiciu wrote: >> Finally, TSO/LRO is an optimization that is intended to work with TCP. >> If TCP already knows there's a problem using TSO/LRO it can and should >> be disabled for that connection. >> >> When we did so, we saw no measurable impact on either TCP performance or >> CPU load. Which raises significant concerns as to whether TSO/LRO is >> even needed in many cases. > > You can’t just disable TSO/LRO for 10Gbps NICs. With TSO, a single TCP connection easily reaches 10Gbps; without it you only get 4Gbps, and you max out one CPU core - as my student’s tests show. > > If there’s anything we have learnt from trying to get MPTCP upstreamed in the Linux kernel, is that it can’t affect the performance of the TCP stack. If MPTCP is compiled in and not used, the TCP stack should work exactly as it did before. For EDO, in particular, this means that no-one will ever enable it because the performance hit for servers is terrible. > > You can always scream abuse at TSO/LRO, but this won’t change anything I am afraid - even if NIC vendors change their TSO implementation, having a concerted hardware upgrade seems highly unlikely. > > You can, however, achieve 10Gbps with software segmentation offloading / coalescing at slightly higher CPU costs than hardware offloading. This is called GSO/GRO in linux, see details here: http://www.linuxfoundation.org/collaborate/workgroups/networking/gso. If you really want to use EDO in its current form, changing GSO/LRO support and upstreaming it is the best bet. However, this deployment path is also difficult - unless everyone upgrades their kernel at the same, you will either have a) fraction of servers with EDO support but broken by TSO or b) EDO servers that are dead slow. > > So, my advice would also be to redesign EDO to play nice with TSO/LRO - that’s the only hope for adoption. > > Cheers. > Costin > > > >> >> Joe >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue Jul 28 10:27:50 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4A11B2C8F for ; Tue, 28 Jul 2015 10:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Ytpq6NDpS7_S for ; Tue, 28 Jul 2015 10:27:47 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A175E1B2C8E for ; Tue, 28 Jul 2015 10:27:47 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t6SHRUF6002225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2015 10:27:32 -0700 (PDT) To: Yoshifumi Nishida References: <55A811B2.2080302@isi.edu> <55B15610.1020300@isi.edu> <55B26EAB.7010900@isi.edu> <55B696E6.1090105@isi.edu> From: Joe Touch Message-ID: <55B7BB82.5050004@isi.edu> Date: Tue, 28 Jul 2015 10:27:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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: Cc: "tcpm@ietf.org" , touch@isi.edu Subject: Re: [tcpm] draft-bonaventure-mptcp-long-options-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 17:27:48 -0000 On 7/28/2015 8:34 AM, Yoshifumi Nishida wrote: > Hi Joe, ... >> Let's please be very clear: >> >> TSO/LRO needs to be compliant with TCP >> >>> I'm not sure if we can >>> ignore the NIC behavior that have been observed. >> >> If it's in direct contradiction to the software's documentation, isn't >> it very clearly a bug? > > Hmm. But, I'm not sure which document you are referring.. Could you > point it out? I'm shifting students (the last one graduated in May; the new one starts in Sept), so I don't have that handy. The rule is "don't coalesce if the option values don't match". It clearly makes no sense to coalesce under those conditions unless you KNOW you can pick among the option values. But picking means you know what the options mean. The docs we had said (somewhere) that if there were unknown options that varied from segment to segment then coalescing would not happen. We tested that with dummy option whose values varied and coalescing still happened. That would spell disaster for a large number of options, e.g., TCP MD5, TCP-AO, MPTCP, etc. It's clearly not intended operation. Again, we're working to figure out whether we're seeing a bug in the kernel or whether this might be due to incorrect data structures we're using. Joe From nobody Wed Jul 29 07:25:34 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275C41A6F32; Wed, 29 Jul 2015 07:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 0MHdB1H61zh8; Wed, 29 Jul 2015 07:25:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA561A21BD; Wed, 29 Jul 2015 07:25:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.2.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150729142503.26474.66256.idtracker@ietfa.amsl.com> Date: Wed, 29 Jul 2015 07:25:03 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-undeployed-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 14:25:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status Authors : Alexander Zimmermann Wesley M. Eddy Lars Eggert Filename : draft-ietf-tcpm-undeployed-02.txt Pages : 8 Date : 2015-07-29 Abstract: This document reclassifies several TCP extensions and TCP-related documents that have either been superseded, never seen widespread use, or are no longer recommended for use to Historic status. The affected RFCs are RFC 675, RFC 721, RFC 761, RFC 813, RFC 816, RFC 879, RFC 896, RFC 1078, and RFC 6013. Additionally, it reclassifies RFC 700, RFC 794, RFC 814, RFC 817, RFC 872, RFC 889, RFC 964, and RFC 1071 to Informational status. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-undeployed-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-undeployed-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jgh@redhat.com Tue Jul 28 09:09:07 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF851ACDA8 for ; Tue, 28 Jul 2015 09:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mP-Tba70nKlH for ; Tue, 28 Jul 2015 09:09:05 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37B521ACD96 for ; Tue, 28 Jul 2015 09:08:50 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 1CD9633E61A for ; Tue, 28 Jul 2015 16:02:41 +0000 (UTC) Received: from desk-22-202.gsslab.fab.redhat.com (desk-22-202.gsslab.fab.redhat.com [10.33.22.202]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6SG2ct6015081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2015 12:02:40 -0400 To: tcpm@ietf.org References: From: Jeremy Harris Organization: Red Hat Message-ID: <55B7A79E.4080903@redhat.com> Date: Tue, 28 Jul 2015 17:02:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: X-Mailman-Approved-At: Wed, 29 Jul 2015 08:25:25 -0700 Subject: Re: [tcpm] Next steps for sednbuffer advertising X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: jgh@redhat.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 16:24:58 -0000 On 28/07/15 15:31, Costin Raiciu wrote: > 1) do you find sendbuffer advertising useful - should something like this be standardised? Yes, and maybe. My use-case is different: diagnosis of performance issues. I'd also like to have observability of the congestion window and the ssthresh. This would not be needed at all times, but could be enabled as needed. > 2) do you agree/like/dislike the encoding(s) we have proposed, or do you have beter alternatives? I do not like the repurposing of the ACK value, and feel that using an option would be preferable. Possibly having the option in the SYN defining the content (a descriptive string, and a number of bytes; repeated for each possible datum) would maintain future flexibility. The option in data segments would carry just a packed sequence of values. -- Jeremy From nobody Wed Jul 29 11:12:46 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C071A6F30 for ; Wed, 29 Jul 2015 11:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ClV_b84WFjtV for ; Wed, 29 Jul 2015 11:12:43 -0700 (PDT) Received: from mail-vn0-x236.google.com (mail-vn0-x236.google.com [IPv6:2607:f8b0:400c:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8851A0358 for ; Wed, 29 Jul 2015 11:12:42 -0700 (PDT) Received: by vnav141 with SMTP id v141so4178202vna.0 for ; Wed, 29 Jul 2015 11:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=FkyJNScYSh/bk1fh5gpFdWwPFy0Uhnqsdky9/wBaX6k=; b=pCt3ETGoc9lE/PXWXD7z0TAIkPzWgM9GBWjZ78P3nIXl+7eMfzEN+bsW23uDpKn6EU TlW+Ngl9/nAWUcs89qAaI9d47cxy6D3o0wR1Kt0YT+k3eN7VPfLpVP0hCBUyecRMQ9eg 4TgGHy43cPlhlNoqCNTjP+6BfB7dnkn5RyhybTSphvQtHu9oX581YleRifNepYH2SZpf hJApwA/606PrVGhmAr6rVHWhBt8/Y6+5iL162/PUD2bamyLHdAJfEQA3fDb7rXr8FnHQ By8txpQSAn2HzG0KtoLg8547KPa347M6ERcVPVxGpKbTC+ctuDAi7rWn7uTDAkZd2uXd bjlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=FkyJNScYSh/bk1fh5gpFdWwPFy0Uhnqsdky9/wBaX6k=; b=nHs+yF6Mu099/19+wViBhPPe1QsTReb2DwoulrY4E90+c/69nr0s7KqWNymBuqGJMR s6M++nXDYaEUHWMLdadvlmw2l0gwk3tf7mb8FG9n8QsXlqunrbX6M5UOK05o409znYia VOK9Q3RNVpiT4E6A/Wx6KyRE93Vvkx9u1+2JFM6D6jHidFZBEIQy2NbjzVU40gqnhs// reS0u5rv3IrVaGvtJSU+Y4JyhMjWnlM69exPT+WAwSoqWXJi0+rBtth3OpGrfY7OnV82 t8yYECUTvLHtJO1az8Q0CfJvZ5qWl8TQmXPrVJjN+4f7W8hg3fQJqSY3s3ZMsMbqa4kM davw== X-Gm-Message-State: ALoCoQkKpuUhhuYjkJ2bzAwPDJY132AStS6Ik/JVAhnrz9JwzYBNDiAPPrU7/melhsw1qUfgnB1d X-Received: by 10.52.180.3 with SMTP id dk3mr54029010vdc.32.1438193562171; Wed, 29 Jul 2015 11:12:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.83 with HTTP; Wed, 29 Jul 2015 11:12:02 -0700 (PDT) In-Reply-To: <20150729142503.26474.66256.idtracker@ietfa.amsl.com> References: <20150729142503.26474.66256.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Wed, 29 Jul 2015 11:12:02 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-undeployed-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 18:12:44 -0000 On Wed, Jul 29, 2015 at 7:25 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status > Authors : Alexander Zimmermann > Wesley M. Eddy > Lars Eggert > Filename : draft-ietf-tcpm-undeployed-02.txt > Pages : 8 > Date : 2015-07-29 > > Abstract: > This document reclassifies several TCP extensions and TCP-related > documents that have either been superseded, never seen widespread > use, or are no longer recommended for use to Historic status. The > affected RFCs are RFC 675, RFC 721, RFC 761, RFC 813, RFC 816, RFC > 879, RFC 896, RFC 1078, and RFC 6013. Additionally, it reclassifies > RFC 700, RFC 794, RFC 814, RFC 817, RFC 872, RFC 889, RFC 964, and > RFC 1071 to Informational status. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tcpm-undeployed-02 The draft looks good to me. > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-undeployed-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jul 30 02:02:21 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677C91B2D5B for ; Thu, 30 Jul 2015 02:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 u_0WEMVHp4cB for ; Thu, 30 Jul 2015 02:02:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E57BE1B2D5D for ; Thu, 30 Jul 2015 02:02:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.2.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150730090216.15754.80770.idtracker@ietfa.amsl.com> Date: Thu, 30 Jul 2015 02:02:16 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 09:02:19 -0000 Changed milestone "Submit RFC793bis document to the IESG for publication as Internet Standard", added draft-ietf-tcpm-rfc793bis to milestone. URL: https://datatracker.ietf.org/wg/tcpm/charter/ From nobody Thu Jul 30 04:47:52 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42421A8732; Thu, 30 Jul 2015 04:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 CPozGuCyiqjn; Thu, 30 Jul 2015 04:47:39 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 CC1321A6F2F; Thu, 30 Jul 2015 04:47:37 -0700 (PDT) Received: from [81.174.189.118] (port=39150 helo=[192.168.0.11]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZKmJD-0006Mm-J2; Thu, 30 Jul 2015 12:47:36 +0100 Message-ID: <55BA0ED6.8060808@bobbriscoe.net> Date: Thu, 30 Jul 2015 12:47:34 +0100 From: Bob Briscoe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: tcpm IETF list , tsvwg IETF list , tsv-area IETF list , iccrg IRTF list References: <55B77CFE.9090505@bobbriscoe.net> In-Reply-To: <55B77CFE.9090505@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------030901060405050102080506" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net Archived-At: Subject: [tcpm] Invitation to subscribe to new DCTCP Evolution mailing list: (tcpPrague@ietf.org) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 11:47:46 -0000 This is a multi-part message in MIME format. --------------030901060405050102080506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit tcpm, tsvwg, tsvarea, iccrg lists Recently, there have been developments (see URLs at end) that would make it possible to deploy scalable low-latency low-loss protocols like Data Center TCP alongside a mix of traffic, either in data centres and private networks, or even on the public Internet. One approach was demonstrated at the recent IETF in Prague, showing DCTCP giving ultra-low latency over a broadband Internet access while competing with a mix of Internet traffic on roughly equal terms. As a result of an ad hoc meeting ("Bar BoF" = Birds of a Feather) at the Prague IETF, we have formed a new mailing list. I'd like to invite you to join the list via: The idea is to ensure that those working on DCTCP implementations across platforms (Free BSD, Linux, Windows, ...) will converge on solutions that will interwork with each other and with existing traffic. Although it is under the IETF's umbrella, we hope and expect that discussion will be as much about implementation as writing standards. However, we get the benefit of the IETF's IPR disclosure rules , and of course it fits the IETF's purpose of interoperability. The draft notes of the meeting are below. And below that, is the original announcement with some context and background URLs. You can catch up on any discussion you've missed using the list archives via the link above. If you want to respond about something most relevant to tcpprague, pls avoid cross-posting to all the other lists in this announcement. Cheers Bob Briscoe -------- Forwarded Message -------- Subject: Notes: DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40, Prague Date: Tue, 28 Jul 2015 14:00:46 +0100 From: Bob Briscoe To: TCP Prague IETF List Folks, These notes have taken a week, because I've only just put my machine back together after having to rebuild the hardware a little :| _*Notes: DCTCP Evolution Bar BoF*_ 6-7pm Tue 21 Jul 2015, Budapest room, The Hilton, Prague, CZ **Summary of Actions:* *Lars E: Set up tcpprague wiki page Bob B: Request tcpprague@ietf.org mailing list, via IETF process (requires Area Director approval) Bob B: Document Rationale - initiate a para on wiki. Lars E: fwd Dagstuhl invitee list to Bob Bob B: Set up list on wiki to assign people to invite those not in the room to join. * * 18:00 Introductions - name and interest ** ***Present: Marcelo Bagnulo Braun Praveen Balasubramanian Martin Bekker Bob Briscoe Anna Brunstrom Stuart Cheshire Koen De Schepper Fabien Duchen Phil Eardley Lars Eggert Michio Honda Per Hurtig Jana Iyengar Naeem Khademi Mirja Kuehlewind Matt Mathis > Andrew McGregor Karen Nielsen Tommy Pauly Andreas Petlund > Costin Raiciu Pasi Sarolahti Richard Scheffenegger David Schinazi Randall Stewart Dave Thaler Brian Trammell > Michael Tuexen Felix Weinrank Michael Welzl Alex Zimmermann ** Scope and Agenda Bashing** *** [Non-italic text is from the materials pre-prepared by Koen De Schepper and Bob Briscoe. /Italic text summarises conversation in the room./] Meeting is covered by the standard IETF "Note Well" concerning intellectual property. *Scope*: * Evolving the e2e DCTCP protocol for use alongside existing traffic (whether in DCs, private nets or public Internet). * Primarily to get DCTCP /developers/ involved early (Windows, FreeBSD, Linux), so that whatever we decide to standardise can be implemented in parallel (Doing implementation and standardisation in series is not desirable, in whichever order). * Primarily an organisational meeting about creating a forum / community to do this work, using people's experience to know what will work best. *Not in Scope:*** * Network changes are not in scope unless they impact the list of changes needed to DCTCP * The in-network side of the solution (two approaches exist [DCttH , Judd15 ], others may follow).* ** Identifier of DCTCP-like traffic (please discuss by email, not in this meeting) /Lars E: Informational draft recording Microsoft's DCTCP should not be stalled by this, as it has value of its own. Unanimous agreement. / /Praveen S: Microsoft has offered a royalty free license for DCTCP IPR ./ /Karen N: Is DCTCP over a non-TCP transport (e.g. SCTP) in scope//? Unanimous "Yes"// / /Outcome of discussion on the features of this DCTCP-like congestion control that define this work:// / 1. /Must use ECN, but unlike RFC3168 ECN, marking is not merely equivalent to drop,// //so ECN signals can be more plentiful and sooner than drop./ 2. /P//acket rate is proportional to 1/p//, where p is the ECN marking probability. // / /Matt M: 1/p makes congestion control scale with the bandwidth, //by making//the intensity of congestion control signals per RTT invariant//./ // /Stuart Ch: Apple is turning on ECN by default in clients. Currently in developer seeds but probably in the next releases. Packet loss is also not a mystery./ ** 18:15 List of /must-have/ changes before deployment alongside existing traffic.** *** /Matt M: Rather than a "MUST-have" list, produce a prioritised list, because where to draw the necessity line could depend on the use-case.// / The following list wasn't formally prioritised in the meeting, but items where some people questioned necessity are shifted down. 1. Fall back to Reno or Cubic behaviour on loss; /For how long?//quick consensus: 1 RTT, but needs further discussion. ECN response continues to operate in parallel./ 2. Negotiate altered feedback semantics, to convey the extent of ECN marking, not just its existence, and this feedback needs to be robust to loss [RFC-to-be 7560 ]; /Mirja K, Richard S & Bob B plan to have spec of much simpler solution out soon. / 3. Use of a standardised packet identifier (if ECN-capable is not enough) /Identifier tbd. /*/- - - 8< - - - - - - - - highest line between "must-have for safety" and "would be nice for performance" - - - - - - 8< - - - -/* 4. Handle a window of less than 2 when the RTT is low, rather than increase the queue [TCP-sub-mss-cwnd ], like TCP Nice . /Michael W: Is this "must-have"? Quite a complicated step. // //Bob B: Yes, but, otherwise DCTCP will pollute ultra-low latency queues from the start./ 5. Average ECN feedback over its own RTT, not the hard-coded RTT suitable only for data-centres, perhaps reduce cwnd by seg-size/2 per ECN Echo, like Relentless TCP [Mathis09 ]; /???: How bad would long-RTT flows be? More generally, how can we evaluate all this?/ /Bob B: With mixed RTTs, flows with RTT > a couple of ms will respond too quickly to bursts.//Whatever, it's already been implemented by Mohammad Alizadeh in Linux, and evaluated , so this is easy./ 6. Heuristic testing for classic ECN bottlenecks //The idea would be to detect a 'classic' RFC316 bottleneck by whether appreciable delay growth accompanies the marking (originally suggested by Michael W). /Bob B: Complex and slow to detect, so it would have to learn and cache for new flows - suggest this should only be a must-have if measurements prove it to be a problem - i.e. if a significant proportion of classic ECN bottlenecks //exist// //Matt M: No need for this - rate mismatch //no worse than TCP already sees with RTT discrepancies./ /* - - - 8< - - - - - - - - lowest line between "must-have for safety" and "would be nice for performance" - - - - - - 8< - - - -*/ 7. /Costin R: //Faster-than-additive increase//(similar to Cubic) //A performance improvement, not "must-have", but would be nice to have while we're doing this./ 8. /[Not discussed in the meeting, but added by Bob B for the record]: Less drastic exit from slow-start, to match less drastic rate reduction per mark.// //Currently, because marking threshold is shallow, //slow start exits earlier than with drop, unnecessarily increasing completion time.// / / //Costin R: Any other way to evolve towards DCTCP over mixed networks, without separate queues in the network?// ////Bob B: To discuss on ML, and if we continue with the proposed approach, we must record the rationale on the WIki.// /// ** 18:30 Brainstorm to identify people not present who will be important to this.** *** Mohammad Alizadeh Grenville Armitage Fred Baker Stephen Bensley Daniel Borkmann Yuchung Cheng Kenjiro Cho 邓灵莉/Lingli Deng Eric Dumazet Gorry Fairhurst Jamal Hadi Salim Glenn Judd Midori Kato Kenneth Klette Jonassen > (already subscribed) Sridharan, Murari Hiren Panchasara Hagen Pfeifer Balaji Prabhakar KK Ramakrishnan Lawrence Stewart Dave Taht Florian Westphal /Agreed to cc to the following for awareness, but no need to invite to join the list:// /Stephen Hemminger David Miller /Missing types of organisations:// / * /Network operators (not so relevant for e2e protocol, but need to be motivated to deploy the network part)/ * /CDN//s/ /[Bob B adds: Subsequent to mtg, Erik Nygren tells me Xin Zhang leads Akamai's congestion control team. Also I noticed Hiren used to work at Limelight, so may have contacts]// //// //Lars E: Co-organising a Dagstuhl retreat around DCTCP. Will forward list of invitees to Bob to notify once the ML exists.// //Also Lars's list of FreeBSD and Linux devs.// /// ** 18:40 What is the best way to ensure the outputs from a number of separate developers all converge in parallel to standardisation?** ***/Common Test Suite// //Interop//events ////Plugfests// ////Serving paths (e.g. Google's) capable of serving this/ ** 18:50 Next steps: Actions to set up suitable MLs, tools, with timesales etc.** *** /Discussed pros and cons of hosting ML on ietf.org.// //General agreement: use ietf.org for ML - because the IPR Note Well is useful. // // /Name for ML? / //Matt M: TCP Prague (for an evolving protocol, a meaningless tag is best).// //Karen N: ecn-prague, because it's not just TCP?// // //Agreed: //tcpprague@ietf.org//// // //Actions:// //Bob B: ML - ask SpencerD/MartinS, following the documented process// //Lars E: Set up wiki page - for assigning people to send out invitations// /// ** End 19:05** *** Notes: Bob Briscoe, helped by Andrew McGregor 28 Jul 2015 -------- Forwarded Message -------- Subject: DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40, Prague Date: Mon, 20 Jul 2015 22:46:14 +0100 From: Bob Briscoe To: Mirja Kuehlewind , EGGERT, Lars , Dave Thaler , Praveen Balasubramanian , Alex Zimmermann , Richard Scheffenegger , Fred Baker , Matt Mathis , Andrew McGregor , Dave Taht , Stuart Cheshire , Michael WELZL , Andreas Petlund , Gorry Fairhurst , Anna Brunstrom CC: De Schepper, Koen (Koen) Folks, DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40, Prague Location: Unless I have emailed with a room location before then, pls meet at the IETF reception. Koen & I are trying to get together people in Prague who are involved in development of DCTCP across platforms (Windows, Free BSD, Linux, etc), and who are interested in evolving it for use on heterogeneous networks, e.g. * data centres with a mix of TCP flavours, not just DCTCP * private networks * the public Internet Pls fwd this invite to anyone in Prague who ought to be involved that I've missed (pls cc everyone else too). Sorry for short notice. One purpose of the session will be to build a community beyond the IETF, so I'd like us to compose an email to a wider set of people after the session, e.g.: Stephen Bensley Glenn Judd Daniel Borkmann Florian Westphal 邓 灵莉/Lingli Deng Mohammad Alizadeh Stephen Hemminger David S. Miller Sridharan, Murari > Yuchung Cheng > Koen & Bob PS. Below is some background, and some agenda ideas. Pls discuss, bash and add your own. > We've recently developed an AQM that allows DCTCP to co-exist with > Cubic/Reno etc. with zero config. Links below. > > We have to add some necessary mechanisms to DCTCP (listed below) so it > will be safe alongside other traffic. Two questions: > > Q1. We don't want to fork DCTCP. Does anyone think a fork optimised > for homogeneous DCTCP would be better? > > Q2. Anyone interested in helping? > We have an idea how to do each one, but sharing the load would be > great - there's Linux, FreeBSD, Windows, etc. to cover. > > List of the 4 essential 'safety' mods to DCTCP (copied from the IETF > Internet Draft linked below) and one that might need to be essential: > o fall back to Reno or Cubic behaviour on loss; > > o negotiate its altered feedback semantics, which conveys the extent > of ECN marking, not just its existence, and this feedback needs to > be robust to loss [I-D.ietf-tcpm-accecn-reqs]; > > o handle a window of less than 2 when the RTT is low, rather than > increase the queue [TCP-sub-mss-w]. > > o average ECN feedback over its own RTT, not the hard-coded RTT > suitable only for data-centres, perhaps like Relentless > TCP [Mathis09]; > > > o Use of a standardised packet identifier (if ECN-capable is not enough) > > > oHeuristic testing for classic ECN bottlenecks (optional?) > > > > > We're trying to move fast because if we can get on top of other > developments (e.g. Apple's recent release of ECN), it will mean less > messy classification code in the AQM. > So the links below are not on official sites yet. > > ‘Data Centre to the Home’: Ultra-Low Latency for All > > > Highlights: > * 1ms 99%-ile queuing delay for all DCTCP traffic in thousands of > expts incl. high load, > over an e2e test network with real broadband equipment. > * DCTCP co-existence with Reno & Cubic, with no transport ID inspection. > * less ops per packet than RED > * Zero config > > IETF Draft to standardise those parts of the AQM relevant to > interop(not yet submitted to IETF): > > > Koen & Bob --------------030901060405050102080506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit tcpm, tsvwg, tsvarea, iccrg lists

Recently, there have been developments (see URLs at end) that would make it possible to deploy scalable low-latency low-loss protocols like Data Center TCP alongside a mix of traffic, either in data centres and private networks, or even on the public Internet. One approach was demonstrated at the recent IETF in Prague, showing DCTCP giving ultra-low latency over a broadband Internet access while competing with a mix of Internet traffic on roughly equal terms.

As a result of an ad hoc meeting ("Bar BoF" = Birds of a Feather) at the Prague IETF, we have formed a new mailing list.
I'd like to invite you to join the list via: <https://www.ietf.org/mailman/listinfo/tcpprague>

The idea is to ensure that those working on DCTCP implementations across platforms (Free BSD, Linux, Windows, ...) will converge on solutions that will interwork with each other and with existing traffic. Although it is under the IETF's umbrella, we hope and expect that discussion will be as much about implementation as writing standards. However, we get the benefit of the IETF's IPR disclosure rules, and of course it fits the IETF's purpose of interoperability.


The draft notes of the meeting are below.
And below that, is the original announcement with some context and background URLs.
You can catch up on any discussion you've missed using the list archives via the link above.


If you want to respond about something most relevant to tcpprague, pls avoid cross-posting to all the other lists in this announcement.


Cheers



Bob Briscoe



-------- Forwarded Message --------
Subject: Notes: DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40, Prague
Date: Tue, 28 Jul 2015 14:00:46 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: TCP Prague IETF List <tcpPrague@ietf.org>


Folks,

These notes have taken a week, because I've only just put my machine back together after having to rebuild the hardware a little :|


Notes: DCTCP Evolution Bar BoF
6-7pm Tue 21 Jul 2015, Budapest room, The Hilton, Prague, CZ

Summary of Actions:
Lars E: Set up tcpprague wiki page
Bob B: Request tcpprague@ietf.org mailing list, via IETF process (requires Area Director approval)
Bob B: Document Rationale - initiate a para on wiki.
Lars E: fwd Dagstuhl invitee list to Bob
Bob B: Set up list on wiki to assign people to invite those not in the room to join.

* 18:00 Introductions - name and interest
Present:
Marcelo    Bagnulo Braun    <marcelo@it.uc3m.es>
Praveen    Balasubramanian    <pravb@microsoft.com>
Martin    Bekker    <martin.becke@haw-hamburg.de>
Bob    Briscoe    <ietf@bobbriscoe.net>
Anna    Brunstrom    <anna.brunstrom@kau.se>
Stuart    Cheshire    <cheshire@apple.com>
Koen    De Schepper    <koen.de_schepper@alcatel-lucent.com>
Fabien    Duchen    <fabien.duchene@uclouvain.be>
Phil    Eardley    <philip.eardley@bt.com>
Lars    Eggert    <lars@netapp.com>
Michio    Honda    <michio@netapp.com>
Per    Hurtig    <Per.Hurtig@kau.se>
Jana    Iyengar    <jri@google.com>
Naeem    Khademi    <naeem.khademi@gmail.com>
Mirja    Kuehlewind    <mirja.kuehlewind@tik.ee.ethz.ch>
Matt    Mathis    <mattmathis@google.com>
Andrew    McGregor    <andrewmcgr@google.com>
Karen    Nielsen    <karen.nielsen@tieto.com>
Tommy    Pauly    <tpauly@apple.com>
Andreas Petlund <apetlund@ifi.uio.no>
Costin    Raiciu    <costin.raiciu@cs.pub.ro>
Pasi    Sarolahti    <pasi.sarolahti@iki.fi>
Richard    Scheffenegger    <rs@netapp.com>
David    Schinazi    <dschinazi@apple.com>
Randall    Stewart    <randall@lakerest.net>
Dave    Thaler    <dthaler@microsoft.com>
Brian    Trammell   <ietf@trammell.ch>
Michael    Tuexen    <Michael.Tuexen@lurchi.franken.de>
Felix    Weinrank    <weinrank@fh-munster.de>
Michael    Welzl    <michawe@ifi.uio.no>
Alex    Zimmermann    <alexander.zimmermann@netapp.com>

* Scope and Agenda Bashing
[Non-italic text is from the materials pre-prepared by Koen De Schepper and Bob Briscoe.
Italic text summarises conversation in the room.]

Meeting is covered by the standard IETF "Note Well" concerning intellectual property.

Scope:
* Evolving the e2e DCTCP protocol for use alongside existing traffic (whether in DCs, private nets or public Internet).
* Primarily to get DCTCP /developers/ involved early (Windows, FreeBSD, Linux), so that whatever we decide to standardise can be implemented in parallel
  (Doing implementation and standardisation in series is not desirable, in whichever order).
* Primarily an organisational meeting about creating a forum / community to do this work, using people's experience to know what will work best.

Not in Scope:
* Network changes are not in scope unless they impact the list of changes needed to DCTCP
* The in-network side of the solution (two approaches exist [DCttH, Judd15], others may follow).
* Identifier of DCTCP-like traffic (please discuss by email, not in this meeting)

Lars E: Informational draft recording Microsoft's DCTCP should not be stalled by this, as it has value of its own.
   Unanimous agreement.

Praveen S: Microsoft has offered a royalty free license for DCTCP IPR.

Karen N: Is DCTCP over a non-TCP transport (e.g. SCTP) in scope?
   Unanimous "Yes"

Outcome of discussion on the features of this DCTCP-like congestion control that define this work:
  1. Must use ECN, but unlike RFC3168 ECN, marking is not merely equivalent to drop,
    so ECN signals can be more plentiful and sooner than drop.
  2. Packet rate is proportional to 1/p, where p is the ECN marking probability.
Matt M: 1/p makes congestion control scale with the bandwidth, by making the intensity of congestion control signals per RTT invariant.

Stuart Ch: Apple is turning on ECN by default in clients. Currently in developer seeds but probably in the next releases.  Packet loss is also not a mystery.

* 18:15 List of /must-have/ changes before deployment alongside existing traffic.
Matt M: Rather than a "MUST-have" list, produce a prioritised list, because where to draw the necessity line could depend on the use-case.

The following list wasn't formally prioritised in the meeting, but items where some people questioned necessity are shifted down.
  1. Fall back to Reno or Cubic behaviour on loss;
    For how long? quick consensus: 1 RTT, but needs further discussion. ECN response continues to operate in parallel.
  2. Negotiate altered feedback semantics, to convey the extent of ECN marking, not just its existence, and this feedback needs to be robust to loss [RFC-to-be 7560];
    Mirja K, Richard S & Bob B plan to have spec of much simpler solution out soon.
  3. Use of a standardised packet identifier (if ECN-capable is not enough)
    Identifier tbd.
    - - - 8< - - - - - - - - highest line between "must-have for safety" and "would be nice for performance" - - - - - -  8< - - - -
  4. Handle a window of less than 2 when the RTT is low, rather than increase the queue [TCP-sub-mss-cwnd], like TCP Nice.
    Michael W: Is this "must-have"? Quite a complicated step.
    Bob B: Yes, but, otherwise DCTCP will pollute ultra-low latency queues from the start.
  5. Average ECN feedback over its own RTT, not the hard-coded RTT suitable only for data-centres, perhaps reduce cwnd by seg-size/2 per ECN Echo, like Relentless TCP [Mathis09];
    ???: How bad would long-RTT flows be?  More generally, how can we evaluate all this?
    Bob B: With mixed RTTs, flows with RTT > a couple of ms will respond too quickly to bursts. Whatever, it's already been implemented by Mohammad Alizadeh in Linux, and evaluated, so this is easy.
  6. Heuristic testing for classic ECN bottlenecks
    The idea would be to detect a 'classic' RFC316 bottleneck by whether appreciable delay growth accompanies the marking (originally suggested by Michael W).
    Bob B: Complex and slow to detect, so it would have to learn and cache for new flows - suggest this should only be a must-have if measurements prove it to be a problem - i.e. if a significant proportion of classic ECN bottlenecks     exist
    Matt M: No need for this - rate mismatch no worse than TCP already sees with RTT discrepancies.
     - - - 8< - - - - - - - - lowest line between "must-have for safety" and "would be nice for performance" - - - - - -  8< - - - -
  7. Costin R: Faster-than-additive increase (similar to Cubic)
    A performance improvement, not "must-have", but would be nice to have while we're doing this.
  8. [Not discussed in the meeting, but added by Bob B for the record]: Less drastic exit from slow-start, to match less drastic rate reduction per mark.
    Currently, because marking threshold is shallow, slow start exits earlier than with drop, unnecessarily increasing completion time.

Costin R: Any other way to evolve towards DCTCP over mixed networks, without separate queues in the network?
 Bob B: To discuss on ML, and if we continue with the proposed approach, we must record the rationale on the WIki.
* 18:30 Brainstorm to identify people not present who will be important to this.
Mohammad    Alizadeh    <alizadeh.mr@gmail.com>
Grenville    Armitage    <garmitage@swin.edu.au>
Fred    Baker    <fred@cisco.com>
Stephen    Bensley    <sbens@microsoft.com>
Daniel    Borkmann    <daniel.borkmann@alumni.ethz.ch>
Yuchung    Cheng    <ycheng@google.com>
Kenjiro    Cho    <kjc@iijlab.net>
邓灵莉/Lingli    Deng    <denglingli@chinamobile.com>
Eric    Dumazet    <edumazet@gmail.com>
Gorry    Fairhurst    <gorry@erg.abdn.ac.uk>
Jamal    Hadi Salim    <hadi@mojatatu.com>
Glenn    Judd    <glenn.judd@morganstanley.com>
Midori    Kato    <katoon@sfc.wide.ad.jp>
Kenneth    Klette Jonassen    <kennetkl@ifi.uio.no>    (already subscribed)
Sridharan,    Murari    <muraris@microsoft.com>
Hiren    Panchasara    <hiren.panchasara@gmail.com>
Hagen     Pfeifer    <hagen@jauu.net>
Balaji    Prabhakar    <balaji@ee.stanford.edu>
KK    Ramakrishnan    <kk@cs.ucr.edu>
Lawrence    Stewart    <lstewart@netflix.com>
Dave    Taht    <dave.taht@gmail.com>
Florian    Westphal    <fw@strlen.de>

Agreed to cc to the following for awareness, but no need to invite to join the list:
Stephen    Hemminger    <stephen@networkplumber.org>
David    Miller    <davem@davemloft.net>

Missing types of organisations:
  • Network operators (not so relevant for e2e protocol, but need to be motivated to deploy the network part)
  • CDNs
[Bob B adds: Subsequent to mtg, Erik Nygren tells me Xin Zhang leads Akamai's congestion control team. Also I noticed Hiren used to work at Limelight, so may have contacts]
Lars E: Co-organising a Dagstuhl retreat around DCTCP. Will forward list of invitees to Bob to notify once the ML exists.
Also Lars's list of FreeBSD and Linux devs.
* 18:40 What is the best way to ensure the outputs from a number of separate developers all converge in parallel to standardisation?
 Common Test Suite
 Interop events
 Plugfests
 Serving paths (e.g. Google's) capable of serving this

* 18:50 Next steps: Actions to set up suitable MLs, tools, with timesales etc.
Discussed pros and cons of hosting ML on ietf.org.
 General agreement: use ietf.org for ML - because the IPR Note Well is useful.

Name for ML?
Matt M: TCP Prague (for an evolving protocol, a meaningless tag is best).
Karen N: ecn-prague, because it's not just TCP?

Agreed: tcpprague@ietf.org

Actions:
 Bob B: ML - ask SpencerD/MartinS, following the documented process
 Lars E: Set up wiki page - for assigning people to send out invitations
* End 19:05

Notes: Bob Briscoe, helped by Andrew McGregor
28 Jul 2015


-------- Forwarded Message --------
Subject: DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40, Prague
Date: Mon, 20 Jul 2015 22:46:14 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: Mirja Kuehlewind <mirja.kuehlewind@tik.ee.ethz.ch>, EGGERT, Lars <lars@netapp.com>, Dave Thaler <dthaler@microsoft.com>, Praveen Balasubramanian <pravb@microsoft.com>, Alex Zimmermann <alexander.zimmermann@netapp.com>, Richard Scheffenegger <rs@netapp.com>, Fred Baker <fred@cisco.com>, Matt Mathis <matt.mathis@gmail.com>, Andrew McGregor <andrewmcgr@google.com>, Dave Taht <dave.taht@gmail.com>, Stuart Cheshire <cheshire@apple.com>, Michael WELZL <michawe@ifi.uio.no>, Andreas Petlund <andreas@petlund.no>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Anna Brunstrom <anna.brunstrom@kau.se>
CC: De Schepper, Koen (Koen) <koen.de_schepper@alcatel-lucent.com>


Folks,

DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40, Prague
Location: Unless I have emailed with a room location before then, pls meet at the IETF reception.

Koen & I are trying to get together people in Prague who are involved in development of DCTCP across platforms (Windows, Free BSD, Linux, etc), and who are interested in evolving it for use on heterogeneous networks, e.g.
* data centres with a mix of TCP flavours, not just DCTCP
* private networks
* the public Internet

Pls fwd this invite to anyone in Prague who ought to be involved that I've missed (pls cc everyone else too).

Sorry for short notice.

One purpose of the session will be to build a community beyond the IETF, so I'd like us to compose an email to a wider set of people after the session, e.g.:

Stephen Bensley <sbens@microsoft.com>
Glenn Judd <glenn.judd@morganstanley.com>
Daniel Borkmann <daniel.borkmann@alumni.ethz.ch>
Florian Westphal <fw@strlen.de>
邓 灵莉/Lingli Deng <denglingli@chinamobile.com>
Mohammad Alizadeh <alizadeh.mr@gmail.com>
Stephen Hemminger <stephen@networkplumber.org>
David S. Miller <davem@davemloft.net>
Sridharan, Murari <muraris@microsoft.com>
Yuchung Cheng <ycheng@google.com>


Koen & Bob

PS. Below is some background, and some agenda ideas. Pls discuss, bash and add your own.


We've recently developed an AQM that allows DCTCP to co-exist with Cubic/Reno etc. with zero config. Links below.

We have to add some necessary mechanisms to DCTCP (listed below) so it will be safe alongside other traffic. Two questions:

Q1. We don't want to fork DCTCP. Does anyone think a fork optimised for homogeneous DCTCP would be better?

Q2. Anyone interested in helping?
We have an idea how to do each one, but sharing the load would be great - there's Linux, FreeBSD, Windows, etc. to cover.

List of the 4 essential 'safety' mods to DCTCP (copied from the IETF Internet Draft linked below) and one that might need to be essential: 
   o  fall back to Reno or Cubic behaviour on loss;
 
   o  negotiate its altered feedback semantics, which conveys the extent
      of ECN marking, not just its existence, and this feedback needs to
      be robust to loss [I-D.ietf-tcpm-accecn-reqs];
 
   o  handle a window of less than 2 when the RTT is low, rather than
      increase the queue [TCP-sub-mss-w].
 
   o  average ECN feedback over its own RTT, not the hard-coded RTT
      suitable only for data-centres, perhaps like Relentless
      TCP [Mathis09];


   o  Use of a standardised packet identifier (if ECN-capable is not enough)


   o  Heuristic testing for classic ECN bottlenecks (optional?)

We're trying to move fast because if we can get on top of other developments (e.g. Apple's recent release of ECN), it will mean less messy classification code in the AQM.
So the links below are not on official sites yet.

‘Data Centre to the Home’: Ultra-Low Latency for All
<http://www.bobbriscoe.net/projects/latency/dctth_preprint.pdf>

Highlights:
* 1ms 99%-ile queuing delay for all DCTCP traffic in thousands of expts incl. high load,
   over an e2e test network with real broadband equipment.
* DCTCP co-existence with Reno & Cubic, with no transport ID inspection.
* less ops per packet than RED
* Zero config

IETF Draft to standardise those parts of the AQM relevant to interop (not yet submitted to IETF):
<http://www.bobbriscoe.net/projects/latency/draft-briscoe-aqm-dualq-coupled-00.txt>



Koen & Bob

--------------030901060405050102080506-- From nobody Fri Jul 31 06:52:58 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399B11A8860 for ; Fri, 31 Jul 2015 06:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 Qz2NpmEz9xeU for ; Fri, 31 Jul 2015 06:52:55 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id D7F981A1B20 for ; Fri, 31 Jul 2015 06:52:54 -0700 (PDT) Received: from t40700-la020.org.aalto.fi (130.233.145.130) by kirsi2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 5511FF6A00FF04B9 for tcpm@ietf.org; Fri, 31 Jul 2015 16:52:53 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3C5AD4D0-3AE1-45CA-B93E-E06935E3F99D@iki.fi> Date: Fri, 31 Jul 2015 16:52:54 +0300 To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 13:52:57 -0000 Hi, The tcpm-undeployed draft has been on hold for a while, but we now = believe it is ok to be submitted for publication. Therefore this mail = starts a working group last call for draft-ietf-tcpm-undeployed-02 = ("Moving Outdated TCP Extensions and TCP-related Documents to Historic = and Informational Status"), to be submitted as Informational RFC. The = WGLC runs until Friday, August 21st (three weeks because of the ongoing = summer holiday period). Link to the HTML version of the document: = https://tools.ietf.org/html/draft-ietf-tcpm-undeployed-02 . Please let us know if you have any comments about the latest version. Thanks! - Pasi From nobody Fri Jul 31 10:04:39 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2D41A89C7 for ; Fri, 31 Jul 2015 10:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 3ZHXF0MbQxuz for ; Fri, 31 Jul 2015 10:04:36 -0700 (PDT) Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id B79651A892E for ; Fri, 31 Jul 2015 10:04:36 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t6VH4ZXK007468 for ; Fri, 31 Jul 2015 13:04:35 -0400 Received: (qmail 19471 invoked by uid 0); 31 Jul 2015 17:04:35 -0000 X-TCPREMOTEIP: 24.166.126.82 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.135?) (wes@mti-systems.com@24.166.126.82) by 0 with ESMTPA; 31 Jul 2015 17:04:35 -0000 To: Pasi Sarolahti , "tcpm@ietf.org Extensions" References: <3C5AD4D0-3AE1-45CA-B93E-E06935E3F99D@iki.fi> From: Wesley Eddy X-Enigmail-Draft-Status: N1110 Organization: MTI Systems Message-ID: <55BBAA9D.9010907@mti-systems.com> Date: Fri, 31 Jul 2015 13:04:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <3C5AD4D0-3AE1-45CA-B93E-E06935E3F99D@iki.fi> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-undeployed-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:04:38 -0000 On 7/31/2015 9:52 AM, Pasi Sarolahti wrote: > Hi, > > The tcpm-undeployed draft has been on hold for a while, but we now believe it is ok to be submitted for publication. Therefore this mail starts a working group last call for draft-ietf-tcpm-undeployed-02 ("Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status"), to be submitted as Informational RFC. The WGLC runs until Friday, August 21st (three weeks because of the ongoing summer holiday period). > > Link to the HTML version of the document: https://tools.ietf.org/html/draft-ietf-tcpm-undeployed-02 . > > Please let us know if you have any comments about the latest version. > One reason it was held up, was to get feedback from the IESG on our handling of the documents pre-dating the status field, and that's resolved now. My only small feedback is that I think we definitely should call out the TCPMUX part in the shepherd writeup or IETF LC text, since it has been discussed on the IETF main list in the past, and should be reviewed by applications-oriented people. What we did is clearly the right thing for TCP (IMO), but someone out there may disagree, and we'd rather discuss with them during last call than after an RFC is out :). In a couple of places, we could make an editorial change: "SHOULD not longer" -> "SHOULD NOT be". -- Wes Eddy MTI Systems