From Michael.Scharf@alcatel-lucent.com Fri Apr 1 00:05:42 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1A43A6BD7 for ; Fri, 1 Apr 2011 00:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJnN1lGJxXpo for ; Fri, 1 Apr 2011 00:05:42 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id CF95F3A6B04 for ; Fri, 1 Apr 2011 00:05:41 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p3177IE3024064; Fri, 1 Apr 2011 09:07:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF03B.6FC56A5B" Date: Fri, 1 Apr 2011 09:07:17 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C026F62E6@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00? Thread-index: AcvwGcYfatRmJa6gTIef2Rkk0J/iKQAHzRgG References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de><1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no><5FDC413D5FA246468C200652D63E627A0D9D5908@LDCMVEXC1-PRD.hq.netapp.com> From: "SCHARF, Michael" To: "Matt Mathis" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 07:05:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF03B.6FC56A5B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Matt, > When you said "interest", did you actually mean as a WG item? You > didn't quite ask the question. > > We plan to update the document and bring it to the next IETF in any > case, and we know of a number of individuals who have expressed > interest. It would be excellent to have an update that addresses the comments on = the list. > My only reservation with making it a WG item is that we expect to > broaden the scope somewhat, and the current file and document names > may not be appropriate. As long as a future scope changes are not a > problem, a WG item would be preferred. Could you please detail these expected scope changes? Thanks Michael ------_=_NextPart_001_01CBF03B.6FC56A5B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [tcpm] Interest = indraft-mathis-tcpm-proportional-rate-reduction-00?

Matt,

> When you said "interest", did you actually mean as a WG = item?   You
> didn't quite ask the question.
>
> We plan to update the document and bring it to the next IETF in = any
> case, and we know of  a number of individuals who have = expressed
> interest.

It would be excellent to have an update that addresses the comments on = the list.

> My only reservation with making it a WG item is that we expect = to
> broaden the scope somewhat, and the current file and document = names
> may not be appropriate.   As long as a future scope = changes are not a
> problem, a WG item would be preferred.

Could you please detail these expected scope changes?

Thanks

Michael

------_=_NextPart_001_01CBF03B.6FC56A5B-- From rs@netapp.com Fri Apr 1 00:57:34 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F3B28C139 for ; Fri, 1 Apr 2011 00:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.846 X-Spam-Level: X-Spam-Status: No, score=-9.846 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+ZKU8lEZLMz for ; Fri, 1 Apr 2011 00:57:33 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 56B7728C0EE for ; Fri, 1 Apr 2011 00:57:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,281,1299484800"; d="scan'208";a="248316664" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 01 Apr 2011 00:59:11 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p317xAAT001061; Fri, 1 Apr 2011 00:59:11 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Apr 2011 08:59:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF042.AE61AEA4" Date: Fri, 1 Apr 2011 08:59:08 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A08575329@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00? Thread-Index: AcvwKV9y4aRiH+87SmGwu9QZciYKfQAGU4O6 From: "Scheffenegger, Richard" To: X-OriginalArrivalTime: 01 Apr 2011 07:59:11.0187 (UTC) FILETIME=[AF6D3A30:01CBF042] Cc: tcpm@ietf.org, Michael.Scharf@alcatel-lucent.com, michawe@ifi.uio.no Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 07:57:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF042.AE61AEA4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgbmFuZGl0YSwNCg0KSSB1bmRlcnN0YW5kIHRoZSAiZ2xvYmFsIiBib3VuZC4gSW4gYSAoaHlw b3RoZXRpY2FsKSBzY2VuYXJpbyB3aGVyZSB0aGUgc2VuZGVyIGJlY29tZXMgYXBwIGxpbWl0ZWQg ZHVyaW5nIHRoZSBwcnItcmIgcGhhc2UsIHRoZSBzb2NrZXQgbWF5IGJlY29tZSBlbXB0eSBzaG9y dGx5LiBXaGVuIHRoZSBhcHAgY29udGludWVzLCB0aGUgc2VuZGVyIG1heSBjbG9jayBvdXQgYSBs YXJnZXIgYnVyc3QuIA0KDQpJaXJjLCBsaW51eCBoYXMgYW5vdGhlciBjbGFtcCBhdCBubyBtb3Jl IHRoYW4gMyBzZWcvYWNrIGR1cmluZyBsb3NzIHJlY292ZXJ5Li4uDQoNCkltaG8gc3VjaCBhIHNl Y29uZGFyeSBjbGFtcCBtYWtlcyBzZW5zZSB0byBhbGxldmlhdGUgYnVyc3RzIGFmdGVyIGFwcCBz dGFsbHMNCg0KVGhhdCdzIHRoZSBiYWNrZ3JvdW5kIG9mIG15IHF1ZXN0aW9uDQoNClJpY2hhcmQN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVm9uOiBOYW5kaXRhIER1a2tp cGF0aSA8bmFuZGl0YWRAZ29vZ2xlLmNvbT4gDQpBbjogU2NoZWZmZW5lZ2dlciwgUmljaGFyZCAN CkNjOiBNaWNoYWVsIFdlbHpsIDxtaWNoYXdlQGlmaS51aW8ubm8+OyB0Y3BtQGlldGYub3JnIDx0 Y3BtQGlldGYub3JnPjsgU0NIQVJGLCBNaWNoYWVsIDxNaWNoYWVsLlNjaGFyZkBhbGNhdGVsLWx1 Y2VudC5jb20+IA0KR2VzZW5kZXQ6IEZyaSBBcHIgMDEgMDU6NTc6NDggMjAxMQ0KQmV0cmVmZjog UmU6IFt0Y3BtXSBJbnRlcmVzdCBpbmRyYWZ0LW1hdGhpcy10Y3BtLXByb3BvcnRpb25hbC1yYXRl LXJlZHVjdGlvbi0wMD8gDQoNCg0KDQoJSSB3b3VsZCBhbHNvIGJlIGludGVyZXN0ZWQgaW4gbGVh cm5pbmcgaG93IHRoZSBhbGdvcml0aG0gYmVoYXZlcywgd2hlbiBtb3JlIHRoZW4gb25lIGhhbGYg b2YgdGhlIHdpbmRvdyBpcyBsb3N0IChpZSwgdGhlcmUgYXJlbuKAmXQgZW5vdWdoIEFDS3Mgc2Vu dCBiYWNrIHRvIGNsb2NrIG91dCBlYWNoIGFsbG93ZWQgZGF0YSBzZWdtZW50IGJ5IGl04oCZcyBv d24gQUNLKS4gV2lsbCBpdCBjbG9jayBvdXQgbXVsdGlwbGUgc2VnbWVudHMgcGVyIEFDSyAoYW5k IGlmIHNvLCB3aWxsIHRoZXkgYmUgc3ByZWFkIG92ZXIgdGhlIHJlbWFpbmluZyBBQ0tzLCBzbyB0 byBsaW1pdCB0aGUgbWF4aW11bSBudW1iZXIgb2Ygc2VudCBwYWNrZXRzIHBlciBBQ0sg4oCTIG9y IHdvdWxkIFBSUi1SQiBieSBpdHNlbGYgYWxsb3cgYSBidXJzdCBvZiBwYWNrZXRzIGJlaW5nIGNs b2NrZWQgb3V0IGJ5IGEgc2luZ2xlIEFDSz8gDQoNCg0KUFJSLVJCIGNhbiBjbG9jayBvdXQgbXVs dGlwbGUgc2VnbWVudHMgcGVyIEFDSyBidXQgaGFzIGEgYm91bmQgLSBvbiBldmVyeSBBQ0sgdGhl IGN1bXVsYXRpdmUgYW1vdW50IG9mIGRhdGEgc2VudCBpbiByZWNvdmVyeSBpcyBib3VuZCBieSB0 aGUgYW1vdW50IG9mIGRhdGEgZGVsaXZlcmVkIHRvIHRoZSByZWNlaXZlciBkdXJpbmcgcmVjb3Zl cnkuIFRoaXMgaXMgdW5saWtlIGluIHJmYzM1MTcsIHdoZXJlIGxhcmdlciB0aGUgbG9zc2VzIGFy ZSwgdGhlIGJpZ2dlciB0aGUgYnVyc3QgY2FuIGJlICh1cHRvIFtzc3RocmVzaCAtIHBpcGVdKS4g V2lsbCBzZW5kIG91dCBhbiBleGFtcGxlIHdpdGggdGhpcyBzY2VuYXJpbyBhZnRlciBJIGdldCBi YWNrIHRvIENhbC4NCg0KDQoJSSB0aGluayBMaW51eCBkb2VzIHN1Y2ggYSBzZW5kLXJhdGUgY2xh bXBpbmcgYXV0b21hdGljYWxseSDigJMgaG93IGlzIHRoZSBpbnRlcmFjdGlvbiB3aXRoIFBSUi1S Qiwgc2hvdWxkIHRoYXQgbm90IGJlIHBhcnQgb2YgdGhpcyBkcmFmdCB0b28pPw0KDQoNCkxpbnV4 IGRvZXMgdGhlIGNsYW1waW5nIGJ5IHJlZHVjaW5nIGN3bmQgdG8gbWluKHNzdGhyZXNoLCBwaXBl ICsgMSkgb24gZWFjaCBBQ0sgaW4gcmVjb3ZlcnkuIFRoaXMgaGFzIHRoZSB1bmZvcnR1bmF0ZSBi ZWhhdmlvciBpbiB0aGF0OiAxKSBpdCBpcyBsaW1pdGVkIHRvIGNsb2NraW5nIG91dCBhdCBtb3N0 IDEgcGFja2V0L0FDSywgYW5kIDIpIGZvciBzaG9ydCBXZWIgdHJhZmZpYyBvciB3aGVuIHRoZSBh cHBsaWNhdGlvbiBpcyB0ZW1wb3JhcmlseSBydW5uaW5nIG91dCBvZiBuZXcgZGF0YSB0byBzZW5k LCBwaXBlIHJlZHVjZXMgdG8gMCwgc28gY3duZCA9PSAxIGF0IHRoZSBlbmQgb2YgcmVjb3Zlcnku IFBSUi1SQiB3aWxsIHJlcGxhY2UgdGhlIGFib3ZlIGFuZCBzbyBubyBxdWVzdGlvbiBvZiBpbnRl cmFjdGlvbi4gDQoNCg0KCSANCg0KCUZyb206IE5hbmRpdGEgRHVra2lwYXRpIFttYWlsdG86bmFu ZGl0YWRAZ29vZ2xlLmNvbV0gDQoJU2VudDogRG9ubmVyc3RhZywgMzEuIE3DpHJ6IDIwMTEgMDM6 MzANCglUbzogTWljaGFlbCBXZWx6bA0KCUNjOiB0Y3BtQGlldGYub3JnOyBTQ0hBUkYsIE1pY2hh ZWwNCglTdWJqZWN0OiBSZTogW3RjcG1dIEludGVyZXN0IGluZHJhZnQtbWF0aGlzLXRjcG0tcHJv cG9ydGlvbmFsLXJhdGUtcmVkdWN0aW9uLTAwPw0KDQoJIA0KDQoJT24gVGh1LCBNYXIgMzEsIDIw MTEgYXQgMTo0MyBBTSwgTWljaGFlbCBXZWx6bCA8bWljaGF3ZUBpZmkudWlvLm5vPiB3cm90ZToN Cg0KCWkgYW0gaW4gcHJpbmNpcGxlIGludGVyZXN0ZWQgYW5kIGhhdmUgdGhlIGltcHJlc3Npb24g dGhhdCB0aGlzIGlzIHByb2JhYmx5IGEgdXNlZnVsIGRvY3VtZW50LCBidXQgdG9vIGNvbXBsaWNh dGVkLiBtYXliZSBhbiBleGFtcGxlIHdvdWxkIGhlbHA/DQoNCgkgDQoNCglUaGF0J3MgYSBncmVh dCBpZGVhIC0gd2Ugd2lsbCBwb3N0IGEgY291cGxlIG9mIGV4YW1wbGVzIHdpdGhpbiBuZXh0IGZl dyBkYXlzIG9uIGhvdyB0aGUgYWxnb3JpdGhtIGJlaGF2ZXMgdW5kZXIgc2luZ2xlIGFuZCBtdWx0 aXBsZSBsb3NzZXMuIEl0IGlzIGFjdHVhbGx5IHN1cnByaXNpbmdseSBzaW1wbGUuDQoNCgkgDQoN CgkgDQoNCgkJT24gTWFyIDMwLCAyMDExLCBhdCAxMToyMSBQTSwgU0NIQVJGLCBNaWNoYWVsIHdy b3RlOg0KDQoJCUZvbGtzLA0KCQkNCgkJc2luY2Ugd2UgcmFuIG91dCBvZiB0aW1lIGR1cmluZyB0 aGUgVENQTSBzZXNzaW9uLCBJIHNoaWZ0ZWQgdGhlDQoJCWRpc2N1c3Npb24gb2YgZHJhZnQtbWF0 aGlzLXRjcC1yYXRlaGFsdmluZy0wMCB0byB0aGUgbGlzdC4NCgkJDQoJCUluIG9yZGVyIHRvIHRy aWdnZXIgdGhpcyBkaXNjdXNzaW9uLCBJJ2QgbGlrZSB0byBzdGFydCBhbiBpbmZvcm1hbCBwb2xs DQoJCXdobyB3b3VsZCBpbiBwcmluY2lwbGUgYmUgaW50ZXJlc3RlZCBpbiB0aGUgdG9waWMgb2Yg dGhhdCBkcmFmdC4gSWYgc28sDQoJCXBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsLiBPZiBjb3Vy c2UsIGFueSB0ZWNobmljYWwgY29tbWVudCB3b3VsZCBiZQ0KCQlleGNlbGxlbnQuDQoJCQ0KCQlU aGFua3MhDQoJCQ0KCQlNaWNoYWVsDQoJCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoJCXRjcG0gbWFpbGluZyBsaXN0DQoJCXRjcG1AaWV0Zi5vcmcNCgkJ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQoNCgkJDQoJCV9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJCXRjcG0gbWFpbGlu ZyBsaXN0DQoJCXRjcG1AaWV0Zi5vcmcNCgkJaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90Y3BtDQoNCgkgDQoNCg0K ------_=_NextPart_001_01CBF042.AE61AEA4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPg0KSGkgbmFuZGl0YSw8YnI+ PGJyPkkgdW5kZXJzdGFuZCB0aGUgJnF1b3Q7Z2xvYmFsJnF1b3Q7IGJvdW5kLiBJbiBhIChoeXBv dGhldGljYWwpIHNjZW5hcmlvIHdoZXJlIHRoZSBzZW5kZXIgYmVjb21lcyBhcHAgbGltaXRlZCBk dXJpbmcgdGhlIHByci1yYiBwaGFzZSwgdGhlIHNvY2tldCBtYXkgYmVjb21lIGVtcHR5IHNob3J0 bHkuIFdoZW4gdGhlIGFwcCBjb250aW51ZXMsIHRoZSBzZW5kZXIgbWF5IGNsb2NrIG91dCBhIGxh cmdlciBidXJzdC4gPGJyPjxicj5JaXJjLCBsaW51eCBoYXMgYW5vdGhlciBjbGFtcCBhdCBubyBt b3JlIHRoYW4gMyBzZWcvYWNrIGR1cmluZyBsb3NzIHJlY292ZXJ5Li4uPGJyPjxicj5JbWhvIHN1 Y2ggYSBzZWNvbmRhcnkgY2xhbXAgbWFrZXMgc2Vuc2UgdG8gYWxsZXZpYXRlIGJ1cnN0cyBhZnRl ciBhcHAgc3RhbGxzPGJyPjxicj5UaGF0J3MgdGhlIGJhY2tncm91bmQgb2YgbXkgcXVlc3Rpb248 YnI+PGJyPlJpY2hhcmQ8L2ZvbnQ+PC9kaXY+DQo8YnI+PGRpdj48aHIgc2l6ZT0yIHdpZHRoPSIx MDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQo8Zm9udCBmYWNlPVRhaG9tYSBzaXplPTI+ DQo8Yj5Wb248L2I+OiBOYW5kaXRhIER1a2tpcGF0aSAmbHQ7bmFuZGl0YWRAZ29vZ2xlLmNvbSZn dDsNPGJyPjxiPkFuPC9iPjogU2NoZWZmZW5lZ2dlciwgUmljaGFyZA08YnI+PGI+Q2M8L2I+OiBN aWNoYWVsIFdlbHpsICZsdDttaWNoYXdlQGlmaS51aW8ubm8mZ3Q7OyB0Y3BtQGlldGYub3JnICZs dDt0Y3BtQGlldGYub3JnJmd0OzsgU0NIQVJGLCBNaWNoYWVsICZsdDtNaWNoYWVsLlNjaGFyZkBh bGNhdGVsLWx1Y2VudC5jb20mZ3Q7DTxicj48Yj5HZXNlbmRldDwvYj46IEZyaSBBcHIgMDEgMDU6 NTc6NDggMjAxMTxicj48Yj5CZXRyZWZmPC9iPjogUmU6IFt0Y3BtXSBJbnRlcmVzdCBpbmRyYWZ0 LW1hdGhpcy10Y3BtLXByb3BvcnRpb25hbC1yYXRlLXJlZHVjdGlvbi0wMD8NPGJyPjwvZm9udD48 YnI+PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg c29saWQ7cGFkZGluZy1sZWZ0OjFleDsiPjxkaXYgbGFuZz0iREUtQVQiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9IkFwcGxl LXN0eWxlLXNwYW4iIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1zaXplOiAx NXB4OyAiPkkgd291bGQgYWxzbyBiZSBpbnRlcmVzdGVkIGluIGxlYXJuaW5nIGhvdyB0aGUgYWxn b3JpdGhtIGJlaGF2ZXMsIHdoZW4gbW9yZSB0aGVuIG9uZSBoYWxmIG9mIHRoZSB3aW5kb3cgaXMg bG9zdCAoaWUsIHRoZXJlIGFyZW7igJl0IGVub3VnaCBBQ0tzIHNlbnQgYmFjayB0byBjbG9jayBv dXQgZWFjaCBhbGxvd2VkIGRhdGEgc2VnbWVudCBieSBpdOKAmXMgb3duIEFDSykuIFdpbGwgaXQg Y2xvY2sgb3V0IG11bHRpcGxlIHNlZ21lbnRzIHBlciBBQ0sgKGFuZCBpZiBzbywgd2lsbCB0aGV5 IGJlIHNwcmVhZCBvdmVyIHRoZSByZW1haW5pbmcgQUNLcywgc28gdG8gbGltaXQgdGhlIG1heGlt dW0gbnVtYmVyIG9mIHNlbnQgcGFja2V0cyBwZXIgQUNLIOKAkyBvciB3b3VsZCBQUlItUkIgYnkg aXRzZWxmIGFsbG93IGEgYnVyc3Qgb2YgcGFja2V0cyBiZWluZyBjbG9ja2VkIG91dCBieSBhIHNp bmdsZSBBQ0s/IDwvc3Bhbj48L3A+DQo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+ PC9kaXY+PGRpdj5QUlItUkIgY2FuIGNsb2NrIG91dCBtdWx0aXBsZSBzZWdtZW50cyBwZXIgQUNL IGJ1dCBoYXMgYSBib3VuZCAtIG9uIGV2ZXJ5IEFDSyB0aGUgY3VtdWxhdGl2ZSBhbW91bnQgb2Yg ZGF0YSBzZW50IGluIHJlY292ZXJ5IGlzIGJvdW5kIGJ5IHRoZSBhbW91bnQgb2YgZGF0YSBkZWxp dmVyZWQgdG8gdGhlIHJlY2VpdmVyIGR1cmluZyByZWNvdmVyeS4gVGhpcyBpcyB1bmxpa2UgaW4g cmZjMzUxNywgd2hlcmUgbGFyZ2VyIHRoZSBsb3NzZXMgYXJlLCB0aGUgYmlnZ2VyIHRoZSBidXJz dCBjYW4gYmUgKHVwdG8gW3NzdGhyZXNoIC0gcGlwZV0pLsKgV2lsbCBzZW5kIG91dCBhbiBleGFt cGxlIHdpdGggdGhpcyBzY2VuYXJpbyBhZnRlciBJIGdldCBiYWNrIHRvIENhbC48L2Rpdj4NCjxk aXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXg7 Ij48ZGl2IGxhbmc9IkRFLUFUIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj48ZGl2PjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtc2l6ZTogMTVweDsgIj5JIHRoaW5rIExpbnV4IGRv ZXMgc3VjaCBhIHNlbmQtcmF0ZSBjbGFtcGluZyBhdXRvbWF0aWNhbGx5IOKAkyBob3cgaXMgdGhl IGludGVyYWN0aW9uIHdpdGggUFJSLVJCLCBzaG91bGQgdGhhdCBub3QgYmUgcGFydCBvZiB0aGlz IGRyYWZ0IHRvbyk/PC9zcGFuPjwvcD4NCjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxi cj48L2Rpdj48ZGl2PkxpbnV4IGRvZXMgdGhlIGNsYW1waW5nIGJ5IHJlZHVjaW5nIGN3bmQgdG8g bWluKHNzdGhyZXNoLCBwaXBlICsgMSkgb24gZWFjaCBBQ0sgaW4gcmVjb3ZlcnkuIFRoaXMgaGFz IHRoZSB1bmZvcnR1bmF0ZSBiZWhhdmlvciBpbiB0aGF0OiAxKSBpdCBpcyBsaW1pdGVkIHRvIGNs b2NraW5nIG91dCBhdCBtb3N0IDEgcGFja2V0L0FDSywgYW5kIDIpIGZvciBzaG9ydCBXZWIgdHJh ZmZpYyBvciB3aGVuIHRoZSBhcHBsaWNhdGlvbiBpcyB0ZW1wb3JhcmlseSBydW5uaW5nIG91dCBv ZiBuZXcgZGF0YSB0byBzZW5kLCBwaXBlIHJlZHVjZXMgdG8gMCwgc28gY3duZCA9PSAxIGF0IHRo ZSBlbmQgb2YgcmVjb3ZlcnkuIFBSUi1SQiB3aWxsIHJlcGxhY2UgdGhlIGFib3ZlIGFuZCBzbyBu byBxdWVzdGlvbiBvZiBpbnRlcmFjdGlvbi7CoDwvZGl2Pg0KPGRpdj48YnI+PC9kaXY+PGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVy LWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleDsiPjxkaXYgbGFuZz0iREUtQVQi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPsKg PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+PGRpdj48ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gTmFuZGl0YSBEdWtraXBhdGkgW21haWx0bzo8YSBocmVm PSJtYWlsdG86bmFuZGl0YWRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5hbmRpdGFkQGdv b2dsZS5jb208L2E+XSA8YnI+DQo8Yj5TZW50OjwvYj4gRG9ubmVyc3RhZywgMzEuIE3DpHJ6IDIw MTEgMDM6MzA8YnI+PGI+VG86PC9iPiBNaWNoYWVsIFdlbHpsPGJyPjxiPkNjOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50Y3BtQGlldGYub3JnPC9h PjsgU0NIQVJGLCBNaWNoYWVsPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3RjcG1dIEludGVyZXN0 IGluZHJhZnQtbWF0aGlzLXRjcG0tcHJvcG9ydGlvbmFsLXJhdGUtcmVkdWN0aW9uLTAwPzwvc3Bh bj48L3A+DQo8L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iaDUiPjxwIGNs YXNzPSJNc29Ob3JtYWwiPsKgPC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBN YXIgMzEsIDIwMTEgYXQgMTo0MyBBTSwgTWljaGFlbCBXZWx6bCAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1pY2hhd2VAaWZpLnVpby5ubyIgdGFyZ2V0PSJfYmxhbmsiPm1pY2hhd2VAaWZpLnVpby5ubzwv YT4mZ3Q7IHdyb3RlOjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmkgYW0gaW4gcHJpbmNpcGxl IGludGVyZXN0ZWQgYW5kIGhhdmUgdGhlIGltcHJlc3Npb24gdGhhdCB0aGlzIGlzIHByb2JhYmx5 IGEgdXNlZnVsIGRvY3VtZW50LCBidXQgdG9vIGNvbXBsaWNhdGVkLiBtYXliZSBhbiBleGFtcGxl IHdvdWxkIGhlbHA/PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+wqA8L3A+PC9kaXY+PGRp dj48cCBjbGFzcz0iTXNvTm9ybWFsIj4NClRoYXQmIzM5O3MgYSBncmVhdCBpZGVhIC0gd2Ugd2ls bCBwb3N0IGEgY291cGxlIG9mIGV4YW1wbGVzIHdpdGhpbiBuZXh0IGZldyBkYXlzIG9uIGhvdyB0 aGUgYWxnb3JpdGhtIGJlaGF2ZXMgdW5kZXIgc2luZ2xlIGFuZCBtdWx0aXBsZSBsb3NzZXMuIEl0 IGlzIGFjdHVhbGx5IHN1cnByaXNpbmdseSBzaW1wbGUuPC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 Ik1zb05vcm1hbCI+wqA8L3A+PC9kaXY+DQo8ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPsKgPC9w PjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+PGRpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+DQpPbiBNYXIgMzAsIDIwMTEsIGF0IDExOjIxIFBNLCBTQ0hB UkYsIE1pY2hhZWwgd3JvdGU6PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvbGtzLDxicj48YnI+ c2luY2Ugd2UgcmFuIG91dCBvZiB0aW1lIGR1cmluZyB0aGUgVENQTSBzZXNzaW9uLCBJIHNoaWZ0 ZWQgdGhlPGJyPmRpc2N1c3Npb24gb2YgZHJhZnQtbWF0aGlzLXRjcC1yYXRlaGFsdmluZy0wMCB0 byB0aGUgbGlzdC48YnI+PGJyPg0KSW4gb3JkZXIgdG8gdHJpZ2dlciB0aGlzIGRpc2N1c3Npb24s IEkmIzM5O2QgbGlrZSB0byBzdGFydCBhbiBpbmZvcm1hbCBwb2xsPGJyPndobyB3b3VsZCBpbiBw cmluY2lwbGUgYmUgaW50ZXJlc3RlZCBpbiB0aGUgdG9waWMgb2YgdGhhdCBkcmFmdC4gSWYgc28s PGJyPnBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsLiBPZiBjb3Vyc2UsIGFueSB0ZWNobmljYWwg Y29tbWVudCB3b3VsZCBiZTxicj4NCmV4Y2VsbGVudC48YnI+PGJyPlRoYW5rcyE8YnI+PGJyPk1p Y2hhZWw8YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+dGNwbSBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj50Y3BtQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG08L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPnRjcG0gbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+dGNwbUBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPC9hPjwvcD4NCjwvZGl2PjwvZGl2Pjwv YmxvY2txdW90ZT48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj7CoDwvcD48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPg0K ------_=_NextPart_001_01CBF042.AE61AEA4-- From Michael.Scharf@alcatel-lucent.com Fri Apr 1 01:39:29 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17FC13A63CB for ; Fri, 1 Apr 2011 01:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jznn9L96hebs for ; Fri, 1 Apr 2011 01:39:28 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id E0F8C3A63D2 for ; Fri, 1 Apr 2011 01:39:27 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p318f6jS007621 for ; Fri, 1 Apr 2011 10:41:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF048.8A9BC613" Date: Fri, 1 Apr 2011 10:41:06 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security Thread-index: AcvwSIp/qDAIfNhYRCmC35upNS5V5w== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] Volunteers to review (parts of) draft-ietf-tcpm-tcp-security X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 08:39:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF048.8A9BC613 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, as noted during the meeting, we do need volunteers that are willing to = review the technical recommendations in draft-ietf-tcpm-tcp-security-02. = The working group came up with a workflow to evaluate/categorize each = recommendation. This process is explained on Fernando's slides: http://www.ietf.org/proceedings/80/slides/tcpm-8.ppt Therein, you can also find some overview of the number of = recommendations and their distribution. During the meeting, some participants volunteered to help and review = parts of the document. I'd really appreciate if those of you could just = post a small note to the list. And it would really help if some more = folks would offer help, too. If you are particularly interested in = certain sections (only), just let us know. Due to the length of the document, it would be perfectly fine to review = only certain parts of the document. Please also note that the document does require sufficient interest and = feedback from the working group in order to move forward. Thanks! Michael ------_=_NextPart_001_01CBF048.8A9BC613 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Volunteers to review (parts of) = draft-ietf-tcpm-tcp-security

All,

as noted during the meeting, we do need volunteers that are willing to = review the technical recommendations in draft-ietf-tcpm-tcp-security-02. = The working group came up with a workflow to evaluate/categorize each = recommendation. This process is explained on Fernando's slides:

http://www.= ietf.org/proceedings/80/slides/tcpm-8.ppt

Therein, you can also find some overview of the number of = recommendations and their distribution.

During the meeting, some participants volunteered to help and review = parts of the document. I'd really appreciate if those of you could just = post a small note to the list. And it would really help if some more = folks would offer help, too. If you are particularly interested in = certain sections (only), just let us know.

Due to the length of the document, it would be perfectly fine to review = only certain parts of the document.

Please also note that the document does require sufficient interest and = feedback from the working group in order to move forward.

Thanks!

Michael

------_=_NextPart_001_01CBF048.8A9BC613-- From michawe@ifi.uio.no Fri Apr 1 08:51:40 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C173A68AC for ; Fri, 1 Apr 2011 08:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNRDLtCkYnh8 for ; Fri, 1 Apr 2011 08:51:39 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id E29793A6884 for ; Fri, 1 Apr 2011 08:51:38 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1Q5gf0-000429-61 for tcpm@ietf.org; Fri, 01 Apr 2011 17:53:18 +0200 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Q5gez-0005Wm-M2 for tcpm@ietf.org; Fri, 01 Apr 2011 17:53:18 +0200 Message-Id: <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> From: Michael Welzl To: tcpm In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 1 Apr 2011 17:52:54 +0200 References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 8 sum rcpts/h 20 sum msgs/h 12 total rcpts 8085 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8E1DA45489052033A95F87C3B716BB2166D7A748 X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 8 total 794 max/h 18 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] Volunteers to review (parts of) draft-ietf-tcpm-tcp-security X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 15:51:40 -0000 Hi! I disagree, I think this document should not be reviewed further at this stage, but removed instead. Plenty of reasons, and they have all been said before - which is why I also think that we should avoid even discussing this further. The group's email archive could be read instead. Now, this is of course just my personal opinion; but this document has been on the table quite a while now, and it wasn't clear to me in any way at this meeting that there would be strong interest in having it published, let alone contributing to it. Cheers, Michael On Apr 1, 2011, at 10:41 AM, SCHARF, Michael wrote: > All, > > as noted during the meeting, we do need volunteers that are willing > to review the technical recommendations in draft-ietf-tcpm-tcp- > security-02. The working group came up with a workflow to evaluate/ > categorize each recommendation. This process is explained on > Fernando's slides: > > http://www.ietf.org/proceedings/80/slides/tcpm-8.ppt > > Therein, you can also find some overview of the number of > recommendations and their distribution. > > During the meeting, some participants volunteered to help and review > parts of the document. I'd really appreciate if those of you could > just post a small note to the list. And it would really help if some > more folks would offer help, too. If you are particularly interested > in certain sections (only), just let us know. > > Due to the length of the document, it would be perfectly fine to > review only certain parts of the document. > > Please also note that the document does require sufficient interest > and feedback from the working group in order to move forward. > > Thanks! > > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Fri Apr 1 16:39:50 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9345C3A69AD for ; Fri, 1 Apr 2011 16:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.378 X-Spam-Level: X-Spam-Status: No, score=-10.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+km9EKHdYhS for ; Fri, 1 Apr 2011 16:39:48 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 9A7ED3A69AC for ; Fri, 1 Apr 2011 16:39:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,285,1299484800"; d="scan'208";a="248447003" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 01 Apr 2011 16:41:28 -0700 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p31NfRA2009233; Fri, 1 Apr 2011 16:41:27 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Apr 2011 01:41:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 2 Apr 2011 00:41:10 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0DA84BF4@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Volunteers to review (parts of)draft-ietf-tcpm-tcp-security Thread-Index: AcvwhO96JYZuckk5QVqgZvzOi6mixgAQB9GQ References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> From: "Scheffenegger, Richard" To: "tcpm" , "Fernando Gont" , X-OriginalArrivalTime: 01 Apr 2011 23:41:27.0267 (UTC) FILETIME=[518E6B30:01CBF0C6] Cc: Michael Welzl Subject: Re: [tcpm] Volunteers to review (parts of)draft-ietf-tcpm-tcp-security X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 01 Apr 2011 23:39:50 -0000 Fernando, After attending to Joe's and Bob's IP ID Reuse presentation, and talking with Tim, I'm thinking that nailing everything down completely would disable any future room for improvement. In particular, when certain field are currently simply ignored, with these BCP doc all these packets would have to be discarded - so one cannot build a backwards-compatible new 3WHS signaling protocol (see my timestamp proposal; Tim may have something based around the same idea soon also - what's listed on slides 9+10 would stop all these ideas cold). Richard Scheffenegger > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no] > Sent: Freitag, 01. April 2011 17:53 > To: tcpm > Subject: Re: [tcpm] Volunteers to review (parts of)draft-ietf-tcpm-tcp- > security >=20 > Hi! >=20 > I disagree, I think this document should not be reviewed further at > this stage, but removed instead. > Plenty of reasons, and they have all been said before - which is why I > also think that we should avoid even discussing this further. The > group's email archive could be read instead. >=20 > Now, this is of course just my personal opinion; but this document has > been on the table quite a while now, and it wasn't clear to me in any > way at this meeting that there would be strong interest in having it > published, let alone contributing to it. >=20 > Cheers, > Michael >=20 >=20 > On Apr 1, 2011, at 10:41 AM, SCHARF, Michael wrote: >=20 > > All, > > > > as noted during the meeting, we do need volunteers that are willing > > to review the technical recommendations in draft-ietf-tcpm-tcp- > > security-02. The working group came up with a workflow to evaluate/ > > categorize each recommendation. This process is explained on > > Fernando's slides: > > > > http://www.ietf.org/proceedings/80/slides/tcpm-8.ppt > > > > Therein, you can also find some overview of the number of > > recommendations and their distribution. > > > > During the meeting, some participants volunteered to help and review > > parts of the document. I'd really appreciate if those of you could > > just post a small note to the list. And it would really help if some > > more folks would offer help, too. If you are particularly interested > > in certain sections (only), just let us know. > > > > Due to the length of the document, it would be perfectly fine to > > review only certain parts of the document. > > > > Please also note that the document does require sufficient interest > > and feedback from the working group in order to move forward. > > > > Thanks! > > > > Michael > > > > _______________________________________________ > > 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 ananth@cisco.com Fri Apr 1 23:54:21 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3255E28C138 for ; Fri, 1 Apr 2011 23:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.269 X-Spam-Level: X-Spam-Status: No, score=-11.269 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY6Hdi5yABkb for ; Fri, 1 Apr 2011 23:54:19 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7135D28C145 for ; Fri, 1 Apr 2011 23:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2892; q=dns/txt; s=iport; t=1301727355; x=1302936955; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=NjX7nFr3e3+0YP5VzVOCzof8uhSmRpOaoczE+0NXFcs=; b=GJJi2wiL6RPcltyz0t+ZZZ+Dj5pqSGovCs61hVtxzQOd0ijccWkZlM78 jL/q+nmlxsFlrpvUCCocWn5jj4lAOYQj61BMGoT5Alk68wbSh+PFZlA/S LVuh3odcXmClrryK2whpSWcVOYzpc55So1z5htwqjhJXUvgBtOOkR/+75 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAABzIlk2rRDoJ/2dsb2JhbACYJY09d6Vpm3uFawSFR4s9 X-IronPort-AV: E=Sophos;i="4.63,287,1299456000"; d="scan'208";a="287877955" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2011 06:55:55 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p326ttVR030607; Sat, 2 Apr 2011 06:55:55 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 23:55:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 23:55:53 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580C56D686@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Volunteers to review (parts of)draft-ietf-tcpm-tcp-security Thread-Index: AcvwhQIkk3kXt6d1Q8WPuPLB8gZn3gAfWTng References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> From: "Anantha Ramaiah (ananth)" To: "Michael Welzl" , "tcpm" X-OriginalArrivalTime: 02 Apr 2011 06:55:55.0243 (UTC) FILETIME=[0347E3B0:01CBF103] Subject: Re: [tcpm] Volunteers to review (parts of)draft-ietf-tcpm-tcp-security X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 02 Apr 2011 06:54:21 -0000 Michael, If what you are saying is true, then this document should not have become a WG document. By saying it is a WG document we are endorsing that there is rough consensus in the WG to pursue publishing this document. It is utter waste of time for the author and the reviewers to have spent some energy and then say that "throw away this document". I assume you were in the TCPM meeting and how come you did not raise your objection then, when this topic came up, curious... -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Michael Welzl > Sent: Friday, April 01, 2011 8:53 AM > To: tcpm > Subject: Re: [tcpm] Volunteers to review (parts of)draft-ietf-tcpm-tcp- > security >=20 > Hi! >=20 > I disagree, I think this document should not be reviewed further at > this stage, but removed instead. > Plenty of reasons, and they have all been said before - which is why I > also think that we should avoid even discussing this further. The > group's email archive could be read instead. >=20 > Now, this is of course just my personal opinion; but this document has > been on the table quite a while now, and it wasn't clear to me in any > way at this meeting that there would be strong interest in having it > published, let alone contributing to it. >=20 > Cheers, > Michael >=20 >=20 > On Apr 1, 2011, at 10:41 AM, SCHARF, Michael wrote: >=20 > > All, > > > > as noted during the meeting, we do need volunteers that are willing > > to review the technical recommendations in draft-ietf-tcpm-tcp- > > security-02. The working group came up with a workflow to evaluate/ > > categorize each recommendation. This process is explained on > > Fernando's slides: > > > > http://www.ietf.org/proceedings/80/slides/tcpm-8.ppt > > > > Therein, you can also find some overview of the number of > > recommendations and their distribution. > > > > During the meeting, some participants volunteered to help and review > > parts of the document. I'd really appreciate if those of you could > > just post a small note to the list. And it would really help if some > > more folks would offer help, too. If you are particularly interested > > in certain sections (only), just let us know. > > > > Due to the length of the document, it would be perfectly fine to > > review only certain parts of the document. > > > > Please also note that the document does require sufficient interest > > and feedback from the working group in order to move forward. > > > > Thanks! > > > > Michael > > > > _______________________________________________ > > 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 ananth@cisco.com Fri Apr 1 23:59:15 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9051B28C138 for ; Fri, 1 Apr 2011 23:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.224 X-Spam-Level: X-Spam-Status: No, score=-11.224 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfzUSM84KSBr for ; Fri, 1 Apr 2011 23:59:11 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B5C8D28C0F8 for ; Fri, 1 Apr 2011 23:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=6687; q=dns/txt; s=iport; t=1301727652; x=1302937252; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=FsiB+KcZVcuuSSPHU/wuvESj7MD3L8pIRTzxZhs3178=; b=hfx23Q2uOezl1Wb1Z9ruJhAIWRsatA2E6IOZJT4twcTuo9mPgHuB51Bg OsBnx3ra7D9P+pgRf/VXHrkJbNVU7o2PUvnRMv+4BhUEqaznbFnOzLiUp CgW4RDtHCb27/sYS5WQGHrSYCMfFPmary68Xip6IOTh61GoaucQEX2m/C E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAFvJlk2rRDoH/2dsb2JhbACCX5VGjT13pV2beoVrBIVHiz0 X-IronPort-AV: E=Sophos;i="4.63,287,1299456000"; d="scan'208,217";a="287879639" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2011 07:00:52 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3270qea003958; Sat, 2 Apr 2011 07:00:52 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Apr 2011 00:00:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF103.B3D97C8C" Date: Sat, 2 Apr 2011 00:00:51 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580C56D687@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Volunteers to review (parts of) draft-ietf-tcpm-tcp-security Thread-Index: AcvwSIp/qDAIfNhYRCmC35upNS5V5wAuuokg References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> From: "Anantha Ramaiah (ananth)" To: "SCHARF, Michael" , X-OriginalArrivalTime: 02 Apr 2011 07:00:52.0616 (UTC) FILETIME=[B4876880:01CBF103] Subject: Re: [tcpm] Volunteers to review (parts of) draft-ietf-tcpm-tcp-security X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 02 Apr 2011 06:59:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF103.B3D97C8C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Michael, I already reviewed the document as a whole. I privately discussed some of the comments with Fernando and will post them to the list soon. I am back to work and too many things to catch up, so please expect delays. -Anantha =20 From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of SCHARF, Michael Sent: Friday, April 01, 2011 1:41 AM To: tcpm@ietf.org Subject: [tcpm] Volunteers to review (parts of) draft-ietf-tcpm-tcp-security =20 All, as noted during the meeting, we do need volunteers that are willing to review the technical recommendations in draft-ietf-tcpm-tcp-security-02. The working group came up with a workflow to evaluate/categorize each recommendation. This process is explained on Fernando's slides: http://www.ietf.org/proceedings/80/slides/tcpm-8.ppt Therein, you can also find some overview of the number of recommendations and their distribution. During the meeting, some participants volunteered to help and review parts of the document. I'd really appreciate if those of you could just post a small note to the list. And it would really help if some more folks would offer help, too. If you are particularly interested in certain sections (only), just let us know. Due to the length of the document, it would be perfectly fine to review only certain parts of the document. Please also note that the document does require sufficient interest and feedback from the working group in order to move forward. Thanks! Michael ------_=_NextPart_001_01CBF103.B3D97C8C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Volunteers to review (parts of) = draft-ietf-tcpm-tcp-security

Michael,

    I already reviewed the document as a = whole. I privately discussed some of the comments with Fernando and will post = them to the list soon. I am back to work and too many things to catch up, so = please expect delays.

-Anantha

 

From:= tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of = SCHARF, Michael
Sent: Friday, April 01, 2011 1:41 AM
To: tcpm@ietf.org
Subject: [tcpm] Volunteers to review (parts of) draft-ietf-tcpm-tcp-security

 

All,

as noted during the meeting, we do need volunteers that are willing to = review the technical recommendations in draft-ietf-tcpm-tcp-security-02. The = working group came up with a workflow to evaluate/categorize each = recommendation. This process is explained on Fernando's slides:

http://www.= ietf.org/proceedings/80/slides/tcpm-8.ppt

Therein, you can also find some overview of the number of = recommendations and their distribution.

During the meeting, some participants volunteered to help and review = parts of the document. I'd really appreciate if those of you could just post a = small note to the list. And it would really help if some more folks would = offer help, too. If you are particularly interested in certain sections (only), just = let us know.

Due to the length of the document, it would be perfectly fine to review = only certain parts of the document.

Please also note that the document does require sufficient interest and feedback from the working group in order to move forward.

Thanks!

Michael

------_=_NextPart_001_01CBF103.B3D97C8C-- From michawe@ifi.uio.no Sat Apr 2 00:01:37 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3E1328C0F8 for ; Sat, 2 Apr 2011 00:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GZayKKpJGg0 for ; Sat, 2 Apr 2011 00:01:32 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id DF6D928C138 for ; Sat, 2 Apr 2011 00:01:31 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1Q5urX-0004Vl-RX; Sat, 02 Apr 2011 09:03:11 +0200 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Q5urX-0004qB-7W; Sat, 02 Apr 2011 09:03:11 +0200 Message-Id: <9D8384DD-2F15-4BD7-931F-99B60ED13E47@ifi.uio.no> From: Michael Welzl To: "Anantha Ramaiah (ananth)" In-Reply-To: <0C53DCFB700D144284A584F54711EC580C56D686@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 2 Apr 2011 09:02:49 +0200 References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> <0C53DCFB700D144284A584F54711EC580C56D686@xmb-sjc-21c.amer.cisco.com> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 5 sum msgs/h 3 total rcpts 8127 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 59A43A7EF7EC0F5A9FD71B729DECD3CDCE5A701C X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 818 max/h 18 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm Subject: Re: [tcpm] Volunteers to review (parts of)draft-ietf-tcpm-tcp-security X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 02 Apr 2011 07:01:37 -0000 I agree: it was, in my opinion, a mistake for the group to take it up as a document. You can find me stating that I'm against that in the archive. Why did I not raise my objection at the meeting: I figured, I have said my opinion before, it didn't help, why would it be constructive to stand up and say "stop" again? but, after the presentation, it looked obvious to me that this document doesn't have the community interest it needs. Cheers, Michael On Apr 2, 2011, at 8:55 AM, Anantha Ramaiah (ananth) wrote: > Michael, > If what you are saying is true, then this document should not have > become a WG document. By saying it is a WG document we are endorsing > that there is rough consensus in the WG to pursue publishing this > document. It is utter waste of time for the author and the reviewers > to > have spent some energy and then say that "throw away this document". I > assume you were in the TCPM meeting and how come you did not raise > your > objection then, when this topic came up, curious... > -Anantha > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf > Of >> Michael Welzl >> Sent: Friday, April 01, 2011 8:53 AM >> To: tcpm >> Subject: Re: [tcpm] Volunteers to review (parts > of)draft-ietf-tcpm-tcp- >> security >> >> Hi! >> >> I disagree, I think this document should not be reviewed further at >> this stage, but removed instead. >> Plenty of reasons, and they have all been said before - which is >> why I >> also think that we should avoid even discussing this further. The >> group's email archive could be read instead. >> >> Now, this is of course just my personal opinion; but this document >> has >> been on the table quite a while now, and it wasn't clear to me in any >> way at this meeting that there would be strong interest in having it >> published, let alone contributing to it. >> >> Cheers, >> Michael >> >> >> On Apr 1, 2011, at 10:41 AM, SCHARF, Michael wrote: >> >>> All, >>> >>> as noted during the meeting, we do need volunteers that are willing >>> to review the technical recommendations in draft-ietf-tcpm-tcp- >>> security-02. The working group came up with a workflow to evaluate/ >>> categorize each recommendation. This process is explained on >>> Fernando's slides: >>> >>> http://www.ietf.org/proceedings/80/slides/tcpm-8.ppt >>> >>> Therein, you can also find some overview of the number of >>> recommendations and their distribution. >>> >>> During the meeting, some participants volunteered to help and review >>> parts of the document. I'd really appreciate if those of you could >>> just post a small note to the list. And it would really help if some >>> more folks would offer help, too. If you are particularly interested >>> in certain sections (only), just let us know. >>> >>> Due to the length of the document, it would be perfectly fine to >>> review only certain parts of the document. >>> >>> Please also note that the document does require sufficient interest >>> and feedback from the working group in order to move forward. >>> >>> Thanks! >>> >>> Michael >>> >>> _______________________________________________ >>> 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 fernando.gont.netbook.win@gmail.com Sat Apr 2 11:53:05 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84A273A67D7 for ; Sat, 2 Apr 2011 11:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQpjR+muhXj7 for ; Sat, 2 Apr 2011 11:53:04 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 25D183A6452 for ; Sat, 2 Apr 2011 11:53:03 -0700 (PDT) Received: by bwz13 with SMTP id 13so3463017bwz.31 for ; Sat, 02 Apr 2011 11:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=LT9C+n8qjfhhfN3yQa0Sxmi2Mv6lpxq9T6A7yh6GPTY=; b=nEK0/k4d48Btdhz8oi4Ignp9Rjsk2FEGsEk5g3oWAueZrerGF3BewfYRRVqmlPlms7 MxzGY8nPXYU0iOiZHD2cFNYMX/hyPYxeiDbLbOX9p3kfQJpVBPXG8gM0GlVNgt/OeW01 sHRhyhQyJAn1Ncz+dMk9xT5LI/AgfEK9msxbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=AJETqY9K/Q+0TNUQ61nuEruVtPDS5UbZ41B8H4oxNACWiVqQhHjD9THC3zaDG3lvlQ V4kddschZ3mqW/9+dsfc4SfWR+P4pYU9hbpbPraLMCT88fZR/2d9v9wSwgFxrL4sYj9f BJHaCbvccbzrm/sMeS3VbnBq0EAy4nHWqQ/js= Received: by 10.204.7.8 with SMTP id b8mr2345832bkb.31.1301770484381; Sat, 02 Apr 2011 11:54:44 -0700 (PDT) Received: from [172.30.12.221] (241.150.broadband12.iol.cz [90.179.150.241]) by mx.google.com with ESMTPS id t1sm2070442bkx.19.2011.04.02.11.54.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Apr 2011 11:54:44 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9770F1.8010800@gont.com.ar> Date: Sat, 02 Apr 2011 15:54:41 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Michael Welzl References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> In-Reply-To: <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm Subject: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 02 Apr 2011 18:53:05 -0000 [changed the subject, since this has nothing to do with the request sent by the chairs] On 01/04/2011 12:52 p.m., Michael Welzl wrote: > I disagree, I think this document should not be reviewed further at this > stage, but removed instead. I personally believe it is harmful that the chairs are requesting reviewers, based on a very recent discussion, and you raise issues from a past discussion in the thread, arguing against what the wg has agreed upon. > Plenty of reasons, and they have all been said before - which is why I > also think that we should avoid even discussing this further. This is false. The claims have been "Oh, this document is harmful!". Please look at the only one or two concrete examples that were raised, and my response to them. And, FWIW, this is in I-D stage. If there's any recommendation that is wrong, we have plenty of time to change it, and I urge you to state explicitly which recommendations you think are incorrect, and we may fix/eliminate them where necessary. > The group's email archive could be read instead. I did, but found nothing. Please provide references. > Now, this is of course just my personal opinion; but this document has > been on the table quite a while now, and it wasn't clear to me in any > way at this meeting that there would be strong interest in having it > published, let alone contributing to it. I don't think the past meeting was trying to sense that. It was trying to get reviewers, and agree on a procedure to follow when reviewing the document. P.S.: For the sake of keeping a good signal/noise ratio and spending the wg's energy in getting work done, I will not respond to this thread until it is explicitly stated what are the recommendations that are deemed as harmful/incorrect. This thread, as is, sounds more like flaming than anything else. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From michawe@ifi.uio.no Sat Apr 2 12:39:35 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00ED3A6884 for ; Sat, 2 Apr 2011 12:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0KZjT+5Nk+f for ; Sat, 2 Apr 2011 12:39:34 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 909893A6877 for ; Sat, 2 Apr 2011 12:39:34 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1Q66h8-0007IT-Tb for tcpm@ietf.org; Sat, 02 Apr 2011 21:41:14 +0200 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Q66h8-0002jl-Gk for tcpm@ietf.org; Sat, 02 Apr 2011 21:41:14 +0200 Message-Id: <9EC7C0A8-D383-4D8A-9EC0-D952E2EE53F2@ifi.uio.no> From: Michael Welzl To: tcpm In-Reply-To: <4D9770F1.8010800@gont.com.ar> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 2 Apr 2011 21:40:52 +0200 References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> <4D9770F1.8010800@gont.com.ar> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 6 sum msgs/h 4 total rcpts 8158 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 451B082E0ACD96ED806853D5BCE28ADFF6FCE8DF X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 840 max/h 18 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 02 Apr 2011 19:39:35 -0000 On Apr 2, 2011, at 8:54 PM, Fernando Gont wrote: > [changed the subject, since this has nothing to do with the request > sent > by the chairs] > > On 01/04/2011 12:52 p.m., Michael Welzl wrote: >> I disagree, I think this document should not be reviewed further at >> this >> stage, but removed instead. > > I personally believe it is harmful that the chairs are requesting > reviewers, based on a very recent discussion, and you raise issues > from > a past discussion in the thread, arguing against what the wg has > agreed > upon. Hm, you have a point there. I still have the same opinion as I had then, but I might be mistaken about IETF procedures. Now that the WG approved it as a WG document, *can* it even be stopped? Can the WG change its mind and kick it out if there is consensus for doing so, or lack of interest for it? I will wait for an answer to this from the chairs before I even continue. I don't want to waste everyone's time. Cheers, Michael From rs@netapp.com Sat Apr 2 15:42:47 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049213A68E3 for ; Sat, 2 Apr 2011 15:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.389 X-Spam-Level: X-Spam-Status: No, score=-10.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtJewxHKoJFs for ; Sat, 2 Apr 2011 15:42:46 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id A9A673A68E1 for ; Sat, 2 Apr 2011 15:42:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,290,1299484800"; d="scan'208";a="247303355" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 02 Apr 2011 15:44:26 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p32MiNUW020962; Sat, 2 Apr 2011 15:44:25 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Apr 2011 23:44:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 2 Apr 2011 23:44:07 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0DA84C0E@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4D9770F1.8010800@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) Thread-Index: AcvxZ3MRHWzmiuDuSumjY3dnDHPXmAAHrzNg References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de><414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> <4D9770F1.8010800@gont.com.ar> From: "Scheffenegger, Richard" To: "Fernando Gont" , "Michael Welzl" X-OriginalArrivalTime: 02 Apr 2011 22:44:25.0988 (UTC) FILETIME=[84BA6C40:01CBF187] Cc: tcpm Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 02 Apr 2011 22:42:47 -0000 Fernando, Well, I realized that you recommend (more or less explicitly), that all fields in the header that SHOULD be zero, MUST BE zero, and that any non-compliant tcp packet MUST be silently discarded (supposedly by the intended receiver or potentially even by some middlebox)... At least that's what I get just from the last two slides of your presentation. IIRC, the same recommendation is mentioned in the document for TSecr in SYN (the very bits which my current proposal would use). Although, I believe the wording there is more liberal, and does not say such a packet has to be silently discarded... I strongly object to "silently discarded". It appears to me, that this draft goes against the spirit of "be liberal what you accept, be conservative in what you do" (you=3Dtcp stack in this case). Making sure that these fields are *ignored* by implementations which can not interpret anything other than zero is what has to be stipulated - NOT silent discards! However, what I think is the right way to handle unknown values in field that (currently) have no meaning, is already specified in the protocol docs (but as a SHOULD, and MUST ignore; at least in RFC1323 timestamps it's written that way. Thus a improper implementation that leaks data by not properly initializing fields, is hurting itself more, than anyone else... Richard Scheffenegger > -----Original Message----- > From: Fernando Gont [mailto:fernando@gont.com.ar] > Sent: Samstag, 02. April 2011 20:55 > To: Michael Welzl > Cc: tcpm > Subject: [tcpm] miscellaneous comments about tcp-security (was Re: > Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) >=20 > [changed the subject, since this has nothing to do with the request > sent > by the chairs] >=20 > On 01/04/2011 12:52 p.m., Michael Welzl wrote: > > I disagree, I think this document should not be reviewed further at > this > > stage, but removed instead. >=20 > I personally believe it is harmful that the chairs are requesting > reviewers, based on a very recent discussion, and you raise issues from > a past discussion in the thread, arguing against what the wg has agreed > upon. >=20 >=20 >=20 > > Plenty of reasons, and they have all been said before - which is why > I > > also think that we should avoid even discussing this further. >=20 > This is false. The claims have been "Oh, this document is harmful!". > Please look at the only one or two concrete examples that were raised, > and my response to them. >=20 > And, FWIW, this is in I-D stage. If there's any recommendation that is > wrong, we have plenty of time to change it, and I urge you to state > explicitly which recommendations you think are incorrect, and we may > fix/eliminate them where necessary. >=20 >=20 > > The group's email archive could be read instead. >=20 > I did, but found nothing. Please provide references. >=20 >=20 >=20 > > Now, this is of course just my personal opinion; but this document > has > > been on the table quite a while now, and it wasn't clear to me in any > > way at this meeting that there would be strong interest in having it > > published, let alone contributing to it. >=20 > I don't think the past meeting was trying to sense that. It was trying > to get reviewers, and agree on a procedure to follow when reviewing the > document. >=20 > P.S.: For the sake of keeping a good signal/noise ratio and spending > the > wg's energy in getting work done, I will not respond to this thread > until it is explicitly stated what are the recommendations that are > deemed as harmful/incorrect. This thread, as is, sounds more like > flaming than anything else. >=20 > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From christos@zoulas.com Sat Apr 2 16:48:26 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869C13A68F4 for ; Sat, 2 Apr 2011 16:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9I7QDYa4sEg for ; Sat, 2 Apr 2011 16:48:25 -0700 (PDT) Received: from rebar.astron.com (rebar.astron.com [38.117.134.202]) by core3.amsl.com (Postfix) with ESMTP id BDD503A68F2 for ; Sat, 2 Apr 2011 16:48:25 -0700 (PDT) Received: by rebar.astron.com (Postfix, from userid 10080) id 25C945653E; Sat, 2 Apr 2011 19:50:06 -0400 (EDT) From: christos@zoulas.com (Christos Zoulas) Date: Sat, 2 Apr 2011 19:50:06 -0400 In-Reply-To: <5FDC413D5FA246468C200652D63E627A0DA84C0E@LDCMVEXC1-PRD.hq.netapp.com> from "Scheffenegger, Richard" (Apr 2, 11:44pm) Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: "Scheffenegger, Richard" , "Fernando Gont" , "Michael Welzl" Message-Id: <20110402235006.25C945653E@rebar.astron.com> Cc: tcpm Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 02 Apr 2011 23:48:26 -0000 On Apr 2, 11:44pm, rs@netapp.com ("Scheffenegger, Richard") wrote: -- Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Vol | Fernando, | | Well, I realized that you recommend (more or less explicitly), that all | fields in the header that SHOULD be zero, MUST BE zero, and that any | non-compliant tcp packet MUST be silently discarded (supposedly by the | intended receiver or potentially even by some middlebox)... | | At least that's what I get just from the last two slides of your | presentation. | | IIRC, the same recommendation is mentioned in the document for TSecr in | SYN (the very bits which my current proposal would use). Although, I | believe the wording there is more liberal, and does not say such a | packet has to be silently discarded... So what should a middlebox do? Scrub them to 0 or pass them along? If it scrubs them to 0 again it will be compliant, but it will break future protocol use. | I strongly object to "silently discarded". It appears to me, that this | draft goes against the spirit of "be liberal what you accept, be | conservative in what you do" (you=tcp stack in this case). Making sure | that these fields are *ignored* by implementations which can not | interpret anything other than zero is what has to be stipulated - NOT | silent discards! I can see the behavior to pass as useful (no strange packet drops, if the protocol starts using those bits, you don't need to make a middlebox understand them), but dangerous (if a middlebox passes them along was it supposed to interpret them somehow and act on them instead?). | However, what I think is the right way to handle unknown values in field | that (currently) have no meaning, is already specified in the protocol | docs (but as a SHOULD, and MUST ignore; at least in RFC1323 timestamps | it's written that way. Thus a improper implementation that leaks data by | not properly initializing fields, is hurting itself more, than anyone | else... You are just encouraging sloppy but convenient behavior. christos From rs@netapp.com Sat Apr 2 17:10:09 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E872E3A68F8 for ; Sat, 2 Apr 2011 17:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXHabdCMGFgk for ; Sat, 2 Apr 2011 17:10:09 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 7A5F53A68F4 for ; Sat, 2 Apr 2011 17:10:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,290,1299484800"; d="scan'208";a="248575650" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 02 Apr 2011 17:10:12 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p330A0T0025941; Sat, 2 Apr 2011 17:10:02 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 Apr 2011 01:09:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Apr 2011 01:09:40 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0DA84C11@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20110402235006.25C945653E@rebar.astron.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] miscellaneous comments about tcp-security (was Re:Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) Thread-Index: AcvxkLgN4WSXEJprQjm7ZI8fen3PIQAAXdpg References: <5FDC413D5FA246468C200652D63E627A0DA84C0E@LDCMVEXC1-PRD.hq.netapp.com>from "Scheffenegger, Richard" (Apr 2, 11:44pm) <20110402235006.25C945653E@rebar.astron.com> From: "Scheffenegger, Richard" To: "Christos Zoulas" , "Fernando Gont" , "Michael Welzl" X-OriginalArrivalTime: 03 Apr 2011 00:09:58.0364 (UTC) FILETIME=[77DCD9C0:01CBF193] Cc: tcpm Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re:Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 00:10:10 -0000 Hi Christos, > You are just encouraging sloppy but convenient behavior. s/sloppy/conservative/g s/convenient/liberal/g If one is paranoid, policing "unknown" behavior in a private net is fine with me. But "policing" should not be enforced ubiquitously. But this may be a minority view... > So what should a middlebox do? Scrub them to 0 or pass them along? If > it scrubs them to 0 again it will be compliant, but it will break > future protocol use. A middelbox should not mess with stuff it doesn't understand... the default should be to pass undefined bits along (it's the end hosts responsibility to not react badly). But again, a non-default option to scrub (or worse, silently drop) these packets MAY be provided. But do we need a BCP for that? I don't think so... Richard Scheffenegger > -----Original Message----- > From: Christos Zoulas [mailto:christos@zoulas.com] > Sent: Sonntag, 03. April 2011 01:50 > To: Scheffenegger, Richard; Fernando Gont; Michael Welzl > Cc: tcpm > Subject: Re: [tcpm] miscellaneous comments about tcp-security (was > Re:Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) >=20 > On Apr 2, 11:44pm, rs@netapp.com ("Scheffenegger, Richard") wrote: > -- Subject: Re: [tcpm] miscellaneous comments about tcp-security (was > Re: Vol >=20 > | Fernando, > | > | Well, I realized that you recommend (more or less explicitly), that > all > | fields in the header that SHOULD be zero, MUST BE zero, and that any > | non-compliant tcp packet MUST be silently discarded (supposedly by > the > | intended receiver or potentially even by some middlebox)... > | > | At least that's what I get just from the last two slides of your > | presentation. > | > | IIRC, the same recommendation is mentioned in the document for TSecr > in > | SYN (the very bits which my current proposal would use). Although, I > | believe the wording there is more liberal, and does not say such a > | packet has to be silently discarded... >=20 > So what should a middlebox do? Scrub them to 0 or pass them along? If > it scrubs them to 0 again it will be compliant, but it will break > future > protocol use. >=20 > | I strongly object to "silently discarded". It appears to me, that > this > | draft goes against the spirit of "be liberal what you accept, be > | conservative in what you do" (you=3Dtcp stack in this case). Making > sure > | that these fields are *ignored* by implementations which can not > | interpret anything other than zero is what has to be stipulated - NOT > | silent discards! >=20 > I can see the behavior to pass as useful (no strange packet drops, if > the protocol starts using those bits, you don't need to make a > middlebox > understand them), but dangerous (if a middlebox passes them along was > it > supposed to interpret them somehow and act on them instead?). >=20 > | However, what I think is the right way to handle unknown values in > field > | that (currently) have no meaning, is already specified in the > protocol > | docs (but as a SHOULD, and MUST ignore; at least in RFC1323 > timestamps > | it's written that way. Thus a improper implementation that leaks data > by > | not properly initializing fields, is hurting itself more, than anyone > | else... >=20 > You are just encouraging sloppy but convenient behavior. >=20 > christos > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From christos@zoulas.com Sat Apr 2 19:18:51 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774E53A68FF for ; Sat, 2 Apr 2011 19:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m5OHccWuiJ8 for ; Sat, 2 Apr 2011 19:18:50 -0700 (PDT) Received: from rebar.astron.com (rebar.astron.com [38.117.134.202]) by core3.amsl.com (Postfix) with ESMTP id A38DB3A68FE for ; Sat, 2 Apr 2011 19:18:50 -0700 (PDT) Received: by rebar.astron.com (Postfix, from userid 10080) id C455C5653F; Sat, 2 Apr 2011 22:20:30 -0400 (EDT) From: christos@zoulas.com (Christos Zoulas) Date: Sat, 2 Apr 2011 22:20:30 -0400 In-Reply-To: <5FDC413D5FA246468C200652D63E627A0DA84C11@LDCMVEXC1-PRD.hq.netapp.com> from "Scheffenegger, Richard" (Apr 3, 1:09am) Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: "Scheffenegger, Richard" , "Fernando Gont" , "Michael Welzl" Message-Id: <20110403022030.C455C5653F@rebar.astron.com> Cc: tcpm Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re:Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 02:18:51 -0000 On Apr 3, 1:09am, rs@netapp.com ("Scheffenegger, Richard") wrote: -- Subject: RE: [tcpm] miscellaneous comments about tcp-security (was Re:Volu | > You are just encouraging sloppy but convenient behavior. | | s/sloppy/conservative/g | s/convenient/liberal/g | | If one is paranoid, policing "unknown" behavior in a private net is fine | with me. But "policing" should not be enforced ubiquitously. But this | may be a minority view... I still think it is sloppy. Why would we get non-zero bits in there in the first place? The only reason I can think is because someone forgot to zero them and we are getting trash from the heap or the stack. We all keep finding information disclosure issues in code all the time because we forget to initialize things. In this case it is not a security issue, but we should not encourage sloppy coding uniformly so that people improve their coding practices. | > So what should a middlebox do? Scrub them to 0 or pass them along? If | > it scrubs them to 0 again it will be compliant, but it will break | > future protocol use. | | A middelbox should not mess with stuff it doesn't understand... the | default should be to pass undefined bits along (it's the end hosts | responsibility to not react badly). But again, a non-default option to | scrub (or worse, silently drop) these packets MAY be provided. But do we | need a BCP for that? I don't think so... I like specifications that don't have "may"s. "May"s just lead to ambiguity, and make testing more complex. I think we should be moving towards making specifications stricter and not liberal. In this case perhaps it is too late. christos From mattmathis@google.com Sat Apr 2 20:33:31 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1FE28C0E1 for ; Sat, 2 Apr 2011 20:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgazcyE3Fm+8 for ; Sat, 2 Apr 2011 20:33:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id AFC0628C0D0 for ; Sat, 2 Apr 2011 20:33:28 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p333Z91O003977 for ; Sat, 2 Apr 2011 20:35:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301801709; bh=SbiwdYllu6YGF9F4v3DZUrJWL5k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=P4AVkZXvP+olYLs6W5VhBFZxI1/bsY4yPAO1UDhuhpBaVPC+9duz6/T+umIGSepLv NHfu3WK9+ilkcgSK/gsUA== Received: from ewy3 (ewy3.prod.google.com [10.241.103.3]) by hpaq3.eem.corp.google.com with ESMTP id p333Z75a001099 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 2 Apr 2011 20:35:08 -0700 Received: by ewy3 with SMTP id 3so1626921ewy.22 for ; Sat, 02 Apr 2011 20:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XQVGkBqPaqgORupv/7zMelV4pUIerm8jtlVFe6uHlD8=; b=g+D1LArEzmTHuSmUWvm/Isa8cIc4KTLksQVq3bAYWTgdG+oFShLeElbXgDTdtBAXUu SvBauvSaoqJ7db3U1taw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gxw7/gwcaFWsSWEA+uBwOToOvRYwi0UaYSiJ7qeFJBda0TdmencWHl0OtOIAshJeCl Hv3lxZUtRH8OY6+CayRw== MIME-Version: 1.0 Received: by 10.213.27.19 with SMTP id g19mr1002240ebc.127.1301801707549; Sat, 02 Apr 2011 20:35:07 -0700 (PDT) Received: by 10.213.104.139 with HTTP; Sat, 2 Apr 2011 20:35:07 -0700 (PDT) In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C026F62E6@SLFSNX.rcs.alcatel-research.de> References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> <1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> <5FDC413D5FA246468C200652D63E627A0D9D5908@LDCMVEXC1-PRD.hq.netapp.com> <133D9897FB9C5E4E9DF2779DC91E947C026F62E6@SLFSNX.rcs.alcatel-research.de> Date: Sat, 2 Apr 2011 23:35:07 -0400 Message-ID: From: Matt Mathis To: "SCHARF, Michael" Content-Type: multipart/alternative; boundary=0015174c18f658b4e7049ffb5496 X-System-Of-Record: true Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 03:33:31 -0000 --0015174c18f658b4e7049ffb5496 Content-Type: text/plain; charset=ISO-8859-1 We will address comments raised on the list. So far most have been clarifications, but people have found a minor bug or two. The scope change has to do with the issue that Nandita mentioned earlier in the thread: linux reduces cwnd to flightsize beyond the extent required by standards. There are a number of people who insist that this algorithm (cwnd moderation) is critical for correct operation. We want to consider an alternative or two and evaluate the trade-offs. The resulting document is likely to have wider scope than just recovery, but we haven't determined exactly yet. (An no, it isn't a Linux specific issue). The point of view will be: increasing the accuracy with which the primary congestion control algorithm regulates the TCP window, by reducing the extent to which non-loss/non-ecn events such as application stalls, reordering etc, perturb cwnd. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Fri, Apr 1, 2011 at 3:07 AM, SCHARF, Michael < Michael.Scharf@alcatel-lucent.com> wrote: > Matt, > > > > When you said "interest", did you actually mean as a WG item? You > > didn't quite ask the question. > > > > We plan to update the document and bring it to the next IETF in any > > case, and we know of a number of individuals who have expressed > > interest. > > It would be excellent to have an update that addresses the comments on the > list. > > > > My only reservation with making it a WG item is that we expect to > > broaden the scope somewhat, and the current file and document names > > may not be appropriate. As long as a future scope changes are not a > > problem, a WG item would be preferred. > > Could you please detail these expected scope changes? > > Thanks > > Michael > > --0015174c18f658b4e7049ffb5496 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We will address comments raised on the list. =A0 So far most have been clar= ifications, but people have found a minor bug or two.

Th= e scope change has to do with the issue that Nandita mentioned earlier in t= he thread: linux reduces cwnd to flightsize beyond the extent required by s= tandards. =A0There are a number of people who insist that this algorithm (c= wnd moderation) is critical for correct operation. =A0 We want to consider = an alternative or two and=A0evaluate=A0the=A0trade-offs. =A0 The resulting = document is likely to have wider scope than just recovery, but we haven'= ;t determined exactly yet. =A0 (An no, it isn't a Linux specific issue)= .

The point of view will be: increasing the accuracy with= which the primary congestion control algorithm regulates the TCP window, b= y reducing the extent to which=A0non-loss/non-ecn events such as=A0applicat= ion stalls, reordering etc, perturb cwnd.

Thanks,
--MM--
The best way to predic= t the future is to create it. =A0- Alan Kay



On Fri, Apr 1, 2011 at 3:07 AM, SCHARF, = Michael <Michael.Scharf@alcatel-lucent.com> wrote:

Matt,



> When you said "interest", did you actually mean as a WG item= ?=A0=A0 You
> didn't quite ask the question.
>
> We plan to update the document and bring it to the next IETF in any > case, and we know of=A0 a number of individuals who have expressed
> interest.

It would be excellent to have an update that addresses the comments on the = list.


> My only reservation with making it a WG item is that we expect to
> broaden the scope somewhat, and the current file and document names > may not be appropriate.=A0=A0 As long as a future scope changes are no= t a
> problem, a WG item would be preferred.

Could you please detail these expected scope changes?

Thanks

Michael


--0015174c18f658b4e7049ffb5496-- From michawe@ifi.uio.no Sun Apr 3 00:16:35 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4EA3A6934 for ; Sun, 3 Apr 2011 00:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtfieF22r9sD for ; Sun, 3 Apr 2011 00:16:34 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id B28593A6932 for ; Sun, 3 Apr 2011 00:16:33 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1Q6HZb-0005qt-HV; Sun, 03 Apr 2011 09:18:11 +0200 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Q6HZa-0005bG-W8; Sun, 03 Apr 2011 09:18:11 +0200 Message-Id: From: Michael Welzl To: christos@zoulas.com (Christos Zoulas) In-Reply-To: <20110403022030.C455C5653F@rebar.astron.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 3 Apr 2011 09:17:45 +0200 References: <20110403022030.C455C5653F@rebar.astron.com> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 8171 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6DDBFA2372AC5B514ADBCE4FE0E12DF29CE6B06F X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 848 max/h 18 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm , Fernando Gont Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re:Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 07:16:35 -0000 On Apr 3, 2011, at 4:20 AM, Christos Zoulas wrote: > On Apr 3, 1:09am, rs@netapp.com ("Scheffenegger, Richard") wrote: > -- Subject: RE: [tcpm] miscellaneous comments about tcp-security > (was Re:Volu > > | > You are just encouraging sloppy but convenient behavior. > | > | s/sloppy/conservative/g > | s/convenient/liberal/g > | > | If one is paranoid, policing "unknown" behavior in a private net > is fine > | with me. But "policing" should not be enforced ubiquitously. But > this > | may be a minority view... > > I still think it is sloppy. Why would we get non-zero bits in there > in the first place? The only reason I can think is because someone > forgot to zero them and we are getting trash from the heap or the > stack. We all keep finding information disclosure issues in code > all the time because we forget to initialize things. In this case > it is not a security issue, but we should not encourage sloppy coding > uniformly so that people improve their coding practices. The reason to get non-zero bits that we are all concerned about here is that the IETF has developed something new that your middlebox doesn't yet understand. Future mechanism X could make TCP go a little faster, but it requires a new bit (say, one of the reserved bits); your middlebox drops it; because the risk of even very rarely having packets consistently dropped greatly outweighs the potential benefit of having TCP go a bit faster, people will tend to not use mechanism X. Replace mechanism X with ECN, and you see the point, I hope. I looked for the reserved bits in Fernando's document just now, and must admit that I was a bit surprised to see that it says exactly that: "TCP MUST ignore the Reserved field of incoming TCP segments. DISCUSSION: Internet-Draft TCP Security Assessment January 2011 These four bits are reserved for future use, and must be zero. As with virtually every field, the Reserved field could be used as a covert channel. While there exist intermediate devices such as protocol scrubbers that clear these bits, and firewalls that drop/ reject segments with any of these bits set, these devices should consider the impact of these policies on TCP interoperability. For example, as TCP continues to evolve, all or part of the bits in the Reserved field could be used to implement some new functionality. If some middle-box or end-system implementation were to drop a TCP segment merely because some of these bits are not set to zero, interoperability problems would arise." I have no problem with this text in the draft. (although it just repeats "be liberal in what you accept"). > | > So what should a middlebox do? Scrub them to 0 or pass them > along? If > | > it scrubs them to 0 again it will be compliant, but it will break > | > future protocol use. > | > | A middelbox should not mess with stuff it doesn't understand... the > | default should be to pass undefined bits along (it's the end hosts > | responsibility to not react badly). But again, a non-default > option to > | scrub (or worse, silently drop) these packets MAY be provided. But > do we > | need a BCP for that? I don't think so... > > I like specifications that don't have "may"s. "May"s just lead to > ambiguity, > and make testing more complex. I think we should be moving towards > making > specifications stricter and not liberal. In this case perhaps it is > too late. I think it is good practice to require as little as possible in protocol design. I'm sure that this is explained in an RFC somewhere - it should?! Cheers, Michael From fernando.gont.netbook.win@gmail.com Sun Apr 3 04:13:46 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31623A698C for ; Sun, 3 Apr 2011 04:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6YRzkY9FhjF for ; Sun, 3 Apr 2011 04:13:46 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D3A063A6984 for ; Sun, 3 Apr 2011 04:13:45 -0700 (PDT) Received: by bwz13 with SMTP id 13so3729367bwz.31 for ; Sun, 03 Apr 2011 04:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=X6nnlLL6zqwzA0fXOvN5KEEN/I6BQjgF+O8a17e2Eho=; b=ZT9ct9JjpXXudhD86FYvlfB5CLorZ8zsBZPwV6v373E4htIoU+53ieSOqEZUr4liMS 507Y6dAwXfr3CZMGSNBix7J0OXzHkTh6qH2tthmB4IkmxYtdxx3ZBkmBh5Yg6l96lxP5 7sH27DQIstfparsSxVCyWl25RMaUGYadzNQFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=bMR6wCh0PBgx8uQKpMPjQxccrwH4nk0VlrG1FGYV9BfRV8sWX8vAoWriM18H0F7sc8 9+30X7MLLR6yvaOA4SfLJJJMe3HrBK3wJwJ0arUIOJa54HEIT5twSX/nC4y/Hzda+Y8Z hbtxcj5OXi9mUsCD93te2YjdGlppfB6u8nKP0= Received: by 10.204.19.83 with SMTP id z19mr5185651bka.191.1301829326559; Sun, 03 Apr 2011 04:15:26 -0700 (PDT) Received: from [192.168.1.19] (ip-84-42-135-174.net.upcbroadband.cz [84.42.135.174]) by mx.google.com with ESMTPS id t1sm2399604bkx.7.2011.04.03.04.15.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 04:15:25 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9773B4.6090903@gont.com.ar> Date: Sat, 02 Apr 2011 16:06:28 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> <5FDC413D5FA246468C200652D63E627A0DA84BF4@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0DA84BF4@LDCMVEXC1-PRD.hq.netapp.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm , shep@alum.mit.edu, Michael Welzl Subject: [tcpm] tcp-security and tcp extensions (was: Re: Volunteers to review (parts of)draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 11:13:46 -0000 On 01/04/2011 08:41 p.m., Scheffenegger, Richard wrote: > After attending to Joe's and Bob's IP ID Reuse presentation, and talking > with Tim, I'm thinking that nailing everything down completely would > disable any future room for improvement. In particular, when certain > field are currently simply ignored, with these BCP doc all these packets > would have to be discarded I don't follow. Could please provide a reference to a specific paragraph in the tcp-security I-D that argues that because a field is currently unused, a node should drop packets that have that bit set? -- And, if you find one of such instances, we should fix it. That's it. -- Alas, that's the reason why the tcp-security is in I-D stage. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Sun Apr 3 04:28:38 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7AC3A6989 for ; Sun, 3 Apr 2011 04:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5ykXHQnelh1 for ; Sun, 3 Apr 2011 04:28:33 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 400303A6784 for ; Sun, 3 Apr 2011 04:28:32 -0700 (PDT) Received: by bwz13 with SMTP id 13so3733939bwz.31 for ; Sun, 03 Apr 2011 04:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=buckKzR65JHadTTl1DADoiFDg7jsDI40tW8WQuZiNfk=; b=KtbnbJjE3EXZS+E/8/qxe04XUwgz705AkaFZevWkNvU9a3UMUh7qlqouVicuURdgC3 ZqY+hHCVFi/VMwULOlvmtBnkrHKnf9f2Jjhs47QpWgdasgWqsNapLxNOu2y+I6TjjJdH 0BKi1Rpy4npUVvp6t7bxUd3TFfkOKve3Wxvd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=wlIm+nfudZzW/Y/NGUguCCcyORXbxq6yj3IiiOVOKsR22gJnOFt38m7XA5nXK1nnK0 0Rj/8vYBAZ1AAgkcAdmd2q7XXNC8gkMBic78jY0rsFitrIAQXADdh+Lrj5LJJhVtSAN9 PvMzXZzzHrDwTcx5aw/jVOQn8wIJXbMnfORE4= Received: by 10.204.136.1 with SMTP id p1mr1255609bkt.105.1301830213183; Sun, 03 Apr 2011 04:30:13 -0700 (PDT) Received: from [192.168.1.19] (ip-84-42-135-174.net.upcbroadband.cz [84.42.135.174]) by mx.google.com with ESMTPS id 16sm2406043bkm.6.2011.04.03.04.30.11 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2011 04:30:12 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D985A41.10302@gont.com.ar> Date: Sun, 03 Apr 2011 08:30:09 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de><414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> <4D9770F1.8010800@gont.com.ar> <5FDC413D5FA246468C200652D63E627A0DA84C0E@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0DA84C0E@LDCMVEXC1-PRD.hq.netapp.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm , Michael Welzl Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 11:28:39 -0000 Hi, Richard, On 02/04/2011 07:44 p.m., Scheffenegger, Richard wrote: > Well, I realized that you recommend (more or less explicitly), that all > fields in the header that SHOULD be zero, MUST BE zero, and that any > non-compliant tcp packet MUST be silently discarded (supposedly by the > intended receiver or potentially even by some middlebox)... I personally believe that the reserved bits MUST be zero -- actually, that's what is generally REQUIRED by the *specs* (i.e., "Unused. MUST be set to zero, and ignored by the receiver" stuff). Regarding what to do with unused bits that are set, I agree the proper thing to do would be to ignore them, such that when those bits are specified in some future extension, that extension can be deployed. -- so if there's advice that goes against this principle, I'd be glad to change it. Anyway, the above is *my* view, but if the wg agreed otherwise, I'd be happy to change the relevant text. > I strongly object to "silently discarded". It appears to me, that this > draft goes against the spirit of "be liberal what you accept, be > conservative in what you do" (you=tcp stack in this case). Making sure > that these fields are *ignored* by implementations which can not > interpret anything other than zero is what has to be stipulated - NOT > silent discards! Which field are your referring to, in this case? > However, what I think is the right way to handle unknown values in field > that (currently) have no meaning, is already specified in the protocol > docs (but as a SHOULD, and MUST ignore; at least in RFC1323 timestamps > it's written that way. Thus a improper implementation that leaks data by > not properly initializing fields, is hurting itself more, than anyone > else... Any implementation that leaks information, or has packet-of-death attacks, etc., hurts itself. But due to programming errors, we have seen to many of these issues. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From michawe@ifi.uio.no Sun Apr 3 05:25:23 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA4F3A69BE for ; Sun, 3 Apr 2011 05:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48bJOr7rBPfR for ; Sun, 3 Apr 2011 05:25:10 -0700 (PDT) Received: from mail-out2.uio.no (mail-forward2.uio.no [IPv6:2001:700:100:10::71]) by core3.amsl.com (Postfix) with ESMTP id D9ABC3A67D1 for ; Sun, 3 Apr 2011 05:25:02 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.74) (envelope-from ) id 1Q6MO7-0006Qa-CQ; Sun, 03 Apr 2011 14:26:39 +0200 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Q6MO6-0002fe-Ro; Sun, 03 Apr 2011 14:26:39 +0200 Message-Id: From: Michael Welzl To: Fernando Gont In-Reply-To: <4D9773B4.6090903@gont.com.ar> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 3 Apr 2011 14:26:17 +0200 References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> <5FDC413D5FA246468C200652D63E627A0DA84BF4@LDCMVEXC1-PRD.hq.netapp.com> <4D9773B4.6090903@gont.com.ar> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 9 sum msgs/h 4 total rcpts 8186 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 581CEFB272F77F8AFABC4A654E5F6350800E6AC0 X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 857 max/h 18 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm , shep@alum.mit.edu Subject: Re: [tcpm] tcp-security and tcp extensions (was: Re: Volunteers to review (parts of)draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 12:25:23 -0000 Hi all, On Apr 2, 2011, at 9:06 PM, Fernando Gont wrote: > On 01/04/2011 08:41 p.m., Scheffenegger, Richard wrote: >> After attending to Joe's and Bob's IP ID Reuse presentation, and >> talking >> with Tim, I'm thinking that nailing everything down completely would >> disable any future room for improvement. In particular, when certain >> field are currently simply ignored, with these BCP doc all these >> packets >> would have to be discarded > > I don't follow. Could please provide a reference to a specific > paragraph > in the tcp-security I-D that argues that because a field is currently > unused, a node should drop packets that have that bit set? > > -- And, if you find one of such instances, we should fix it. That's > it. > -- Alas, that's the reason why the tcp-security is in I-D stage. From a quick glance, it indeed seems that Fernando has removed a lot of the "nailing down" text. So I will change my assertion of the document: - If ALL such text is removed / fixed, I no longer consider the document dangerous. In this case, I still consider it useless, because it seems (remember, I might be wrong, I didn't read the 100+ pages) to give just plenty of mundane advice, basically repeating what other specifications say in different words. It seems to me that it is this mundane advice that makes the document as long as it is. By "mundane advice", I mean: spec. A would say "this is the length field. it should have the length" and this doc would say "if the length doesn't match, drop the packet". This isn't harmful, but not worth specifying, to me. Fernando says that the necessity to specify such things comes from real experience. I can appreciate this view; I take a neutral position on this (i.e. I personally consider it useless, but if TCPM wants to publish that, I won't object). I repeat, this is IFF all text that would hinder future innovation as discussed above and in the few previous emails would be removed. Someone besides Fernando himself would have to make this check, and I'm not going to volunteer because I've read a previous version of the document before, and it was just painful and long. In a nutshell, because I am getting the impression that Fernando is willing to remove all such dangerous advice, I take back what I said before about reviewing the document. If there are volunteers to take up the work, fine with me. Cheers, Michael From L.Wood@surrey.ac.uk Sun Apr 3 05:38:15 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DD83A67CC for ; Sun, 3 Apr 2011 05:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLC9beCrTuGh for ; Sun, 3 Apr 2011 05:38:14 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 19A243A67C3 for ; Sun, 3 Apr 2011 05:38:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-9.tower-72.messagelabs.com!1301834393!27601403!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.43] Received: (qmail 6096 invoked from network); 3 Apr 2011 12:39:54 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-9.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 3 Apr 2011 12:39:54 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.223]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Sun, 3 Apr 2011 13:39:53 +0100 From: To: Date: Sun, 3 Apr 2011 13:39:52 +0100 Thread-Topic: [tcpm] tcp-security and tcp extensions (was: Re: Volunteers to review (parts of)draft-ietf-tcpm-tcp-security) Thread-Index: Acvx/DsN9ozYatigQbWd4661DctQLQ== Message-ID: References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> <5FDC413D5FA246468C200652D63E627A0DA84BF4@LDCMVEXC1-PRD.hq.netapp.com> <4D9773B4.6090903@gont.com.ar> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org, shep@alum.mit.edu, fernando@gont.com.ar, L.Wood@surrey.ac.uk Subject: Re: [tcpm] tcp-security and tcp extensions (was: Re: Volunteers to review (parts of)draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 12:38:15 -0000 On 3 Apr 2011, at 13:26, Michael Welzl wrote: >=20 > I repeat, this is IFF all text that would hinder future innovation as =20 > discussed above and in the few previous emails would be removed. For clarity, that is presumably the mathematicians' 'If and only if' abbrev= iation and not a typo... http://en.wikipedia.org/wiki/If_and_only_if From christos@zoulas.com Sun Apr 3 09:50:14 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30163A6850 for ; Sun, 3 Apr 2011 09:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-lNP1c0DzgX for ; Sun, 3 Apr 2011 09:50:14 -0700 (PDT) Received: from rebar.astron.com (rebar.astron.com [38.117.134.202]) by core3.amsl.com (Postfix) with ESMTP id 42E483A684F for ; Sun, 3 Apr 2011 09:50:13 -0700 (PDT) Received: by rebar.astron.com (Postfix, from userid 10080) id 1066A5653E; Sun, 3 Apr 2011 12:51:55 -0400 (EDT) From: christos@zoulas.com (Christos Zoulas) Date: Sun, 3 Apr 2011 12:51:54 -0400 In-Reply-To: from Michael Welzl (Apr 3, 9:17am) Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: Michael Welzl Message-Id: <20110403165155.1066A5653E@rebar.astron.com> Cc: tcpm , Fernando Gont Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re:Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 16:50:15 -0000 On Apr 3, 9:17am, michawe@ifi.uio.no (Michael Welzl) wrote: -- Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re:Volu | The reason to get non-zero bits that we are all concerned about here | is that the IETF has developed something new that your middlebox | doesn't yet understand. Future mechanism X could make TCP go a little | faster, but it requires a new bit (say, one of the reserved bits); | your middlebox drops it; because the risk of even very rarely having | packets consistently dropped greatly outweighs the potential benefit | of having TCP go a bit faster, people will tend to not use mechanism X. | | Replace mechanism X with ECN, and you see the point, I hope. Now imagine the situation where half of the TCP/IP stack implementations put random values in the reserved bits, before one of those bits became mechanism X. This is why I am advocating to specify that the unused bits should be zero. So that they can be used in the future, and to promote safe coding practices. | I think it is good practice to require as little as possible in | protocol design. I'm sure that this is explained in an RFC somewhere - | it should?! Require as little as possible does not conflict with specify the implementations behavior as completely as possible. christos From michawe@ifi.uio.no Sun Apr 3 10:14:37 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6555D3A697E for ; Sun, 3 Apr 2011 10:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.399 X-Spam-Level: X-Spam-Status: No, score=-104.399 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mF429WGyn1Gn for ; Sun, 3 Apr 2011 10:14:36 -0700 (PDT) Received: from mail-out2.uio.no (mail-forward2.uio.no [IPv6:2001:700:100:10::71]) by core3.amsl.com (Postfix) with ESMTP id 467DB3A684F for ; Sun, 3 Apr 2011 10:14:36 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.74) (envelope-from ) id 1Q6QuH-0003ny-SU; Sun, 03 Apr 2011 19:16:09 +0200 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Q6QuH-0008AX-7B; Sun, 03 Apr 2011 19:16:09 +0200 Message-Id: <3A2ADD56-5AC0-4918-B8DC-861E1A866661@ifi.uio.no> From: Michael Welzl To: Christos Zoulas In-Reply-To: <20110403165155.1066A5653E@rebar.astron.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 3 Apr 2011 19:15:47 +0200 References: <20110403165155.1066A5653E@rebar.astron.com> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 5 sum msgs/h 1 total rcpts 8191 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F5EB000EB75D89D6F4ADE79126C87FEB8B1BFC57 X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 859 max/h 18 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm , Fernando Gont Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re:Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 17:14:37 -0000 On Apr 3, 2011, at 6:51 PM, Christos Zoulas wrote: > On Apr 3, 9:17am, michawe@ifi.uio.no (Michael Welzl) wrote: > -- Subject: Re: [tcpm] miscellaneous comments about tcp-security > (was Re:Volu > > | The reason to get non-zero bits that we are all concerned about here > | is that the IETF has developed something new that your middlebox > | doesn't yet understand. Future mechanism X could make TCP go a > little > | faster, but it requires a new bit (say, one of the reserved bits); > | your middlebox drops it; because the risk of even very rarely having > | packets consistently dropped greatly outweighs the potential benefit > | of having TCP go a bit faster, people will tend to not use > mechanism X. > | > | Replace mechanism X with ECN, and you see the point, I hope. > > Now imagine the situation where half of the TCP/IP stack > implementations > put random values in the reserved bits, before one of those bits > became mechanism X. This is why I am advocating to specify that > the unused bits should be zero. So that they can be used in the > future, and to promote safe coding practices. I agree that they should by default by zeroed by the sender, and I think this is probably written in some RFC somewhere; but this is the least important aspect, I'd say, as new specifications don't normally require them to be zero by default, as you can't really rely on this in the Internet anyway. The more important thing is that middleboxes don't zero them (thereby a new mechanism not yet known to this middlebox), let alone drop them (thereby giving people a good reason to almost never turn the new mechanism on). > | I think it is good practice to require as little as possible in > | protocol design. I'm sure that this is explained in an RFC > somewhere - > | it should?! > > Require as little as possible does not conflict with specify the > implementations behavior as completely as possible. Correct, and it does not conflict with what you said before, to which I answered. What you said was "May's just lead to ambiguity, and make testing more complex. I think we should be moving towards making specifications stricter and not liberal." By "require" as little as possible I meant "use only as many MUSTs as you have to". Cheers, Michael From wes@mti-systems.com Sun Apr 3 11:45:14 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A64B28C0F8 for ; Sun, 3 Apr 2011 11:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q68iJumHgrAI for ; Sun, 3 Apr 2011 11:45:13 -0700 (PDT) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by core3.amsl.com (Postfix) with ESMTP id 572A728C0F3 for ; Sun, 3 Apr 2011 11:45:13 -0700 (PDT) Received: from cm-omr13 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p33Iks2M005565 for ; Sun, 3 Apr 2011 14:46:54 -0400 Authentication-Results: cm-omr13 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.41.146] ([174.130.41.146:59769] helo=[192.168.1.101]) by cm-omr13 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 5C/13-15894-E90C89D4; Sun, 03 Apr 2011 14:46:54 -0400 Message-ID: <4D98C09C.9050205@mti-systems.com> Date: Sun, 03 Apr 2011 20:46:52 +0200 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: tcpm@ietf.org References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> <4D9770F1.8010800@gont.com.ar> <9EC7C0A8-D383-4D8A-9EC0-D952E2EE53F2@ifi.uio.no> In-Reply-To: <9EC7C0A8-D383-4D8A-9EC0-D952E2EE53F2@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 18:45:14 -0000 On 4/2/2011 9:40 PM, Michael Welzl wrote: > > On Apr 2, 2011, at 8:54 PM, Fernando Gont wrote: > >> [changed the subject, since this has nothing to do with the request sent >> by the chairs] >> >> On 01/04/2011 12:52 p.m., Michael Welzl wrote: >>> I disagree, I think this document should not be reviewed further at this >>> stage, but removed instead. >> >> I personally believe it is harmful that the chairs are requesting >> reviewers, based on a very recent discussion, and you raise issues from >> a past discussion in the thread, arguing against what the wg has agreed >> upon. > > Hm, you have a point there. I still have the same opinion as I had then, > but I might be mistaken about IETF procedures. > Now that the WG approved it as a WG document, *can* it even be stopped? > Can the WG change its mind and kick it out if there is consensus for > doing so, or lack of interest for it? > > I will wait for an answer to this from the chairs before I even > continue. I don't want to waste everyone's time. > Hi Michael, I'm not one of the chairs, but I used to be, so maybe I can help answer this :). WG documents can expire just like any other I-D, and charter milestones can be removed at chairs' request, with AD approval. In fact, this possibility had been considered with the tcp-security document in the past. However, following the Beijing meeting, Fernando made a large effort to rewrite the document and make the recommendations clearly separated from the rationale so that the process of reviewing them that had begun in Anaheim could continue, and we decided to give it one more chance. Prior to Prague, we'd seen only about 3 people (not including Fernando) volunteer to help review, but we planned to ask during the meeting, and were considering that we might have to drop it as a WG item if we couldn't find at least 5. I saw about 6 hands in the meeting, plus the 3 we already had. So, this looked to me like it might have just enough energy to continue. I think Richard's note in this thread actually identifies key reasons why TCPM needs to do this document. Without recommendations from the IETF on how to harden TCP stacks without limiting innovation potential, recommendations from outside will almost certainly be too restrictive. -- Wes Eddy MTI Systems From Donald.Smith@qwest.com Sun Apr 3 12:15:04 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565843A69D8 for ; Sun, 3 Apr 2011 12:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpmN8VSAXFmt for ; Sun, 3 Apr 2011 12:15:03 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 18C723A69D6 for ; Sun, 3 Apr 2011 12:15:03 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id p33JGdUP016287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Apr 2011 14:16:40 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id AD7331E004D; Sun, 3 Apr 2011 14:16:34 -0500 (CDT) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 94E0A1E0032; Sun, 3 Apr 2011 14:16:34 -0500 (CDT) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id p33JGXxQ002932; Sun, 3 Apr 2011 14:16:33 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Sun, 3 Apr 2011 13:16:32 -0600 From: "Smith, Donald" To: Wesley Eddy , "tcpm@ietf.org" Date: Sun, 3 Apr 2011 13:15:42 -0600 Thread-Topic: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) Thread-Index: AcvyL4SX7grJyiKLQ0irNjDHdkRO1wABAHaN Message-ID: References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> <414DE818-6083-402F-BECA-AEFE1340BCEE@ifi.uio.no> <4D9770F1.8010800@gont.com.ar> <9EC7C0A8-D383-4D8A-9EC0-D952E2EE53F2@ifi.uio.no>, <4D98C09C.9050205@mti-systems.com> In-Reply-To: <4D98C09C.9050205@mti-systems.com> 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 X-CFilter-Loop: Reflected Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 03 Apr 2011 19:15:04 -0000 I have volunteered to review this in the past and will review the new versi= on soon. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Wesley Edd= y [wes@mti-systems.com] Sent: Sunday, April 03, 2011 12:46 PM To: tcpm@ietf.org Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Vol= unteers to review (parts of) draft-ietf-tcpm-tcp-security) On 4/2/2011 9:40 PM, Michael Welzl wrote: > > On Apr 2, 2011, at 8:54 PM, Fernando Gont wrote: > >> [changed the subject, since this has nothing to do with the request sent >> by the chairs] >> >> On 01/04/2011 12:52 p.m., Michael Welzl wrote: >>> I disagree, I think this document should not be reviewed further at thi= s >>> stage, but removed instead. >> >> I personally believe it is harmful that the chairs are requesting >> reviewers, based on a very recent discussion, and you raise issues from >> a past discussion in the thread, arguing against what the wg has agreed >> upon. > > Hm, you have a point there. I still have the same opinion as I had then, > but I might be mistaken about IETF procedures. > Now that the WG approved it as a WG document, *can* it even be stopped? > Can the WG change its mind and kick it out if there is consensus for > doing so, or lack of interest for it? > > I will wait for an answer to this from the chairs before I even > continue. I don't want to waste everyone's time. > Hi Michael, I'm not one of the chairs, but I used to be, so maybe I can help answer this :). WG documents can expire just like any other I-D, and charter milestones can be removed at chairs' request, with AD approval. In fact, this possibility had been considered with the tcp-security document in the past. However, following the Beijing meeting, Fernando made a large effort to rewrite the document and make the recommendations clearly separated from the rationale so that the process of reviewing them that had begun in Anaheim could continue, and we decided to give it one more chance. Prior to Prague, we'd seen only about 3 people (not including Fernando) volunteer to help review, but we planned to ask during the meeting, and were considering that we might have to drop it as a WG item if we couldn't find at least 5. I saw about 6 hands in the meeting, plus the 3 we already had. So, this looked to me like it might have just enough energy to continue. I think Richard's note in this thread actually identifies key reasons why TCPM needs to do this document. Without recommendations from the IETF on how to harden TCP stacks without limiting innovation potential, recommendations from outside will almost certainly be too restrictive. -- Wes Eddy MTI Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From shoaibrm@gmail.com Sun Apr 3 19:25:08 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE353A68F1 for ; Sun, 3 Apr 2011 19:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4POoyNht2Lc for ; Sun, 3 Apr 2011 19:25:06 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id C90F53A68C7 for ; Sun, 3 Apr 2011 19:25:06 -0700 (PDT) Received: by pzk30 with SMTP id 30so1529963pzk.31 for ; Sun, 03 Apr 2011 19:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tPRtux6IEhca0Hy/EIJQhjk/aFCiVJ+il8SIneSE01I=; b=sJ0mIcIaFBjYa4yJ5T9SQhxTVI5FfL62+/WJavdbB24hy+8NutEMDwPW4GMuhNspQA TM2XQQ6CSAAymsu+jTsMZ4Q7Fts1GDroi3BnEFgl+h0C5xDPhzPVR6vCrfY6IVGcwbCS 8za19eDKRruqjmgEP9J0btWuqZufveTxXoh04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=l10zJNiT45i7eUxl5XrESSjdlNX3acDxuj3J/bDCJDKAzLQUdRPwMs1WteMcNYDNdN F2oWmKKRoetAuVSmFVY/ZCc+wK3xl3ODWGJvKnDElCpi/TFJOPg7oQPqqHouYZe3m+wP 80UPpYuRqvMwzlorrJJRIz5fw/KmK6MT1PJSI= Received: by 10.143.26.19 with SMTP id d19mr5615520wfj.131.1301884008723; Sun, 03 Apr 2011 19:26:48 -0700 (PDT) Received: from [192.168.1.105] (c-67-161-1-45.hsd1.ca.comcast.net [67.161.1.45]) by mx.google.com with ESMTPS id p40sm6915357wfc.5.2011.04.03.19.26.46 (version=SSLv3 cipher=OTHER); Sun, 03 Apr 2011 19:26:47 -0700 (PDT) Message-ID: <4D992C65.6080208@gmail.com> Date: Sun, 03 Apr 2011 19:26:45 -0700 From: Shoaib Rao User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: tcpm@ietf.org References: <20110402235006.25C945653E@rebar.astron.com> In-Reply-To: <20110402235006.25C945653E@rebar.astron.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 02:25:08 -0000 On 04/02/2011 04:50 PM, Christos Zoulas wrote: > On Apr 2, 11:44pm, rs@netapp.com ("Scheffenegger, Richard") wrote: > -- Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Vol > > | Fernando, > | > | Well, I realized that you recommend (more or less explicitly), that all > | fields in the header that SHOULD be zero, MUST BE zero, and that any > | non-compliant tcp packet MUST be silently discarded (supposedly by the > | intended receiver or potentially even by some middlebox)... > | > | At least that's what I get just from the last two slides of your > | presentation. > | > | IIRC, the same recommendation is mentioned in the document for TSecr in > | SYN (the very bits which my current proposal would use). Although, I > | believe the wording there is more liberal, and does not say such a > | packet has to be silently discarded... > > So what should a middlebox do? Scrub them to 0 or pass them along? If > it scrubs them to 0 again it will be compliant, but it will break future > protocol use. RFC 3360 " Inappropriate TCP Resets Considered Harmful" already addresses this Abstract This document is being written because there are a number of firewalls in the Internet that inappropriately reset a TCP connection upon receiving certain TCP SYN packets, in particular, packets with flags set in the Reserved field of the TCP header. In this document we argue that this practice is not conformant with TCP standards, and is an inappropriate overloading of the semantics of the TCP reset. We also consider the longer-term consequences of this and similar actions as obstacles to the evolution of the Internet infrastructure. Shoaib. > | I strongly object to "silently discarded". It appears to me, that this > | draft goes against the spirit of "be liberal what you accept, be > | conservative in what you do" (you=tcp stack in this case). Making sure > | that these fields are *ignored* by implementations which can not > | interpret anything other than zero is what has to be stipulated - NOT > | silent discards! > > I can see the behavior to pass as useful (no strange packet drops, if > the protocol starts using those bits, you don't need to make a middlebox > understand them), but dangerous (if a middlebox passes them along was it > supposed to interpret them somehow and act on them instead?). > > | However, what I think is the right way to handle unknown values in field > | that (currently) have no meaning, is already specified in the protocol > | docs (but as a SHOULD, and MUST ignore; at least in RFC1323 timestamps > | it's written that way. Thus a improper implementation that leaks data by > | not properly initializing fields, is hurting itself more, than anyone > | else... > > You are just encouraging sloppy but convenient behavior. > > christos > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Mon Apr 4 11:02:28 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5C53A6867 for ; Mon, 4 Apr 2011 11:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ3sCB-iFTey for ; Mon, 4 Apr 2011 11:02:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 6B56D3A69BC for ; Mon, 4 Apr 2011 11:02:27 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p34I49uI015163 for ; Mon, 4 Apr 2011 11:04:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301940249; bh=Le+McqPQLyYTObzcp1N7wbcEpCI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=E6XLGQD38qT2kLfS7+uoy1+tmVGneGQmFLAjFyxvrjhD0X+vDuzZttcC0kxG0SNqR tKzJDsnTB8uWBoNIc1byg== Received: from vxb41 (vxb41.prod.google.com [10.241.33.105]) by hpaq12.eem.corp.google.com with ESMTP id p34I3vbq021003 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 4 Apr 2011 11:04:08 -0700 Received: by vxb41 with SMTP id 41so5308452vxb.32 for ; Mon, 04 Apr 2011 11:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IoFdumykzaAmPy3bF/eg1rDRi6Rej0F9i3PeP1FjCN0=; b=Yt9dc82OhMjzEPFqx515gA1XYiIOs3aCwfrCJApUfNB7KIZBKhDwiEMxGeOpgG2tFc lQEPpB+0hoMq9+KDB95A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=RjWXGJZ7FD4sFyufXNbXZu31KXZhLjWFvS7TV/LTh9f8XxF2TsrOJ4qTxIC+/nYGTE Q7JYcYi3jZ9J+HKzhwUA== Received: by 10.52.88.12 with SMTP id bc12mr5028250vdb.243.1301940247222; Mon, 04 Apr 2011 11:04:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.16.148 with HTTP; Mon, 4 Apr 2011 11:03:47 -0700 (PDT) In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> From: Yuchung Cheng Date: Mon, 4 Apr 2011 11:03:47 -0700 Message-ID: To: "SCHARF, Michael" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] Volunteers to review (parts of) draft-ietf-tcpm-tcp-security X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:02:28 -0000 On Fri, Apr 1, 2011 at 1:41 AM, SCHARF, Michael wrote: > All, > > as noted during the meeting, we do need volunteers that are willing to > review the technical recommendations in draft-ietf-tcpm-tcp-security-02. The > working group came up with a workflow to evaluate/categorize each > recommendation. This process is explained on Fernando's slides: > > http://www.ietf.org/proceedings/80/slides/tcpm-8.ppt > > Therein, you can also find some overview of the number of recommendations > and their distribution. > > During the meeting, some participants volunteered to help and review parts > of the document. I'd really appreciate if those of you could just post a > small note to the list. And it would really help if some more folks would > offer help, too. If you are particularly interested in certain sections > (only), just let us know. I am interested in reviewing section 5, 6, 7, 8, 9. Is there a deadline? From mallman@icir.org Mon Apr 4 12:00:12 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F6E3A67A8 for ; Mon, 4 Apr 2011 12:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.483 X-Spam-Level: X-Spam-Status: No, score=-106.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbPNwrMiq0eN for ; Mon, 4 Apr 2011 12:00:09 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id C90853A66B4 for ; Mon, 4 Apr 2011 12:00:08 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p34J1orW000662; Mon, 4 Apr 2011 12:01:50 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AD73C3800A7E; Mon, 4 Apr 2011 14:34:52 -0400 (EDT) To: Wesley Eddy From: Mark Allman In-Reply-To: <4D98C09C.9050205@mti-systems.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: And We Danced MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma3916-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 04 Apr 2011 14:34:52 -0400 Sender: mallman@icir.org Message-Id: <20110404183452.AD73C3800A7E@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 04 Apr 2011 19:00:12 -0000 ----------ma3916-1 Content-Type: text/plain Content-Disposition: inline > Prior to Prague, we'd seen only about 3 people (not including > Fernando) volunteer to help review, but we planned to ask during the > meeting, and were considering that we might have to drop it as a WG > item if we couldn't find at least 5. I saw about 6 hands in the > meeting, plus the 3 we already had. So, this looked to me like it > might have just enough energy to continue. I assume I am one of the 3. But, don't interpret that as support for the document. Its more like falling on my civic-duty sword. See my other two notes for details, but I wanted to make sure you were counting right. :) allman ----------ma3916-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2aD0wACgkQWyrrWs4yIs47dQCgiY4ZX0a/d5eYNb3pq18ktdW7 DpcAn3RZaujHGSMBD+5SpHb6ozQ8FPe2 =rtsI -----END PGP SIGNATURE----- ----------ma3916-1-- From mallman@icir.org Mon Apr 4 12:00:13 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98FA3A67AA for ; Mon, 4 Apr 2011 12:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ6rxiyAL2Yw for ; Mon, 4 Apr 2011 12:00:09 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id C90313A6452 for ; Mon, 4 Apr 2011 12:00:08 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p34J1ooW000660 for ; Mon, 4 Apr 2011 12:01:50 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9DE8738000AF for ; Mon, 4 Apr 2011 14:18:40 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Touch of Grey MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma2942-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 04 Apr 2011 14:18:40 -0400 Sender: mallman@icir.org Message-Id: <20110404181840.9DE8738000AF@lawyers.icir.org> Subject: [tcpm] security draft: section 9 review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 04 Apr 2011 19:00:13 -0000 ----------ma2942-1 Content-Type: text/plain Content-Disposition: inline I talked with Wes a while back and agreed to review the congestion control section of the security document (section 9). To try to calibrate myself I also read through the intro. In sum, I basically find this section to be 15 pages of re-hash that adds little if anything to the state of our understanding. Section 1: + The premise of this document seems strange to me. Basically, the reviewed documents don't consider security or people don't read them or whatever and so we have to invent a new 100+ page document that nobody will read to fix this situation. Huh. + The older of the TCP documents may not consider security as well as we'd like, but the newer documents do consider security and in some cases at least as well as this document. So, perhaps there are things to be done to older documents to shore them up, but I am not entirely sure there is any value in re-visiting the newer documents and parroting back what is said in those in some new document. + I wonder if there is a different route here which is along the lines of spelling out what a modern TCP looks like and then trying to go after issues that *are not* addressed by the documents themselves. E.g., who cares about blind dupack attacks in a world that to an exceedingly large degree uses SACK? It is not necessarily a service to anyone to discuss things that don't matter a ton---and in a way that isn't all that different from the current standards. As far as I can tell section 9 makes three recommendations over and above the RFCs: - Stricter check on out-of-window packets to prevent blind attackers from using this check to strobe out valid ACKs once they guess the four-tuple. I don't have a lot of heartburn with the proposed check except that there is an extra approximately 112 pages used to describe it than would be necessary. - Stronger language about the number of dupacks a TCP sender should expect from a correctly behaving TCP receiver. I.e., this document (on page 765) says a TCP SHOULD limit the number of dupacks it will honor and RFC 5681 says a TCP MAY limit the number (on page 10). Perhaps the mechanism ought to be a SHOULD and not a MAY. But, in a SACK-dominated world I have a hard time getting worked up over it one way or the other. And, changes of this level perhaps should get 20sec in the emacs buffer to change MAY to SHOULD in 5681, be WGLCed for two weeks and be put in the actual main document. (Not that I think it is important enough to do so ...) - Recommendation against the penalty box for flows not responding to ECN. In particular, the draft worries about forged segments causing a flow to appear non-responsive and then reset. Fine, fair enough. Penalty boxes come with pros and cons and that is a con. I don't think penalty boxes are part of the standard and therefore this appears as merely a comment and so I am not sure if it is BCP material. At best a BCP should probably flag the issue (rather than make a recommendation). But, it isn't a TCP issue, per se, and so one wonders if a document aimed at TCP implementations is really going to get it in the hands of the right audience. Or, if this is the right WG to worry about such things and make recommendations in that space. OK, now comments on section 9: o RFC 2581 has been obsolete for 18 months. Please change to RFC 5681 and note that RFC 5681 changed in ways that are germane to this document so this is not cosmetic. o I found the entire structure of the section to be a mess in both macroscopic and microscopic ways. The whole things at least needs coherently organized. (See below.) o 9.1.1 starts very abruptly with a "rule" without any context around it. This formulation is carried throughout and its just damn weird. It'd seem much more natural to tee up a problem and then give a mitigating rule. My reaction to this "rule" was something like "in slow start? congestion avoidance? what in the hell is he talking about?". o This document says nothing over and above what RFC 5681 says about ACK division. I.e., page 6 of RFC 5681 discusses exactly this for both slow start and congestion avoidance. o The upshot of 9.1.2 is a notion that TCPs SHOULD limit the number of acceptable dupacks. This extends (slightly) the MAY that is in RFC 5681 (page 10). Further, it would seem nice to note here that SACK-based loss recovery (and all empirical evidence I have seen points to SACK being massively used) does not share these issues with dupack-based attacks and to try to put these attacks in perspective given the proportion of SACK-savvy hosts. o The figure references in this document are ridiculous. You need to figure out how to explain things without figures in this document, or use diagrams or something. What you have is essentially normative references to some tech report that someone has to look at to understand the text of this document. Its an unreasonable construct. Its fine to explain something that I can understand in this document and *also* point to a discussion/figure elsewhere, but don't require me to go look at it there. o 9.1.3: The authors beliefs about middleboxes are nice. My daughter believes in the tooth fairy, too. Seemingly in a document that is targeted at BCP we should strive for something a bit more concrete and citable than belief. o 9.1.3: There is not enough discussion around this attack. In particular, there are two reasons why someone might want to do this attack. The first reason is for a receiver to try to coax a higher sending rate out of the sender for some transfer they care about. The trouble---and it should at least be discussed---is that the user is walking a tightrope here. They are coaxing out faster transmission, but as soon as a packet they have ACKed is lost its "game over" and they have to start a new connection. Depending on how things work they might have to start the whole transfer over again. Or, if their app protocol supports it perhaps they can restart things at the point of loss. But, either way it takes complexity and time to fix things. And, as the sending rate is coaxed faster the odds of taking a loss increase. So, the attack somewhat works against itself and that makes it less compelling. At least a document about security would want to understand the threat model, right? The second reason for optimistic ACKing is to hurt the network (i.e., Sherwood's work). I.e., the recipient does not care about the data and so losses are immaterial. Rather, the attacker wishes to coax the sender into blasting the network to congest the whole thing. Different threat model. o The intro to 9.2 is a confusing mess. I don't know what the hell it is trying to say and a bunch of stuff is then repeated later. o I basically fail to see how this blind attacks section is better than the one we already have in the form of Joe's RFC. o There is a whole section on the difficulty of blind attacks and it basically boils down to "we have seen some cases where it is easy to guess the four tuple" and once we have done that then it is "not hard" to wedge enough out of window packets to the receiver between legit packets to mount these attacks. Neither of these statements carries much evidence. The truth of the matter is attacking arbitrary TCP connections in a blind fashion is incredibly difficult. There are more predictable connections whereby one can get some of the four tuple and that makes things easier. But, even if I give you a bit of that and the sequence number its still hard and it still takes a lot of packets. And, even with your stronger "near in-window" check it is still possible. The bottom line is that the community has recognized this and invented actual mechanisms---not heuristics---to prevent blind attacks. And, yet there is *no* mention of these. I have no idea how I am supposed to take this document seriously. o 9.2.4: It took me a bit of thinking to try to understand what in the hell you were talking about with respect to NewReno. I finally think I figured it out, no thanks to the text. Basically, I think you are saying that if I can wedge three dupacks into a NewReno connection then the connection will enter loss recovery and every legit ACK will look like it is pointing to a lost packet and therefore trigger a needless retransmit. This bit needs completely re-written. o 9.2.4: Limited transmit... You're worried about two additional segments? That is a security problem? Really? Off-the-rails insane. o 9.2.5: SACK: Note 3517bis alters the definition of dupack to basically what is in this document. I am pretty sure its safe to go ahead and reference that in this document as 3517bisbis will likely be done before this document. o 9.2.5: You move from one "TCP SHOULD ..." to the next with no warning. Some sane sectioning or headings or something would really help a bunch here. o There is really nothing new in the ECN section. All these things---as this document notes---are discussed elsewhere. o I don't follow the introduction of compromised routers when talking about ECN. Why didn't you discuss those in terms of causing TCP slowdown attacks by dropping packets, say? Or, by knocking down rwnd, say? Or, by corrupting data, say? Why all the sudden are malicious routers germane? It makes no sense and just adds to the less-than-coherent rambling of this section. o There are any number of places in this section where things are just needlessly repeated. Probably it stems from the structure, but it could see a massive cleanup so that you say something only once. Things inexplicably not in the document: o There are two basic forms of attacks this document discusses. The first is an attack involving one of the endpoints gaming the congestion control. The other is a blind attacker. This latter could be helped by TCP-AO and it seems curious that this is not even mentioned. o There is actually a third class of attacks and that is a third-party attack (i.e. not a participant) that is not blind. I.e., someone sitting across a coffee shop. TCPM's fascination with blind attacks aside this seems to me like a much more likely avenue for attack than a blind attack. In this case, many of the attacks discussed in this document become quite possible and a whole lot easier. And, even the protections discussed offer little help. Again, TCP-AO would offer protection in these cases. Sorry for the long email about such a short part of the document. If the rest of the document is like this then I don't see anything compelling. There may be some nuggets here or there (e.g., a tighter check on out-of-window segments), but these new bits don't justify the 15 page section let alone a 100+ page document. There has to be a better way to more lucidly get those sorts of things into implementers' hands. allman ----------ma2942-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2aC4AACgkQWyrrWs4yIs4RcQCeK+P4Q1bu25wGImrR0MtrFJF0 L00An242h7Pgq1hsQlZArdmkJNhhFmXy =NUqk -----END PGP SIGNATURE----- ----------ma2942-1-- From mallman@icir.org Mon Apr 4 12:00:26 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF38128C151 for ; Mon, 4 Apr 2011 12:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.496 X-Spam-Level: X-Spam-Status: No, score=-106.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkRYsXWS6qhf for ; Mon, 4 Apr 2011 12:00:25 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 2B0DE28C161 for ; Mon, 4 Apr 2011 12:00:23 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p34J1orw000658; Mon, 4 Apr 2011 12:01:50 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 239933801453; Mon, 4 Apr 2011 14:58:27 -0400 (EDT) To: Wesley Eddy From: Mark Allman In-Reply-To: <4D98C09C.9050205@mti-systems.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: And We Danced MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma5330-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 04 Apr 2011 14:58:27 -0400 Sender: mallman@icir.org Message-Id: <20110404185827.239933801453@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 04 Apr 2011 19:00:27 -0000 ----------ma5330-1 Content-Type: text/plain Content-Disposition: inline > I think Richard's note in this thread actually identifies key > reasons why TCPM needs to do this document. Point taken. But, I want to disagree. The caveat is (per my other note) that I have only read the intro and section 9. And, I basically haven't tracked this document's history and did not weigh in on whether it should be a WG item. However, lack of literacy skills nor lack of timeliness have ever been an impediment to forming an opinion for me! :-) I think at a high level what this document creates is a big mess. Page 7 of this section document lists 18 RFCs that are "assessed". Most of those RFCs take security into account. That doesn't mean they are flawless. To the contrary they are all likely flawed in some fashion. But, having one massive off-to-the-side document try to fix this situation is asking for trouble and confusion. For instance, lets consider one example from this document. It says: TCP SHOULD limit the number of duplicate acknowledgements it will honour to: Max_DupACKs = (FlightSize / SMSS) - 1 Where FlightSize and SMSS are the values defined in RFC 2581 [Allman et al, 1999]. When more than Max_DupACKs duplicate acknowledgements are received, the exceeding DupACKs should be silently dropped. And, RFC 5681 [an update to RFC2581 that happened 18mos ago and which the security document ignores] says: 4. For each additional duplicate ACK received (after the third), cwnd MUST be incremented by SMSS. This artificially inflates the congestion window in order to reflect the additional segment that has left the network. Note: [SCWA99] discusses a receiver-based attack whereby many bogus duplicate ACKs are sent to the data sender in order to artificially inflate cwnd and cause a higher than appropriate sending rate to be used. A TCP MAY therefore limit the number of times cwnd is artificially inflated during loss recovery to the number of outstanding segments (or, an approximation thereof). So, in very basic terms these two things are talking about the same mechanism. RFC 5681 [a Draft Standard] says this bit is a MAY and the draft [lets presume it is a BCP] says it is a SHOULD. Which one is normative? We might go consult the rules and figure that out and That'd Be The Answer. But, to have two documents specifying the same mechanism and assigning MUST/SHOULD/MAY differently is creating a mess. It'd be further madness if the mechanism was not specified uniformly. The fact is we have considered security in our work in the past and where we have gotten it wrong we have processes to fix it. But, adding some parallel specification for 18 documents here is not a good idea. We really should let this expire and pick up any useful pieces and roll those in where they belong. TCP is a big enough mess across a big enough set of specifications. We don't need to aggravate the situation needlessly. IMHO. allman ----------ma5330-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2aFNIACgkQWyrrWs4yIs4PeQCgi+jZc/tohdefT8ydXc+4kHCq AiUAoJ+TKyx+TNYqYw0roJzVvSuC+EKN =0Y7G -----END PGP SIGNATURE----- ----------ma5330-1-- From hal.wigoda@gmail.com Mon Apr 4 12:54:45 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B63633A6768 for ; Mon, 4 Apr 2011 12:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krd1XaRyhRHZ for ; Mon, 4 Apr 2011 12:54:45 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id E1FAA3A67B0 for ; Mon, 4 Apr 2011 12:54:44 -0700 (PDT) Received: by gwb20 with SMTP id 20so2709892gwb.31 for ; Mon, 04 Apr 2011 12:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=vXSK33ElTzypFAzM9E1IBujqv0938DZn88ktichZG5s=; b=dWObxYZ5YLhCcTmXdQnk8G0ZXTLXvq3tAZXrKIvzviXepwHJ/+uO/Zv36AsQG2CZFv leH33CuYWwVlCEIGvBdaB7pU3eThFHhK3y5b2nBPeolJfXjwfD3+fAN2hM7Z1DLTvke/ F9+nETBz/4TUjMf+R6U/pD516och4pUNzLc10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=PU44KK4pWSRofBKnO0wai2K16Md5C2xjzxjrgWWVb0184yxDmtYSo36cdfHmSAx3F2 WCNq65pHCDK3yvkhVlSKsbm+GXPzeh21oJCQifn9aBHKYj425Zy0NVBcHtzsWvz3AKI1 NRXDgdT6NjA+RxqNJLeUVAS7MZwOASsmcAz48= Received: by 10.101.218.3 with SMTP id v3mr5517241anq.41.1301946987307; Mon, 04 Apr 2011 12:56:27 -0700 (PDT) Received: from [10.13.68.85] ([166.205.15.111]) by mx.google.com with ESMTPS id e24sm5702423ana.2.2011.04.04.12.56.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 12:56:25 -0700 (PDT) References: <133D9897FB9C5E4E9DF2779DC91E947C026F62E8@SLFSNX.rcs.alcatel-research.de> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Hal Wigoda Date: Mon, 4 Apr 2011 15:56:13 -0400 To: Yuchung Cheng Cc: "tcpm@ietf.org" , "SCHARF, Michael" Subject: Re: [tcpm] Volunteers to review (parts of) draft-ietf-tcpm-tcp-security X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:54:45 -0000 I'd be willing to review it.=20 ------- On Apr 4, 2011, at 2:03 PM, Yuchung Cheng wrote: > On Fri, Apr 1, 2011 at 1:41 AM, SCHARF, Michael > wrote: >> All, >>=20 >> as noted during the meeting, we do need volunteers that are willing to >> review the technical recommendations in draft-ietf-tcpm-tcp-security-02. T= he >> working group came up with a workflow to evaluate/categorize each >> recommendation. This process is explained on Fernando's slides: >>=20 >> http://www.ietf.org/proceedings/80/slides/tcpm-8.ppt >>=20 >> Therein, you can also find some overview of the number of recommendations= >> and their distribution. >>=20 >> During the meeting, some participants volunteered to help and review part= s >> of the document. I'd really appreciate if those of you could just post a >> small note to the list. And it would really help if some more folks would= >> offer help, too. If you are particularly interested in certain sections >> (only), just let us know. >=20 > I am interested in reviewing section 5, 6, 7, 8, 9. Is there a deadline? > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From alexander.zimmermann@comsys.rwth-aachen.de Mon Apr 4 13:26:00 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462A73A67CF for ; Mon, 4 Apr 2011 13:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjMlfBhjNlGv for ; Mon, 4 Apr 2011 13:25:59 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 1AFBA3A67BD for ; Mon, 4 Apr 2011 13:25:59 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LJ500FU6A64UA20@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 04 Apr 2011 22:27:40 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.63,299,1299452400"; d="scan'208";a="104399961" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 04 Apr 2011 22:27:41 +0200 Received: from [192.168.4.12] ([unknown] [77.109.115.146]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LJ500H6PA64FI30@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 04 Apr 2011 22:27:40 +0200 (CEST) From: Alexander Zimmermann In-reply-to: <20110404185827.239933801453@lawyers.icir.org> Date: Mon, 04 Apr 2011 22:27:38 +0200 Message-id: References: <20110404185827.239933801453@lawyers.icir.org> To: mallman@icir.org X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: tcpm@ietf.org Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:26:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 04.04.2011 um 20:58 schrieb Mark Allman: > The fact is we have considered security in our work in the past and > where we have gotten it wrong we have processes to fix it. But, adding > some parallel specification for 18 documents here is not a good idea. > We really should let this expire and pick up any useful pieces and roll > those in where they belong. TCP is a big enough mess across a big > enough set of specifications. We don't need to aggravate the situation > needlessly. +1 > > IMHO. > > allman > // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2aKbsACgkQdyiq39b9uS4JPACfW/CfDvtXmwCq8Vopjb5mLZ0V A6EAnAyRE4LAb/1xKZerR8rpVUTaLsZp =HYrU -----END PGP SIGNATURE----- From ananth@cisco.com Mon Apr 4 17:35:55 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDED13A6823 for ; Mon, 4 Apr 2011 17:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.185 X-Spam-Level: X-Spam-Status: No, score=-11.185 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nduGUEOLuF9 for ; Mon, 4 Apr 2011 17:35:54 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 946A53A6816 for ; Mon, 4 Apr 2011 17:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=4485; q=dns/txt; s=iport; t=1301963857; x=1303173457; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=EVueTBdRTm5+cJBFdvsmO3d5VMMUZKE//kCB8F1ib30=; b=Ls3XY7m9xc/W4hLIVOAIYhBqLpE7dNctD/Y1UqisxpRy2ioxcUcEpy03 zIwPQDAw692WU3g1ZqHlJ6OjhwxJ2LHc2XOQ7/v+k0djvAjK4z2P7mBmn oU8QYCv/TZE13kJo1f1ojvQNmYLnN2tBkvA2QsKSaz5CTUB1jLfv1wdcT w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAAJRjmk2rRDoG/2dsb2JhbACYII1Hd6cQnB+DEIJbBIVHiz0 X-IronPort-AV: E=Sophos;i="4.63,300,1299456000"; d="scan'208";a="289263324" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 05 Apr 2011 00:37:37 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p350bb1x028845; Tue, 5 Apr 2011 00:37:37 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 17:37:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Apr 2011 17:37:33 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580C56DB50@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20110404185827.239933801453@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) Thread-Index: Acvy+wTf2GlV8RtxTq+D6lfhg0SYUwALL5Vg References: <4D98C09C.9050205@mti-systems.com> <20110404185827.239933801453@lawyers.icir.org> From: "Anantha Ramaiah (ananth)" To: , "Wesley Eddy" X-OriginalArrivalTime: 05 Apr 2011 00:37:37.0179 (UTC) FILETIME=[A96B6EB0:01CBF329] Cc: tcpm@ietf.org Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 00:35:55 -0000 Interesting thought. Let me try to offer my few bits here.=20 - Do we want to make TCP robust, by that I mean fix flaws in TCP specs w.r.t security, address vulnerabilities etc., The answer seems to be yes. We have embarked on few TCP specs relating to this effort, TCP-AO etc., have become RFC's. We did agree to make TCP-security document as a WG item. (right or wrong, doesn't matter for the current argument sake). So, I would think one way to tackle this problem is to form a design team or a separate sub WG, say TCPSec or whatever that can use the tcp-security document as a starting point and formulate changes to individual RFC's ("roll them to where they belong" like you say below) in the form of errata's or documents. Just my thought and it maybe stupid, but I see that as one way to move forward, may not be the most optimal way. $0.02, -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Mark Allman > Sent: Monday, April 04, 2011 11:58 AM > To: Wesley Eddy > Cc: tcpm@ietf.org > Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: > Volunteers to review (parts of) draft-ietf-tcpm-tcp-security) >=20 >=20 > > I think Richard's note in this thread actually identifies key reasons > > why TCPM needs to do this document. >=20 > Point taken. But, I want to disagree. The caveat is (per my other > note) that I have only read the intro and section 9. And, I basically > haven't tracked this document's history and did not weigh in on whether > it should be a WG item. >=20 > However, lack of literacy skills nor lack of timeliness have ever been > an impediment to forming an opinion for me! :-) >=20 > I think at a high level what this document creates is a big mess. Page > 7 of this section document lists 18 RFCs that are "assessed". Most of > those RFCs take security into account. That doesn't mean they are > flawless. To the contrary they are all likely flawed in some fashion. > But, having one massive off-to-the-side document try to fix this > situation is asking for trouble and confusion. >=20 > For instance, lets consider one example from this document. It says: >=20 > TCP SHOULD limit the number of duplicate acknowledgements it will > honour to: >=20 > Max_DupACKs =3D (FlightSize / SMSS) - 1 >=20 > Where FlightSize and SMSS are the values defined in RFC 2581 [Allman > et al, 1999]. When more than Max_DupACKs duplicate acknowledgements > are received, the exceeding DupACKs should be silently dropped. >=20 > And, RFC 5681 [an update to RFC2581 that happened 18mos ago and which > the security document ignores] says: >=20 > 4. For each additional duplicate ACK received (after the third), > cwnd MUST be incremented by SMSS. This artificially inflates > the > congestion window in order to reflect the additional segment > that > has left the network. >=20 > Note: [SCWA99] discusses a receiver-based attack whereby many > bogus duplicate ACKs are sent to the data sender in order to > artificially inflate cwnd and cause a higher than appropriate > sending rate to be used. A TCP MAY therefore limit the number > of > times cwnd is artificially inflated during loss recovery to the > number of outstanding segments (or, an approximation thereof). >=20 > So, in very basic terms these two things are talking about the same > mechanism. RFC 5681 [a Draft Standard] says this bit is a MAY and the > draft [lets presume it is a BCP] says it is a SHOULD. Which one is > normative? We might go consult the rules and figure that out and > That'd Be The Answer. But, to have two documents specifying the same > mechanism and assigning MUST/SHOULD/MAY differently is creating a mess. > It'd be further madness if the mechanism was not specified uniformly. >=20 > The fact is we have considered security in our work in the past and > where we have gotten it wrong we have processes to fix it. But, adding > some parallel specification for 18 documents here is not a good idea. > We really should let this expire and pick up any useful pieces and roll > those in where they belong. TCP is a big enough mess across a big > enough set of specifications. We don't need to aggravate the situation > needlessly. >=20 > IMHO. >=20 > allman >=20 >=20 From Michael.Scharf@alcatel-lucent.com Tue Apr 5 00:56:07 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1453A68E5 for ; Tue, 5 Apr 2011 00:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwfnQN2iWmUm for ; Tue, 5 Apr 2011 00:56:06 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 924B53A67EF for ; Tue, 5 Apr 2011 00:56:06 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p357vmi4010443 for ; Tue, 5 Apr 2011 09:57:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Apr 2011 09:57:47 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0522F8DD@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Discussion on recommendations in draft-ietf-tcpm-tcp-security Thread-index: AcvzZycyxM9xiAgLSjKXZOeL8smv7Q== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] Discussion on recommendations in draft-ietf-tcpm-tcp-security X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 07:56:07 -0000 Folks, here are some thoughts on how to achieve progress concerning the security draft: - Fernando and the chairs have asked for reviews of the recommendations in draft-ietf-tcpm-tcp-security. We have to understand which of them are technically correct, which of them should be better documented, and which need to be fixed in the TCP spec. This is the purpose of the workflow that has been developed by the group. - The structure and scope of draft-ietf-tcpm-tcp-security is a separate question. This is a working group document that can be changed (or even abandoned) by the group. Based on the feedback, it seems to be clear that we have to discuss in one of the next meetings how to publish this, i. e., whether the groups wants a 100 pages document, etc. But it also seems to be reasonably to first have a look at the actual recommendations. Thus, let's start with this work, and get it done. Also, the chairs understand that reviewing the recommendations doesn't mean that you consent to the current draft. - Let's be pragmatic. There is other important work in TCPM that will require time and effort, too, and we should not get stuck forever with this topic. I will try my best to technically facilitate the discussion of the recommendations (stay tuned). For the moment, please have a look at the technical recommendations. Thanks Michael From muraris@microsoft.com Tue Apr 5 10:22:31 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CAE28C127 for ; Tue, 5 Apr 2011 10:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.419 X-Spam-Level: X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brmRvQrzuZg5 for ; Tue, 5 Apr 2011 10:22:26 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id AE3FA28C12B for ; Tue, 5 Apr 2011 10:22:25 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Apr 2011 10:23:59 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.31]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0270.002; Tue, 5 Apr 2011 10:23:59 -0700 From: Murari Sridharan To: "SCHARF, Michael" , "tcpm@ietf.org" Thread-Topic: [tcpm] Discussion on recommendations in draft-ietf-tcpm-tcp-security Thread-Index: AcvzZycyxM9xiAgLSjKXZOeL8smv7QATp6fA Date: Tue, 5 Apr 2011 17:23:58 +0000 Message-ID: References: <133D9897FB9C5E4E9DF2779DC91E947C0522F8DD@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0522F8DD@SLFSNX.rcs.alcatel-research.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] Discussion on recommendations in draft-ietf-tcpm-tcp-security X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 17:22:31 -0000 Michael, I agree with this approach. There are a lot of useful recommendati= ons in this draft and similar approaches have been adopted in Windows and w= e'd like to review portions and provide feedback. I'll get somebody in my t= eam to post feedback on specific issues to the mailing lists.=20 Thanks Murari=20 -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of SCH= ARF, Michael Sent: Tuesday, April 05, 2011 12:58 AM To: tcpm@ietf.org Subject: [tcpm] Discussion on recommendations in draft-ietf-tcpm-tcp-securi= ty Folks, here are some thoughts on how to achieve progress concerning the security d= raft: - Fernando and the chairs have asked for reviews of the recommendations in = draft-ietf-tcpm-tcp-security. We have to understand which of them are techn= ically correct, which of them should be better documented, and which need t= o be fixed in the TCP spec. This is the purpose of the workflow that has be= en developed by the group. - The structure and scope of draft-ietf-tcpm-tcp-security is a separate que= stion. This is a working group document that can be changed (or even abandoned) by the group. Based on the feedback, it seems to be clear that w= e have to discuss in one of the next meetings how to publish this, i. e., w= hether the groups wants a 100 pages document, etc. But it also seems to be = reasonably to first have a look at the actual recommendations. Thus, let's = start with this work, and get it done. Also, the chairs understand that reviewing the recommendations doesn't mean= that you consent to the current draft. - Let's be pragmatic. There is other important work in TCPM that will requi= re time and effort, too, and we should not get stuck forever with this topi= c. I will try my best to technically facilitate the discussion of the recommen= dations (stay tuned). For the moment, please have a look at the technical r= ecommendations. Thanks Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From wwwrun@rfc-editor.org Tue Apr 5 17:32:10 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A6F28C122; Tue, 5 Apr 2011 17:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPvABKnBD5Ia; Tue, 5 Apr 2011 17:32:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 346B228C121; Tue, 5 Apr 2011 17:32:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id ADFBFE076D; Tue, 5 Apr 2011 17:33:30 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110406003330.ADFBFE076D@rfc-editor.org> Date: Tue, 5 Apr 2011 17:33:30 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] BCP 159, RFC 6191 on Reducing the TIME-WAIT State Using TCP Timestamps X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 00:32:10 -0000 A new Request for Comments is now available in online RFC libraries. BCP 159 RFC 6191 Title: Reducing the TIME-WAIT State Using TCP Timestamps Author: F. Gont Status: Best Current Practice Stream: IETF Date: April 2011 Mailbox: fernando@gont.com.ar Pages: 10 Characters: 22953 See Also: BCP0159 I-D Tag: draft-ietf-tcpm-tcp-timestamps-04.txt URL: http://www.rfc-editor.org/rfc/rfc6191.txt This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. This memo documents an Internet Best Current Practice. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From mallman@icir.org Wed Apr 6 05:10:16 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9731728C139 for ; Wed, 6 Apr 2011 05:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.502 X-Spam-Level: X-Spam-Status: No, score=-106.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+iMCG8u49UR for ; Wed, 6 Apr 2011 05:10:15 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id BA16928C12B for ; Wed, 6 Apr 2011 05:10:15 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p36CBxCP007297 for ; Wed, 6 Apr 2011 05:11:59 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8EA093840CD5 for ; Wed, 6 Apr 2011 08:11:57 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Born to be Wild MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma22669-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Apr 2011 08:11:57 -0400 Sender: mallman@icir.org Message-Id: <20110406121157.8EA093840CD5@lawyers.icir.org> Subject: [tcpm] security draft: section 14 review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 06 Apr 2011 12:10:16 -0000 ----------ma22669-1 Content-Type: text/plain Content-Disposition: inline I agreed to try to review section 14 of the security draft, which I was able to do between meetings yesterday. Comments: o The point of this section is not clear to me. Port scans do not impact TCP's security. They may impact the host's security, but such a broadening of scope seems strange to me. E.g., TCP can be used to carry all manner of malcode, but do we want to tackle that problem in this document? I hope not. I don't see much in this section that is all that useful TCP-wise. o The document should at least show perspective about scanning. That is, in the limit if an adversary has enough time and enough machines they can figure out your open/closed ports no matter what you do. Of course, there are things one can do to make this take longer or require a larger set of scanners. But, at least we should start from the reality that at the end of the day this activity cannot be prevented. o I *think* this section is sketching techniques that can be used to force adversaries to expend more resources in finding a host's open/closed ports. But, if this is the goal then it ought to be explicitly stated. o BTW, port scanning is not a big chunk of the scanning we see [we've recently been working on an extension of an IMC 2007 paper on the subject]. To the contrary we mostly see network scans of a given port. Our conjecture is that attackers have some attack vector (IIS exploit, say) and so there is no reason to see if (say) the ssh port is open on some machine. Rather, it is more important to find which machines might be running a web server. So, a scan across hosts instead of a scan across ports makes a lot more sense. Obviously, this is not the entirety of scans and some indeed do port scan some set of ports (one presumes this is a multi-vector attack)---these are just not as common according to our data. o All these scan types are just clever exploitation of some small feature / bug in the spec or the way stacks are coded. You probably didn't identify all such behavior. Rather than introduce a bunch of new and quite specific rules ("don't RST if there is no ACK bit set") how about just introducing a blanket rule that says "its OK to not respond to crap"? I.e., if you have no connection state (whether that be active or in TIME-WAIT or whatever) then just don't respond to anything that isn't a SYN. Lots of firewalls (network and host) implement that general policy now. I understand the peer might have some out-of-date connection state or something and a RST might help it better understand a connection is gone, but thats an optimization. And blocking these can certainly be viewed as a policy decision. But, even with this rule you still can be found out. It makes it more difficult as the attackers have to issue normal looking communication, but it doesn't solve the problem. o This section represents another instance of the "parallel specs" problem I sketched the other day. There are new proposed rules in here that update 793. What is one to do when looking at a full standard vs. a 100-page BCP? This is creating a mess. In sum, this doesn't look like "TCP security" to me and so I'd just assume leave it out. allman ----------ma22669-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2cWI0ACgkQWyrrWs4yIs7cwwCcDTxcrnYS1xMtTqUE8E5sNqu3 5+wAn2UIZWMIFqx8pFqkLHxc8bPG21zd =ditK -----END PGP SIGNATURE----- ----------ma22669-1-- From iesg-secretary@ietf.org Wed Apr 6 11:47:12 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3DA528C116; Wed, 6 Apr 2011 11:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tcYwiHe24AV; Wed, 6 Apr 2011 11:47:11 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBBEA3A68B9; Wed, 6 Apr 2011 11:47:11 -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: 3.15 Message-ID: <20110406184711.17711.63929.idtracker@localhost> Date: Wed, 06 Apr 2011 11:47:11 -0700 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (Computing TCP's Retransmission Timer) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 18:47:12 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Computing TCP's Retransmission Timer' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-paxson-tcpm-rfc2988bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-paxson-tcpm-rfc2988bis/ No IPR declarations have been submitted directly on this I-D. From fernando.gont.netbook.win@gmail.com Wed Apr 6 12:28:22 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A953A697A for ; Wed, 6 Apr 2011 12:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSp4CshuiGVK for ; Wed, 6 Apr 2011 12:28:10 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id AD0133A6978 for ; Wed, 6 Apr 2011 12:28:07 -0700 (PDT) Received: by yic13 with SMTP id 13so840046yic.31 for ; Wed, 06 Apr 2011 12:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=JiEz+GyvvV5FQuAKfCYdA7u5qI7DBxj3SeaQq8hjCbg=; b=HfhrBvSRfqqfmPsIHJxoAPU1oLbYJpVUQna/lI/mtDTlIuTXa0yRG/EFRLcNBK6EUq Bb/dwQFvjd6C3ZnWDtDLvRxTprVyofUFscpMy7KogKqePINk9RxZ6qFRorGGPnEuFg7K dn/V3sQwTym+7jwF/LjXxNj0N4hN8zMbqr/FY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=s8noMIqa9QdpfTUwfvhtzlz/17CkHir4A1lZYP8PVDcqK/Re/QSERd0UTtZ2R8S8Ee 4TDXi/G9aARolyMVk0Lygnmwnlma0fFHwrlSK0t4Re5EYn8BQAil7+ENavNWR4RA/LRj GkDTjS6ioeyUkzvg7BR55pPNoUf/LQ1eF06w4= Received: by 10.150.193.10 with SMTP id q10mr2155437ybf.413.1302118184519; Wed, 06 Apr 2011 12:29:44 -0700 (PDT) Received: from [192.168.123.101] ([190.48.201.131]) by mx.google.com with ESMTPS id q29sm517732yba.17.2011.04.06.12.29.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 12:29:43 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9CBF21.30106@gont.com.ar> Date: Wed, 06 Apr 2011 16:29:37 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: mallman@icir.org References: <20110406121157.8EA093840CD5@lawyers.icir.org> In-Reply-To: <20110406121157.8EA093840CD5@lawyers.icir.org> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] security draft: section 14 review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 19:28:22 -0000 Hi, Mark, Thanks so much for taking the time to review Section 14. Please find my comments inline.... On 06/04/2011 09:11 a.m., Mark Allman wrote: > > I agreed to try to review section 14 of the security draft, which I was > able to do between meetings yesterday. Comments: > > o The point of this section is not clear to me. Port scans do not > impact TCP's security. They may impact the host's security, but > such a broadening of scope seems strange to me. E.g., TCP can be > used to carry all manner of malcode, but do we want to tackle that > problem in this document? I hope not. I don't see much in this > section that is all that useful TCP-wise. This section is meant to cover all variants of TCP-based portscans, some of which are based on features/bugs of existing stacks. Some variants can be mitigated if some changes to the code are applied. (Note: I'm simply providing a rationale for the Section) > o The document should at least show perspective about scanning. That > is, in the limit if an adversary has enough time and enough machines > they can figure out your open/closed ports no matter what you do. > Of course, there are things one can do to make this take longer or > require a larger set of scanners. But, at least we should start > from the reality that at the end of the day this activity cannot be > prevented. Agreed. One point to note is that some scan methods are more stelathy than others. e.g., simply connect()-scan versus an ACK scan. > o I *think* this section is sketching techniques that can be used to > force adversaries to expend more resources in finding a host's > open/closed ports. But, if this is the goal then it ought to be > explicitly stated. Actually, it aims at covering the existing TCP-based techniques, and to provide mitigations for the more stealthy ones. > o BTW, port scanning is not a big chunk of the scanning we see [we've > recently been working on an extension of an IMC 2007 paper on the > subject]. To the contrary we mostly see network scans of a given > port. Our conjecture is that attackers have some attack vector (IIS > exploit, say) and so there is no reason to see if (say) the ssh port > is open on some machine. Rather, it is more important to find which > machines might be running a web server. I think this depends on what the attacker is trying to achieve. If he's just after more nodes for his botnet, yes: he just has an exploit, and only cares about a specific port. If it's a targetted attack, then he'll probably sweep the entire port range of the target host(s). That said, the port-scanning techniques described in this section applies to both cases. i.e., if there are stealthy port-scanning techniques, an attacker would possibly would those over the trivial connect()-based scan. > o All these scan types are just clever exploitation of some small > feature / bug in the spec or the way stacks are coded. You probably > didn't identify all such behavior. You might be right. FWIW, these are the "known" ones. > Rather than introduce a bunch of > new and quite specific rules ("don't RST if there is no ACK bit > set") how about just introducing a blanket rule that says "its OK to > not respond to crap"? I.e., if you have no connection state > (whether that be active or in TIME-WAIT or whatever) then just don't > respond to anything that isn't a SYN. Lots of firewalls (network > and host) implement that general policy now. How would you suggest to codify such rule? -- Because it's something along the lines of "don't respond to crap", then there's the question of "what do you mean by crap?" But yes, if all those stealthy portscan techniques can be mitigated with a simply rule such as the one you mentioned, that sounds like a valid way forward. > I understand the peer might have some out-of-date connection state > or something and a RST might help it better understand a connection > is gone, but thats an optimization. And blocking these can > certainly be viewed as a policy decision. > > But, even with this rule you still can be found out. It makes it > more difficult as the attackers have to issue normal looking > communication, but it doesn't solve the problem. Agreed. But it becomes easier to track. > o This section represents another instance of the "parallel specs" > problem I sketched the other day. I don't think I've received your note (was it posted to tcpm? If not, please send it off-list to me). > There are new proposed rules in > here that update 793. What is one to do when looking at a full > standard vs. a 100-page BCP? This is creating a mess. Wouldn't RFC793 be formally updated in this respect? Or maybe a short I-D issued in response to these std issues? > In sum, this doesn't look like "TCP security" to me and so I'd just > assume leave it out. So you argue that these issues should not be addressed in this document? (e.g., mitigations for stealh port-scan methods). And if not here, where? Thanks again! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From mallman@icir.org Wed Apr 6 12:45:18 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B663A67DA for ; Wed, 6 Apr 2011 12:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2eMCMWbxons for ; Wed, 6 Apr 2011 12:45:13 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id C8B5E28C0ED for ; Wed, 6 Apr 2011 12:45:12 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p36Jkpf3001812; Wed, 6 Apr 2011 12:46:52 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D4A91386850C; Wed, 6 Apr 2011 15:46:51 -0400 (EDT) To: Fernando Gont From: Mark Allman In-Reply-To: <4D9CBF21.30106@gont.com.ar> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Just What I Needed MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma49961-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Apr 2011 15:46:51 -0400 Sender: mallman@icir.org Message-Id: <20110406194651.D4A91386850C@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] security draft: section 14 review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 06 Apr 2011 19:45:19 -0000 ----------ma49961-1 Content-Type: text/plain Content-Disposition: inline > > I agreed to try to review section 14 of the security draft, which I was > > able to do between meetings yesterday. Comments: > > > > o The point of this section is not clear to me. Port scans do not > > impact TCP's security. They may impact the host's security, but > > such a broadening of scope seems strange to me. E.g., TCP can be > > used to carry all manner of malcode, but do we want to tackle that > > problem in this document? I hope not. I don't see much in this > > section that is all that useful TCP-wise. > > This section is meant to cover all variants of TCP-based portscans, some > of which are based on features/bugs of existing stacks. Some variants > can be mitigated if some changes to the code are applied. > > (Note: I'm simply providing a rationale for the Section) I still don't get it. This has nothing to do with TCP security. I am not responding to a bunch of your comments directly because I think you said what I said and so I'm going to assume we agree. > > o BTW, port scanning is not a big chunk of the scanning we see [we've > > recently been working on an extension of an IMC 2007 paper on the > > subject]. To the contrary we mostly see network scans of a given > > port. Our conjecture is that attackers have some attack vector (IIS > > exploit, say) and so there is no reason to see if (say) the ssh port > > is open on some machine. Rather, it is more important to find which > > machines might be running a web server. > > I think this depends on what the attacker is trying to achieve. If > he's just after more nodes for his botnet, yes: he just has an > exploit, and only cares about a specific port. If it's a targetted > attack, then he'll probably sweep the entire port range of the target > host(s). I was sketching what we *see*. > > Rather than introduce a bunch of > > new and quite specific rules ("don't RST if there is no ACK bit > > set") how about just introducing a blanket rule that says "its OK to > > not respond to crap"? I.e., if you have no connection state > > (whether that be active or in TIME-WAIT or whatever) then just don't > > respond to anything that isn't a SYN. Lots of firewalls (network > > and host) implement that general policy now. > > How would you suggest to codify such rule? -- Because it's something > along the lines of "don't respond to crap", then there's the question of > "what do you mean by crap?" Well, I think I defined it like this: I.e., if you have no connection state (whether that be active or in TIME-WAIT or whatever) then just don't respond to anything that isn't a SYN. > > o This section represents another instance of the "parallel specs" > > problem I sketched the other day. > > I don't think I've received your note (was it posted to tcpm? If not, > please send it off-list to me). (Yes- I sent several to TCPM the other day.) > > In sum, this doesn't look like "TCP security" to me and so I'd just > > assume leave it out. > > So you argue that these issues should not be addressed in this document? To be clear, I argued the other day that this document should not exist on the grounds that it creates a gigantic mess. But, that aside these issues are not issues that impact TCP security. There are many "security issues" that *involve* TCP, but that doesn't mean we need to change TCP to mitigate them. allman ----------ma49961-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2cwysACgkQWyrrWs4yIs4+uQCcC97L+51/JQx3cQoRDS8Z6Xrq 6f0AnR/kDeqcEL/58AzVNS6zxeo1q3wv =KVe/ -----END PGP SIGNATURE----- ----------ma49961-1-- From fernando.gont.netbook.win@gmail.com Wed Apr 6 13:23:15 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8313A6995 for ; Wed, 6 Apr 2011 13:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFh9odj6bwkY for ; Wed, 6 Apr 2011 13:23:14 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 2B0193A69C3 for ; Wed, 6 Apr 2011 13:23:14 -0700 (PDT) Received: by gxk19 with SMTP id 19so857842gxk.31 for ; Wed, 06 Apr 2011 13:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=jUYH/4/uRVrbftvEZDq9oglNUuic6xl1PHsX8yRdV5E=; b=Q4C2QRNMWvf8jsI13ri5y9bPELx7AsJrQNLyZjic5C1HbmE0G0GRdl7ZHFmwwRb5E3 wJn/XxtV7B9z6X8myiJXaIsvgEyqOn1fbJAaZiXJiTtAaP5KG3+lsicA/vLZj3PAFYRu NFYmhVugI0mTHNcMRXffeg/P8kaGHo6Bf/l3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=xkI/Kqk4gUe3TUdjeOGNvu2rCHqVzFqtPwfU+eBi9L+dIiU+UABd27J4AIEC2pgPpW 830aILL5REni0ejfRgRa5GDMFALDlqiWdpn90xr4BbRIq8el2kwkP0uRafzeno/JFp6e 8V7Xqe2R2UH1aqdpIAYwxBYf0y3xltUiUFjiY= Received: by 10.151.2.2 with SMTP id e2mr68290ybi.27.1302121497861; Wed, 06 Apr 2011 13:24:57 -0700 (PDT) Received: from [192.168.123.101] ([190.48.201.131]) by mx.google.com with ESMTPS id m12sm856366ybn.27.2011.04.06.13.24.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 13:24:56 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9CCC11.7030309@gont.com.ar> Date: Wed, 06 Apr 2011 17:24:49 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: mallman@icir.org References: <20110406194651.D4A91386850C@lawyers.icir.org> In-Reply-To: <20110406194651.D4A91386850C@lawyers.icir.org> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] security draft: section 14 review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 20:23:15 -0000 On 06/04/2011 04:46 p.m., Mark Allman wrote: >>> o The point of this section is not clear to me. Port scans do not >>> impact TCP's security. They may impact the host's security, but >>> such a broadening of scope seems strange to me. E.g., TCP can be >>> used to carry all manner of malcode, but do we want to tackle that >>> problem in this document? I hope not. I don't see much in this >>> section that is all that useful TCP-wise. >> >> This section is meant to cover all variants of TCP-based portscans, some >> of which are based on features/bugs of existing stacks. Some variants >> can be mitigated if some changes to the code are applied. >> >> (Note: I'm simply providing a rationale for the Section) > > I still don't get it. This has nothing to do with TCP security. The stealth port-scanning techniques are based on TCP features/bugs. If one ones to mitigate them, they need to be mitigated in the TCP code. That's why they are discussed in this document. >>> o BTW, port scanning is not a big chunk of the scanning we see [we've >>> recently been working on an extension of an IMC 2007 paper on the >>> subject]. To the contrary we mostly see network scans of a given >>> port. Our conjecture is that attackers have some attack vector (IIS >>> exploit, say) and so there is no reason to see if (say) the ssh port >>> is open on some machine. Rather, it is more important to find which >>> machines might be running a web server. >> >> I think this depends on what the attacker is trying to achieve. If >> he's just after more nodes for his botnet, yes: he just has an >> exploit, and only cares about a specific port. If it's a targetted >> attack, then he'll probably sweep the entire port range of the target >> host(s). > > I was sketching what we *see*. Agreed. Just curious: where has the dataset been obtained? (I ask because I'd expect your data to represent the general case. OTOH, one would expect NSA's networks and the like to have their whole port ranges swept completely) >> How would you suggest to codify such rule? -- Because it's something >> along the lines of "don't respond to crap", then there's the question of >> "what do you mean by crap?" > > Well, I think I defined it like this: > > I.e., if you have no connection state (whether that be active or in > TIME-WAIT or whatever) then just don't respond to anything that > isn't a SYN. That sounds very reasonable. Should I e.g. simply make some general comments on availalable stealth port-scanning techniques, provide references, and just include this rule? (in replacement of the current Section 14) >>> o This section represents another instance of the "parallel specs" >>> problem I sketched the other day. >> >> I don't think I've received your note (was it posted to tcpm? If not, >> please send it off-list to me). > > (Yes- I sent several to TCPM the other day.) I have found them now (three posts on April 4th). >>> In sum, this doesn't look like "TCP security" to me and so I'd just >>> assume leave it out. >> >> So you argue that these issues should not be addressed in this document? > > To be clear, I argued the other day that this document should not exist > on the grounds that it creates a gigantic mess. But, that aside these > issues are not issues that impact TCP security. There are many > "security issues" that *involve* TCP, but that doesn't mean we need to > change TCP to mitigate them. My *personal* take is that, if they are TCP-specific (as the stealth port-scanning techniques), and can be easily fixed, we should do it. IMO, these stealth portscan techniques should not exist. I'll let others weigh in. Just to make sure I got your point clear: Aside from your comments about the document in general, you argue that this section should be removed, and that this document should not try to mitigate the stealth portscanning vectors? Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From mallman@icir.org Wed Apr 6 13:43:44 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E06D128C0FA for ; Wed, 6 Apr 2011 13:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiCakI-RdIPb for ; Wed, 6 Apr 2011 13:43:43 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 098803A69DE for ; Wed, 6 Apr 2011 13:43:39 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p36KjKVE008149; Wed, 6 Apr 2011 13:45:20 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9DA6D38696E2; Wed, 6 Apr 2011 16:45:19 -0400 (EDT) To: Fernando Gont From: Mark Allman In-Reply-To: <4D9CCC11.7030309@gont.com.ar> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Just What I Needed MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma53471-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Apr 2011 16:45:19 -0400 Sender: mallman@icir.org Message-Id: <20110406204519.9DA6D38696E2@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] security draft: section 14 review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 06 Apr 2011 20:43:45 -0000 ----------ma53471-1 Content-Type: text/plain Content-Disposition: inline > The stealth port-scanning techniques are based on TCP features/bugs. If > one ones to mitigate them, they need to be mitigated in the TCP code. (Or in a firewall like everyone does.) > Agreed. Just curious: where has the dataset been obtained? LBL. See ... Mark Allman, Vern Paxson, Jeff Terrell. A Brief History of Scanning. ACM SIGCOMM/USENIX Internet Measurement Conference, October 2007. http://www.icir.org/mallman/papers/scan-history-imc07.pdf ... which only pays scant attention to port scanning and not in a terribly meaningful way, but we are working on better stuff. And, for more recent data. But, that gives you some idea of the data we're looking at. > >> How would you suggest to codify such rule? -- Because it's something > >> along the lines of "don't respond to crap", then there's the question of > >> "what do you mean by crap?" > > > > Well, I think I defined it like this: > > > > I.e., if you have no connection state (whether that be active or in > > TIME-WAIT or whatever) then just don't respond to anything that > > isn't a SYN. > > That sounds very reasonable. Should I e.g. simply make some general > comments on availalable stealth port-scanning techniques, provide > references, and just include this rule? (in replacement of the current > Section 14) If you wrote a one-page I-D that said a TCP MAY "not respond to crap" (codified better of course) such that it basically mimics broadly used firewalling strategies that might be OK. You can put whatever you want in section 14 of this document...I won't support it. allman ----------ma53471-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2c0N8ACgkQWyrrWs4yIs4SjACfU8rWI4Y0xATltbQ+H4VrIA0Y wIgAniPBD0TM7Arhd9RNGTSq5cjefMQN =zVY6 -----END PGP SIGNATURE----- ----------ma53471-1-- From fernando.gont.netbook.win@gmail.com Wed Apr 6 14:12:08 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403BD28C0ED for ; Wed, 6 Apr 2011 14:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntR9zbgAaZrK for ; Wed, 6 Apr 2011 14:12:07 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id E62EA3A67C2 for ; Wed, 6 Apr 2011 14:12:06 -0700 (PDT) Received: by yic13 with SMTP id 13so880959yic.31 for ; Wed, 06 Apr 2011 14:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=0bKKAObuZrsjUUexhDC2mcxHgr8p+eA0OsngIAJJiaY=; b=TsKgQ4XVWhm8ztDLVv60JseKc8hYZ4bW66/DKlPF+a1fprn4o5QneHPvSciubI/Jl2 anu811cEAy7SX2Zc4c2BetHr88EEbFuDEKKVxVyz4kbOS5NKpanTqIsQmIaUfM7kyMSe njCC2gLv+OYFdNJ1XdvwzcbBAUdcsNebTxx9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=DVvCdBoxFrkFcrp/CU8zzInY0TtZhE7eo6qhMKn0kNKuuBdkinYmUekJ9qMgsoNUlu 42otyhjs5GHTpMdSY5DRZLZbMF2vuVAtmgUbyjC89or35IIyKO6qq+97XQyF0IAFAAEi s/bqpZ/fS75WnrvHq1yHr20z8A7w0BXKY4zw4= Received: by 10.236.180.136 with SMTP id j8mr126161yhm.219.1302124429861; Wed, 06 Apr 2011 14:13:49 -0700 (PDT) Received: from [192.168.123.101] ([190.48.201.131]) by mx.google.com with ESMTPS id g23sm386029yhc.35.2011.04.06.14.13.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 14:13:49 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9CD784.2000305@gont.com.ar> Date: Wed, 06 Apr 2011 18:13:40 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: mallman@icir.org References: <20110406204519.9DA6D38696E2@lawyers.icir.org> In-Reply-To: <20110406204519.9DA6D38696E2@lawyers.icir.org> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] security draft: section 14 review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 21:12:08 -0000 On 06/04/2011 05:45 p.m., Mark Allman wrote: >> The stealth port-scanning techniques are based on TCP features/bugs. If >> one ones to mitigate them, they need to be mitigated in the TCP code. > > (Or in a firewall like everyone does.) In quite a number of cases, firewalls need to mitigate things simply because implementations are not doing as good as they could/should. I don't see why one should rely on a firewall for *this* >> Agreed. Just curious: where has the dataset been obtained? > > LBL. See ... > > Mark Allman, Vern Paxson, Jeff Terrell. A Brief History of Scanning. > ACM SIGCOMM/USENIX Internet Measurement Conference, October 2007. > http://www.icir.org/mallman/papers/scan-history-imc07.pdf > > ... which only pays scant attention to port scanning and not in a > terribly meaningful way, but we are working on better stuff. And, for > more recent data. But, that gives you some idea of the data we're > looking at. Thanks for the pointer. I'll read your paper. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Wed Apr 6 15:00:43 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A033A67E9 for ; Wed, 6 Apr 2011 15:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3udGireuSLFi for ; Wed, 6 Apr 2011 15:00:40 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 977643A6965 for ; Wed, 6 Apr 2011 15:00:40 -0700 (PDT) Received: by ywi6 with SMTP id 6so893022ywi.31 for ; Wed, 06 Apr 2011 15:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=It/UDhdMmZ1Tcmy/nay4R+NgI5/lw+Hm6aS3NMZxaFA=; b=Pffsr1dMmHvaKyBTMKkf6HtKZg+1gdcFO2n55ra+eLR3YdRgHoHp3R3THyPsm3KQl6 XQd8ktxjLpyDmKOELHEig1vFSM8lLHrUlNH2zVHIE/WlY0huHAF5C2qL/KwodYOdi1e9 z5VWJx9n27UWPbdA6RLKr/zkLlh0WYXVwhfic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=S9YJmtMaeuXiJYJQgD+rQhv82jrQ5uBLgvOSFcH26VbgtfwAno3Z8pRD1066GelQ1/ nToCBem90yxUJIcegkxPu24Iv2OE7occ6EIwA5PFhJDN7Dz8CDSh965P01YUQtBVTgjw oboYyKWnmfEHhhX/Nhq307YfF0LGsm0X76Itg= Received: by 10.146.144.8 with SMTP id r8mr146356yad.9.1302127344342; Wed, 06 Apr 2011 15:02:24 -0700 (PDT) Received: from [192.168.123.101] ([190.48.201.131]) by mx.google.com with ESMTPS id x34sm1105655ana.10.2011.04.06.15.02.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2011 15:02:22 -0700 (PDT) Sender: Fernando Gont Message-ID: <4D9CE2E4.80707@gont.com.ar> Date: Wed, 06 Apr 2011 19:02:12 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: mallman@icir.org References: <20110404181840.9DE8738000AF@lawyers.icir.org> In-Reply-To: <20110404181840.9DE8738000AF@lawyers.icir.org> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] security draft: section 9 review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 22:00:43 -0000 Hi, Mark, On 04/04/2011 03:18 p.m., Mark Allman wrote: > In sum, I basically find this section to be 15 pages of re-hash that > adds little if anything to the state of our understanding. I agree that it contains lots of background that should be removed. > Section 1: > > + The premise of this document seems strange to me. Basically, the > reviewed documents don't consider security or people don't read them > or whatever and so we have to invent a new 100+ page document that > nobody will read to fix this situation. Huh. The assessed documents do not consider security, or there are decisions that need to be taken when one implements an RFC, on which the aforementioned RFCs do not provide advice. The document is large, and I should probably remove much (if not all) of the background information that makes the document as large as it currently is. > + The older of the TCP documents may not consider security as well as > we'd like, but the newer documents do consider security and in some > cases at least as well as this document. So, perhaps there are > things to be done to older documents to shore them up, but I am not > entirely sure there is any value in re-visiting the newer documents > and parroting back what is said in those in some new document. Maybe that when that's the case (i.e., everything is covered in the curresponding RFC), this document should just say that, and that's it. > + I wonder if there is a different route here which is along the lines > of spelling out what a modern TCP looks like and then trying to go > after issues that *are not* addressed by the documents themselves. > E.g., who cares about blind dupack attacks in a world that to an > exceedingly large degree uses SACK? When I tested these attacks, they did work even for SACK-enabled connections. I recall that we discussed this off-list, and that something in this respect was added to the 2581bis document ("sack-enabled connections should validate dupacks by making sure that they include new sack information" or the like). At the time, 2581bis had not made it into an RFC (and the aforementioned changes had not been ncorporated when the CPNI TCP document was published, IIRC). This might be, as mentioned in my other post, a specific example on which tcp-security is simply outdated. Question: Any data regarding whether current implementations do validate the dupacks for sack-enabled connections? > It is not necessarily a service > to anyone to discuss things that don't matter a ton FWIW, I'm not arguing that e.g. these dupack attacks matter a lot. But if they can be simply mitigated, I don't see why we should leave them in. > As far as I can tell section 9 makes three recommendations over and > above the RFCs: > > - Stricter check on out-of-window packets to prevent blind attackers > from using this check to strobe out valid ACKs once they guess the > four-tuple. > > I don't have a lot of heartburn with the proposed check except that > there is an extra approximately 112 pages used to describe it than > would be necessary. Agreed. I'm already working in removing much (probably most) of the text in this section. > - Stronger language about the number of dupacks a TCP sender should > expect from a correctly behaving TCP receiver. I.e., this document > (on page 765) says a TCP SHOULD limit the number of dupacks it will > honor and RFC 5681 says a TCP MAY limit the number (on page 10). > Perhaps the mechanism ought to be a SHOULD and not a MAY. But, in a > SACK-dominated world I have a hard time getting worked up over it > one way or the other. Does sack, in practice, mitigate these attacks? (see above) > And, changes of this level perhaps should get > 20sec in the emacs buffer to change MAY to SHOULD in 5681, be WGLCed > for two weeks and be put in the actual main document. (Not that I > think it is important enough to do so ...) No objections to this. Actually, I think that I suggested this myself at the time 2581bis was being produced. > OK, now comments on section 9: > > o RFC 2581 has been obsolete for 18 months. Please change to RFC 5681 > and note that RFC 5681 changed in ways that are germane to this > document so this is not cosmetic. Will do. > o 9.1.1 starts very abruptly with a "rule" without any context around > it. This formulation is carried throughout and its just damn > weird. > > It'd seem much more natural to tee up a problem and then > give a mitigating rule. My reaction to this "rule" was something > like "in slow start? congestion avoidance? what in the hell is he > talking about?". Regarding the REQ/DISCUSSION format, this was actually requested some time ago (i.e., reformat the document a la RFC1122). However, I do agree that this should be better specified. At the very least, whether this is during slow start, congestion avoidance, etc. > o This document says nothing over and above what RFC 5681 says about > ACK division. I.e., page 6 of RFC 5681 discusses exactly this > for both slow start and congestion avoidance. As noted, tcp-security is outdated regarding RFC5681. I'll fix this. > o The upshot of 9.1.2 is a notion that TCPs SHOULD limit the number of > acceptable dupacks. This extends (slightly) the MAY that is in RFC > 5681 (page 10). Further, it would seem nice to note here that > SACK-based loss recovery (and all empirical evidence I have seen > points to SACK being massively used) does not share these issues > with dupack-based attacks and to try to put these attacks in > perspective given the proportion of SACK-savvy hosts. IIRC, last time I checked (2007), sack didn't make a difference. This may have changed since then. I will try to re-run my tests. > o The figure references in this document are ridiculous. You need to > figure out how to explain things without figures in this document, > or use diagrams or something. What you have is essentially > normative references to some tech report that someone has to look at > to understand the text of this document. Its an unreasonable > construct. Its fine to explain something that I can understand in > this document and *also* point to a discussion/figure elsewhere, but > don't require me to go look at it there. Agreed. I think this is even noted in the "TODO list". This is editorial work to be done. Meanwhile, I thought the wg might simply decide that e.g. those figures were simply not necessary... hence no much sense in doing ASCII-art for them. > o 9.1.3: There is not enough discussion around this attack. Agreed. But this is another instance of "should the document include background stuff, or should it simply provide a reference to the background stuff when such a thing is available?". Note that I'm not arguing one way or another. > In > particular, there are two reasons why someone might want to do this > attack. > > The first reason is for a receiver to try to coax a higher sending > rate out of the sender for some transfer they care about. The > trouble---and it should at least be discussed---is that the user is > walking a tightrope here. They are coaxing out faster transmission, > but as soon as a packet they have ACKed is lost its "game over" and > they have to start a new connection. Depending on how things work > they might have to start the whole transfer over again. Or, if > their app protocol supports it perhaps they can restart things at > the point of loss. But, either way it takes complexity and time to > fix things. And, as the sending rate is coaxed faster the odds of > taking a loss increase. So, the attack somewhat works against > itself and that makes it less compelling. At least a document about > security would want to understand the threat model, right? Agreed. Will do. > o The intro to 9.2 is a confusing mess. I don't know what the hell it > is trying to say and a bunch of stuff is then repeated later. In the previous attacks, the attacker is one endpoint of the connection (i.e., he attacks his own connection). In the attacks described in Section 9.2, the attacker attacks a third-party connection. He forges out-of-window packets, which elicit dupacks from the recipient of these out-of-window packets. (and there's no need to hit the window... actually, for these attacks to work the attack packets must *not* with the window). -- I know you'll hate it, but this is better explained with the figures in the PDF document (which are probably virtually impossible to convert to ASCII art). > o I basically fail to see how this blind attacks section is better > than the one we already have in the form of Joe's RFC. Joe's RFC does not cover these attacks. His RFCs covers *in-window* attacks. That aside, the unnumbered subsections "port randomization", "GTSM", "ingress and egress filtering", etc., should be removed., or at least summarized in a single paragraph. > o There is a whole section on the difficulty of blind attacks and it > basically boils down to "we have seen some cases where it is easy to > guess the four tuple" and once we have done that then it is "not > hard" to wedge enough out of window packets to the receiver between > legit packets to mount these attacks. Which section are you referring to? > Neither of these statements > carries much evidence. The truth of the matter is attacking > arbitrary TCP connections in a blind fashion is incredibly > difficult. There are more predictable connections whereby one can > get some of the four tuple and that makes things easier. But, even > if I give you a bit of that and the sequence number its still hard > and it still takes a lot of packets. And, even with your stronger > "near in-window" check it is still possible. The bottom line is > that the community has recognized this and invented actual > mechanisms---not heuristics---to prevent blind attacks. And, yet > there is *no* mention of these. What are the mechanisms that you're referring to? And what attack vectors are you arguing that they apply to? > o 9.2.4: It took me a bit of thinking to try to understand what in the > hell you were talking about with respect to NewReno. I finally > think I figured it out, no thanks to the text. Basically, I think > you are saying that if I can wedge three dupacks Actually, you cause one of the endpoints to wedge the dupacks -- you don't do it yourself. > into a NewReno > connection then the connection will enter loss recovery and every > legit ACK will look like it is pointing to a lost packet and > therefore trigger a needless retransmit. This bit needs completely > re-written. Will do. > o 9.2.4: Limited transmit... You're worried about two additional > segments? That is a security problem? Really? Off-the-rails > insane. No. I'm not worried at all. This section simply answers the question "what if limited retransmit is implemented?". Maybe what's missing is a sentence that notes that this is not big deal. > o 9.2.5: SACK: Note 3517bis alters the definition of dupack to > basically what is in this document. I am pretty sure its safe to go > ahead and reference that in this document as 3517bisbis will likely > be done before this document. Will do. > o 9.2.5: You move from one "TCP SHOULD ..." to the next with no > warning. Some sane sectioning or headings or something would really > help a bunch here. Will do. > o I don't follow the introduction of compromised routers when talking > about ECN. Why didn't you discuss those in terms of causing TCP > slowdown attacks by dropping packets, say? Or, by knocking down > rwnd, say? Or, by corrupting data, say? Why all the sudden are > malicious routers germane? It makes no sense and just adds to the > less-than-coherent rambling of this section. I guess that this has to do with "what possible issues does ECN introduce?" -- which I think is the same approach the SecCons of the ECN RFC itself takes. That said, I think it's already noted in the document that if you assume that the router has been compromising, then you're already toast. --- probably that of playing with ECN would be the last choice that an attacker would use. > Things inexplicably not in the document: > > o There are two basic forms of attacks this document discusses. The > first is an attack involving one of the endpoints gaming the > congestion control. The other is a blind attacker. This latter > could be helped by TCP-AO and it seems curious that this is not even > mentioned. Agreed. Will do. > o There is actually a third class of attacks and that is a third-party > attack (i.e. not a participant) that is not blind. I.e., someone > sitting across a coffee shop. TCPM's fascination with blind attacks > aside this seems to me like a much more likely avenue for attack > than a blind attack. In this case, many of the attacks discussed in > this document become quite possible and a whole lot easier. And, > even the protections discussed offer little help. Again, TCP-AO > would offer protection in these cases. You're right. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From mallman@icir.org Wed Apr 6 19:38:35 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9C73A6784 for ; Wed, 6 Apr 2011 19:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.606 X-Spam-Level: X-Spam-Status: No, score=-106.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjqckrP09hpu for ; Wed, 6 Apr 2011 19:38:34 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id A47983A659A for ; Wed, 6 Apr 2011 19:38:34 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p372eDvC013753; Wed, 6 Apr 2011 19:40:14 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 75BDF386F29E; Wed, 6 Apr 2011 22:40:13 -0400 (EDT) To: Fernando Gont From: Mark Allman In-Reply-To: <4D9CE2E4.80707@gont.com.ar> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Just What I Needed MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma9227-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 06 Apr 2011 22:40:13 -0400 Sender: mallman@icir.org Message-Id: <20110407024013.75BDF386F29E@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] security draft: section 9 review X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 07 Apr 2011 02:38:35 -0000 ----------ma9227-1 Content-Type: text/plain Content-Disposition: inline > On 04/04/2011 03:18 p.m., Mark Allman wrote: > > In sum, I basically find this section to be 15 pages of re-hash that > > adds little if anything to the state of our understanding. > > I agree that it contains lots of background that should be removed. I'm not going to waste WG bandwidth doing counter-point on my review. Basically, I stand by my review in the face of your response. My basic bottom line is: (1) Section 9 has a lot of words and basically makes one new concrete suggestion (only responding to close out-of-window packets) over and above what has been specified and considered elsewhere. That could be written in a two page I-D, but I guess somehow it feels better in some tour de force omnibus document? Who knows ... (2) You use the notion of "removal" a lot in your response. It is inexplicable to me that this needs that much surgery to be acceptable after all this time. Why are we being asked to review this if it is in such cruddy shape and you know it? Why this big push to get even piece-meal reviewing done? I mean, when you aren't even current to a Draft Standard on TCP congestion control that has been on the books for 18 months how are we supposed to take this seriously? When you discuss blind attacks and don't even *mention* TCP-AO how are we supposed to take this seriously? (3) Updating 18 documents with one document is a recipe for disaster. I wonder---but not enough to go back and look---how the WG ever agreed to such a path. I have seen enough on the list and off to have a pretty good idea that this thing has no consensus now and dollars to donuts it will never reach that bar. We should not throw good effort after bad and move on to other items. If there are useful bits in here they should be incorporated in the standards as necessary via the usual procedure and not via some massive catch all. allman ----------ma9227-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2dJA0ACgkQWyrrWs4yIs443ACcDd7+dLE9qEUX7YRZwPD1IBQ5 mXYAnRU9Vp70IY+6Ml2NW1jnHCtwHged =A2az -----END PGP SIGNATURE----- ----------ma9227-1-- From Michael.Scharf@alcatel-lucent.com Thu Apr 7 07:26:33 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5ABB28C105 for ; Thu, 7 Apr 2011 07:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ST1v7G-H7G5Z for ; Thu, 7 Apr 2011 07:26:33 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id BA3FC28C0E1 for ; Thu, 7 Apr 2011 07:26:32 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p37ESFU0019396 for ; Thu, 7 Apr 2011 16:28:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF530.08087F61" Date: Thu, 7 Apr 2011 16:28:15 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C026F62ED@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Vacation Thread-index: Acv1MAfY4I8zIyNiQ12P/ge8hv9PPw== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] Vacation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 14:26:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF530.08087F61 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, just to let you know: I am on vacation until April 20 and I read e-mails = only sporadically until then. I'll take care of some of the outstanding = issues afterwards. I know that this timing is somehow suboptimal, but this was planned = before I became co-chair. Sorry Michael ------_=_NextPart_001_01CBF530.08087F61 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Vacation

Folks,

just to let you know: I am on vacation until April 20 and I read e-mails = only sporadically until then. I'll take care of some of the outstanding = issues afterwards.

I know that this timing is somehow suboptimal, but this was planned = before I became co-chair.

Sorry

Michael

------_=_NextPart_001_01CBF530.08087F61-- From ycheng@google.com Fri Apr 8 11:12:19 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C1A3A6A17 for ; Fri, 8 Apr 2011 11:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.949 X-Spam-Level: X-Spam-Status: No, score=-104.949 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4c3aSJKNhrY for ; Fri, 8 Apr 2011 11:12:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 49D3B3A6A0D for ; Fri, 8 Apr 2011 11:12:18 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p38IE3tr023564 for ; Fri, 8 Apr 2011 11:14:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302286443; bh=TwG1dsbpB1+cxA8NU6IFUOWszvs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tFClMbBoLaijacRMWM5MmrWZ4FcF9DjkEOKToFVoZc5rralGjbTVR4/yqn4dIIZ14 +mz4CYr7p+X+W+rlroScQ== Received: from vws12 (vws12.prod.google.com [10.241.21.140]) by wpaz9.hot.corp.google.com with ESMTP id p38ICCb7030469 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 8 Apr 2011 11:14:02 -0700 Received: by vws12 with SMTP id 12so4689017vws.17 for ; Fri, 08 Apr 2011 11:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ClGGEP+o3fdVdqsDZz4nT0eHRPbBX7A63jHc9bdtFmE=; b=hgO74U86nKGZNTgu4d41Ku2rY3NsBng3EESw7R/BtKgAeY/ZuQs0IjfPkiYnlx0IoO 69IcOea+PkDLme4r6tyQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=aK7hEete1uv1phZ8MOuBTQvstqdugiM0PwAFPE23Ct3L09NB4tujTsdQJW+GzmR4fD bfntu0FrGm4o/+CWay5Q== Received: by 10.220.180.68 with SMTP id bt4mr691157vcb.180.1302286442106; Fri, 08 Apr 2011 11:14:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.16.148 with HTTP; Fri, 8 Apr 2011 11:13:42 -0700 (PDT) In-Reply-To: References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> <1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> <5FDC413D5FA246468C200652D63E627A0D9D5908@LDCMVEXC1-PRD.hq.netapp.com> <133D9897FB9C5E4E9DF2779DC91E947C026F62E6@SLFSNX.rcs.alcatel-research.de> From: Yuchung Cheng Date: Fri, 8 Apr 2011 11:13:42 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary=00248c0d7a90c70ed104a06c30a1 X-System-Of-Record: true Cc: Matthew Mathis Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 18:12:19 -0000 --00248c0d7a90c70ed104a06c30a1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi folks, As promised, we have came up a few examples to best illustrate the difference among PRR-RB, RFC3517, Linux. Linux currently implements some variant of rate-halving. The tables below some example the per ACK response during the first round-trip in Fast-recovery of Linux, RFC3517, and PRR-RB. In all examples, cwnd =3D pipe =3D 20 when the first packet is lost. Each column in the table shows the internal stats upon receiving an (dup)ACK with appropriate SACK blocks ack#: the ack of a packet. X means the packet is dropped.cwnd: cwnd after processing the ACK. It is not shown in PRR-RB because cwnd does not control the numbre of packets sent during Fast-Recovery. pipe: estimated packets in the network sent: packets sent. N: new data. R: retransmits RB: PRR-RB uses the reduction bound for sndcnt =3D min(ssthresh - pipe, prr_delivered - prr_out) s: the first term. f: the second term NOTE: we use the 3517 loss marking in all algorithms. (Linux default uses the more aggressive FACK). Therefore all Fast-Recovery starts after ACK3. ---------------------------------------------------------------------------= ---- 1. First packet is lost. Trail new data beyond RecoverPoint ack# X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 LINUX cwnd: 20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 pipe: 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10 sent: N N R N N N N N N N N 3517 cwnd: 20 20 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 pipe: 19 19 18 18 17 16 15 14 13 12 11 10 10 10 10 10 10 10 10 sent: N N R N N N N N N N N PRR-RB pipe: 19 19 18 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 10 sent: N N R N N N N N N N N RB: s s All algoritms send same amount. 3517 experiences the =93half-window=94 of silence ---------------------------------------------------------------------------= ---- 2. First packet is lost. No new data beyond RecoveryPoint ack# X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 LINUX cwnd: 20 20 17 16 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 pipe: 19 18 16 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 sent: R 3517 cwnd: 20 20 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 pipe: 19 18 16 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 sent: R PRR-RB pipe: 19 18 16 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 sent: R RB: s s s s s s s s s s Linux cwnd drops to 2 and does slow-start after recovery. This applies to ANY cwnd value. ---------------------------------------------------------------------------= ---- 3. First 15 packets are lost. Trail data beyond RecoveryPoint ack# X X X X X X X X X X X X X X X 15 16 17 18 19 LINUX cwnd: 20 20 5 5 5 pipe: 19 19 4 4 4 sent: N N R R R 3517 cwnd: 20 20 11 11 11 pipe: 19 19 4 10 10 sent: N N 7R R R PRR-RB pipe: 19 19 4 6 6 sent: N N 3R R R RB: f f f a) 3517 sends a larger burst (7 retransmits) under heavy drops compared to Linux and PRR-RB b) Linux cwnd drops to 5 and does slow-start after recovery ---------------------------------------------------------------------------= ---- 4. First 15 packets are lost. No new data beyond RecoveryPoint ack# X X X X X X X X X X X X X X X 15 16 17 18 19 LINUX cwnd: 20 20 3 3 3 pipe: 19 18 2 2 2 sent: R R R 3517 cwnd: 20 20 10 10 10 pipe: 19 18 2 9 9 sent: 8R R R PRR-RB pipe: 19 18 2 4 4 sent: 3R R R RB: f f f a) Linux cwnd drops to 3 and does slow-start after recovery b) The second term in the reduction-bound in PRR-RB lowers the burst size (on ack 17). We are developing on a new algorithm to send as many as RFC3517 but pace out the 10 packets. ---------------------------------------------------------------------------= ---- 5. First 2 and last 8 packets are lost. No trailing data beyond RecoverPoin= t ack# X X 2 3 4 5 6 7 8 9 10 X X X X X X X X X LINUX cwnd: 20 20 16 15 15 14 14 13 12 pipe: 19 18 15 15 14 14 13 12 11 sent: R R 3517 cwnd: 20 20 10 10 10 10 10 10 10 pipe: 19 18 15 15 14 13 12 11 10 sent: R PRR-RB pipe: 19 18 15 16 15 14 13 12 11 sent: 2R RB: s s s s a) 3517 will timeout if the only retransmit is lost again --00248c0d7a90c70ed104a06c30a1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable = Hi folks,

As promised,=A0we have came up a few examples = to best illustrate the difference among PRR-RB, RFC3517, Linux. Linux curre= ntly implements some variant of rate-halving.

The tables below some example the per ACK response du= ring the first
round-trip in Fast-recovery of Linux, RFC3517= , and PRR-RB. In all examples,
cwnd =3D pipe =3D 20 when the first packet is lost.
<= font class=3D"Apple-style-span" face=3D"'courier new', monospace"><= br>

Each column in the table shows the internal stat= s upon receiving an
(dup)ACK with appropriate SACK blocks

= ack#: the ack of a packet. X means the packet is dropped.cwnd: cwnd<= /div>
=A0 =A0 =A0 after processing the ACK. It is not shown in PRR-RB b= ecause cwnd
=A0 =A0 =A0 does not control the numbre of packets sent during Fast-Re= covery.

pipe: estimated packets in the network
<= font class=3D"Apple-style-span" face=3D"'courier new', monospace"><= br>
sent: packets sent. N: new data. R: retransmits

<= /font>
RB: =A0 PRR-RB uses the reduction bound for
=A0 =A0 = =A0 sndcnt =3D min(ssthresh - pipe, prr_delivered - prr_out)
=A0 =A0 =A0 s: the first term. f: the second term

NOTE: we use the 3517 loss marking in all algori= thms. (Linux default uses
the more aggressive FACK). Therefore all Fast-Recovery starts after AC= K3.

---------------------------------------------------------= ----------------------
1. First packet is lost. Trail new = data beyond RecoverPoint

ack# =A0 X =A01 =A02 =A03 =A04 =A05 =A06 =A07 = =A08 =A09 10 11 12 13 14 15 16 17 18 19
LINUX
cwnd: =A0 =A020 20 19 18 18 17 17 16 16 15 15 1= 4 14 13 13 12 12 11 11
pipe: =A0 =A019 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10<= /font>
sent: =A0 =A0 N =A0N =A0R =A0 =A0 N =A0 =A0 N =A0 =A0 N = =A0 =A0 N =A0 =A0 N =A0 =A0 N =A0 =A0 N =A0 =A0 N

3517
cwnd: =A0 =A020 20 11 11 1= 1 11 11 11 11 11 11 11 11 11 11 11 11 11 11
pipe: =A0 =A019 19 18 18 17 16 15 14 13 12 11 10 10 10 10 10 10 10 10<= /font>
sent: =A0 =A0 N =A0N =A0R =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0N =A0N =A0N =A0N =A0N =A0N =A0N =A0N

PRR-RB
pipe: =A0 =A019 19 18 18= 18 17 17 16 16 15 15 14 14 13 13 12 12 11 10
sent: =A0 =A0 N =A0N =A0R =A0N =A0 =A0 N =A0 =A0 N =A0 =A0 N =A0 =A0 N= =A0 =A0 N =A0 =A0 N =A0 =A0 =A0 =A0N
RB: =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0s =A0s


All algoritms send same am= ount. 3517 experiences the =93half-window=94 of silence



---------------------------------------------------------= ----------------------
2. First packet is lost. No new dat= a beyond RecoveryPoint

ack# =A0 X =A01 =A02 =A03 =A04 =A05 =A06 =A07 = =A08 =A09 10 11 12 13 14 15 16 17 18 19
LINUX
cwnd: =A0 =A020 20 17 16 16 15 14 13 12 11 10 = =A09 =A08 =A07 =A06 =A05 =A04 =A03 =A02
pipe: =A0 =A019 18 16 16 15 14 13 12 11 10 =A09 =A08 =A07 =A06 =A05 = =A04 =A03 =A02 =A01
sent: =A0 =A0 =A0 =A0 =A0 R

3517
cwnd: =A0 =A020 20 10 10 1= 0 10 10 10 10 10 10 10 10 10 10 10 10 10 10
pipe: =A0 =A019 18 16 16 15 14 13 12 11 10 =A09 =A08 =A07 =A06 =A05 = =A04 =A03 =A02 =A01
sent: =A0 =A0 =A0 =A0 =A0 R

PRR-RB
pipe: =A0 =A019 18 16 16= 15 14 13 12 11 10 =A09 =A08 =A07 =A06 =A05 =A04 =A03 =A02 =A01
sent: =A0 =A0 =A0 =A0 =A0 R
RB: =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0s =A0s =A0s =A0s =A0s =A0s = =A0s =A0s =A0s =A0s

Linux cwnd drops to 2 and does slow-start after = recovery. This applies
to ANY cwnd value.


---------------------------------------------------------= ----------------------
3. First 15 packets are lost. Trail= data beyond RecoveryPoint

ack# =A0 X =A0X =A0X =A0X =A0X =A0X =A0X =A0X = =A0X =A0X =A0X =A0X =A0X =A0X =A0X 15 16 17 18 19
LINUX
cwnd: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A020 20 =A05 =A05 =A05
pipe: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A019 19 =A04 =A04 =A04
sent: =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 N =A0N =A0R =A0R =A0R

3517
cwnd: =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A020 2= 0 11 11 11
pipe: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A019 19 =A04 10 10
sent: =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 N =A0N 7R =A0R =A0R

PRR-RB
pipe: =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 19 19 =A04 =A06 =A06
sent: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 N =A0N 3R =A0R =A0R
RB: =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 f =A0f =A0f


a) 3517 se= nds a larger burst (7 retransmits) under heavy drops compared to
=A0 =A0Linux and PRR-RB
b) Linux cwnd drops to 5 and do= es slow-start after recovery

------------------------------------------------= -------------------------------
4. First 15 packets are lost. No new data beyond RecoveryPoint<= /div>

ack# =A0 X =A0X =A0X =A0X =A0X =A0X =A0X =A0X =A0X =A0X = =A0X =A0X =A0X =A0X =A0X 15 16 17 18 19
LINUX
cwnd: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A020 20 =A03 =A03 =A03
pipe: =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A019 18 =A02 =A02 =A02
sent: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 R =A0R =A0R

3517
cwnd: =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A020 20 10 10 = 10
pipe: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A019 18 =A02 =A09 =A09
sent: =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A08R =A0R =A0R

PRR-RB
pipe: =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 19 18 =A02 =A04 =A04
sent: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03R =A0R =A0R
RB: = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 f =A0f =A0f

a) Linux cwnd drops to 3 and does slow-start aft= er recovery
b) The second term in the reduction-bound in PRR-RB lowers the burst s= ize
=A0 =A0(on ack 17). We are developing on a new algorit= hm to send as many as RFC3517
=A0 =A0but pace out the 10 packets.

=
----------------------------------------------------------------------= ---------
5. First 2 and last 8 packets are lost. No trailing data beyond Recove= rPoint

ack# =A0 X =A0X =A02 =A03 =A04 =A05 =A06 =A07 =A08 =A09 1= 0 =A0X =A0X =A0X =A0X =A0X =A0X =A0X =A0X =A0X
LINUX
cwnd: =A0 =A0 =A0 20 20 16 15 15 14 14 13 12
pipe: = =A0 =A0 =A0 19 18 15 15 14 14 13 12 11
sent: =A0 =A0 =A0 =A0 =A0 =A0 =A0R =A0 =A0 R

3517
cwnd: =A0 =A0 =A0 20 20 10 10 10 10 10 10 10
pipe: = =A0 =A0 =A0 19 18 15 15 14 13 12 11 10
sent: =A0 =A0 =A0 =A0 =A0 =A0 =A0R

<= div>PRR-RB
pipe: =A0 =A0 =A0 19 18 15 16 15 14 13 12 11
sent: = =A0 =A0 =A0 =A0 =A0 =A0 2R
RB: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s =A0s =A0s =A0s

= a) 3517 will timeout if the only retransmit is lost again


--00248c0d7a90c70ed104a06c30a1-- From ayourtch@gmail.com Tue Apr 12 14:26:54 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 16B17E097C for ; Tue, 12 Apr 2011 14:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJKLOQ951LxP for ; Tue, 12 Apr 2011 14:26:53 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 3B299E0976 for ; Tue, 12 Apr 2011 14:26:53 -0700 (PDT) Received: by iwn39 with SMTP id 39so8732741iwn.31 for ; Tue, 12 Apr 2011 14:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=D32XvmYTYAcGR8qqg+Cyy87ShlCFvrmntxrgg1q2mOk=; b=TcpdQjgM7Nv7HSkaiBFtBNV1kPSaIohif9JTp/yH1lpmnX+TLVQeY+GhfMwEFHT7if 38bs4VasLzliu9GIgQf6J45dRNPch1+Zn7uvt34bdwgmV3QFbZad2Re5tyXOiCngGmIo RFti6OzYtLif+OYkIWZk2IHu8lVeSbt/VG0xU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=U9sKIIGhw7PKHxcOdB8nsUl4BGi2eZz+ackB1uhNZRPK3is/1zaxS759dwRC4re0gR xhgwPUE3mqfVr7PIR6uI/ueeGSZEeuTf2402CUsiVpJnGq3Xve70xgLOh+q9v2NLyt8c fXSnW4R97AnzAaziEIa+PYQbeXQn7HesGkOgM= MIME-Version: 1.0 Received: by 10.43.131.195 with SMTP id hr3mr10777564icc.268.1302643612357; Tue, 12 Apr 2011 14:26:52 -0700 (PDT) Received: by 10.42.244.67 with HTTP; Tue, 12 Apr 2011 14:26:52 -0700 (PDT) Date: Tue, 12 Apr 2011 23:26:52 +0200 Message-ID: From: Andrew Yourtchenko To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 21:26:54 -0000 Folks, my observation is - there's an ongoing "musical chairs" game with respect to TCP options space. As a WG I think we should take a step to tackle it upfront and see what (if) can be done about it. During the IETF in Prague, I discussed an idea offline with several people, and the rough consensus from what I heard was that I should package it up for further beating up into a draft, to hear more from the WG at large. So here it is: http://tools.ietf.org/html/draft-yourtchenko-tcp-loic NB: the draft deliberately omits the discussion of the hard problem of the two parallel 3WHS operations and their timing to get a robust solution. The draft is there to get a sense from the community on the general approach - whether it may be used as a building block going forward or not at all. flame on, please! :-) (I know, the name does implicate :-) cheers, andrew From ananth@cisco.com Tue Apr 12 15:19:18 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 21850E0844 for ; Tue, 12 Apr 2011 15:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C10LaCNl4ayX for ; Tue, 12 Apr 2011 15:19:17 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 23D65E07BE for ; Tue, 12 Apr 2011 15:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2131; q=dns/txt; s=iport; t=1302646757; x=1303856357; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ji79hkx5POdlK3oFEtlD8Jct0dRb7dMwEDHYRZ+WbmU=; b=YavvCl7aqBc1RkAClgSXQdM1sv1Zv6KHtpuEnuLypm6dvI60eAaeTuGW Eqo4QvjztXsVNXhgJ2yXqiMvXf8cx73fSV2CzvA1ZTl5fvvlBnGIq2174 wBYP7FuKkDjUgfr9/uqsjdarrbwdOg3YhAkYw/Op+JGr4YsutOYYGGdhZ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAKbOpE2rRDoI/2dsb2JhbACYHY1od6dtnRWFbgSFXIt9 X-IronPort-AV: E=Sophos;i="4.64,200,1301875200"; d="scan'208";a="335820335" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2011 22:18:57 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3CMInFB007828; Tue, 12 Apr 2011 22:18:57 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 15:18:56 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Apr 2011 15:18:56 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580C6C459C@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Extending the TCP option space - yet another approach Thread-Index: Acv5WGJs1pkm7+TqRWi1rK/sPMI19wAAoDfA References: From: "Anantha Ramaiah (ananth)" To: "Andrew Yourtchenko" , X-OriginalArrivalTime: 12 Apr 2011 22:18:56.0895 (UTC) FILETIME=[9D72D8F0:01CBF95F] Subject: Re: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 22:19:18 -0000 To add more... History : TCP option space issue, when I raised it 5 years back, was deemed as a "solution in search of a problem". There was no convergence reached on any of the proposals that were being discussed. Adam Langley also tried to revive the TCP options discussion sometime back. Time passed by and currently with many proposals seeking a new TCP option etc., (includes MPTCP) the TCP option space is more and more becoming a real issue. I chatted with the chairs during this IETF and they seem to agree that this is an area where TCP WG can do something.=20 >From my part I had volunteered to write up an ID ( a small document) describing the problem and reasons for doing TCP option space extension. I am working on it. -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Andrew Yourtchenko > Sent: Tuesday, April 12, 2011 2:27 PM > To: tcpm@ietf.org > Subject: [tcpm] Extending the TCP option space - yet another approach >=20 > Folks, >=20 > my observation is - there's an ongoing "musical chairs" game with > respect to TCP options space. As a WG I think we should take a step to > tackle it upfront and see what (if) can be done about it. >=20 > During the IETF in Prague, I discussed an idea offline with several > people, and the rough consensus from what I heard was that I should > package it up for further beating up into a draft, to hear more from > the WG at large. >=20 > So here it is: http://tools.ietf.org/html/draft-yourtchenko-tcp-loic >=20 > NB: the draft deliberately omits the discussion of the hard problem of > the two parallel 3WHS operations and their timing to get a robust > solution. The draft is there to get a sense from the community on the > general approach - whether it may be used as a building block going > forward or not at all. >=20 > flame on, please! :-) (I know, the name does implicate :-) >=20 > cheers, > andrew > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Tue Apr 12 15:48:51 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 408ADE06CE for ; Tue, 12 Apr 2011 15:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQRZMqi2xBU2 for ; Tue, 12 Apr 2011 15:48:50 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfc.amsl.com (Postfix) with ESMTP id 7FDE1E0695 for ; Tue, 12 Apr 2011 15:48:50 -0700 (PDT) Received: from [10.133.228.121] (UAPublic-41.guest.arizona.edu [206.207.225.41]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p3CMm3kK017309 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 12 Apr 2011 15:48:14 -0700 (PDT) Message-ID: <4DA4D6A3.1010706@isi.edu> Date: Tue, 12 Apr 2011 15:48:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC580C6C459C@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580C6C459C@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 22:48:51 -0000 Hi, all, On 4/12/2011 3:18 PM, Anantha Ramaiah (ananth) wrote: > > To add more... > > History : TCP option space issue, when I raised it 5 years back, was > deemed as a "solution in search of a problem". I would describe it as a "unsolvable problem" with many proposed solutions, none of which was viable. Here's the nutshell, as I recall it: - extra space after the 3WHS is easy; create an option, and once it's ACK'd you can use it (in each direction) - extra space is useful only if it exists in the SYN, however; that's where space is at a real premium - extra space in the SYN is not possible there's no way to provide the space before you negotiate support in a backward compatible way There were several mechanisms, some of which attempted to use data in the SYN (which corrupts the data path if not supported), and even one that suggested just doubling all the TCP header fields (Mark Allman). Regardless of need or utility, it is simply not possible in the SYN. So basically: - we can trivially add space after a SYN exchange; it that's useful, let's do it - if the real need is for space inside the SYN, a real solution needs to be presented that is backward compatible Non-backward compatible solutions to increased SYN space are trivial too - use a new protocol number. ;-) Regarding Andrew's proposal, IMO it isn't useful: - outboard boxes and some intermediate systemsdump packets with erroneous checksums -- or worse, they update the checksums ;-( the latter would be really bad - even if they didn't, if you support the new method, how long do you hold the first SYN you get in hopes of seeing a SYN-LO? that's the trouble with dual-open tricks; you get stuck waiting for something that might never happen, and end up delaying everything If I missed anything, please post. Joe From jakob.heitz@ericsson.com Tue Apr 12 15:59:54 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F2049E06A5 for ; Tue, 12 Apr 2011 15:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.761 X-Spam-Level: X-Spam-Status: No, score=-4.761 tagged_above=-999 required=5 tests=[AWL=1.838, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qoq70nn5yOPo for ; Tue, 12 Apr 2011 15:59:54 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id 76EEDE06C5 for ; Tue, 12 Apr 2011 15:59:54 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3CMxqeJ021300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Apr 2011 17:59:52 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.141]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 12 Apr 2011 18:59:52 -0400 From: Jakob Heitz To: Joe Touch , "Anantha Ramaiah (ananth)" Date: Tue, 12 Apr 2011 18:59:50 -0400 Thread-Topic: [tcpm] Extending the TCP option space - yet another approach Thread-Index: Acv5Y86khTeHP/f1R72OpWak7K6KswAAOprw Message-ID: <7309FCBCAE981B43ABBE69B31C8D21390E3F87AF26@EUSAACMS0701.eamcs.ericsson.se> References: <0C53DCFB700D144284A584F54711EC580C6C459C@xmb-sjc-21c.amer.cisco.com> <4DA4D6A3.1010706@isi.edu> In-Reply-To: <4DA4D6A3.1010706@isi.edu> 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 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 22:59:55 -0000 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Joe Touch > - even if they didn't, if you support the new method, how long do you=20 > hold the first SYN you get in hopes of seeing a SYN-LO? that's the=20 > trouble with dual-open tricks; you get stuck waiting for=20 > something that=20 > might never happen, and end up delaying everything Hold it until the next packet comes. If that packet isn't a SYN-LO, then it's not coming. Nothing is delayed. -- Jakob Heitz. =20 From touch@isi.edu Tue Apr 12 16:03:52 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1CE94E0943 for ; Tue, 12 Apr 2011 16:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju17hG7Tzri9 for ; Tue, 12 Apr 2011 16:03:51 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfc.amsl.com (Postfix) with ESMTP id 6BFD1E06C9 for ; Tue, 12 Apr 2011 16:03:51 -0700 (PDT) Received: from [10.133.228.121] (UAPublic-41.guest.arizona.edu [206.207.225.41]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p3CN3OvW022571 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 12 Apr 2011 16:03:34 -0700 (PDT) Message-ID: <4DA4DA3C.9010106@isi.edu> Date: Tue, 12 Apr 2011 16:03:24 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jakob Heitz References: <0C53DCFB700D144284A584F54711EC580C6C459C@xmb-sjc-21c.amer.cisco.com> <4DA4D6A3.1010706@isi.edu> <7309FCBCAE981B43ABBE69B31C8D21390E3F87AF26@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21390E3F87AF26@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p3CN3OvW022571 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 23:03:52 -0000 On 4/12/2011 3:59 PM, Jakob Heitz wrote: >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Joe Touch >> - even if they didn't, if you support the new method, how long do you >> hold the first SYN you get in hopes of seeing a SYN-LO? that's the >> trouble with dual-open tricks; you get stuck waiting for >> something that >> might never happen, and end up delaying everything > > Hold it until the next packet comes. If that packet isn't > a SYN-LO, then it's not coming. Nothing is delayed. What next packet? If it's a legacy TCP, you're waiting for a SYN retransmission, and you've now killed their performance. Joe From touch@isi.edu Tue Apr 12 16:06:38 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 16729E0949 for ; Tue, 12 Apr 2011 16:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LkU6Ksehy7q for ; Tue, 12 Apr 2011 16:06:37 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfc.amsl.com (Postfix) with ESMTP id 56C5AE0943 for ; Tue, 12 Apr 2011 16:06:37 -0700 (PDT) Received: from [10.133.228.121] (UAPublic-41.guest.arizona.edu [206.207.225.41]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p3CN6Eup022887 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 12 Apr 2011 16:06:24 -0700 (PDT) Message-ID: <4DA4DAE6.5030200@isi.edu> Date: Tue, 12 Apr 2011 16:06:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC580C6C459C@xmb-sjc-21c.amer.cisco.com> <4DA4D6A3.1010706@isi.edu> In-Reply-To: <4DA4D6A3.1010706@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p3CN6Eup022887 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 23:06:38 -0000 FWIW, I'd be glad to write up the problem and why a solution cannot exist, so we can stop going around this block ;-) Joe On 4/12/2011 3:48 PM, Joe Touch wrote: > Hi, all, > > On 4/12/2011 3:18 PM, Anantha Ramaiah (ananth) wrote: >> >> To add more... >> >> History : TCP option space issue, when I raised it 5 years back, was >> deemed as a "solution in search of a problem". > > I would describe it as a "unsolvable problem" with many proposed > solutions, none of which was viable. > > Here's the nutshell, as I recall it: > > - extra space after the 3WHS is easy; create an option, and once it's > ACK'd you can use it (in each direction) > > - extra space is useful only if it exists in the SYN, however; that's > where space is at a real premium > > - extra space in the SYN is not possible > there's no way to provide the space before you negotiate support in a > backward compatible way > > There were several mechanisms, some of which attempted to use data in > the SYN (which corrupts the data path if not supported), and even one > that suggested just doubling all the TCP header fields (Mark Allman). > > Regardless of need or utility, it is simply not possible in the SYN. > > So basically: > - we can trivially add space after a SYN exchange; it that's useful, > let's do it > > - if the real need is for space inside the SYN, a real solution needs to > be presented that is backward compatible > > Non-backward compatible solutions to increased SYN space are trivial too > - use a new protocol number. ;-) > > Regarding Andrew's proposal, IMO it isn't useful: > > - outboard boxes and some intermediate systemsdump packets with > erroneous checksums -- or worse, they update the checksums ;-( the > latter would be really bad > > - even if they didn't, if you support the new method, how long do you > hold the first SYN you get in hopes of seeing a SYN-LO? that's the > trouble with dual-open tricks; you get stuck waiting for something that > might never happen, and end up delaying everything > > If I missed anything, please post. > > Joe From wes@mti-systems.com Tue Apr 12 17:08:54 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B6613E08B6 for ; Tue, 12 Apr 2011 17:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHvlogt9K+Y7 for ; Tue, 12 Apr 2011 17:08:54 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfc.amsl.com (Postfix) with ESMTP id F2E41E06B8 for ; Tue, 12 Apr 2011 17:08:53 -0700 (PDT) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p3D08rF9015236 for ; Tue, 12 Apr 2011 20:08:53 -0400 Authentication-Results: cm-omr12 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.46.39] ([174.130.46.39:59890] helo=[192.168.1.104]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 9E/A1-10006-599E4AD4; Tue, 12 Apr 2011 20:08:53 -0400 Message-ID: <4DA4E9C9.60502@mti-systems.com> Date: Tue, 12 Apr 2011 20:09:45 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: tcpm@ietf.org References: <0C53DCFB700D144284A584F54711EC580C6C459C@xmb-sjc-21c.amer.cisco.com> <4DA4D6A3.1010706@isi.edu> In-Reply-To: <4DA4D6A3.1010706@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 00:08:54 -0000 On 4/12/2011 6:48 PM, Joe Touch wrote: > Hi, all, > > On 4/12/2011 3:18 PM, Anantha Ramaiah (ananth) wrote: >> >> To add more... >> >> History : TCP option space issue, when I raised it 5 years back, was >> deemed as a "solution in search of a problem". > > I would describe it as a "unsolvable problem" with many proposed > solutions, none of which was viable. > > Here's the nutshell, as I recall it: > > - extra space after the 3WHS is easy; create an option, and once it's > ACK'd you can use it (in each direction) I agree. > - extra space is useful only if it exists in the SYN, however; that's > where space is at a real premium I disagree; there's definitely utility beyond just having this capability in the SYN, some of this was defined in the LO/SLO draft linked to below. > - extra space in the SYN is not possible > there's no way to provide the space before you negotiate support in a > backward compatible way I agree. > There were several mechanisms, some of which attempted to use data in > the SYN (which corrupts the data path if not supported), and even one > that suggested just doubling all the TCP header fields (Mark Allman). The ones I recall are: - LO/SLO : http://tools.ietf.org/html/draft-eddy-tcp-loo-04 - DO redefinition : http://tools.ietf.org/html/draft-kohler-tcpm-extopt-00 - tcpx2 : https://tools.ietf.org/html/draft-allman-tcpx2-hack-00 Andrew's LOIC is interesting, and significantly different than these. If there's evidence that it can survive some significant fraction of middleboxes, that would be good; this was a concern with all 3 of the proposals listed above. > Regardless of need or utility, it is simply not possible in the SYN. The SLO option was an attempt to handle that by sending long options that you would have liked to be on the SYN later (i.e. on the ACK completing the handshake); in implementation, this meant calling the function in the kernel for processing SYN options on a received packet even though the packet wasn't a SYN, which was slightly awkward, but fairly simple. > So basically: > - we can trivially add space after a SYN exchange; it that's useful, > let's do it > The LO option is one way to handle that: http://tools.ietf.org/html/draft-eddy-tcp-loo-04 -- Wes Eddy MTI Systems From touch@isi.edu Tue Apr 12 17:39:55 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F126E0720 for ; Tue, 12 Apr 2011 17:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TGp00qzfV-2 for ; Tue, 12 Apr 2011 17:39:54 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfc.amsl.com (Postfix) with ESMTP id 89033E070F for ; Tue, 12 Apr 2011 17:39:54 -0700 (PDT) Received: from [10.133.228.121] (UAPublic-41.guest.arizona.edu [206.207.225.41]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p3D0dQQV011054 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 12 Apr 2011 17:39:36 -0700 (PDT) Message-ID: <4DA4F0BD.9040901@isi.edu> Date: Tue, 12 Apr 2011 17:39:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Wesley Eddy References: <0C53DCFB700D144284A584F54711EC580C6C459C@xmb-sjc-21c.amer.cisco.com> <4DA4D6A3.1010706@isi.edu> <4DA4E9C9.60502@mti-systems.com> In-Reply-To: <4DA4E9C9.60502@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p3D0dQQV011054 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 00:39:55 -0000 Hi, Wes, On 4/12/2011 5:09 PM, Wesley Eddy wrote: ... >> - extra space is useful only if it exists in the SYN, however; that's >> where space is at a real premium > > I disagree; there's definitely utility beyond just having this > capability in the SYN, some of this was defined in the LO/SLO draft > linked to below. If there is, it's a lot easier to do as a single mod. ... >> There were several mechanisms, some of which attempted to use data in >> the SYN (which corrupts the data path if not supported), and even one >> that suggested just doubling all the TCP header fields (Mark Allman). > > > The ones I recall are: > - LO/SLO : http://tools.ietf.org/html/draft-eddy-tcp-loo-04 > - DO redefinition : http://tools.ietf.org/html/draft-kohler-tcpm-extopt-00 > - tcpx2 : https://tools.ietf.org/html/draft-allman-tcpx2-hack-00 > > Andrew's LOIC is interesting, and significantly different than these. It's a bit of revisiting tcpx2, and just assumes that the endpoint tries to start two connections at the same time. That's been suggested before, but has problems: - how long do you wait to figure out which connection to accept? - what happens when either attempt's SYN is lost? AFAICT, all variants here end up costing either the legacy or the new variant excessive delays, and that's not going to fly. >> Regardless of need or utility, it is simply not possible in the SYN. > > The SLO option was an attempt to handle that by sending long options > that you would have liked to be on the SYN later (i.e. on the ACK > completing the handshake); in implementation, this meant calling the > function in the kernel for processing SYN options on a received packet > even though the packet wasn't a SYN, which was slightly awkward, but > fairly simple. This was discussed on this list back in 2004. The key interfering issue raised then, AFAICT, was intervening middleboxes that transparently rewrite segments. I'm not sure whether that's still an issue, or whether other issues were raised, but let's recall that thread before exploring this as if we haven't discussed it before ;-) >> So basically: >> - we can trivially add space after a SYN exchange; it that's useful, >> let's do it > > The LO option is one way to handle that: > http://tools.ietf.org/html/draft-eddy-tcp-loo-04 Sure - but that would need to be factored out as a separate thing if deemed useful. Joe From mallman@icir.org Tue Apr 12 19:17:25 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A9418E071F for ; Tue, 12 Apr 2011 19:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IJYQGTGigfO for ; Tue, 12 Apr 2011 19:17:25 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfc.amsl.com (Postfix) with ESMTP id 0728FE066C for ; Tue, 12 Apr 2011 19:17:24 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p3D2HMrF008198; Tue, 12 Apr 2011 19:17:23 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C1825394FFF7; Tue, 12 Apr 2011 22:17:22 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <4DA4D6A3.1010706@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: The Entertainer MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma1970-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 12 Apr 2011 22:17:22 -0400 Sender: mallman@icir.org Message-Id: <20110413021722.C1825394FFF7@lawyers.icir.org> Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 13 Apr 2011 02:17:25 -0000 ----------ma1970-1 Content-Type: text/plain Content-Disposition: inline > and even > one that suggested just doubling all the TCP header fields (Mark > Allman). > > [...] > > Non-backward compatible solutions to increased SYN space are trivial > too - use a new protocol number. ;-) Note, my proposal did both of these. allman ----------ma1970-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2lB7IACgkQWyrrWs4yIs4AzwCdHzUyOr/QWLKWHt6mOuz8wQcQ gDQAn2jtsD/Yeb/T9IlxP9kLhaZRmR0R =U5eT -----END PGP SIGNATURE----- ----------ma1970-1-- From L.Wood@surrey.ac.uk Wed Apr 13 02:32:56 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 742A8E0689 for ; Wed, 13 Apr 2011 02:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6cFlhpoh2GS for ; Wed, 13 Apr 2011 02:32:55 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by ietfc.amsl.com (Postfix) with ESMTP id 245C5E0684 for ; Wed, 13 Apr 2011 02:32:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-14.tower-72.messagelabs.com!1302687173!26108180!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.39] Received: (qmail 28410 invoked from network); 13 Apr 2011 09:32:53 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-14.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 13 Apr 2011 09:32:53 -0000 Received: from EXMB01CMS.surrey.ac.uk ([10.60.0.2]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Wed, 13 Apr 2011 10:32:54 +0100 From: To: , Date: Wed, 13 Apr 2011 10:32:52 +0100 Thread-Topic: [tcpm] Extending the TCP option space - yet another approach Thread-Index: Acv5Zkmvh4RJlmXLSVeOrENqMv8SAgAVnaxw Message-ID: References: <0C53DCFB700D144284A584F54711EC580C6C459C@xmb-sjc-21c.amer.cisco.com> <4DA4D6A3.1010706@isi.edu> <4DA4DAE6.5030200@isi.edu> In-Reply-To: <4DA4DAE6.5030200@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 09:32:56 -0000 =20 > FWIW, I'd be glad to write up the problem and why a solution=20 > cannot exist, so we can stop going around this block ;-) Please do. It will be interesting to compare that to all the different proposals for doing increased option space. (Increasing available option space for SACK use can increase TCP's performance in unusual environments - paths with high bw*delay products. But since performance can be increased further in those environments by simply using something else other than TCP, that's arguably a moot point.) L. http://sat-net.com/L.Wood= From mallman@icir.org Wed Apr 13 05:38:56 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 83319E0757 for ; Wed, 13 Apr 2011 05:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22wDwHMCo8Jn for ; Wed, 13 Apr 2011 05:38:55 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfc.amsl.com (Postfix) with ESMTP id 94B72E06FE for ; Wed, 13 Apr 2011 05:38:55 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p3DCcr0Q003070; Wed, 13 Apr 2011 05:38:53 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5CBCF3964F24; Wed, 13 Apr 2011 08:38:53 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <4DA4F0BD.9040901@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Pink Houses MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma39259-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 13 Apr 2011 08:38:53 -0400 Sender: mallman@icir.org Message-Id: <20110413123853.5CBCF3964F24@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 13 Apr 2011 12:38:56 -0000 ----------ma39259-1 Content-Type: text/plain Content-Disposition: inline > It's a bit of revisiting tcpx2, and just assumes that the endpoint > tries to start two connections at the same time. That's been > suggested before, but has problems: > > - how long do you wait to figure out which connection to accept? > - what happens when either attempt's SYN is lost? > > AFAICT, all variants here end up costing either the legacy or the > new variant excessive delays, and that's not going to fly. I don't think this is entirely true if one keeps a little history. Appended is a table and some text I sent several weeks ago in the context of the fast open proposal. It shows that the lions share of connections over the course of a day were between IPs that had a previous connection. Further, if you fire two SYNs and act on the first SYN+ACK you add no delay. o If that SYN+ACK is for the new thing, great. We win and we move along. o If that SYN+ACK is old-style then we perhaps progress without some new fangled TCP item. But, we can still observe a new style SYN+ACK if it comes along and record that it did show up for future usage. That doesn't add delay and the cost is something you have to be willing to do anyway: operate without the new wrinkle. Of course, one of the key aspects the above discussion and the data below doesn't touch on is multiple points of attachment. I.e., just because I know that sitting here in my office I can get some TCP-new through to host X doesn't mean I will be able to do so when I go to campus. So, certainly there will need to be some re-learning and depending on mobility patterns that may or may not be a pain. (Note: the information that I can get TCP-new to host X from my office is not for nothing on campus. That at least says host X is cool with it.) Further, paths change, middleboxes change, etc. and so you'd need some robust fallback mechanism (e.g., because even though you "know" something from previous history it doesn't work anymore) and that may well add delay. My point is that with a bit of work we can likely make added delay (a) the exception and (b) not all that big. allman Well, I grabbed a connection log from yesterday for a monitoring point that watches a fiber-to-the-home setup that serves 100 houses in Cleveland, OH to test this out. (Nothing magic here ... it just happened to be handy data.) For each outgoing TCP connection I looked at whether there was a previous connection from the current source host to the current destination host within the last [threshold] seconds. The results for various thresholds: 30sec 60sec 120sec 180sec 240sec Inf ----------------------------------------------------------------------------- Total 15.3M 15.3M 15.3M 15.3M 15.3M 15.3M Prev 5.1M 6.1M 7.2M 7.8M 8.2M 15.1M NoPrev 10.1M 9.2M 8.1M 7.4M 7.1M 145K (modulo rounding errors; you get the point ...) Where "Prev" means there was a previous connection in the time interval and "NoPrev" means there was no previous connection. The "Inf" column removes the time threshold and just tests whether there was a previous connection or not. The analysis is not perfect. E.g., the same source could be used for a few machines behind a NAT in the given house. But, it gives a general idea. ----------ma39259-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2lmV0ACgkQWyrrWs4yIs5QHgCgg8Xo/pEC8YXIkOLZfgm+DTM8 LQQAoItb7qnlxEFpYN4WtDBonEgmfGBA =41Sy -----END PGP SIGNATURE----- ----------ma39259-1-- From Lennart.Schulte@comsys.rwth-aachen.de Wed Apr 13 03:44:30 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 96F56E06D5 for ; Wed, 13 Apr 2011 03:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJgsHdXjbHj8 for ; Wed, 13 Apr 2011 03:44:30 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfc.amsl.com (Postfix) with ESMTP id E3506E06C2 for ; Wed, 13 Apr 2011 03:44:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=UTF-8 Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LJL008FG76470I0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 13 Apr 2011 12:44:28 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.64,203,1301868000"; d="scan'208";a="52749133" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 13 Apr 2011 12:44:28 +0200 Received: from [192.168.0.100] ([unknown] [95.222.130.29]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LJL0039M75SUD90@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 13 Apr 2011 12:44:28 +0200 (CEST) Message-id: <4DA57E7D.6040206@comsys.rwth-aachen.de> Date: Wed, 13 Apr 2011 12:44:13 +0200 From: Lennart Schulte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 To: mallman@icir.org, eblanton@cs.ohiou.edu X-Enigmail-Version: 1.1.2 X-Mailman-Approved-At: Wed, 13 Apr 2011 08:16:38 -0700 Cc: tcpm@ietf.org Subject: [tcpm] FlightSizePrev in TCP-NCR X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:45:33 -0000 Hi folks, we are currently implementing TCP-NCR in Linux. Consider the following scenario: The connection experiences a lot of reordering and all segments carry SACK information, even those which advance the cumulative ACK point. However loss recovery is never entered (reordering extent < dupthresh). RFC5681 allows an increase of CWND for every ACK that advances the cumulative ACK point, even if this ACK carries SACK information, so CWND will grow during the connection's lifetime. In contrast TCP-NCR calculates the number of segments to sent during Extended Limited Transmit with FlightSizePrev (E.2). Also, if an ACK arrives that advances the cumulative ACK point and also carries SACK information, it sets the CWND to no more than FlightSizePrev (T.1). Since FlightSizePrev is held constant for such an ACK and is not set again (T.4), the CWND is not allowed to increase during the whole connection when there is no ACK that does not carry any SACK information. With this behavior the throughput will stay very low. My questions are: 1) Why FlightSizePrev is used in E.2? 2) Why FlightSizePrev is not recalculated in T.4? Thanks, Lennart From touch@isi.edu Wed Apr 13 08:22:09 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 37177E077D for ; Wed, 13 Apr 2011 08:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhZWo-g0oIhM for ; Wed, 13 Apr 2011 08:22:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfc.amsl.com (Postfix) with ESMTP id 86A89E0704 for ; Wed, 13 Apr 2011 08:22:08 -0700 (PDT) Received: from [10.133.205.207] (UAPublic-35.guest.arizona.edu [206.207.225.35]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p3DFLGQE013591 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 13 Apr 2011 08:21:26 -0700 (PDT) Message-ID: <4DA5BF6C.9060504@isi.edu> Date: Wed, 13 Apr 2011 08:21:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: mallman@icir.org References: <20110413123853.5CBCF3964F24@lawyers.icir.org> In-Reply-To: <20110413123853.5CBCF3964F24@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:22:09 -0000 Hi, Mark, On 4/13/2011 5:38 AM, Mark Allman wrote: > >> It's a bit of revisiting tcpx2, and just assumes that the endpoint >> tries to start two connections at the same time. That's been >> suggested before, but has problems: >> >> - how long do you wait to figure out which connection to accept? >> - what happens when either attempt's SYN is lost? >> >> AFAICT, all variants here end up costing either the legacy or the >> new variant excessive delays, and that's not going to fly. > > I don't think this is entirely true if one keeps a little history. > Appended is a table and some text I sent several weeks ago in the > context of the fast open proposal. It shows that the lions share of > connections over the course of a day were between IPs that had a > previous connection. Although that may be true, increased address sharing means that IP addresses aren't the whole story. History cannot be used to affect future connections without verification, and that verification needs to happen during the SYN, so you can't *use* extended options in the SYN regardless. > Further, if you fire two SYNs and act on the first SYN+ACK you add no > delay. > > o If that SYN+ACK is for the new thing, great. We win and we move > along. > > o If that SYN+ACK is old-style then we perhaps progress without some > new fangled TCP item. But, we can still observe a new style SYN+ACK > if it comes along and record that it did show up for future usage. The problem is that TCP is designed to respond to options it doesn't know by ignoring them. If the SYN that arrives first is the one with the long options, you need to ensure that the long options aren't misinterpreted. That's always been the challenge. The current proposal gets around this by using phantom data (e.g., "2") to change the checksum. However, there are devices that repack things that might just recalculate the checksum rather than checking it first. Further, let's say we send SYN with incompatible long options with phantom data (+2 checksum), and there's an error that makes the resulting checksum OK. That SYN could then be accepted and acted on by an endpoint that doesn't support the option. I'm concerned about weakening TCP's robustness this way. Joe From ayourtch@gmail.com Wed Apr 13 09:17:27 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C3BCFE081C for ; Wed, 13 Apr 2011 09:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMS9-7ioufEr for ; Wed, 13 Apr 2011 09:17:26 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 5B7B2E082A for ; Wed, 13 Apr 2011 09:17:26 -0700 (PDT) Received: by iwn39 with SMTP id 39so920325iwn.31 for ; Wed, 13 Apr 2011 09:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uOBuRHlsuBEwLtMvNUnFYUXfy17lC9sSU5b+F89XzU0=; b=VUGe26hQMTXVj7+w4GJkVNOwLc31K7m/NZ69NmMw1FlvL3rFwQKGA4Y1Xy80J7k2vb JbzpqmNtOFxTGMpwhrVpVZUQGyQrvpwFdjbsbcEwAkr/ihfwCQZljjrdsDnjd3ivZQNT 1Lh9HiciCfsF8BUeI/DiaSn4P1unGjgT5JaRE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wN8eryY+d/inavn3xBAhAzcLEmrtTdnVsZ9tA3VeG9bZJ4vjgkqt62xHokbchNT4QK l/VJbZEecJtlSy9X1NvjTqnHag9jOYrkZADTuHN3e+t4wbnMuNWiCHVGdOvIubOhKutn fbvbCc1BYDUKVJDvrinZmvbW4oKJvqK8iBASI= MIME-Version: 1.0 Received: by 10.42.146.196 with SMTP id k4mr12543615icv.105.1302711440616; Wed, 13 Apr 2011 09:17:20 -0700 (PDT) Received: by 10.42.144.132 with HTTP; Wed, 13 Apr 2011 09:17:20 -0700 (PDT) In-Reply-To: <20110413123853.5CBCF3964F24@lawyers.icir.org> References: <4DA4F0BD.9040901@isi.edu> <20110413123853.5CBCF3964F24@lawyers.icir.org> Date: Wed, 13 Apr 2011 18:17:20 +0200 Message-ID: From: Andrew Yourtchenko To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] Extending the TCP option space - yet another approach X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:17:28 -0000 On Wed, Apr 13, 2011 at 2:38 PM, Mark Allman wrote: > >> It's a bit of revisiting tcpx2, and just assumes that the endpoint >> tries to start two connections at the same time. That's been >> suggested before, but has problems: >> >> =A0 =A0 =A0 - how long do you wait to figure out which connection to acc= ept? >> =A0 =A0 =A0 - what happens when either attempt's SYN is lost? >> >> AFAICT, all variants here end up costing either the legacy or the >> new variant excessive delays, and that's not going to fly. > > I don't think this is entirely true if one keeps a little history. > Appended is a table and some text I sent several weeks ago in the > context of the fast open proposal. =A0It shows that the lions share of > connections over the course of a day were between IPs that had a > previous connection. > > Further, if you fire two SYNs and act on the first SYN+ACK you add no > delay. > > =A0o If that SYN+ACK is for the new thing, great. =A0We win and we move > =A0 =A0along. > > =A0o If that SYN+ACK is old-style then we perhaps progress without some > =A0 =A0new fangled TCP item. =A0But, we can still observe a new style SYN= +ACK > =A0 =A0if it comes along and record that it did show up for future usage. > > That doesn't add delay and the cost is something you have to be willing > to do anyway: operate without the new wrinkle. Precisely. However, I thought we need to also account potential path asymmetry. This makes for the competing threeway handshakes (and needs further thinking, that's why I excluded it in my writeup). Maybe I'm overthinking it though. > > Of course, one of the key aspects the above discussion and the data > below doesn't touch on is multiple points of attachment. =A0I.e., just > because I know that sitting here in my office I can get some TCP-new > through to host X doesn't mean I will be able to do so when I go to > campus. =A0So, certainly there will need to be some re-learning and > depending on mobility patterns that may or may not be a pain. =A0(Note: > the information that I can get TCP-new to host X from my office is not > for nothing on campus. =A0That at least says host X is cool with it.) > Further, paths change, middleboxes change, etc. and so you'd need some > robust fallback mechanism (e.g., because even though you "know" > something from previous history it doesn't work anymore) and that may > well add delay. =A0My point is that with a bit of work we can likely make > added delay (a) the exception and (b) not all that big. I think memoizing the behavior should happen together with some kind of ephemeral "host identification" - due to NATs, as Joe mentions. In that light fast open + extending the TCP option space (by whatever method) would make a pretty happy couple. Long options by themselves are just plumbing. But if they have the fast open use case glued to them, that's a killer app to push it forward. cheers, andrew > > allman > > > > > > > > > Well, I grabbed a connection log from yesterday for a monitoring point > that watches a fiber-to-the-home setup that serves 100 houses in > Cleveland, OH to test this out. =A0(Nothing magic here ... it just > happened to be handy data.) =A0For each outgoing TCP connection I looked > at whether there was a previous connection from the current source host > to the current destination host within the last [threshold] seconds. > The results for various thresholds: > > =A0 =A0 =A0 =A0 =A0 =A030sec =A0 =A0 =A060sec =A0 =A0 =A0120sec =A0 =A0 = =A0180sec =A0 =A0 =A0240sec =A0 =A0 =A0Inf > -------------------------------------------------------------------------= ---- > Total =A0 =A0 =A0 15.3M =A0 =A0 =A015.3M =A0 =A0 =A015.3M =A0 =A0 =A0 15.= 3M =A0 =A0 =A0 15.3M =A0 =A0 =A0 15.3M > Prev =A0 =A0 =A0 =A0 5.1M =A0 =A0 =A0 6.1M =A0 =A0 =A0 7.2M =A0 =A0 =A0 = =A07.8M =A0 =A0 =A0 =A08.2M =A0 =A0 =A0 15.1M > NoPrev =A0 =A0 =A010.1M =A0 =A0 =A0 9.2M =A0 =A0 =A0 8.1M =A0 =A0 =A0 =A0= 7.4M =A0 =A0 =A0 =A07.1M =A0 =A0 =A0 =A0145K > > (modulo rounding errors; you get the point ...) > > Where "Prev" means there was a previous connection in the time interval > and "NoPrev" means there was no previous connection. =A0The "Inf" column > removes the time threshold and just tests whether there was a previous > connection or not. =A0The analysis is not perfect. =A0E.g., the same sour= ce > could be used for a few machines behind a NAT in the given house. =A0But, > it gives a general idea. > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From eblanton@cs.ohiou.edu Wed Apr 13 11:24:53 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C4BF8E06EA for ; Wed, 13 Apr 2011 11:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+f3egbyIG0Q for ; Wed, 13 Apr 2011 11:24:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 994E0E0665 for ; Wed, 13 Apr 2011 11:24:51 -0700 (PDT) Received: from 99-52-196-7.lightspeed.crmlin.sbcglobal.net ([99.52.196.7] helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QA4kE-000DNI-3s for tcpm@ietf.org; Wed, 13 Apr 2011 18:24:50 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id 421A73BFDC; Wed, 13 Apr 2011 14:24:49 -0400 (EDT) Date: Wed, 13 Apr 2011 14:24:49 -0400 From: Ethan Blanton To: tcpm@ietf.org Message-ID: <20110413182449.GA4240@colt> Mail-Followup-To: tcpm@ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline X-GnuPG-Fingerprint: CB44 99AC EDDA D1AB D6E6 A2CA FF1F 8B16 771F C72B User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 18:24:53 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, The 3517bis -01 is out, and available here: http://www.ietf.org/id/draft-blanton-tcpm-3517bis-01.txt We believe that we have addressed all of the concerns with -00 in this document, and that it is ready for last call. A quick rundown of the concerns which came up in -00 and their related changes (or the reasoning behind not changing anything) follows. * Matt Mathis brought up a concern with the quoted requirement from RFC 2018 that SACK information MUST be discarded following an RTO. There is an Errata on 2018 (also by Matt) addressing this. We were not comfortable updating 2018 "on the side" as it were, so rather than change the quoted recommendation, we added some text explaining that this issue has been reconsidered, that there is an Errata on the subject, and that implementors should find out what the state of affair is when implementing. Section 5.1 paragraph 1 now reads: In order to avoid memory deadlocks, the TCP receiver is allowed to discard data that has already been selectively acknowledged. As a result, [RFC2018] suggests that a TCP sender SHOULD expunge the SACK information gathered from a receiver upon a retransmission timeout "since the timeout might indicate that the data receiver has reneged." Additionally, a TCP sender MUST "ignore prior SACK information in determining which data to retransmit." However, since the publication of [RFC2018] this has come to be viewed by some as too strong. It has been suggested that, as long as robust tests for reneging are present, an implementation can retain and use SACK information across a timeout event [Errata1610]. While this document does not change the specification in [RFC2018], we note that implementers should consult any updates to [RFC2018] on this subject. Further, a SACK TCP sender SHOULD utilize all SACK information made available during the slow start phase of loss recovery following an RTO. * Richard Scheffenegger brought up an end-of-window loss corner case which RFC 3517 loss recovery does not handle as aggressively as NewReno, potentially leading to RTO. While the problem itself is well-understood, our read of the consensus is that the suggestions put forth to mitigate it are not. Since 3517 is standards track and mature, no changes were made to the document regarding end-of-window losses. * There has been ongoing discussion regarding TCP security in relation to Fernando's draft. One of the bullets in that draft involves a blind out-of-window attack which can cause a sender to mistakenly infer loss in the absence of SACK. A note was added to security considerations to hilight this robustness when DupACKs are properly accounted: Similarly, [CPNI309] sketches a variant of a blind attack [RFC5961] whereby an attacker can spoof out-of-window data to a TCP endpoint, causing it to respond to the legitimate peer with a duplicate cumulative ACK, per [RFC793]. Adding a SACK-based requirement to trigger loss recovery effectively mitigates this attack, as the duplicate ACKs caused by out-of-window segments will not contain SACK information indicating reception of previously un-SACKED in-window data. * The "Changes Relative to RFC 3517" section has been clarified editorially. * Despite the IETF/IESG joint commitment to making submission of I-Ds as painful as possible, we negotiated the boilerplate minefield and updated the text and formatting of the draft *just so* to convince the automated tools to accept it. Thanks, Ethan --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTaXqcf8fixZ3H8crAQiGHQf+IZ72TyNGOMeDbGtZU59BR3JYH82i64uv 7bIFfrmQ8EWCHq/8rJLWQkFCfy7I2z8du9264BQBddjWFc+Ix5e4zbvKp1FUE7tu 7GPpA97HQXZdFRXXRwv/2EhouufXRIfkLciT+T5FmVUFAiPKr4F1ozOVlYfK2IGT sOrOTlzQe21E6X1GiW4m1P5Qoi3Id7bYtWcrA7M1PJVh0LV+d9QQyfYh4AG9NXRR 9c2CRURQxVtc7C+4Z4C+8fHhtnhgitW6pZnXYHe1OV2kQkJt5AwNCDkXY8tARJUv huZINHbbkUIkmMKE1DCv8d4pQyxdZulqhNCu+McQTVJjoi8uNLtSMQ== =XUSw -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From ycheng@google.com Wed Apr 13 12:48:38 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F45EE07CB for ; Wed, 13 Apr 2011 12:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.977 X-Spam-Level: X-Spam-Status: No, score=-107.977 tagged_above=-999 required=5 tests=[AWL=-1.999, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2olLIYPg2mI2 for ; Wed, 13 Apr 2011 12:48:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id 3067EE083D for ; Wed, 13 Apr 2011 12:48:37 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p3DJmZgj020526 for ; Wed, 13 Apr 2011 12:48:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302724116; bh=bqgxJkXXy4vI+sny+qovHAB1Vok=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=fSFK6eyfos0SLVCUXe8Tc/udomogFSvQx0abLPGjPs8caVWDRics462gxxju+z5h8 zx1+bPoErkS3gu7Sew8ZQ== Received: from gxk8 (gxk8.prod.google.com [10.202.11.8]) by kpbe20.cbf.corp.google.com with ESMTP id p3DJlXo8018621 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 13 Apr 2011 12:48:34 -0700 Received: by gxk8 with SMTP id 8so515407gxk.23 for ; Wed, 13 Apr 2011 12:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=xDfA+0JVx6gxirKlEE4ww9CLpiZ8Eu9u5BWy0AJEyIs=; b=Ezr71Sak1Zy9mVoZjvXVW7D/3+3qRuwUMeOLsItX3kHilVn6d47ZPj6bWOuFIrt+L0 H5+PTsfObNcOe/MI+0fQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=xAArSj7PTI4/UomI4c3ovaSAv7f5dteGqNgXUVI1CGNJM0Y40Wo1BeA5PsPFp3DzgJ Y/SkhKVGKGv7x1wYXVqw== Received: by 10.150.182.12 with SMTP id e12mr824994ybf.389.1302724114122; Wed, 13 Apr 2011 12:48:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.109.8 with HTTP; Wed, 13 Apr 2011 12:48:14 -0700 (PDT) In-Reply-To: <20110413182449.GA4240@colt> References: <20110413182449.GA4240@colt> From: Yuchung Cheng Date: Wed, 13 Apr 2011 12:48:14 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:48:38 -0000 Hi Ethan, I have two questions: 1) IsLost (SeqNum): This routine returns whether the given sequence number is considered to be lost. The routine returns true when either DupThresh discontiguous SACKed sequences have arrived above 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence numbers greater than 'SeqNum' have been SACKed. Otherwise, the routine returns false. Does RFC require DupThresh discontinuous sack blocks? e.g., For example, if a sender sends 4 data packets send pkt1: 1-100 send pkt2: 101-200 send pkt3: 201-300 send pkt4: 301-400 receive ack: ack1 with one sack block 101-400. does IsLost(1) returns true? 2) If the incoming ACK is a duplicate acknowledgment and the TCP is not currently in loss recovery, the TCP MUST increase DupAcks by one and take the following steps: (1) If DupAcks >= DupThresh, go to step (4). (2) If DupAcks < DupThresh but IsLost (SND.UNA) returns true---indicating at least three segments have arrived above the current cumulative acknowledgment point, which is taken to indicate loss---go to step (4). can we combine (1) and (2)? go to steps (4) if IsLost(SND.UNA) is true. I guess it depends on your answer of my first question. Thanks, Yuchung From mallman@icir.org Wed Apr 13 12:59:24 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 17706E084E for ; Wed, 13 Apr 2011 12:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.47 X-Spam-Level: X-Spam-Status: No, score=-106.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PR4x2U2Pq0HL for ; Wed, 13 Apr 2011 12:59:21 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfc.amsl.com (Postfix) with ESMTP id DA14AE06BC for ; Wed, 13 Apr 2011 12:59:20 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p3DJxHSb025350; Wed, 13 Apr 2011 12:59:17 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 539A73970266; Wed, 13 Apr 2011 15:59:17 -0400 (EDT) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Pink Houses MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma147-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 13 Apr 2011 15:59:17 -0400 Sender: mallman@icir.org Message-Id: <20110413195917.539A73970266@lawyers.icir.org> Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 13 Apr 2011 19:59:24 -0000 ----------ma147-1 Content-Type: text/plain Content-Disposition: inline > 1) IsLost (SeqNum): > > This routine returns whether the given sequence number is > considered to be lost. The routine returns true when either > DupThresh discontiguous SACKed sequences have arrived above > 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence > numbers greater than 'SeqNum' have been SACKed. Otherwise, the > routine returns false. > > Does RFC require DupThresh discontinuous sack blocks? e.g., > For example, if a sender sends 4 data packets > send pkt1: 1-100 > send pkt2: 101-200 > send pkt3: 201-300 > send pkt4: 301-400 > receive ack: ack1 with one sack block 101-400. > does IsLost(1) returns true? Yes. If **EITHER**: - You have DupThresh distinct blocks above 1 (so, e.g., if you continue your example a few more and you collect up SACKs for 101-200, 301-400, 501-500 you'd declare sequence number 1 to be lost), **OR**, - You have (DupThresh-1) * SMSS bytes SACKed in the scoreboard (so, (400-101) > (2 * 100) in the case you present) then you declare the given sequence number to be lost. > 2) > If the incoming ACK is a duplicate acknowledgment and the TCP is > > not currently in loss recovery, the TCP MUST increase DupAcks by > one and take the following steps: > > (1) If DupAcks >= DupThresh, go to step (4). > > (2) If DupAcks < DupThresh but IsLost (SND.UNA) returns > true---indicating at least three segments have arrived above > the current cumulative acknowledgment point, which is taken > to indicate loss---go to step (4). > > can we combine (1) and (2)? go to steps (4) if IsLost(SND.UNA) is > true. I guess it depends on your answer of my first question. My first hit here is that this could indeed be tightened up by just getting rid of DupAcks and consulting IsLost (SND.UNA). If that returns true we enter loss recovery, if not we don't. Do I understand that to be what you're saying? (I do need to go back and look at the context around this bit of the document to make sure that is plausible, I guess.) allman ----------ma147-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2mAJUACgkQWyrrWs4yIs7JMwCfaF0DZU5rKLJqR6w7xKGpeikL cn8AoJrto6AXl0Igd2kXWwZLr9hS3gjA =E3cQ -----END PGP SIGNATURE----- ----------ma147-1-- From ilpo.jarvinen@helsinki.fi Wed Apr 13 13:11:05 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E33A3E084E for ; Wed, 13 Apr 2011 13:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4MyFJrQQvAs for ; Wed, 13 Apr 2011 13:11:05 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4AF9FE06BC for ; Wed, 13 Apr 2011 13:11:05 -0700 (PDT) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 13 Apr 2011 23:11:03 +0300 id 00093E59.4DA60357.00005E3C Date: Wed, 13 Apr 2011 23:11:03 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: Mark Allman In-Reply-To: <20110413195917.539A73970266@lawyers.icir.org> Message-ID: References: <20110413195917.539A73970266@lawyers.icir.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 20:11:06 -0000 On Wed, 13 Apr 2011, Mark Allman wrote: > > 2) > > If the incoming ACK is a duplicate acknowledgment and the TCP is > > > > not currently in loss recovery, the TCP MUST increase DupAcks by > > one and take the following steps: > > > > (1) If DupAcks >= DupThresh, go to step (4). > > > > (2) If DupAcks < DupThresh but IsLost (SND.UNA) returns > > true---indicating at least three segments have arrived above > > the current cumulative acknowledgment point, which is taken > > to indicate loss---go to step (4). > > > > can we combine (1) and (2)? go to steps (4) if IsLost(SND.UNA) is > > true. I guess it depends on your answer of my first question. > > My first hit here is that this could indeed be tightened up by just > getting rid of DupAcks and consulting IsLost (SND.UNA). If that returns > true we enter loss recovery, if not we don't. Do I understand that to > be what you're saying? ...I see, now we're back in discussing what this DupAcks counter is for, right? It was added in sack-recovery-entry ID and had proper explation of its purpose there in place. The DupAcks counter is to handle case where the sender is sending smaller than SMSS sized segments. ...Perhaps it would be useful to explain it like the sack-recovery-entry did because otherwise this will just keep confusing people? -- i. From eblanton@cs.ohiou.edu Wed Apr 13 13:13:18 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 96D2CE0802 for ; Wed, 13 Apr 2011 13:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vpy0W5LjfPV for ; Wed, 13 Apr 2011 13:13:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id CF7B5E06BC for ; Wed, 13 Apr 2011 13:13:17 -0700 (PDT) Received: from 99-52-196-7.lightspeed.crmlin.sbcglobal.net ([99.52.196.7] helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QA6RA-000LmQ-Eo; Wed, 13 Apr 2011 20:13:16 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id B42DD3BFDC; Wed, 13 Apr 2011 16:13:15 -0400 (EDT) Date: Wed, 13 Apr 2011 16:13:15 -0400 From: Ethan Blanton To: Yuchung Cheng Message-ID: <20110413201315.GC4240@colt> Mail-Followup-To: Yuchung Cheng , "tcpm@ietf.org Extensions" References: <20110413182449.GA4240@colt> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wULyF7TL5taEdwHz" Content-Disposition: inline In-Reply-To: X-GnuPG-Fingerprint: CB44 99AC EDDA D1AB D6E6 A2CA FF1F 8B16 771F C72B User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 20:13:18 -0000 --wULyF7TL5taEdwHz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yuchung Cheng spake unto us the following wisdom: > I have two questions: >=20 > 1) IsLost (SeqNum): >=20 > This routine returns whether the given sequence number is > considered to be lost. The routine returns true when either > DupThresh discontiguous SACKed sequences have arrived above > 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence > numbers greater than 'SeqNum' have been SACKed. Otherwise, the > routine returns false. >=20 > Does RFC require DupThresh discontinuous sack blocks? e.g., > For example, if a sender sends 4 data packets > send pkt1: 1-100 > send pkt2: 101-200 > send pkt3: 201-300 > send pkt4: 301-400 > receive ack: ack1 with one sack block 101-400. > does IsLost(1) returns true? Let me clerify this a bit. Are you positing this when SMSS >> 100 bytes? If so, then the answer is "maybe". The draft is written in the context of a TCP which does not keep track of segments. If, in this case, SMSS >> 100 bytes, then IsLost(1) will return false for a pure byte-counting TCP. Note from Section 3: Finally, note that the algorithm in this document assumes a sender that is not keeping track of segment boundaries after transmitting a segment. It is possible that a sender that did keep this extra state may be able to use a more refined and precise algorithm than the one presented herein, however, we leave this as future work. If SMSS =3D=3D 100 bytes, then yes, IsLost(1) will return true. > 2) > If the incoming ACK is a duplicate acknowledgment and the TCP is >=20 > not currently in loss recovery, the TCP MUST increase DupAcks by > one and take the following steps: >=20 > (1) If DupAcks >=3D DupThresh, go to step (4). >=20 > (2) If DupAcks < DupThresh but IsLost (SND.UNA) returns > true---indicating at least three segments have arrived above > the current cumulative acknowledgment point, which is taken > to indicate loss---go to step (4). >=20 > can we combine (1) and (2)? go to steps (4) if IsLost(SND.UNA) is > true. I guess it depends on your answer of my first question. No, not unless you assume a TCP which tracks segments, you assume that all segments are SMSS-sized, or you *always* use Nagle's algorithm. If a TCP is sending segments of size < SMSS, then counting incoming DupAcks allows you to trigger loss recovery when 3 incoming ACKs with new SACK information arrive, regardless of the size of the segments triggering those ACKs. Hope that helps. Ethan --wULyF7TL5taEdwHz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTaYD2/8fixZ3H8crAQgazQf/W0CjlbO5bnIEFJq9syULb/R+bQrF7F+1 8g0VtV23PGoifylU+o6k6hxfyL1k4Q4uCpm/DgZEW6aYwo1CBOhTKYhhdAEqDwMK m5MRDpt2ZBmULZ8A8NaflrO0mSfLmsRuFcEpXrJm0mQNbIvK65ls2koNcxJ3Zyjl 2LsjT5iEzyi7/fBQNPe/AhwInR54ft4kFqZ+rp8AeAffts95xSRm6w4mXQbM18dQ urughzVo+dDM+NLO2TxsoeiUomEjRTfRmCfVQ4gx07iMYrLR3aThfniSIMHb0RlB 62E/4wLV+mQ/t97D2CgIFkmzp5VAeRCTFnEMg264xXl3hsOGtA+asQ== =g9zx -----END PGP SIGNATURE----- --wULyF7TL5taEdwHz-- From mallman@icir.org Wed Apr 13 13:42:42 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7AB7BE0848 for ; Wed, 13 Apr 2011 13:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.337 X-Spam-Level: X-Spam-Status: No, score=-106.337 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GNE46nYZBuS for ; Wed, 13 Apr 2011 13:42:42 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfc.amsl.com (Postfix) with ESMTP id CB01FE05F5 for ; Wed, 13 Apr 2011 13:42:41 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p3DKgU0h000207; Wed, 13 Apr 2011 13:42:30 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 695F539907D3; Wed, 13 Apr 2011 16:42:30 -0400 (EDT) To: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Pink Houses MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma2742-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 13 Apr 2011 16:42:30 -0400 Sender: mallman@icir.org Message-Id: <20110413204230.695F539907D3@lawyers.icir.org> Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 13 Apr 2011 20:42:42 -0000 ----------ma2742-1 Content-Type: text/plain Content-Disposition: inline > ...I see, now we're back in discussing what this DupAcks counter is > for, right? It was added in sack-recovery-entry ID and had proper > explation of its purpose there in place. The DupAcks counter is to handle > case where the sender is sending smaller than SMSS sized segments. > ...Perhaps it would be useful to explain it like the sack-recovery-entry > did because otherwise this will just keep confusing people? Thanks for the reminder... Ethan also noted that this is for the small packet case. I forgot about that. Why don't we just add a quick note to the document after the (1) test. I.e., something like ... (1) If DupAcks >= DupThresh, go to step (4). Note: This check covers the case when a TCP is not sending full-sized packets and therefore IsLost() (next step) may be hard-pressed to declare a segment as lost. allman ----------ma2742-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2mCrYACgkQWyrrWs4yIs5fSgCfbyW5kdh1DPwWuoMfCXRqQ2hz ShQAnjIoawDJ8oHJpZu6UYXuqHK0r+yX =JdMP -----END PGP SIGNATURE----- ----------ma2742-1-- From ilpo.jarvinen@helsinki.fi Wed Apr 13 14:52:04 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6278DE0810 for ; Wed, 13 Apr 2011 14:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPNhz93TV2nF for ; Wed, 13 Apr 2011 14:52:03 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfc.amsl.com (Postfix) with ESMTP id B39E5E0809 for ; Wed, 13 Apr 2011 14:52:03 -0700 (PDT) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 14 Apr 2011 00:52:02 +0300 id 00093E4A.4DA61B02.00003CE8 Date: Thu, 14 Apr 2011 00:52:02 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: Mark Allman In-Reply-To: <20110413204230.695F539907D3@lawyers.icir.org> Message-ID: References: <20110413204230.695F539907D3@lawyers.icir.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 21:52:04 -0000 On Wed, 13 Apr 2011, Mark Allman wrote: > > > ...I see, now we're back in discussing what this DupAcks counter is > > for, right? It was added in sack-recovery-entry ID and had proper > > explation of its purpose there in place. The DupAcks counter is to handle > > case where the sender is sending smaller than SMSS sized segments. > > ...Perhaps it would be useful to explain it like the sack-recovery-entry > > did because otherwise this will just keep confusing people? > > Thanks for the reminder... Ethan also noted that this is for the small > packet case. I forgot about that. Why don't we just add a quick note > to the document after the (1) test. I.e., something like ... > > (1) If DupAcks >= DupThresh, go to step (4). > > Note: This check covers the case when a TCP is not sending > full-sized packets and therefore IsLost() (next step) may be packets => segments > hard-pressed to declare a segment as lost. Something simple like that would certainly be useful. -- i. From ycheng@google.com Wed Apr 13 16:56:24 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 685A4E0742 for ; Wed, 13 Apr 2011 16:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCF+NvGsF2e4 for ; Wed, 13 Apr 2011 16:56:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfc.amsl.com (Postfix) with ESMTP id 99961E0679 for ; Wed, 13 Apr 2011 16:56:23 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p3DNuNpJ010799 for ; Wed, 13 Apr 2011 16:56:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302738983; bh=N5JG0ezsuPm9gvz4UeFg+18SEEg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type:Content-Transfer-Encoding; b=oIrG7iAsbqZh/BV9fxGd4shYJfOD6Mb9/s2v7GFoGZzKq+cEHw5ZL6LfuQOHddnoB e9e89Srf9VLIRsUWq2y1A== Received: from gxk9 (gxk9.prod.google.com [10.202.11.9]) by kpbe18.cbf.corp.google.com with ESMTP id p3DNu2sC000404 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 13 Apr 2011 16:56:21 -0700 Received: by gxk9 with SMTP id 9so704841gxk.40 for ; Wed, 13 Apr 2011 16:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=MC2cvUuMePYR/T5NGNfDs/OarRuujzMxgPNLbAO3N+0=; b=S3ZfEtJc5SYTs7tDA9g7UtTqrh41n0j5No+B7vJSpIkdOpRkNFQJEqUyILyAvZQaRD jEY/WXBWPK4DpL8NKg0w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=DbK1KeksnE2Yj02v37zHpzrXOZIBELqwhX916nWi6PdxO8JIcGvlOm1MWPodvM8mSv +sVFV3KK/2q7ii6ZmUVw== Received: by 10.150.171.5 with SMTP id t5mr1120700ybe.332.1302738981310; Wed, 13 Apr 2011 16:56:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.109.8 with HTTP; Wed, 13 Apr 2011 16:56:01 -0700 (PDT) In-Reply-To: <20110413201315.GC4240@colt> References: <20110413182449.GA4240@colt> <20110413201315.GC4240@colt> From: Yuchung Cheng Date: Wed, 13 Apr 2011 16:56:01 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 23:56:24 -0000 Thanks for the clarification. My example assumes SMSS=3D1460 (sorry for not being clear). AFAIK, Linux (even with fack disabled) triggers the fast-recovery when any 3 packets (of any size) are sacked beyond SND.UNA. On Wed, Apr 13, 2011 at 1:13 PM, Ethan Blanton wrot= e: > Yuchung Cheng spake unto us the following wisdom: >> I have two questions: >> >> 1) IsLost (SeqNum): >> >> =A0 =A0 =A0 This routine returns whether the given sequence number is >> =A0 =A0 =A0 considered to be lost. =A0The routine returns true when eith= er >> =A0 =A0 =A0 DupThresh discontiguous SACKed sequences have arrived above >> =A0 =A0 =A0 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequ= ence >> =A0 =A0 =A0 numbers greater than 'SeqNum' have been SACKed. =A0Otherwise= , the >> =A0 =A0 =A0 routine returns false. >> >> Does RFC require DupThresh discontinuous sack blocks? e.g., >> For example, if a sender sends 4 data packets >> send pkt1: 1-100 >> send pkt2: 101-200 >> send pkt3: 201-300 >> send pkt4: 301-400 >> receive ack: ack1 with one sack block 101-400. >> does IsLost(1) returns true? > > Let me clerify this a bit. =A0Are you positing this when SMSS >> 100 > bytes? =A0If so, then the answer is "maybe". =A0The draft is written in > the context of a TCP which does not keep track of segments. =A0 If, in > this case, SMSS >> 100 bytes, then IsLost(1) will return false for a > pure byte-counting TCP. =A0Note from Section 3: > > =A0 Finally, note that the algorithm in this document assumes a > =A0 sender that is not keeping track of segment boundaries after > =A0 transmitting a segment. =A0It is possible that a sender that did > =A0 keep this extra state may be able to use a more refined and > =A0 precise algorithm than the one presented herein, however, we > =A0 leave this as future work. > > If SMSS =3D=3D 100 bytes, then yes, IsLost(1) will return true. > >> 2) >> If the incoming ACK is a duplicate acknowledgment and the TCP is >> >> =A0 =A0not currently in loss recovery, the TCP MUST increase DupAcks by >> =A0 =A0one and take the following steps: >> >> =A0 =A0(1) If DupAcks >=3D DupThresh, go to step (4). >> >> =A0 =A0(2) If DupAcks < DupThresh but IsLost (SND.UNA) returns >> =A0 =A0 =A0 =A0true---indicating at least three segments have arrived ab= ove >> =A0 =A0 =A0 =A0the current cumulative acknowledgment point, which is tak= en >> =A0 =A0 =A0 =A0to indicate loss---go to step (4). >> >> can we combine (1) and (2)? go to steps (4) if IsLost(SND.UNA) is >> true. I guess it depends on your answer of my first question. > > No, not unless you assume a TCP which tracks segments, you assume that > all segments are SMSS-sized, or you *always* use Nagle's algorithm. > If a TCP is sending segments of size < SMSS, then counting incoming > DupAcks allows you to trigger loss recovery when 3 incoming ACKs with > new SACK information arrive, regardless of the size of the segments > triggering those ACKs. > > Hope that helps. > > Ethan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEVAwUBTaYD2/8fixZ3H8crAQgazQf/W0CjlbO5bnIEFJq9syULb/R+bQrF7F+1 > 8g0VtV23PGoifylU+o6k6hxfyL1k4Q4uCpm/DgZEW6aYwo1CBOhTKYhhdAEqDwMK > m5MRDpt2ZBmULZ8A8NaflrO0mSfLmsRuFcEpXrJm0mQNbIvK65ls2koNcxJ3Zyjl > 2LsjT5iEzyi7/fBQNPe/AhwInR54ft4kFqZ+rp8AeAffts95xSRm6w4mXQbM18dQ > urughzVo+dDM+NLO2TxsoeiUomEjRTfRmCfVQ4gx07iMYrLR3aThfniSIMHb0RlB > 62E/4wLV+mQ/t97D2CgIFkmzp5VAeRCTFnEMg264xXl3hsOGtA+asQ=3D=3D > =3Dg9zx > -----END PGP SIGNATURE----- > > From eblanton@cs.ohiou.edu Wed Apr 13 17:17:12 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 526C9E0697 for ; Wed, 13 Apr 2011 17:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Usb-BVKz5axd for ; Wed, 13 Apr 2011 17:17:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id C7A36E0679 for ; Wed, 13 Apr 2011 17:17:11 -0700 (PDT) Received: from 99-52-196-7.lightspeed.crmlin.sbcglobal.net ([99.52.196.7] helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QAAFC-000A8m-8w; Thu, 14 Apr 2011 00:17:10 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id 772C13BFDC; Wed, 13 Apr 2011 20:17:09 -0400 (EDT) Date: Wed, 13 Apr 2011 20:17:09 -0400 From: Ethan Blanton To: Yuchung Cheng Message-ID: <20110414001709.GD4240@colt> Mail-Followup-To: Yuchung Cheng , "tcpm@ietf.org Extensions" References: <20110413182449.GA4240@colt> <20110413201315.GC4240@colt> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ffoCPvUAPMgSXi6H" Content-Disposition: inline In-Reply-To: X-GnuPG-Fingerprint: CB44 99AC EDDA D1AB D6E6 A2CA FF1F 8B16 771F C72B User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 00:17:12 -0000 --ffoCPvUAPMgSXi6H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yuchung Cheng spake unto us the following wisdom: > Thanks for the clarification. My example assumes SMSS=3D1460 (sorry for > not being clear). >=20 > AFAIK, Linux (even with fack disabled) triggers the fast-recovery when > any 3 packets (of any size) are sacked beyond SND.UNA. And this is correct behavior, and what 3517/3517bis will both do. Ethan --ffoCPvUAPMgSXi6H Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTaY9Bf8fixZ3H8crAQiK4wgAoQyvMtlEgeKDGRCs6TQrih+DIwJMiLCW 8dBVrq4y3qgatI68qZ7lon3a/cvnB372/llGZa//xnT7aeM9w++c3tdNUzWBjWNy rx4XYXEUcW2HShKAi/fvIbOatR9eeGyKsCJpJSJV0RhAJqpnH79zf5NF+W9eUUdr Q6Wk6ycNR4hTcL8Ls+keM2N2+UyKFIeorTNmAo3O2wiLpV171EuFdenwefkaA7ha Y+ntOvtwe9xb2bUS8i5w2f2OWrLVnBcvbn+EPmBTYH8nYmD5oWJgPKES7L8O28nF I7tInYp72EK+wmqrf+g1N7ooQCFOZNfw7pWm37WpDnWrRPIDcKudWw== =1xXZ -----END PGP SIGNATURE----- --ffoCPvUAPMgSXi6H-- From ycheng@google.com Wed Apr 13 17:58:19 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C2D15E0750 for ; Wed, 13 Apr 2011 17:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.677 X-Spam-Level: X-Spam-Status: No, score=-106.677 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6IgMNH8VYIf for ; Wed, 13 Apr 2011 17:58:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id 055CEE05F5 for ; Wed, 13 Apr 2011 17:58:18 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p3E0wITx019244 for ; Wed, 13 Apr 2011 17:58:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302742698; bh=DfkB8ksOztNdIAuH4K5o0MAV5fA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=phiqgNrsdMXZspkkN8pPx1C1xicax0dq0tGCsplL2p+gp6x+lm4waJRAR0IYAkKB5 TL386Yj302drlO/L1WUcg== Received: from gxk19 (gxk19.prod.google.com [10.202.11.19]) by hpaq6.eem.corp.google.com with ESMTP id p3E0wGXK024839 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 13 Apr 2011 17:58:17 -0700 Received: by gxk19 with SMTP id 19so615977gxk.31 for ; Wed, 13 Apr 2011 17:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=GpD/S8t4AtzauLo24zNzOmirMB4djYuSThAWmC3Qt2c=; b=R1xe4m5rGGvc3nDNSSDM3BpqpBUwtuMqSvODT8ZspS/oUHc3AdNfiQY6d7G6knikCK WsS7w6DMyVdLNvTAPVxw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=V4zzsigOaPG1sn0K+WAMhkmJHGzVdn0JshH+c7IB+hmImeZNu3JiXn0vu3tjTWnjKr PDjTjN/Eq32EmfbNbaEQ== Received: by 10.151.63.12 with SMTP id q12mr1075346ybk.275.1302742696102; Wed, 13 Apr 2011 17:58:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.109.8 with HTTP; Wed, 13 Apr 2011 17:57:56 -0700 (PDT) In-Reply-To: <20110414001709.GD4240@colt> References: <20110413182449.GA4240@colt> <20110413201315.GC4240@colt> <20110414001709.GD4240@colt> From: Yuchung Cheng Date: Wed, 13 Apr 2011 17:57:56 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 00:58:19 -0000 On Wed, Apr 13, 2011 at 5:17 PM, Ethan Blanton wrote: > Yuchung Cheng spake unto us the following wisdom: >> Thanks for the clarification. My example assumes SMSS=1460 (sorry for >> not being clear). >> >> AFAIK, Linux (even with fack disabled) triggers the fast-recovery when >> any 3 packets (of any size) are sacked beyond SND.UNA. > > And this is correct behavior, and what 3517/3517bis will both do. > Ah that's right. The subtle difference is that Linux IsLost(sn) returns true if any 3 segments beyond sn are sacked, i.e., the seq# of these segments need not be discontinuous. Therefore the loss marking is more aggressive after F-R starts (even with FACK disabled). From alexander.zimmermann@comsys.rwth-aachen.de Wed Apr 13 22:13:21 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 50EBBE081D for ; Wed, 13 Apr 2011 22:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIIJlYlQbVZo for ; Wed, 13 Apr 2011 22:13:19 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by ietfc.amsl.com (Postfix) with ESMTP id 87072E080B for ; Wed, 13 Apr 2011 22:12:06 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LJM007XTMG5F5G0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 14 Apr 2011 07:12:05 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.64,209,1301868000"; d="scan'208";a="106440876" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 14 Apr 2011 07:12:06 +0200 Received: from [192.168.4.16] ([unknown] [77.109.115.140]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LJM00KPGMG4QP30@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Thu, 14 Apr 2011 07:12:05 +0200 (CEST) From: Alexander Zimmermann In-reply-to: Date: Thu, 14 Apr 2011 07:12:03 +0200 Content-transfer-encoding: quoted-printable Message-id: References: <20110413195917.539A73970266@lawyers.icir.org> To: =?utf-8?Q?Ilpo_J=C3=A4rvinen?= X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: Ethan Blanton , "tcpm@ietf.org Extensions" , Mark Allman Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 05:13:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 13.04.2011 um 22:11 schrieb Ilpo J=C3=A4rvinen: > On Wed, 13 Apr 2011, Mark Allman wrote: >=20 >>> 2) >>> If the incoming ACK is a duplicate acknowledgment and the TCP is >>>=20 >>> not currently in loss recovery, the TCP MUST increase DupAcks by >>> one and take the following steps: >>>=20 >>> (1) If DupAcks >=3D DupThresh, go to step (4). >>>=20 >>> (2) If DupAcks < DupThresh but IsLost (SND.UNA) returns >>> true---indicating at least three segments have arrived above >>> the current cumulative acknowledgment point, which is taken >>> to indicate loss---go to step (4). >>>=20 >>> can we combine (1) and (2)? go to steps (4) if IsLost(SND.UNA) is >>> true. I guess it depends on your answer of my first question. >>=20 >> My first hit here is that this could indeed be tightened up by just >> getting rid of DupAcks and consulting IsLost (SND.UNA). If that = returns >> true we enter loss recovery, if not we don't. Do I understand that = to >> be what you're saying? >=20 > ...I see, now we're back in discussing what this DupAcks counter is=20 > for, right? It was added in sack-recovery-entry ID and had proper=20 > explation of its purpose there in place. The DupAcks counter is to = handle=20 > case where the sender is sending smaller than SMSS sized segments.=20 > ...Perhaps it would be useful to explain it like the = sack-recovery-entry=20 > did because otherwise this will just keep confusing people? Yes, please. I really recommend to add section 3.1 of=20 draft-ietf-tcpm-sack-recovery-entry-01.txt to the draft. Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2mgiMACgkQdyiq39b9uS4qBgCeIneNaYUM/nz8df4hJgcp9ZQ+ FFkAoNI7qWbugaH1iX3fRWtE2Th+X24O =3DmwhX -----END PGP SIGNATURE----- From rs@netapp.com Thu Apr 14 01:46:52 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 919BEE0698 for ; Thu, 14 Apr 2011 01:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.395 X-Spam-Level: X-Spam-Status: No, score=-10.395 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzdvzaQnK6QU for ; Thu, 14 Apr 2011 01:46:52 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfc.amsl.com (Postfix) with ESMTP id D265CE066A for ; Thu, 14 Apr 2011 01:46:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,210,1301900400"; d="scan'208";a="250073225" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 14 Apr 2011 01:46:50 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p3E8knEe021989; Thu, 14 Apr 2011 01:46:49 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Apr 2011 09:46:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2011 09:46:26 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0DDF2A05@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20110413204230.695F539907D3@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 Thread-Index: Acv6G1zwIbAgOWpbSR610190WfOh0QAZL91g References: <20110413204230.695F539907D3@lawyers.icir.org> From: "Scheffenegger, Richard" To: , =?iso-8859-1?Q?Ilpo_J=E4rvinen?= X-OriginalArrivalTime: 14 Apr 2011 08:46:49.0528 (UTC) FILETIME=[7E803380:01CBFA80] Cc: tcpm@ietf.org Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 08:46:52 -0000 I'm also in favor of having this note included - a full section like in = draft-ietf-tcpm-sack-recovery-entry may be too much though... Richard Scheffenegger > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org] > Sent: Mittwoch, 13. April 2011 22:43 > To: Ilpo J=E4rvinen > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 >=20 >=20 > > ...I see, now we're back in discussing what this DupAcks counter is > > for, right? It was added in sack-recovery-entry ID and had proper > > explation of its purpose there in place. The DupAcks counter is to > > handle case where the sender is sending smaller than SMSS sized > segments. > > ...Perhaps it would be useful to explain it like the > > sack-recovery-entry did because otherwise this will just keep > confusing people? >=20 > Thanks for the reminder... Ethan also noted that this is for the small > packet case. I forgot about that. Why don't we just add a quick note > to the document after the (1) test. I.e., something like ... >=20 > (1) If DupAcks >=3D DupThresh, go to step (4). >=20 > Note: This check covers the case when a TCP is not sending > full-sized packets and therefore IsLost() (next step) may be > hard-pressed to declare a segment as lost. >=20 > allman >=20 >=20 From kojo@cs.helsinki.fi Thu Apr 14 02:21:14 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 18E1EE0685 for ; Thu, 14 Apr 2011 02:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjaE90UyJDD8 for ; Thu, 14 Apr 2011 02:21:13 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfc.amsl.com (Postfix) with ESMTP id 08BD4E0676 for ; Thu, 14 Apr 2011 02:21:11 -0700 (PDT) Received: from wox-18.cs.helsinki.fi (wox-18.cs.helsinki.fi [128.214.11.68]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 14 Apr 2011 12:21:10 +0300 id 00093E5E.4DA6BC86.00004F67 Received: by wox-18.cs.helsinki.fi (Postfix, from userid 3011) id 181E1358B3; Thu, 14 Apr 2011 12:21:10 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by wox-18.cs.helsinki.fi (Postfix) with ESMTP id 12D59358B2; Thu, 14 Apr 2011 12:21:10 +0300 (EEST) Date: Thu, 14 Apr 2011 12:21:09 +0300 (EEST) From: Markku Kojo To: Yuchung Cheng In-Reply-To: Message-ID: References: <20110413182449.GA4240@colt> <20110413201315.GC4240@colt> <20110414001709.GD4240@colt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 09:21:14 -0000 On Wed, 13 Apr 2011, Yuchung Cheng wrote: > On Wed, Apr 13, 2011 at 5:17 PM, Ethan Blanton wrote: > > Yuchung Cheng spake unto us the following wisdom: > >> Thanks for the clarification. My example assumes SMSS=1460 (sorry for > >> not being clear). > >> > >> AFAIK, Linux (even with fack disabled) triggers the fast-recovery when > >> any 3 packets (of any size) are sacked beyond SND.UNA. > > > > And this is correct behavior, and what 3517/3517bis will both do. > > > Ah that's right. The subtle difference is that Linux IsLost(sn) > returns true if any 3 segments beyond sn are sacked, i.e., the seq# of > these segments need not be discontinuous. Therefore the loss marking > is more aggressive after F-R starts (even with FACK disabled). Right. The difference is that the Linux TCP sender tracks segment boundaries and is therefore able to determine that 3 small segments have made it to the receiver even though these segments are continuous. As Ethan noted the draft is written such that it does not require a TCP sender to keep track of segment boundaries after a segment has been transmitted (Note in Section 3). /Markku From alexander.zimmermann@comsys.rwth-aachen.de Thu Apr 14 03:54:32 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0C981E066A for ; Thu, 14 Apr 2011 03:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.351 X-Spam-Level: X-Spam-Status: No, score=-4.351 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdYSOn+Y8x53 for ; Thu, 14 Apr 2011 03:54:31 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by ietfc.amsl.com (Postfix) with ESMTP id CB9EDE0712 for ; Thu, 14 Apr 2011 03:54:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LJN00C592ATB070@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 14 Apr 2011 12:54:29 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.64,210,1301868000"; d="scan'208";a="106514442" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 14 Apr 2011 12:54:29 +0200 Received: from [192.168.4.16] ([unknown] [77.109.115.140]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LJN000E42ASRU10@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Thu, 14 Apr 2011 12:54:29 +0200 (CEST) From: Alexander Zimmermann In-reply-to: Date: Thu, 14 Apr 2011 12:54:26 +0200 Message-id: References: <20110413182449.GA4240@colt> <20110413201315.GC4240@colt> <20110414001709.GD4240@colt> To: Markku Kojo X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: Ethan Blanton , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 10:54:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 14.04.2011 um 11:21 schrieb Markku Kojo: > On Wed, 13 Apr 2011, Yuchung Cheng wrote: > >> On Wed, Apr 13, 2011 at 5:17 PM, Ethan Blanton wrote: >>> Yuchung Cheng spake unto us the following wisdom: >>>> Thanks for the clarification. My example assumes SMSS=1460 (sorry for >>>> not being clear). >>>> >>>> AFAIK, Linux (even with fack disabled) triggers the fast-recovery when >>>> any 3 packets (of any size) are sacked beyond SND.UNA. >>> >>> And this is correct behavior, and what 3517/3517bis will both do. >>> >> Ah that's right. The subtle difference is that Linux IsLost(sn) >> returns true if any 3 segments beyond sn are sacked, i.e., the seq# of >> these segments need not be discontinuous. Therefore the loss marking >> is more aggressive after F-R starts (even with FACK disabled). > > Right. The difference is that the Linux TCP sender tracks segment > boundaries and is therefore able to determine that 3 small segments > have made it to the receiver even though these segments are continuous. > > As Ethan noted the draft is written such that it does not require > a TCP sender to keep track of segment boundaries after a segment > has been transmitted (Note in Section 3). AFAIK you and Ilpo pointed out in your draft that in a case of a segment-based stack the dupthresh counter is not necessary anymore and we can handle everything with IsLost(). So, I recommend that this should be included in 3517bis (as a big side note or in an appendix section) Alex > > /Markku > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2m0mMACgkQdyiq39b9uS7wkQCfXvF4f1x+22gFWyzztBmblAEw 38wAoIoqofN7pdGGClXBKQsvfiQ1fLj/ =hJQJ -----END PGP SIGNATURE----- From mallman@icir.org Thu Apr 14 05:41:37 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B0A38E072F for ; Thu, 14 Apr 2011 05:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtjooYKuTrGH for ; Thu, 14 Apr 2011 05:41:36 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfc.amsl.com (Postfix) with ESMTP id ACDE1E068E for ; Thu, 14 Apr 2011 05:41:36 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p3ECXdk1025483; Thu, 14 Apr 2011 05:33:39 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A6DE239993D2; Thu, 14 Apr 2011 08:33:39 -0400 (EDT) To: Alexander Zimmermann From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Can't Get Enough MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma59811-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 14 Apr 2011 08:33:39 -0400 Sender: mallman@icir.org Message-Id: <20110414123339.A6DE239993D2@lawyers.icir.org> Cc: Ethan Blanton , "tcpm@ietf.org Extensions" , Markku Kojo Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 14 Apr 2011 12:41:37 -0000 ----------ma59811-1 Content-Type: text/plain Content-Disposition: inline > AFAIK you and Ilpo pointed out in your draft that in a case of a > segment-based stack the dupthresh counter is not necessary anymore and > we can handle everything with IsLost(). So, I recommend that this > should be included in 3517bis (as a big side note or in an appendix > section) We do note in the document ... Finally, note that the algorithm in this document assumes a sender that is not keeping track of segment boundaries after transmitting a segment. It is possible that a sender that did keep this extra state may be able to use a more refined and precise algorithm than the one presented herein, however, we leave this as future work. ... which seems reasonable to me. The document **does not** seek to offer both byte- and packet-based variants. It is perfectly fine for a stack to use a packet-based variant and this document could still form the basis of such a beast. But, such an implementation could likely hone a number of things that are approximations in the current document, or get by without particular counters or whatnot. Tracking packets may in fact be a good tradeoff in some cases. But, it just isn't what this document strives to specify. Some other document can puzzle through a packet-based variant if folks want such a specification. allman ----------ma59811-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2m6aMACgkQWyrrWs4yIs5gUwCgnUzRCNZXovpvchrZKjc/ne+i IBYAoJ0RNXK8jbcoT/V9GYObj6zl/kOi =fxyV -----END PGP SIGNATURE----- ----------ma59811-1-- From alexander.zimmermann@comsys.rwth-aachen.de Thu Apr 14 06:45:38 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AE28CE0748 for ; Thu, 14 Apr 2011 06:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.576 X-Spam-Level: X-Spam-Status: No, score=-4.576 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJUXtLhV7XVL for ; Thu, 14 Apr 2011 06:45:37 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfc.amsl.com (Postfix) with ESMTP id 7374FE06B8 for ; Thu, 14 Apr 2011 06:45:37 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LJN0072SA80NBE0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 14 Apr 2011 15:45:36 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.64,211,1301868000"; d="scan'208";a="106557565" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 14 Apr 2011 15:45:30 +0200 Received: from [192.168.4.16] ([unknown] [77.109.115.140]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LJN000ZVA7TRU50@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Thu, 14 Apr 2011 15:45:30 +0200 (CEST) From: Alexander Zimmermann In-reply-to: <20110414123339.A6DE239993D2@lawyers.icir.org> Date: Thu, 14 Apr 2011 15:45:28 +0200 Message-id: References: <20110414123339.A6DE239993D2@lawyers.icir.org> To: mallman@icir.org X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: Ethan Blanton , "tcpm@ietf.org Extensions" , Markku Kojo Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 13:45:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, Am 14.04.2011 um 14:33 schrieb Mark Allman: > >> AFAIK you and Ilpo pointed out in your draft that in a case of a >> segment-based stack the dupthresh counter is not necessary anymore and >> we can handle everything with IsLost(). So, I recommend that this >> should be included in 3517bis (as a big side note or in an appendix >> section) > > We do note in the document ... > > Finally, note that the algorithm in this document assumes a > sender that is not keeping track of segment boundaries after > transmitting a segment. It is possible that a sender that did > keep this extra state may be able to use a more refined and > precise algorithm than the one presented herein, however, we > leave this as future work. > > ... which seems reasonable to me. For me too. The only thing that I try to say is, that in the current version of the draft, it is hard to understand why we need the dupthresh counter (and can not only rely on IsLost()). If we can add some text from Ilpo back to the main doc, I'm satisfied... Alex > > allman > > > // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2m+nkACgkQdyiq39b9uS69yQCffNmibzbQqQFicr7IH4CpsYYR wbEAni+nX5vCwzLNUB9SAJWUmyUteGyq =cwQi -----END PGP SIGNATURE----- From ilpo.jarvinen@helsinki.fi Thu Apr 14 07:10:55 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1A871E077A for ; Thu, 14 Apr 2011 07:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpH7NA+huxAI for ; Thu, 14 Apr 2011 07:10:53 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfc.amsl.com (Postfix) with ESMTP id 843C9E0760 for ; Thu, 14 Apr 2011 07:10:52 -0700 (PDT) Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 14 Apr 2011 17:10:52 +0300 id 00093E7A.4DA7006C.0000363D Date: Thu, 14 Apr 2011 17:10:51 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi To: Mark Allman In-Reply-To: <20110414123339.A6DE239993D2@lawyers.icir.org> Message-ID: References: <20110414123339.A6DE239993D2@lawyers.icir.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" , Ethan Blanton , Markku Kojo Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:10:55 -0000 On Thu, 14 Apr 2011, Mark Allman wrote: > > > AFAIK you and Ilpo pointed out in your draft that in a case of a > > segment-based stack the dupthresh counter is not necessary anymore and > > we can handle everything with IsLost(). So, I recommend that this > > should be included in 3517bis (as a big side note or in an appendix > > section) > > We do note in the document ... > > Finally, note that the algorithm in this document assumes a > sender that is not keeping track of segment boundaries after > transmitting a segment. It is possible that a sender that did > keep this extra state may be able to use a more refined and > precise algorithm than the one presented herein, however, we > leave this as future work. > > ... which seems reasonable to me. The document **does not** seek to > offer both byte- and packet-based variants. It is perfectly fine for a > stack to use a packet-based variant and this document could still form > the basis of such a beast. But, such an implementation could likely > hone a number of things that are approximations in the current document, > or get by without particular counters or whatnot. Tracking packets may > in fact be a good tradeoff in some cases. I think there are multiple shades of gray there. ...In the one end there's fully packet based algorithm and in the other fully seqno based one. The first one is certainly a problem that isn't even specified outside of recovery fully afaik, and shouldn't be tried here (in 3517bis). But on the middle ground there's such a version where the only the heuristics to detect that dupThresh segments above another are SACKed is replaced with an accurate version (it actually doesn't even have to be a "packet based" implementation although this information is naturally always available in case of packet based implementaion which is why it gets mentioned usually as "if TCP is packet based blah blah..."). Such refined IsLost just does more accurately what the heuristics version of IsLost tried to do. I find it unlikely that there's a can of worms in such refining because then the goal of the original heuristics is just met more often than in the original. Unless there's something flawed in the not-always-met goal of the original heuristics? -- i. From ananth@cisco.com Thu Apr 14 07:21:33 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 99DB1E088D for ; Thu, 14 Apr 2011 07:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSqZUKyztVcj for ; Thu, 14 Apr 2011 07:21:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id BFAC9E0709 for ; Thu, 14 Apr 2011 07:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=1622; q=dns/txt; s=iport; t=1302790892; x=1304000492; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=9VZgmRdrg70l9Jne/EzEHVfIuU6Mz3I8nIfsJhj6vFU=; b=FMGqnILUSfxZof0Gk/9aFXX5svpSa2JlKmE5rvN/GU/AeEApndKaHhUo vsJZkqP9ACd08jmpdyXFW00Ot106Eov7rmc1FUcpTi1nXzboud2VCZBvw BwHwjiwa1OlNEIE8dqC/+eOjZSrwArIRIpQuvhcKv3hMtB0nrMyEaxGR0 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHgBp02rRDoG/2dsb2JhbACldneIb5wNnQGFbgSFWowP X-IronPort-AV: E=Sophos;i="4.64,211,1301875200"; d="scan'208";a="681278827" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2011 14:21:32 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3EELWFl003093; Thu, 14 Apr 2011 14:21:32 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 07:21:32 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2011 07:20:30 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580C782002@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20110414123339.A6DE239993D2@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 Thread-Index: Acv6oVR1616Q60NoThuBs6REoK/xHwACh1AA References: <20110414123339.A6DE239993D2@lawyers.icir.org> From: "Anantha Ramaiah (ananth)" To: , "Alexander Zimmermann" X-OriginalArrivalTime: 14 Apr 2011 14:21:32.0000 (UTC) FILETIME=[40963E00:01CBFAAF] Cc: Ethan Blanton , tcpm@ietf.org, Markku Kojo Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 14:21:33 -0000 >=20 > We do note in the document ... >=20 > Finally, note that the algorithm in this document assumes a > sender that is not keeping track of segment boundaries after > transmitting a segment. It is possible that a sender that did > keep this extra state may be able to use a more refined and > precise algorithm than the one presented herein, however, we > leave this as future work. >=20 > ... which seems reasonable to me. The document **does not** seek to > offer both byte- and packet-based variants. It is perfectly fine for a > stack to use a packet-based variant and this document could still form > the basis of such a beast. But, such an implementation could likely > hone a number of things that are approximations in the current > document, or get by without particular counters or whatnot. Tracking > packets may in fact be a good tradeoff in some cases. But, it just > isn't what this document strives to specify. Some other document can > puzzle through a packet-based variant if folks want such a > specification. I have been passively watching this thread. Just wanted to note that our implementation(s) uses packet based buffering scheme and it comes across handy in many situations including the current case. So, I think that adding text that benefits implementations using packet variants would be really helpful. Coming back to this thread, Between having a separate document that caters to packet based variants versus folding the information into the existing document itself, I would prefer the latter, FWIW. Thanks, -Anantha From mallman@icir.org Thu Apr 14 07:50:13 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0548CE0766 for ; Thu, 14 Apr 2011 07:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEkIco0SX+pU for ; Thu, 14 Apr 2011 07:50:12 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfc.amsl.com (Postfix) with ESMTP id 0F517E0699 for ; Thu, 14 Apr 2011 07:50:11 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p3EEfwiN005329; Thu, 14 Apr 2011 07:41:59 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C2AF0399E1A5; Thu, 14 Apr 2011 10:41:58 -0400 (EDT) To: "Anantha Ramaiah (ananth)" From: Mark Allman In-Reply-To: <0C53DCFB700D144284A584F54711EC580C782002@xmb-sjc-21c.amer.cisco.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Can't Get Enough MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma1974-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 14 Apr 2011 10:41:58 -0400 Sender: mallman@icir.org Message-Id: <20110414144158.C2AF0399E1A5@lawyers.icir.org> Cc: tcpm@ietf.org, Ethan Blanton , Markku Kojo Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 14 Apr 2011 14:50:13 -0000 ----------ma1974-1 Content-Type: text/plain Content-Disposition: inline > I have been passively watching this thread. Just wanted to note that > our implementation(s) uses packet based buffering scheme and it comes > across handy in many situations including the current case. I do not doubt that. > So, I think that adding text that benefits implementations using > packet variants would be really helpful. Coming back to this thread, > Between having a separate document that caters to packet based > variants versus folding the information into the existing document > itself, I would prefer the latter, FWIW. Let me stress that RFC3517 (and the bis) do not somehow strive to be *the* SACK-based recovery algorithm. It is *a* reasonable way to do loss recovery with SACK. We worked very diligently to understand how this algorithm works (and where it doesn't). The bis adds a small piece that makes the scheme more robust. I think it would be a pity to not publish that quite soon (and there have been no objections as far as I can tell to the basic technical merits and/or scheme, but only refinements to the text to make it more understandable). Holding the (as best as I can tell) agreed upon bis up so that we can go back and massage in a variant of the algorithm that leverages understanding of segment boundaries seems imprudent to me given that (a) it will take great care (if our experience with RFC3517 is any indication), (b) we have no idea how hard it will be to get right (we thought the scheme in RFC3517 would be easy, too, and it took us 2.5 years and 14 revisions) and (c) nobody has signed up to do it. So, I would *strongly* prefer we push what we agree to out. And, I *encourage* anyone who has better ideas to pursue those (e.g., as Matt and the Google gang are doing). There needn't be only one. allman ----------ma1974-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2nB7YACgkQWyrrWs4yIs6yUACfVa1rDQ/zLSh75oWQrpMNYY+R zzoAnR44iK7bJs9PsFiJ1k6LlTU+8SJv =W7Jc -----END PGP SIGNATURE----- ----------ma1974-1-- From alexander.zimmermann@comsys.rwth-aachen.de Thu Apr 14 09:31:03 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6C19BE08BF for ; Thu, 14 Apr 2011 09:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GWb+Suvx5ej for ; Thu, 14 Apr 2011 09:31:02 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by ietfc.amsl.com (Postfix) with ESMTP id 69164E0807 for ; Thu, 14 Apr 2011 09:30:59 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LJN00C2PHVM96G0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 14 Apr 2011 18:30:58 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.64,212,1301868000"; d="scan'208";a="52873491" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Thu, 14 Apr 2011 18:30:58 +0200 Received: from [192.168.4.16] ([unknown] [77.109.115.140]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LJN00041HVLRUA0@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Thu, 14 Apr 2011 18:30:58 +0200 (CEST) From: Alexander Zimmermann In-reply-to: <4DA57E7D.6040206@comsys.rwth-aachen.de> Date: Thu, 14 Apr 2011 18:30:56 +0200 Message-id: References: <4DA57E7D.6040206@comsys.rwth-aachen.de> To: Mark Allman X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: Ethan Blanton , "tcpm@ietf.org Extensions" , Lennart Schulte Subject: Re: [tcpm] FlightSizePrev in TCP-NCR X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 16:31:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, Hi Ethan, here is one easy example: Receiver: 2 4 1 6 3 ... Sender: S2 S2,4 A3,S4 S4,6 A5,S6 3517: LT LT Inc LT Inc with S=SACK, A=ACK, LT=Limited Transmit, Inc=CWND increase Am 13.04.2011 um 12:44 schrieb Lennart Schulte: > Hi folks, > > we are currently implementing TCP-NCR in Linux. > > Consider the following scenario: > The connection experiences a lot of reordering and all segments carry > SACK information, even those which advance the cumulative ACK point. > However loss recovery is never entered (reordering extent < dupthresh). > > RFC5681 allows an increase of CWND for every ACK that advances the > cumulative ACK point, even if this ACK carries SACK information, so CWND > will grow during the connection's lifetime. See example above... > > In contrast TCP-NCR calculates the number of segments to sent during > Extended Limited Transmit with FlightSizePrev (E.2). (pipe + Skipped) <= (FlightSizePrev - SMSS) ... and not with CWND (like 3517). Why? => Main question (1) > Also, if an ACK > arrives that advances the cumulative ACK point and also carries SACK > information, it sets the CWND to no more than FlightSizePrev (T.1). > Since FlightSizePrev is held constant for such an ACK and is not set > again (T.4), Copy&Paste (T.4) When an incoming ACK extends the cumulative ACK point and also contains SACK information, the initializations in steps (I.2) and (I.3) from Section 3.1 MUST be taken (but step (I.1) MUST NOT be executed) to re-start Extended Limited Transmit... why "(I.1) MUST NOT be executed"? => Main question (2) > the CWND is not allowed to increase during the whole > connection when there is no ACK that does not carry any SACK > information. With this behavior the throughput will stay very low. In example above, RFC3517 can still increase the CWND according Slow Start or Congestion Avoidance, NCR get stucked. > > My questions are: > 1) Why FlightSizePrev is used in E.2? > 2) Why FlightSizePrev is not recalculated in T.4? > > Thanks, > Lennart // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2nIUEACgkQdyiq39b9uS6bGwCgvCNsSicXQU6U2YZ6jX0iD9SV gL4An1Due/ZmbhiZOJ+ihFW4AqVUFymA =O9Qz -----END PGP SIGNATURE----- From Internet-Drafts@ietf.org Thu Apr 14 18:00:03 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1581CE06BC; Thu, 14 Apr 2011 18:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hpb3wrTM1etc; Thu, 14 Apr 2011 18:00:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 57380E0711; Thu, 14 Apr 2011 18:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110415010002.17515.38504.idtracker@ietfc.amsl.com> Date: Thu, 14 Apr 2011 18:00:02 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-initcwnd-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 01:00:03 -0000 --NextPart 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 : Increasing TCP's Initial Window Author(s) : J. Chu, et al. Filename : draft-ietf-tcpm-initcwnd-01.txt Pages : 20 Date : 2011-04-14 This document proposes an increase in the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without risking congestion collapse. The document closes with a discussion of a list of concerns, and some results from recent studies to address the concerns. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-initcwnd-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-initcwnd-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-14175656.I-D@ietf.org> --NextPart-- From yoshifumi.nishida@gmail.com Fri Apr 15 03:22:41 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 57B36E07D2 for ; Fri, 15 Apr 2011 03:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WVpgUuKDs+J for ; Fri, 15 Apr 2011 03:22:40 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfc.amsl.com (Postfix) with ESMTP id 272BBE07B2 for ; Fri, 15 Apr 2011 03:22:40 -0700 (PDT) Received: by pvh1 with SMTP id 1so1261818pvh.31 for ; Fri, 15 Apr 2011 03:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=9dj9YeseF7paKQqIesigtW9su4F3vo4YpjDME2vCgnE=; b=hFTkFSuMUbez+RLwJ7s9fqZ+CipwPfd26dhDcd+zuBdfNMBkZ6RGVghiCa0Z/n36zk arBoXjzkdXZS/Acm8nCHY1Cz3zz1S2t0tVYX5NxSSWdgq2NJ3y2GKefLr/k772O2/dLP 0XcwP4uLJx1l4LOWHtOfoE1636SpkyYnVL6yA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=IdysnBrX1t6sFGeIvddMJPrBXY67uuxfNju9drBJ0vMbN8Yq1SowFlLr2hO1nM0oO8 6tGC9FnzfgXFKIX3aPfNS2YcwcJlYuTBeqEgdoNA/FZdwK2bZPhjifNmV27WrDXkwYMr 2pLfrzFOQNl5fdLMRm6KourzfpJbMi0ctNrYk= MIME-Version: 1.0 Received: by 10.68.64.229 with SMTP id r5mr1705632pbs.139.1302862959514; Fri, 15 Apr 2011 03:22:39 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.68.57.105 with HTTP; Fri, 15 Apr 2011 03:22:39 -0700 (PDT) In-Reply-To: References: <20110304131713.0283B33BB8C1@lawyers.icir.org> Date: Fri, 15 Apr 2011 03:22:39 -0700 X-Google-Sender-Auth: eICoVm_becUExkgDjrMeaT2MwKg Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org\"" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 10:22:41 -0000 Dear folks, I've submitted an I-D as a solution for the issue we discussed about a month ago. The proposed logic in the doc allows TCP to retransmit one segment per RTT where all available data TCP has is unSACKed and not sure if it is lost. Below is the information of the draft. -------------------------------- Filename: draft-nishida-tcpm-rescue-retransmission Revision: 00 Title: Rescue Retransmission for SACK-based Loss Recovery Algorithm Creation_date: 2011-04-15 WG ID: Independent Submission Number_of_pages: 14 Abstract: This memo describes an issue in the recovery algorithm in RFC3517 and proposes a simple modification to avoid unnecessary timeouts for performance improvement. ------------------- Since it sends just one segment per RTT, I think the amount of spurious retransmissions will be small. Also, I believe the logic is not so complicated while it will be useful to avoid tcp's stalling. The little trick in this logic is sending the highest unsacked segment and expect that the next ACK will convey some useful information. It would be great If you could give some comments on this draft. If I'm misunderstanding something, please let me know. The proposed logic will work something likes this. case: packets 1--10 are transmitted in order, but arrive at the receiver as "2, 3, 4, 1, 5, 6, 7, 8, 9, 10 snd 1--10, cwnd = 10 rcv ack=1, sack={2-2} (via pkt 2) rcv ack=1, sack={2-3} (via pkt 3) rcv ack=1, sack={2-4} (via pkt 4) rexmt 1, cwnd = 5, pipe = 7 rcv ack=5 (via pkt 1-orig), pipe = 6 rcv ack=6 (via pkt 5), pipe = 5 rcv ack=7 (via pkt 6), pipe = 4 rexmt 10, pipe = 5 rcv ack=8 (via pkt 7), pipe = 3 rcv ack=9 (via pkt 8), pipe = 2 case: packet 1,2,3,4,5,6 are transmitted in order. 1,5 6 are lost. rcv ack=1, sack={2-2} (via pkt 2) rcv ack=1, sack={2-3} (via pkt 3) rcv ack=1, sack={2-4} (via pkt 4) rexmt 1, cwnd = 3, pipe = 3 rcv ack=5 (via pkt 1), pipe = 2 rexmt 6, pipe = 1 rcv ack=5 sack={6-6} (via pkt 6) pipe = 2 rexmt 5, pipe = 1 Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From mattmathis@google.com Fri Apr 15 08:37:33 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4DBA5E08D6 for ; Fri, 15 Apr 2011 08:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.377 X-Spam-Level: X-Spam-Status: No, score=-105.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccUW-+zhaByF for ; Fri, 15 Apr 2011 08:37:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id 74630E070B for ; Fri, 15 Apr 2011 08:37:32 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p3FFbV4C021061 for ; Fri, 15 Apr 2011 08:37:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302881851; bh=giQ7ojuHSxxJvDxeoPhzwd071Tw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=lKxBrMzQecwi4NfmrD2YF19sa6IykcQ4T3aqF9gCjdwm+NyDy2uHeKtBqB8makRBv BV7kCBk2/D5OLCmdiSrxw== Received: from eyh5 (eyh5.prod.google.com [10.208.8.5]) by hpaq5.eem.corp.google.com with ESMTP id p3FFbKlF023607 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 15 Apr 2011 08:37:30 -0700 Received: by eyh5 with SMTP id 5so1066015eyh.26 for ; Fri, 15 Apr 2011 08:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=sk4Bul7J/TmASMJx2r55g1KvqOy3VzVwyigZNsqOgqI=; b=He/FvLltRM5nBBIer+IP24zJeFRPNzmhZKxlZ+5l9sIX7RgaTuxCQEIhaZv19JYrx7 8NBCJMzO6WwwLvyqKQBg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=nflMs1QEH4BjLNWZ6hlZcdOuRSJAFcvrywnACFVf06+LnRHwqKuQQ21/LzBNQHMo/a m7s6WHJwvoenL4BfahHQ== MIME-Version: 1.0 Received: by 10.213.16.199 with SMTP id p7mr2966531eba.13.1302881850353; Fri, 15 Apr 2011 08:37:30 -0700 (PDT) Received: by 10.213.104.139 with HTTP; Fri, 15 Apr 2011 08:37:30 -0700 (PDT) In-Reply-To: <20110413182449.GA4240@colt> References: <20110413182449.GA4240@colt> Date: Fri, 15 Apr 2011 11:37:30 -0400 Message-ID: From: Matt Mathis To: TCP Maintenance and Minor Extensions WG Content-Type: multipart/mixed; boundary=0015174bed26dfea7004a0f6d11b X-System-Of-Record: true Subject: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:37:33 -0000 --0015174bed26dfea7004a0f6d11b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would like to suggest an alternate wording for Section 5.1 paragraph 1: To make SACK robust in the presence of unknown implementation bugs and reneging, RFC 2018 indicates that the sender MUST ignore prior SACK information a on a timeout. However, since preserving SACK information on timeouts greatly reduces wasted network capacity under overload conditions, this requirement is probably too strong. Errata1610 amends the MUST to a SHOULD and suggests that as long as there are robust tests for inconsistent SACK information, an implementation might retain and use SACK=A0 information across a timeout. =A0The SACK consistency checks might include snd.una advancing to just before a byte that has been reported in a SACK block, and repeated timeouts or DSACKS. This document does not formally update the specification in [RFC2018], however implementers should consult any updates to [RFC2018] on this subject.=A0 Furthermore, a SACK TCP sender SHOULD utilize all SACK information made available during the slow start phase of loss recovery following an=A0 RTO. (Feel free to make additional adjustments) Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay --0015174bed26dfea7004a0f6d11b Content-Type: application/pgp-signature; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" Content-Transfer-Encoding: base64 X-Attachment-Id: cf3dcbb1af0bfb05_0.0.1 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xMCAoR05V L0xpbnV4KQoKaVFFVkF3VUJUYVhxY2Y4Zml4WjNIOGNyQVFpR0hRZitJWjcyVHlOR09NZURiR3Ra VTU5QlIzSllIODJpNjR1dgo3YklGZnJtUThFV0NIcS84ckpMV1FrRkNmeTdJMno4ZHU5MjY0QlFC ZGRqV0ZjK0l4NWU0emJ2S3AxRlVFN3R1CjdHUHBBOTdIUVhaZEZSWFhSd3YvMkVob3V1ZlhSSWZr TGNpVCtUNUZtVlVGQWlQS3I0RjFvek9WbFlmSzJJR1QKc09yT1RselFlMjFFNlgxR2lXNG0xUDVR b2kzSWQ3Yll0V2NyQTdNMVBKVmgwTFYrZDlRUXlmWWg0QUc5TlhSUgo5YzJDUlVSUXhWdGM3Qys0 WjRDKzhmSGh0bmhnaXRXNnBablhZSGUxT1Yya1FrSnQ1QXdOQ0RrWFk4dEFSSlV2Cmh1WklOSGJi a1VJa21NS0UxREN2OGQ0cFF5eGRadWxxaE5DdStNY1FUVkpqb2k4dU5MdFNNUT09Cj1YVVN3Ci0t LS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --0015174bed26dfea7004a0f6d11b-- From mattmathis@google.com Fri Apr 15 10:25:33 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9052413003B for ; Fri, 15 Apr 2011 10:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1LAy6o+pv6a for ; Fri, 15 Apr 2011 10:25:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id 619BE13002E for ; Fri, 15 Apr 2011 10:25:32 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p3FHPVbS001431 for ; Fri, 15 Apr 2011 10:25:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302888331; bh=PbP/ecE9yy1GhX80wbvU9cXtqqM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=NkhSx++4WdOeVdBbNHhKOHZVTEQ7VgTb8ZS085Zx3uQvMrDKKYtra053Y3kzwxwbQ qHuzzoUvixLN0Q2zxQnag== Received: from eyx24 (eyx24.prod.google.com [10.208.24.24]) by hpaq13.eem.corp.google.com with ESMTP id p3FHP4Ge008250 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 15 Apr 2011 10:25:30 -0700 Received: by eyx24 with SMTP id 24so1062796eyx.5 for ; Fri, 15 Apr 2011 10:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jmB8LNbFDvYRS1cUzcMtYwxnWBB3SAfdvfYMw+77iw4=; b=b+2E3Uv2lKPkg/Iy2SBYszC07tbq9k8Eq8WnzoG2uJgXu8qQZS/8+Bsitb90T0Bz2I w4QwoOOSJJn8jpDi3bAA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lAf4DhYeyNh4gHwFyo2DgTaHDrDtNz9mOwjPwMhsYcpZI04cv58BmUvSVTntCnouhT ELUsi3dQbPf3HBTrSb9A== MIME-Version: 1.0 Received: by 10.213.34.207 with SMTP id m15mr3002604ebd.89.1302888329893; Fri, 15 Apr 2011 10:25:29 -0700 (PDT) Received: by 10.213.104.139 with HTTP; Fri, 15 Apr 2011 10:25:29 -0700 (PDT) In-Reply-To: <20110415155759.C581639DB25D@lawyers.icir.org> References: <20110415155759.C581639DB25D@lawyers.icir.org> Date: Fri, 15 Apr 2011 13:25:29 -0400 Message-ID: From: Matt Mathis To: TCP Maintenance and Minor Extensions WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: mallman@icir.org Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 17:25:33 -0000 (back on tcpm) Well, ok, keep your words. However please at least remove or change the first sentence. Reneging is not really about memory, we only used that as an excuse. We allowed the receivers to renege to force implementers think about and actually test their code with inconsistent SACK updates. At the time there was a strong track record for the following oft repeated ugly scenario: the first implementer has a bug that does not effect self-interoperability, and goes on to capture a significant market share. The second and subsequent implementer do not have the bug and get punished by having interoperability problems. Everybody switches to "implemented but off by default". Several years go by waiting for the deployed bugs to vanish (w/o any market pressure) before the new feature gets turned on.... We wanted to guarantee that SACK could not cause interoperability problems and that the worst case impact of SACK bugs would be reduced performance. The last resort was to use Tahoe style go-back-n timeout behavior. Considering how may truly weird traces that we all have looked at, this worked: as far as I know SACK bugs have never caused connection hangs or aborts. At the time 2018 was in draft there was a lot of pressure to take reneging out. We knew that it implicitly forbid many useful optimizations. It stayed in only because of the robustness argument. Note that if you ever free queued data because it has been SACKed, SACK bugs become fatal. Now that SACK is well established, it might be a feature to have bugs cause interoperability problems. Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay On Fri, Apr 15, 2011 at 11:57 AM, Mark Allman wrote: > > Hi Matt! > > Question: do erratas formally update a spec? =A0I have forgotten. > > In any case, I like our words a lot better than your words. =A0I (1) thin= k > we're more precise in laying out the current state, (2) don't think it > is this document's place to get into reneging detection in any sort of > detail and (3) the detail you do provide in your text is fuzzy and > non-actionable anyway ("eh, you could use DSACKs, perhaps!"). > > What we tried to do is to say 3517bis is not normative on this subject > and so please go look at the current normative stuff and of course use > all SACK information available at all times. =A0That seems enough to me. > Its all a minor point in this document. > > (I hate working .bis documents. =A0Everyone wants something. =A0That said= , > you should update 2018.) > > allman > > > > From narten@us.ibm.com Mon Apr 18 07:48:03 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 45370E07EA for ; Mon, 18 Apr 2011 07:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.951 X-Spam-Level: X-Spam-Status: No, score=-105.951 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMFtT3umGjdv for ; Mon, 18 Apr 2011 07:48:02 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by ietfc.amsl.com (Postfix) with ESMTP id A17A2E07D2 for ; Mon, 18 Apr 2011 07:48:02 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3IERq9R026488 for ; Mon, 18 Apr 2011 10:27:52 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3IEm1JZ2027570 for ; Mon, 18 Apr 2011 10:48:01 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3IElx7q018078 for ; Mon, 18 Apr 2011 10:48:00 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-206-86.mts.ibm.com [9.65.206.86]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3IElxmg018017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Apr 2011 10:47:59 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p3IElwLI025952; Mon, 18 Apr 2011 10:47:58 -0400 Message-Id: <201104181447.p3IElwLI025952@cichlid.raleigh.ibm.com> To: Matt Mathis Date: Mon, 18 Apr 2011 10:47:58 -0400 From: Thomas Narten Cc: tcpm@ietf.org Subject: [tcpm] pmtu discovery (RFC 4821) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 14:48:03 -0000 Hi Matt. What is the status of RFC 4821 uptake? What is the current thinking w.r.t. 4821? Is it still considered the Right Thing to implement? Or have implementation attempts concluded its too complex to implement? Or? The 6man WG is updating the Node Requirements document, and it was suggested that it add a recommendation for 4821. The current RFC (4294) was written before RFC 4821. Thoughts? Thomas From mallman@icir.org Mon Apr 18 11:52:03 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AC34CE0848 for ; Mon, 18 Apr 2011 11:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTeVTmRm8WkN for ; Mon, 18 Apr 2011 11:52:02 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfc.amsl.com (Postfix) with ESMTP id 27894E0715 for ; Mon, 18 Apr 2011 11:52:01 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p3IIpx0u001280; Mon, 18 Apr 2011 11:52:00 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E9AB73A356D8; Mon, 18 Apr 2011 13:50:32 -0400 (EDT) To: Yoshifumi Nishida From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Love Hurts MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma31208-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 18 Apr 2011 13:50:32 -0400 Sender: mallman@icir.org Message-Id: <20110418175032.E9AB73A356D8@lawyers.icir.org> Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 18 Apr 2011 18:52:03 -0000 ----------ma31208-1 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > Filename: draft-nishida-tcpm-rescue-retransmission First, I must say its a nicely clever trick, Yoshifumi. The neat observation is that by sending one segment per loss event you can encourage the information needed to let the standard 3517 algorithm fix end-of-window loss. The basic idea here is that when you're stuck and cannot send anything according to RFC3517 (and the bis) the algorithm is extended to allow sending the last unSACKed packet again. This, in turn, triggers an ACK with new SACK information that can further prod the loss recovery process. (Details are in Yoshifumi's draft). Second, the proposed fix isn't quite right, IMO. Consider the case of sending 6 segments (cwnd=3D6), losing only segment #1 and having no further data to send. So, this is what arrives at and is sent by the data sender: 1. ACK 1, SACK 2:2 [do nothing] 2. ACK 1, SACK 2:3 [do nothing] 3. ACK 1, SACK 2:4 --> cwnd =3D FlightSize / 2 =3D 3, pipe =3D 2 (segs 5 & 6) --> retransmit segment 1, pipe =3D 3 (segs 1(rxt), 5 & 6) 4. ACK 1, SACK 2:5 --> pipe =3D 2 (segs 1(rxt) & 6) --> we have no data judged as having been lost ((1) in NextSeg()) --> we have no new data to send ((2) in NextSeg()) --> we have no "last resort" data to send ((3) in NextSeg()), i.e., unSACKed data not judged as lost, but with SACKed data above it) --> so, we invoke the proposed (4) in NextSeg() and transmit the segment at the end of the window, or segment 6 5. ACK 1, SACK 2:6 6. ACK 7 7. ACK 7, (DSACK 6, if supported) In this case we just don't wait long enough to re-send this rescue packet (step 4 above) and so we really have no idea if the end of the window has been lost or not (and, in the above example it has not and so the retransmit is spurious). In step 4 above we cannot possibly have gained an understanding about the end of the window. =20=20=20 Third, this failure mode is readily fixed by forcing the rescue retransmit to happen an RTT after loss recovery has started (i.e., to ensure all ACKs for the window of data that experienced loss roll in first). This is easy enough. When loss recovery is initiated we set RescueRxt to the highest octet of the first retransmission. Now, rule (4) in NextSeg() =A0 (4) If the conditions for rules (1), (2) and (3) fail, but there =A0 =A0 exists outstanding and unSACKed data we provide the opportunity =A0 =A0 =A0 for a single "rescue" retransmission. =A0If HighACK is greater = than =A0 =A0 =A0 RescueRxt then one segment of up to SMSS octets that includes t= he =A0 =A0 =A0 highest outstanding unSACKed sequence number SHOULD be returned. =A0 =A0 =A0 Further, RescueRxt MUST be set to RecoveryPoint. =A0Finally, =A0 =A0 =A0 HighRxt MUST NOT be updated. I.e., before we can send a rescue segment the first segment retransmitted must be ACKed (ensuring an RTT has passed).=20=20 Finally, contrary to my usual mantra of keeping 3517bis clean and only including well-understood things and not gooping it up, I think this change [including the fix above] may well be OK. I think that for several reasons: (1) The change does not alter any of the *actions* or algorithms of RFC3517. Rather, the change turns a current inaction into an action. Therefore, the implications are easier to understand. (2) RFC3517 strives to fix all loss within an RTT of loss detection. Therefore, by pushing this rescue transmission to at least an RTT after the guts of the algorithm has been completed we are reducing the possible interactions and badness. (3) The scope of the proposed change is quite small. The change allows for **one** additional packet transmission **per loss event**. This packet is meant to then coax us into a regime where the already understood parts of RFC3517 take over and fix things up. So, even if we needlessly retransmit this rescue packet its just one packet per event and at that rate cannot likely cause any damage to the network, competing traffic or the connection itself. And, if it is spurious it isn't going to add any information to change the behavior of the algorithm that won't come along anyway. So, I'm all for rolling this nifty little tweak in. allman ----------ma31208-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2seegACgkQWyrrWs4yIs50uQCffeRktxaXQszPka1+OauLBGR0 jmQAmwRJitSCYUSvCRqoIyUtW5c3tCer =KTwS -----END PGP SIGNATURE----- ----------ma31208-1-- From eblanton@cs.ohiou.edu Mon Apr 18 12:58:49 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EF7F5E0870 for ; Mon, 18 Apr 2011 12:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIk1hmCXRNWE for ; Mon, 18 Apr 2011 12:58:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id E9859E081F for ; Mon, 18 Apr 2011 12:58:48 -0700 (PDT) Received: from 99-52-196-7.lightspeed.crmlin.sbcglobal.net ([99.52.196.7] helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBuas-0008Wh-Tm; Mon, 18 Apr 2011 19:58:47 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id 36BBB3BFDC; Mon, 18 Apr 2011 15:58:46 -0400 (EDT) Date: Mon, 18 Apr 2011 15:58:46 -0400 From: Ethan Blanton To: Mark Allman Message-ID: <20110418195846.GA20974@colt> Mail-Followup-To: Mark Allman , Yoshifumi Nishida , "tcpm@ietf.org" References: <20110418175032.E9AB73A356D8@lawyers.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <20110418175032.E9AB73A356D8@lawyers.icir.org> X-GnuPG-Fingerprint: CB44 99AC EDDA D1AB D6E6 A2CA FF1F 8B16 771F C72B User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 19:58:50 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Mark Allman spake unto us the following wisdom: > (3) The scope of the proposed change is quite small. The change > allows for **one** additional packet transmission **per loss > event**. This packet is meant to then coax us into a regime where > the already understood parts of RFC3517 take over and fix things > up. So, even if we needlessly retransmit this rescue packet its > just one packet per event and at that rate cannot likely cause any > damage to the network, competing traffic or the connection > itself. And, if it is spurious it isn't going to add any > information to change the behavior of the algorithm that won't > come along anyway. Let me add to this, per some discussion with mallman. Not only is this one packet per loss event, this is one packet where if we *could* have sent something different, we *would* have -- so it's no more "aggressive" in that sense than 3517. I do wish to note that some patterns of reordering with moderate cwnd sizes (a cwnd of at least 8 segments is required) will trigger this rescue retransmission reliably. However, as mentioned above, only in cases where 3517 would allow the sender to send a segment anyway, and bounded to a single retransmission per loss event. Steps (1) and (3) of NextSeg can be coaxed into spuriously retransmitting more than one segment in the face of reordering, under the right conditions, so I don't think this is a big deal. > So, I'm all for rolling this nifty little tweak in. I want to think about this a little more before I make that declaration. However, I *do* like this. It is clever and minimal, and the implications of "messing up" are well-defined and limited (to a constant one segment, even!). I simply want to make sure we're not overlooking anything before I give it my blessing (whatever that is worth). Ethan --wac7ysb48OaltWcw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTayX9f8fixZ3H8crAQjQ+AgAitp7/2AeLoepwh8omnuMZyxhixJBKpcN buPs7VLDXKNba8MX6YAlZ/BbptmigdedIvBF0W9bkMlPzJMhy5WVHVvyJp74FOU3 2b9YNNivlr3SXKpD6QJA9pV4JC7Fv8QWiuBkAXgA/sEXPmhUBykrZly8OzxMwSuI N4G5pIjQ4F06NjTzUksRdiTt3sxJC28m5MelGAJfLjbxVYLAZcsltJFkX7/cpM68 eDKKgtxAMmzGu+UyfQ8v/j+mdO7D8axm48/13scTyoWTZTwsOLYoxP6Ecyl7gycg 2j1LmcjruW/1txqDdF0Kjtf4049LkwLswjRz9modZ/pG7mx8dJTTuA== =q8rG -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From yoshifumi.nishida@gmail.com Mon Apr 18 22:18:30 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BF3A3E068E for ; Mon, 18 Apr 2011 22:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTLl85uv5zbG for ; Mon, 18 Apr 2011 22:18:29 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id 9F2C5E0661 for ; Mon, 18 Apr 2011 22:18:29 -0700 (PDT) Received: by pxi20 with SMTP id 20so3828440pxi.27 for ; Mon, 18 Apr 2011 22:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=N6HCa2bpbSYdMMjcAz/7ITJFUcIHHxGW6QAD3SR8Z0s=; b=FhKmWeDiKjEXvKHlE0UJefmhTtKY8BN3J6MeejoP/5uc6najw3m+pBSrnB855ilEnt AzqmZ9lB2x04t8CaE0EX7QDONbKlcxYyPQwb05OqqF0l3ocbfB1F9Jl+2ksWcCO2QdCI 3LqwTlCi92w/vufiWGlxbOVTPGOoLzEXfh7j8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=B9HQcA76dM2xF7p8766M8RhdIukcHnGI40Mk/1bYBmvyjXMzzNaPMsw9qc2ekkY/9g 2Y3qXjRA9P60Y1JVR2Bl6Jfbk2SjBOd7jxZ4S0w29DKfSeZGiyPpGx86vCxoyE5YJ6oy ztLVLuVenCi+Nrq/KKWAjN/fVu9rnZVggMqS0= MIME-Version: 1.0 Received: by 10.68.64.229 with SMTP id r5mr8119328pbs.139.1303190308882; Mon, 18 Apr 2011 22:18:28 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.68.57.105 with HTTP; Mon, 18 Apr 2011 22:18:28 -0700 (PDT) In-Reply-To: <20110418175032.E9AB73A356D8@lawyers.icir.org> References: <20110418175032.E9AB73A356D8@lawyers.icir.org> Date: Mon, 18 Apr 2011 22:18:28 -0700 X-Google-Sender-Auth: ztxfcRHrFLO9IZn6t0lBkRaiPC0 Message-ID: From: Yoshifumi Nishida To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 05:18:30 -0000 Hello Mark, Thanks for the comments. The algorithm you presented is smarter than I wrote in the draft. you're right that my logic has a bug and it's fixed in your algorithm, so I totally agree with this. Since whole intention in my draft is already covered by your comments, I don't have any more things to add. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/4/18 Mark Allman : > >> Filename: =A0 =A0 =A0 =A0draft-nishida-tcpm-rescue-retransmission > > First, I must say its a nicely clever trick, Yoshifumi. =A0The neat > observation is that by sending one segment per loss event you can > encourage the information needed to let the standard 3517 algorithm fix > end-of-window loss. > > The basic idea here is that when you're stuck and cannot send anything > according to RFC3517 (and the bis) the algorithm is extended to allow > sending the last unSACKed packet again. =A0This, in turn, triggers an ACK > with new SACK information that can further prod the loss recovery > process. =A0(Details are in Yoshifumi's draft). > > Second, the proposed fix isn't quite right, IMO. =A0Consider the case of > sending 6 segments (cwnd=3D6), losing only segment #1 and having no > further data to send. =A0So, this is what arrives at and is sent by the > data sender: > > =A0 =A01. =A0ACK 1, SACK 2:2 > =A0 =A0 =A0 =A0[do nothing] > =A0 =A02. =A0ACK 1, SACK 2:3 > =A0 =A0 =A0 =A0[do nothing] > =A0 =A03. =A0ACK 1, SACK 2:4 > =A0 =A0 =A0 =A0--> cwnd =3D FlightSize / 2 =3D 3, pipe =3D 2 (segs 5 & 6) > =A0 =A0 =A0 =A0--> retransmit segment 1, pipe =3D 3 (segs 1(rxt), 5 & 6) > =A0 =A04. =A0ACK 1, SACK 2:5 > =A0 =A0 =A0 =A0--> pipe =3D 2 (segs 1(rxt) & 6) > =A0 =A0 =A0 =A0--> we have no data judged as having been lost ((1) in > =A0 =A0 =A0 =A0 =A0 =A0NextSeg()) > =A0 =A0 =A0 =A0--> we have no new data to send ((2) in NextSeg()) > =A0 =A0 =A0 =A0--> we have no "last resort" data to send ((3) in NextSeg(= )), > =A0 =A0 =A0 =A0 =A0 =A0i.e., unSACKed data not judged as lost, but with S= ACKed data > =A0 =A0 =A0 =A0 =A0 =A0above it) > =A0 =A0 =A0 =A0--> so, we invoke the proposed (4) in NextSeg() and transm= it the > =A0 =A0 =A0 =A0 =A0 =A0segment at the end of the window, or segment 6 > =A0 =A05. =A0ACK 1, SACK 2:6 > =A0 =A06. =A0ACK 7 > =A0 =A07. =A0ACK 7, (DSACK 6, if supported) > > In this case we just don't wait long enough to re-send this rescue > packet (step 4 above) and so we really have no idea if the end of the > window has been lost or not (and, in the above example it has not and so > the retransmit is spurious). =A0In step 4 above we cannot possibly have > gained an understanding about the end of the window. > > Third, this failure mode is readily fixed by forcing the rescue > retransmit to happen an RTT after loss recovery has started (i.e., to > ensure all ACKs for the window of data that experienced loss roll in > first). =A0This is easy enough. =A0When loss recovery is initiated we set > RescueRxt to the highest octet of the first retransmission. =A0Now, rule > (4) in NextSeg() > > =A0 (4) If the conditions for rules (1), (2) and (3) fail, but there > =A0=A0 =A0 exists outstanding and unSACKed data we provide the opportunit= y > =A0 =A0 =A0 for a single "rescue" retransmission. =A0If HighACK is greate= r than > =A0 =A0 =A0 RescueRxt then one segment of up to SMSS octets that includes= the > =A0 =A0 =A0 highest outstanding unSACKed sequence number SHOULD be return= ed. > =A0 =A0 =A0 Further, RescueRxt MUST be set to RecoveryPoint. =A0Finally, > =A0 =A0 =A0 HighRxt MUST NOT be updated. > > I.e., before we can send a rescue segment the first segment > retransmitted must be ACKed (ensuring an RTT has passed). > > Finally, contrary to my usual mantra of keeping 3517bis clean and only > including well-understood things and not gooping it up, I think this > change [including the fix above] may well be OK. =A0I think that for > several reasons: > > =A0(1) The change does not alter any of the *actions* or algorithms of > =A0 =A0 =A0RFC3517. =A0Rather, the change turns a current inaction into a= n > =A0 =A0 =A0action. =A0Therefore, the implications are easier to understan= d. > > =A0(2) RFC3517 strives to fix all loss within an RTT of loss detection. > =A0 =A0 =A0Therefore, by pushing this rescue transmission to at least an = RTT > =A0 =A0 =A0after the guts of the algorithm has been completed we are redu= cing > =A0 =A0 =A0the possible interactions and badness. > > =A0(3) The scope of the proposed change is quite small. =A0The change > =A0 =A0 =A0allows for **one** additional packet transmission **per loss > =A0 =A0 =A0event**. =A0This packet is meant to then coax us into a regime= where > =A0 =A0 =A0the already understood parts of RFC3517 take over and fix thin= gs > =A0 =A0 =A0up. =A0So, even if we needlessly retransmit this rescue packet= its > =A0 =A0 =A0just one packet per event and at that rate cannot likely cause= any > =A0 =A0 =A0damage to the network, competing traffic or the connection > =A0 =A0 =A0itself. =A0And, if it is spurious it isn't going to add any > =A0 =A0 =A0information to change the behavior of the algorithm that won't > =A0 =A0 =A0come along anyway. > > So, I'm all for rolling this nifty little tweak in. > > allman > > > > From ycheng@google.com Mon Apr 18 22:31:38 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7DF67E0687 for ; Mon, 18 Apr 2011 22:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.826 X-Spam-Level: X-Spam-Status: No, score=-105.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCNv7Kawu41I for ; Mon, 18 Apr 2011 22:31:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfc.amsl.com (Postfix) with ESMTP id 28110E0661 for ; Mon, 18 Apr 2011 22:31:37 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p3J5VaNa014678 for ; Mon, 18 Apr 2011 22:31:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303191096; bh=T1AEgf+E34QxmaatYhqT1r5VbQA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=wpDOKA0g6N6n77XimAG7sVt69WZpUpFBkCjuJJK7SRwdQSmVvic8qrW7ZpezGFjXs rWEKiX/ZXCo4KAfLCiunw== Received: from gye5 (gye5.prod.google.com [10.243.50.5]) by kpbe13.cbf.corp.google.com with ESMTP id p3J5VYmn031923 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 18 Apr 2011 22:31:34 -0700 Received: by gye5 with SMTP id 5so6193072gye.2 for ; Mon, 18 Apr 2011 22:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jT1Ai22inyCIcox1DT8p/BzQb601kqde1nK29ENvsHY=; b=vojTYHScMgpgYi5rpHAbKghFSiE/kDG4Yx6FtLnM11yYVfi/7YwC86/iG3+8v62vNl 96iLTZU8EtrWAhM8E2PQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=sZORDd/ZkBDF0NBxeTWRIhE+1HidPSUpupERb7+8J1S+Xj/aFMuvzxqJdjoQDFOd9m OY/+ubroKhVkEQLSKBDw== Received: by 10.151.105.7 with SMTP id h7mr4709213ybm.218.1303191094140; Mon, 18 Apr 2011 22:31:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.109.8 with HTTP; Mon, 18 Apr 2011 22:31:14 -0700 (PDT) In-Reply-To: References: <20110418175032.E9AB73A356D8@lawyers.icir.org> From: Yuchung Cheng Date: Mon, 18 Apr 2011 22:31:14 -0700 Message-ID: To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=00151750eeb83da10104a13ed248 X-System-Of-Record: true Cc: "tcpm@ietf.org\"" , mallman@icir.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 05:31:38 -0000 --00151750eeb83da10104a13ed248 Content-Type: text/plain; charset=ISO-8859-1 I also think the idea + Mark's change are really neat. One nit: since rescue-retransmit does not update HighRxt, the HighRxt definition may need some update or clarification. On Mon, Apr 18, 2011 at 10:18 PM, Yoshifumi Nishida wrote: > Hello Mark, > > Thanks for the comments. > The algorithm you presented is smarter than I wrote in the draft. > you're right that my logic has a bug and it's fixed in your algorithm, > so I totally agree with this. > Since whole intention in my draft is already covered by your comments, > I don't have > any more things to add. > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > > 2011/4/18 Mark Allman : > > > >> Filename: draft-nishida-tcpm-rescue-retransmission > > > > First, I must say its a nicely clever trick, Yoshifumi. The neat > > observation is that by sending one segment per loss event you can > > encourage the information needed to let the standard 3517 algorithm fix > > end-of-window loss. > > > > The basic idea here is that when you're stuck and cannot send anything > > according to RFC3517 (and the bis) the algorithm is extended to allow > > sending the last unSACKed packet again. This, in turn, triggers an ACK > > with new SACK information that can further prod the loss recovery > > process. (Details are in Yoshifumi's draft). > > > > Second, the proposed fix isn't quite right, IMO. Consider the case of > > sending 6 segments (cwnd=6), losing only segment #1 and having no > > further data to send. So, this is what arrives at and is sent by the > > data sender: > > > > 1. ACK 1, SACK 2:2 > > [do nothing] > > 2. ACK 1, SACK 2:3 > > [do nothing] > > 3. ACK 1, SACK 2:4 > > --> cwnd = FlightSize / 2 = 3, pipe = 2 (segs 5 & 6) > > --> retransmit segment 1, pipe = 3 (segs 1(rxt), 5 & 6) > > 4. ACK 1, SACK 2:5 > > --> pipe = 2 (segs 1(rxt) & 6) > > --> we have no data judged as having been lost ((1) in > > NextSeg()) > > --> we have no new data to send ((2) in NextSeg()) > > --> we have no "last resort" data to send ((3) in NextSeg()), > > i.e., unSACKed data not judged as lost, but with SACKed data > > above it) > > --> so, we invoke the proposed (4) in NextSeg() and transmit the > > segment at the end of the window, or segment 6 > > 5. ACK 1, SACK 2:6 > > 6. ACK 7 > > 7. ACK 7, (DSACK 6, if supported) > > > > In this case we just don't wait long enough to re-send this rescue > > packet (step 4 above) and so we really have no idea if the end of the > > window has been lost or not (and, in the above example it has not and so > > the retransmit is spurious). In step 4 above we cannot possibly have > > gained an understanding about the end of the window. > > > > Third, this failure mode is readily fixed by forcing the rescue > > retransmit to happen an RTT after loss recovery has started (i.e., to > > ensure all ACKs for the window of data that experienced loss roll in > > first). This is easy enough. When loss recovery is initiated we set > > RescueRxt to the highest octet of the first retransmission. Now, rule > > (4) in NextSeg() > > > > (4) If the conditions for rules (1), (2) and (3) fail, but there > > exists outstanding and unSACKed data we provide the opportunity > > for a single "rescue" retransmission. If HighACK is greater than > > RescueRxt then one segment of up to SMSS octets that includes the > > highest outstanding unSACKed sequence number SHOULD be returned. > > Further, RescueRxt MUST be set to RecoveryPoint. Finally, > > HighRxt MUST NOT be updated. > > > > I.e., before we can send a rescue segment the first segment > > retransmitted must be ACKed (ensuring an RTT has passed). > > > > Finally, contrary to my usual mantra of keeping 3517bis clean and only > > including well-understood things and not gooping it up, I think this > > change [including the fix above] may well be OK. I think that for > > several reasons: > > > > (1) The change does not alter any of the *actions* or algorithms of > > RFC3517. Rather, the change turns a current inaction into an > > action. Therefore, the implications are easier to understand. > > > > (2) RFC3517 strives to fix all loss within an RTT of loss detection. > > Therefore, by pushing this rescue transmission to at least an RTT > > after the guts of the algorithm has been completed we are reducing > > the possible interactions and badness. > > > > (3) The scope of the proposed change is quite small. The change > > allows for **one** additional packet transmission **per loss > > event**. This packet is meant to then coax us into a regime where > > the already understood parts of RFC3517 take over and fix things > > up. So, even if we needlessly retransmit this rescue packet its > > just one packet per event and at that rate cannot likely cause any > > damage to the network, competing traffic or the connection > > itself. And, if it is spurious it isn't going to add any > > information to change the behavior of the algorithm that won't > > come along anyway. > > > > So, I'm all for rolling this nifty little tweak in. > > > > allman > > > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --00151750eeb83da10104a13ed248 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I also think the idea + Mark's change are really neat.=A0

O= ne nit: since rescue-retransmit does not update HighRxt, the HighRxt defini= tion may need some update or clarification.


On Mon, Apr 18, 2011 at 10:18 PM, Yoshifumi Nishida <<= a href=3D"mailto:nishida@sfc.wide.ad.jp">nishida@sfc.wide.ad.jp> wrote:
Hello Mark,

Thanks for the comments.
The algorithm you presented is smarter than I wrote in the draft.
you're right that my logic has a bug and it's fixed in your algorit= hm,
so I totally agree with this.
Since whole intention in my draft is already covered by your comments,
I don't have
any more things to add.

Thanks,
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp

2011/4/18 Mark Allman <mallman= @icir.org>:
>
>> Filename: =A0 =A0 =A0 =A0draft-nishida-tcpm-rescue-retransmission<= br> >
> First, I must say its a nicely clever trick, Yoshifumi. =A0The neat > observation is that by sending one segment per loss event you can
> encourage the information needed to let the standard 3517 algorithm fi= x
> end-of-window loss.
>
> The basic idea here is that when you're stuck and cannot send anyt= hing
> according to RFC3517 (and the bis) the algorithm is extended to allow<= br> > sending the last unSACKed packet again. =A0This, in turn, triggers an = ACK
> with new SACK information that can further prod the loss recovery
> process. =A0(Details are in Yoshifumi's draft).
>
> Second, the proposed fix isn't quite right, IMO. =A0Consider the c= ase of
> sending 6 segments (cwnd=3D6), losing only segment #1 and having no > further data to send. =A0So, this is what arrives at and is sent by th= e
> data sender:
>
> =A0 =A01. =A0ACK 1, SACK 2:2
> =A0 =A0 =A0 =A0[do nothing]
> =A0 =A02. =A0ACK 1, SACK 2:3
> =A0 =A0 =A0 =A0[do nothing]
> =A0 =A03. =A0ACK 1, SACK 2:4
> =A0 =A0 =A0 =A0--> cwnd =3D FlightSize / 2 =3D 3, pipe =3D 2 (segs = 5 & 6)
> =A0 =A0 =A0 =A0--> retransmit segment 1, pipe =3D 3 (segs 1(rxt), 5= & 6)
> =A0 =A04. =A0ACK 1, SACK 2:5
> =A0 =A0 =A0 =A0--> pipe =3D 2 (segs 1(rxt) & 6)
> =A0 =A0 =A0 =A0--> we have no data judged as having been lost ((1) = in
> =A0 =A0 =A0 =A0 =A0 =A0NextSeg())
> =A0 =A0 =A0 =A0--> we have no new data to send ((2) in NextSeg()) > =A0 =A0 =A0 =A0--> we have no "last resort" data to send = ((3) in NextSeg()),
> =A0 =A0 =A0 =A0 =A0 =A0i.e., unSACKed data not judged as lost, but wit= h SACKed data
> =A0 =A0 =A0 =A0 =A0 =A0above it)
> =A0 =A0 =A0 =A0--> so, we invoke the proposed (4) in NextSeg() and = transmit the
> =A0 =A0 =A0 =A0 =A0 =A0segment at the end of the window, or segment 6<= br> > =A0 =A05. =A0ACK 1, SACK 2:6
> =A0 =A06. =A0ACK 7
> =A0 =A07. =A0ACK 7, (DSACK 6, if supported)
>
> In this case we just don't wait long enough to re-send this rescue=
> packet (step 4 above) and so we really have no idea if the end of the<= br> > window has been lost or not (and, in the above example it has not and = so
> the retransmit is spurious). =A0In step 4 above we cannot possibly hav= e
> gained an understanding about the end of the window.
>
> Third, this failure mode is readily fixed by forcing the rescue
> retransmit to happen an RTT after loss recovery has started (i.e., to<= br> > ensure all ACKs for the window of data that experienced loss roll in > first). =A0This is easy enough. =A0When loss recovery is initiated we = set
> RescueRxt to the highest octet of the first retransmission. =A0Now, ru= le
> (4) in NextSeg()
>
> =A0 (4) If the conditions for rules (1), (2) and (3) fail, but there > =A0=A0 =A0 exists outstanding and unSACKed data we provide the opportu= nity
> =A0 =A0 =A0 for a single "rescue" retransmission. =A0If High= ACK is greater than
> =A0 =A0 =A0 RescueRxt then one segment of up to SMSS octets that inclu= des the
> =A0 =A0 =A0 highest outstanding unSACKed sequence number SHOULD be ret= urned.
> =A0 =A0 =A0 Further, RescueRxt MUST be set to RecoveryPoint. =A0Finall= y,
> =A0 =A0 =A0 HighRxt MUST NOT be updated.
>
> I.e., before we can send a rescue segment the first segment
> retransmitted must be ACKed (ensuring an RTT has passed).
>
> Finally, contrary to my usual mantra of keeping 3517bis clean and only=
> including well-understood things and not gooping it up, I think this > change [including the fix above] may well be OK. =A0I think that for > several reasons:
>
> =A0(1) The change does not alter any of the *actions* or algorithms of=
> =A0 =A0 =A0RFC3517. =A0Rather, the change turns a current inaction int= o an
> =A0 =A0 =A0action. =A0Therefore, the implications are easier to unders= tand.
>
> =A0(2) RFC3517 strives to fix all loss within an RTT of loss detection= .
> =A0 =A0 =A0Therefore, by pushing this rescue transmission to at least = an RTT
> =A0 =A0 =A0after the guts of the algorithm has been completed we are r= educing
> =A0 =A0 =A0the possible interactions and badness.
>
> =A0(3) The scope of the proposed change is quite small. =A0The change<= br> > =A0 =A0 =A0allows for **one** additional packet transmission **per los= s
> =A0 =A0 =A0event**. =A0This packet is meant to then coax us into a reg= ime where
> =A0 =A0 =A0the already understood parts of RFC3517 take over and fix t= hings
> =A0 =A0 =A0up. =A0So, even if we needlessly retransmit this rescue pac= ket its
> =A0 =A0 =A0just one packet per event and at that rate cannot likely ca= use any
> =A0 =A0 =A0damage to the network, competing traffic or the connection<= br> > =A0 =A0 =A0itself. =A0And, if it is spurious it isn't going to add= any
> =A0 =A0 =A0information to change the behavior of the algorithm that wo= n't
> =A0 =A0 =A0come along anyway.
>
> So, I'm all for rolling this nifty little tweak in.
>
> allman
>
>
>
>
_____________________________= __________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--00151750eeb83da10104a13ed248-- From rs@netapp.com Tue Apr 19 04:21:35 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6B833E06C8 for ; Tue, 19 Apr 2011 04:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyCcNPS5Qed8 for ; Tue, 19 Apr 2011 04:21:34 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by ietfc.amsl.com (Postfix) with ESMTP id EE6FAE0732 for ; Tue, 19 Apr 2011 04:21:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,239,1301900400"; d="scan'208";a="248108828" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 19 Apr 2011 04:21:32 -0700 Received: from amsrsexc1-prd.hq.netapp.com (amsrsexc1-prd.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p3JBLVWS001105; Tue, 19 Apr 2011 04:21:32 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Apr 2011 13:21:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Apr 2011 12:21:05 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0DFA913E@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) Thread-Index: Acv+UUhJDlpYEEjiSIGFye4TuwxfGQAMZBUw References: <20110418175032.E9AB73A356D8@lawyers.icir.org> From: "Scheffenegger, Richard" To: "Yoshifumi Nishida" , X-OriginalArrivalTime: 19 Apr 2011 11:21:31.0407 (UTC) FILETIME=[EEFF49F0:01CBFE83] Cc: tcpm@ietf.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 11:21:35 -0000 Yoshifumi, Mark, I really like that idea about only sending the very last segment anew = very much!=20 As Mark and Yuchung pointed out, my original idea about the partial ACK = would clock out the *suspected* (but unproven) lost data segement only = at 1 per RTT, while this new proposal is even better suited (when 3 or = more consecutive segments are lost, a few RTTs are saved on recovery as = the full RFC3517 algorithm, including pipe, comes into play!). I'm glad to have sparked this discussion about end-of-stream loss = recovery! Richard Scheffenegger > -----Original Message----- > From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] > Sent: Dienstag, 19. April 2011 07:18 > To: mallman@icir.org > Cc: tcpm@ietf.org" > Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss > recovery (TCP SACK) ) >=20 > Hello Mark, >=20 > Thanks for the comments. > The algorithm you presented is smarter than I wrote in the draft. > you're right that my logic has a bug and it's fixed in your algorithm, > so I totally agree with this. > Since whole intention in my draft is already covered by your comments, > I don't have > any more things to add. >=20 > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp >=20 > 2011/4/18 Mark Allman : > > > >> Filename: =A0 =A0 =A0 =A0draft-nishida-tcpm-rescue-retransmission > > > > First, I must say its a nicely clever trick, Yoshifumi. =A0The neat > > observation is that by sending one segment per loss event you can > > encourage the information needed to let the standard 3517 algorithm > fix > > end-of-window loss. > > > > The basic idea here is that when you're stuck and cannot send > anything > > according to RFC3517 (and the bis) the algorithm is extended to = allow > > sending the last unSACKed packet again. =A0This, in turn, triggers = an > ACK > > with new SACK information that can further prod the loss recovery > > process. =A0(Details are in Yoshifumi's draft). > > > > Second, the proposed fix isn't quite right, IMO. =A0Consider the = case > of > > sending 6 segments (cwnd=3D6), losing only segment #1 and having no > > further data to send. =A0So, this is what arrives at and is sent by = the > > data sender: > > > > =A0 =A01. =A0ACK 1, SACK 2:2 > > =A0 =A0 =A0 =A0[do nothing] > > =A0 =A02. =A0ACK 1, SACK 2:3 > > =A0 =A0 =A0 =A0[do nothing] > > =A0 =A03. =A0ACK 1, SACK 2:4 > > =A0 =A0 =A0 =A0--> cwnd =3D FlightSize / 2 =3D 3, pipe =3D 2 (segs 5 = & 6) > > =A0 =A0 =A0 =A0--> retransmit segment 1, pipe =3D 3 (segs 1(rxt), 5 = & 6) > > =A0 =A04. =A0ACK 1, SACK 2:5 > > =A0 =A0 =A0 =A0--> pipe =3D 2 (segs 1(rxt) & 6) > > =A0 =A0 =A0 =A0--> we have no data judged as having been lost ((1) = in > > =A0 =A0 =A0 =A0 =A0 =A0NextSeg()) > > =A0 =A0 =A0 =A0--> we have no new data to send ((2) in NextSeg()) > > =A0 =A0 =A0 =A0--> we have no "last resort" data to send ((3) in = NextSeg()), > > =A0 =A0 =A0 =A0 =A0 =A0i.e., unSACKed data not judged as lost, but = with SACKed > data > > =A0 =A0 =A0 =A0 =A0 =A0above it) > > =A0 =A0 =A0 =A0--> so, we invoke the proposed (4) in NextSeg() and = transmit > the > > =A0 =A0 =A0 =A0 =A0 =A0segment at the end of the window, or segment = 6 > > =A0 =A05. =A0ACK 1, SACK 2:6 > > =A0 =A06. =A0ACK 7 > > =A0 =A07. =A0ACK 7, (DSACK 6, if supported) > > > > In this case we just don't wait long enough to re-send this rescue > > packet (step 4 above) and so we really have no idea if the end of = the > > window has been lost or not (and, in the above example it has not = and > so > > the retransmit is spurious). =A0In step 4 above we cannot possibly = have > > gained an understanding about the end of the window. > > > > Third, this failure mode is readily fixed by forcing the rescue > > retransmit to happen an RTT after loss recovery has started (i.e., = to > > ensure all ACKs for the window of data that experienced loss roll in > > first). =A0This is easy enough. =A0When loss recovery is initiated = we set > > RescueRxt to the highest octet of the first retransmission. =A0Now, > rule > > (4) in NextSeg() > > > > =A0 (4) If the conditions for rules (1), (2) and (3) fail, but there > > =A0=A0 =A0 exists outstanding and unSACKed data we provide the = opportunity > > =A0 =A0 =A0 for a single "rescue" retransmission. =A0If HighACK is = greater > than > > =A0 =A0 =A0 RescueRxt then one segment of up to SMSS octets that = includes > the > > =A0 =A0 =A0 highest outstanding unSACKed sequence number SHOULD be > returned. > > =A0 =A0 =A0 Further, RescueRxt MUST be set to RecoveryPoint. = =A0Finally, > > =A0 =A0 =A0 HighRxt MUST NOT be updated. > > > > I.e., before we can send a rescue segment the first segment > > retransmitted must be ACKed (ensuring an RTT has passed). > > > > Finally, contrary to my usual mantra of keeping 3517bis clean and > only > > including well-understood things and not gooping it up, I think this > > change [including the fix above] may well be OK. =A0I think that for > > several reasons: > > > > =A0(1) The change does not alter any of the *actions* or algorithms = of > > =A0 =A0 =A0RFC3517. =A0Rather, the change turns a current inaction = into an > > =A0 =A0 =A0action. =A0Therefore, the implications are easier to = understand. > > > > =A0(2) RFC3517 strives to fix all loss within an RTT of loss = detection. > > =A0 =A0 =A0Therefore, by pushing this rescue transmission to at = least an > RTT > > =A0 =A0 =A0after the guts of the algorithm has been completed we are > reducing > > =A0 =A0 =A0the possible interactions and badness. > > > > =A0(3) The scope of the proposed change is quite small. =A0The = change > > =A0 =A0 =A0allows for **one** additional packet transmission **per = loss > > =A0 =A0 =A0event**. =A0This packet is meant to then coax us into a = regime > where > > =A0 =A0 =A0the already understood parts of RFC3517 take over and fix = things > > =A0 =A0 =A0up. =A0So, even if we needlessly retransmit this rescue = packet its > > =A0 =A0 =A0just one packet per event and at that rate cannot likely = cause > any > > =A0 =A0 =A0damage to the network, competing traffic or the = connection > > =A0 =A0 =A0itself. =A0And, if it is spurious it isn't going to add = any > > =A0 =A0 =A0information to change the behavior of the algorithm that = won't > > =A0 =A0 =A0come along anyway. > > > > So, I'm all for rolling this nifty little tweak in. > > > > allman > > > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From alexander.zimmermann@comsys.rwth-aachen.de Tue Apr 19 05:40:09 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 49E75E06E0 for ; Tue, 19 Apr 2011 05:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-1.238, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co-RXdD-bEaV for ; Tue, 19 Apr 2011 05:40:08 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by ietfc.amsl.com (Postfix) with ESMTP id 2C768E06A7 for ; Tue, 19 Apr 2011 05:40:07 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LJW00I8SGIUS6J0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 19 Apr 2011 14:40:06 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.64,239,1301868000"; d="sig'?scan'208";a="107424976" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 19 Apr 2011 14:40:07 +0200 Received: from [192.168.4.14] ([unknown] [77.109.116.66]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LJW00FI2GIU9120@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 19 Apr 2011 14:40:06 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-1-639573763 From: Alexander Zimmermann In-reply-to: Date: Tue, 19 Apr 2011 14:40:04 +0200 Content-transfer-encoding: 7bit Message-id: References: <4DA57E7D.6040206@comsys.rwth-aachen.de> To: =?utf-8?Q?Ilpo_J=C3=A4rvinen?= , Richard Scheffenegger , Yuchung Cheng X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] FlightSizePrev in TCP-NCR X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 12:40:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-639573763 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii BTW, if anyone other than the two co-author has some time and is willing = to help us, especially the SACK specialists (Ilpo, Richard, Yuchung,...), be our = guest... :-) Alex Am 14.04.2011 um 18:30 schrieb Alexander Zimmermann: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Mark, Hi Ethan, >=20 > here is one easy example: >=20 > Receiver: 2 4 1 6 3 ... > Sender: S2 S2,4 A3,S4 S4,6 A5,S6 >=20 > 3517: LT LT Inc LT Inc >=20 > with S=3DSACK, A=3DACK, LT=3DLimited Transmit, Inc=3DCWND increase >=20 >=20 > Am 13.04.2011 um 12:44 schrieb Lennart Schulte: >=20 >> Hi folks, >>=20 >> we are currently implementing TCP-NCR in Linux. >>=20 >> Consider the following scenario: >> The connection experiences a lot of reordering and all segments carry >> SACK information, even those which advance the cumulative ACK point. >> However loss recovery is never entered (reordering extent < = dupthresh). >>=20 >> RFC5681 allows an increase of CWND for every ACK that advances the >> cumulative ACK point, even if this ACK carries SACK information, so = CWND >> will grow during the connection's lifetime. >=20 > See example above... >=20 >>=20 >> In contrast TCP-NCR calculates the number of segments to sent during >> Extended Limited Transmit with FlightSizePrev (E.2). >=20 > (pipe + Skipped) <=3D (FlightSizePrev - SMSS) >=20 > ... and not with CWND (like 3517). Why? =3D> Main question (1) >=20 >=20 >> Also, if an ACK >> arrives that advances the cumulative ACK point and also carries SACK >> information, it sets the CWND to no more than FlightSizePrev (T.1). >> Since FlightSizePrev is held constant for such an ACK and is not set >> again (T.4), >=20 > Copy&Paste >=20 > (T.4) When an incoming ACK extends the cumulative ACK point and also > contains SACK information, the initializations in steps (I.2) and > (I.3) from Section 3.1 MUST be taken (but step (I.1) MUST NOT be > executed) to re-start Extended Limited Transmit... >=20 > why "(I.1) MUST NOT be executed"? =3D> Main question (2) >=20 >> the CWND is not allowed to increase during the whole >> connection when there is no ACK that does not carry any SACK >> information. With this behavior the throughput will stay very low. >=20 > In example above, RFC3517 can still increase the CWND according > Slow Start or Congestion Avoidance, NCR get stucked. >=20 >>=20 >> My questions are: >> 1) Why FlightSizePrev is used in E.2? >> 2) Why FlightSizePrev is not recalculated in T.4? >>=20 >> Thanks, >> Lennart >=20 // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-1-639573763 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2tgqUACgkQdyiq39b9uS6n5QCgs7w8LPkLcmB+V1iekutIV7BI +d0AoNQeh88JhSnNaC0LJceWWFeCMPzM =MQ8N -----END PGP SIGNATURE----- --Apple-Mail-1-639573763-- From Michael.Scharf@alcatel-lucent.com Wed Apr 20 14:42:03 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3A1A9E0781 for ; Wed, 20 Apr 2011 14:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNFEiOp0Cwmi for ; Wed, 20 Apr 2011 14:42:02 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfc.amsl.com (Postfix) with ESMTP id 797DBE06DC for ; Wed, 20 Apr 2011 14:42:02 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p3KLg0fN004056 for ; Wed, 20 Apr 2011 23:42:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Apr 2011 23:41:59 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C05679874@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes of IETF 80 Thread-Index: Acv/o8dLhVf9MkDXQ1GPDyaAuIZAUw== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] Draft minutes of IETF 80 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 21:42:03 -0000 Folks, I uploaded draft minutes of TCPM, based on the excellent notes from Gorry (thanks!): http://www.ietf.org/proceedings/80/minutes/tcpm.txt Please send us any correction or clarification within the next two weeks. Thanks, Michael From thomas.r.henderson@boeing.com Thu Apr 21 08:28:53 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 88E2CE07AB for ; Thu, 21 Apr 2011 08:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M1lg30uvgws for ; Thu, 21 Apr 2011 08:28:52 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfc.amsl.com (Postfix) with ESMTP id 79B13E0655 for ; Thu, 21 Apr 2011 08:28:52 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p3LFSOBX003124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2011 08:28:24 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p3LFSN1F005960; Thu, 21 Apr 2011 10:28:23 -0500 (CDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p3LFSNNB005940 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 21 Apr 2011 10:28:23 -0500 (CDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Thu, 21 Apr 2011 08:28:23 -0700 From: "Henderson, Thomas R" To: tcpm WG Date: Thu, 21 Apr 2011 08:28:22 -0700 Thread-Topic: NewReno draft update published Thread-Index: AcwAOL+ZRPlYwtFgSHOscnebNBo6MA== Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEED716A4@XCH-NW-10V.nw.nos.boeing.com> 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 Cc: "gurtov@hiit.fi" , "floyd@acm.org" Subject: [tcpm] NewReno draft update published X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 15:28:53 -0000 I've published some revisions to RFC 3782 bis that I discussed at the IETF = 80 meeting: http://tools.ietf.org/html/draft-ietf-tcpm-rfc3782-bis-02 I don't have any other revisions planned, so if there are no other comments= , I think it is ready for WGLC. As discussed at the meeting, it is planned= to go to Proposed Standard. - Tom From ycheng@google.com Thu Apr 21 11:56:49 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8424BE07E7 for ; Thu, 21 Apr 2011 11:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.043 X-Spam-Level: X-Spam-Status: No, score=-105.043 tagged_above=-999 required=5 tests=[AWL=-2.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZscjSD365Npm for ; Thu, 21 Apr 2011 11:56:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id DDE98E07DA for ; Thu, 21 Apr 2011 11:56:47 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p3LIukki022144 for ; Thu, 21 Apr 2011 11:56:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303412207; bh=DdGEc5w05UlTsHO/jkceSlrvHdU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=QbmyrSUAk/2YzzIER7evXk6QbnI2ZwfOWuZniUnGDr8ZuLiMmUNCmUUaWo1MsMMhM SpELPu8MTClJMbRiaCeig== Received: from gwj21 (gwj21.prod.google.com [10.200.10.21]) by wpaz1.hot.corp.google.com with ESMTP id p3LIuJNU022575 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 21 Apr 2011 11:56:45 -0700 Received: by gwj21 with SMTP id 21so5625gwj.30 for ; Thu, 21 Apr 2011 11:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HfI65siUriwAnDAZcFKZ09TUk1jNKuejdr0wwdEv/0g=; b=tMQkkHx0jLPyw18ZVhNHW0eotRnvNDtMdsyGsn4lIj0lUs/yOBYNZKzrhuezdNwn22 dX6XD8DQFcmdwKwqwNLg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Cc8aXPjxkbMkUw/UzmsOhiFGghFaJHI8q9ANbN9Ps6NLvpYQXtevj/aV9dU4geyddQ p0vJeP1hbMYayD3Z2+8Q== Received: by 10.151.3.2 with SMTP id f2mr745957ybi.47.1303412205123; Thu, 21 Apr 2011 11:56:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.109.8 with HTTP; Thu, 21 Apr 2011 11:56:24 -0700 (PDT) In-Reply-To: References: <4DA57E7D.6040206@comsys.rwth-aachen.de> From: Yuchung Cheng Date: Thu, 21 Apr 2011 11:56:24 -0700 Message-ID: To: Alexander Zimmermann Content-Type: multipart/alternative; boundary=000e0cd6a7b27b788204a1724dd8 X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" , Matthew Mathis Subject: Re: [tcpm] FlightSizePrev in TCP-NCR X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 21 Apr 2011 18:56:49 -0000 --000e0cd6a7b27b788204a1724dd8 Content-Type: text/plain; charset=ISO-8859-1 Sorry, I read the RFC have the exactly the same questions and plus a few more ... 1) E.2 does not make sense that limited-transmit is only allowed if pipe drops under FlightSizePrev == FlightSize when receiving some dubious ACK. The RFC needs some clarification for this step. 2) T.4 skipping T.1 does not make sense either 3) Burst suppression in T.1 and T.2 are both MUST. I don't get it. Why suppress burst upon detecting reordering, not loss? are reorderings highly correlated to cwnd size. FWIW, Linux has similar logic which I find bizarre. 4) E.6. DupThresh will keep getting larger as limited-transmits increase FlightSize. Are there any studies on the effectiveness of TCP-NCR? AFAIK, Linux uses the scoreboard to derive the reordering degree to compute dynamic dupthresh. The mechanism seems simpler and more effective. On Tue, Apr 19, 2011 at 5:40 AM, Alexander Zimmermann < alexander.zimmermann@comsys.rwth-aachen.de> wrote: > BTW, if anyone other than the two co-author has some time and is willing to > help us, > especially the SACK specialists (Ilpo, Richard, Yuchung,...), be our > guest... :-) > > Alex > > Am 14.04.2011 um 18:30 schrieb Alexander Zimmermann: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi Mark, Hi Ethan, > > > > here is one easy example: > > > > Receiver: 2 4 1 6 3 ... > > Sender: S2 S2,4 A3,S4 S4,6 A5,S6 > > > > 3517: LT LT Inc LT Inc > > > > with S=SACK, A=ACK, LT=Limited Transmit, Inc=CWND increase > > > > > > Am 13.04.2011 um 12:44 schrieb Lennart Schulte: > > > >> Hi folks, > >> > >> we are currently implementing TCP-NCR in Linux. > >> > >> Consider the following scenario: > >> The connection experiences a lot of reordering and all segments carry > >> SACK information, even those which advance the cumulative ACK point. > >> However loss recovery is never entered (reordering extent < dupthresh). > >> > >> RFC5681 allows an increase of CWND for every ACK that advances the > >> cumulative ACK point, even if this ACK carries SACK information, so CWND > >> will grow during the connection's lifetime. > > > > See example above... > > > >> > >> In contrast TCP-NCR calculates the number of segments to sent during > >> Extended Limited Transmit with FlightSizePrev (E.2). > > > > (pipe + Skipped) <= (FlightSizePrev - SMSS) > > > > ... and not with CWND (like 3517). Why? => Main question (1) > > > > > >> Also, if an ACK > >> arrives that advances the cumulative ACK point and also carries SACK > >> information, it sets the CWND to no more than FlightSizePrev (T.1). > >> Since FlightSizePrev is held constant for such an ACK and is not set > >> again (T.4), > > > > Copy&Paste > > > > (T.4) When an incoming ACK extends the cumulative ACK point and also > > contains SACK information, the initializations in steps (I.2) and > > (I.3) from Section 3.1 MUST be taken (but step (I.1) MUST NOT be > > executed) to re-start Extended Limited Transmit... > > > > why "(I.1) MUST NOT be executed"? => Main question (2) > > > >> the CWND is not allowed to increase during the whole > >> connection when there is no ACK that does not carry any SACK > >> information. With this behavior the throughput will stay very low. > > > > In example above, RFC3517 can still increase the CWND according > > Slow Start or Congestion Avoidance, NCR get stucked. > > > >> > >> My questions are: > >> 1) Why FlightSizePrev is used in E.2? > >> 2) Why FlightSizePrev is not recalculated in T.4? > >> > >> Thanks, > >> Lennart > > > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22222 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // > > --000e0cd6a7b27b788204a1724dd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, I read the RFC have the exactly the same questions and plus a few mo= re ...=A0

1) E.2 does not make sense that limited-transm= it is only allowed if pipe drops under FlightSizePrev =3D=3D FlightSize whe= n receiving some dubious ACK. The RFC needs some clarification for this ste= p.

2) T.4 skipping T.1 does not make sense either

3) Burst suppression in T.1 and T.2 are both MUST. I don&#= 39;t get it. Why suppress burst upon detecting reordering, not loss? are re= orderings highly correlated to cwnd size. FWIW, Linux has similar logic whi= ch I find bizarre.

4) E.6. DupThresh will keep getting larger as limited-t= ransmits increase FlightSize.=A0

Are there any stu= dies on the effectiveness of TCP-NCR? AFAIK,=A0Linux uses the scoreboard to= derive the reordering degree to compute dynamic dupthresh. The mechanism s= eems simpler and more effective.



On Tue, A= pr 19, 2011 at 5:40 AM, Alexander Zimmermann <alexander.zimmermann= @comsys.rwth-aachen.de> wrote:
BTW, if anyone other than the two co-author= has some time and is willing to help us,
especially the SACK specialists (Ilpo, Richard, Yuchung,...), be our guest.= .. :-)

Alex

Am 14.04.2011 um 18:30 schrieb Alexander Zimmermann:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Mark, Hi Ethan,
>
> here is one easy example:
>
> Receiver: =A02 =A0 =A0 4 =A0 =A0 =A01 =A0 =A0 =A06 =A0 =A0 =A03 =A0 = =A0 ...
> Sender: =A0 =A0S2 =A0 =A0S2,4 =A0 A3,S4 =A0S4,6 =A0 A5,S6
>
> 3517: =A0 =A0 =A0LT =A0 =A0LT =A0 =A0 Inc =A0 =A0LT =A0 =A0 Inc
>
> with S=3DSACK, A=3DACK, LT=3DLimited Transmit, Inc=3DCWND increase
>
>
> Am 13.04.2011 um 12:44 schrieb Lennart Schulte:
>
>> Hi folks,
>>
>> we are currently implementing TCP-NCR in Linux.
>>
>> Consider the following scenario:
>> The connection experiences a lot of reordering and all segments ca= rry
>> SACK information, even those which advance the cumulative ACK poin= t.
>> However loss recovery is never entered (reordering extent < dup= thresh).
>>
>> RFC5681 allows an increase of CWND for every ACK that advances the=
>> cumulative ACK point, even if this ACK carries SACK information, s= o CWND
>> will grow during the connection's lifetime.
>
> See example above...
>
>>
>> In contrast TCP-NCR calculates the number of segments to sent duri= ng
>> Extended Limited Transmit with FlightSizePrev (E.2).
>
> (pipe + Skipped) <=3D (FlightSizePrev - SMSS)
>
> ... and not with CWND (like 3517). Why? =3D> Main question (1)
>
>
>> Also, if an ACK
>> arrives that advances the cumulative ACK point and also carries SA= CK
>> information, it sets the CWND to no more than FlightSizePrev (T.1)= .
>> Since FlightSizePrev is held constant for such an ACK and is not s= et
>> again (T.4),
>
> Copy&Paste
>
> (T.4) When an incoming ACK extends the cumulative ACK point and also > =A0 =A0 =A0contains SACK information, the initializations in steps (I.= 2) and
> =A0 =A0 =A0(I.3) from Section 3.1 MUST be taken (but step (I.1) MUST N= OT be
> =A0 =A0 =A0executed) to re-start Extended Limited Transmit...
>
> why "(I.1) MUST NOT be executed"? =3D> Main question (2)<= br> >
>> the CWND is not allowed to increase during the whole
>> connection when there is no ACK that does not carry any SACK
>> information. With this behavior the throughput will stay very low.=
>
> In example above, RFC3517 can still increase the CWND according
> Slow Start or Congestion Avoidance, NCR get stucked.
>
>>
>> My questions are:
>> 1) Why FlightSizePrev is used in E.2?
>> 2) Why FlightSizePrev is not recalculated in T.4?
>>
>> Thanks,
>> Lennart
>

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: zimmermann@cs.rwt= h-aachen.de
// web: http://www.u= mic-mesh.net
//


--000e0cd6a7b27b788204a1724dd8-- From mallman@icir.org Thu Apr 21 14:07:01 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 896ADE0732 for ; Thu, 21 Apr 2011 14:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8RmLlSA7CrT for ; Thu, 21 Apr 2011 14:07:01 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfc.amsl.com (Postfix) with ESMTP id D13A5E070C for ; Thu, 21 Apr 2011 14:07:00 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p3LL6nN5020185; Thu, 21 Apr 2011 14:06:49 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8A73A3A90B55; Thu, 21 Apr 2011 17:06:49 -0400 (EDT) To: Lennart Schulte From: Mark Allman In-Reply-To: <4DA57E7D.6040206@comsys.rwth-aachen.de> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Nobody Told Me MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma40041-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 21 Apr 2011 17:06:49 -0400 Sender: mallman@icir.org Message-Id: <20110421210649.8A73A3A90B55@lawyers.icir.org> Cc: eblanton@cs.ohiou.edu, tcpm@ietf.org Subject: Re: [tcpm] FlightSizePrev in TCP-NCR X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 21 Apr 2011 21:07:01 -0000 ----------ma40041-1 Content-Type: text/plain Content-Disposition: inline > Consider the following scenario: The connection experiences a lot of > reordering and all segments carry SACK information, even those which > advance the cumulative ACK point. However loss recovery is never > entered (reordering extent < dupthresh). I think the real bottom line is that NCR doesn't well cover that case. The cwnd is basically held constant during the event because (1) if it is really loss then you're going to chop the cwnd in half and so who cares and (2) if it is reordering then it should be worked out in an RTT and so you lose an SMSS of cwnd growth and so who cares. And, (2) is true if it is only occasionally you see windows of packets that get jumbled up. But, if you see constant reordering RTT after RTT then I can see where that might not hold and "who cares" might be too glib. However, I guess I'd have to see some evidence that wasn't a totally pathological case before I'd buy that there was something that needed done about it. allman ----------ma40041-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2wnGkACgkQWyrrWs4yIs4YlQCfSY2uuXYdPx3u1YmUSVH3gLWO 4iIAn0CnCjzB0Cou7K2nQE0i4kBKKm5n =vYmt -----END PGP SIGNATURE----- ----------ma40041-1-- From rs@netapp.com Fri Apr 22 00:38:38 2011 Return-Path: X-Original-To: tcpm@ietfc.amsl.com Delivered-To: tcpm@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9BC71E06DB for ; Fri, 22 Apr 2011 00:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exOxnK0WRxGl for ; Fri, 22 Apr 2011 00:38:38 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfc.amsl.com (Postfix) with ESMTP id BC6FFE0679 for ; Fri, 22 Apr 2011 00:38:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,253,1301900400"; d="scan'208";a="251169124" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 22 Apr 2011 00:38:36 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p3M7cap8026623; Fri, 22 Apr 2011 00:38:36 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Apr 2011 08:38:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Apr 2011 08:38:12 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0E0624E0@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20110421210649.8A73A3A90B55@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] FlightSizePrev in TCP-NCR Thread-Index: AcwAaBb4Jyh86nFzQmSStZHUaWG93QAVzIFA References: <4DA57E7D.6040206@comsys.rwth-aachen.de> <20110421210649.8A73A3A90B55@lawyers.icir.org> From: "Scheffenegger, Richard" To: , "Lennart Schulte" X-OriginalArrivalTime: 22 Apr 2011 07:38:36.0085 (UTC) FILETIME=[49EC5E50:01CC00C0] Cc: eblanton@cs.ohiou.edu, tcpm@ietf.org Subject: Re: [tcpm] FlightSizePrev in TCP-NCR X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Apr 2011 07:38:38 -0000 Hi Mark, when I read the RFC, the authors claim that NCR is supposed to allow TCP to run unimpeded across future equipment that will introduce "heavy" (from our current understanding) reordering more or less constantly.... If this was one of the design goals, there would be a (3) where constant reordering is the norm (and not the exception), which was viewed at the time of the RFC as a design goal (section 1, 3rd point in the motivations list). Based on that, it seems that Alex and Lennart have identified a bug where the algorithm appears to contradict the design goal... Richard Scheffenegger > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org] > Sent: Donnerstag, 21. April 2011 23:07 > To: Lennart Schulte > Cc: eblanton@cs.ohiou.edu; tcpm@ietf.org > Subject: Re: [tcpm] FlightSizePrev in TCP-NCR >=20 >=20 > > Consider the following scenario: The connection experiences a lot of > > reordering and all segments carry SACK information, even those which > > advance the cumulative ACK point. However loss recovery is never > > entered (reordering extent < dupthresh). >=20 > I think the real bottom line is that NCR doesn't well cover that case. > The cwnd is basically held constant during the event because (1) if it > is really loss then you're going to chop the cwnd in half and so who > cares and (2) if it is reordering then it should be worked out in an > RTT and so you lose an SMSS of cwnd growth and so who cares. And, (2) > is true if it is only occasionally you see windows of packets that get > jumbled up. But, if you see constant reordering RTT after RTT then I > can see where that might not hold and "who cares" might be too glib. > However, I guess I'd have to see some evidence that wasn't a totally > pathological case before I'd buy that there was something that needed > done about it. >=20 > allman >=20 >=20 From Internet-Drafts@ietf.org Tue Apr 26 10:00:02 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49634E072C; Tue, 26 Apr 2011 10:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCdgHaPZxbG0; Tue, 26 Apr 2011 10:00:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB319E06A6; Tue, 26 Apr 2011 10:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110426170001.8867.52344.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2011 10:00:01 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-rfc1948bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 17:00:02 -0000 --NextPart 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 : Defending Against Sequence Number Attacks Author(s) : F. Gont, S. Bellovin Filename : draft-ietf-tcpm-rfc1948bis-00.txt Pages : 12 Date : 2011-04-22 This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker of guessing the sequence numbers in use by a target connection are reduced. This document is a revision of RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc1948bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-rfc1948bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-26095339.I-D@ietf.org> --NextPart-- From fernando.gont.netbook.win@gmail.com Tue Apr 26 16:30:27 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F525E07DA for ; Tue, 26 Apr 2011 16:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPNWreANJ581 for ; Tue, 26 Apr 2011 16:30:26 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D295E07A3 for ; Tue, 26 Apr 2011 16:30:26 -0700 (PDT) Received: by gyf3 with SMTP id 3so505235gyf.31 for ; Tue, 26 Apr 2011 16:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=RSefwAG6BvUf+SMyt0qtVsrNXrYvDmrtcJEsU9gERpk=; b=fqW4mKeBlHrKr/mPAtVcLQT7rpV7vERGl7Aj5yM+1ZFJBiHGWWaVCyyEnPXLOYPZ/V xCkHp/WJk0fRaCzE7Qpx9hAaccEh8wbtq1R+KQtx+cG6pc+qzOSGgB+MAhastl5K+Q// tvOhs7hW2cBIko6qEF6wIG9GFVo67Gq6/a1Rg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=pJZEWyGC4YvNYl9242bioofZq9KVSoyfEO6+Ln02btrJZk9vggAgBcwjmenKVlu5v8 izdzt86E12tk0cx/CUGW+yidFYfF7PGVdq9KXMhdl3RvxQMJwT+sem1NUbbNv8oiAsv5 p+rt04EvwCIdNQim2yu9LCVkbye5B9HQqyhpw= Received: by 10.150.168.3 with SMTP id q3mr1176103ybe.398.1303860625638; Tue, 26 Apr 2011 16:30:25 -0700 (PDT) Received: from [192.168.1.113] (cianita.frh.utn.edu.ar [170.210.17.149]) by mx.google.com with ESMTPS id q18sm550349ybk.11.2011.04.26.16.30.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 16:30:25 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DB7558C.9000503@gont.com.ar> Date: Tue, 26 Apr 2011 20:30:20 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tcpm] New revision of draft-ietf-tcpm-rfc1948bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 23:30:27 -0000 Folks, We have published a revision of the aforementioned I-D, which aims at addressing the comments that we received since the publication of the first (individual) version of the I-D. Please let me know if you feel that there are any comments that still need to be addressed, or if you have any further suggestions. Thanks! P.S.: For your convenience, the diff from the last version of the I-D is available at: Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From mattmathis@google.com Thu Apr 28 05:37:09 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9086FE06A7 for ; Thu, 28 Apr 2011 05:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xojc2WBmK2Zc for ; Thu, 28 Apr 2011 05:37:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 96780E0674 for ; Thu, 28 Apr 2011 05:37:08 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p3SCb7hp031504 for ; Thu, 28 Apr 2011 05:37:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303994227; bh=07o8PcHc4wPRheQlkTbcyAfsj3M=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Z/pp6unYVzFk3lxDHtYqkWt+k4O3XMuqoHnDTgeRXgGvvYxiIil2t6mH1bc1mU/yx DVWABIWftLIZJNr2lw3Uw== Received: from eyd9 (eyd9.prod.google.com [10.208.4.9]) by hpaq14.eem.corp.google.com with ESMTP id p3SCb51U012413 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 28 Apr 2011 05:37:06 -0700 Received: by eyd9 with SMTP id 9so1168570eyd.14 for ; Thu, 28 Apr 2011 05:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5PWXSc0uuuE7gKgRBTrNOL5taoZ8OQajEGeNjGSI88U=; b=NVSy75QtKuZYcXlybi6jrVBRyVHRKeQwxVEVGd6QCcSG+uXddWyew4ZPIvb7j7iEf2 M3foeNWLA0Pengpp/KQA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CKQR346t2lMvCLswYVu9MR64ajZ6+s4SugOakvD7jKoOZlvVsxadkz9YxwWKLaL+/I VIDqwyDfpeIDJGjHuCXQ== MIME-Version: 1.0 Received: by 10.213.21.2 with SMTP id h2mr2856461ebb.51.1303994225582; Thu, 28 Apr 2011 05:37:05 -0700 (PDT) Received: by 10.213.104.139 with HTTP; Thu, 28 Apr 2011 05:37:05 -0700 (PDT) In-Reply-To: <201104181447.p3IElwLI025952@cichlid.raleigh.ibm.com> References: <201104181447.p3IElwLI025952@cichlid.raleigh.ibm.com> Date: Thu, 28 Apr 2011 08:37:05 -0400 Message-ID: From: Matt Mathis To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] pmtu discovery (RFC 4821) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 12:37:09 -0000 Sorry I missed this earlier... On Mon, Apr 18, 2011 at 10:47 AM, Thomas Narten wrote: > What is the status of RFC 4821 uptake? > > What is the current thinking w.r.t. 4821? Is it still considered the > Right Thing to implement? Or have implementation attempts concluded > its too complex to implement? Or? I believe the Linux implementation for TCP is complete, but configured for "black hole" detection only. We wanted to configure it for opportunistic jumbo detection, but there was an unanticipated driver problem. Basically the MTU/MRU has to be selected when the NIC is initialized, before it can learn anything about the network. If you set the NIC MTU up, then you lower its performance on 1500 Byte networks. I was also told that it was on the tentative manifest for some now past Microsoft release, but I have no idea if it actually made it. > The 6man WG is updating the Node Requirements document, and it was > suggested that it add a recommendation for 4821. The current RFC > (4294) was written before RFC 4821. > > Thoughts? I have always thought the IPv6 approach of mandating at least 1280 Bytes and everyone just presuming that the network was going to magically deliver such a mandate was asking for troubles, especially in the presence of tunnels, etc. So yes I would require 4821 for black hole detection. The hard part (politically) is you SHOULD probe below 1280 bytes. Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay From perfgeek@mac.com Thu Apr 28 08:39:48 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3577E0685 for ; Thu, 28 Apr 2011 08:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+adxq5gDIXH for ; Thu, 28 Apr 2011 08:39:47 -0700 (PDT) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by ietfa.amsl.com (Postfix) with ESMTP id 31FA2E0669 for ; Thu, 28 Apr 2011 08:39:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp014.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LKD00MKBCTT1T00@asmtp014.mac.com> for tcpm@ietf.org; Thu, 28 Apr 2011 08:39:31 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-04-28_06:2011-04-28, 2011-04-28, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1104280086 Message-id: From: rick jones To: Matt Mathis In-reply-to: Date: Thu, 28 Apr 2011 08:39:28 -0700 References: <201104181447.p3IElwLI025952@cichlid.raleigh.ibm.com> X-Mailer: Apple Mail (2.936) Cc: Thomas Narten , tcpm@ietf.org Subject: Re: [tcpm] pmtu discovery (RFC 4821) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 15:39:48 -0000 On Apr 28, 2011, at 5:37 AM, Matt Mathis wrote: > Sorry I missed this earlier... > > On Mon, Apr 18, 2011 at 10:47 AM, Thomas Narten > wrote: >> What is the status of RFC 4821 uptake? >> >> What is the current thinking w.r.t. 4821? Is it still considered the >> Right Thing to implement? Or have implementation attempts concluded >> its too complex to implement? Or? > > I believe the Linux implementation for TCP is complete, but configured > for "black hole" detection only. We wanted to configure it for > opportunistic jumbo detection, but there was an unanticipated driver > problem. Basically the MTU/MRU has to be selected when the NIC is > initialized, before it can learn anything about the network. If you > set the NIC MTU up, then you lower its performance on 1500 Byte > networks. I like MTU's larger than 1500 bytes, and I may be mixing things incorrectly, but in the presence of TSO and GRO in the NICs isn't trying to find a larger MTU/MRU something of a diminished return? (IMO) The biggest bang from larger MTUs was the reduction of trips up and down the protocol stack, not the improvement in the ratio of data to data+headers. rick jones > > I was also told that it was on the tentative manifest for some now > past Microsoft release, but I have no idea if it actually made it. > >> The 6man WG is updating the Node Requirements document, and it was >> suggested that it add a recommendation for 4821. The current RFC >> (4294) was written before RFC 4821. >> >> Thoughts? > > I have always thought the IPv6 approach of mandating at least 1280 > Bytes and everyone just presuming that the network was going to > magically deliver such a mandate was asking for troubles, especially > in the presence of tunnels, etc. So yes I would require 4821 for > black hole detection. The hard part (politically) is you SHOULD > probe below 1280 bytes. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm Wisdom teeth are impacted, people are affected by the effects of events From touch@isi.edu Thu Apr 28 11:42:14 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8BCE06DB for ; Thu, 28 Apr 2011 11:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIPurY+GVFH9 for ; Thu, 28 Apr 2011 11:42:13 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfa.amsl.com (Postfix) with ESMTP id AB645E0669 for ; Thu, 28 Apr 2011 11:42:13 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p3SIg4Vi015385 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 28 Apr 2011 11:42:04 -0700 (PDT) Message-ID: <4DB9B4FC.7020507@isi.edu> Date: Thu, 28 Apr 2011 11:42:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: rick jones References: <201104181447.p3IElwLI025952@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p3SIg4Vi015385 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Thomas Narten , tcpm@ietf.org, Matt Mathis Subject: Re: [tcpm] pmtu discovery (RFC 4821) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 18:42:14 -0000 On 4/28/2011 8:39 AM, rick jones wrote: ... > I like MTU's larger than 1500 bytes, and I may be mixing things > incorrectly, but in the presence of TSO and GRO in the NICs isn't trying > to find a larger MTU/MRU something of a diminished return? (IMO) The > biggest bang from larger MTUs was the reduction of trips up and down the > protocol stack, not the improvement in the ratio of data to data+headers. Larger MTUs reduces thrashing contexts in the up/down stack processing, and reduces the per-byte computation overheads. I don't think the returns are diminishing - going to 3000-byte packets halves the CPU processing for transport and network protocols, the interrupts or polling involved, etc. I.e., it's not just about bandwidth overhead. Most protocol operations (except checksums, which are largely in hardware, and security protocols) are per packet, not per byte. This allows more data for a given header rate, which reduces system load for a given data capacity (or supports higher capacity, depending on how you view it). Joe From touch@isi.edu Thu Apr 28 13:26:00 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58471E069A for ; Thu, 28 Apr 2011 13:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.531 X-Spam-Level: X-Spam-Status: No, score=-104.531 tagged_above=-999 required=5 tests=[AWL=1.468, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlSYgP3zg9w2 for ; Thu, 28 Apr 2011 13:25:59 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B1F3AE0679 for ; Thu, 28 Apr 2011 13:25:59 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p3SKPRi6024575 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 28 Apr 2011 13:25:27 -0700 (PDT) Message-ID: <4DB9CD37.8020106@isi.edu> Date: Thu, 28 Apr 2011 13:25:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: timothyhartrick@gmail.com References: <201104181447.p3IElwLI025952@cichlid.raleigh.ibm.com> <4DB9B4FC.7020507@isi.edu> <1304021611.3998.11.camel@feller> In-Reply-To: <1304021611.3998.11.camel@feller> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Thomas Narten , tcpm@ietf.org, Matt Mathis Subject: Re: [tcpm] pmtu discovery (RFC 4821) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Apr 2011 20:26:00 -0000 Hi, Tim, On 4/28/2011 1:13 PM, Tim Hartrick wrote: > > > Joe, > > But.... Rick's point was that TSO and GRO have moved the non-checksum, > per-packet protocol operations into hardware as well. The consequence > of this is that stacks now consume less CPU using 1500 byte MTUs with > TSO and GRO than they would using jumbo MTUs without TSO and GRO. It is > certainly true using TSO and GRO with jumbo MTUs would reduce the load > even further but at the cost of added complexity of detecting the > presence of jumbo MTU capability. Thus the reference to diminishing > returns.... Per-byte operations in hardware are typically designed to support some existing data rate limit, e.g., PCI bus limits, link limits, etc. Per-packet offload support is not always designed to those max rates. When they are, then there are diminishing returns for those external devices. There are still operations that involve the CPU; when they are proportional to the number of packets, reducing the number of packets can help. I think we're all on the same page; my points were for clarification, not disagreement. Joe > On Thu, 2011-04-28 at 11:42 -0700, Joe Touch wrote: >> >> On 4/28/2011 8:39 AM, rick jones wrote: >> ... >>> I like MTU's larger than 1500 bytes, and I may be mixing things >>> incorrectly, but in the presence of TSO and GRO in the NICs isn't trying >>> to find a larger MTU/MRU something of a diminished return? (IMO) The >>> biggest bang from larger MTUs was the reduction of trips up and down the >>> protocol stack, not the improvement in the ratio of data to data+headers. >> >> Larger MTUs reduces thrashing contexts in the up/down stack processing, >> and reduces the per-byte computation overheads. I don't think the >> returns are diminishing - going to 3000-byte packets halves the CPU >> processing for transport and network protocols, the interrupts or >> polling involved, etc. >> >> I.e., it's not just about bandwidth overhead. Most protocol operations >> (except checksums, which are largely in hardware, and security >> protocols) are per packet, not per byte. This allows more data for a >> given header rate, which reduces system load for a given data capacity >> (or supports higher capacity, depending on how you view it). >> >> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From alexander.zimmermann@comsys.rwth-aachen.de Fri Apr 29 07:22:25 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D21E0772 for ; Fri, 29 Apr 2011 07:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OmuYukFbz8A for ; Fri, 29 Apr 2011 07:22:21 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4B4E06BF for ; Fri, 29 Apr 2011 07:22:21 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LKF00HIT3X71PJ0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Fri, 29 Apr 2011 16:22:19 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.64,287,1301868000"; d="sig'?scan'208";a="53834419" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Fri, 29 Apr 2011 16:22:19 +0200 Received: from [IPv6:::1] ([unknown] [137.226.54.2]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LKF00NKZ3X64A40@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Fri, 29 Apr 2011 16:22:19 +0200 (CEST) From: Alexander Zimmermann Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-7--637777094 Content-transfer-encoding: 7bit Date: Fri, 29 Apr 2011 16:22:17 +0200 Message-id: <42F62298-4BDB-4D3E-992D-E7799BC8C6D6@comsys.rwth-aachen.de> To: Ethan Blanton , Mark Allman X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: "tcpm@ietf.org Extensions" Subject: [tcpm] 3517bis - do we need an Update() call? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 14:22:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-7--637777094 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi Ethan, hi Mark, I have the feeling that we have a little inconsistency in the current spec. IMHO we need a "Update()" call between Step 3.1 and Step 3.2. Like (B.1 and B.2)... Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-7--637777094 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk26yZkACgkQdyiq39b9uS6/JQCgwS06JvA4CxAAck3BJ9dMlEVF VIMAoOVmLgNk3KkW7C0hRwoHX/INjxkJ =OGI3 -----END PGP SIGNATURE----- --Apple-Mail-7--637777094-- From alexander.zimmermann@comsys.rwth-aachen.de Fri Apr 29 07:29:04 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FCFE0693 for ; Fri, 29 Apr 2011 07:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcaHChgbSjmT for ; Fri, 29 Apr 2011 07:29:00 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8D135E075B for ; Fri, 29 Apr 2011 07:29:00 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LKF006G348BCXG0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Fri, 29 Apr 2011 16:28:59 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.64,288,1301868000"; d="sig'?scan'208";a="109338664" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 29 Apr 2011 16:28:56 +0200 Received: from [IPv6:::1] ([unknown] [137.226.54.2]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LKF00NOS4874A40@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Fri, 29 Apr 2011 16:28:56 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-8--637379092 From: Alexander Zimmermann In-reply-to: <42F62298-4BDB-4D3E-992D-E7799BC8C6D6@comsys.rwth-aachen.de> Date: Fri, 29 Apr 2011 16:28:55 +0200 Content-transfer-encoding: 7bit Message-id: References: <42F62298-4BDB-4D3E-992D-E7799BC8C6D6@comsys.rwth-aachen.de> To: Ethan Blanton , Mark Allman X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] 3517bis - do we need an Update() call? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 14:29:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-8--637379092 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mia culpa, the step is included in the first sentence of Section 5. Sorry for making noise... Am 29.04.2011 um 16:22 schrieb Alexander Zimmermann: > Hi Ethan, hi Mark, > > I have the feeling that we have a little inconsistency in the > current spec. IMHO we need a "Update()" call between Step 3.1 > and Step 3.2. Like (B.1 and B.2)... > > Alex > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-8--637379092 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk26yycACgkQdyiq39b9uS7yFACg9dyVtP6k7SAqdjcORtDfXG/7 cbIAn0SsNZtt2kGgqAMydMw8sgcqbMVB =8gQr -----END PGP SIGNATURE----- --Apple-Mail-8--637379092-- From timothyhartrick@gmail.com Thu Apr 28 13:14:16 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AC7E0733 for ; Thu, 28 Apr 2011 13:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50C56KRpN9fD for ; Thu, 28 Apr 2011 13:14:15 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 793C8E072D for ; Thu, 28 Apr 2011 13:13:43 -0700 (PDT) Received: by gxk19 with SMTP id 19so1406097gxk.31 for ; Thu, 28 Apr 2011 13:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:from:reply-to:to:cc:in-reply-to :references:content-type:organization:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=LHPaj2J54OWK0n4gWQzKW8CPrMIJv4cI6PH/mGc0PT4=; b=PiuG2xQY+Ue3aIoaZ0JbyEzDliS/SU7ZIDab11MZ+0AttEGy5QHeQ2Ulmf1Yl/Af3f OCr3t4chLndUB4jvBunQlBrQdxfFH9HMYwENOEPACRwXF8zSacO7GRQ1Eal1FoShVWZ8 aTySuqJWW4lSv9J4eYsMbMQiMWFBojdK+hE1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :organization:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=KK9yUrvATb4n5ui67PrPdCQnuf69wUzcBxGiF10FkyabL5nsrLXdzbJN38s1NSmUwf DJw3eDo74JYtmZIcwlU5apYY/VqADTyErSSpGz3mg8Kv6YNq5zJDV5cgTjEOiltNK5Ks OcpdX88FFd/8yqXiRR0OWEj09mBUqfT2S7jf4= Received: by 10.150.141.17 with SMTP id o17mr3511522ybd.85.1304021622753; Thu, 28 Apr 2011 13:13:42 -0700 (PDT) Received: from [192.168.29.48] ([67.41.221.225]) by mx.google.com with ESMTPS id p28sm1444042ybk.15.2011.04.28.13.13.40 (version=SSLv3 cipher=OTHER); Thu, 28 Apr 2011 13:13:41 -0700 (PDT) From: Tim Hartrick To: Joe Touch In-Reply-To: <4DB9B4FC.7020507@isi.edu> References: <201104181447.p3IElwLI025952@cichlid.raleigh.ibm.com> <4DB9B4FC.7020507@isi.edu> Content-Type: text/plain; charset="UTF-8" Organization: Tim Hartrick Date: Thu, 28 Apr 2011 14:13:31 -0600 Message-ID: <1304021611.3998.11.camel@feller> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 (2.30.3-1.fc13) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Apr 2011 08:07:16 -0700 Cc: Thomas Narten , tcpm@ietf.org, Matt Mathis Subject: Re: [tcpm] pmtu discovery (RFC 4821) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: timothyhartrick@gmail.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 20:14:16 -0000 Joe, But.... Rick's point was that TSO and GRO have moved the non-checksum, per-packet protocol operations into hardware as well. The consequence of this is that stacks now consume less CPU using 1500 byte MTUs with TSO and GRO than they would using jumbo MTUs without TSO and GRO. It is certainly true using TSO and GRO with jumbo MTUs would reduce the load even further but at the cost of added complexity of detecting the presence of jumbo MTU capability. Thus the reference to diminishing returns.... Tim Hartrick On Thu, 2011-04-28 at 11:42 -0700, Joe Touch wrote: > > On 4/28/2011 8:39 AM, rick jones wrote: > ... > > I like MTU's larger than 1500 bytes, and I may be mixing things > > incorrectly, but in the presence of TSO and GRO in the NICs isn't trying > > to find a larger MTU/MRU something of a diminished return? (IMO) The > > biggest bang from larger MTUs was the reduction of trips up and down the > > protocol stack, not the improvement in the ratio of data to data+headers. > > Larger MTUs reduces thrashing contexts in the up/down stack processing, > and reduces the per-byte computation overheads. I don't think the > returns are diminishing - going to 3000-byte packets halves the CPU > processing for transport and network protocols, the interrupts or > polling involved, etc. > > I.e., it's not just about bandwidth overhead. Most protocol operations > (except checksums, which are largely in hardware, and security > protocols) are per packet, not per byte. This allows more data for a > given header rate, which reduces system load for a given data capacity > (or supports higher capacity, depending on how you view it). > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From johnwheffner@gmail.com Fri Apr 29 08:17:44 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54737E077F for ; Fri, 29 Apr 2011 08:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZryf1-2DDnF for ; Fri, 29 Apr 2011 08:17:43 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F726E0720 for ; Fri, 29 Apr 2011 08:17:43 -0700 (PDT) Received: by bwz13 with SMTP id 13so3708766bwz.31 for ; Fri, 29 Apr 2011 08:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9KYZO+vl2GyaITFgwQxKCunxcU/IaXnOgzjryNPS314=; b=d1Yqb10zVXmAkebgylD/K+4lIAPvr+Q9668dMypIOsdHSSt0Uawd4Wp5p2plk9eSOp xfBhAZfR03ccHy8wb44ahXAiu01Ac0J5obdcAw3i7YW2x3oSIWWtUD0pquqZBjywlUub OR2RBmShUiSYv4aFVPzJktuyrXSkbAC7veiKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hbqpKv2yypSu+8cY/Ne5CcRlB1vKQnUJJRw72c4Sb9Si8XI0RcE7z2tmkhVD0Mh31S X8Cd1QaQ9ilPMjU3IGkbf56mAK8eprvX5Jg3s/ZP0OtYgKeSyPyfOPtWhI3j4VKA95jF yCXSSa6UfcfQa270ntNr+vEmSUbApFYjQ6bWE= MIME-Version: 1.0 Received: by 10.204.16.70 with SMTP id n6mr753741bka.87.1304090262498; Fri, 29 Apr 2011 08:17:42 -0700 (PDT) Received: by 10.204.117.78 with HTTP; Fri, 29 Apr 2011 08:17:42 -0700 (PDT) In-Reply-To: References: <201104181447.p3IElwLI025952@cichlid.raleigh.ibm.com> Date: Fri, 29 Apr 2011 11:17:42 -0400 Message-ID: From: John Heffner To: rick jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] pmtu discovery (RFC 4821) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 15:17:44 -0000 On Thu, Apr 28, 2011 at 11:39 AM, rick jones wrote: > > On Apr 28, 2011, at 5:37 AM, Matt Mathis wrote: > >> Sorry I missed this earlier... >> >> On Mon, Apr 18, 2011 at 10:47 AM, Thomas Narten wrot= e: >>> >>> What is the status of RFC 4821 uptake? >>> >>> What is the current thinking w.r.t. 4821? Is it still considered the >>> Right Thing to implement? Or have implementation attempts concluded >>> its too complex to implement? Or? >> >> I believe the Linux implementation for TCP is complete, but configured >> for "black hole" detection only. =A0 We wanted to configure it for >> opportunistic jumbo detection, but there was an unanticipated driver >> problem. =A0Basically the MTU/MRU has to be selected when the NIC is >> initialized, before it can learn anything about the network. =A0If you >> set the NIC MTU up, then you lower its performance on 1500 Byte >> networks. > > I like MTU's larger than 1500 bytes, and I may be mixing things incorrect= ly, > but in the presence of TSO and GRO in the NICs isn't trying to find a lar= ger > MTU/MRU something of a diminished return? =A0(IMO) The biggest bang from > larger MTUs was the reduction of trips up and down the protocol stack, no= t > the improvement in the ratio of data to data+headers. It feels like this discussion is going off on a tangent, but I'll note there are still a few big wins a large paht MTU has over stateless offload, especially on a WAN: o Most congestion control algorithms operate on a per-segment basis, and thus have an MSS term in the steady state throughput formula. A larger path MTU helps alleviate congestion control scaling issues. o No current stacks I know of have a loss scoreboard implementation that is O(1) on a per-segment basis. (Most have constant lookup optimisations for the typical case. Some like FreeBSD bound the maximum number of losses tracked, making it constant in theory as long as you don't increase that bound.. but then you rely on timeouts at larger window sizes.) A larger path MTU makes the scoreboard more efficient with large window sizes. -John From cait@asomi.com Fri Apr 29 09:39:46 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D54E06BD for ; Fri, 29 Apr 2011 09:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t65o3cmqrOle for ; Fri, 29 Apr 2011 09:39:42 -0700 (PDT) Received: from smtpauth01.prod.mesa1.secureserver.net (smtpauth01.prod.mesa1.secureserver.net [64.202.165.181]) by ietfa.amsl.com (Postfix) with SMTP id 0FA3CE069F for ; Fri, 29 Apr 2011 09:39:41 -0700 (PDT) Received: (qmail 11866 invoked from network); 29 Apr 2011 16:39:41 -0000 Received: from unknown (108.80.57.164) by smtpauth01.prod.mesa1.secureserver.net (64.202.165.181) with ESMTP; 29 Apr 2011 16:39:41 -0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Caitlin Bestler In-Reply-To: <1304021611.3998.11.camel@feller> Date: Fri, 29 Apr 2011 09:39:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201104181447.p3IElwLI025952@cichlid.raleigh.ibm.com> <4DB9B4FC.7020507@isi.edu> <1304021611.3998.11.camel@feller> To: timothyhartrick@gmail.com X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , tcpm@ietf.org, Matt Mathis , Joe Touch Subject: Re: [tcpm] pmtu discovery (RFC 4821) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 16:39:46 -0000 On Apr 28, 2011, at 1:13 PM, Tim Hartrick wrote: >=20 >=20 > Joe, >=20 > But.... Rick's point was that TSO and GRO have moved the = non-checksum, > per-packet protocol operations into hardware as well. The consequence > of this is that stacks now consume less CPU using 1500 byte MTUs with > TSO and GRO than they would using jumbo MTUs without TSO and GRO. It = is > certainly true using TSO and GRO with jumbo MTUs would reduce the load > even further but at the cost of added complexity of detecting the > presence of jumbo MTU capability. Thus the reference to diminishing > returns.... >=20 >=20 >=20 Whether or not a host uses hardware is irrelevant. It is still work that = the host has to do. A 63K tcp message is still more Ethernet frames when the PMTU is 1500 than it is when the PMTU is 9K. Each of those frames needs to = establish at least the context of the TCP message, even if establishing the full = context of the TCP connection is deferred until the full message is received. Now admittedly, if the message does not get interleaved with other = traffic then the cost of establishing the context of an already loaded TCP = message is exceedingly small. But it is something that must be done for LRO = algorithms whether that work is being done in hardware or a device driver. So clearly a larger MTU will always benefit hosts, even if the benefit = has been properly limited to only restoring the context of a specific TCP message = rather than requiring the restoration of the context for the full TCP = connection. The real tradeoff is one of optimizing for the hosts versus the = forwarding elements. Larger frame sizes make efficient memory allocation in the network more problematic. But nobody forces switches or routers to support larger MTUs. I can't think of any reason not to take advantage when working at L3 and above not to just take what L2 is willing to = provide. If any switch vendors think the standards are pushing larger MTUs to the detriment of the network then they should make that argument. But larger MTUs mean less work for IP hosts, wherever the host chooses to do its work. -- Caitlin Bestler cait@asomi.com http://www.asomi.com/CaitlinBestlerResume.html From rs@netapp.com Sat Apr 30 02:11:28 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD2AE06E5 for ; Sat, 30 Apr 2011 02:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.545 X-Spam-Level: X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXRzEf9mGtxb for ; Sat, 30 Apr 2011 02:11:27 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7C6E06E4 for ; Sat, 30 Apr 2011 02:11:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,292,1301900400"; d="scan'208";a="252466896" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 30 Apr 2011 02:11:25 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p3U9BOEN005265; Sat, 30 Apr 2011 02:11:25 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 30 Apr 2011 10:11:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Apr 2011 10:11:03 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0E190E33@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20110418175032.E9AB73A356D8@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) Thread-Index: Acv9+cQrdnSGpQxJRJSUnQ7Y+JcyiAJGXqYQ References: <20110418175032.E9AB73A356D8@lawyers.icir.org> From: "Scheffenegger, Richard" To: , "Yoshifumi Nishida" X-OriginalArrivalTime: 30 Apr 2011 09:11:24.0308 (UTC) FILETIME=[9425C540:01CC0716] Cc: tcpm@ietf.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2011 09:11:28 -0000 Hi, I have been thinking about this a little bit more. There may be one peculiar corner case with the new Rule 4; I believe = it's probably out-of-scope for 3517bis, but would like to point it out = nevertheless. > (4) If the conditions for rules (1), (2) and (3) fail, but there > exists outstanding and unSACKed data we provide the opportunity > for a single "rescue" retransmission. If HighACK is greater = than > RescueRxt then one segment of up to SMSS octets that includes = the > highest outstanding unSACKed sequence number SHOULD be returned. > Further, RescueRxt MUST be set to RecoveryPoint. Finally, > HighRxt MUST NOT be updated. The issue revolves around the observation, that with tail-drop there are = often periods of burst loss (a number of consecutive packets of a = session get lost). During a good fraction of these events, a number of = retransmitted packets are still encountering the network condition that = led to the loss, and are lost too... The very first retransmitted packet = (which would change HighAck) is particularly vulnerable to encounter = such a condition, unfortunately. The senders sharing the bottleneck may = have not yet reacted to reduce their sending rate enough, when the = sender(s) with the lowest RTT is staring the retransmission. Given the following events (segments sent/lost), S0 XX S2 S3 S4 XX S6 XX XX |(end of stream) XX S5=20 Rule 4 would not trigger even when another retransmitted segment (S5) = was successfully received (and S1, S7, S8 would require a RTO to = recover). Anyway, lost retransmissions themselves are out-of-scope for 3517 (and = at the root of this corner case is a lost retransmission). So I don't = think addressing this particular instance has to be done there. However, = if someone implements the Rule 4 above in a stack that does = lost-retransmission recovery (ie. Linux), the statement "HighACK is = greater than RescueRxt" may need to be expanded to include SACKed = octets. For example, if a newly arrived ACK SACKs bytes below FACK, but = doesn't advance FACK (some hole closes at least partially in the senders = SACK datastructure), that could also be a valid trigger for Rule 4. Just = using SACK information alone, such a heuristic would still be prone to = be triggered by delayed original segments as well as true = retransmissions. But the case has been made, that a single = retransmission (of S8 in the above example) would be acceptable... Richard Scheffenegger > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org] > Sent: Montag, 18. April 2011 19:51 > To: Yoshifumi Nishida > Cc: tcpm@ietf.org" > Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss > recovery (TCP SACK) ) >=20 >=20 > > Filename: draft-nishida-tcpm-rescue-retransmission >=20 > First, I must say its a nicely clever trick, Yoshifumi. The neat > observation is that by sending one segment per loss event you can > encourage the information needed to let the standard 3517 algorithm = fix > end-of-window loss. >=20 > The basic idea here is that when you're stuck and cannot send anything > according to RFC3517 (and the bis) the algorithm is extended to allow > sending the last unSACKed packet again. This, in turn, triggers an = ACK > with new SACK information that can further prod the loss recovery > process. (Details are in Yoshifumi's draft). >=20 > Second, the proposed fix isn't quite right, IMO. Consider the case of > sending 6 segments (cwnd=3D6), losing only segment #1 and having no > further data to send. So, this is what arrives at and is sent by the > data sender: >=20 > 1. ACK 1, SACK 2:2 > [do nothing] > 2. ACK 1, SACK 2:3 > [do nothing] > 3. ACK 1, SACK 2:4 > --> cwnd =3D FlightSize / 2 =3D 3, pipe =3D 2 (segs 5 & 6) > --> retransmit segment 1, pipe =3D 3 (segs 1(rxt), 5 & 6) > 4. ACK 1, SACK 2:5 > --> pipe =3D 2 (segs 1(rxt) & 6) > --> we have no data judged as having been lost ((1) in > NextSeg()) > --> we have no new data to send ((2) in NextSeg()) > --> we have no "last resort" data to send ((3) in NextSeg()), > i.e., unSACKed data not judged as lost, but with SACKed > data > above it) > --> so, we invoke the proposed (4) in NextSeg() and transmit > the > segment at the end of the window, or segment 6 > 5. ACK 1, SACK 2:6 > 6. ACK 7 > 7. ACK 7, (DSACK 6, if supported) >=20 > In this case we just don't wait long enough to re-send this rescue > packet (step 4 above) and so we really have no idea if the end of the > window has been lost or not (and, in the above example it has not and > so the retransmit is spurious). In step 4 above we cannot possibly > have gained an understanding about the end of the window. >=20 > Third, this failure mode is readily fixed by forcing the rescue > retransmit to happen an RTT after loss recovery has started (i.e., to > ensure all ACKs for the window of data that experienced loss roll in > first). This is easy enough. When loss recovery is initiated we set > RescueRxt to the highest octet of the first retransmission. Now, rule > (4) in NextSeg() >=20 > =A0 (4) If the conditions for rules (1), (2) and (3) fail, but there > =A0 =A0 exists outstanding and unSACKed data we provide the = opportunity > =A0 =A0 =A0 for a single "rescue" retransmission. =A0If HighACK is = greater than > =A0 =A0 =A0 RescueRxt then one segment of up to SMSS octets that = includes the > =A0 =A0 =A0 highest outstanding unSACKed sequence number SHOULD be = returned. > =A0 =A0 =A0 Further, RescueRxt MUST be set to RecoveryPoint. = =A0Finally, > =A0 =A0 =A0 HighRxt MUST NOT be updated. >=20 > I.e., before we can send a rescue segment the first segment > retransmitted must be ACKed (ensuring an RTT has passed). >=20 > Finally, contrary to my usual mantra of keeping 3517bis clean and only > including well-understood things and not gooping it up, I think this > change [including the fix above] may well be OK. I think that for > several reasons: >=20 > (1) The change does not alter any of the *actions* or algorithms of > RFC3517. Rather, the change turns a current inaction into an > action. Therefore, the implications are easier to understand. >=20 > (2) RFC3517 strives to fix all loss within an RTT of loss detection. > Therefore, by pushing this rescue transmission to at least an = RTT > after the guts of the algorithm has been completed we are > reducing > the possible interactions and badness. >=20 > (3) The scope of the proposed change is quite small. The change > allows for **one** additional packet transmission **per loss > event**. This packet is meant to then coax us into a regime > where > the already understood parts of RFC3517 take over and fix things > up. So, even if we needlessly retransmit this rescue packet its > just one packet per event and at that rate cannot likely cause > any > damage to the network, competing traffic or the connection > itself. And, if it is spurious it isn't going to add any > information to change the behavior of the algorithm that won't > come along anyway. >=20 > So, I'm all for rolling this nifty little tweak in. >=20 > allman >=20 >=20 From mallman@icir.org Sat Apr 30 19:10:23 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDCFE06FD for ; Sat, 30 Apr 2011 19:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDWw51WRN1ys for ; Sat, 30 Apr 2011 19:10:23 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABC9E06AF for ; Sat, 30 Apr 2011 19:10:23 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p412ALbM003637; Sat, 30 Apr 2011 19:10:21 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 62C093BB2DFE; Sat, 30 Apr 2011 22:10:21 -0400 (EDT) To: "Scheffenegger, Richard" From: Mark Allman In-Reply-To: <5FDC413D5FA246468C200652D63E627A0E190E33@LDCMVEXC1-PRD.hq.netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Dead Flowers MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma49421-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 30 Apr 2011 22:10:21 -0400 Sender: mallman@icir.org Message-Id: <20110501021021.62C093BB2DFE@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 01 May 2011 02:10:23 -0000 ----------ma49421-1 Content-Type: text/plain Content-Disposition: inline > Anyway, lost retransmissions themselves are out-of-scope for 3517 Exactly. > (and at the root of this corner case is a lost retransmission). So I > don't think addressing this particular instance has to be done > there. However, if someone implements the Rule 4 above in a stack that > does lost-retransmission recovery (ie. Linux), the statement "HighACK > is greater than RescueRxt" may need to be expanded to include SACKed > octets. For example, if a newly arrived ACK SACKs bytes below FACK, > but doesn't advance FACK (some hole closes at least partially in the > senders SACK datastructure), that could also be a valid trigger for > Rule 4. Just using SACK information alone, such a heuristic would > still be prone to be triggered by delayed original segments as well as > true retransmissions. But the case has been made, that a single > retransmission (of S8 in the above example) would be acceptable... Yes, if you do something different then you'll have to do something else different, too. allman ----------ma49421-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk28wQ0ACgkQWyrrWs4yIs4MqgCgiWbrVy2y49w0mximOz4anfan vkwAn2/fxju3gvOXNFA6PpA/NqV+ZXt4 =puSR -----END PGP SIGNATURE----- ----------ma49421-1--