From tsabatini@hotmail.com Wed Aug 1 12:23:45 2012 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 0F53D11E80D7 for ; Wed, 1 Aug 2012 12:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YugjIpLEzm71 for ; Wed, 1 Aug 2012 12:23:44 -0700 (PDT) Received: from blu0-omc4-s9.blu0.hotmail.com (blu0-omc4-s9.blu0.hotmail.com [65.55.111.148]) by ietfa.amsl.com (Postfix) with ESMTP id 78A8D11E80D5 for ; Wed, 1 Aug 2012 12:23:44 -0700 (PDT) Received: from BLU0-SMTP412 ([65.55.111.137]) by blu0-omc4-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Aug 2012 12:23:43 -0700 X-Originating-IP: [184.71.189.194] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Received: from [172.16.3.246] ([184.71.189.194]) by BLU0-SMTP412.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Aug 2012 12:23:39 -0700 Date: Wed, 1 Aug 2012 15:23:26 -0400 From: Anthony Sabatini To: "Scheffenegger, Richard" , tcpm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 01 Aug 2012 19:23:40.0238 (UTC) FILETIME=[281316E0:01CD701B] Cc: "Matthew Mathis \(mattmathis@google.com\)" Subject: [tcpm] Settling Time and RFC3517bis 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, 01 Aug 2012 19:23:45 -0000 U2V0dGxpbmcgVGltZSBpcyB0aGUgY29uY2VwdCBvZiBob3cgbG9uZyB3ZSB3YWl0IGZvciBhbiBv dXQgb2Ygb3JkZXIgcGFja2V0LiAgSXQgaGFzIGJlZW4gYW4gdW5uYW1lZCBtYWluc3RheSBvZiBJ UHY0IGZyb20gdGhlIGJlZ2lubmluZywgbWFzcXVlcmFkaW5nIHVuZGVyIHRoZSBuYW1lICJGcmFn bWVudGF0aW9uIFJlYXNzZW1ibHkgVGltZXIiIGJ1dCBhdCB0aGUgVENQIGxldmVsIGl0cyBwaHlz aWNhbCBleGlzdGVuY2UgaGFzIGdvbmUgdW5hY2tub3dsZWRnZWQuCgpTZXR0bGluZyBUaW1lIGlz IHJhdGhlciBlYXN5IHRvIGNhbGN1bGF0ZSBhcyBpdCBoYXMgYSBjZWlsaW5nIG9mIC4yNSpSVFQg KGFueSBudW1iZXIgb3ZlciB0aGF0IGFuZCB5b3UgYXJlIGluIHJldHJhbnNtaXNzaW9uIHRlcnJp dG9yeSkgYW5kIGEgZmxvb3Igb2YgRnJhZ21lbnRhdGlvbiBSZWFzc2VtYmx5IFRpbWUgKiAxLjI1 IChuZWVkIHRvIGxlYXZlIGVub3VnaCB0aW1lIHRvIHByb2Nlc3MgcmVhc3NlbWJsZWQgcGFja2V0 KS4gIE9idmlvdXNseSB0aGUgbG93ZXIgbnVtYmVyIGlzIGJldHRlciBhbmQgdGhlcmUgYXJlIHBy b2JhYmx5IHRob3VzYW5kcyBvZiBlbWFpbHMgb24gaG93ICB0byBzZXQgdGhlIEZyYWdtZW50YXRp b24gUmVhc3NlbWJseSBUaW1lciBwcm9wZXJseS4KClRoZSBwb2ludCBoZXJlIGlzIHdlIGFyZSBk YW5jaW5nIGFyb3VuZCBpc3N1ZXMgYnkgc2F5aW5nIHdlIHdhaXQgZm9yIG11bHRpcGxlIEFDS3Mg YmVmb3JlIGEgU0FDSyBibG9jayBpcyBwcm9jZXNzZWQsIHlvdSBhcmUgYmFkbHkgc2ltdWxhdGlu ZyByZWFzc2VtYmx5IGRlbGF5LiAgQmV0dGVyIHRvIGFjdCBvbiB0aGUgZmlyc3QgYXBwZWFyYW5j ZSBvZiBhIGhvbGUgaW4gdGhlIHNlcXVlbmNlIGJ1dCBkZWxheSB0aGUgYWN0dWFsIGNhbGwgZm9y IHJldHJhbnNtaXNzaW9uIGJ5IFNldHRsaW5nIFRpbWUgdG8gc2VlIGlmIHRoZSB3b3JsZCBoYXMg Y2hhbmdlZCBiZWZvcmUgeW91IGlzc3VlIHRoZSByZXRyYW5zbWlzc2lvbi4gIEFsc28gdGhlIHRp bWUgcmVwcmVzZW50ZWQgYnkgbXVsdGlwbGUgQUNLcyBpcyBleHRyZW1lbHkgdmFyaWFibGUsICBz aG9ydCBzZWdtZW50cyBhbmQgcmFuZG9tIHRpbWVzIGZvciBXT1csIGxvbmcgc2VnbWVudHMgYW5k IGNvbnRpbnVvdXMgZm9yIGZpbGUgdHJhbnNmZXIuIAoKTm90ZSBmb3IgdGhlIHJlY29yZCBhIERF TEFZIFRJTUVSIGlzIG5vdCBpbiBhbmQgb2YgaXRzZWxmIGFuIGV2ZW50LCBpdCBpcyBkZWxheWlu ZyBhbmQgZXhpc3RpbmcgZXZlbnQsIHRoZXJlZm9yZSBpdHMgZXhwaXJhdGlvbiBkb2VzIG5vdCBo YXZlIGFueSBpbXBsaWNhdGlvbnMgb2YgaXRzIG93biwgdGhlIGV2ZW50IGFscmVhZHkgIGhhcHBl bmVkLgoKVG9ueQoKU2VudCBmcm9tIG15IEFTVVMgUGFk From touch@isi.edu Wed Aug 1 14:14:34 2012 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 1BDCC11E8310 for ; Wed, 1 Aug 2012 14:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.517 X-Spam-Level: X-Spam-Status: No, score=-103.517 tagged_above=-999 required=5 tests=[AWL=-0.918, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlVMaXX1oPsW for ; Wed, 1 Aug 2012 14:14:33 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 462DB11E8295 for ; Wed, 1 Aug 2012 14:14:33 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q71LE90b015358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Aug 2012 14:14:09 -0700 (PDT) Message-ID: <50199C21.8010404@isi.edu> Date: Wed, 01 Aug 2012 14:14:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Anthony Sabatini References: In-Reply-To: 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, "Matthew Mathis \(mattmathis@google.com\)" Subject: Re: [tcpm] Settling Time and RFC3517bis 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, 01 Aug 2012 21:14:34 -0000 On 8/1/2012 12:23 PM, Anthony Sabatini wrote: > Settling Time is the concept of how long we wait for an out of order packet. That's already called reordering time. Settling time is a term from analog electronics/optics, and I don't see a good reason to import it here. > It has been an unnamed mainstay of IPv4 from the beginning, > masquerading under the name "Fragmentation Reassembly Timer" but at the > TCP level its physical existence has gone unacknowledged. There has been no masquerading, but there appears to be confusion ;-) Fragmentation reassembly is based on the time between the arrival of the first fragment of a set (FWIW, I mean "first" as "first in time", not "the packet with an offset of 0") and the last (again, in time, not the fragment where MF=0), and is not affected at all by the order of the arrival of the fragments. In TCP, the reordering is of segments, and is tolerated by the receive window. > Settling Time is rather easy to calculate as it has a ceiling of > .25*RTT (any number over that and you are in retransmission > territory) TCP should never do anything RTT-based in less than a full RTT. It has no business retransmitting in less than one RTT. > and a floor of Fragmentation Reassembly Time * 1.25 (need > to leave enough time to process reassembled packet). The additional time is whatever time is needed to: - complete reassembly - get the resulting IP datagram to TCP for processing This should be on the order of microseconds, vs. milliseconds for most RTTs; 25% of the reassembly timer is thousands of time larger. However, again, the issue for TCP is the segment reordering time, which does not necessarily have anything to do with the reassembly time. E.g., even atomic (non-fragmented) segments can arrive out of order. > Obviously the > lower number is better and there are probably thousands of emails on > how to set the Fragmentation Reassembly Timer properly. > > The point here is we are dancing around issues by saying we wait for > multiple ACKs before a SACK block is processed, you are badly > simulating reassembly delay. Better to act on the first appearance > of a hole in the sequence but delay the actual call for > retransmission by Settling Time to see if the world has changed > before you issue the retransmission. Also the time represented by > multiple ACKs is extremely variable, short segments and random times > for WOW, long segments and continuous for file transfer. As the use of multiple concurrent paths becomes more common, out-of-order segment receipt becomes the norm. Jumping the gun on retransmitting holes could turn a mild reordering situation into a congested system quickly. I see no reason to act on holes on timescales shorter than 1-2 RTTs. Joe > Note for the record a DELAY TIMER is not in and of itself an event, > it is delaying and existing event, therefore its expiration does not > have any implications of its own, the event already happened. > > Tony > > Sent from my ASUS Pad > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From pasi.sarolahti@iki.fi Wed Aug 1 14:21:10 2012 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 42CB111E8339 for ; Wed, 1 Aug 2012 14:21:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s92GvWP+DtBD for ; Wed, 1 Aug 2012 14:21:09 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 722A711E8322 for ; Wed, 1 Aug 2012 14:21:09 -0700 (PDT) Received: from dhcp-4556.meeting.ietf.org (130.129.69.86) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 4FD08A2302F27298 for tcpm@ietf.org; Thu, 2 Aug 2012 00:21:07 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2012 14:21:09 -0700 Message-Id: <93A0A934-F2F2-4BB6-AC7A-7FB0DDA4C6A6@iki.fi> To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [tcpm] Draft TCPM meeting minutes 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, 01 Aug 2012 21:21:10 -0000 Hi, The draft meeting minutes are available at = http://www.ietf.org/proceedings/84/minutes/minutes-84-tcpm . Please let = me know if there are errors. Many thanks to Andrew, Richard and Matt for taking notes!=20 - Pasi From tsabatini@hotmail.com Thu Aug 2 11:08:31 2012 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 30AE011E81E8 for ; Thu, 2 Aug 2012 11:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4FKPvsRX6ux for ; Thu, 2 Aug 2012 11:08:30 -0700 (PDT) Received: from blu0-omc4-s27.blu0.hotmail.com (blu0-omc4-s27.blu0.hotmail.com [65.55.111.166]) by ietfa.amsl.com (Postfix) with ESMTP id EA09D11E81BF for ; Thu, 2 Aug 2012 11:08:29 -0700 (PDT) Received: from BLU0-SMTP42 ([65.55.111.137]) by blu0-omc4-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 11:08:28 -0700 X-Originating-IP: [184.71.189.194] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Received: from [172.16.3.246] ([184.71.189.194]) by BLU0-SMTP42.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 11:08:27 -0700 Date: Thu, 2 Aug 2012 14:07:46 -0400 From: Anthony Sabatini To: Joe Touch MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 02 Aug 2012 18:08:27.0700 (UTC) FILETIME=[D0CE2F40:01CD70D9] Cc: tcpm@ietf.org, "Matthew Mathis \(mattmathis@google.com\)" Subject: Re: [tcpm] Settling Time and RFC3517bis 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, 02 Aug 2012 18:08:31 -0000 Sm9lIC0KClRoYW5rIHlvdSBmb3IgeW91ciBpbnNpZ2h0ZnVsIGNvbW1lbnRzLgoKMSkgSSBhbSB1 c2VkIHRvIElUVSB0ZXJtaW5vbG9neS4gIFNldHRsaW5nIHRpbWUgaW4gSVRVIGlzIHVzZWQgaW4g b3B0aWNhbCwgZWxlY3RyaWNhbCBhbmQgaW5mcmFzdHJ1Y3R1cmUgc3RhbmRhcmRzLiAgSXQgd2Fz IGluIHRoYXQgbGFzdCBjb250ZXh0IHRoYXQgSSB1c2VkIGl0LiAgSSB3aWxsIGNoYW5nZSBhbGwg cmVmZXJlbmNlcyB0byAiUmVvcmRlcmluZyBUaW1lIi4KCjIpIE15IHBvaW50IGFib3V0IGZyYWdt ZW50YXRpb24gaXMgdGhhdCAiRnJhZ21lbnRhdGlvbiBSZWFzc2VtYmx5IFRpbWVyIiBhbmQgIlJl b3JkZXJpbmcgVGltZSIgYXJlIGRpZmZlcmVudCBuYW1lcyB0byBkZXNjcmliZSB0aGUgc2FtZSBp c3N1ZS4KCjMpIFNUQU5EQVJEIFRDUCBjYW4gbm90IHJlY292ZXIgaW4gbGVzcyB0aGFuIG9uZSBS VFQsIFNBQ0sgVENQIGFzIHdyaXR0ZW4gY2VydGFpbmx5IGNhbiBhbmQgZG9lcyBjdXJyZW50bHkg cmVjb3ZlciBpbiBsZXNzIHRoYXQgb25lIFJUVCBvbiBhdCBsZWFzdCBsb25nIGxpbmtzLiAgV2l0 aCB0aGUgY2hhbmdlcyBJIGhhdmUgYmVlbiBwcm9wb3NpbmcgbmVhcmx5IGFsbCBlcnJvcnMgY2Fu IGJlIHJlY292ZXJlZCBpbiBsZXNzIHRoYW4gb25lIFJUVC4KCjQpIEV2ZW4gdGVycmVzdHJpYWwg R29vZ2xlIENBIHRvIEdvb2dsZSBOWSBpcyA0NSBtcyBtaW5pbXVtLCBhZGQgc3dpdGNoaW5nIGVx dWlwbWVudCB3aXRob3V0IE1QTFMgYW5kIHRoYXQgZ29lcyB0byAxMDAgbXMsIHdpdGggTVBMUyB3 aG8ga25vd3MuICBPbmUgUlRUIGlzIGEgaHVnZSBhbW91bnQgb2YgdGltZSwgb24gYSBzYXRlbGxp dGUgb3Igb2NlYW4gbGluayBpdCBpcyBnbGFjaWFsLiAgVENQTSBoYXMgbm8gYnVzaW5lc3MgZGlz Y3Vzc2luZyBmb3J3YXJkIGVycm9yIGNvcnJlY3Rpb24gYmVmb3JlIGV4cGxvcmluZyB0aGUgbWVj aGFuaWNzIG9mIG1ha2luZyB0aGUgY3VycmVudCBwcm90b2NvbCBtb3JlIGVmZmljaWVudCwgbG93 ZXIgbGF0ZW5jeSBhbmQgbW9yZSByZWxpYWJsZS4KCjUpIFRoZSAxLjI1ICogRnJhZ21lbnRhdGlv biBSZWFzc2VtYmx5IFRpbWVyIHdhcyBjaG9zZW4gYXMgYSBtaW5pbXVtIHRvIGluY2x1ZGUgYSBi aXQgbW9yZSByZW9yZGVyaW5nIHRpbWUuICBSZWdhcmRsZXNzIGlmIGEgcGFja2V0IGhhcyBub3Qg YXJyaXZlZCBpbiAuMjUgKiBSVFQgY2FuIGl0IGV2ZW4gcmVtb3RlbHkgYmUgY29uc2lkZXJlZCBh cyAib3V0IG9mIG9yZGVyIiBhcyBvcHBvc2VkIHRvIGxvc3Q/Cgo2KSBXaHkgaXMgdGhlIElFVEYg c3BlbmRpbmcgYWxsIG9mIGl0cyB0aW1lIGNvdmVyaW5nIGZvciBncmVlZHkgY2FycmllcnMgd2hv IGRvIG5vdCBpbnN0YWxsIGVub3VnaCBmaWJlciBvciBzd2l0Y2hpbmcgZXF1aXBtZW50PyAgQUxM IG9mIHRoZSBjaGFuZ2VzIGJlaW5nIG1hZGUgaW4gdGhlIGNvbmdlc3Rpb24gYXJlYSByZXN1bHQg aW4gYSBXT1JTRSBleHBlcmllbmNlIGZvciB0aGUgZW5kIHVzZXIsIHRoZSBwZW9wbGUgd2Ugc2hv dWxkIHJlYWxseSBjYXJlIGFib3V0LgoKVG9ueQoKU2VudCBmcm9tIG15IEFTVVMgUGFkCgpKb2Ug VG91Y2ggPHRvdWNoQGlzaS5lZHU+IHdyb3RlOgoKPgo+Cj5PbiA4LzEvMjAxMiAxMjoyMyBQTSwg QW50aG9ueSBTYWJhdGluaSB3cm90ZToKPj4gU2V0dGxpbmcgVGltZSBpcyB0aGUgY29uY2VwdCBv ZiBob3cgbG9uZyB3ZSB3YWl0IGZvciBhbiBvdXQgb2Ygb3JkZXIgcGFja2V0Lgo+Cj5UaGF0J3Mg YWxyZWFkeSBjYWxsZWQgcmVvcmRlcmluZyB0aW1lLiBTZXR0bGluZyB0aW1lIGlzIGEgdGVybSBm cm9tIAo+YW5hbG9nIGVsZWN0cm9uaWNzL29wdGljcywgYW5kIEkgZG9uJ3Qgc2VlIGEgZ29vZCBy ZWFzb24gdG8gaW1wb3J0IGl0IGhlcmUuCj4KPj4gSXQgaGFzIGJlZW4gYW4gdW5uYW1lZCBtYWlu c3RheSBvZiBJUHY0IGZyb20gdGhlIGJlZ2lubmluZywKPj4gbWFzcXVlcmFkaW5nIHVuZGVyIHRo ZSBuYW1lICJGcmFnbWVudGF0aW9uIFJlYXNzZW1ibHkgVGltZXIiIGJ1dCBhdCB0aGUKPj4gVENQ IGxldmVsIGl0cyBwaHlzaWNhbCBleGlzdGVuY2UgaGFzIGdvbmUgdW5hY2tub3dsZWRnZWQuCj4K PlRoZXJlIGhhcyBiZWVuIG5vIG1hc3F1ZXJhZGluZywgYnV0IHRoZXJlIGFwcGVhcnMgdG8gYmUg Y29uZnVzaW9uIDstKQo+Cj5GcmFnbWVudGF0aW9uIHJlYXNzZW1ibHkgaXMgYmFzZWQgb24gdGhl IHRpbWUgYmV0d2VlbiB0aGUgYXJyaXZhbCBvZiB0aGUgCj5maXJzdCBmcmFnbWVudCBvZiBhIHNl dCAoRldJVywgSSBtZWFuICJmaXJzdCIgYXMgImZpcnN0IGluIHRpbWUiLCBub3QgCj4idGhlIHBh Y2tldCB3aXRoIGFuIG9mZnNldCBvZiAwIikgYW5kIHRoZSBsYXN0IChhZ2FpbiwgaW4gdGltZSwg bm90IHRoZSAKPmZyYWdtZW50IHdoZXJlIE1GPTApLCBhbmQgaXMgbm90IGFmZmVjdGVkIGF0IGFs bCBieSB0aGUgb3JkZXIgb2YgdGhlIAo+YXJyaXZhbCBvZiB0aGUgZnJhZ21lbnRzLgo+Cj5JbiBU Q1AsIHRoZSByZW9yZGVyaW5nIGlzIG9mIHNlZ21lbnRzLCBhbmQgaXMgdG9sZXJhdGVkIGJ5IHRo ZSByZWNlaXZlIAo+d2luZG93Lgo+Cj4+IFNldHRsaW5nIFRpbWUgaXMgcmF0aGVyIGVhc3kgdG8g Y2FsY3VsYXRlIGFzIGl0IGhhcyBhIGNlaWxpbmcgb2YKPj4gLjI1KlJUVCAoYW55IG51bWJlciBv dmVyIHRoYXQgYW5kIHlvdSBhcmUgaW4gcmV0cmFuc21pc3Npb24KPj4gdGVycml0b3J5KQo+Cj5U Q1Agc2hvdWxkIG5ldmVyIGRvIGFueXRoaW5nIFJUVC1iYXNlZCBpbiBsZXNzIHRoYW4gYSBmdWxs IFJUVC4gSXQgaGFzIAo+bm8gYnVzaW5lc3MgcmV0cmFuc21pdHRpbmcgaW4gbGVzcyB0aGFuIG9u ZSBSVFQuCj4KPj4gYW5kIGEgZmxvb3Igb2YgRnJhZ21lbnRhdGlvbiBSZWFzc2VtYmx5IFRpbWUg KiAxLjI1IChuZWVkCj4+IHRvIGxlYXZlIGVub3VnaCB0aW1lIHRvIHByb2Nlc3MgcmVhc3NlbWJs ZWQgcGFja2V0KS4KPgo+VGhlIGFkZGl0aW9uYWwgdGltZSBpcyB3aGF0ZXZlciB0aW1lIGlzIG5l ZWRlZCB0bzoKPgktIGNvbXBsZXRlIHJlYXNzZW1ibHkKPgktIGdldCB0aGUgcmVzdWx0aW5nIElQ IGRhdGFncmFtIHRvIFRDUCBmb3IgcHJvY2Vzc2luZwo+Cj5UaGlzIHNob3VsZCBiZSBvbiB0aGUg b3JkZXIgb2YgbWljcm9zZWNvbmRzLCB2cy4gbWlsbGlzZWNvbmRzIGZvciBtb3N0IAo+UlRUczsg MjUlIG9mIHRoZSByZWFzc2VtYmx5IHRpbWVyIGlzIHRob3VzYW5kcyBvZiB0aW1lIGxhcmdlci4K Pgo+SG93ZXZlciwgYWdhaW4sIHRoZSBpc3N1ZSBmb3IgVENQIGlzIHRoZSBzZWdtZW50IHJlb3Jk ZXJpbmcgdGltZSwgd2hpY2ggCj5kb2VzIG5vdCBuZWNlc3NhcmlseSBoYXZlIGFueXRoaW5nIHRv IGRvIHdpdGggdGhlIHJlYXNzZW1ibHkgdGltZS4gRS5nLiwgCj5ldmVuIGF0b21pYyAobm9uLWZy YWdtZW50ZWQpIHNlZ21lbnRzIGNhbiBhcnJpdmUgb3V0IG9mIG9yZGVyLgo+Cj4+IE9idmlvdXNs eSB0aGUKPj4gbG93ZXIgbnVtYmVyIGlzIGJldHRlciBhbmQgdGhlcmUgYXJlIHByb2JhYmx5IHRo b3VzYW5kcyBvZiBlbWFpbHMgb24KPj4gaG93ICB0byBzZXQgdGhlIEZyYWdtZW50YXRpb24gUmVh c3NlbWJseSBUaW1lciBwcm9wZXJseS4KPj4KPj4gVGhlIHBvaW50IGhlcmUgaXMgd2UgYXJlIGRh bmNpbmcgYXJvdW5kIGlzc3VlcyBieSBzYXlpbmcgd2Ugd2FpdCBmb3IKPj4gbXVsdGlwbGUgQUNL cyBiZWZvcmUgYSBTQUNLIGJsb2NrIGlzIHByb2Nlc3NlZCwgeW91IGFyZSBiYWRseQo+PiBzaW11 bGF0aW5nIHJlYXNzZW1ibHkgZGVsYXkuICBCZXR0ZXIgdG8gYWN0IG9uIHRoZSBmaXJzdCBhcHBl YXJhbmNlCj4+IG9mIGEgaG9sZSBpbiB0aGUgc2VxdWVuY2UgYnV0IGRlbGF5IHRoZSBhY3R1YWwg Y2FsbCBmb3IKPj4gcmV0cmFuc21pc3Npb24gYnkgU2V0dGxpbmcgVGltZSB0byBzZWUgaWYgdGhl IHdvcmxkIGhhcyBjaGFuZ2VkCj4+IGJlZm9yZSB5b3UgaXNzdWUgdGhlIHJldHJhbnNtaXNzaW9u LiAgQWxzbyB0aGUgdGltZSByZXByZXNlbnRlZCBieQo+PiBtdWx0aXBsZSBBQ0tzIGlzIGV4dHJl bWVseSB2YXJpYWJsZSwgIHNob3J0IHNlZ21lbnRzIGFuZCByYW5kb20gdGltZXMKPj4gZm9yIFdP VywgbG9uZyBzZWdtZW50cyBhbmQgY29udGludW91cyBmb3IgZmlsZSB0cmFuc2Zlci4KPgo+QXMg dGhlIHVzZSBvZiBtdWx0aXBsZSBjb25jdXJyZW50IHBhdGhzIGJlY29tZXMgbW9yZSBjb21tb24s IAo+b3V0LW9mLW9yZGVyIHNlZ21lbnQgcmVjZWlwdCBiZWNvbWVzIHRoZSBub3JtLiBKdW1waW5n IHRoZSBndW4gb24gCj5yZXRyYW5zbWl0dGluZyBob2xlcyBjb3VsZCB0dXJuIGEgbWlsZCByZW9y ZGVyaW5nIHNpdHVhdGlvbiBpbnRvIGEgCj5jb25nZXN0ZWQgc3lzdGVtIHF1aWNrbHkuCj4KPkkg c2VlIG5vIHJlYXNvbiB0byBhY3Qgb24gaG9sZXMgb24gdGltZXNjYWxlcyBzaG9ydGVyIHRoYW4g MS0yIFJUVHMuCj4KPkpvZQo+Cj4KPj4gTm90ZSBmb3IgdGhlIHJlY29yZCBhIERFTEFZIFRJTUVS IGlzIG5vdCBpbiBhbmQgb2YgaXRzZWxmIGFuIGV2ZW50LAo+PiBpdCBpcyBkZWxheWluZyBhbmQg ZXhpc3RpbmcgZXZlbnQsIHRoZXJlZm9yZSBpdHMgZXhwaXJhdGlvbiBkb2VzIG5vdAo+PiBoYXZl IGFueSBpbXBsaWNhdGlvbnMgb2YgaXRzIG93biwgdGhlIGV2ZW50IGFscmVhZHkgIGhhcHBlbmVk LiA+Cj4+IFRvbnkKPj4KPj4gU2VudCBmcm9tIG15IEFTVVMgUGFkCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IHRjcG0gbWFpbGluZyBsaXN0Cj4+ IHRjcG1AaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 Y3BtCj4+Cj4K From touch@isi.edu Thu Aug 2 11:37:52 2012 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 9890F11E824D for ; Thu, 2 Aug 2012 11:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.501 X-Spam-Level: X-Spam-Status: No, score=-103.501 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm0ZJalB0jZG for ; Thu, 2 Aug 2012 11:37:51 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id C185811E824C for ; Thu, 2 Aug 2012 11:37:51 -0700 (PDT) Received: from [192.168.1.100] (jt-wifi2.isi.edu [128.9.160.35]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q72IbC1I020682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Aug 2012 11:37:15 -0700 (PDT) Message-ID: <501AC7D7.8090401@isi.edu> Date: Thu, 02 Aug 2012 11:32:55 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Anthony Sabatini References: In-Reply-To: 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: tcpm@ietf.org, "Matthew Mathis \(mattmathis@google.com\)" Subject: Re: [tcpm] Settling Time and RFC3517bis 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, 02 Aug 2012 18:37:52 -0000 Hi, Tony, On 8/2/2012 11:07 AM, Anthony Sabatini wrote: > Joe - > > Thank you for your insightful comments. > > 1) I am used to ITU terminology. Settling time in ITU is used in > optical, electrical and infrastructure standards. It was in that last > context that I used it. I will change all references to "Reordering Time". AOK. > 2) My point about fragmentation is that "Fragmentation Reassembly > Timer" and "Reordering Time" are different names to describe the same issue. But they are not. Fragmentation reassembly time is the time of the spread-out of a set of fragments of a single IP packet -- it does not matter at all whether the fragments are reordered or not. There is neither a performance nor a time delay difference when fragments come out of order vs. in-order. The only impact is when fragments of different packets are *interleaved* - whether they are reordered or not. Reordering time would affect only things that care about order. TCP doesn't care strictly about reordering of the incoming segments, but as you note there is a performance impact of things coming out of order at the TCP level. >> 3) STANDARD TCP can not recover in less than one RTT, SACK TCP as > written certainly can and does currently recover in less that one RTT on > at least long links. With the changes I have been proposing nearly all > errors can be recovered in less than one RTT. Please explain. In less than 1 RTT the source cannot know what packets have arrived at the sender, so it cannot know what to retransmit. In less than 1 RTT, the sender has no new information, and cannot do much of anything. The *receiver* can react differently, which can impact the sender later, but the loop cannot be closed in less than 1 RTT. > 4) Even terrestrial Google CA to Google NY is 45 ms minimum, add > switching equipment without MPLS and that goes to 100 ms, with MPLS who > knows. One RTT is a huge amount of time, on a satellite or ocean link it > is glacial. TCPM has no business discussing forward error correction > before exploring the mechanics of making the current protocol more > efficient, lower latency and more reliable. TCP does not use FEC, but many links - especially satellite and oceanic - do. That's at the link layer. The tradeoff between ARQ-based error correction and FEC error correction is a known issue, and TCP is not exempt from it. > 5) The 1.25 * Fragmentation Reassembly Timer was chosen as a minimum > to include a bit more reordering time. Regardless if a packet has not > arrived in .25 * RTT can it even remotely be considered as "out of > order" as opposed to lost? Reordering typically has no relationship to the RTT, except that reordering is always less than the max RTT. Neither reordering nor the RTT is related at all to the fragmentation reassembly timer, unless a stream includes some fragments and some non-fragment packets. In that case, you would need to wait at least 1 * reassembly time to account for differences between reassembled packets and non-reassembled ones. > 6) Why is the IETF spending all of its time covering for greedy > carriers who do not install enough fiber or switching equipment? ALL of > the changes being made in the congestion area result in a WORSE > experience for the end user, the people we should really care about. The IETF is focused on making sure things work in the most possible cases - especially in the cases of IP and TCP. Optimization is nice, but can *always* be sacrificed when it compromises generality. The purpose of congestion control is to improve everyone's experience as a group by making some user's experience worse, by definition. The IETF cares about the end users as a group, but not individual greedy end users whose behavior impacts others. Joe > > Tony > > Sent from my ASUS Pad > > Joe Touch wrote: > >> >> >> On 8/1/2012 12:23 PM, Anthony Sabatini wrote: >>> Settling Time is the concept of how long we wait for an out of order packet. >> >> That's already called reordering time. Settling time is a term from >> analog electronics/optics, and I don't see a good reason to import it here. >> >>> It has been an unnamed mainstay of IPv4 from the beginning, >>> masquerading under the name "Fragmentation Reassembly Timer" but at the >>> TCP level its physical existence has gone unacknowledged. >> >> There has been no masquerading, but there appears to be confusion ;-) >> >> Fragmentation reassembly is based on the time between the arrival of the >> first fragment of a set (FWIW, I mean "first" as "first in time", not >> "the packet with an offset of 0") and the last (again, in time, not the >> fragment where MF=0), and is not affected at all by the order of the >> arrival of the fragments. >> >> In TCP, the reordering is of segments, and is tolerated by the receive >> window. >> >>> Settling Time is rather easy to calculate as it has a ceiling of >>> .25*RTT (any number over that and you are in retransmission >>> territory) >> >> TCP should never do anything RTT-based in less than a full RTT. It has >> no business retransmitting in less than one RTT. >> >>> and a floor of Fragmentation Reassembly Time * 1.25 (need >>> to leave enough time to process reassembled packet). >> >> The additional time is whatever time is needed to: >> - complete reassembly >> - get the resulting IP datagram to TCP for processing >> >> This should be on the order of microseconds, vs. milliseconds for most >> RTTs; 25% of the reassembly timer is thousands of time larger. >> >> However, again, the issue for TCP is the segment reordering time, which >> does not necessarily have anything to do with the reassembly time. E.g., >> even atomic (non-fragmented) segments can arrive out of order. >> >>> Obviously the >>> lower number is better and there are probably thousands of emails on >>> how to set the Fragmentation Reassembly Timer properly. >>> >>> The point here is we are dancing around issues by saying we wait for >>> multiple ACKs before a SACK block is processed, you are badly >>> simulating reassembly delay. Better to act on the first appearance >>> of a hole in the sequence but delay the actual call for >>> retransmission by Settling Time to see if the world has changed >>> before you issue the retransmission. Also the time represented by >>> multiple ACKs is extremely variable, short segments and random times >>> for WOW, long segments and continuous for file transfer. >> >> As the use of multiple concurrent paths becomes more common, >> out-of-order segment receipt becomes the norm. Jumping the gun on >> retransmitting holes could turn a mild reordering situation into a >> congested system quickly. >> >> I see no reason to act on holes on timescales shorter than 1-2 RTTs. >> >> Joe >> >> >>> Note for the record a DELAY TIMER is not in and of itself an event, >>> it is delaying and existing event, therefore its expiration does not >>> have any implications of its own, the event already happened. > >>> Tony >>> >>> Sent from my ASUS Pad >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> From rick.jones2@hp.com Thu Aug 2 11:49:02 2012 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 0F64821E8114 for ; Thu, 2 Aug 2012 11:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75mn4iH-WO2c for ; Thu, 2 Aug 2012 11:49:01 -0700 (PDT) Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5249121E8113 for ; Thu, 2 Aug 2012 11:49:01 -0700 (PDT) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id 51DF7C13A; Thu, 2 Aug 2012 18:49:00 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id DD49310003; Thu, 2 Aug 2012 18:48:59 +0000 (UTC) Message-ID: <501ACB9A.8030000@hp.com> Date: Thu, 02 Aug 2012 11:48:58 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Joe Touch References: <501AC7D7.8090401@isi.edu> In-Reply-To: <501AC7D7.8090401@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, "Matthew Mathis \(mattmathis@google.com\)" Subject: Re: [tcpm] Settling Time and RFC3517bis 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, 02 Aug 2012 18:49:02 -0000 Joe - Just so as I am sure I am thinking the same thing as you when you write "RTT" you mean that from the time a segment is first transmitted rather than from the time when some indication of a hole arrives at the sender yes? rick jones From touch@isi.edu Thu Aug 2 11:58:48 2012 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 E767611E81DE for ; Thu, 2 Aug 2012 11:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.485 X-Spam-Level: X-Spam-Status: No, score=-103.485 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9rWlYyMCLUN for ; Thu, 2 Aug 2012 11:58:48 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 67B0611E818D for ; Thu, 2 Aug 2012 11:58:48 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q72Iw5bp021468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Aug 2012 11:58:05 -0700 (PDT) Message-ID: <501ACDBD.80705@isi.edu> Date: Thu, 02 Aug 2012 11:58:05 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Rick Jones References: <501AC7D7.8090401@isi.edu> <501ACB9A.8030000@hp.com> In-Reply-To: <501ACB9A.8030000@hp.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, "Matthew Mathis \(mattmathis@google.com\)" Subject: Re: [tcpm] Settling Time and RFC3517bis 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, 02 Aug 2012 18:58:49 -0000 On 8/2/2012 11:48 AM, Rick Jones wrote: > Joe - > > Just so as I am sure I am thinking the same thing as you when you write > "RTT" you mean that from the time a segment is first transmitted rather > than from the time when some indication of a hole arrives at the sender > yes? RTT = round trip time. It's the time delay between when a message is sent from the source to when any confirmation of receipt of that message could return back to that source. Holes are determined by gaps of sequences of packets. They ALWAYS involve delays larger than 1 RTT because within 1 RTT either a packet arrives or it doesn't; when it doesn't, there's no indication of a gap until the *next* packet arrives. Packets that are reordered that cause that same effect are reordered because at least one packet (the earlier one) is delayed longer, which means the second packet arrives but the first didn't. The time is thus still longer than 1 RTT. Joe From internet-drafts@ietf.org Thu Aug 2 12:31:07 2012 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 5F8C211E8104; Thu, 2 Aug 2012 12:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLv4NcyCKoxD; Thu, 2 Aug 2012 12:31:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C913A11E80D1; Thu, 2 Aug 2012 12:31:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120802193106.1203.87297.idtracker@ietfa.amsl.com> Date: Thu, 02 Aug 2012 12:31:06 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-04.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: Thu, 02 Aug 2012 19:31:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : TCP Extensions for High Performance Author(s) : David Borman Bob Braden Van Jacobson Richard Scheffenegger Filename : draft-ietf-tcpm-1323bis-04.txt Pages : 46 Date : 2012-08-02 Abstract: This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). Selective acknowledgments are not included in this memo. This memo updates and obsoletes RFC 1323. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rs@netapp.com Thu Aug 2 12:33:01 2012 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 1962411E8103 for ; Thu, 2 Aug 2012 12:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.109 X-Spam-Level: X-Spam-Status: No, score=-10.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYLMr2LNXCfE for ; Thu, 2 Aug 2012 12:33:00 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id AD61411E80D2 for ; Thu, 2 Aug 2012 12:33:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,702,1336374000"; d="scan'208";a="672324870" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 02 Aug 2012 12:33:00 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q72JX0SS004115 for ; Thu, 2 Aug 2012 12:33:00 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.34]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 12:32:59 -0700 From: "Scheffenegger, Richard" To: "tcpm (tcpm@ietf.org)" Thread-Topic: draft-ietf-tcpm-1323bis Thread-Index: Ac1w33W0H5GvXIWXTUK6FSf5db1dIw== Date: Thu, 2 Aug 2012 19:32:58 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D4E1D02@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tcpm] draft-ietf-tcpm-1323bis 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, 02 Aug 2012 19:33:01 -0000 Hi, While updating 1323bis for RFC2119 Phrases (see IETF84 presentation), I fou= nd that some normative text that is directly from RFC 1323 does not strictl= y use the normative phrasing... Most new (diff 1323 / 1323bis) text does, though. I would like to know the opinion of the WG as how to proceed with non-RFC 2= 119 normative phrases. Shall they be kept unchanged (identical to 1323)? Or shall the wording be changed, and the appropriate uppercase words includ= ed to make these definitely normative? So far, I updated the phrasing only in those places, that are normative, an= d lend themselves to easy update (e.g. simply changing the lowercase 2119 = word to uppercase). I also found two references to variables (TS.TStamp, TS.Stamp) that seem to= mean TS.Recent, but have been missed in RFC1323 so far :)=20 Please review the updated version! Richard Scheffenegger From michael.scharf@alcatel-lucent.com Thu Aug 2 13:45:21 2012 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 B44A511E80FE for ; Thu, 2 Aug 2012 13:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.982 X-Spam-Level: X-Spam-Status: No, score=-7.982 tagged_above=-999 required=5 tests=[AWL=-1.733, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmJm9Ymbwljd for ; Thu, 2 Aug 2012 13:45:20 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA7311E8091 for ; Thu, 2 Aug 2012 13:45:20 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q72KjJsa013527 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 2 Aug 2012 22:45:19 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 2 Aug 2012 22:45:19 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Thu, 2 Aug 2012 22:45:16 +0200 Thread-Topic: Consenus on adding a new TCPM charter milestone for accurate feedback Thread-Index: Ac1w77kil5FV/raKQXmqnugWwrJWXA== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 02 Aug 2012 20:45:21 -0000 Hi all, There has been broad support for a new TCPM charter milestone on accurate E= CN feedback in TCP. We therefore want to confirm that working group consensus is to add the fol= lowing milestone to the TCPM carter: "Sep 2013 Submit document on accurate ECN feedback in TCP to the IESG f= or publication as an Experimental RFC" The chairs believe that the consensus is not to adopt any specific document= as of now. However, the working group should converge on the mechanism by = March 2013 latest. Please feel free to comment if you have any additional thoughts, within the= next two weeks. Thanks Michael (on behalf of the TCPM co-chairs) From ycheng@google.com Thu Aug 2 14:13:47 2012 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 D6A9A11E8173 for ; Thu, 2 Aug 2012 14:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.944 X-Spam-Level: X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGfuvlWP5IAc for ; Thu, 2 Aug 2012 14:13:47 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4478D11E8143 for ; Thu, 2 Aug 2012 14:13:47 -0700 (PDT) Received: by ggnc4 with SMTP id c4so9990377ggn.31 for ; Thu, 02 Aug 2012 14:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=lDS2+FN+CIeXXHgEn+JeReqtlyQdp+OSWr8W9tI3lCI=; b=HwdIqerFZRINjyWLlj5EOas8X+Eq5zgFZEyutYX2mDqTgT++GtaS2eQTWECIKzWJ+h JPQkkYQb+3aFM32dNRblHjFbtSGnp3rTjZlqc1NmRcBVGyjQifEgpbv16ck47+QPtouj muDVAVG/I7ZGsa+REt6Uy0A4Vqs2wI3Cm5eRQQQauRBpo6LjSmv6FrxJw+K688rqpCHw EKrA+cHPENTJaTrzLTdj8N2qMPoiEGR3OvMGW79ufofM9Q7z/I60qWQM74ak4nB/EMHk 7B/r3w66BopWNctx9QYtpgHrEK5n/fhjpXaCT95h13dOSX04qGUJafD6zsAj5drGJgiH 5LIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=lDS2+FN+CIeXXHgEn+JeReqtlyQdp+OSWr8W9tI3lCI=; b=eNxVgvV1Yv2dINRM3PhDGE0iurpjVNb/ElZwbylmh+tWq5wmvbpNjdPDprMGZqZ9eC MjIAS1X/D+wZ1trGWpGp5fO4RTNdc6Apze2Tlt/xh7ZLxe5pdn924PXBFYcaV8mGg+PR lucitdldCBK0OZGKkg8nonVURn92zHPSByIUKu8Edz0k8CtFAboFukJhvvj/7dz9the+ 7QzA8zslSyWUW+mtgKaBc+LxcuDoCxBVrAI4RV+AuWm2sbdCJpTeaLKzWV0FchasKJr7 jJ3WbGcZQwQxc1DBjtxJeOAOSBEZE/v2NEbfz9WP39z4A0TTl0aPHJi93Iun3aGMESdS GxyQ== Received: by 10.60.7.104 with SMTP id i8mr39967446oea.31.1343942026682; Thu, 02 Aug 2012 14:13:46 -0700 (PDT) Received: by 10.60.7.104 with SMTP id i8mr39967427oea.31.1343942026540; Thu, 02 Aug 2012 14:13:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.99.37 with HTTP; Thu, 2 Aug 2012 14:13:26 -0700 (PDT) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Thu, 2 Aug 2012 14:13:26 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkEtNYiOONerrchN8aBjjmGyesVts5XcPYMu4LRlhdhGYoXiTVYGB7eMil8ee6MOb11DRVagOwGFNEFCHYZq7y7/j8GWlBH2gqZqbNhVjmaum0IvO0sH2/mzJpWT/uDTVpzsBAs5EWXoqcQJ/goowbwKckSgssbXSFo91xaqBTHc09TIpk= Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 02 Aug 2012 21:13:47 -0000 is accurate ECN part of "maintenance and minor extension"? On Thu, Aug 2, 2012 at 1:45 PM, Scharf, Michael (Michael) wrote: > Hi all, > > There has been broad support for a new TCPM charter milestone on accurate ECN feedback in TCP. > > We therefore want to confirm that working group consensus is to add the following milestone to the TCPM carter: > > "Sep 2013 Submit document on accurate ECN feedback in TCP to the IESG for publication as an Experimental RFC" > > The chairs believe that the consensus is not to adopt any specific document as of now. However, the working group should converge on the mechanism by March 2013 latest. > > Please feel free to comment if you have any additional thoughts, within the next two weeks. > > Thanks > > Michael (on behalf of the TCPM co-chairs) > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Thu Aug 2 14:17:26 2012 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 E88E011E8185 for ; Thu, 2 Aug 2012 14:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8rI-zaYaodw for ; Thu, 2 Aug 2012 14:17:25 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 33D6A11E8180 for ; Thu, 2 Aug 2012 14:17:25 -0700 (PDT) Received: by ghbg16 with SMTP id g16so9961906ghb.31 for ; Thu, 02 Aug 2012 14:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=wPkxSqDRK+Sy30AxggjE3uRPrvBj16mgT40Q6tXONbk=; b=Hg1/AswUDJNgjxcGAvhPC/fzp5kSvcekSO2BOMpR16Lfr0wgBdEKyna5HhjVUkCgq4 ErkGTv7v3uYCOZpuAleZfdWAb9X+g9FUuk/46p8SKZyTPmOfzYmCsM0t3hVXc0SSMR6q UeqpjSeybSXcrdKExmhXfm5X/O6GBu6TkhmiGwr7NMGLKjQT2oq0SREQDfNJNendmdNf VAfyyNPO+TUTFr6MyG+Kng9S0dhQWLCfKh4x7l6K3ulbejmcIakxLM4/chc2rRYZoX3a rVEKffdmR1HjKqvCJu5euvyxdzIEi5KL6TXb/krjAuk1xLAF+/+t+NPi+H4nN70CdLCr sB2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=wPkxSqDRK+Sy30AxggjE3uRPrvBj16mgT40Q6tXONbk=; b=ogf1Nv/Lfdp7+Q9zs8gJ24KpQbQPv+kHTzygRTH7tJTwD9xaLiMjwpjASOBMHk9bBO VcDz2M6mBO+8yuaAXveCkYH8M35V611skto8LfVcUrKvXw2yX+N5MEIAt6AxxzuFePBk p0s005InJMYvHlgy2QieFSBSEscznnTBAwZP3kc350U2stpfReAr2jQpUH1QisVACgZw b+mABSZARitQLzOrwQedzOXoGX+CKLhpTOVENfdoyu874hPitriztyGuLEaUdSuC9HbF j3MANJzi/YhZ7X1DApqoMwCGqGhWZUvcCd7UazSjfGgDEgvqKSvYv6JD4v49pdCWV7bA c0/g== Received: by 10.60.28.101 with SMTP id a5mr39809171oeh.69.1343942244750; Thu, 02 Aug 2012 14:17:24 -0700 (PDT) Received: by 10.60.28.101 with SMTP id a5mr39809144oeh.69.1343942244574; Thu, 02 Aug 2012 14:17:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.99.37 with HTTP; Thu, 2 Aug 2012 14:17:04 -0700 (PDT) In-Reply-To: References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Thu, 2 Aug 2012 14:17:04 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkSr7BOExSUcyzr74aYNi7NP1cincogpMnuG5bCJDnpD18TeHz7TS1cGdvwjZJfxSxW2Hc1zV4EcIMZnv7GKb53WIwMcbtenNo0c4mFeL1F0uIB493of30tj+QGX4u3ONi5C4w5foMvGJ18+e9sOau7CkNBnlGCu1rDcuqgf5pl49EyfAE= Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 02 Aug 2012 21:17:26 -0000 On Thu, Aug 2, 2012 at 2:13 PM, Yuchung Cheng wrote: > is accurate ECN part of "maintenance and minor extension"? sorry got cut-off. I second that to add acc-ECN to tcpm, but often times I am confused the roles between iccrg and tcpm. To me there should be a tcp-dev to discuss all TCP changes. Other protocols often just apply the principles of CC in TCP. > > > > On Thu, Aug 2, 2012 at 1:45 PM, Scharf, Michael (Michael) > wrote: >> Hi all, >> >> There has been broad support for a new TCPM charter milestone on accurate ECN feedback in TCP. >> >> We therefore want to confirm that working group consensus is to add the following milestone to the TCPM carter: >> >> "Sep 2013 Submit document on accurate ECN feedback in TCP to the IESG for publication as an Experimental RFC" >> >> The chairs believe that the consensus is not to adopt any specific document as of now. However, the working group should converge on the mechanism by March 2013 latest. >> >> Please feel free to comment if you have any additional thoughts, within the next two weeks. >> >> Thanks >> >> Michael (on behalf of the TCPM co-chairs) >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Thu Aug 2 16:10:41 2012 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 D294A11E81C6 for ; Thu, 2 Aug 2012 16:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.874 X-Spam-Level: X-Spam-Status: No, score=-7.874 tagged_above=-999 required=5 tests=[AWL=-1.625, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoFFy4Y4S4cn for ; Thu, 2 Aug 2012 16:10:41 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id B826611E81A4 for ; Thu, 2 Aug 2012 16:10:39 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q72NAZjv012631 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 3 Aug 2012 01:10:35 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 3 Aug 2012 01:10:35 +0200 From: "Scharf, Michael (Michael)" To: Yuchung Cheng Date: Fri, 3 Aug 2012 01:10:31 +0200 Thread-Topic: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback Thread-Index: Ac1w9Dmsf2N50Br2R7+3ta+Ygv64kAADifgA Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDAA@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 02 Aug 2012 23:10:42 -0000 > > is accurate ECN part of "maintenance and minor extension"? Do you argue that it is a major change? For instance, just transporting a more accurate encoding does not imply tha= t CC is changed at all. > I second that to add acc-ECN to tcpm, but often times I am=20 > confused the roles between iccrg and tcpm. To me there should=20 > be a tcp-dev to discuss all TCP changes. Other protocols=20 > often just apply the principles of CC in TCP. ICCRG is reseach... Is more research needed to find for an experimental enc= oding that allows more than one feedback per RTT? Anybody who thinks that this topic would be too "disruptive" for TCPM: Plea= se speak up now. Michael From rs@netapp.com Thu Aug 2 17:06:14 2012 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 5F81021F8BE2 for ; Thu, 2 Aug 2012 17:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.156 X-Spam-Level: X-Spam-Status: No, score=-10.156 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipP2WIvaT3QY for ; Thu, 2 Aug 2012 17:06:12 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB5721F8BE1 for ; Thu, 2 Aug 2012 17:06:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,704,1336374000"; d="scan'208";a="672437210" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 02 Aug 2012 17:06:12 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q7306CnE003937; Thu, 2 Aug 2012 17:06:12 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.34]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 17:06:12 -0700 From: "Scheffenegger, Richard" To: Yuchung Cheng Thread-Topic: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback Thread-Index: Ac1w77kil5FV/raKQXmqnugWwrJWXAAPpskAAAAgfAAAA/ZSgAAOggeA Date: Fri, 3 Aug 2012 00:06:11 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D4E2584@SACEXCMBX02-PRD.hq.netapp.com> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDAA@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDAA@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 03 Aug 2012 00:06:14 -0000 Yuchung, I believe that this work is definitely in charter for TCPM. AccECN is about a semantic/signaling change of the (existing) wire-protocol= bits. We are not proposing to make incompatible, or major changes to the wire-pro= tocol. There are other, standards track WGs that actually have a documented need f= or a better congestion feedback scheme than exists today in TCP (conex). Th= e only feedback scheme meeting these requirements is currently DCCP (Ack Ve= ctor ECN-marked), SCTP (draft only), and RTP (draft only). The problem you are perhaps observing is that as TCP is the de-facto standa= rd protocol for the majority of transport needs (and we probably all agree = that it's often not the best choice technically, but the only choice for de= ployability), the limitations of TCP become apparent and people are still i= nterested in addressing those within the given confines...=20 =20 Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Scharf, Michael (Michael) > Sent: Donnerstag, 02. August 2012 16:11 > To: Yuchung Cheng > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for > accurate feedback >=20 > > > is accurate ECN part of "maintenance and minor extension"? >=20 > Do you argue that it is a major change? >=20 > For instance, just transporting a more accurate encoding does not imply > that CC is changed at all. >=20 > > I second that to add acc-ECN to tcpm, but often times I am confused > > the roles between iccrg and tcpm. To me there should be a tcp-dev to > > discuss all TCP changes. Other protocols often just apply the > > principles of CC in TCP. >=20 > ICCRG is reseach... Is more research needed to find for an experimental > encoding that allows more than one feedback per RTT? >=20 > Anybody who thinks that this topic would be too "disruptive" for TCPM: > Please speak up now. >=20 > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Thu Aug 2 17:59:58 2012 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 DBC6621F8C03 for ; Thu, 2 Aug 2012 17:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.95 X-Spam-Level: X-Spam-Status: No, score=-102.95 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0xv65WbU-J1 for ; Thu, 2 Aug 2012 17:59:58 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F38A21F8BFD for ; Thu, 2 Aug 2012 17:59:58 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so245448obb.31 for ; Thu, 02 Aug 2012 17:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=JJefkt+eIoKMuCb0nYOlyoPkRj8Jj72anKLRr/6L8Xg=; b=BeeS8LpFkbi2xDoVu1HfYN3JQK60musP2kn2AWF++nhk4vaNoGbtPmLQ1x/l/lFx+C kIhOPk4ylvJarRxpQgzua8c9rnkeeUTsD5srU0lYRNdu1b0ZW8BgMbV9aQ6XAF8E7Nde YJuUbBFl9DtFrU2jBLpY22VfE07aqeSB8snWqK2N1qhD66ildb7/P9IgwrqrzG6m1biX CqViQNcDA7VHhoyBf7uqN5n6LqZbI9qnXKxJ5eFSxT4Pmkj5KvwkFCCfhShwhLnR5dE0 49v/yiC/CZg4bs6IUTJQIUp58RVFnyHybf/eJvjhGkz85mhzx/B/McyYBjI2ER9HLoa1 o3LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=JJefkt+eIoKMuCb0nYOlyoPkRj8Jj72anKLRr/6L8Xg=; b=Xxbiv73g4MorZ1AgAxpLo/riEfHR2Q0pH+VWtXwjU6wNbGh7mFPUAK3qlIOaOSoZQT B04cdrlMmdQTQptJr59e6vE8iQFkRicuehFWTe8AmWNu8gpqtvBND1sg7Hv5ExYZQ3NS DwGw94aimGjbcxjr0m4TTwVdLz0XOmYiW1Pms4ChKgfVBa4Ay1/8Op6Ufr6pu3jsRHbA AB9xX0qx4RzCi4oS5jqMxGadtjf9AYpfVuHTghZYe+DktR5cJILa6Ogp1tz6MqRFp+Iy lC381QYcFtn9Lu+mAaVloSRVlbjyCQV8jgvaTqfwA8AS1/Aj3INVIiTDrqNYYJ/ldS4y gZfA== Received: by 10.60.28.101 with SMTP id a5mr40994939oeh.69.1343955597668; Thu, 02 Aug 2012 17:59:57 -0700 (PDT) Received: by 10.60.28.101 with SMTP id a5mr40994932oeh.69.1343955597541; Thu, 02 Aug 2012 17:59:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.99.37 with HTTP; Thu, 2 Aug 2012 17:59:37 -0700 (PDT) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDAA@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDAA@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Thu, 2 Aug 2012 17:59:37 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmhJ4hed63ACPRtL99/d0IuFdmsyXgbKwb82U2fP3g3VDsBsUWhRRmsL4wxgMhTtC1rViB7wZuecMp0fwO9xV/k+vFMivESeQCDcfd0bRfJweK3vSgNtKHKmLUmsJxvAEkBQda5Yo45haqEqkcM9n96i7x67OevTrDMrUDYimw/r9iNYj0= Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 03 Aug 2012 00:59:59 -0000 On Thu, Aug 2, 2012 at 4:10 PM, Scharf, Michael (Michael) wrote: >> > is accurate ECN part of "maintenance and minor extension"? > > Do you argue that it is a major change? > > For instance, just transporting a more accurate encoding does not imply that CC is changed at all. > >> I second that to add acc-ECN to tcpm, but often times I am >> confused the roles between iccrg and tcpm. To me there should >> be a tcp-dev to discuss all TCP changes. Other protocols >> often just apply the principles of CC in TCP. > > ICCRG is reseach... Is more research needed to find for an experimental encoding that allows more than one feedback per RTT? > > Anybody who thinks that this topic would be too "disruptive" for TCPM: Please speak up now. with the proposed milestone, we'll add more signals to ECN then ? discuss what to do about them in iccrg or other group? what's the plan for better ECN is my question. sorry if this sounds dumb. > > Michael From john@jlc.net Thu Aug 2 18:28:32 2012 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 508CF21F8C39 for ; Thu, 2 Aug 2012 18:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.596 X-Spam-Level: X-Spam-Status: No, score=-105.596 tagged_above=-999 required=5 tests=[AWL=1.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeH23EH9fHqL for ; Thu, 2 Aug 2012 18:28:31 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 5E53E21F8AB3 for ; Thu, 2 Aug 2012 18:28:31 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id E409033C20; Thu, 2 Aug 2012 21:28:30 -0400 (EDT) Date: Thu, 2 Aug 2012 21:28:30 -0400 From: John Leslie To: "Scharf, Michael (Michael)" Message-ID: <20120803012830.GC59530@verdi> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> User-Agent: Mutt/1.4.1i Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 03 Aug 2012 01:28:32 -0000 Scharf, Michael (Michael) wrote: > > We therefore want to confirm that working group consensus is to add > the following milestone to the TCPM carter: > > "Sep 2013 Submit document on accurate ECN feedback in TCP to the > IESG for publication as an Experimental RFC" > > The chairs believe that the consensus is not to adopt any specific > document as of now. However, the working group should converge on > the mechanism by March 2013 latest. I find myself worried by the name "accurate ECN feedback". That is a reasonable name for the draft we've seen; but I don't think it's the right name for the _output_ of this WG. The issue is a bit complicated, alas: there's very good reason to want a signal coming back to the sender which carries more precision than the current signal (ECN-Echo in an unreliable ACK). Quoting RFC 3168 Section 6.1: ] ] * An ECT codepoint is set in packets transmitted by the sender to ] indicate that ECN is supported by the transport entities for ] these packets. ] ] * An ECN-capable router detects impending congestion and detects ] that an ECT codepoint is set in the packet it is about to drop. ] Instead of dropping the packet, the router chooses to set the CE ] codepoint in the IP header and forwards the packet. ] ] * The receiver receives the packet with the CE codepoint set, and ] sets the ECN-Echo flag in its next TCP ACK sent to the sender. ] ] * The sender receives the TCP ACK with ECN-Echo set, and reacts to ] the congestion as if a packet had been dropped. ] ] * The sender sets the CWR flag in the TCP header of the next ] packet sent to the receiver to acknowledge its receipt of and ] reaction to the ECN-Echo flag. In fact, due to the unreliable nature of the ACK, the receiver continues to set ECN-Echo (ECE) until it sees a CWR. From 6.1.3: ] ] To provide robustness against the possibility of a dropped ACK packet ] carrying an ECN-Echo flag, the TCP receiver sets the ECN-Echo flag in ] a series of ACK packets sent subsequently. The TCP receiver uses the ] CWR flag received from the TCP sender to determine when to stop ] setting the ECN-Echo flag. This is messy! and it is only acceptable for trying to match the window-reduction of a packet loss. So there is very good reason to come up with a mechanism to provide better reliability and precision of informing the sender about ECT codepoints seen by the reciver. I entirely support such an effort, but I think "greater precision" would be a better term than "accurate". -- John Leslie From mallman@icir.org Fri Aug 3 08:12:34 2012 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 7E86A21F8DBD for ; Fri, 3 Aug 2012 08:12:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dem9ojYBYp5L for ; Fri, 3 Aug 2012 08:12:34 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 09BD321F8D9A for ; Fri, 3 Aug 2012 08:12:34 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q73FCVso003131; Fri, 3 Aug 2012 08:12:31 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 06CED26594A9; Fri, 3 Aug 2012 11:12:31 -0400 (EDT) To: Anthony Sabatini From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Pretending X-URL-0: http://www.icir.org/mallman-files/Document68108.doc MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma59996-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 03 Aug 2012 11:12:31 -0400 Sender: mallman@icir.org Message-Id: <20120803151231.06CED26594A9@lawyers.icir.org> Cc: tcpm@ietf.org, "Matthew Mathis \(mattmathis@google.com\)" , Joe Touch Subject: Re: [tcpm] Settling Time and RFC3517bis 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: Fri, 03 Aug 2012 15:12:34 -0000 ----------ma59996-1 Content-Type: text/plain Content-Disposition: inline This is all pretty mis-guided. Let me say just a few quick things. > 3) STANDARD TCP can not recover in less than one RTT, Correct. Nor would we want it to. If you retransmit in less than one RTT from the time a segment is originally sourced then you will always be retransmitting blind. I.e., you'll have no indication as to whether that segment needs to be retransmitted or not. > SACK TCP as written certainly can and does currently recover in > less that one RTT on at least long links. Incorrect. At least I am aware of no TCP SACK-based loss recovery variant that retransmits a segment less than one RTT after it was originally sent. You reference 3517bis in the subject. The algorithm specified in RFC 3517 and 3517bis *does not* retransmit a segment in less than one RTT. > With the changes I have been proposing nearly all errors can be > recovered in less than one RTT. The only way to recover in less than one RTT is to retransmit blind. I.e., retransmit segments without any indication as to whether they have arrived at the receiver or not. One could write such an algorithm. And, probably show it fixes lost segments sooner. But, the question would immediately become "at what cost?". I.e., how many needless retransmits are being piled into the network to accomplish this task? And, the answer nearly has to be proportional to the benefit you obtain. I.e., I bet that as you speculatively retransmit more segments you will also spurious retransmit more segments. And, this is needless retransmits that we know are being piled into a congested network and so are using scarce network resources. So, all around a bad idea. allman ----------ma59996-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlAb6l4ACgkQWyrrWs4yIs5+TQCdGRg5cAxNZoCG5oPJ4s8dz4mi s/oAoIEaI99AE7N7JqpbWOlWp8oPxswV =Ak87 -----END PGP SIGNATURE----- ----------ma59996-1-- From elb@psg.com Thu Aug 2 14:57:14 2012 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 E947E21E8090 for ; Thu, 2 Aug 2012 14:57: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVvn8DxXIq1L for ; Thu, 2 Aug 2012 14:57:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1C83111E80F0 for ; Thu, 2 Aug 2012 14:57:14 -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.77 (FreeBSD)) (envelope-from ) id 1Sx3OK-0003wX-Jo; Thu, 02 Aug 2012 21:57:12 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id E2FE63C77C; Thu, 2 Aug 2012 17:57:11 -0400 (EDT) Date: Thu, 2 Aug 2012 17:57:11 -0400 From: Ethan Blanton To: Anthony Sabatini Message-ID: <20120802215711.GA4665@colt> Mail-Followup-To: Anthony Sabatini , Joe Touch , tcpm@ietf.org, "Matthew Mathis (mattmathis@google.com)" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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) X-Mailman-Approved-At: Fri, 03 Aug 2012 08:23:34 -0700 Cc: tcpm@ietf.org, "Matthew Mathis \(mattmathis@google.com\)" , Joe Touch Subject: Re: [tcpm] Settling Time and RFC3517bis 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, 02 Aug 2012 21:57:15 -0000 Anthony Sabatini spake unto us the following wisdom: > 2) My point about fragmentation is that "Fragmentation Reassembly > Timer" and "Reordering Time" are different names to describe the same > issue. They are not. This seems to reflect a fundamental misunderstanding of the respective roles of IP and TCP. There are two primary differences between IP fragmentation and TCP segmentation for the purposes of this specific discussion, namely: * IP fragmentation and delivery are best-effort, while TCP segments are reliable (at a higher layer in the stack than the IP datagrams they ride in) * IP fragments of a single datagram are always generated nearly simultaneously (within the performance limits of the IP stack and the local transport hardware), while TCP segments may be generated and emitted arbitrarily far apart in time Each of these points has an important implication. The first means that, if you do not receive the fragments of an IP segment quite rapidly (and a single RTT is a reasonable upper bound, though certainly one could envision cases where it may take longer), you are not going to receive them at all. The IP datagram can be discarded blindly, and the sending machine will retransmit its contents via whatever appropriate means if its upper-layer protocols direct so. The TCP segment, on the other hand, must have its suspected loss somehow transmitted back to the sending TCP so that it can be retransmitted. The second point means that a TCP segment can arrive at any time and may arrive a very long time (days, months, or years, in the extreme) after the previous segment. It is true that, under normal conditions, a TCP segment should not arrive long after a *succeeding* segment, but it can happen, and as TCP is a reliable transport, this should be accounted for. Since TCP cannot react to loss in less than one full RTT anyway (another misconception in your logic, more below), the receiving TCP might as well wait a full RTT or more for progress. If the segment is truly lost, the connection will only begin to (substantially) suffer performance-wise if the sending 3517-compliant TCP runs out of new data to send. Until that time, whether the segment is retransmitted in the meantime or not, the TCP will proceed essentially unaltered. (The precise timing of the retransmission will affect segment clocking somewhat, but in the long run, in the case of a true loss, this should be a moderate effect.) > 3) STANDARD TCP can not recover in less than one RTT, SACK TCP as > written certainly can and does currently recover in less that one RTT > on at least long links. With the changes I have been proposing nearly > all errors can be recovered in less than one RTT. This is entirely untrue. It takes one RTT at minimum for a sending TCP to receive indication from the receiver that a segment was lost. The sending TCP must send segments following the lost segment that the receiving TCP SACKs. Only when those SACK blocks arrive at the sending TCP does it know that the segment was possibly lost. > 6) Why is the IETF spending all of its time covering for greedy > carriers who do not install enough fiber or switching equipment? ALL > of the changes being made in the congestion area result in a WORSE > experience for the end user, the people we should really care about. I recommend that you read the following paper: Congestion Avoidance and Control. Van Jacobson. Proceedings of the SIGCOMM 1988 Symposium on Communications Architectures and Protocols. pp. 314--329. A version of this paper was published in the 1988 Computer Communications Review, and a version co-authored by Michael Karels also appeared in 1988 with additional information. The takeaway from these papers is that, not only is congestion control a good idea on paper, but its absence has been documented to cause congestion collapse and complete non-responsiveness of the network to useful traffic. You are correct that provisioning can help this circumstance *in some cases*, but it cannot, by definition, help in all cases -- there can always exist a situation where the network has more packets in flight than it can support, no matter how widely provisioned, if the provisioning is finite. A lesson learned from the congestion collapses of the 80s is that this condition of over over-subscription of valuable data does not even have to persist -- it only has to last long enough for the retransmissions of that valuable data to overwhelm the network. Ethan From rs@netapp.com Fri Aug 3 09:40:25 2012 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 D80D121F8D5D for ; Fri, 3 Aug 2012 09:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.194 X-Spam-Level: X-Spam-Status: No, score=-10.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1QWcbIRLzXJ for ; Fri, 3 Aug 2012 09:40:24 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id C0EBF21F8D5B for ; Fri, 3 Aug 2012 09:40:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,707,1336374000"; d="scan'208";a="672896718" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 03 Aug 2012 09:40:15 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q73Ge2rE024087; Fri, 3 Aug 2012 09:40:14 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.34]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 09:40:07 -0700 From: "Scheffenegger, Richard" To: John Leslie , "Scharf, Michael (Michael)" Thread-Topic: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback Thread-Index: AQHNcRdNm+gbE5XUrUGt+OV5rFZDwpdHU7Vg Date: Fri, 3 Aug 2012 16:40:06 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D4E39FE@SACEXCMBX02-PRD.hq.netapp.com> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120803012830.GC59530@verdi> In-Reply-To: <20120803012830.GC59530@verdi> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 03 Aug 2012 16:40:26 -0000 Hi John, Am I right in assuming that with "greater precision" you imply that this do= esn't necessarily mean "exact" feedback? (Originally we discussed using "more accurate" in the title of the draft; = that meant lower precision than "exact", but the "more" got lost along the = way, leaving "accurate"). I would argue that the current ECE/CWR mechanism is perfectly reliable - up= to a certain precision limited by the number of bits set aside for the sig= nal back from the receiver to the sender. What would be more reliable? (ECE is a counter that can only increase, and remains at the maximum value = until being reset; CWR provides the reset signal). OTOH, if the feedback signal is encoded with enough bits, reliability can b= e brought arbitrarily close to "perfect", even without an explicit forward = signal (CWR). As soon as the counter (and signal for it) cover all the packets individual= ly in a window, the ECN feedback can be exact; The question becomes, can th= e reset mechanism be abandoned when "enough" bits are available for the sig= nal, or must the principal architecture (a counter increasing up to some po= int, until it is reset) be maintained... BTW: I found that ECN for SCTP also failed to discuss this, but there a 32 = bit counter is used (plus a Reset signal/CWR). To jump forward a bit, I suspect the delineation is somewhere around 5 bits= (2.3 bits in the codepoint draft; 3 bits in reECN; 8 bits in the TCP Optio= n draft). Using 5 bits or less, a handshare mechanism is required; using mo= re than 5, and a simple counter suffices to maintain exactness (until TCP s= uffers from loss of the ACK clock etc). The signaling is another question; Perhaps a certain loss of granularity is= acceptable for the currently discussed protocols (i.e. Conex; slight overe= stimating congestion is not as bad as underestimating). But other (future) = uses (e.g. DCTCP) would probably require the full precision - with other wo= rds, "exact" signaling... However, we (authors), while discussing this internally, would also be glad= of any opinion regarding this! Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > John Leslie > Sent: Donnerstag, 02. August 2012 18:29 > To: Scharf, Michael (Michael) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for > accurate feedback >=20 > Scharf, Michael (Michael) wrote: > > > > We therefore want to confirm that working group consensus is to add > > the following milestone to the TCPM carter: > > > > "Sep 2013 Submit document on accurate ECN feedback in TCP to the > > IESG for publication as an Experimental RFC" > > > > The chairs believe that the consensus is not to adopt any specific > > document as of now. However, the working group should converge on > > the mechanism by March 2013 latest. >=20 > I find myself worried by the name "accurate ECN feedback". >=20 > That is a reasonable name for the draft we've seen; but I don't > think it's the right name for the _output_ of this WG. >=20 > The issue is a bit complicated, alas: there's very good reason > to want a signal coming back to the sender which carries more > precision than the current signal (ECN-Echo in an unreliable ACK). > Quoting RFC 3168 Section 6.1: > ] > ] * An ECT codepoint is set in packets transmitted by the sender to > ] indicate that ECN is supported by the transport entities for > ] these packets. > ] > ] * An ECN-capable router detects impending congestion and detects > ] that an ECT codepoint is set in the packet it is about to drop. > ] Instead of dropping the packet, the router chooses to set the CE > ] codepoint in the IP header and forwards the packet. > ] > ] * The receiver receives the packet with the CE codepoint set, and > ] sets the ECN-Echo flag in its next TCP ACK sent to the sender. > ] > ] * The sender receives the TCP ACK with ECN-Echo set, and reacts to > ] the congestion as if a packet had been dropped. > ] > ] * The sender sets the CWR flag in the TCP header of the next > ] packet sent to the receiver to acknowledge its receipt of and > ] reaction to the ECN-Echo flag. >=20 > In fact, due to the unreliable nature of the ACK, the receiver > continues to set ECN-Echo (ECE) until it sees a CWR. From 6.1.3: > ] > ] To provide robustness against the possibility of a dropped ACK packet > ] carrying an ECN-Echo flag, the TCP receiver sets the ECN-Echo flag in > ] a series of ACK packets sent subsequently. The TCP receiver uses the > ] CWR flag received from the TCP sender to determine when to stop > ] setting the ECN-Echo flag. >=20 > This is messy! and it is only acceptable for trying to match the > window-reduction of a packet loss. >=20 > So there is very good reason to come up with a mechanism to provide > better reliability and precision of informing the sender about ECT > codepoints seen by the reciver. >=20 > I entirely support such an effort, but I think "greater precision" > would be a better term than "accurate". >=20 > -- > John Leslie > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From john@jlc.net Fri Aug 3 11:34:22 2012 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 AC0AF11E8098 for ; Fri, 3 Aug 2012 11:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.647 X-Spam-Level: X-Spam-Status: No, score=-105.647 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjfGmoGRbQr1 for ; Fri, 3 Aug 2012 11:34:22 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id B9A8611E808D for ; Fri, 3 Aug 2012 11:34:21 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 458DB33C24; Fri, 3 Aug 2012 14:34:21 -0400 (EDT) Date: Fri, 3 Aug 2012 14:34:21 -0400 From: John Leslie To: "Scheffenegger, Richard" Message-ID: <20120803183421.GB15012@verdi> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120803012830.GC59530@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E39FE@SACEXCMBX02-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D4E39FE@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Mutt/1.4.1i Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 03 Aug 2012 18:34:22 -0000 Scheffenegger, Richard wrote: > > Hi John, > > Am I right in assuming that with "greater precision" you imply that > this doesn't necessarily mean "exact" feedback? Yes, but... This is mainly to avoid arguing what "exact" might mean. > (Originally we discussed using "more accurate" in the title of the draft; > that meant lower precision than "exact", but the "more" got lost along > the way, leaving "accurate"). (I must admit I'm at least as anxious to avoid arguing what "accurate" might mean.) > I would argue that the current ECE/CWR mechanism is perfectly reliable I might take the other side of that argument... > - up to a certain precision limited by the number of bits set aside > for the signal back from the receiver to the sender. What would be more > reliable? "Reliable" in TCP means that everything not acknowledged will be retransmitted. That would imply repeating each ECE until that specific ECE is acknowledged -- and clarifying to the sender how that CWR was understood. But I'm not trying to argue either way whether "reliable" would be "better" than "unreliable". > (ECE is a counter that can only increase, and remains at the maximumi > value until being reset; CWR provides the reset signal). Umm... "remains at maximum" implies some loss of precision... > OTOH, if the feedback signal is encoded with enough bits, reliability > can be brought arbitrarily close to "perfect", even without an explicit > forward signal (CWR). Indeed, one could argue "reliability" by unacknowledged repetition. (I'd prefer some other term, but it certainly would serve for the "precision" I was seeking.) > As soon as the counter (and signal for it) cover all the packets > individually in a window, the ECN feedback can be exact; Actually, there are two counters, packets and (payload) bytes. > The question becomes, can the reset mechanism be abandoned when > "enough" bits are available for the signal, or must the principal > architecture (a counter increasing up to some point, until it is > reset) be maintained... I don't choose to express an opinion on that yet. > BTW: I found that ECN for SCTP also failed to discuss this, but > there a 32 bit counter is used (plus a Reset signal/CWR). :^) > To jump forward a bit, I suspect the delineation is somewhere around > 5 bits (2.3 bits in the codepoint draft; 3 bits in reECN; 8 bits in > the TCP Option draft). Using 5 bits or less, a handshare mechanism is > required; using more than 5, and a simple counter suffices to maintain > exactness (until TCP suffers from loss of the ACK clock etc). No comment (yet)... > The signaling is another question; Perhaps a certain loss of > granularity is acceptable for the currently discussed protocols > (i.e. Conex; slight overestimating congestion is not as bad as > underestimating). But other (future) uses (e.g. DCTCP) would probably > require the full precision - with other words, "exact" signaling... "Exact" _is_ a reasonable goal... > However, we (authors), while discussing this internally, would also > be glad of any opinion regarding this! I will note that current ECN processing in TCP is awfully specialized: I can imagine congestion-control algorithms it would serve poorly. :^( But leaving that aside, ECN processing for other transport protocols almost certainly deserves a different treatment. It would be nice if our "greater precision" effort could serve the needs of yet-unseen future transport protocols. -- John Leslie From rs@netapp.com Fri Aug 3 13:58:39 2012 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 03DD921E808E for ; Fri, 3 Aug 2012 13:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twtVXlli6S7o for ; Fri, 3 Aug 2012 13:58:38 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4613521E808A for ; Fri, 3 Aug 2012 13:58:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,708,1336374000"; d="scan'208";a="672991567" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 03 Aug 2012 13:58:23 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q73KwMU4019513; Fri, 3 Aug 2012 13:58:23 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.34]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 13:58:21 -0700 From: "Scheffenegger, Richard" To: John Leslie Thread-Topic: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback Thread-Index: AQHNcaad6WGNeCXLeE+xrdvJ28VJWZdIjAjA Date: Fri, 3 Aug 2012 20:58:18 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D4E4381@SACEXCMBX02-PRD.hq.netapp.com> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120803012830.GC59530@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E39FE@SACEXCMBX02-PRD.hq.netapp.com> <20120803183421.GB15012@verdi> In-Reply-To: <20120803183421.GB15012@verdi> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 03 Aug 2012 20:58:39 -0000 Hi John, Thanks for your comments so far! > > I would argue that the current ECE/CWR mechanism is perfectly reliable >=20 > I might take the other side of that argument... Could you please explain? (I should have perhaps added, RFC3168 is perfectl= y reliable for at least, and up to, one CE mark per RTT; The sender gets th= e information that at least one CE mark was received in the RTT under all c= ircumstances). > Actually, there are two counters, packets and (payload) bytes. Correct; but as soon as not every data segment is ACKed (and the ACK not lo= st), the delineation (for figuring out which payload bytes got marked) beco= mes fuzzy... Even when the sender keeps state as to the segment boundaries,= it's not clear which of multiple segments were marked (except in the two e= xtreme cases), when delayed ACKs (or even ACK compression) are in play...=20 Which brings up another question that I haven't put in this forum: Will there be a conceivable benefit when the sender knows the exact order o= r markings? The way the receiver ECN state-machine of DCTCP is described allows the sen= der to reconstruct the exact order of markings (the "CE stream"), provided = no (relevant) ACKs are lost. With the complication that the sender rarely k= nows, when and if a relevant ACK got dropped... This level of precision is lost, when the receiver uses some kind of summar= y signal; But making such a signal reliable requires even more bits, and so= me more or less complex encoding scheme... But I am not sure if such an extreme precision will be necessary to TCP at = least (and other transports do provide means to encode that...) To have a proper counter (congested bytes), I think that would need to be e= xplicit; Mirja did some experiments using implicit ACKs, but to get them wo= rk properly, you end up with sending out more ACKs than strictly necessary = (like what DCTCP receivers do), and single ACK loss can still result in wro= ng signals at the sender.... Richard Scheffenegger > -----Original Message----- > From: John Leslie [mailto:john@jlc.net] > Sent: Freitag, 03. August 2012 11:34 > To: Scheffenegger, Richard > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for > accurate feedback >=20 > Scheffenegger, Richard wrote: > > > > Hi John, > > > > Am I right in assuming that with "greater precision" you imply that > > this doesn't necessarily mean "exact" feedback? >=20 > Yes, but... This is mainly to avoid arguing what "exact" might mean. >=20 > > (Originally we discussed using "more accurate" in the title of the > > draft; that meant lower precision than "exact", but the "more" got > > lost along the way, leaving "accurate"). >=20 > (I must admit I'm at least as anxious to avoid arguing what "accurate" > might mean.) >=20 > > I would argue that the current ECE/CWR mechanism is perfectly reliable >=20 > I might take the other side of that argument... >=20 > > - up to a certain precision limited by the number of bits set aside > > for the signal back from the receiver to the sender. What would be > > more reliable? >=20 > "Reliable" in TCP means that everything not acknowledged will be > retransmitted. That would imply repeating each ECE until that specific EC= E > is acknowledged -- and clarifying to the sender how that CWR was > understood. >=20 > But I'm not trying to argue either way whether "reliable" would be > "better" than "unreliable". >=20 > > (ECE is a counter that can only increase, and remains at the maximumi > > value until being reset; CWR provides the reset signal). >=20 > Umm... "remains at maximum" implies some loss of precision... >=20 > > OTOH, if the feedback signal is encoded with enough bits, reliability > > can be brought arbitrarily close to "perfect", even without an > > explicit forward signal (CWR). >=20 > Indeed, one could argue "reliability" by unacknowledged repetition. > (I'd prefer some other term, but it certainly would serve for the > "precision" I was seeking.) >=20 > > As soon as the counter (and signal for it) cover all the packets > > individually in a window, the ECN feedback can be exact; >=20 > Actually, there are two counters, packets and (payload) bytes. >=20 > > The question becomes, can the reset mechanism be abandoned when > > "enough" bits are available for the signal, or must the principal > > architecture (a counter increasing up to some point, until it is > > reset) be maintained... >=20 > I don't choose to express an opinion on that yet. >=20 > > BTW: I found that ECN for SCTP also failed to discuss this, but there > > a 32 bit counter is used (plus a Reset signal/CWR). >=20 > :^) >=20 > > To jump forward a bit, I suspect the delineation is somewhere around > > 5 bits (2.3 bits in the codepoint draft; 3 bits in reECN; 8 bits in > > the TCP Option draft). Using 5 bits or less, a handshare mechanism is > > required; using more than 5, and a simple counter suffices to maintain > > exactness (until TCP suffers from loss of the ACK clock etc). >=20 > No comment (yet)... >=20 > > The signaling is another question; Perhaps a certain loss of > > granularity is acceptable for the currently discussed protocols (i.e. > > Conex; slight overestimating congestion is not as bad as > > underestimating). But other (future) uses (e.g. DCTCP) would probably > > require the full precision - with other words, "exact" signaling... >=20 > "Exact" _is_ a reasonable goal... >=20 > > However, we (authors), while discussing this internally, would also be > > glad of any opinion regarding this! >=20 > I will note that current ECN processing in TCP is awfully specialized: > I can imagine congestion-control algorithms it would serve poorly. :^( Bu= t > leaving that aside, ECN processing for other transport protocols almost > certainly deserves a different treatment. >=20 > It would be nice if our "greater precision" effort could serve the > needs of yet-unseen future transport protocols. >=20 > -- > John Leslie From tsabatini@hotmail.com Fri Aug 3 16:37:42 2012 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 DDEAC21E8048 for ; Fri, 3 Aug 2012 16:37:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnvwqoccVjrO for ; Fri, 3 Aug 2012 16:37:42 -0700 (PDT) Received: from blu0-omc2-s17.blu0.hotmail.com (blu0-omc2-s17.blu0.hotmail.com [65.55.111.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1C121E8045 for ; Fri, 3 Aug 2012 16:37:42 -0700 (PDT) Received: from BLU0-SMTP185 ([65.55.111.71]) by blu0-omc2-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Aug 2012 16:37:42 -0700 X-Originating-IP: [130.129.66.12] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Received: from [130.129.66.12] ([130.129.66.12]) by BLU0-SMTP185.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Aug 2012 16:37:39 -0700 Date: Fri, 3 Aug 2012 19:37:32 -0400 From: Anthony Sabatini To: mallman@icir.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 03 Aug 2012 23:37:39.0468 (UTC) FILETIME=[F8308CC0:01CD71D0] Cc: tcpm@ietf.org, "Matthew Mathis \(mattmathis@google.com\)" , Joe Touch Subject: Re: [tcpm] Settling Time and RFC3517bis 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, 03 Aug 2012 23:37:43 -0000 QWxsIC0KCkJlY2F1c2Ugb2YgdGhlIHdvcmRpbmcgb2YgdGhlIG9yaWdpbmFsIGNvbW1lbnQgaXQg d2FzIG5vdCBjbGVhciB3aGV0aGVyIHRoZSBSVFQgcmVmZXJyZWQgdG8gdGhlIGdlbmVyYXRlZCBT QUNLIGluZm9ybWF0aW9uIGZyb20gdGhlIHJlY2VpdmVyIG9yIHRoZSBvcmlnaW5hbCB0cmFuc21p c3Npb24gZnJvbSB0aGUgc2VuZGVyLiAgQnkgZGVmaW5pdGlvbiwgd2l0aCByZXNwZWN0IHRvIHRo ZSBzZW5kZXIsIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBwcm9wZXJseSByZXRyYW5zbWl0IHRoZSBt ZXNzYWdlIGluIGxlc3MgdGhhbiBvbmUgUlRUIHBsdXMgUmVvcmRlcmluZyB0aW1lIHBsdXMgcHJv Y2Vzc2luZyB0aW1lLgoKSSBhbSBzb3JyeSBmb3IgdGhpcyBtaXN1bmRlcnN0YW5kaW5nLgoKVG9u eQoKU2VudCBmcm9tIG15IEFTVVMgUGFkCgpNYXJrIEFsbG1hbiA8bWFsbG1hbkBpY2lyLm9yZz4g d3JvdGU6Cgo+Cj5UaGlzIGlzIGFsbCBwcmV0dHkgbWlzLWd1aWRlZC4gIExldCBtZSBzYXkganVz dCBhIGZldyBxdWljayB0aGluZ3MuCj4KPj4gMykgU1RBTkRBUkQgVENQIGNhbiBub3QgcmVjb3Zl ciBpbiBsZXNzIHRoYW4gb25lIFJUVCwgCj4KPkNvcnJlY3QuICBOb3Igd291bGQgd2Ugd2FudCBp dCB0by4gIElmIHlvdSByZXRyYW5zbWl0IGluIGxlc3MgdGhhbiBvbmUKPlJUVCBmcm9tIHRoZSB0 aW1lIGEgc2VnbWVudCBpcyBvcmlnaW5hbGx5IHNvdXJjZWQgdGhlbiB5b3Ugd2lsbCBhbHdheXMK PmJlIHJldHJhbnNtaXR0aW5nIGJsaW5kLiAgSS5lLiwgeW91J2xsIGhhdmUgbm8gaW5kaWNhdGlv biBhcyB0byB3aGV0aGVyCj50aGF0IHNlZ21lbnQgbmVlZHMgdG8gYmUgcmV0cmFuc21pdHRlZCBv ciBub3QuCj4KPj4gICAgU0FDSyBUQ1AgYXMgd3JpdHRlbiBjZXJ0YWlubHkgY2FuIGFuZCBkb2Vz IGN1cnJlbnRseSByZWNvdmVyIGluCj4+ICAgIGxlc3MgdGhhdCBvbmUgUlRUIG9uIGF0IGxlYXN0 IGxvbmcgbGlua3MuICAKPgo+SW5jb3JyZWN0LiAgQXQgbGVhc3QgSSBhbSBhd2FyZSBvZiBubyBU Q1AgU0FDSy1iYXNlZCBsb3NzIHJlY292ZXJ5Cj52YXJpYW50IHRoYXQgcmV0cmFuc21pdHMgYSBz ZWdtZW50IGxlc3MgdGhhbiBvbmUgUlRUIGFmdGVyIGl0IHdhcwo+b3JpZ2luYWxseSBzZW50LiAg WW91IHJlZmVyZW5jZSAzNTE3YmlzIGluIHRoZSBzdWJqZWN0LiAgVGhlIGFsZ29yaXRobQo+c3Bl Y2lmaWVkIGluIFJGQyAzNTE3IGFuZCAzNTE3YmlzICpkb2VzIG5vdCogcmV0cmFuc21pdCBhIHNl Z21lbnQgaW4KPmxlc3MgdGhhbiBvbmUgUlRULgo+Cj4+ICAgIFdpdGggdGhlIGNoYW5nZXMgSSBo YXZlIGJlZW4gcHJvcG9zaW5nIG5lYXJseSBhbGwgZXJyb3JzIGNhbiBiZQo+PiAgICByZWNvdmVy ZWQgaW4gbGVzcyB0aGFuIG9uZSBSVFQuCj4KPlRoZSBvbmx5IHdheSB0byByZWNvdmVyIGluIGxl c3MgdGhhbiBvbmUgUlRUIGlzIHRvIHJldHJhbnNtaXQgYmxpbmQuCj5JLmUuLCByZXRyYW5zbWl0 IHNlZ21lbnRzIHdpdGhvdXQgYW55IGluZGljYXRpb24gYXMgdG8gd2hldGhlciB0aGV5IGhhdmUK PmFycml2ZWQgYXQgdGhlIHJlY2VpdmVyIG9yIG5vdC4gIE9uZSBjb3VsZCB3cml0ZSBzdWNoIGFu IGFsZ29yaXRobS4KPkFuZCwgcHJvYmFibHkgc2hvdyBpdCBmaXhlcyBsb3N0IHNlZ21lbnRzIHNv b25lci4gIEJ1dCwgdGhlIHF1ZXN0aW9uCj53b3VsZCBpbW1lZGlhdGVseSBiZWNvbWUgImF0IHdo YXQgY29zdD8iLiAgSS5lLiwgaG93IG1hbnkgbmVlZGxlc3MKPnJldHJhbnNtaXRzIGFyZSBiZWlu ZyBwaWxlZCBpbnRvIHRoZSBuZXR3b3JrIHRvIGFjY29tcGxpc2ggdGhpcyB0YXNrPwo+QW5kLCB0 aGUgYW5zd2VyIG5lYXJseSBoYXMgdG8gYmUgcHJvcG9ydGlvbmFsIHRvIHRoZSBiZW5lZml0IHlv dSBvYnRhaW4uCj5JLmUuLCBJIGJldCB0aGF0IGFzIHlvdSBzcGVjdWxhdGl2ZWx5IHJldHJhbnNt aXQgbW9yZSBzZWdtZW50cyB5b3Ugd2lsbAo+YWxzbyBzcHVyaW91cyByZXRyYW5zbWl0IG1vcmUg c2VnbWVudHMuICAKPgo+QW5kLCB0aGlzIGlzIG5lZWRsZXNzIHJldHJhbnNtaXRzIHRoYXQgd2Ug a25vdyBhcmUgYmVpbmcgcGlsZWQgaW50byBhCj5jb25nZXN0ZWQgbmV0d29yayBhbmQgc28gYXJl IHVzaW5nIHNjYXJjZSBuZXR3b3JrIHJlc291cmNlcy4gIFNvLCBhbGwKPmFyb3VuZCBhIGJhZCBp ZGVhLgo+Cj5hbGxtYW4KPgo+Cj4K From mattmathis@google.com Sun Aug 5 13:02:10 2012 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 B823121F8522 for ; Sun, 5 Aug 2012 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU7t61v1g-sb for ; Sun, 5 Aug 2012 13:02:09 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 443C521F851B for ; Sun, 5 Aug 2012 13:02:08 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so831229wib.13 for ; Sun, 05 Aug 2012 13:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=gCK+MFmUQvR4jEpaX4+Fa9U83NJt9uycI9Dc1vntnw4=; b=WK7rx/0TtrQO3QS8ytCquKfkA/b+T6PqePfzNDwsN5RvlDeMdbmagud8R4DjRC6+Z0 VN98gi8i1hBdOc7hQiVEceXXToRx0Tv3qgSF08pqA+SY4EhC7vWbpD9Qf7ukg3J0fGcQ zyOgBT7SyNZYQLN2G6KWmP/8eS03JU25Fd1SSoDUj3mfzKX1JRNkwJICs4N+rJ2TJFNB gRy0LKxdT7b5G3IpWmDSOYMFEB2O4DRRXJLdrz3yFNvSGpX6FQwbbVNL6UQDXZltVno5 WVuCC0tIBoJX3judXZGQYUllNiqvthyMW4hudx6TKOxsCGkUYw01d/HCP15Y7dS4eT84 RDMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=gCK+MFmUQvR4jEpaX4+Fa9U83NJt9uycI9Dc1vntnw4=; b=DYKNkQ8ubR/HTI9lS13MBAgh1E0EuQYaSRhJQz7nS4Rxx84mWcNxO/lkeFdAL5jHjq Sliq5P4Q9/5KC8LI4E+aB0Y6nF4sNW59sjZFgRgzV3COOBxUMBYVBwihg3+EtwU5nhwW VZ7Jqavmmec12mF8YTen0gCSfOryojJ8kXKqUsBXKQc3DDJKkZWkDY1/nuaCo+v8khzY OJQJpmz9TEAZcJOnQCIWL1qz0Ng9atFcJrrceu5aZrWHIsPYQvvCZlXbWohlRVfIKnld ATpkp+acuUabe9fxWTISPN8cwkE7md5a7b1Tn5JtPGxiPqg4lxMwhm3AB6AYhDGsMIYr QQ+A== Received: by 10.217.1.79 with SMTP id m57mr4125429wes.121.1344196928161; Sun, 05 Aug 2012 13:02:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.1.79 with SMTP id m57mr4125419wes.121.1344196927986; Sun, 05 Aug 2012 13:02:07 -0700 (PDT) Received: by 10.216.213.193 with HTTP; Sun, 5 Aug 2012 13:02:07 -0700 (PDT) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D4E4381@SACEXCMBX02-PRD.hq.netapp.com> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120803012830.GC59530@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E39FE@SACEXCMBX02-PRD.hq.netapp.com> <20120803183421.GB15012@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E4381@SACEXCMBX02-PRD.hq.netapp.com> Date: Sun, 5 Aug 2012 13:02:07 -0700 Message-ID: From: Matt Mathis To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnt1BTFwvlnrOsdddqRKXLWl7ScIlrjdb/pwlu4J0RhruMimGz1pEZhCxI0sg1rRjbkSs/Qmfn4ISwnrrx1A6lrGT2XncX8nC3LBO+GBOWD8Mzchy9NCZCF/jfw6dlejmVsDDtA9GVLKHNQEWgWH7Ep0+czT+T3IUXCPTKPa3oGqfYqfjcegGTpjm23OajYqG33bQAI Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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: Sun, 05 Aug 2012 20:02:10 -0000 I agree that "accurate" is a little bit too strong of term. Perhaps "counted", "proportional", "quantified", "measured", etc. And yes, TCPM is probably the right place, since all CC standards track docs are explicitly in scope, even as applied to other protocols. If we separate signalling from action, some proposed actions clearly need to mature in ICCRG for a bit. Here is a tough question though: does the choice of alternate actions effect the design of the signalling? If so, it may be premature to commit on the signalling. (e.g. for low threshold ECN (aka DCTCP) isolated ECN marks would be extremely unlikely and it would probably be ok to miss a few.), Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Fri, Aug 3, 2012 at 1:58 PM, Scheffenegger, Richard wrot= e: > > Hi John, > > > Thanks for your comments so far! > >> > I would argue that the current ECE/CWR mechanism is perfectly reliable >> >> I might take the other side of that argument... > > Could you please explain? (I should have perhaps added, RFC3168 is perfec= tly reliable for at least, and up to, one CE mark per RTT; The sender gets = the information that at least one CE mark was received in the RTT under all= circumstances). > > >> Actually, there are two counters, packets and (payload) bytes. > > Correct; but as soon as not every data segment is ACKed (and the ACK not = lost), the delineation (for figuring out which payload bytes got marked) be= comes fuzzy... Even when the sender keeps state as to the segment boundarie= s, it's not clear which of multiple segments were marked (except in the two= extreme cases), when delayed ACKs (or even ACK compression) are in play... > > Which brings up another question that I haven't put in this forum: > > Will there be a conceivable benefit when the sender knows the exact order= or markings? > > The way the receiver ECN state-machine of DCTCP is described allows the s= ender to reconstruct the exact order of markings (the "CE stream"), provide= d no (relevant) ACKs are lost. With the complication that the sender rarely= knows, when and if a relevant ACK got dropped... > > This level of precision is lost, when the receiver uses some kind of summ= ary signal; But making such a signal reliable requires even more bits, and = some more or less complex encoding scheme... > > > But I am not sure if such an extreme precision will be necessary to TCP a= t least (and other transports do provide means to encode that...) > > > To have a proper counter (congested bytes), I think that would need to be= explicit; Mirja did some experiments using implicit ACKs, but to get them = work properly, you end up with sending out more ACKs than strictly necessar= y (like what DCTCP receivers do), and single ACK loss can still result in w= rong signals at the sender.... > > > > > Richard Scheffenegger > > > > >> -----Original Message----- >> From: John Leslie [mailto:john@jlc.net] >> Sent: Freitag, 03. August 2012 11:34 >> To: Scheffenegger, Richard >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for >> accurate feedback >> >> Scheffenegger, Richard wrote: >> > >> > Hi John, >> > >> > Am I right in assuming that with "greater precision" you imply that >> > this doesn't necessarily mean "exact" feedback? >> >> Yes, but... This is mainly to avoid arguing what "exact" might mean. >> >> > (Originally we discussed using "more accurate" in the title of the >> > draft; that meant lower precision than "exact", but the "more" got >> > lost along the way, leaving "accurate"). >> >> (I must admit I'm at least as anxious to avoid arguing what "accurate= " >> might mean.) >> >> > I would argue that the current ECE/CWR mechanism is perfectly reliable >> >> I might take the other side of that argument... >> >> > - up to a certain precision limited by the number of bits set aside >> > for the signal back from the receiver to the sender. What would be >> > more reliable? >> >> "Reliable" in TCP means that everything not acknowledged will be >> retransmitted. That would imply repeating each ECE until that specific E= CE >> is acknowledged -- and clarifying to the sender how that CWR was >> understood. >> >> But I'm not trying to argue either way whether "reliable" would be >> "better" than "unreliable". >> >> > (ECE is a counter that can only increase, and remains at the maximumi >> > value until being reset; CWR provides the reset signal). >> >> Umm... "remains at maximum" implies some loss of precision... >> >> > OTOH, if the feedback signal is encoded with enough bits, reliability >> > can be brought arbitrarily close to "perfect", even without an >> > explicit forward signal (CWR). >> >> Indeed, one could argue "reliability" by unacknowledged repetition. >> (I'd prefer some other term, but it certainly would serve for the >> "precision" I was seeking.) >> >> > As soon as the counter (and signal for it) cover all the packets >> > individually in a window, the ECN feedback can be exact; >> >> Actually, there are two counters, packets and (payload) bytes. >> >> > The question becomes, can the reset mechanism be abandoned when >> > "enough" bits are available for the signal, or must the principal >> > architecture (a counter increasing up to some point, until it is >> > reset) be maintained... >> >> I don't choose to express an opinion on that yet. >> >> > BTW: I found that ECN for SCTP also failed to discuss this, but there >> > a 32 bit counter is used (plus a Reset signal/CWR). >> >> :^) >> >> > To jump forward a bit, I suspect the delineation is somewhere around >> > 5 bits (2.3 bits in the codepoint draft; 3 bits in reECN; 8 bits in >> > the TCP Option draft). Using 5 bits or less, a handshare mechanism is >> > required; using more than 5, and a simple counter suffices to maintain >> > exactness (until TCP suffers from loss of the ACK clock etc). >> >> No comment (yet)... >> >> > The signaling is another question; Perhaps a certain loss of >> > granularity is acceptable for the currently discussed protocols (i.e. >> > Conex; slight overestimating congestion is not as bad as >> > underestimating). But other (future) uses (e.g. DCTCP) would probably >> > require the full precision - with other words, "exact" signaling... >> >> "Exact" _is_ a reasonable goal... >> >> > However, we (authors), while discussing this internally, would also be >> > glad of any opinion regarding this! >> >> I will note that current ECN processing in TCP is awfully specialized= : >> I can imagine congestion-control algorithms it would serve poorly. :^( B= ut >> leaving that aside, ECN processing for other transport protocols almost >> certainly deserves a different treatment. >> >> It would be nice if our "greater precision" effort could serve the >> needs of yet-unseen future transport protocols. >> >> -- >> John Leslie > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Sun Aug 5 13:17:37 2012 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 0C77521F852C for ; Sun, 5 Aug 2012 13:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.952 X-Spam-Level: X-Spam-Status: No, score=-102.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX11KXeg3DIb for ; Sun, 5 Aug 2012 13:17:36 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D72021F851B for ; Sun, 5 Aug 2012 13:17:35 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so5355161obb.31 for ; Sun, 05 Aug 2012 13:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=8+CHlSyGGu/1MxRxXiPVGmOp2IKzRt9zqMGgc8GW9dU=; b=LPvC1XYJ+LPPGiv26z5Vm9xQLACxNnUdsKbNI12/xEldflOqiYx8dC7Mg6noxY5cCa 8Q4I55vSyEBaiiCIbZLSqhE7NR6oBQm7jYXMsm6E2JwmY+4rXX0Z/IDou8+FAAlpyPjA 0sHToEqocS7IUX6SpSFPsfrKgAON/vVcjm4igos5ZjPjjZrUmzL3idvcykQPvkf1eOgo p+3DLm0MGJvNkEEsCKZ1ORGv27+gKp/AjA11ZWtYNklGZ7Bub3IDdX/vRf5MsHr4qEs5 90AjMvqu04gyk48Q0SdhSVnMG/dhbGYseFT+hy1FK93jLgAR0p4lPsYKFkeFHjQqRZpx gXhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=8+CHlSyGGu/1MxRxXiPVGmOp2IKzRt9zqMGgc8GW9dU=; b=VPkx2F56UsIORIQBBxaODvIn+xab2Sz4ABuLSDhEMNadNEcaa9GgAlSL7XJ4B/ctil FAB/+ZwwTxraM7QbJACHZzi+ZAG6eTpXQIjNbLBo1Blcu72a/aYq8Jv6iW3TVPyUzbC8 1h/oq09b+qqpLup2eRKFtwjbbZbQuppVWuQXuGXtHPTQy9VhJ80TkwmAIz3qLQVLsMzW O1l7j3EjmYyzkjWrVvYN6WV56GWgofK0UXXVKyjGelHzfXhsp1neaPiZqd435S4uTgYX YfOVVpW6YGDRqMMZ6qmWta24OPjzm+XiAKWukY33g5kvP+ua9WwgBeTG7v856AqfNe6+ eRZQ== Received: by 10.182.207.6 with SMTP id ls6mr15805822obc.36.1344197855664; Sun, 05 Aug 2012 13:17:35 -0700 (PDT) Received: by 10.182.207.6 with SMTP id ls6mr15805802obc.36.1344197855279; Sun, 05 Aug 2012 13:17:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.99.37 with HTTP; Sun, 5 Aug 2012 13:17:15 -0700 (PDT) In-Reply-To: References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120803012830.GC59530@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E39FE@SACEXCMBX02-PRD.hq.netapp.com> <20120803183421.GB15012@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E4381@SACEXCMBX02-PRD.hq.netapp.com> From: Yuchung Cheng Date: Sun, 5 Aug 2012 13:17:15 -0700 Message-ID: To: Matt Mathis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnRsvbigDpSKJLEsnIFIa/A7S5wa4rDLOwsPFAWzMrE69sdoy+y2jdJMQpgJRVnOypPNybBt6rwW2umjFz9DWo/NCGiGeiwFnCgVTOrucJHiNg+Xpubkmz/jkQZ4PI2ruq9CZgfcfee96gS3zp75NsM2s51QZfUDrFGx8+lDLekw4sSZvcKet/ACMgDNAnT8Yv3xvh3 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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: Sun, 05 Aug 2012 20:17:37 -0000 On Sun, Aug 5, 2012 at 1:02 PM, Matt Mathis wrote: > I agree that "accurate" is a little bit too strong of term. Perhaps > "counted", "proportional", "quantified", "measured", etc. > > And yes, TCPM is probably the right place, since all CC standards > track docs are explicitly in scope, even as applied to other > protocols. > > If we separate signalling from action, some proposed actions clearly > need to mature in ICCRG for a bit. Here is a tough question though: > does the choice of alternate actions effect the design of the > signalling? If so, it may be premature to commit on the signalling. > (e.g. for low threshold ECN (aka DCTCP) isolated ECN marks would be > extremely unlikely and it would probably be ok to miss a few.), That's exactly my question ... thanks for presenting it in a much better wording. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > > On Fri, Aug 3, 2012 at 1:58 PM, Scheffenegger, Richard wr= ote: >> >> Hi John, >> >> >> Thanks for your comments so far! >> >>> > I would argue that the current ECE/CWR mechanism is perfectly reliabl= e >>> >>> I might take the other side of that argument... >> >> Could you please explain? (I should have perhaps added, RFC3168 is perfe= ctly reliable for at least, and up to, one CE mark per RTT; The sender gets= the information that at least one CE mark was received in the RTT under al= l circumstances). >> >> >>> Actually, there are two counters, packets and (payload) bytes. >> >> Correct; but as soon as not every data segment is ACKed (and the ACK not= lost), the delineation (for figuring out which payload bytes got marked) b= ecomes fuzzy... Even when the sender keeps state as to the segment boundari= es, it's not clear which of multiple segments were marked (except in the tw= o extreme cases), when delayed ACKs (or even ACK compression) are in play..= . >> >> Which brings up another question that I haven't put in this forum: >> >> Will there be a conceivable benefit when the sender knows the exact orde= r or markings? >> >> The way the receiver ECN state-machine of DCTCP is described allows the = sender to reconstruct the exact order of markings (the "CE stream"), provid= ed no (relevant) ACKs are lost. With the complication that the sender rarel= y knows, when and if a relevant ACK got dropped... >> >> This level of precision is lost, when the receiver uses some kind of sum= mary signal; But making such a signal reliable requires even more bits, and= some more or less complex encoding scheme... >> >> >> But I am not sure if such an extreme precision will be necessary to TCP = at least (and other transports do provide means to encode that...) >> >> >> To have a proper counter (congested bytes), I think that would need to b= e explicit; Mirja did some experiments using implicit ACKs, but to get them= work properly, you end up with sending out more ACKs than strictly necessa= ry (like what DCTCP receivers do), and single ACK loss can still result in = wrong signals at the sender.... >> >> >> >> >> Richard Scheffenegger >> >> >> >> >>> -----Original Message----- >>> From: John Leslie [mailto:john@jlc.net] >>> Sent: Freitag, 03. August 2012 11:34 >>> To: Scheffenegger, Richard >>> Cc: tcpm@ietf.org >>> Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for >>> accurate feedback >>> >>> Scheffenegger, Richard wrote: >>> > >>> > Hi John, >>> > >>> > Am I right in assuming that with "greater precision" you imply that >>> > this doesn't necessarily mean "exact" feedback? >>> >>> Yes, but... This is mainly to avoid arguing what "exact" might mean. >>> >>> > (Originally we discussed using "more accurate" in the title of the >>> > draft; that meant lower precision than "exact", but the "more" got >>> > lost along the way, leaving "accurate"). >>> >>> (I must admit I'm at least as anxious to avoid arguing what "accurat= e" >>> might mean.) >>> >>> > I would argue that the current ECE/CWR mechanism is perfectly reliabl= e >>> >>> I might take the other side of that argument... >>> >>> > - up to a certain precision limited by the number of bits set aside >>> > for the signal back from the receiver to the sender. What would be >>> > more reliable? >>> >>> "Reliable" in TCP means that everything not acknowledged will be >>> retransmitted. That would imply repeating each ECE until that specific = ECE >>> is acknowledged -- and clarifying to the sender how that CWR was >>> understood. >>> >>> But I'm not trying to argue either way whether "reliable" would be >>> "better" than "unreliable". >>> >>> > (ECE is a counter that can only increase, and remains at the maximumi >>> > value until being reset; CWR provides the reset signal). >>> >>> Umm... "remains at maximum" implies some loss of precision... >>> >>> > OTOH, if the feedback signal is encoded with enough bits, reliability >>> > can be brought arbitrarily close to "perfect", even without an >>> > explicit forward signal (CWR). >>> >>> Indeed, one could argue "reliability" by unacknowledged repetition. >>> (I'd prefer some other term, but it certainly would serve for the >>> "precision" I was seeking.) >>> >>> > As soon as the counter (and signal for it) cover all the packets >>> > individually in a window, the ECN feedback can be exact; >>> >>> Actually, there are two counters, packets and (payload) bytes. >>> >>> > The question becomes, can the reset mechanism be abandoned when >>> > "enough" bits are available for the signal, or must the principal >>> > architecture (a counter increasing up to some point, until it is >>> > reset) be maintained... >>> >>> I don't choose to express an opinion on that yet. >>> >>> > BTW: I found that ECN for SCTP also failed to discuss this, but there >>> > a 32 bit counter is used (plus a Reset signal/CWR). >>> >>> :^) >>> >>> > To jump forward a bit, I suspect the delineation is somewhere around >>> > 5 bits (2.3 bits in the codepoint draft; 3 bits in reECN; 8 bits in >>> > the TCP Option draft). Using 5 bits or less, a handshare mechanism is >>> > required; using more than 5, and a simple counter suffices to maintai= n >>> > exactness (until TCP suffers from loss of the ACK clock etc). >>> >>> No comment (yet)... >>> >>> > The signaling is another question; Perhaps a certain loss of >>> > granularity is acceptable for the currently discussed protocols (i.e. >>> > Conex; slight overestimating congestion is not as bad as >>> > underestimating). But other (future) uses (e.g. DCTCP) would probably >>> > require the full precision - with other words, "exact" signaling... >>> >>> "Exact" _is_ a reasonable goal... >>> >>> > However, we (authors), while discussing this internally, would also b= e >>> > glad of any opinion regarding this! >>> >>> I will note that current ECN processing in TCP is awfully specialize= d: >>> I can imagine congestion-control algorithms it would serve poorly. :^( = But >>> leaving that aside, ECN processing for other transport protocols almost >>> certainly deserves a different treatment. >>> >>> It would be nice if our "greater precision" effort could serve the >>> needs of yet-unseen future transport protocols. >>> >>> -- >>> John Leslie >> _______________________________________________ >> 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 ycheng@google.com Sun Aug 5 15:32:35 2012 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 A23DC21F856D for ; Sun, 5 Aug 2012 15:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2G-4rGrXdbO for ; Sun, 5 Aug 2012 15:32:31 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 193B121F8562 for ; Sun, 5 Aug 2012 15:32:28 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so5516550obb.31 for ; Sun, 05 Aug 2012 15:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=r5DoVVexWcAuIYCOBzqAcmXNPkAJHs0wPAOTpKipJNY=; b=SzoGGSD4DkdzC3dNuH7x8UEw0D7twy4WY4fMOxOeAfNPMBpG+r00XRE4kGXQ4Attgc KD5C4OTa8XkKViKLKOhxQKogRqDRESQk1oyfVLQKBH6rssW97qkp8hF0HMdoTsMveRwT InH8sdunpUFuR1s0SoqpfgV+atXOl4LbZcwplpnMghkdoHkLG4B0wFSMO21VGFuuA/2y cajTtMLDkyaFalA7QB0IqyI76m+VP894yRF+j/DnZPqyjcbjUgRqRrKjHnZxeznsXyUU 0w/lJWnB5wPUvRynKwYz83CEr78a0qvagzPgbIeC6FE+ws5y/CeZuS/eV/25NwcTL+o+ oFUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=r5DoVVexWcAuIYCOBzqAcmXNPkAJHs0wPAOTpKipJNY=; b=o0dbb5YpWHFFfn9kkTiLSfhplvGKB0Uo9YVWNPm4UadERFskiXejdhU7KeOyMi0Yw5 XW9Gim0bf5JQ158oJL3OUxZLAmE0HYZp8byGOMC1ix7MYPYitwYKbAYvJmyIgBh8Xd+L Esb8dzg874CAO9uWpoaNGf1nQYnci2vP/J8oGL5HxnSdcQCZK2p49a86/iUyeQeWuewE gUS0/14kGJUuZsZqDhP8nnWN9gRqxbQCwxsJg8VEuIjf+yoRZUdoM8dwTXObxgxmcyIG nULU78XvCVYAGeiL7cFdr91vKgRQxW0QyeUDRkI72rNsJxuzYqQY/xJ3Zmv3Kk7tKRUc 1Cog== Received: by 10.182.207.6 with SMTP id ls6mr16182571obc.36.1344205948533; Sun, 05 Aug 2012 15:32:28 -0700 (PDT) Received: by 10.182.207.6 with SMTP id ls6mr16182559obc.36.1344205948235; Sun, 05 Aug 2012 15:32:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.99.37 with HTTP; Sun, 5 Aug 2012 15:32:08 -0700 (PDT) In-Reply-To: <69ACA3A4BA39B0499C1917FB0718BB254BE747BB86@EMV04-UKBR.domain1.systemhost.net> References: <69ACA3A4BA39B0499C1917FB0718BB254BE747BB86@EMV04-UKBR.domain1.systemhost.net> From: Yuchung Cheng Date: Sun, 5 Aug 2012 15:32:08 -0700 Message-ID: To: bob.briscoe@bt.com Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmaPqtBn/y3i8FVC6EnpOrbpGEzg1mmRkIsOYqtwEyXqF9yOfVIqZpAi8cUxhAotACghzr4lCZ846FFGs1c2JDNJ01li74WNp5EEhvJv5EdIx9nbqjXlP2YfkDbDXn1vkJoBLdAbyytFVDf4hlwW80kBuRmozXqZjzduJnGAukN/n5q0o9jWjsL2pdy2LsGNyjWV9Sc Cc: tcpm@ietf.org, draft-ietf-tcpm-fastopen@tools.ietf.org Subject: Re: [tcpm] Some ideas building on draft-ietf-tcpm-fastopen-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: Sun, 05 Aug 2012 22:32:35 -0000 Hi Bob, Re-inst. our discussions during the meeting. On Thu, Jul 26, 2012 at 10:19 PM, wrote: > Yuchung, Jerry, Sivasankar, Arvind, > > I liked this enough to want to work on improving it. I have a couple of > proposals that occurred to me, which I've finally made time to write up. > > (I'll send editorial nits from reviewing the draft later) > > ==Proposal #1/ == > Fast Open Cookie Request MUST (SHOULD?) be on a FIN > > I believe it would be better for the reasons below if: > * the client put a fast open cookie request in its FIN, not its SYN (whether > or not the server has sent a FIN first). > * Then the server can send the fastopen cookie on the FIN-ACK. > * If the client times out waiting for a FIN-ACK, it just re-sends as usual. > * If the server's FIN-ACK never arrives (perhaps because a middlebox has > eaten it), the client just doesn't have a cookie for the next session and > uses a 3WHS as normal. > > Note, only the Request would have to be on a FIN. The Fast Open Cookie > itself would obviously still be on the SYN of subsequent connections. Then, > when a subsequent connection finishes, it can refresh the cookie on its FIN, > ready for another connection later. > > This solves a couple of potential problems with a fastopen request-response > on the initial SYN exchange: > a) A FIN-cookie sidesteps the risk of unpredictable delay of the very first > SYN due to some middleboxes dropping new TCP options (any timeouts due to > non-delivery don't hold up the session, which has already finished) > b) Transports GETting typical Web pages could (ab)use the fastopen cookie on > the SYN exchange by opening multiple TCP connections during the initial > connection without each one suffering the delay of a 3WHS. This creates a > perverse incentive to use multiple parallel connections, because you can get > the same latency benefit as HTTP pipelining [Yoshifumi posed this problem > some time ago]. If clients can only request a fastopen cookie on a FIN, > they don't have this perverse incentive to not bother with pipelining. > > I have no evidence, but it seems intuitive that if the TCP option got > through on the first FIN, it might be more likely to get through on the next > SYN, altho I admit options on SYNs are looked at more closely by > middleboxes. Like Jerry's response, I also like your ideas of cookie in FIN to mitigate middlebox drops. But I don't think doing so will practically diminish parallel connections, because most other time it works better: this change only affects the (first) connection to get cookies. I personally don't mind adding a MAY for cookie exchange in FIN stage. > > > ==Proposal #2/ == > Fastopen cookies (optionally) authenticate both the client's network address > and the its knowledge of the TCP timestamp option on the segment carrying > the server's cookie. > > I would like to propose that if the server TCP-timestamps the segment > carrying its cookie, the client MUST use a timestamp option on the segment > that starts the subsequent fast open, and in its timestamp echo field it > must echo the timestamp sent with the earlier cookie. Then: > i) the server can use the timestamp as part of the material for generating > and validating the cookie and > ii) the server can set an expiry_duration, and check whether the echoed > timestamp is older than time(now) - expiry_duration. > > Reasoning: > The draft currently says: > " 3. The cookie expires after a certain amount of time. The reason is > detailed in the "Security Consideration" section. This can be > done by either periodically changing the server key used to > generate cookies or including a timestamp in the cookie. > " > > Let's take each in turn: > * Periodically changing the server key: Let's imagine the key changes every > 30 min. Then all cookies issued in the last 30 mins stop being useful, even > those just issued a second ago, or a minute ago, or 15 minutes ago... > * Including a timestamp in the cookie. This is only useful if the timestamp > is in the clear within the cookie, otherwise the server cannot use it to key > the cookie. But a timestamp in the clear takes valuable bits away from the > cookie, weakening its strength. This is unnecessary if there's already space > for a timestamp option on the segment (which is very common). > > Security Considerations mentions only two ways a client can collect valid > cookies from other hosts: > i) compromising other hosts, or > ii) (legally) taking over the lease of an IP address from a DHCP server. > But there is a much more problematic third way: > iii) sitting behind the same NAT as a neighbour (esp. a carrier-grade NAT > serving thousands of clients), where the NAT uses a common IP address for > many clients. > > As it stands, the cookie is only dependent on the client's network address. > Binding a TCP timestamp option into the cookie as well adds a lot more > entropy. > > With only the IP address for entropy, a client behind a NAT (or an attacker > in control of a compromised host behind a NAT) can get its own (valid) > cookie and use it in a brute-force spoof of numerous neighbouring clients - > to either SYN-flood the server or launch a reflection attack on its > neighbours by fast-opening loads of new TCP connections requesting large > data items on behalf of its neighbours, bypassing the safety check of the > 3WHS. > > In contrast, if a cookie depends on both the client's network address and > server's timestamp, a cookie requested by a client behind a NAT will only be > the same as a neighbours cookie served by the same server within the same > clock tick. > > This doesn't stop attackers getting valid cookies from compromised hosts, > but it does effectively prevent these more trivial attacks on neighbours. I also like TS idea but I see two problems in proposal #2: a) scale: servers need to remember the timestamps. NOTE: in our implementation, servers do not need to remember the cookie. b) a change in TS RFC: SYN ECR value is not 0. Are Mr. firewalls ok with that? > > > ==Proposal #3/ == > Special cookie values > > (A minor point compared to the two above) > > 4.1.2 Server Cookie handling > > " Also note the server may want to use special cookie values, e.g., > "0", for specific scenarios. For example, the server wants to notify > the client the support of TFO, but chooses not to return a valid > cookie for security or performance reasons upon receiving a TFO > request. > " > > I suggest the server just returns the cookie option with length 2 and no > cookie data, to show it supports the option, but chooses not to give a Acked. I prefer so actually. > cookie. Then the server doesn't have to run an extra 'if' test every time it > generates a cookie, just to check the cookie doesn't collide with a special > value. > > This would require the value of the cookie option request kind to be > different from the cookie option kind. Otherwise a response meaning "cookie > supported but empty" would be confused with a cookie request for the > half-connection in the opposite direction. > > > == Outstanding concern == > > Similar to a concern of Joe Touch's and Richard Scheffeneger's: dividing up > TCP implementations into ones with idempotent semantics and ones without. > This confuses the simple applicability of TCP. We need to work on that - but > manyana. Great point. We MUST be more specific about that point in the next revision. All and all thanks for reviewing our draft :) > > > > Bob > > > > [PS. Apologies if you already got this once - I've been 'experimenting' with > my email] > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From ycheng@google.com Sun Aug 5 17:12:50 2012 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 C7CEE21F859B for ; Sun, 5 Aug 2012 17:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfbGpwD6gO5H for ; Sun, 5 Aug 2012 17:12:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 16B8821F8587 for ; Sun, 5 Aug 2012 17:12:49 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so5639159obb.31 for ; Sun, 05 Aug 2012 17:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=E8yoHH7XsN34tQlkqH1LHb1DQD+yXfpixlOU6nVNLxY=; b=JADQFsgchT5LT49NgrJtca1j95fmr+RRHoUL1oD8MQZf1VlKOviDz+x+aso6wucxvx 2i7odCq4nM+rmoxOuMrqCnA8HqyJJ9CwSZ0QIekRngXReiMRGHzg81d7nj44U8PJP2Wy RZnFQM9hObmYXj2bMapYc6+jbN4yvz2KPlFOUBK6GYFxU+fQzgxA8FzEP1AQbcPhSI1a IZ2afNrkZgOmAmHXHSf2wGwTadPgDuncCaVhw9BDMM5J9aVbGmN9VoYvlwuZpqHXMZ9a lYVv1dkAOdWBdKEv7tATSMhC9wsoszWH3UYM38gwTPAA/bu9BylsnE9/3Q5MgQs8WcDt gRWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=E8yoHH7XsN34tQlkqH1LHb1DQD+yXfpixlOU6nVNLxY=; b=HOF5DMHpvE1GRtVAVX7HGskd1GRFHI9hU4VVucgV+/zZ8uWNuZUR5bxZjQ6jti3H28 /tMW0roDyC64qkcoYIlomZDpKQci+73gXody1ihgvC6Kf4VEQud6X95a860uB8SDOP19 YOx0LaGNLZ08Q2L1YWK1Sbm7N9wUsvXJOfnx3kLN2XjHpKBSHjmI9p2c0jlp9Ss3zlKQ wPxm5GS5iw89otf8T1YEZmdC4xOXRqBHeZG0raYzwKr4WU9FXpqb94iAIzEo7Ix9Zo8H F9HdUfca3Mt/iu92xDvnXwVdyEc/Ug0qoq78Us7kBFthFgtftt2U2GXvHMA3qaKxahgN NXBg== Received: by 10.182.51.37 with SMTP id h5mr16652722obo.35.1344211969436; Sun, 05 Aug 2012 17:12:49 -0700 (PDT) Received: by 10.182.51.37 with SMTP id h5mr16652711obo.35.1344211969149; Sun, 05 Aug 2012 17:12:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.99.37 with HTTP; Sun, 5 Aug 2012 17:12:28 -0700 (PDT) In-Reply-To: <4FC6A317.3010604@isi.edu> References: <20120530224029.12692.80401.idtracker@ietfa.amsl.com> <4FC6A317.3010604@isi.edu> From: Yuchung Cheng Date: Sun, 5 Aug 2012 17:12:28 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl31J5fBU9F2+ujZdYjEWsew3KhWUdVidgq7tYff0EaZGCSH6nyX5J9W4/YxXY8q2LF6vmojIoAfTyP/2ByJgeNPzIpUs+Zqf7KpT0sakaFyOpmLb//LE+rYiPqub9Cz5xziSDGLFkqtoHWVCIYIne/jpiIuSII9AV5iyLckLh8YpRVNF2DIKMAF0TWV6XvwEew9vYx Cc: Eric Dumazet , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-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: Mon, 06 Aug 2012 00:12:51 -0000 On Wed, May 30, 2012 at 3:45 PM, Joe Touch wrote: > Hi, all, > > This version incorporates feedback from the list. In specific: > > - minimum magic number length is not specified > > There are minor reorganization and revisions as well. > > Joe Two questions: 1) how to share the magic value with other developers (for other OSes)? Since I don't know, I am doing this on the list: We implemented this draft in the Fast Open for Linux. The magic is 0xF989 by this simple formula (suggested by Eric Dumazet): time_t now = time(NULL); printf("0x%04x\n", 0xFFFF & (now ^ (now >> 16))); Maybe a simple text file under ietf.org work? 2) While the draft does not address the transition plan, we developers have to. TFO plan is that once IANA grants the precious number, Linux will support both values for a while, until most clients use the new value. It's hassle but well ... but other TCP features may have different plans. Should this kind of transition plan be part of any new TCP draft that needs new option? Thanks. > > > On 5/30/2012 3:40 PM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the TCP Maintenance and Minor >> Extensions Working Group of the IETF. >> >> Title : Shared Use of Experimental TCP Options >> Author(s) : Joe Touch >> Filename : draft-ietf-tcpm-experimental-options-01.txt >> Pages : 8 >> Date : 2012-05-30 >> >> This document describes how TCP option codepoints can support >> concurrent experiments using a magic number field. This mechanism >> avoids the need for a coordinated registry, and is backward- >> compatible with currently known uses. >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-experimental-options-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-experimental-options-01.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ >> >> _______________________________________________ >> 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 touch@isi.edu Mon Aug 6 08:41:05 2012 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 916A921F858E for ; Mon, 6 Aug 2012 08:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.118 X-Spam-Level: X-Spam-Status: No, score=-103.118 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4v2PQsj3Zhm for ; Mon, 6 Aug 2012 08:41:05 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id E806121F8517 for ; Mon, 6 Aug 2012 08:41:04 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q76FeUBd006643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 6 Aug 2012 08:40:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: Date: Mon, 6 Aug 2012 08:40:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120530224029.12692.80401.idtracker@ietfa.amsl.com> <4FC6A317.3010604@isi.edu> To: Yuchung Cheng X-Mailer: Apple Mail (2.1278) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Eric Dumazet , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-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: Mon, 06 Aug 2012 15:41:05 -0000 On Aug 5, 2012, at 5:12 PM, Yuchung Cheng wrote: > On Wed, May 30, 2012 at 3:45 PM, Joe Touch wrote: >> Hi, all, >>=20 >> This version incorporates feedback from the list. In specific: >>=20 >> - minimum magic number length is not specified >>=20 >> There are minor reorganization and revisions as well. >>=20 >> Joe > Two questions: >=20 > 1) how to share the magic value with other developers (for other = OSes)? >=20 > Since I don't know, I am doing this on the list: > We implemented this draft in the Fast Open for Linux. The magic is = 0xF989 > by this simple formula (suggested by Eric Dumazet): > time_t now =3D time(NULL); > printf("0x%04x\n", 0xFFFF & (now ^ (now >> 16))); >=20 > Maybe a simple text file under ietf.org work? The magic numbers should be noted in the document that defines the = option. We can ask IANA to manage the list of such known numbers, but = two key issues need to be ensured: 1) the numbers in such a list are voluntarily reported, and IANA doesn't = enforce ownership i.e., it's just a list of known uses, not a registry 2) numbers in the list need to comply with the recommendations of this = doc, i.e., at least 32-bits long > 2) While the draft does not address the transition plan, we developers = have > to. TFO plan is that once IANA grants the precious number, Linux = will > support both values for a while, until most clients use the new = value. Correct. We'll make that more clear in an update of this doc. Support for the magic-number variant can be dropped either when it's = desired (to reduce code) or to deliberately transition to production = code (vs. experimental, which may differ). > It's hassle but well ... but other TCP features may have different = plans. >=20 > Should this kind of transition plan be part of any new TCP draft = that > needs new option? Yes. I'll add that recommendation to this doc as well. Note that the assigned option SHOULD NOT include the magic number, = though - to conserve SYN space. Joe >=20 > Thanks. >=20 >>=20 >>=20 >> On 5/30/2012 3:40 PM, internet-drafts@ietf.org wrote: >>>=20 >>>=20 >>> 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. >>>=20 >>> Title : Shared Use of Experimental TCP Options >>> Author(s) : Joe Touch >>> Filename : draft-ietf-tcpm-experimental-options-01.txt >>> Pages : 8 >>> Date : 2012-05-30 >>>=20 >>> This document describes how TCP option codepoints can support >>> concurrent experiments using a magic number field. This mechanism >>> avoids the need for a coordinated registry, and is backward- >>> compatible with currently known uses. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>>=20 >>> = http://www.ietf.org/internet-drafts/draft-ietf-tcpm-experimental-options-0= 1.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>>=20 >>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-experimental-options-01= .txt >>>=20 >>> The IETF datatracker page for this Internet-Draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Tue Aug 7 09:40:38 2012 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 8865121F8610 for ; Tue, 7 Aug 2012 09:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.267 X-Spam-Level: X-Spam-Status: No, score=-10.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r4zyt9oZv7Z for ; Tue, 7 Aug 2012 09:40:37 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5C82921F8602 for ; Tue, 7 Aug 2012 09:40:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,728,1336374000"; d="scan'208";a="674220975" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 07 Aug 2012 09:40:21 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q77GeLxb019129; Tue, 7 Aug 2012 09:40:21 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.34]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0309.002; Tue, 7 Aug 2012 09:40:20 -0700 From: "Scheffenegger, Richard" To: Matt Mathis Thread-Topic: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback Thread-Index: AQHNcaad6WGNeCXLeE+xrdvJ28VJWZdIjAjAgAOQZICAAnLiQA== Date: Tue, 7 Aug 2012 16:40:20 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D4E8E64@SACEXCMBX02-PRD.hq.netapp.com> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120803012830.GC59530@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E39FE@SACEXCMBX02-PRD.hq.netapp.com> <20120803183421.GB15012@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E4381@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 07 Aug 2012 16:40:38 -0000 Hi Matt, > does the choice of alternate actions effect the design of the signalling? > If so, it may be premature to commit on the signalling. > (e.g. for low threshold ECN (aka DCTCP) isolated ECN marks would be > extremely unlikely and it would probably be ok to miss a few.), I believe that any signaling would still have to cater for legacy style, lo= w-density ECN marking (RED) for some time.=20 Further I suspect that the way how the sender handles segments (segment-ori= ented or bytestream-oriented TCP) can also have an indirect implication as = to the quality of a feedback signal, if only a few bits can be used for it. I asked this question a couple days ago, if the exact ordering in which CE = marks are received on the receiver need to be conveyed back to the sender. = That would allow the sender to infer exactly which packet was marked. One a= rgument in favor of this which was brought forward was that this could allo= w the sender to know how many "congestion bytes" were marked. However, that= particular aspect can also be addressed with a byte-counting feedback sign= al, and the full CE "bit stream" is not required then. The last question I still wonder is, would there be any benefit to the netw= ork to know when the sender did react to a control signal... When using Conex, CWR really is redundant (but it does mark the exact segme= nt when TCP CC reacted; conex signals don't necessarily have that, but the = draft is still in flux there). Today, CWR is also (primarily) used as a "reset" signal to the receiver, as= much as a signal that the sender TCP CC reacted. If we could find enough bits (as mentioned my experiments point to slightly= over 5 bits as being sufficient), a very simple, straight forward signalin= g scheme should cater even unknown future needs (except for the exact CE bi= tstream case mentioned above). Best regards, Richard Scheffenegger > -----Original Message----- > From: Matt Mathis [mailto:mattmathis@google.com] > Sent: Sonntag, 05. August 2012 13:02 > To: Scheffenegger, Richard > Cc: John Leslie; tcpm@ietf.org > Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for > accurate feedback >=20 > I agree that "accurate" is a little bit too strong of term. Perhaps > "counted", "proportional", "quantified", "measured", etc. >=20 > And yes, TCPM is probably the right place, since all CC standards track > docs are explicitly in scope, even as applied to other protocols. >=20 > If we separate signalling from action, some proposed actions clearly > need to mature in ICCRG for a bit. Here is a tough question though: > does the choice of alternate actions effect the design of the signalling? > If so, it may be premature to commit on the signalling. > (e.g. for low threshold ECN (aka DCTCP) isolated ECN marks would be > extremely unlikely and it would probably be ok to miss a few.), >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 >=20 > On Fri, Aug 3, 2012 at 1:58 PM, Scheffenegger, Richard > wrote: > > > > Hi John, > > > > > > Thanks for your comments so far! > > > >> > I would argue that the current ECE/CWR mechanism is perfectly > >> > reliable > >> > >> I might take the other side of that argument... > > > > Could you please explain? (I should have perhaps added, RFC3168 is > perfectly reliable for at least, and up to, one CE mark per RTT; The > sender gets the information that at least one CE mark was received in the > RTT under all circumstances). > > > > > >> Actually, there are two counters, packets and (payload) bytes. > > > > Correct; but as soon as not every data segment is ACKed (and the ACK no= t > lost), the delineation (for figuring out which payload bytes got marked) > becomes fuzzy... Even when the sender keeps state as to the segment > boundaries, it's not clear which of multiple segments were marked (except > in the two extreme cases), when delayed ACKs (or even ACK compression) ar= e > in play... > > > > Which brings up another question that I haven't put in this forum: > > > > Will there be a conceivable benefit when the sender knows the exact > order or markings? > > > > The way the receiver ECN state-machine of DCTCP is described allows the > sender to reconstruct the exact order of markings (the "CE stream"), > provided no (relevant) ACKs are lost. With the complication that the > sender rarely knows, when and if a relevant ACK got dropped... > > > > This level of precision is lost, when the receiver uses some kind of > summary signal; But making such a signal reliable requires even more bits= , > and some more or less complex encoding scheme... > > > > > > But I am not sure if such an extreme precision will be necessary to > > TCP at least (and other transports do provide means to encode that...) > > > > > > To have a proper counter (congested bytes), I think that would need to > be explicit; Mirja did some experiments using implicit ACKs, but to get > them work properly, you end up with sending out more ACKs than strictly > necessary (like what DCTCP receivers do), and single ACK loss can still > result in wrong signals at the sender.... > > > > > > > > > > Richard Scheffenegger > > > > > > > > > >> -----Original Message----- > >> From: John Leslie [mailto:john@jlc.net] > >> Sent: Freitag, 03. August 2012 11:34 > >> To: Scheffenegger, Richard > >> Cc: tcpm@ietf.org > >> Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone > >> for accurate feedback > >> > >> Scheffenegger, Richard wrote: > >> > > >> > Hi John, > >> > > >> > Am I right in assuming that with "greater precision" you imply that > >> > this doesn't necessarily mean "exact" feedback? > >> > >> Yes, but... This is mainly to avoid arguing what "exact" might mean= . > >> > >> > (Originally we discussed using "more accurate" in the title of the > >> > draft; that meant lower precision than "exact", but the "more" got > >> > lost along the way, leaving "accurate"). > >> > >> (I must admit I'm at least as anxious to avoid arguing what > "accurate" > >> might mean.) > >> > >> > I would argue that the current ECE/CWR mechanism is perfectly > >> > reliable > >> > >> I might take the other side of that argument... > >> > >> > - up to a certain precision limited by the number of bits set aside > >> > for the signal back from the receiver to the sender. What would be > >> > more reliable? > >> > >> "Reliable" in TCP means that everything not acknowledged will be > >> retransmitted. That would imply repeating each ECE until that > >> specific ECE is acknowledged -- and clarifying to the sender how that > >> CWR was understood. > >> > >> But I'm not trying to argue either way whether "reliable" would be > >> "better" than "unreliable". > >> > >> > (ECE is a counter that can only increase, and remains at the > >> > maximumi value until being reset; CWR provides the reset signal). > >> > >> Umm... "remains at maximum" implies some loss of precision... > >> > >> > OTOH, if the feedback signal is encoded with enough bits, > >> > reliability can be brought arbitrarily close to "perfect", even > >> > without an explicit forward signal (CWR). > >> > >> Indeed, one could argue "reliability" by unacknowledged repetition. > >> (I'd prefer some other term, but it certainly would serve for the > >> "precision" I was seeking.) > >> > >> > As soon as the counter (and signal for it) cover all the packets > >> > individually in a window, the ECN feedback can be exact; > >> > >> Actually, there are two counters, packets and (payload) bytes. > >> > >> > The question becomes, can the reset mechanism be abandoned when > >> > "enough" bits are available for the signal, or must the principal > >> > architecture (a counter increasing up to some point, until it is > >> > reset) be maintained... > >> > >> I don't choose to express an opinion on that yet. > >> > >> > BTW: I found that ECN for SCTP also failed to discuss this, but > >> > there a 32 bit counter is used (plus a Reset signal/CWR). > >> > >> :^) > >> > >> > To jump forward a bit, I suspect the delineation is somewhere > >> > around > >> > 5 bits (2.3 bits in the codepoint draft; 3 bits in reECN; 8 bits in > >> > the TCP Option draft). Using 5 bits or less, a handshare mechanism > >> > is required; using more than 5, and a simple counter suffices to > >> > maintain exactness (until TCP suffers from loss of the ACK clock > etc). > >> > >> No comment (yet)... > >> > >> > The signaling is another question; Perhaps a certain loss of > >> > granularity is acceptable for the currently discussed protocols (i.e= . > >> > Conex; slight overestimating congestion is not as bad as > >> > underestimating). But other (future) uses (e.g. DCTCP) would > >> > probably require the full precision - with other words, "exact" > signaling... > >> > >> "Exact" _is_ a reasonable goal... > >> > >> > However, we (authors), while discussing this internally, would also > >> > be glad of any opinion regarding this! > >> > >> I will note that current ECN processing in TCP is awfully > specialized: > >> I can imagine congestion-control algorithms it would serve poorly. > >> :^( But leaving that aside, ECN processing for other transport > >> protocols almost certainly deserves a different treatment. > >> > >> It would be nice if our "greater precision" effort could serve the > >> needs of yet-unseen future transport protocols. > >> > >> -- > >> John Leslie > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From pasi.sarolahti@iki.fi Wed Aug 8 02:32:53 2012 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 BA3C821F867A for ; Wed, 8 Aug 2012 02:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.412 X-Spam-Level: X-Spam-Status: No, score=-100.412 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_05=-1.11, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFDj4MXQoxEf for ; Wed, 8 Aug 2012 02:32:53 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA5721F866D for ; Wed, 8 Aug 2012 02:32:53 -0700 (PDT) Received: from pc108.netlab.hut.fi (130.233.154.108) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 4FD1DCFC005CA3F1 for tcpm@ietf.org; Wed, 8 Aug 2012 12:32:51 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Aug 2012 12:32:50 +0300 Message-Id: <4FB4EC54-0274-451D-99D2-ED999D2DC863@iki.fi> To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [tcpm] WGLC for Proportional Rate Reduction 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, 08 Aug 2012 09:32:53 -0000 Hi, As discussed in the meeting last week, we will now start working group = last call for "Proportional Rate Reduction for TCP" = (draft-ietf-tcpm-proportional-rate-reduction-02), to be published as = Experimental RFC. The WGLC runs until Friday, August 24th. Please read = the draft and send comments by then. If you have read the draft and = think it is ok, notifying just that is also helpful (even without = comments). The draft is available at = http://tools.ietf.org/html/draft-ietf-tcpm-proportional-rate-reduction-02=20= - Pasi From muraris@microsoft.com Thu Aug 9 15:05:56 2012 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 D3BD521F8644 for ; Thu, 9 Aug 2012 15:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.459 X-Spam-Level: X-Spam-Status: No, score=-100.459 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBKW2tYDPw68 for ; Thu, 9 Aug 2012 15:05:56 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 13A3E21F8628 for ; Thu, 9 Aug 2012 15:05:56 -0700 (PDT) Received: from mail118-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 9 Aug 2012 22:05:54 +0000 Received: from mail118-co1 (localhost [127.0.0.1]) by mail118-co1-R.bigfish.com (Postfix) with ESMTP id F1278AA0370 for ; Thu, 9 Aug 2012 22:05:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -11 X-BigFish: VS-11(zf7Iz9371I542M4015Izz1202hzz5eeeKz2fh2a8h683h839h944hd25hf0ah107ah) Received-SPF: pass (mail118-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=muraris@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.37; KIP:(null); UIP:(null); (null); H:CH1PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail118-co1 (localhost.localdomain [127.0.0.1]) by mail118-co1 (MessageSwitch) id 1344549952318873_31070; Thu, 9 Aug 2012 22:05:52 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.234]) by mail118-co1.bigfish.com (Postfix) with ESMTP id 4C4A4A8003F for ; Thu, 9 Aug 2012 22:05:52 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 9 Aug 2012 22:05:51 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.309.3; Thu, 9 Aug 2012 22:05:50 +0000 Received: from mail12-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 9 Aug 2012 22:05:08 +0000 Received: from mail12-tx2 (localhost [127.0.0.1]) by mail12-tx2-R.bigfish.com (Postfix) with ESMTP id 890BE1A0176 for ; Thu, 9 Aug 2012 22:05:08 +0000 (UTC) Received: from mail12-tx2 (localhost.localdomain [127.0.0.1]) by mail12-tx2 (MessageSwitch) id 1344549906244328_24743; Thu, 9 Aug 2012 22:05:06 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.245]) by mail12-tx2.bigfish.com (Postfix) with ESMTP id 2F1A9140128; Thu, 9 Aug 2012 22:05:06 +0000 (UTC) Received: from CH1PRD0310HT003.namprd03.prod.outlook.com (157.56.244.37) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 9 Aug 2012 22:05:05 +0000 Received: from CH1PRD0310MB369.namprd03.prod.outlook.com ([169.254.9.25]) by CH1PRD0310HT003.namprd03.prod.outlook.com ([10.255.137.38]) with mapi id 14.16.0175.005; Thu, 9 Aug 2012 22:05:03 +0000 From: Murari Sridharan To: Matt Mathis , rtp-congestion , "tcpm (tcpm@ietf.org)" Thread-Topic: [R-C] Fwd: video and TCP interaction Thread-Index: AQHNdk/12WAR1LYzgEO/Mu8pEGRV/pdSCClQ Date: Thu, 9 Aug 2012 22:05:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ALVESTRAND.NO$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [tcpm] [R-C] Fwd: video and TCP interaction 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, 09 Aug 2012 22:05:57 -0000 It is interesting that this paper references RFC 5681 when it finds that th= e OS after a period of inactivity goes back to initial (restart) cwnd of 10= packets :-) Thanks, Murari -----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@a= lvestrand.no] On Behalf Of Matt Mathis Sent: Thursday, August 9, 2012 9:56 AM To: rtp-congestion Cc: Nandita Dukkipati Subject: [R-C] Fwd: video and TCP interaction This seem particularly relevant here. Confused, Timid, and Unstable: Picking a Video Streaming Rate is Hard http://www.stanford.edu/~huangty/videoRateAdapt.pdf >From IMC 2012 Thanks, --MM-- _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion From abegen@cisco.com Thu Aug 9 15:32:35 2012 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 314C821F860B for ; Thu, 9 Aug 2012 15:32:35 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS8gfg18lNjs for ; Thu, 9 Aug 2012 15:32:34 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4961C21F8609 for ; Thu, 9 Aug 2012 15:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1595; q=dns/txt; s=iport; t=1344551554; x=1345761154; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=aaCfKvZoOoQK+8WZTkiaqVYpjCTvEOeDC2Am8Z+gQ84=; b=dHOG151vDxHnhnlBXpV4/e28dXQmhNMlwfbVjEDJg1OebzR3uLhIh5m3 aHZAqv8Uzixhj6so/HVlCp2ZVLdR9GspjPf5sn2ADWOmQ1RKrXgieYbme 36juTwU+pQwW+BFREBm/rIIrWPy0lnhec0AbpKnZs8gH9J5poK8Q8foMJ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIzgI1CtJV2Y/2dsb2JhbABFFoJXtnWBB4IgAQEBAgIBAQEPAVsXBAIBCBEEAQELHQcnCxQJCAIEARIIGodrAQqae6Btiw8ShXJgA6NygWaCXw X-IronPort-AV: E=Sophos;i="4.77,742,1336348800"; d="scan'208";a="110125746" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 09 Aug 2012 22:32:33 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q79MWWXH027893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Aug 2012 22:32:32 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Thu, 9 Aug 2012 17:32:32 -0500 From: "Ali C. Begen (abegen)" To: Murari Sridharan , Matt Mathis , rtp-congestion , "tcpm (tcpm@ietf.org)" Thread-Topic: [R-C] Fwd: video and TCP interaction Thread-Index: AQHNdk/Z8CsR+J4qQE6+bjZ36xub/pdSXT4A//+zTMA= Date: Thu, 9 Aug 2012 22:32:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.248.106] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19098.001 x-tm-as-result: No--37.718200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] [R-C] Fwd: video and TCP interaction 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, 09 Aug 2012 22:32:35 -0000 SSR is a killer in http streaming apps and there are certain ways to avoid = that long inactivity that will trigger SSR. There are quite a number of ser= vers out there running a particular OS that do not implement SSR at all. > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of M= urari Sridharan > Sent: Thursday, August 09, 2012 6:05 PM > To: Matt Mathis; rtp-congestion; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] [R-C] Fwd: video and TCP interaction >=20 > It is interesting that this paper references RFC 5681 when it finds that = the OS after a period of inactivity goes back to initial > (restart) cwnd of 10 packets :-) >=20 > Thanks, > Murari >=20 > -----Original Message----- > From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces= @alvestrand.no] On Behalf Of Matt Mathis > Sent: Thursday, August 9, 2012 9:56 AM > To: rtp-congestion > Cc: Nandita Dukkipati > Subject: [R-C] Fwd: video and TCP interaction >=20 > This seem particularly relevant here. >=20 > Confused, Timid, and Unstable: > Picking a Video Streaming Rate is Hard >=20 > http://www.stanford.edu/~huangty/videoRateAdapt.pdf >=20 > From IMC 2012 >=20 > Thanks, > --MM-- > _______________________________________________ > Rtp-congestion mailing list > Rtp-congestion@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtp-congestion >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rick.jones2@hp.com Thu Aug 9 15:37:00 2012 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 3A98B21F8690 for ; Thu, 9 Aug 2012 15:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHsfpTceXjT8 for ; Thu, 9 Aug 2012 15:36:59 -0700 (PDT) Received: from g6t0187.atlanta.hp.com (g6t0187.atlanta.hp.com [15.193.32.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6C67621F866E for ; Thu, 9 Aug 2012 15:36:59 -0700 (PDT) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g6t0187.atlanta.hp.com (Postfix) with ESMTPS id A514328031; Thu, 9 Aug 2012 22:36:58 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id ED27F10003; Thu, 9 Aug 2012 22:36:55 +0000 (UTC) Message-ID: <50243B86.1050901@hp.com> Date: Thu, 09 Aug 2012 15:36:54 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Murari Sridharan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm \(tcpm@ietf.org\)" , Matt Mathis , rtp-congestion Subject: Re: [tcpm] [R-C] Fwd: video and TCP interaction 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, 09 Aug 2012 22:37:00 -0000 On 08/09/2012 03:05 PM, Murari Sridharan wrote: > It is interesting that this paper references RFC 5681 when it finds > that the OS after a period of inactivity goes back to initial > (restart) cwnd of 10 packets :-) I personally am not much of a fan of slow-start after idle (or persist I suppose) but this: >> The competing wget flow has already filled the buffer during the >> OFF period, and so the video flow sees very high packet loss. caught my eye and immediately made me think of the likes of codel and wonder how that might have changed behaviour of the overall system. It also made me wonder if the three services might have tested their heuristics in an environment with lots and lots of buffering at the bottleneck... rick jones > Thanks, > Murari > > -----Original Message----- > From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of Matt Mathis > Sent: Thursday, August 9, 2012 9:56 AM > To: rtp-congestion > Cc: Nandita Dukkipati > Subject: [R-C] Fwd: video and TCP interaction > > This seem particularly relevant here. > > Confused, Timid, and Unstable: > Picking a Video Streaming Rate is Hard > > http://www.stanford.edu/~huangty/videoRateAdapt.pdf > >>From IMC 2012 > > Thanks, > --MM-- > _______________________________________________ > Rtp-congestion mailing list > Rtp-congestion@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtp-congestion > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From mzanaty@cisco.com Thu Aug 9 19:17:31 2012 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 D2E2D21F861E for ; Thu, 9 Aug 2012 19:17:30 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayvFa6Nq+Ohi for ; Thu, 9 Aug 2012 19:17:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 46C8721F861A for ; Thu, 9 Aug 2012 19:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mzanaty@cisco.com; l=1569; q=dns/txt; s=iport; t=1344565049; x=1345774649; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OjBxm+4+4uWnm6kp2841BY+AHqbbpfw8h6nm5hVogmA=; b=C0Wmm21/RZu6nvtQE40I8LjiQqrctaSDpuLFktfe2bhyIKvZxGvpV/6M U3qK/7TRVyj7AhCufXv0tdfY+fJf656v+tDpz24PZFY5x6YkpoNLt0lxd GJXhw+Nx+Bp/NAhQfDQTePTtV1lvyZv4EBwP6uubKej6v7Mrl/t5Dxeko o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIzgI1CtJV2Z/2dsb2JhbABFFrlMgQeCIAEBAQICAQEBDwEnNAsMBAIBCBEEAQELFAkHJwsUCQgCBAENBQgah2sLmnugbYsPEoVyYAOjcoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,743,1336348800"; d="scan'208";a="109968047" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 10 Aug 2012 02:17:28 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7A2HSS5001015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Aug 2012 02:17:28 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Thu, 9 Aug 2012 21:17:28 -0500 From: "Mo Zanaty (mzanaty)" To: Murari Sridharan , Matt Mathis , rtp-congestion , "tcpm (tcpm@ietf.org)" Thread-Topic: [R-C] Fwd: video and TCP interaction Thread-Index: AQHNdk/12WAR1LYzgEO/Mu8pEGRV/pdSCClQgAA6TPA= Date: Fri, 10 Aug 2012 02:17:27 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D90F56B481@xmb-rcd-x14.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.238.217] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19098.001 x-tm-as-result: No--27.220300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 10 Aug 2012 08:50:06 -0700 Subject: Re: [tcpm] [R-C] Fwd: video and TCP interaction 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, 10 Aug 2012 02:17:31 -0000 More interesting than IW10 on CDNs, "Service C" (which must be Vudu) stream= s at 9M! The RMCAT evaluation criteria should include testing with competin= g DASH flows (Vudu for fireworks bigger than those in Vancouver). Mo -----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@a= lvestrand.no] On Behalf Of Murari Sridharan Sent: Thursday, August 09, 2012 6:05 PM To: Matt Mathis; rtp-congestion; tcpm (tcpm@ietf.org) Cc: Nandita Dukkipati Subject: Re: [R-C] Fwd: video and TCP interaction It is interesting that this paper references RFC 5681 when it finds that th= e OS after a period of inactivity goes back to initial (restart) cwnd of 10= packets :-) Thanks, Murari -----Original Message----- From: rtp-congestion-bounces@alvestrand.no [mailto:rtp-congestion-bounces@a= lvestrand.no] On Behalf Of Matt Mathis Sent: Thursday, August 9, 2012 9:56 AM To: rtp-congestion Cc: Nandita Dukkipati Subject: [R-C] Fwd: video and TCP interaction This seem particularly relevant here. Confused, Timid, and Unstable: Picking a Video Streaming Rate is Hard http://www.stanford.edu/~huangty/videoRateAdapt.pdf >From IMC 2012 Thanks, --MM-- _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion From nishida@sfc.wide.ad.jp Fri Aug 10 11:40:25 2012 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 C31F421F8731 for ; Fri, 10 Aug 2012 11:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BtHC1tMglge for ; Fri, 10 Aug 2012 11:40:25 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6DD21F86D1 for ; Fri, 10 Aug 2012 11:40:24 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B18872780AF for ; Sat, 11 Aug 2012 03:40:22 +0900 (JST) Received: by wgbdr13 with SMTP id dr13so1080450wgb.13 for ; Fri, 10 Aug 2012 11:40:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.105.130 with SMTP id gm2mr7980823wib.6.1344624020242; Fri, 10 Aug 2012 11:40:20 -0700 (PDT) Received: by 10.194.45.71 with HTTP; Fri, 10 Aug 2012 11:40:20 -0700 (PDT) Date: Fri, 10 Aug 2012 11:40:20 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org\"" , draft-ietf-tcpm-initcwnd@tools.ietf.org Content-Type: multipart/alternative; boundary=f46d0442810415411f04c6edad89 Subject: [tcpm] next steps for draft-ietf-tcpm-initcwnd 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, 10 Aug 2012 18:40:25 -0000 --f46d0442810415411f04c6edad89 Content-Type: text/plain; charset=ISO-8859-1 Hello folks, Since the WGLC duration for this draft has been expired and there seems to be no continuous discussions, we are thinking how to proceed this. Our primary decision is we would like to suggest authors to update the draft based on the discussions during the WGLC. There has been discussion on restructuring the draft. While this appears to be a valid suggestion, we conclude it's not strong enough to impose extra efforts on the authors at this time. (However, if authors want to do, I won't stop it. I will respect author's efforts. :) ) So, authors, please revise the draft based on the comments you received. If there's no strong objection on the revised version, we'll send it to IESG. We really appreciate everyone who has been taking your time for reviewing and discussing the draft. Thanks, -- Yoshifumi one of tcpm co-chairs --f46d0442810415411f04c6edad89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello folks,

Since the WGLC duration for this draft has been expired= and there seems to be no continuous discussions, we are thinking how to pr= oceed this.

Our primary decision is we would like to suggest author= s to update the draft based on the discussions during the WGLC.
There has been discussion on restructuring the draft. While this appears to= be a valid suggestion, we conclude it's not strong enough to impose ex= tra efforts on the authors at this time.
(However, if authors want to d= o, I won't stop it. I will respect author's efforts. :) )

So, authors, please revise the draft based on the comments you received= .
If there's no strong objection on the revised version, we'll s= end it to IESG.

We really appreciate everyone who has been taking yo= ur time for reviewing and discussing the draft.

Thanks,
--
Yoshifumi
one of tcpm co-chairs
--f46d0442810415411f04c6edad89-- From tsabatini@hotmail.com Sat Aug 11 14:24:00 2012 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 3D3E211E80A3 for ; Sat, 11 Aug 2012 14:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQc4OE-kLYaR for ; Sat, 11 Aug 2012 14:23:59 -0700 (PDT) Received: from bay0-omc1-s27.bay0.hotmail.com (bay0-omc1-s27.bay0.hotmail.com [65.54.190.38]) by ietfa.amsl.com (Postfix) with ESMTP id 443CB11E8087 for ; Sat, 11 Aug 2012 14:23:59 -0700 (PDT) Received: from BAY002-W87 ([65.54.190.59]) by bay0-omc1-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 Aug 2012 14:23:59 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f6656ed4-194c-4f9a-8c31-7884b8732dc7_" X-Originating-IP: [74.64.96.39] From: Anthony Sabatini To: "mallman@icir.org" Date: Sat, 11 Aug 2012 17:23:58 -0400 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 11 Aug 2012 21:23:59.0302 (UTC) FILETIME=[9F1A5660:01CD7807] Cc: tcpm , Matt Mathis , Joe Touch Subject: Re: [tcpm] Reordering Time and RFC3517bis 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, 11 Aug 2012 21:24:00 -0000 --_f6656ed4-194c-4f9a-8c31-7884b8732dc7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All - After reviewing things a bit more I realize no one has given serious though= t to Fragmentation Reassembly Timer=2C Reordering Time and the pseudo equiv= alent of three acks that is used to substitute for a more rigorous Reorderi= ng Time. First let us examine fragmentation reassembly timer. Since=2C as was point= ed out=2C all fragments are generated at the same time if we do not conside= r reordering of the fragments then the timer need be no greater than the tr= ansmission delay inherent in the fragment length as it relates to link spee= d plus an amount for processing delay=2C relatively speaking a very small a= mount of time. Even if we include a reroute through a satellite link that = adds only 500 ms to the timer=2C there is NO scenario under which reorderin= g will take over two seconds so with an abundance of caution you could set = fragment reassembly time to four seconds and be done with it. Yet EVERY IP= stack sets this value to above fifteen seconds (Linux is 15)=2C some at th= irty seconds (Microsoft is 30) and the rest at SIXTY SECONDS!! (Solaris=2C = BSD). These numbers are unsupportable and make fragmentation a good attack= vector because of it (interesting note=2C unlike the operating system peop= le=2C Cisco who has to deal with this in the real world sets the value to 5= seconds). Now let us look at 3517bis. No where is there a mention of Reordering time= yet by definition it has to be considered. Indeed if we did not consider = reordering time then we could simply queue the retransmission of a missing = segment as soon as a SACK block arrives that implies the segment is missing= . As it is if we saved the block and then waited an amount of time equal t= o the reordering time=2C if we did not receive an ACK or SACK covering the = range we could and should queue it for retransmission WHETHER WE RECEIVED A= NY ACKs OR SACKs IN THE INTERIM. The problem is three ACKs is a very very bad way to simulate reordering tim= e since on a busy link it will trigger too early casing duplicate transmiss= ions and if the link goes idle it will fire way to slowly or not at all=2C = even though it could correctly have been used for retransmission with only = one occurrence. Also for you to think about - a Reordering time of greater than .25*RTT deg= rades the throughput of the link in direct proportion to its value. .Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 > Date: Fri=2C 3 Aug 2012 19:37:32 -0400 > From: tsabatini@hotmail.com > To: mallman@icir.org > CC: tcpm@ietf.org=3B mattmathis@google.com=3B touch@isi.edu > Subject: Re: [tcpm] Settling Time and RFC3517bis >=20 > All - >=20 > Because of the wording of the original comment it was not clear whether t= he RTT referred to the generated SACK information from the receiver or the = original transmission from the sender. By definition=2C with respect to th= e sender=2C it is not possible to properly retransmit the message in less t= han one RTT plus Reordering time plus processing time. >=20 > I am sorry for this misunderstanding. >=20 > Tony >=20 > Sent from my ASUS Pad >=20 > Mark Allman wrote: >=20 > > > >This is all pretty mis-guided. Let me say just a few quick things. > > > >> 3) STANDARD TCP can not recover in less than one RTT=2C=20 > > > >Correct. Nor would we want it to. If you retransmit in less than one > >RTT from the time a segment is originally sourced then you will always > >be retransmitting blind. I.e.=2C you'll have no indication as to whethe= r > >that segment needs to be retransmitted or not. > > > >> SACK TCP as written certainly can and does currently recover in > >> less that one RTT on at least long links. =20 > > > >Incorrect. At least I am aware of no TCP SACK-based loss recovery > >variant that retransmits a segment less than one RTT after it was > >originally sent. You reference 3517bis in the subject. The algorithm > >specified in RFC 3517 and 3517bis *does not* retransmit a segment in > >less than one RTT. > > > >> With the changes I have been proposing nearly all errors can be > >> recovered in less than one RTT. > > > >The only way to recover in less than one RTT is to retransmit blind. > >I.e.=2C retransmit segments without any indication as to whether they ha= ve > >arrived at the receiver or not. One could write such an algorithm. > >And=2C probably show it fixes lost segments sooner. But=2C the question > >would immediately become "at what cost?". I.e.=2C how many needless > >retransmits are being piled into the network to accomplish this task? > >And=2C the answer nearly has to be proportional to the benefit you obtai= n. > >I.e.=2C I bet that as you speculatively retransmit more segments you wil= l > >also spurious retransmit more segments. =20 > > > >And=2C this is needless retransmits that we know are being piled into a > >congested network and so are using scarce network resources. So=2C all > >around a bad idea. > > > >allman > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = --_f6656ed4-194c-4f9a-8c31-7884b8732dc7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All -

After reviewing thi= ngs a bit more I realize no one has given serious thought to Fragmentation = Reassembly Timer=2C Reordering Time and the pseudo equivalent of three acks= that is used to substitute for a more rigorous Reordering Time.

Fir= st let us examine fragmentation reassembly timer. =3B Since=2C as was p= ointed out=2C all fragments are generated at the same time if we do not con= sider reordering of the fragments then the timer need be no greater than th= e transmission delay inherent in the fragment length as it relates to link = speed plus an amount for processing delay=2C relatively speaking a very sma= ll amount of time. =3B Even if we include a reroute through a satellite= link that adds only 500 ms to the timer=2C there is NO scenario under whic= h reordering will take over two seconds so with an abundance of caution you= could set fragment reassembly time to four seconds and be done with it.&nb= sp=3B Yet EVERY IP stack sets this value to above fifteen seconds (Linux is= 15)=2C some at thirty seconds (Microsoft is 30) and the rest at SIXTY SECO= NDS!! (Solaris=2C BSD). =3B These numbers are unsupportable and make fr= agmentation a good attack vector because of it (interesting note=2C unlike = the operating system people=2C Cisco who has to deal with this in the real = world sets the value to 5 seconds).

Now let us look at 3517bis. = =3B No where is there a mention of Reordering time yet by definition it has= to be considered. =3B Indeed if we did not consider reordering time th= en we could simply queue the retransmission of a missing segment as soon as= a SACK block arrives that implies the segment is missing. =3B As it is= if we saved the block and then waited an amount of time equal to the reord= ering time=2C if we did not receive an ACK or SACK covering the range we co= uld and should queue it for retransmission WHETHER WE RECEIVED ANY ACKs OR = SACKs IN THE INTERIM.

The problem is three ACKs is a very very bad w= ay to simulate reordering time since on a busy link it will trigger too ear= ly casing duplicate transmissions and if the link goes idle it will fire wa= y to slowly or not at all=2C even though it could correctly have been used = for retransmission with only one occurrence.

Also for you to think a= bout - a Reordering time of greater than .25*RTT degrades the throughput of= the link in direct proportion to its value.

.Tony

Anthony Sa= batini
200 =3BWest 20th Street
Apt. 1216
New York=2C NY 10011<= br>
Phone: (212) 867-7179
Mobile: (917) 224-8388

 =3B
<= br>
>=3B Date: Fri=2C 3 Aug= 2012 19:37:32 -0400
>=3B From: tsabatini@hotmail.com
>=3B To: ma= llman@icir.org
>=3B CC: tcpm@ietf.org=3B mattmathis@google.com=3B touc= h@isi.edu
>=3B Subject: Re: [tcpm] Settling Time and RFC3517bis
>= =3B
>=3B All -
>=3B
>=3B Because of the wording of the ori= ginal comment it was not clear whether the RTT referred to the generated SA= CK information from the receiver or the original transmission from the send= er. By definition=2C with respect to the sender=2C it is not possible to p= roperly retransmit the message in less than one RTT plus Reordering time pl= us processing time.
>=3B
>=3B I am sorry for this misunderstandi= ng.
>=3B
>=3B Tony
>=3B
>=3B Sent from my ASUS Pad>=3B
>=3B Mark Allman <=3Bmallman@icir.org>=3B wrote:
>= =3B
>=3B >=3B
>=3B >=3BThis is all pretty mis-guided. Let m= e say just a few quick things.
>=3B >=3B
>=3B >=3B>=3B 3) S= TANDARD TCP can not recover in less than one RTT=2C
>=3B >=3B
&g= t=3B >=3BCorrect. Nor would we want it to. If you retransmit in less th= an one
>=3B >=3BRTT from the time a segment is originally sourced th= en you will always
>=3B >=3Bbe retransmitting blind. I.e.=2C you'll= have no indication as to whether
>=3B >=3Bthat segment needs to be = retransmitted or not.
>=3B >=3B
>=3B >=3B>=3B SACK TCP a= s written certainly can and does currently recover in
>=3B >=3B>= =3B less that one RTT on at least long links.
>=3B >=3B
>= =3B >=3BIncorrect. At least I am aware of no TCP SACK-based loss recover= y
>=3B >=3Bvariant that retransmits a segment less than one RTT afte= r it was
>=3B >=3Boriginally sent. You reference 3517bis in the sub= ject. The algorithm
>=3B >=3Bspecified in RFC 3517 and 3517bis *doe= s not* retransmit a segment in
>=3B >=3Bless than one RTT.
>=3B= >=3B
>=3B >=3B>=3B With the changes I have been proposing ne= arly all errors can be
>=3B >=3B>=3B recovered in less than one= RTT.
>=3B >=3B
>=3B >=3BThe only way to recover in less than= one RTT is to retransmit blind.
>=3B >=3BI.e.=2C retransmit segment= s without any indication as to whether they have
>=3B >=3Barrived at= the receiver or not. One could write such an algorithm.
>=3B >=3BA= nd=2C probably show it fixes lost segments sooner. But=2C the question
= >=3B >=3Bwould immediately become "at what cost?". I.e.=2C how many ne= edless
>=3B >=3Bretransmits are being piled into the network to acco= mplish this task?
>=3B >=3BAnd=2C the answer nearly has to be propor= tional to the benefit you obtain.
>=3B >=3BI.e.=2C I bet that as you= speculatively retransmit more segments you will
>=3B >=3Balso spuri= ous retransmit more segments.
>=3B >=3B
>=3B >=3BAnd=2C thi= s is needless retransmits that we know are being piled into a
>=3B >= =3Bcongested network and so are using scarce network resources. So=2C all<= br>>=3B >=3Baround a bad idea.
>=3B >=3B
>=3B >=3Ballman<= br>>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B ______________= _________________________________
>=3B tcpm mailing list
>=3B tcp= m@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/tcpm
=
= --_f6656ed4-194c-4f9a-8c31-7884b8732dc7_-- From touch@isi.edu Sat Aug 11 16:17:27 2012 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 272E011E80A5 for ; Sat, 11 Aug 2012 16:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.203 X-Spam-Level: X-Spam-Status: No, score=-105.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgEnrtvVkt1z for ; Sat, 11 Aug 2012 16:17:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 767AE11E80A3 for ; Sat, 11 Aug 2012 16:17:26 -0700 (PDT) Received: from [10.171.7.124] (mobile-166-147-071-141.mycingular.net [166.147.71.141]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q7BNGjYs011916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 11 Aug 2012 16:16:55 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <02A705A4-98A1-42CE-993D-5EB8CEA840A6@isi.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9B206) From: Joe Touch Date: Sat, 11 Aug 2012 18:16:40 -0500 To: Anthony Sabatini X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm , Matt Mathis , "mallman@icir.org" Subject: Re: [tcpm] Reordering Time and RFC3517bis 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, 11 Aug 2012 23:17:27 -0000 On Aug 11, 2012, at 4:23 PM, Anthony Sabatini wrote:= > First let us examine fragmentation reassembly timer. Since, as was pointe= d out, all fragments are generated at the same time Fragmentation of fragments can also occur, which is not synchronized.=20 > if we do not consider reordering of the fragments We do.=20 > then the timer need be no greater than the transmission delay inherent in t= he fragment length as it relates to link speed plus an amount for processing= delay, relatively speaking a very small amount of time. See multipath routing.=20 ... > These numbers are unsupportable and make fragmentation a good attack vecto= r because of it (interesting note, unlike the operating system people, Cisco= who has to deal with this in the real world sets the value to 5 seconds). Implementations regularly trade compliance - and robustness sometimes - for c= ost.=20 The resulting drops aren't well tracked, so we shouldn't assume shore reasse= mbly timers are ok.=20 Joe= From eblanton@cs.ohiou.edu Sat Aug 11 19:02:01 2012 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 31E7611E80A3 for ; Sat, 11 Aug 2012 19:02:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEJJwl2kIdh1 for ; Sat, 11 Aug 2012 19:02:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 49F8B11E8091 for ; Sat, 11 Aug 2012 19:02:00 -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.77 (FreeBSD)) (envelope-from ) id 1T0NV6-000Jan-RO; Sun, 12 Aug 2012 02:01:58 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id ECC6E3C77C; Sat, 11 Aug 2012 22:01:55 -0400 (EDT) Date: Sat, 11 Aug 2012 22:01:55 -0400 From: Ethan Blanton To: Anthony Sabatini Message-ID: <20120812020155.GA8157@colt> Mail-Followup-To: Anthony Sabatini , "mallman@icir.org" , tcpm , Matt Mathis , Joe Touch References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" 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: Joe Touch , tcpm , Matt Mathis , "mallman@icir.org" Subject: Re: [tcpm] Reordering Time and RFC3517bis 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: Sun, 12 Aug 2012 02:02:01 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Anthony Sabatini spake unto us the following wisdom: > After reviewing things a bit more I realize no one has given serious > thought to Fragmentation Reassembly Timer, Reordering Time and the > pseudo equivalent of three acks that is used to substitute for a more > rigorous Reordering Time. MANY people have thought about this. This means only that you are not familiar with the literature. http://scholar.google.com/scholar?q=ip+fragmentation http://scholar.google.com/scholar?q=tcp+reordering The second link seems to have many more useful papers on the first page, but certainly there is a wealth of information on both. [snip] > Even if we include a reroute through a satellite link that adds only > 500 ms to the timer, there is NO scenario under which reordering will > take over two seconds so with an abundance of caution you could set > fragment reassembly time to four seconds and be done with it. Queuing delay. The rest of this paragraph is invalid, before and after this erroneous statement. [snip] > Now let us look at 3517bis. No where is there a mention of Reordering > time yet by definition it has to be considered. Indeed if we did not > consider reordering time then we could simply queue the retransmission > of a missing segment as soon as a SACK block arrives that implies the > segment is missing. As it is if we saved the block and then waited an > amount of time equal to the reordering time, if we did not receive an > ACK or SACK covering the range we could and should queue it for > retransmission WHETHER WE RECEIVED ANY ACKs OR SACKs IN THE INTERIM. Reordering was *carefully* considered by the community, as well as specifically by the authors of RFC 3517 and 3517bis, myself included. I have published several papers and RFCs specifically on TCP reordering-related issues. You will find them in the above Google Scholar link. Your overly simplistic analysis fails to take into consideration the basic nature of packet switched networks with best effort forwarding and forwarding queues. > The problem is three ACKs is a very very bad way to simulate > reordering time since on a busy link it will trigger too early casing > duplicate transmissions and if the link goes idle it will fire way to > slowly or not at all, even though it could correctly have been used > for retransmission with only one occurrence. This is also a problem that has been extensively considered in the literature. In fact, it is the precise reason we define the 3517 algorithms in terms of DupThresh, rather than the number 3. There are adaptive schemes for tuning DupThresh, as well as networks that simply use a number larger than three. Both 5681 and 3517 permit this, provided that the resulting algorithm is no more aggressive than the algorithms described in 5681. See, for example, RFC 4653. Three dup ACKs is certainly a compromise, but it is not "a very very bad way to simulate reordering time" -- in fact, it is almost always correct, and there are studies to show this. There are certain network pathologies on which it is reliably wrong, and there are situations where it may degrade performance by a small constant factor. These are a trade-off for the heaps of situations where it just Does the Right Thing without complicated timers and predictions. I'm not actually aware of any algorithm that performs markedly better in a wide range of network situations, but I would be shocked to see one that is anywhere near as simple. > Also for you to think about - a Reordering time of greater than > .25*RTT degrades the throughput of the link in direct proportion to > its value. Unecessary retransmissions have a MUCH larger impact than this, as each spurious retransmission cuts cwnd by 1/2. You need to carefully revisit your premises, this thread indicates that you do not understand the interactions of packet switched networks and reliable transport protocols. I would be happy to help you understand these issues, but I will not reply to any more spurious assertions that the well-studied approaches we are currently taking are wrong unless they are accompanied by careful analysis and a clear understanding of the subject matter. Ethan --IS0zKkzwUGydFO0o 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) iQEVAwUBUCcOk/8fixZ3H8crAQjcGQf/T2NNkFY2a2LO7BsGB1Z2lmgYPRVPfMfA 6WYbeOHgypPBreuvcIyT2k5qbxXM8uHZwDzx2scN/c3M2JiRF1nbcwKKWLJoiyr0 u3FhpkWnTwKTqRRPjth49JP0NYysFfG+N4yGIcumViJF3lsxCzHfwHArCMFXupQX Z1GsDBBRDcx4XDg0jd27s5xWJrZEO/6k1rbY0HveSsDVGwBAX8q4INhs6UnjnTiu O+9KOJ4zY5dabeJmE8WdcdLrvMuU/BfX/76vkA+Z4H4QVGWzueqT32ZYJ/ZkCZ8f CI8iMlLinUAjiFx9jZvvlGohdW7CEo5WQAk42P7JCUSjBcpQ5I8Gmw== =jvup -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- From ycheng@google.com Sun Aug 12 10:33:47 2012 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 0438B21F8578 for ; Sun, 12 Aug 2012 10:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9dkyQmzwgMD for ; Sun, 12 Aug 2012 10:33:46 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 270EA21F84D6 for ; Sun, 12 Aug 2012 10:33:45 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so6595959obb.31 for ; Sun, 12 Aug 2012 10:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=9KHy0lHVbljl/K8BMKi6PsJPIRt2Z/iNM07VOPKkeIo=; b=S+M07vhWGhxjZe5xkW2HdNCPiTW7jfvfRRFRCE9Qmv6yoFtOqA+Dp9fGs1Z07hnOFp Op+/JnjipeDtDjNzh9YFe09EqIcWynGUYZ40PBogNeKwqG/ULdjE1quiEx4c44mdWnJ2 LQF0H5ezPiEgn0V/nkD17uwaTqTaSskIwXVhdsPQLCDt0gflcS62+/TDDRuISKXYUamG rmig5xO0ch1MWcKVoTYG2ZpXrs0R3VYdyGBDJEABx0I8lq13kUKDhSeclCaHYavDXWkl djRxcbuWHMVOYFYAL617I6bWFXrX5LX14PFAtvwgRAy4gqrJdqgDZ2BNWoxgGIwUX8oV rmFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=9KHy0lHVbljl/K8BMKi6PsJPIRt2Z/iNM07VOPKkeIo=; b=gTSTBhffE2GIZ9zecVl87JDUJevDxNC9eDaCUJ4+0IVrPYI1FJ37W1d7MCRfqOQUHv KCNXGuvigmIoKnbm45hoLtvC7RNilVNDCaqdHWdyHDTDXkHh1EsYu0+tvfinvwVxxPx6 DXfH6MvFuMa1pecGpgnuurPhGw7AcFT0+bJQTF1KADmqIDw8sW1uLiidD8F2bNtzY82L RveUh2iK7kpoj8hC9E1JVtj9YXL18g978/bEBSbZIBupjyqc7i2tx9VBGEQCM1Llr2Wj Z26t9sQk81XO0i+ajtnNQy+ajqzyPJQsRf+uGTbQRm3KXb1kVvTHDFosrBlaYahGx7JE OJLw== Received: by 10.182.51.37 with SMTP id h5mr7391473obo.35.1344792822830; Sun, 12 Aug 2012 10:33:42 -0700 (PDT) Received: by 10.182.51.37 with SMTP id h5mr7391464obo.35.1344792822640; Sun, 12 Aug 2012 10:33:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.144.34 with HTTP; Sun, 12 Aug 2012 10:33:22 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Sun, 12 Aug 2012 10:33:22 -0700 Message-ID: To: Anthony Sabatini Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnx+liXPSwq6YvR7mIY4/7iPEZ9DFrekbptSTyq13h+hYu8MBZuWXvWTlK/Nz5mi/OiL8xSZdEHL2aWblomX0EHdcQ094DfSDeyXsTuAec9qk5uw2173ixbc7Ki5jABH09ke8drOyyMZwjoUWGYYYjwGtgtxH/TRevnnnn1C44ggK4pWpEvg3RkQ9UvjsH1hQ7Sgyob Cc: tcpm Subject: Re: [tcpm] Reordering Time and RFC3517bis 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: Sun, 12 Aug 2012 17:33:47 -0000 On Sat, Aug 11, 2012 at 2:23 PM, Anthony Sabatini wrote: > All - > > After reviewing things a bit more I realize no one has given serious thought > to Fragmentation Reassembly Timer, Reordering Time and the pseudo equivalent > of three acks that is used to substitute for a more rigorous Reordering > Time. > > First let us examine fragmentation reassembly timer. Since, as was pointed > out, all fragments are generated at the same time if we do not consider > reordering of the fragments then the timer need be no greater than the > transmission delay inherent in the fragment length as it relates to link > speed plus an amount for processing delay, relatively speaking a very small > amount of time. Even if we include a reroute through a satellite link that > adds only 500 ms to the timer, there is NO scenario under which reordering > will take over two seconds so with an abundance of caution you could set > fragment reassembly time to four seconds and be done with it. Yet EVERY IP > stack sets this value to above fifteen seconds (Linux is 15), some at thirty > seconds (Microsoft is 30) and the rest at SIXTY SECONDS!! (Solaris, BSD). > These numbers are unsupportable and make fragmentation a good attack vector > because of it (interesting note, unlike the operating system people, Cisco > who has to deal with this in the real world sets the value to 5 seconds). > > Now let us look at 3517bis. No where is there a mention of Reordering time > yet by definition it has to be considered. Indeed if we did not consider > reordering time then we could simply queue the retransmission of a missing > segment as soon as a SACK block arrives that implies the segment is missing. > As it is if we saved the block and then waited an amount of time equal to > the reordering time, if we did not receive an ACK or SACK covering the range > we could and should queue it for retransmission WHETHER WE RECEIVED ANY ACKs > OR SACKs IN THE INTERIM. Hi Anthony, RFC 5827 suggests a lower dupthresh and similar reordering time logic in the appendix. I implemented RFC 5827 with features suggested in Appendix A.1 and A.3 in Linux 3.5. Coincidentally the imlementation waits .25 RTT to trigger ER as well. > > The problem is three ACKs is a very very bad way to simulate reordering time > since on a busy link it will trigger too early casing duplicate > transmissions and if the link goes idle it will fire way to slowly or not at > all, even though it could correctly have been used for retransmission with > only one occurrence. > > Also for you to think about - a Reordering time of greater than .25*RTT > degrades the throughput of the link in direct proportion to its value. > > .Tony > > Anthony Sabatini > 200 West 20th Street > Apt. 1216 > New York, NY 10011 > > Phone: (212) 867-7179 > Mobile: (917) 224-8388 > > > > >> Date: Fri, 3 Aug 2012 19:37:32 -0400 >> From: tsabatini@hotmail.com >> To: mallman@icir.org >> CC: tcpm@ietf.org; mattmathis@google.com; touch@isi.edu >> Subject: Re: [tcpm] Settling Time and RFC3517bis >> >> All - >> >> Because of the wording of the original comment it was not clear whether >> the RTT referred to the generated SACK information from the receiver or the >> original transmission from the sender. By definition, with respect to the >> sender, it is not possible to properly retransmit the message in less than >> one RTT plus Reordering time plus processing time. >> >> I am sorry for this misunderstanding. >> >> Tony >> >> Sent from my ASUS Pad >> >> Mark Allman wrote: >> >> > >> >This is all pretty mis-guided. Let me say just a few quick things. >> > >> >> 3) STANDARD TCP can not recover in less than one RTT, >> > >> >Correct. Nor would we want it to. If you retransmit in less than one >> >RTT from the time a segment is originally sourced then you will always >> >be retransmitting blind. I.e., you'll have no indication as to whether >> >that segment needs to be retransmitted or not. >> > >> >> SACK TCP as written certainly can and does currently recover in >> >> less that one RTT on at least long links. >> > >> >Incorrect. At least I am aware of no TCP SACK-based loss recovery >> >variant that retransmits a segment less than one RTT after it was >> >originally sent. You reference 3517bis in the subject. The algorithm >> >specified in RFC 3517 and 3517bis *does not* retransmit a segment in >> >less than one RTT. >> > >> >> With the changes I have been proposing nearly all errors can be >> >> recovered in less than one RTT. >> > >> >The only way to recover in less than one RTT is to retransmit blind. >> >I.e., retransmit segments without any indication as to whether they have >> >arrived at the receiver or not. One could write such an algorithm. >> >And, probably show it fixes lost segments sooner. But, the question >> >would immediately become "at what cost?". I.e., how many needless >> >retransmits are being piled into the network to accomplish this task? >> >And, the answer nearly has to be proportional to the benefit you obtain. >> >I.e., I bet that as you speculatively retransmit more segments you will >> >also spurious retransmit more segments. >> > >> >And, this is needless retransmits that we know are being piled into a >> >congested network and so are using scarce network resources. So, all >> >around a bad idea. >> > >> >allman >> > >> > >> > >> _______________________________________________ >> 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 mirja.kuehlewind@ikr.uni-stuttgart.de Mon Aug 13 13:39:13 2012 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 08C9521F8647 for ; Mon, 13 Aug 2012 13:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZxH8OfxpQmd for ; Mon, 13 Aug 2012 13:39:11 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C48521F84E1 for ; Mon, 13 Aug 2012 13:39:11 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 8A17B633B1; Mon, 13 Aug 2012 22:39:05 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4A57259A8A; Mon, 13 Aug 2012 22:39:05 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Jerry Chu Date: Mon, 13 Aug 2012 22:39:04 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201207251811.40438.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201208132239.04933.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-initcwnd-04 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, 13 Aug 2012 20:39:13 -0000 Hi Jerry, I still believe restructuring the document would help to make it better=20 readable but I'm okay to keep the same structure than RFC 3390. Please chec= k=20 if all paragraph are actually in the right section or more subsection are=20 needed to improve readability. Someone who wants to implement the change=20 might not read the whole document and might very easy overread any=20 SHOULDs/MUSTs in any later section than section 3. Maybe it is an option to= =20 add a reference to the later SHOULDs/MUSTs in section 2? Regarding the comments below. You several times named a reference to=20 slides/papers/mails instead of actually addressing my comment in the draft.= I=20 know where to find the information as I've been following the discussion. B= ut=20 someone who later reads the document, might not have followed mail discussi= on=20 or ieft slides. Thus you really should add the references in the document o= r=20 even better, explain the outcome better in the document such that the=20 references are not need anymore. Mirja On Wednesday 01 August 2012 07:32:31 Jerry Chu wrote: > On Wed, Jul 25, 2012 at 2:58 PM, Jerry Chu wrote: > > On Wed, Jul 25, 2012 at 11:12 AM, Mirja Kuehlewind > > > > wrote: > >> Hi Jerry, > >> > >> just one quick comment: > >>> Moreover, the TOC provides a very clear index of the contents so a > >>> savvy reader can > >>> quickly pick the sections of interesting. E.g., if you only want to > >>> focus on the change > >>> you'll know to read section 1 and 2 only. That's it. > >> > >> And that's not really true (anymore). There are several SHOULD and MUST > >> in the other sections as well. Thus you have to read all the doc to > >> correctly implement the changes. I know that the intent was to have > >> everything in section 1 and 2 that is of interest for implementers but > >> due to the many changes that have been done in previous versions, it's > >> not the case anymore. > > > > Actually the only other specification related languages is section 9, > > and it's not > > essential as it simply reiterates what is described in rfc6298. > > > > Yes other SHOULD and MUST can be found in the newly added section 12 > > "Usage and Deployment Recommendations", but that section is mainly about > > what one must do in any future large scale experiment, closely monitori= ng > > a number of key metrics... and not really about protocol specification. > > > > So to summarize, this draft is not just about protocol specification, > > it also addresses > > many other questions like why, and how to go about doing more > > experiments safely. > > > >> That why I said, all the content is there, would be nice to > >> clean-up/restructure a little and then it's done. > >> > >> It's good to have a similar structure than RFC3390 (didn't realize that > >> you tried to have exactly the same sections here) but if the content > >> would fit > > > > It was spelled out up front in 1. Introduction > > > > "This document proposes to raise the upper bound on TCP's initial > > window (IW) to 10 segments or roughly 15KB. It is patterned after and > > borrows heavily from RFC 3390 [RFC3390] and earlier work in this > > area." > > > >> better with a different structure, I'd prefer to have a good readable > >> doc over having a doc that looks similar to RFC3390. > > > > Let's stick to the current format but I will respond to your one other > > criticism on > > section 12 first. The section is quite specific about the metrics to > > monitor: "A key metric to monitor is the rate of packet losses, ECN > > marking, or segment retransmissions during the initial burst." But as > > others have pointed out it can be > > quite difficult to try to get more specific than that, i.e., how much > > performance > > deteriorates before one must back off. As such all we can do for now is > > to have enough warning signs for now but leave some details for future > > investigation. > > > > Jerry > > > >> Mirja > >> > >>> >Hence I'd like to > >>> > propose quite a little restructuring before moving the document > >>> > forward as it is hard to easily catch the main points at the moment. > >>> > More concrete, I'd move at least section 4, 10 and 11, maybe also 5, > >>> > 6 and 7 (or at least partly) to the appendix. The first two paragra= ph > >>> > of section 7 might actually belong in > >>> > >>> Yes it's doable but I think the current flow is fine if you realize > >>> the main purpose of > >>> the document is to justify the change, not the change itself. Also TOC > >>> will make it > >>> much easier to navigate through. > >>> > >>> > the security consideration section. And section 15 (conclusion) is > >>> > not needed at all. More detailed comments below. > >>> > > >>> > Mirja > >>> > > >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > Section 1 Introduction: > >>> > ---------------------------- > >>> > - s/roughly 15KB/maxium 14600B/ > >>> > >>> Ok. > >>> > >>> > - 2. paragraph: Don't like this two sentences at all. I hope the > >>> > reason to increase IW is not just the fact there the queues are lar= ge > >>> > enough to store 10 packets. You basically saying "Let's send more > >>> > packets at once to blow the queues!". I'd say the reason is that fl= ow > >>> > sizes have increased and therefore IW10 would improve latency a lot. > >>> > Only because queues are likely to be large than 10 packets today, it > >>> > is possible at all to send more than 10 packet at once. Btw. even if > >>> > the queue would be small, pacing could help to still allow an IW of > >>> > 10. Moreover, the fact that there might be several concurrent flows, > >>> > does not mean that the buffer has to be larger (only if those flow > >>> > start at the same time with IW10). And even if there is a large > >>> > buffer, if there is a long-lived TCP connection, this flow will fill > >>> > up the queue and there might be by chance still no space in the que= ue > >>> > for 10 additional packets. > >>> > >>> Guess you read the paragraph differently from what the authors had in > >>> mind. What we have in mind was "Ten segments are likely to fit into > >>> queue space" because access link drains much faster these days (due to > >>> b/w growth)... > >>> > >>> Will try to make it more clear. > >>> > >>> Will continue later, > >>> > >>> Jerry > >>> > >>> > - 3. paragraph: Don't agree. You might not know that there is a low > >>> > speed link somewhere on the path. There are cases where the endpoint > >>> > can protect its path by setting the receiver window but that's not > >>> > the general case. > > This is exactly the point - it's not the general case but may be the > vast majority. > I.e., 95% of severely b/w limited hosts may be just 1 hop away or even > directly attached to a slow link (e.g., dailup modem) hence can be > mitigated much easily. No one suggested a solution here to solve the > general problem of > detecting bottleneck > b/w. That's the job TCP's CC algorithm. > > >>> > - 5. paragraph: "We recommend that all TCP implementations have a > >>> > settable TCP IW parameter..." > >>> > -> I'd like to see this not only in the introduction but also in > >>> > the main section (2.) that is describing the changes and maybe even > >>> > as a SHOULD > >>> > > >>> > > >>> > Section 2 TCP Modifications > >>> > ------------- > >>> > - Maybe have a more specific title like "Setting the IW" and some > >>> > subsections > > Plagiarized from RFC3390 :) > > >>> > - equation 1: say somewhere that numbers are in KByte > > Not really. > > >>> > - 4. paragraph ("Note that...") does not belong in this section > > Why not? (It's more or less a disclaim because no one has done any study > on non-Ethernet MTU. > > >>> > - maybe new subsection for paragraph 5 "Resetting the IW after SYN > >>> > loss"; what are "multiple SYN or SYN/ACK retransmissions" -> maybe > >>> > say a number > > Ok. Changed to "more than one". > > >>> > - last paragraph: maybe s/implementations SHOULD fall > >>> > back/implementations MUST fall back/ ? > >>> > > >>> > > >>> > Section 3 Implementation Issues > >>> > ------------- > >>> > - Maybe move the 3 paragraph into section 2 such that the setting of > >>> > the receive window is a MUST or SHOULD of the changes to TCP > > Non-essential. Remember even IW10 is just an upperbound. > > >>> > - 4. paragraph: Please give some explanation (or remove) > > This was brought up and discussed on the list long ago. > > >>> > Section 4 Background > >>> > ------------ > >>> > - Move most parts in the appendix > >>> > > >>> > - Move 2. paragraph into Introduction > >>> > > >>> > - Maybe improve structure with subsections e.g. paragraph 5 and 6 > >>> > as "Recommendation for HTTP Traffic" or something > > See my other response. I prefer not to change the structure at this time. > > >>> > - 7. paragraph: "pacing will not be necessary" > >>> > -> I can't remember having seen any results on this. Please expla= in > >>> > further or remove! > > The statement was really "We suspect" pacing will not be necessary because > our test results do not show any severe congestion from IW10... > > >>> > Section 5 Advantages of a Larger Initial Window > >>> > ----------- > >>> > - section 5.1 Reducing Latency > >>> > You should also mention that for larger transmission with several > >>> > 100s of RTT a save of 4 RTT does not really help. Thus transmissions > >>> > which will finish within a small number of RTT will benefit the mos= t. > > Isn't it obvious already? > > >>> > - section 5.2 > >>> > You make some quite general statements here and then u only refer > >>> > to google data. Maybe you can find some other references as well. > > It's not just google data (see all the refs.) > > >>> > Section 6 > >>> > ---------- > >>> > - paragraph 3 and 4 belong in an evaluation section/appendix (maybe > >>> > own subsection on "Influence of simultaneous opened connections") > >>> > > >>> > Section 7 > >>> > -------- > >>> > - Move 1. paragraph to security consideration > >>> > > >>> > - Move rest in appendix or even parts in the introduction > >>> > > >>> > Section 9 > >>> > ---------- > >>> > - move to main section which is introducing the TCP changes as own > >>> > subsection as a MUST is in here > > Non-essential because it simply restates what is said in rfc6298. It was > added to address some concern (or confusion) that was brought up in the > past that the initial burst of 10 pkts won't bid well for RTO hence causi= ng > spurious rexmits. > > >>> > - can you explain better why this is need or what would happen > >>> > otherwise? > >>> > > >>> > Section 10 > >>> > ---------- > >>> > - Move to appendix, have more subsections and better titles for the > >>> > subsections e.g. "Improvements in Latency", "Impact on the > >>> > Retransmission Rate" and "Multiple TCP Connections" > >>> > > >>> > - The numbers for the latency improvement are only on (google) web > >>> > search. Of course there are quite large improvements possible but t= he > >>> > Internet contains also other traffic. Not sure if your number are > >>> > really that significant...? > > We just stated what we have. > > >>> > Section 11 > >>> > --------- > >>> > - move to appendix > >>> > > >>> > - It's nice that you list all the studies. Could you please quickly > >>> > summarize their results/findings, too? Because I guess that the > >>> > intersting part to know. > > If you are interested please go read them yourself. > > >>> > Section 12 > >>> > -------- > >>> > - Its good to have this section but it's quite unspecific. E.g. you > >>> > say "An increased initial window MUST NOT be turned on by default on > >>> > systems without such monitoring capabilities." But what exactly > >>> > should be monitored and how frequently and so on. Also "any > >>> > significant deterioration" doesn't say anything to me. Is it possib= le > >>> > to have a concrete approach/algorithm here what to monitor when and > >>> > what to do in which cases? And than have this even as part of the > >>> > main section with TCP changes as this section has also some SHOULD > >>> > and MUST and might be overread otherwise. > >>> > > >>> > Section 14 > >>> > --------- > >>> > - "highly unlikely to lead to a persistent state of network > >>> > congestion" -> Even a "highly unlikely" is concerning me in this > >>> > case! Also there is no reasoning for this. But I guess you can even > >>> > say, that this change cannot cause persistent network congestion as > >>> > congestion control is still used.... > > See 1st paragraph of section 7. > > >>> > Section 15 Conclusion > >>> > -------- > >>> > - Is not needed here at all, as no new information > > Most rfcs have a conclusion section for those who have time only for > the 1st and last sections. > > >>> > Appendix > >>> > --------- > >>> > - "One notable exception is YouTube because we don't think > >>> > the large initial window will have much material impact, either > >>> > positive or negative, on bulk data services." > >>> > -> Why is this document than not recommending to NOT use IW10 for > >>> > bulk data services? > > Why should it recommend NOT? How would the TCP stack know apriori bulk > or not? So it will require input from the apps... Is it really worth > the complexity? > > >>> > - "[CW10] contains some result from a testbed study on how short > >>> > flows with a larger initial window might affect the throughput > >>> > performance of other co-existing, long lived, bulk data transfers." > >>> > -> Please also describe what the results are! > > Read the slides please. > > >>> > - paragraph on "Why 10 segment?" > >>> > -> This is something I would prefer to have in the body of the > >>> > document not in the appendix > >>> > > >>> > - "Some simulation studies [JNDK10, JNDK10-1] have been conducted to > >>> > study the effect of a larger initial window on wireless links > >>> > from 2G to 4G networks (EGDE/HSPA/LTE). The overall result seems > >>> > mixed in both raw performance and the fairness index." > >>> > -> Should it be recommend to not use IW10 in wireless scenarios (= if > >>> > known)? > > Studies are still on-going. I don't remember there has been a conclusive > result. > > Jerry > > >> -- > >> ------------------------------------------------------------------- > >> Dipl.-Ing. Mirja K=FChlewind > >> Institute of Communication Networks and Computer Engineering (IKR) > >> University of Stuttgart, Germany > >> Pfaffenwaldring 47, D-70569 Stuttgart > >> > >> tel: +49(0)711/685-67973 > >> email: mirja.kuehlewind@ikr.uni-stuttgart.de > >> web: www.ikr.uni-stuttgart.de > >> ------------------------------------------------------------------- =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From tsabatini@hotmail.com Tue Aug 14 11:16:22 2012 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 8F3E521F8646 for ; Tue, 14 Aug 2012 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV-f5vOMkgUb for ; Tue, 14 Aug 2012 11:16:21 -0700 (PDT) Received: from bay0-omc2-s9.bay0.hotmail.com (bay0-omc2-s9.bay0.hotmail.com [65.54.190.84]) by ietfa.amsl.com (Postfix) with ESMTP id 1C80921F8644 for ; Tue, 14 Aug 2012 11:16:21 -0700 (PDT) Received: from BAY002-W228 ([65.54.190.123]) by bay0-omc2-s9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Aug 2012 11:16:21 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8f90a6fa-7129-4673-bc2f-a70b5bb2f78b_" X-Originating-IP: [74.64.96.39] From: Anthony Sabatini To: Google Yuchung Cheng Date: Tue, 14 Aug 2012 14:16:20 -0400 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 14 Aug 2012 18:16:21.0287 (UTC) FILETIME=[E80AD370:01CD7A48] Cc: tcpm Subject: Re: [tcpm] Reordering Time and RFC3517bis 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, 14 Aug 2012 18:16:22 -0000 --_8f90a6fa-7129-4673-bc2f-a70b5bb2f78b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yuchung - Thank you for your reference to RFC5827 appendix=2C it speaks to the issue = at hand. My point has been if you are cleaning up RFC3517 then reference should be m= ade to this in the "bis" draft. The truth has always been no matter how ma= ny ACKs you have seen=2C if a SACK hole has not been filled in Reordering T= ime=2C then the packet can be safely assumed lost. Obviously this makes yo= u more vulnerable to lost ACKs but the only way to truly fix that would be = to adopt my token strategy. This is why I proposed sending another ACK at = .25*RTT if the link goes idle. This fixes both the Last ACK lost problem a= nd kills a duplicate retransmit if that ACK filled a hole (obviously we wou= ld adjust the two times to not collide=2C probably setting the safety ACK t= o .20*RTT and the delay before considering a hole valid to .30*RTT for exam= ple). Also as a personal comment 3517bis has a "first read" problem. You know wh= at you mean but a casual reader does not. You need to be careful to spell = things out and not use words and expressions common to the working group bu= t which may be misunderstood by people lacking that context. Now with respect to those who say I know nothing and have read nothing - le= t us get back to the whole theoretical underpinning of the "three ACK" rule= =2C Vern Paxson's 1999 paper "End-to-End Internet Packet Dynamics"=2C which= discusses in great detail that at the time the rule is a great substitute = for a fixed delay of between 20 ms and 85 ms. He noted rater pointedly tha= t those numbers were selected based on current link speeds of 56 kbps and 1= =2C544 kbps (T1). The reason for avoiding short fixed delays in TCP were o= utlined in RFC791=2C the fact that timers of that era were based on 60 cycl= e power line frequency or 33 ms minimum resolution (two ticks since that co= uld be anywhere from 17 to 33 ms). Obviously all of these assumptions are = invalid today when average high speed internet is 4 mbps and we are progres= sing toward 10 mbps and microsecond timing services are available and wide = spread. As pointed out to me rather forcefully queueing delays are a major= issue=2C which was rather unneccessary as I have been dealing with the iss= ue for the last 40 years=2C so "three ACKs" is no longer a very useful meas= ure in the real world. I would=2C however=2C point out that there is no ro= uter in common use that has enough memory to buffer more than 5 seconds wor= th of high speed traffic=2C nor would it want to as the information then de= livered would be highly irrelevant.=20 Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 > From: ycheng@google.com > Date: Sun=2C 12 Aug 2012 10:33:22 -0700 > Subject: Re: [tcpm] Reordering Time and RFC3517bis > To: tsabatini@hotmail.com > CC: tcpm@ietf.org >=20 > On Sat=2C Aug 11=2C 2012 at 2:23 PM=2C Anthony Sabatini wrote: > > All - > > > > After reviewing things a bit more I realize no one has given serious th= ought > > to Fragmentation Reassembly Timer=2C Reordering Time and the pseudo equ= ivalent > > of three acks that is used to substitute for a more rigorous Reordering > > Time. > > > > First let us examine fragmentation reassembly timer. Since=2C as was p= ointed > > out=2C all fragments are generated at the same time if we do not consid= er > > reordering of the fragments then the timer need be no greater than the > > transmission delay inherent in the fragment length as it relates to lin= k > > speed plus an amount for processing delay=2C relatively speaking a very= small > > amount of time. Even if we include a reroute through a satellite link = that > > adds only 500 ms to the timer=2C there is NO scenario under which reord= ering > > will take over two seconds so with an abundance of caution you could se= t > > fragment reassembly time to four seconds and be done with it. Yet EVER= Y IP > > stack sets this value to above fifteen seconds (Linux is 15)=2C some at= thirty > > seconds (Microsoft is 30) and the rest at SIXTY SECONDS!! (Solaris=2C B= SD). > > These numbers are unsupportable and make fragmentation a good attack ve= ctor > > because of it (interesting note=2C unlike the operating system people= =2C Cisco > > who has to deal with this in the real world sets the value to 5 seconds= ). > > > > Now let us look at 3517bis. No where is there a mention of Reordering = time > > yet by definition it has to be considered. Indeed if we did not consid= er > > reordering time then we could simply queue the retransmission of a miss= ing > > segment as soon as a SACK block arrives that implies the segment is mis= sing. > > As it is if we saved the block and then waited an amount of time equal = to > > the reordering time=2C if we did not receive an ACK or SACK covering th= e range > > we could and should queue it for retransmission WHETHER WE RECEIVED ANY= ACKs > > OR SACKs IN THE INTERIM. > Hi Anthony=2C >=20 > RFC 5827 suggests a lower dupthresh and similar reordering time logic in = the > appendix. I implemented RFC 5827 with features suggested in Appendix A.1 = and A.3 > in Linux 3.5. Coincidentally the imlementation waits .25 RTT to > trigger ER as well. >=20 > > > > The problem is three ACKs is a very very bad way to simulate reordering= time > > since on a busy link it will trigger too early casing duplicate > > transmissions and if the link goes idle it will fire way to slowly or n= ot at > > all=2C even though it could correctly have been used for retransmission= with > > only one occurrence. > > > > Also for you to think about - a Reordering time of greater than .25*RTT > > degrades the throughput of the link in direct proportion to its value. > > > > .Tony > > > > Anthony Sabatini > > 200 West 20th Street > > Apt. 1216 > > New York=2C NY 10011 > > > > Phone: (212) 867-7179 > > Mobile: (917) 224-8388 > > > > > > > > > >> Date: Fri=2C 3 Aug 2012 19:37:32 -0400 > >> From: tsabatini@hotmail.com > >> To: mallman@icir.org > >> CC: tcpm@ietf.org=3B mattmathis@google.com=3B touch@isi.edu > >> Subject: Re: [tcpm] Settling Time and RFC3517bis > >> > >> All - > >> > >> Because of the wording of the original comment it was not clear whethe= r > >> the RTT referred to the generated SACK information from the receiver o= r the > >> original transmission from the sender. By definition=2C with respect t= o the > >> sender=2C it is not possible to properly retransmit the message in les= s than > >> one RTT plus Reordering time plus processing time. > >> > >> I am sorry for this misunderstanding. > >> > >> Tony > >> > >> Sent from my ASUS Pad > >> > >> Mark Allman wrote: > >> > >> > > >> >This is all pretty mis-guided. Let me say just a few quick things. > >> > > >> >> 3) STANDARD TCP can not recover in less than one RTT=2C > >> > > >> >Correct. Nor would we want it to. If you retransmit in less than one > >> >RTT from the time a segment is originally sourced then you will alway= s > >> >be retransmitting blind. I.e.=2C you'll have no indication as to whet= her > >> >that segment needs to be retransmitted or not. > >> > > >> >> SACK TCP as written certainly can and does currently recover in > >> >> less that one RTT on at least long links. > >> > > >> >Incorrect. At least I am aware of no TCP SACK-based loss recovery > >> >variant that retransmits a segment less than one RTT after it was > >> >originally sent. You reference 3517bis in the subject. The algorithm > >> >specified in RFC 3517 and 3517bis *does not* retransmit a segment in > >> >less than one RTT. > >> > > >> >> With the changes I have been proposing nearly all errors can be > >> >> recovered in less than one RTT. > >> > > >> >The only way to recover in less than one RTT is to retransmit blind. > >> >I.e.=2C retransmit segments without any indication as to whether they= have > >> >arrived at the receiver or not. One could write such an algorithm. > >> >And=2C probably show it fixes lost segments sooner. But=2C the questi= on > >> >would immediately become "at what cost?". I.e.=2C how many needless > >> >retransmits are being piled into the network to accomplish this task? > >> >And=2C the answer nearly has to be proportional to the benefit you ob= tain. > >> >I.e.=2C I bet that as you speculatively retransmit more segments you = will > >> >also spurious retransmit more segments. > >> > > >> >And=2C this is needless retransmits that we know are being piled into= a > >> >congested network and so are using scarce network resources. So=2C al= l > >> >around a bad idea. > >> > > >> >allman > >> > > >> > > >> > > >> _______________________________________________ > >> 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 > > = --_8f90a6fa-7129-4673-bc2f-a70b5bb2f78b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yuchung -

Thank you for y= our reference to RFC5827 appendix=2C it speaks to the issue at hand.
My point has been if you are cleaning up RFC3517 then reference should be = made to this in the "bis" draft. =3B The truth has always been no matte= r how many ACKs you have seen=2C if a SACK hole has not been filled in Reor= dering Time=2C then the packet can be safely assumed lost. =3B Obviousl= y this makes you more vulnerable to lost ACKs but the only way to truly fix= that would be to adopt my token strategy. =3B This is why I proposed s= ending another ACK at .25*RTT if the link goes idle. =3B This fixes bot= h the Last ACK lost problem and kills a duplicate retransmit if that ACK fi= lled a hole (obviously we would adjust the two times to not collide=2C prob= ably setting the safety ACK to .20*RTT and the delay before considering a h= ole valid to .30*RTT for example).

Also as a personal comment 3517bi= s has a "first read" problem. =3B You know what you mean but a casual r= eader does not. =3B You need to be careful to spell things out and not = use words and expressions common to the working group but which may be misu= nderstood by people lacking that context.

Now with respect to those = who say I know nothing and have read nothing - let us get back to the whole= theoretical underpinning of the "three ACK" rule=2C Vern Paxson's 1999 pap= er "End-to-End Internet Packet Dynamics"=2C which discusses in great detail= that at the time the rule is a great substitute for a fixed delay of betwe= en 20 ms and 85 ms. =3B He noted rater pointedly that those numbers wer= e selected based on current link speeds of 56 kbps and 1=2C544 kbps (T1).&n= bsp=3B The reason for avoiding short fixed delays in TCP were outlined in R= FC791=2C the fact that timers of that era were based on 60 cycle power line= frequency or 33 ms minimum resolution (two ticks since that could be anywh= ere from 17 to 33 ms). =3B Obviously all of these assumptions are inval= id today when average high speed internet is 4 mbps and we are progressing = toward 10 mbps and microsecond timing services are available and wide sprea= d. =3B As pointed out to me rather forcefully queueing delays are a maj= or issue=2C which was rather unneccessary as I have been dealing with the i= ssue for the last 40 years=2C so "three ACKs" is no longer a very useful me= asure in the real world. =3B I would=2C however=2C point out that there= is no router in common use that has enough memory to buffer more than 5 se= conds worth of high speed traffic=2C nor would it want to as the informatio= n then delivered would be highly irrelevant.

Tony

Anthony Sa= batini
200 =3BWest 20th Street
Apt. 1216
New York=2C NY 10011<= br>
Phone: (212) 867-7179
Mobile: (917) 224-8388

 =3B
<= br>
>=3B From: ycheng@googl= e.com
>=3B Date: Sun=2C 12 Aug 2012 10:33:22 -0700
>=3B Subject: = Re: [tcpm] Reordering Time and RFC3517bis
>=3B To: tsabatini@hotmail.c= om
>=3B CC: tcpm@ietf.org
>=3B
>=3B On Sat=2C Aug 11=2C 201= 2 at 2:23 PM=2C Anthony Sabatini <=3Btsabatini@hotmail.com>=3B wrote:>=3B >=3B All -
>=3B >=3B
>=3B >=3B After reviewing thi= ngs a bit more I realize no one has given serious thought
>=3B >=3B = to Fragmentation Reassembly Timer=2C Reordering Time and the pseudo equival= ent
>=3B >=3B of three acks that is used to substitute for a more ri= gorous Reordering
>=3B >=3B Time.
>=3B >=3B
>=3B >=3B = First let us examine fragmentation reassembly timer. Since=2C as was point= ed
>=3B >=3B out=2C all fragments are generated at the same time if = we do not consider
>=3B >=3B reordering of the fragments then the ti= mer need be no greater than the
>=3B >=3B transmission delay inheren= t in the fragment length as it relates to link
>=3B >=3B speed plus = an amount for processing delay=2C relatively speaking a very small
>= =3B >=3B amount of time. Even if we include a reroute through a satellit= e link that
>=3B >=3B adds only 500 ms to the timer=2C there is NO s= cenario under which reordering
>=3B >=3B will take over two seconds = so with an abundance of caution you could set
>=3B >=3B fragment rea= ssembly time to four seconds and be done with it. Yet EVERY IP
>=3B &= gt=3B stack sets this value to above fifteen seconds (Linux is 15)=2C some = at thirty
>=3B >=3B seconds (Microsoft is 30) and the rest at SIXTY = SECONDS!! (Solaris=2C BSD).
>=3B >=3B These numbers are unsupportabl= e and make fragmentation a good attack vector
>=3B >=3B because of i= t (interesting note=2C unlike the operating system people=2C Cisco
>= =3B >=3B who has to deal with this in the real world sets the value to 5 = seconds).
>=3B >=3B
>=3B >=3B Now let us look at 3517bis. No= where is there a mention of Reordering time
>=3B >=3B yet by defini= tion it has to be considered. Indeed if we did not consider
>=3B >= =3B reordering time then we could simply queue the retransmission of a miss= ing
>=3B >=3B segment as soon as a SACK block arrives that implies t= he segment is missing.
>=3B >=3B As it is if we saved the block and = then waited an amount of time equal to
>=3B >=3B the reordering time= =2C if we did not receive an ACK or SACK covering the range
>=3B >= =3B we could and should queue it for retransmission WHETHER WE RECEIVED ANY= ACKs
>=3B >=3B OR SACKs IN THE INTERIM.
>=3B Hi Anthony=2C
= >=3B
>=3B RFC 5827 suggests a lower dupthresh and similar reorderin= g time logic in the
>=3B appendix. I implemented RFC 5827 with feature= s suggested in Appendix A.1 and A.3
>=3B in Linux 3.5. Coincidentally= the imlementation waits .25 RTT to
>=3B trigger ER as well.
>=3B=
>=3B >=3B
>=3B >=3B The problem is three ACKs is a very ver= y bad way to simulate reordering time
>=3B >=3B since on a busy link= it will trigger too early casing duplicate
>=3B >=3B transmissions = and if the link goes idle it will fire way to slowly or not at
>=3B &g= t=3B all=2C even though it could correctly have been used for retransmissio= n with
>=3B >=3B only one occurrence.
>=3B >=3B
>=3B >= =3B Also for you to think about - a Reordering time of greater than .25*RTT=
>=3B >=3B degrades the throughput of the link in direct proportion = to its value.
>=3B >=3B
>=3B >=3B .Tony
>=3B >=3B
&= gt=3B >=3B Anthony Sabatini
>=3B >=3B 200 West 20th Street
>= =3B >=3B Apt. 1216
>=3B >=3B New York=2C NY 10011
>=3B >=3B=
>=3B >=3B Phone: (212) 867-7179
>=3B >=3B Mobile: (917) 224-= 8388
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B>=3B >=3B>=3B Date: Fri=2C 3 Aug 2012 19:37:32 -0400
>=3B >= =3B>=3B From: tsabatini@hotmail.com
>=3B >=3B>=3B To: mallman@ic= ir.org
>=3B >=3B>=3B CC: tcpm@ietf.org=3B mattmathis@google.com=3B= touch@isi.edu
>=3B >=3B>=3B Subject: Re: [tcpm] Settling Time and= RFC3517bis
>=3B >=3B>=3B
>=3B >=3B>=3B All -
>=3B &= gt=3B>=3B
>=3B >=3B>=3B Because of the wording of the original c= omment it was not clear whether
>=3B >=3B>=3B the RTT referred to = the generated SACK information from the receiver or the
>=3B >=3B>= =3B original transmission from the sender. By definition=2C with respect to= the
>=3B >=3B>=3B sender=2C it is not possible to properly retran= smit the message in less than
>=3B >=3B>=3B one RTT plus Reorderin= g time plus processing time.
>=3B >=3B>=3B
>=3B >=3B>=3B = I am sorry for this misunderstanding.
>=3B >=3B>=3B
>=3B >= =3B>=3B Tony
>=3B >=3B>=3B
>=3B >=3B>=3B Sent from my A= SUS Pad
>=3B >=3B>=3B
>=3B >=3B>=3B Mark Allman <=3Bmal= lman@icir.org>=3B wrote:
>=3B >=3B>=3B
>=3B >=3B>=3B &g= t=3B
>=3B >=3B>=3B >=3BThis is all pretty mis-guided. Let me say= just a few quick things.
>=3B >=3B>=3B >=3B
>=3B >=3B>= =3B >=3B>=3B 3) STANDARD TCP can not recover in less than one RTT=2C>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BCorrect. Nor would= we want it to. If you retransmit in less than one
>=3B >=3B>=3B &= gt=3BRTT from the time a segment is originally sourced then you will always=
>=3B >=3B>=3B >=3Bbe retransmitting blind. I.e.=2C you'll have = no indication as to whether
>=3B >=3B>=3B >=3Bthat segment needs= to be retransmitted or not.
>=3B >=3B>=3B >=3B
>=3B >=3B= >=3B >=3B>=3B SACK TCP as written certainly can and does currently re= cover in
>=3B >=3B>=3B >=3B>=3B less that one RTT on at least = long links.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BInco= rrect. At least I am aware of no TCP SACK-based loss recovery
>=3B >= =3B>=3B >=3Bvariant that retransmits a segment less than one RTT after = it was
>=3B >=3B>=3B >=3Boriginally sent. You reference 3517bis = in the subject. The algorithm
>=3B >=3B>=3B >=3Bspecified in RFC= 3517 and 3517bis *does not* retransmit a segment in
>=3B >=3B>=3B= >=3Bless than one RTT.
>=3B >=3B>=3B >=3B
>=3B >=3B>= =3B >=3B>=3B With the changes I have been proposing nearly all errors c= an be
>=3B >=3B>=3B >=3B>=3B recovered in less than one RTT.>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BThe only way to r= ecover in less than one RTT is to retransmit blind.
>=3B >=3B>=3B = >=3BI.e.=2C retransmit segments without any indication as to whether they= have
>=3B >=3B>=3B >=3Barrived at the receiver or not. One coul= d write such an algorithm.
>=3B >=3B>=3B >=3BAnd=2C probably sho= w it fixes lost segments sooner. But=2C the question
>=3B >=3B>=3B= >=3Bwould immediately become "at what cost?". I.e.=2C how many needless<= br>>=3B >=3B>=3B >=3Bretransmits are being piled into the network t= o accomplish this task?
>=3B >=3B>=3B >=3BAnd=2C the answer near= ly has to be proportional to the benefit you obtain.
>=3B >=3B>=3B= >=3BI.e.=2C I bet that as you speculatively retransmit more segments you= will
>=3B >=3B>=3B >=3Balso spurious retransmit more segments.<= br>>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3BAnd=2C this is n= eedless retransmits that we know are being piled into a
>=3B >=3B>= =3B >=3Bcongested network and so are using scarce network resources. So= =2C all
>=3B >=3B>=3B >=3Baround a bad idea.
>=3B >=3B>= =3B >=3B
>=3B >=3B>=3B >=3Ballman
>=3B >=3B>=3B >= =3B
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B &= gt=3B>=3B _______________________________________________
>=3B >= =3B>=3B tcpm mailing list
>=3B >=3B>=3B tcpm@ietf.org
>=3B = >=3B>=3B https://www.ietf.org/mailman/listinfo/tcpm
>=3B >=3B>=3B >=3B _______________________________________________
>=3B &g= t=3B tcpm mailing list
>=3B >=3B tcpm@ietf.org
>=3B >=3B http= s://www.ietf.org/mailman/listinfo/tcpm
>=3B >=3B
=
= --_8f90a6fa-7129-4673-bc2f-a70b5bb2f78b_-- From mallman@icir.org Tue Aug 14 12:45:33 2012 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 26A4E21E8091 for ; Tue, 14 Aug 2012 12:45:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoKb4ktPdSZb for ; Tue, 14 Aug 2012 12:45:32 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 768D421E808E for ; Tue, 14 Aug 2012 12:45:31 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q7EJjQXW010579; Tue, 14 Aug 2012 12:45:27 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7D667283EFF1; Tue, 14 Aug 2012 15:45:26 -0400 (EDT) To: Anthony Sabatini From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Empty Sky X-URL-0: http://www.icir.org/mallman-files/Document19802.html X-URL-1: http://www.icir.org/mallman-files/Document67463.xls Date: Tue, 14 Aug 2012 15:45:26 -0400 Sender: mallman@icir.org Message-Id: <20120814194526.7D667283EFF1@lawyers.icir.org> Cc: tcpm Subject: Re: [tcpm] Reordering Time and RFC3517bis 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: Tue, 14 Aug 2012 19:45:33 -0000 Bottom line ... > so "three ACKs" is no longer a very useful measure in the real world. Show us. In other words, make your case empirically. I have looked at (ahem) a few traces in my life and read (ahem) a few papers on the subject and it seems to me the empirical evidence is that three dupacks is actually pretty useful. It provides for reasonably timely retransmission and it is generally able to disambiguate loss from reordering. If you have some empirical observation to the contrary---rather than hand waves---I think we'd all like to see it. There are known issues with three dupacks in that there are cases when you don't or can't get three dupacks back. We have dealt with that in 3517bis, in RFC 3042, in RFC 5827 and the current rtorestart is also aiming to help that situation. So, we know it isn't perfect. So, write down the problem you see, this real world evidence of the problem and your proposed solution. allman From mallman@icir.org Fri Aug 24 10:18:33 2012 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 BA85D21F85AA for ; Fri, 24 Aug 2012 10:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 DzbNu27GdejN for ; Fri, 24 Aug 2012 10:18:33 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id EBB9F21F85A4 for ; Fri, 24 Aug 2012 10:18:32 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q7OHIUKI006063; Fri, 24 Aug 2012 10:18:30 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 35E6429C4C59; Fri, 24 Aug 2012 13:18:30 -0400 (EDT) To: Pasi Sarolahti From: Mark Allman In-Reply-To: <4FB4EC54-0274-451D-99D2-ED999D2DC863@iki.fi> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: One Bourbon, One Scotch, One Beer X-URL-0: http://www.icir.org/mallman-files/Document59550.jpg X-URL-1: http://www.icir.org/mallman-files/Document48875.doc X-URL-2: http://www.icir.org/mallman-files/Document11043.html X-URL-3: http://www.icir.org/mallman-files/Document15802.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma46947-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 24 Aug 2012 13:18:30 -0400 Sender: mallman@icir.org Message-Id: <20120824171830.35E6429C4C59@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for Proportional Rate Reduction 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: Fri, 24 Aug 2012 17:18:33 -0000 ----------ma46947-1 Content-Type: text/plain Content-Disposition: inline > As discussed in the meeting last week, we will now start working group > last call for "Proportional Rate Reduction for TCP" > (draft-ietf-tcpm-proportional-rate-reduction-02), to be published as > Experimental RFC. The WGLC runs until Friday, August 24th. Please read > the draft and send comments by then. If you have read the draft and > think it is ok, notifying just that is also helpful (even without > comments). I have reviewed the draft. I have some comments. - It seems strange that the intro does not offer a sketch and critique of 3517 given that 5681, rate halving and PRR are all sketched and the natural question of "well, how does 3517 related?" comes to mind. - And, this is even more problematic when you start making comparisons to 3517 in the 5th paragraph of the intro. - In general, I think you could intuitively frame these algorithms better in non-normative words. There is clear similarities and differences in the strategies that even if there are muddled (e.g., how many segments get sent in the RTT following recovery, or whether those segments are spread out over the RTT or bunched up together, or how fast segments are sent when they are sent (as distinct from how many are sent)). - It'd be more useful to cite Van's SIGCOMM paper than to cite Van. - It struck me as odd that you noted 3517 as non-conservative. I think that is wrong. But, after reading the entire document I believe I understand what you mean. And, in fairness I must have been reading the intro too quickly because you in fact define it there, but I missed the subtle shit you have introduced. In particular, you say: [...] packet conservation principle: segments delivered to the receiver are used to as the clock to trigger sending the same number of segments back into the network. However, the SIGCOMM 88 paper is what is in my head: By `conservation of packets' we mean that for a connection `in equilibrium', i.e., running stably with a full window of data in transit, the packet flow is what a physicist would call `conservative': A new packet isn't put into the network until an old packet leaves. Being "delivered to the receiver" is only one way a packet can leave the network. RFC 3517 is packet conserving assuming (a) one admits there is another way packets can leave the network and (b) its judgment of losses is reasonable. This latter *can* be unreasonable if the path has a high degree of reordering. In this case the estimate produced by IsLost() can be wrong and RFC 3517 will in fact add packets to the network before previous versions have left the network. That said, while I know of empirical measurements that suggest one can find such paths, I know of none that shows this sort of reordering to be common. So, I think the assumption holds. And, I think RFC 3517 is packet conserving. I think at the very least you should be very clear in calling out your definition of "packet conservation" in the intro---and note that it is not the only interpretation. The document is a lot easier to understand if one has this bit in mind. Otherwise, it comes off as confused. - In definitions you should remind us of the snd.una definition since you use it in many of your definitions. - In 3.1 you should cite Limited Transmit. - There is also a 3517bis which should pop out any day now as RFC 6675. You should at least note this. And, because it is a little different than 3517 in your examples because loss recovery can now be triggered on the first dupack if there is enough SACKed data in the incoming ACK to indicate that three segments have left the network (either lost or delivered). So, e.g., in your second example the ACK of 15 would trigger the 7R burst. I don't think you need to work things in terms of RFC 6675 because your measurements are in terms of RFC 3517. But, at least a note to help folks follow the relationship seems worthwhile. - On page 8 you note that your *measurements* suggest something. But, later on it seems clear that the measurements show something. I suggest cleaning this up. - I find this business about pipe being a lousy estimate on page 10 to be pretty dubious. I understand your point that errors in the estimate are spread across the RTT. That is even nice. But, there is no evidence (provided; and I am aware of none) that pipe is in general a bad estimate. And, even if there is some reordering issues we have defined a way to get around that (RFC 4653) (which probably boils down to something like rate halving in one of the two variants). So, at least some mention of this would seem germane and I'd suggest just toning down the whole thing a bit given that there is no reason to think in most cases pipe is busted. (Or, point to evidence that says pipe is busted. But, if it is then we should also be thinking of adjusting the dupack threshold.) - In the second paragraph of section 5 you mention 'production use'. I get it after reading a couple of paragraphs ahead. You might move the notion that you ran all this in Google production servers to the front of the section. - You note that for 3517 that in 32% of the cases pipe is less than ssthresh when entering loss recovery. I assume this means the ssthresh that is set upon entering, right? You might make this more clear. So, in general I think this document is fine. It needs cleaned up, IMO. But, the mechanism is nice. I do wonder why it is going experimental. That seems too cautious to me. It seems these things are no more aggressive than 3517 and that is standards track and so why should this spin at experimental? What is the experiment here? What are we concerned about? I say let it go as standards track. allman ----------ma46947-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlA3t2UACgkQWyrrWs4yIs4hVQCbB8iBqCoowCl7PzXTOir6sE9H ROYAmQFh04ZzlKxINz70Ui5xZo7bGiQx =OGp9 -----END PGP SIGNATURE----- ----------ma46947-1-- From wwwrun@rfc-editor.org Fri Aug 24 16:33:11 2012 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 CC88D21F8533; Fri, 24 Aug 2012 16:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.004 X-Spam-Level: X-Spam-Status: No, score=-102.004 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 1BOmn5jYsXle; Fri, 24 Aug 2012 16:33:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB9D21F8530; Fri, 24 Aug 2012 16:33:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 52C88B1E00B; Fri, 24 Aug 2012 16:31:08 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120824233108.52C88B1E00B@rfc-editor.org> Date: Fri, 24 Aug 2012 16:31:08 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 6675 on A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP 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, 24 Aug 2012 23:33:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6675 Title: A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP Author: E. Blanton, M. Allman, L. Wang, I. Jarvinen, M. Kojo, Y. Nishida Status: Standards Track Stream: IETF Date: August 2012 Mailbox: elb@psg.com, mallman@icir.org, liliw@juniper.net, ilpo.jarvinen@helsinki.fi, kojo@cs.helsinki.fi, nishida@wide.ad.jp Pages: 15 Characters: 34484 Obsoletes: RFC3517 I-D Tag: draft-ietf-tcpm-3517bis-02.txt URL: http://www.rfc-editor.org/rfc/rfc6675.txt This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it. [STANDARDS-TRACK] This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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 nishida@sfc.wide.ad.jp Sat Aug 25 10:04:17 2012 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 7F29421F84F1 for ; Sat, 25 Aug 2012 10:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.727 X-Spam-Level: X-Spam-Status: No, score=-101.727 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Wl2TjUpkYBAE for ; Sat, 25 Aug 2012 10:04:17 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 048A521F84D4 for ; Sat, 25 Aug 2012 10:04:02 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 498512780CD for ; Sun, 26 Aug 2012 02:04:00 +0900 (JST) Received: by lbky2 with SMTP id y2so1016019lbk.31 for ; Sat, 25 Aug 2012 10:03:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.111.200 with SMTP id ik8mr9341662lab.15.1345914237743; Sat, 25 Aug 2012 10:03:57 -0700 (PDT) Received: by 10.112.102.106 with HTTP; Sat, 25 Aug 2012 10:03:57 -0700 (PDT) In-Reply-To: <20120824171830.35E6429C4C59@lawyers.icir.org> References: <4FB4EC54-0274-451D-99D2-ED999D2DC863@iki.fi> <20120824171830.35E6429C4C59@lawyers.icir.org> Date: Sat, 25 Aug 2012 10:03:57 -0700 Message-ID: From: Yoshifumi Nishida To: mallman@icir.org Content-Type: multipart/alternative; boundary=f46d0408913109f03e04c81a142b Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for Proportional Rate Reduction 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, 25 Aug 2012 17:04:17 -0000 --f46d0408913109f03e04c81a142b Content-Type: text/plain; charset=ISO-8859-1 Hi Mark, On Fri, Aug 24, 2012 at 10:18 AM, Mark Allman wrote: > > I do wonder why it is going experimental. That seems too cautious to > me. It seems these things are no more aggressive than 3517 and that is > standards track and so why should this spin at experimental? What is > the experiment here? What are we concerned about? I say let it go as > standards track. > > I agree with the logic appears to be conservative enough, but I'm not very sure if it's a enough reason to publish a tcp's CC logic as a standard. I'm wondering how to justify this. Thanks, -- Yoshifumi --f46d0408913109f03e04c81a142b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mark,

On Fri, Aug 24, 2012 at 10:18 AM= , Mark Allman <mallman@icir.org> wrote:

I do wonder why it is going experimental. =A0That seems too cautious to
me. =A0It seems these things are no more aggressive than 3517 and that is standards track and so why should this spin at experimental? =A0What is
the experiment here? =A0What are we concerned about? =A0I say let it go as<= br> standards track.


I agree with the logic appears to be= conservative enough, but I'm not very sure if it's a enough reason= to publish a tcp's CC logic as a standard.
I'm wondering how to= justify this.

Thanks,
--
Yoshifumi

--f46d0408913109f03e04c81a142b-- From eblanton@cs.ohiou.edu Sat Aug 25 15:26:31 2012 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 0117F21F8463 for ; Sat, 25 Aug 2012 15:26:31 -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 C8ek-H4-+w4o for ; Sat, 25 Aug 2012 15:26:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 991B921F8452 for ; Sat, 25 Aug 2012 15:26:29 -0700 (PDT) Received: from 99-52-196-7.lightspeed.crmlin.sbcglobal.net ([99.52.196.7] helo=mail.kb8ojh.net) by psg.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T5OoE-00061a-Nh; Sat, 25 Aug 2012 22:26:27 +0000 Received: by mail.kb8ojh.net (Postfix, from userid 1000) id 3B66931BAF; Sat, 25 Aug 2012 18:26:37 -0400 (EDT) Date: Sat, 25 Aug 2012 18:26:37 -0400 From: Ethan Blanton To: Yoshifumi Nishida Message-ID: <20120825222637.GA5194@mail.kb8ojh.net> Mail-Followup-To: Yoshifumi Nishida , mallman@icir.org, tcpm@ietf.org References: <4FB4EC54-0274-451D-99D2-ED999D2DC863@iki.fi> <20120824171830.35E6429C4C59@lawyers.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" 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, mallman@icir.org Subject: Re: [tcpm] WGLC for Proportional Rate Reduction 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, 25 Aug 2012 22:26:31 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Yoshifumi Nishida spake unto us the following wisdom: > > I do wonder why it is going experimental. That seems too cautious to > > me. It seems these things are no more aggressive than 3517 and that is > > standards track and so why should this spin at experimental? What is > > the experiment here? What are we concerned about? I say let it go as > > standards track. > > I agree with the logic appears to be conservative enough, but I'm not very > sure if it's a enough reason to publish a tcp's CC logic as a standard. > I'm wondering how to justify this. As I read 5681, any scheme which is at least as conservative as 5681 is implicitly allowable. I have no problem, in general, with allowing any behavior at least as conservative as a standards track algorithm to go standards track; this suggests that any penalty paid for using the algorithm will be paid by the host using the algorithm, which seems OK to me. As Mark asks, what is the experiment? If WG consensus is that an algorithm is OK out in the wild, standards track is the right target. (Disclaimer: I haven't yet read the draft.) Ethan --8t9RHnE3ZwKMSgU+ 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) iQEVAwUBUDlRHf8fixZ3H8crAQj4pwgAtNaQ42uyVUd66vvMH+yIsMGSKEbe0ynH KHiPbs8u8R4JAgLyttm7uaG4eNsV5RXBzWabmu/YFkE0FuELGRwIv8B1l/ZS04ma GnmnKnCyXpOwGz5VqZsNyierr2RD/+0i5+0FhhF0dV0wfxRfhk16Ip7qbib1714Z D++qaZjVLts5jf/eiR3+dsQCVqCJ+XqhxDx9B9JJYxxaMo/7h/aAc7UhybjTayr8 zURuKkYavZ7I1lDzSOzHTLwJowdbtxOA64Ncp3Uc1X/aDeeM+S3Mvf9W9wzLmldF vFN9yJiC0AURv4Zzf7ZsFYpih3Op7bGGfIAa58dZkJ3xeeFqXspJUw== =YJ6s -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From pasi.sarolahti@iki.fi Sun Aug 26 13:02:36 2012 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 7973521F8516 for ; Sun, 26 Aug 2012 13:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 DfqGrLbTCfI5 for ; Sun, 26 Aug 2012 13:02:35 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5292A21F84FB for ; Sun, 26 Aug 2012 13:02:35 -0700 (PDT) Received: from [192.168.1.65] (80.223.92.46) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 502B83D800A200A1; Sun, 26 Aug 2012 23:02:32 +0300 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Pasi Sarolahti In-Reply-To: <20120824171830.35E6429C4C59@lawyers.icir.org> Date: Sun, 26 Aug 2012 23:02:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <59C900CC-E746-4F54-AF2E-12B12D940D3B@iki.fi> References: <20120824171830.35E6429C4C59@lawyers.icir.org> To: X-Mailer: Apple Mail (2.1278) Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for Proportional Rate Reduction 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: Sun, 26 Aug 2012 20:02:36 -0000 Hi Mark, Thanks for the detailed review. On Aug 24, 2012, at 8:18 PM, Mark Allman wrote: > I do wonder why it is going experimental. That seems too cautious to > me. It seems these things are no more aggressive than 3517 and that = is > standards track and so why should this spin at experimental? What is > the experiment here? What are we concerned about? I say let it go as > standards track. Fair questions. I checked the minutes from IETF-81, where this was = adopted specifically as experimental according to the minutes. I wasn't = there at the time, so I don't know if the PS vs. Exp issue was discussed = at all, but no one seems to have questioned the experimental status = until now. I wonder about the process issues related to changing the status at this = point. People who have read the draft earlier may have done so with the = mindset of evaluating an experimental document. If we wanted to change = the intended status now, we might need a separate consensus call to = verify that the rough consensus supports it. - Pasi From michawe@ifi.uio.no Sun Aug 26 13:22:33 2012 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 0FBDD21F8534 for ; Sun, 26 Aug 2012 13:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.904 X-Spam-Level: X-Spam-Status: No, score=-101.904 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, PLING_QUERY=1.39, 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 0xiGZmO3vYY2 for ; Sun, 26 Aug 2012 13:22:31 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEC721F8513 for ; Sun, 26 Aug 2012 13:22:31 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1T5jLq-0000Pf-29 for tcpm@ietf.org; Sun, 26 Aug 2012 22:22:30 +0200 Received: from 108.134.189.109.customer.cdi.no ([109.189.134.108] helo=[192.168.0.197]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1T5jLp-0005tP-Si for tcpm@ietf.org; Sun, 26 Aug 2012 22:22:30 +0200 Message-Id: <100D9095-9BAC-4947-A9FC-F8CCD24EB011@ifi.uio.no> From: Michael Welzl To: tcpm Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 26 Aug 2012 22:22:29 +0200 X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 4 sum rcpts/h 6 sum msgs/h 5 total rcpts 23035 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.2, required=5.0, autolearn=disabled, PLING_QUERY=0.774, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9D38A1D3BAE816B6F33F2F05F03363AF913D52D9 X-UiO-SPAM-Test: remote_host: 109.189.134.108 spam_score: -41 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 1242 max/h 15 blacklist 0 greylist 0 ratelimit 0 Subject: [tcpm] Ants doing slow start and stuff?! 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: Sun, 26 Aug 2012 20:22:33 -0000 I just had to share this, it's cool: http://engineering.stanford.edu/news/stanford-biologist-computer-scientist-discover-anternet Cheers Michael From michael.scharf@alcatel-lucent.com Sun Aug 26 13:32:10 2012 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 9675E21F8523 for ; Sun, 26 Aug 2012 13:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.778 X-Spam-Level: X-Spam-Status: No, score=-9.778 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 AsXoVfUz1tIx for ; Sun, 26 Aug 2012 13:32:07 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id D8B6E21F853B for ; Sun, 26 Aug 2012 13:32:06 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7QKVxTT009798 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 26 Aug 2012 22:31:59 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sun, 26 Aug 2012 22:31:59 +0200 From: "Scharf, Michael (Michael)" To: Pasi Sarolahti , "mallman@icir.org" Date: Sun, 26 Aug 2012 22:31:57 +0200 Thread-Topic: [tcpm] WGLC for Proportional Rate Reduction Thread-Index: Ac2DxeksFfjLGl+0Q6GhBNoXIFnBFwAA44Hg Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891AAE3D69@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20120824171830.35E6429C4C59@lawyers.icir.org> <59C900CC-E746-4F54-AF2E-12B12D940D3B@iki.fi> In-Reply-To: <59C900CC-E746-4F54-AF2E-12B12D940D3B@iki.fi> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WGLC for Proportional Rate Reduction 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: Sun, 26 Aug 2012 20:32:10 -0000 > > I do wonder why it is going experimental. That seems too=20 > cautious to=20 > > me. It seems these things are no more aggressive than 3517=20 > and that=20 > > is standards track and so why should this spin at=20 > experimental? What=20 > > is the experiment here? What are we concerned about? I=20 > say let it go=20 > > as standards track. >=20 > Fair questions. I checked the minutes from IETF-81, where=20 > this was adopted specifically as experimental according to=20 > the minutes. I wasn't there at the time, so I don't know if=20 > the PS vs. Exp issue was discussed at all, but no one seems=20 > to have questioned the experimental status until now. I don't recall any discussion on a status other than experimental. =20 > I wonder about the process issues related to changing the=20 > status at this point. People who have read the draft earlier=20 > may have done so with the mindset of evaluating an=20 > experimental document. If we wanted to change the intended=20 > status now, we might need a separate consensus call to verify=20 > that the rough consensus supports it. Yes, I think that this would require more feedback from the community. Michael= From michawe@ifi.uio.no Sun Aug 26 13:49:58 2012 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 0D13721F8523 for ; Sun, 26 Aug 2012 13:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 NTwThKgEF2TU for ; Sun, 26 Aug 2012 13:49:57 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2E321F84F1 for ; Sun, 26 Aug 2012 13:49:57 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1T5jmN-0000nd-EM; Sun, 26 Aug 2012 22:49:55 +0200 Received: from 108.134.189.109.customer.cdi.no ([109.189.134.108] helo=[192.168.0.197]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1T5jmN-00059x-05; Sun, 26 Aug 2012 22:49:55 +0200 Message-Id: <692171E1-7AFB-4B95-A1C0-BDF1746756A1@ifi.uio.no> From: Michael Welzl To: "Scharf, Michael (Michael)" In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E891AAE3D69@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.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, 26 Aug 2012 22:49:31 +0200 References: <20120824171830.35E6429C4C59@lawyers.icir.org> <59C900CC-E746-4F54-AF2E-12B12D940D3B@iki.fi> <2A886F9088894347A3BE0CC5B7A85F3E891AAE3D69@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> X-Mailer: Apple Mail (2.936) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 5 sum rcpts/h 10 sum msgs/h 6 total rcpts 23039 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 13E4B9A8D9038B441188DCF6595EE0306200DAC5 X-UiO-SPAM-Test: remote_host: 109.189.134.108 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 1243 max/h 15 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] WGLC for Proportional Rate Reduction 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: Sun, 26 Aug 2012 20:49:58 -0000 On Aug 26, 2012, at 10:31 PM, Scharf, Michael (Michael) wrote: >>> I do wonder why it is going experimental. That seems too >> cautious to >>> me. It seems these things are no more aggressive than 3517 >> and that >>> is standards track and so why should this spin at >> experimental? What >>> is the experiment here? What are we concerned about? I >> say let it go >>> as standards track. >> >> Fair questions. I checked the minutes from IETF-81, where >> this was adopted specifically as experimental according to >> the minutes. I wasn't there at the time, so I don't know if >> the PS vs. Exp issue was discussed at all, but no one seems >> to have questioned the experimental status until now. > > I don't recall any discussion on a status other than experimental. > >> I wonder about the process issues related to changing the >> status at this point. People who have read the draft earlier >> may have done so with the mindset of evaluating an >> experimental document. If we wanted to change the intended >> status now, we might need a separate consensus call to verify >> that the rough consensus supports it. > > Yes, I think that this would require more feedback from the community. I read it, with experimental in mind, but I'd support seeing this on standards track. I agree with Mark's points. Cheers, Michael From mallman@icir.org Mon Aug 27 07:42:06 2012 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 1D84821F86C2 for ; Mon, 27 Aug 2012 07:42:06 -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 erboK4wPafvl for ; Mon, 27 Aug 2012 07:42:05 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0BED921F86C6 for ; Mon, 27 Aug 2012 07:42:05 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q7REg09n023208; Mon, 27 Aug 2012 07:42:00 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 07F8729F0A04; Mon, 27 Aug 2012 10:42:00 -0400 (EDT) To: Yoshifumi Nishida From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Not Fade Away X-URL-0: http://www.icir.org/mallman-files/Document46205.pdf X-URL-1: http://www.icir.org/mallman-files/Document55271.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma34613-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 27 Aug 2012 10:42:00 -0400 Sender: mallman@icir.org Message-Id: <20120827144200.07F8729F0A04@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for Proportional Rate Reduction 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, 27 Aug 2012 14:42:06 -0000 ----------ma34613-1 Content-Type: text/plain Content-Disposition: inline > > I do wonder why it is going experimental. That seems too cautious > > to me. It seems these things are no more aggressive than 3517 and > > that is standards track and so why should this spin at experimental? > > What is the experiment here? What are we concerned about? I say > > let it go as standards track. > > I agree with the logic appears to be conservative enough, but I'm not > very sure if it's a enough reason to publish a tcp's CC logic as a > standard. I'm wondering how to justify this. It sounds to me like this path to experimental was chosen by default. I.e., without thinking about status very hard we can always start at experimental. So, lets think about it for a few minutes. I can argue both ways on technical grounds. On the one hand, PRR does not set the amount of transmission rate reduction, it merely sets the sending pattern based on an externally provided reduction. So, if the algorithm is fed a reduction of 50% (a la current standard TCP) then it will send at most 50% of the previous flight size in the RTT following loss detection. This is absolutely consistent with the spirit of TCP congestion control (RFCs 2914, 5681, 3517, 6675 (== 3517bis)). This reading of things says that even if we call it 'experimental' it is consistent with the "or more conservative" notions allowed by the various RFCs and so PRR is implicitly allowed as standards track regardless of what label you put on it. So, we might as well label it accurately. On the other hand, one could argue that the *pattern* of sending is different under PRR and hence this makes it different enough as to not be covered under the argument above. PRR is at once more conservative and more aggressive than current standards track schemes (a point which could be better made in the PRR document, IMHO). Consider the first example in the draft whereby all schemes send the same number of packets. PRR is more conservative in the rate it sends those packets into the network. The rate is roughly half that before loss detection. However, PRR is also more aggressive in that it starts this sending right away whereas 3517(bis) leaves the network idle for a bit (1/2 RTT) before sending. So, we could view PRR as more aggressive in that it sends sooner. So, I think one can argue either side here. My own hit is that the first order is the reduction factor (half for PRR just as for earlier standard CC schemes) and the second order is the pattern. The pattern might be important in some cases and PRR might be a better pattern than 3517 or rate halving. But, ultimately for safety I think the magnitude of the MD is the important thing. So, of the two arguments above, I buy the first---i.e., that PRR is consistent with the standards and so using it could not be called non-standard and so we should just label it accurately as standards track. allman ----------ma34613-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlA7hzcACgkQWyrrWs4yIs7lcQCePZ7RkfjSXPQPuS13ixFEL85S AEQAn3J1Gwqe64o/b941QCbIhWsVOhfo =1MOn -----END PGP SIGNATURE----- ----------ma34613-1-- From mallman@icir.org Mon Aug 27 07:43:21 2012 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 7707221F8487 for ; Mon, 27 Aug 2012 07:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 cPK7JT9Qz37W for ; Mon, 27 Aug 2012 07:43:21 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id F257221F847F for ; Mon, 27 Aug 2012 07:43:20 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q7REhDpK023414; Mon, 27 Aug 2012 07:43:13 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6624729F0A77; Mon, 27 Aug 2012 10:43:13 -0400 (EDT) To: Pasi Sarolahti From: Mark Allman In-Reply-To: <59C900CC-E746-4F54-AF2E-12B12D940D3B@iki.fi> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Not Fade Away X-URL-0: http://www.icir.org/mallman-files/Document97697.doc MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma34689-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 27 Aug 2012 10:43:13 -0400 Sender: mallman@icir.org Message-Id: <20120827144313.6624729F0A77@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for Proportional Rate Reduction 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, 27 Aug 2012 14:43:21 -0000 ----------ma34689-1 Content-Type: text/plain Content-Disposition: inline > I wonder about the process issues related to changing the status at > this point. The process is that y'all say someone has suggested the status should be standards track and you want to know what the WG thinks of that. This document has not left the WG. I have not seen any declaration that it passed WGLC. It is within this WG's purview to consider this question. allman ----------ma34689-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlA7h4EACgkQWyrrWs4yIs6QZQCeM+n1uiB4sKUquVijvZLl5iUm WSYAoJ3mN91vFqifw3oIZ5iEHJW5pnRE =o/5C -----END PGP SIGNATURE----- ----------ma34689-1-- From wes@mti-systems.com Mon Aug 27 10:47:46 2012 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 3DB4021F8534 for ; Mon, 27 Aug 2012 10:47: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 Nf9wF51gPnfl for ; Mon, 27 Aug 2012 10:47:39 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id A1FBA21F852E for ; Mon, 27 Aug 2012 10:47:38 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7RHlbcl024503 for ; Mon, 27 Aug 2012 13:47:37 -0400 Authentication-Results: cm-omr7 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.46.175.71] ([107.46.175.71:61479] helo=[192.168.43.65]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D3/EF-21064-8B2BB305; Mon, 27 Aug 2012 13:47:37 -0400 Message-ID: <503BB2B6.7050306@mti-systems.com> Date: Mon, 27 Aug 2012 13:47:34 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mallman@icir.org References: <20120827144313.6624729F0A77@lawyers.icir.org> In-Reply-To: <20120827144313.6624729F0A77@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for Proportional Rate Reduction 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, 27 Aug 2012 17:47:46 -0000 On 8/27/2012 10:43 AM, Mark Allman wrote: > >> I wonder about the process issues related to changing the status at >> this point. > > The process is that y'all say someone has suggested the status should be > standards track and you want to know what the WG thinks of that. This > document has not left the WG. I have not seen any declaration that it > passed WGLC. It is within this WG's purview to consider this question. As AD, that's correct :). Personally, I wouldn't have any real problem with PS based on what's known at this point. -- Wes Eddy MTI Systems From pasi.sarolahti@iki.fi Mon Aug 27 11:27:57 2012 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 BEA8221F846D for ; Mon, 27 Aug 2012 11:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 6N+EMg2vgcK5 for ; Mon, 27 Aug 2012 11:27:57 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0A12521F846C for ; Mon, 27 Aug 2012 11:27:56 -0700 (PDT) Received: from [192.168.1.65] (80.223.92.46) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 502B83D800B0C002; Mon, 27 Aug 2012 21:27:53 +0300 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Pasi Sarolahti In-Reply-To: <20120827144313.6624729F0A77@lawyers.icir.org> Date: Mon, 27 Aug 2012 21:27:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120827144313.6624729F0A77@lawyers.icir.org> To: X-Mailer: Apple Mail (2.1278) Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for Proportional Rate Reduction 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, 27 Aug 2012 18:27:57 -0000 On Aug 27, 2012, at 5:43 PM, Mark Allman wrote: >> I wonder about the process issues related to changing the status at >> this point. >=20 > The process is that y'all say someone has suggested the status should = be > standards track and you want to know what the WG thinks of that. This > document has not left the WG. I have not seen any declaration that it > passed WGLC. It is within this WG's purview to consider this = question. Yep. That said, I hope more people can voice their opinions on this. One question, though: the document gives two variants of the algorithm. = If we go for standards track, wouldn't it be better to clearly recommend = one of them? The current advise in conclusions: "At this time we see no reason not to test and deploy PRR-SSRB on a large scale. Implementers worried about any potential impact of raising the window during recovery may want to optionally support PRR-CRB (which is actually simpler to implement) for comparison studies." sounds like there is something to be tested still. - Pasi From mattmathis@google.com Mon Aug 27 12:16:14 2012 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 398DD21F8516 for ; Mon, 27 Aug 2012 12:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 KlQS5ub6RH4x for ; Mon, 27 Aug 2012 12:16:13 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3D82121F8514 for ; Mon, 27 Aug 2012 12:16:13 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so5744643wib.1 for ; Mon, 27 Aug 2012 12:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=R2wZvNQH2SflcGDmxhfz9/12S0y/rj7V2gbmTYQvN8E=; b=N2drAwjTtRPFP6f7K2tY3n0R5c/8tR2fPjDIBFCbU9zDDvxMSzBJVU4WcdynWomoK+ BJ1rSO5Yqvt6VMXBqA8RbbfafbzkUTPtLS9BmOievlM5dK4i1pNuVF1SzKBIWtRgnkRS FNij2bzwrarNpInmstP1kgeShjNCpD+Xb1Kywc++JxTCf+LywkwZ8thEgizY2YAg2uDq h6p4EHLPWJzCuzG000Jn1xmgQ4gKmiK0EmED7NxSccY93mZGfxAlQc6N0bgUBwkrBbiW 1MWiF01Sn78+1PxCRdl5I261ExNVaXbbCi6guh/4qQFTeFm8Y5cVmZztzHXirHQrYfT3 hslw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=R2wZvNQH2SflcGDmxhfz9/12S0y/rj7V2gbmTYQvN8E=; b=QlAtTwfSjtik8zTF9LoUxBeQn3XuXO7AqUJdvDTMBNt9D1mLC7XEAWSR2WPYqoI8Bj yb/fHbSWahOpLLJ3TwGQghEfhBPdegsFD1/odxZK6lAWYX4e9yFS3mJk1oX1K3xf5U7V fKqS/LHJePd/Y3+fRrJNwvv0tP1p2r2EqEi4sBt2TcuaBgMO0eLv/X97FqB1/Dwl7rKE E/RCUlzL0kaL8YBrMhEAhUThm6nzhbIL/Jps1vACM+5qf2mskD8MdTLHFUgaRRQ08FQP gb/Wq4jdI98z8TwJnreWo07tqR+Zc1GXfqfuDV446JDudBdcA28E0Ln9wzuwqRdJ4J1q Sy/w== Received: by 10.216.131.204 with SMTP id m54mr7195872wei.93.1346094972197; Mon, 27 Aug 2012 12:16:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.131.204 with SMTP id m54mr7195859wei.93.1346094971947; Mon, 27 Aug 2012 12:16:11 -0700 (PDT) Received: by 10.217.0.9 with HTTP; Mon, 27 Aug 2012 12:16:11 -0700 (PDT) In-Reply-To: <20120827144313.6624729F0A77@lawyers.icir.org> References: <59C900CC-E746-4F54-AF2E-12B12D940D3B@iki.fi> <20120827144313.6624729F0A77@lawyers.icir.org> Date: Mon, 27 Aug 2012 12:16:11 -0700 Message-ID: From: Matt Mathis To: "mallman@icir.org. Pasi Sarolahti" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkjJs9bTuBf9RtPS8r3o2qJ9RuVR9Wnvej944cjBiES/LlNKrE7ESp/VtK426fGWBigjFuEBiMRWW7j3nC+NMykgFGBsuXA60ibxgJmzHL6iJjLY17JsPBSVSsiIPL0/LD6YRYza1RCcqbuYlTYmS78FRlGm4TfhjEplHpCe4fm+ZV/gxFphnpfN0UuwUnXQ4chcq7S Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for Proportional Rate Reduction 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, 27 Aug 2012 19:16:14 -0000 Sorry for the long radio silence here. The only reason to bother with standards track is if there is a need to compel reluctant manufacturers to implement and deploy it. Customers can then write in their requests for quotes specifications such as "must support SACK (RFC 2018), and then suddenly the lack of SACK support becomes a high priority issue for some large manufacture who shall remain nameless. Back in the old days (before 1990) RFC meant "request for comments" and there was no such concept as "standards track". We wrote down our ideas, and if they were valuable, they became part of the installed base. For PRR this has already come to pass for the installed base that is most important to me. If management at Apple or Microsoft think PRR isn't worth the effort, then making PRR a standard will permit their customers to influence their priorities. Given the extent to which PRR is an across the board win, I really don't think this is required. (However, I could change my mind if a TCP engineer at one of the above companies indicate that they are getting pushback from their management.) Finally there are some details in PRR that are effected by Laminar. I would rather not go to the effort of fixing the current draft to make it a proper normative PS, but not totally correct. (Hint: Yoshifumi Nishida's "off by one" comment reflects the difference between pipe and total_pipe). So here is what I was planning to do: Push out the current document as experimental, and then after Laminar is further along, generate a normative respecification using Laminar state variables (probably as one section of a larger doc, but that remains TBD). Does that make sense? Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Mon, Aug 27, 2012 at 7:43 AM, Mark Allman wrote: > >> I wonder about the process issues related to changing the status at >> this point. > > The process is that y'all say someone has suggested the status should be > standards track and you want to know what the WG thinks of that. This > document has not left the WG. I have not seen any declaration that it > passed WGLC. It is within this WG's purview to consider this question. > > allman > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From mallman@icir.org Mon Aug 27 12:18:04 2012 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 DDE1721F852C for ; Mon, 27 Aug 2012 12:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 OBGTCWjVlLfm for ; Mon, 27 Aug 2012 12:18:04 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD7A21F844B for ; Mon, 27 Aug 2012 12:18:04 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q7RJI3nh024493; Mon, 27 Aug 2012 12:18:03 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id CBF9D2A17058; Mon, 27 Aug 2012 15:18:02 -0400 (EDT) To: Pasi Sarolahti From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Not Fade Away X-URL-0: http://www.icir.org/mallman-files/Document4545.doc X-URL-1: http://www.icir.org/mallman-files/Document13124.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma51175-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 27 Aug 2012 15:18:02 -0400 Sender: mallman@icir.org Message-Id: <20120827191802.CBF9D2A17058@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for Proportional Rate Reduction 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, 27 Aug 2012 19:18:05 -0000 ----------ma51175-1 Content-Type: text/plain Content-Disposition: inline > >> I wonder about the process issues related to changing the status at > >> this point. > > > > The process is that y'all say someone has suggested the status should be > > standards track and you want to know what the WG thinks of that. This > > document has not left the WG. I have not seen any declaration that it > > passed WGLC. It is within this WG's purview to consider this question. > > Yep. That said, I hope more people can voice their opinions on this. Agreed. > One question, though: the document gives two variants of the > algorithm. If we go for standards track, wouldn't it be better to > clearly recommend one of them? The current advise in conclusions: > > "At this time we see no reason not to test and deploy PRR-SSRB on a > large scale. Implementers worried about any potential impact of > raising the window during recovery may want to optionally support > PRR-CRB (which is actually simpler to implement) for comparison > studies." > > sounds like there is something to be tested still. I don't think the question should be: Is there anything more to learn? If that was the question we'd spin everything at experimental forever. Both variants are at most as conservative as current standards. There is a fine tradition in any number of the TCP docs of giving implementers choices. I view this document as doing just that. And, in this case, both choices are conservative in my view. allman ----------ma51175-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlA7x+oACgkQWyrrWs4yIs4kfQCgigT6/cLJwb+EyWUoMHQ24fvf R28AnRaSvfk5n6jPbpBLv3teMN0qqAUw =XGfe -----END PGP SIGNATURE----- ----------ma51175-1-- From michael.scharf@alcatel-lucent.com Tue Aug 28 00:27:17 2012 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 82F2B21F84C2 for ; Tue, 28 Aug 2012 00:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.805 X-Spam-Level: X-Spam-Status: No, score=-9.805 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 zYWcprVby6zQ for ; Tue, 28 Aug 2012 00:27:16 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 63B8021F84B3 for ; Tue, 28 Aug 2012 00:27:16 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7S7LrjA027987 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 28 Aug 2012 09:27:11 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 28 Aug 2012 09:27:08 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Tue, 28 Aug 2012 09:27:06 +0200 Thread-Topic: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback Thread-Index: Ac1zRTdUQ0GSXUdNTf+oTvpqOMOz3wRqKoUg Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891AAE3DB9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120803012830.GC59530@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E39FE@SACEXCMBX02-PRD.hq.netapp.com> <20120803183421.GB15012@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E4381@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 28 Aug 2012 07:27:17 -0000 So, let's discuss wordsmithing. What about simply saying "more detailed"? "Sep 2013 Submit document on more detailed ECN feedback in TCP to the IES= G for publication as an Experimental RFC" Comments are welcome. Michael > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Matt Mathis > Sent: Sunday, August 05, 2012 10:02 PM > To: Scheffenegger, Richard > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Consenus on adding a new TCPM charter=20 > milestone for accurate feedback >=20 > I agree that "accurate" is a little bit too strong of term. =20 > Perhaps "counted", "proportional", "quantified", "measured", etc. >=20 > And yes, TCPM is probably the right place, since all CC=20 > standards track docs are explicitly in scope, even as applied=20 > to other protocols. >=20 > If we separate signalling from action, some proposed actions clearly > need to mature in ICCRG for a bit. Here is a tough question though: > does the choice of alternate actions effect the design of the=20 > signalling? If so, it may be premature to commit on the signalling. > (e.g. for low threshold ECN (aka DCTCP) isolated ECN marks=20 > would be extremely unlikely and it would probably be ok to=20 > miss a few.), >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 >=20 > On Fri, Aug 3, 2012 at 1:58 PM, Scheffenegger, Richard=20 > wrote: > > > > Hi John, > > > > > > Thanks for your comments so far! > > > >> > I would argue that the current ECE/CWR mechanism is perfectly=20 > >> > reliable > >> > >> I might take the other side of that argument... > > > > Could you please explain? (I should have perhaps added,=20 > RFC3168 is perfectly reliable for at least, and up to, one CE=20 > mark per RTT; The sender gets the information that at least=20 > one CE mark was received in the RTT under all circumstances). > > > > > >> Actually, there are two counters, packets and (payload) bytes. > > > > Correct; but as soon as not every data segment is ACKed=20 > (and the ACK not lost), the delineation (for figuring out=20 > which payload bytes got marked) becomes fuzzy... Even when=20 > the sender keeps state as to the segment boundaries, it's not=20 > clear which of multiple segments were marked (except in the=20 > two extreme cases), when delayed ACKs (or even ACK=20 > compression) are in play... > > > > Which brings up another question that I haven't put in this forum: > > > > Will there be a conceivable benefit when the sender knows=20 > the exact order or markings? > > > > The way the receiver ECN state-machine of DCTCP is=20 > described allows the sender to reconstruct the exact order of=20 > markings (the "CE stream"), provided no (relevant) ACKs are=20 > lost. With the complication that the sender rarely knows,=20 > when and if a relevant ACK got dropped... > > > > This level of precision is lost, when the receiver uses=20 > some kind of summary signal; But making such a signal=20 > reliable requires even more bits, and some more or less=20 > complex encoding scheme... > > > > > > But I am not sure if such an extreme precision will be necessary to=20 > > TCP at least (and other transports do provide means to=20 > encode that...) > > > > > > To have a proper counter (congested bytes), I think that=20 > would need to be explicit; Mirja did some experiments using=20 > implicit ACKs, but to get them work properly, you end up with=20 > sending out more ACKs than strictly necessary (like what=20 > DCTCP receivers do), and single ACK loss can still result in=20 > wrong signals at the sender.... > > > > > > > > > > Richard Scheffenegger > > > > > > > > > >> -----Original Message----- > >> From: John Leslie [mailto:john@jlc.net] > >> Sent: Freitag, 03. August 2012 11:34 > >> To: Scheffenegger, Richard > >> Cc: tcpm@ietf.org > >> Subject: Re: [tcpm] Consenus on adding a new TCPM charter=20 > milestone=20 > >> for accurate feedback > >> > >> Scheffenegger, Richard wrote: > >> > > >> > Hi John, > >> > > >> > Am I right in assuming that with "greater precision" you=20 > imply that=20 > >> > this doesn't necessarily mean "exact" feedback? > >> > >> Yes, but... This is mainly to avoid arguing what=20 > "exact" might mean. > >> > >> > (Originally we discussed using "more accurate" in the=20 > title of the=20 > >> > draft; that meant lower precision than "exact", but the=20 > "more" got=20 > >> > lost along the way, leaving "accurate"). > >> > >> (I must admit I'm at least as anxious to avoid arguing=20 > what "accurate" > >> might mean.) > >> > >> > I would argue that the current ECE/CWR mechanism is perfectly=20 > >> > reliable > >> > >> I might take the other side of that argument... > >> > >> > - up to a certain precision limited by the number of=20 > bits set aside=20 > >> > for the signal back from the receiver to the sender.=20 > What would be=20 > >> > more reliable? > >> > >> "Reliable" in TCP means that everything not=20 > acknowledged will be=20 > >> retransmitted. That would imply repeating each ECE until that=20 > >> specific ECE is acknowledged -- and clarifying to the=20 > sender how that=20 > >> CWR was understood. > >> > >> But I'm not trying to argue either way whether=20 > "reliable" would be=20 > >> "better" than "unreliable". > >> > >> > (ECE is a counter that can only increase, and remains at the=20 > >> > maximumi value until being reset; CWR provides the reset signal). > >> > >> Umm... "remains at maximum" implies some loss of precision... > >> > >> > OTOH, if the feedback signal is encoded with enough bits,=20 > >> > reliability can be brought arbitrarily close to "perfect", even=20 > >> > without an explicit forward signal (CWR). > >> > >> Indeed, one could argue "reliability" by unacknowledged=20 > repetition. > >> (I'd prefer some other term, but it certainly would serve for the=20 > >> "precision" I was seeking.) > >> > >> > As soon as the counter (and signal for it) cover all the packets=20 > >> > individually in a window, the ECN feedback can be exact; > >> > >> Actually, there are two counters, packets and (payload) bytes. > >> > >> > The question becomes, can the reset mechanism be abandoned when=20 > >> > "enough" bits are available for the signal, or must the=20 > principal=20 > >> > architecture (a counter increasing up to some point, until it is > >> > reset) be maintained... > >> > >> I don't choose to express an opinion on that yet. > >> > >> > BTW: I found that ECN for SCTP also failed to discuss this, but=20 > >> > there a 32 bit counter is used (plus a Reset signal/CWR). > >> > >> :^) > >> > >> > To jump forward a bit, I suspect the delineation is somewhere=20 > >> > around > >> > 5 bits (2.3 bits in the codepoint draft; 3 bits in=20 > reECN; 8 bits in=20 > >> > the TCP Option draft). Using 5 bits or less, a handshare=20 > mechanism=20 > >> > is required; using more than 5, and a simple counter suffices to=20 > >> > maintain exactness (until TCP suffers from loss of the=20 > ACK clock etc). > >> > >> No comment (yet)... > >> > >> > The signaling is another question; Perhaps a certain loss of=20 > >> > granularity is acceptable for the currently discussed=20 > protocols (i.e. > >> > Conex; slight overestimating congestion is not as bad as=20 > >> > underestimating). But other (future) uses (e.g. DCTCP) would=20 > >> > probably require the full precision - with other words,=20 > "exact" signaling... > >> > >> "Exact" _is_ a reasonable goal... > >> > >> > However, we (authors), while discussing this internally,=20 > would also=20 > >> > be glad of any opinion regarding this! > >> > >> I will note that current ECN processing in TCP is=20 > awfully specialized: > >> I can imagine congestion-control algorithms it would serve poorly.=20 > >> :^( But leaving that aside, ECN processing for other transport=20 > >> protocols almost certainly deserves a different treatment. > >> > >> It would be nice if our "greater precision" effort=20 > could serve the=20 > >> needs of yet-unseen future transport protocols. > >> > >> -- > >> John Leslie > > _______________________________________________ > > 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 michawe@ifi.uio.no Tue Aug 28 00:38:44 2012 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 0E59411E808D for ; Tue, 28 Aug 2012 00:38:44 -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=[AWL=0.000, 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 fbNZIz3XBpxd for ; Tue, 28 Aug 2012 00:38:43 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA7F21F84D3 for ; Tue, 28 Aug 2012 00:38:42 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1T6GNl-0002Cs-Cf for tcpm@ietf.org; Tue, 28 Aug 2012 09:38:41 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1T6GNk-0005z6-U0 for tcpm@ietf.org; Tue, 28 Aug 2012 09:38:41 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Michael Welzl In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E891AAE3DB9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Date: Tue, 28 Aug 2012 09:38:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <133A5697-A014-4287-A942-1856F12652E1@ifi.uio.no> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120803012830.GC59530@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E39FE@SACEXCMBX02-PRD.hq.netapp.com> <20120803183421.GB15012@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E4381@SACEXCMBX02-PRD.hq.netapp.com> <2A886F9088894347A3BE0CC5B7A85F3E891AAE3DB9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> To: tcpm@ietf.org X-Mailer: Apple Mail (2.1278) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 6 sum msgs/h 5 total rcpts 23088 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, RP_MATCHES_RCVD=-1.018, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5580495F8F21D0193C9AD8C916A3F1320C6B4F76 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9297 max/h 20 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 28 Aug 2012 07:38:44 -0000 I like it! Michael On 28. aug. 2012, at 09:27, Scharf, Michael (Michael) wrote: > So, let's discuss wordsmithing. What about simply saying "more = detailed"? >=20 > "Sep 2013 Submit document on more detailed ECN feedback in TCP to = the IESG for publication as an Experimental RFC" >=20 > Comments are welcome. >=20 > Michael >=20 >=20 >=20 >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 >> Behalf Of Matt Mathis >> Sent: Sunday, August 05, 2012 10:02 PM >> To: Scheffenegger, Richard >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] Consenus on adding a new TCPM charter=20 >> milestone for accurate feedback >>=20 >> I agree that "accurate" is a little bit too strong of term. =20 >> Perhaps "counted", "proportional", "quantified", "measured", etc. >>=20 >> And yes, TCPM is probably the right place, since all CC=20 >> standards track docs are explicitly in scope, even as applied=20 >> to other protocols. >>=20 >> If we separate signalling from action, some proposed actions clearly >> need to mature in ICCRG for a bit. Here is a tough question though: >> does the choice of alternate actions effect the design of the=20 >> signalling? If so, it may be premature to commit on the signalling. >> (e.g. for low threshold ECN (aka DCTCP) isolated ECN marks=20 >> would be extremely unlikely and it would probably be ok to=20 >> miss a few.), >>=20 >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >>=20 >>=20 >> On Fri, Aug 3, 2012 at 1:58 PM, Scheffenegger, Richard=20 >> wrote: >>>=20 >>> Hi John, >>>=20 >>>=20 >>> Thanks for your comments so far! >>>=20 >>>>> I would argue that the current ECE/CWR mechanism is perfectly=20 >>>>> reliable >>>>=20 >>>> I might take the other side of that argument... >>>=20 >>> Could you please explain? (I should have perhaps added,=20 >> RFC3168 is perfectly reliable for at least, and up to, one CE=20 >> mark per RTT; The sender gets the information that at least=20 >> one CE mark was received in the RTT under all circumstances). >>>=20 >>>=20 >>>> Actually, there are two counters, packets and (payload) bytes. >>>=20 >>> Correct; but as soon as not every data segment is ACKed=20 >> (and the ACK not lost), the delineation (for figuring out=20 >> which payload bytes got marked) becomes fuzzy... Even when=20 >> the sender keeps state as to the segment boundaries, it's not=20 >> clear which of multiple segments were marked (except in the=20 >> two extreme cases), when delayed ACKs (or even ACK=20 >> compression) are in play... >>>=20 >>> Which brings up another question that I haven't put in this forum: >>>=20 >>> Will there be a conceivable benefit when the sender knows=20 >> the exact order or markings? >>>=20 >>> The way the receiver ECN state-machine of DCTCP is=20 >> described allows the sender to reconstruct the exact order of=20 >> markings (the "CE stream"), provided no (relevant) ACKs are=20 >> lost. With the complication that the sender rarely knows,=20 >> when and if a relevant ACK got dropped... >>>=20 >>> This level of precision is lost, when the receiver uses=20 >> some kind of summary signal; But making such a signal=20 >> reliable requires even more bits, and some more or less=20 >> complex encoding scheme... >>>=20 >>>=20 >>> But I am not sure if such an extreme precision will be necessary to=20= >>> TCP at least (and other transports do provide means to=20 >> encode that...) >>>=20 >>>=20 >>> To have a proper counter (congested bytes), I think that=20 >> would need to be explicit; Mirja did some experiments using=20 >> implicit ACKs, but to get them work properly, you end up with=20 >> sending out more ACKs than strictly necessary (like what=20 >> DCTCP receivers do), and single ACK loss can still result in=20 >> wrong signals at the sender.... >>>=20 >>>=20 >>>=20 >>>=20 >>> Richard Scheffenegger >>>=20 >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: John Leslie [mailto:john@jlc.net] >>>> Sent: Freitag, 03. August 2012 11:34 >>>> To: Scheffenegger, Richard >>>> Cc: tcpm@ietf.org >>>> Subject: Re: [tcpm] Consenus on adding a new TCPM charter=20 >> milestone=20 >>>> for accurate feedback >>>>=20 >>>> Scheffenegger, Richard wrote: >>>>>=20 >>>>> Hi John, >>>>>=20 >>>>> Am I right in assuming that with "greater precision" you=20 >> imply that=20 >>>>> this doesn't necessarily mean "exact" feedback? >>>>=20 >>>> Yes, but... This is mainly to avoid arguing what=20 >> "exact" might mean. >>>>=20 >>>>> (Originally we discussed using "more accurate" in the=20 >> title of the=20 >>>>> draft; that meant lower precision than "exact", but the=20 >> "more" got=20 >>>>> lost along the way, leaving "accurate"). >>>>=20 >>>> (I must admit I'm at least as anxious to avoid arguing=20 >> what "accurate" >>>> might mean.) >>>>=20 >>>>> I would argue that the current ECE/CWR mechanism is perfectly=20 >>>>> reliable >>>>=20 >>>> I might take the other side of that argument... >>>>=20 >>>>> - up to a certain precision limited by the number of=20 >> bits set aside=20 >>>>> for the signal back from the receiver to the sender.=20 >> What would be=20 >>>>> more reliable? >>>>=20 >>>> "Reliable" in TCP means that everything not=20 >> acknowledged will be=20 >>>> retransmitted. That would imply repeating each ECE until that=20 >>>> specific ECE is acknowledged -- and clarifying to the=20 >> sender how that=20 >>>> CWR was understood. >>>>=20 >>>> But I'm not trying to argue either way whether=20 >> "reliable" would be=20 >>>> "better" than "unreliable". >>>>=20 >>>>> (ECE is a counter that can only increase, and remains at the=20 >>>>> maximumi value until being reset; CWR provides the reset signal). >>>>=20 >>>> Umm... "remains at maximum" implies some loss of precision... >>>>=20 >>>>> OTOH, if the feedback signal is encoded with enough bits,=20 >>>>> reliability can be brought arbitrarily close to "perfect", even=20 >>>>> without an explicit forward signal (CWR). >>>>=20 >>>> Indeed, one could argue "reliability" by unacknowledged=20 >> repetition. >>>> (I'd prefer some other term, but it certainly would serve for the=20= >>>> "precision" I was seeking.) >>>>=20 >>>>> As soon as the counter (and signal for it) cover all the packets=20= >>>>> individually in a window, the ECN feedback can be exact; >>>>=20 >>>> Actually, there are two counters, packets and (payload) bytes. >>>>=20 >>>>> The question becomes, can the reset mechanism be abandoned when=20 >>>>> "enough" bits are available for the signal, or must the=20 >> principal=20 >>>>> architecture (a counter increasing up to some point, until it is >>>>> reset) be maintained... >>>>=20 >>>> I don't choose to express an opinion on that yet. >>>>=20 >>>>> BTW: I found that ECN for SCTP also failed to discuss this, but=20 >>>>> there a 32 bit counter is used (plus a Reset signal/CWR). >>>>=20 >>>> :^) >>>>=20 >>>>> To jump forward a bit, I suspect the delineation is somewhere=20 >>>>> around >>>>> 5 bits (2.3 bits in the codepoint draft; 3 bits in=20 >> reECN; 8 bits in=20 >>>>> the TCP Option draft). Using 5 bits or less, a handshare=20 >> mechanism=20 >>>>> is required; using more than 5, and a simple counter suffices to=20= >>>>> maintain exactness (until TCP suffers from loss of the=20 >> ACK clock etc). >>>>=20 >>>> No comment (yet)... >>>>=20 >>>>> The signaling is another question; Perhaps a certain loss of=20 >>>>> granularity is acceptable for the currently discussed=20 >> protocols (i.e. >>>>> Conex; slight overestimating congestion is not as bad as=20 >>>>> underestimating). But other (future) uses (e.g. DCTCP) would=20 >>>>> probably require the full precision - with other words,=20 >> "exact" signaling... >>>>=20 >>>> "Exact" _is_ a reasonable goal... >>>>=20 >>>>> However, we (authors), while discussing this internally,=20 >> would also=20 >>>>> be glad of any opinion regarding this! >>>>=20 >>>> I will note that current ECN processing in TCP is=20 >> awfully specialized: >>>> I can imagine congestion-control algorithms it would serve poorly.=20= >>>> :^( But leaving that aside, ECN processing for other transport=20 >>>> protocols almost certainly deserves a different treatment. >>>>=20 >>>> It would be nice if our "greater precision" effort=20 >> could serve the=20 >>>> needs of yet-unseen future transport protocols. >>>>=20 >>>> -- >>>> John Leslie >>> _______________________________________________ >>> 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 >>=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From john@jlc.net Tue Aug 28 07:37:25 2012 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 2FF4021F84FE for ; Tue, 28 Aug 2012 07:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.878 X-Spam-Level: X-Spam-Status: No, score=-105.878 tagged_above=-999 required=5 tests=[AWL=0.721, 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 rD2pmBHDwe0b for ; Tue, 28 Aug 2012 07:37:24 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id BB27621F84F3 for ; Tue, 28 Aug 2012 07:37:24 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3437333C2A; Tue, 28 Aug 2012 10:37:24 -0400 (EDT) Date: Tue, 28 Aug 2012 10:37:24 -0400 From: John Leslie To: "Scharf, Michael (Michael)" Message-ID: <20120828143724.GK72831@verdi> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120803012830.GC59530@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E39FE@SACEXCMBX02-PRD.hq.netapp.com> <20120803183421.GB15012@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E4381@SACEXCMBX02-PRD.hq.netapp.com> <2A886F9088894347A3BE0CC5B7A85F3E891AAE3DB9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E891AAE3DB9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> User-Agent: Mutt/1.4.1i Cc: tcpm@ietf.org Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 28 Aug 2012 14:37:25 -0000 Scharf, Michael (Michael) wrote: > > So, let's discuss wordsmithing. What about simply saying "more detailed"? > > "Sep 2013 Submit document on more detailed ECN feedback in TCP to the IESG for publication as an Experimental RFC" Sounds better to me... -- John Leslie From ycheng@google.com Tue Aug 28 08:56:08 2012 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 3BFCB21F852C for ; Tue, 28 Aug 2012 08:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 KfURcYlTcZ3J for ; Tue, 28 Aug 2012 08:55:42 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB6E21F856F for ; Tue, 28 Aug 2012 08:55:41 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12272567obb.31 for ; Tue, 28 Aug 2012 08:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=jWJTcbl1nLYubnIzCqDX5GzeA1u0ND8PRKecWFcAYKQ=; b=TWbeMlGaB8HZVv3rUxvSXNPkMldASEHmdKkPCBVufeJ0Mn84T5kWe6cN2KDtPCy6h1 B2/h1OJhmTAJhEKdc4kb8MRp/Y3W75mbu+yqJMVUNiqgtNkEs2LfXRCLQqJXLxHJVMuz udVpNiA/1xPchVoMK5FC0FVEL6wS5o5xu3C1Z8+zNQDNA/TJ7eH5yHwpeMMy1YzhyAYR LKU2wCrAMPISmO5hlNSe3NoUauYu7qAqq5pZc5tlPd++7XhQ9vSqO1RgGptLWsX0hoEH IBCoNw3GSpRVnjVoI0PPCFa/eOj3lpivwofK5gRYwOV3W0aXbmSn3TG7MqmoLeha6fz6 HCNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=jWJTcbl1nLYubnIzCqDX5GzeA1u0ND8PRKecWFcAYKQ=; b=YH0RvCWCtjFlj9eJQUzroRaK8mpwD5UfDvzbL9kD3HOqba1pB2qsakMjU6z9vr3K/U WeFsZYvVyV1Z6icT3kQJIsx1V1aHYvhvHV7wk7PylXJpD+46d4j6nP30eNpkXHBBzQD0 njmo40Icl1rnHcP8SmuQyaRnBuY+yYGlvc9Km+qUV/eXWXI/X23rmPam4ZBZGScsQ8eW voNXROqnUmc95nApiZ/wXDjgq6bU/yItfpfeIf/EwxmKyWTcxDo4PxBpeqoa5rQxeJCi cbIP93HutIX2FHrE4iQ69rV3gPWnu8hy8pyJUeZBr3ye1MJFdx7uLi1/07MAXNe+tSO3 f1Hg== Received: by 10.182.116.2 with SMTP id js2mr12887227obb.38.1346169341076; Tue, 28 Aug 2012 08:55:41 -0700 (PDT) Received: by 10.182.116.2 with SMTP id js2mr12887217obb.38.1346169340936; Tue, 28 Aug 2012 08:55:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.62.73 with HTTP; Tue, 28 Aug 2012 08:55:20 -0700 (PDT) In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E891AAE3DB9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E891A9BBDA8@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120803012830.GC59530@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E39FE@SACEXCMBX02-PRD.hq.netapp.com> <20120803183421.GB15012@verdi> <012C3117EDDB3C4781FD802A8C27DD4F0D4E4381@SACEXCMBX02-PRD.hq.netapp.com> <2A886F9088894347A3BE0CC5B7A85F3E891AAE3DB9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Tue, 28 Aug 2012 08:55:20 -0700 Message-ID: To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnJm+iu7GLzrmbloJVA3/cRC9qgXZX8nxLzwX36NIiDJINNDIXjt4Zfen/mXh0I5iHRlM5WpnxjqWS57ropECBbsb9mYH0nY8mdCXfYPcwbmcimNXlHUDdf6Enql3HUXmQ2xpFW50Cyxyh+ecM2Ww3puq6KZt71Y78UNPXJXwmfEh/bg2jj1fD/H0DCrpJlJqypW3Bk Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Consenus on adding a new TCPM charter milestone for accurate feedback 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, 28 Aug 2012 15:56:08 -0000 On Tue, Aug 28, 2012 at 12:27 AM, Scharf, Michael (Michael) wrote: > So, let's discuss wordsmithing. What about simply saying "more detailed"? > > "Sep 2013 Submit document on more detailed ECN feedback in TCP to the IESG for publication as an Experimental RFC" +1 > > Comments are welcome. > > Michael > > > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Matt Mathis >> Sent: Sunday, August 05, 2012 10:02 PM >> To: Scheffenegger, Richard >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] Consenus on adding a new TCPM charter >> milestone for accurate feedback >> >> I agree that "accurate" is a little bit too strong of term. >> Perhaps "counted", "proportional", "quantified", "measured", etc. >> >> And yes, TCPM is probably the right place, since all CC >> standards track docs are explicitly in scope, even as applied >> to other protocols. >> >> If we separate signalling from action, some proposed actions clearly >> need to mature in ICCRG for a bit. Here is a tough question though: >> does the choice of alternate actions effect the design of the >> signalling? If so, it may be premature to commit on the signalling. >> (e.g. for low threshold ECN (aka DCTCP) isolated ECN marks >> would be extremely unlikely and it would probably be ok to >> miss a few.), >> >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >> >> >> On Fri, Aug 3, 2012 at 1:58 PM, Scheffenegger, Richard >> wrote: >> > >> > Hi John, >> > >> > >> > Thanks for your comments so far! >> > >> >> > I would argue that the current ECE/CWR mechanism is perfectly >> >> > reliable >> >> >> >> I might take the other side of that argument... >> > >> > Could you please explain? (I should have perhaps added, >> RFC3168 is perfectly reliable for at least, and up to, one CE >> mark per RTT; The sender gets the information that at least >> one CE mark was received in the RTT under all circumstances). >> > >> > >> >> Actually, there are two counters, packets and (payload) bytes. >> > >> > Correct; but as soon as not every data segment is ACKed >> (and the ACK not lost), the delineation (for figuring out >> which payload bytes got marked) becomes fuzzy... Even when >> the sender keeps state as to the segment boundaries, it's not >> clear which of multiple segments were marked (except in the >> two extreme cases), when delayed ACKs (or even ACK >> compression) are in play... >> > >> > Which brings up another question that I haven't put in this forum: >> > >> > Will there be a conceivable benefit when the sender knows >> the exact order or markings? >> > >> > The way the receiver ECN state-machine of DCTCP is >> described allows the sender to reconstruct the exact order of >> markings (the "CE stream"), provided no (relevant) ACKs are >> lost. With the complication that the sender rarely knows, >> when and if a relevant ACK got dropped... >> > >> > This level of precision is lost, when the receiver uses >> some kind of summary signal; But making such a signal >> reliable requires even more bits, and some more or less >> complex encoding scheme... >> > >> > >> > But I am not sure if such an extreme precision will be necessary to >> > TCP at least (and other transports do provide means to >> encode that...) >> > >> > >> > To have a proper counter (congested bytes), I think that >> would need to be explicit; Mirja did some experiments using >> implicit ACKs, but to get them work properly, you end up with >> sending out more ACKs than strictly necessary (like what >> DCTCP receivers do), and single ACK loss can still result in >> wrong signals at the sender.... >> > >> > >> > >> > >> > Richard Scheffenegger >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: John Leslie [mailto:john@jlc.net] >> >> Sent: Freitag, 03. August 2012 11:34 >> >> To: Scheffenegger, Richard >> >> Cc: tcpm@ietf.org >> >> Subject: Re: [tcpm] Consenus on adding a new TCPM charter >> milestone >> >> for accurate feedback >> >> >> >> Scheffenegger, Richard wrote: >> >> > >> >> > Hi John, >> >> > >> >> > Am I right in assuming that with "greater precision" you >> imply that >> >> > this doesn't necessarily mean "exact" feedback? >> >> >> >> Yes, but... This is mainly to avoid arguing what >> "exact" might mean. >> >> >> >> > (Originally we discussed using "more accurate" in the >> title of the >> >> > draft; that meant lower precision than "exact", but the >> "more" got >> >> > lost along the way, leaving "accurate"). >> >> >> >> (I must admit I'm at least as anxious to avoid arguing >> what "accurate" >> >> might mean.) >> >> >> >> > I would argue that the current ECE/CWR mechanism is perfectly >> >> > reliable >> >> >> >> I might take the other side of that argument... >> >> >> >> > - up to a certain precision limited by the number of >> bits set aside >> >> > for the signal back from the receiver to the sender. >> What would be >> >> > more reliable? >> >> >> >> "Reliable" in TCP means that everything not >> acknowledged will be >> >> retransmitted. That would imply repeating each ECE until that >> >> specific ECE is acknowledged -- and clarifying to the >> sender how that >> >> CWR was understood. >> >> >> >> But I'm not trying to argue either way whether >> "reliable" would be >> >> "better" than "unreliable". >> >> >> >> > (ECE is a counter that can only increase, and remains at the >> >> > maximumi value until being reset; CWR provides the reset signal). >> >> >> >> Umm... "remains at maximum" implies some loss of precision... >> >> >> >> > OTOH, if the feedback signal is encoded with enough bits, >> >> > reliability can be brought arbitrarily close to "perfect", even >> >> > without an explicit forward signal (CWR). >> >> >> >> Indeed, one could argue "reliability" by unacknowledged >> repetition. >> >> (I'd prefer some other term, but it certainly would serve for the >> >> "precision" I was seeking.) >> >> >> >> > As soon as the counter (and signal for it) cover all the packets >> >> > individually in a window, the ECN feedback can be exact; >> >> >> >> Actually, there are two counters, packets and (payload) bytes. >> >> >> >> > The question becomes, can the reset mechanism be abandoned when >> >> > "enough" bits are available for the signal, or must the >> principal >> >> > architecture (a counter increasing up to some point, until it is >> >> > reset) be maintained... >> >> >> >> I don't choose to express an opinion on that yet. >> >> >> >> > BTW: I found that ECN for SCTP also failed to discuss this, but >> >> > there a 32 bit counter is used (plus a Reset signal/CWR). >> >> >> >> :^) >> >> >> >> > To jump forward a bit, I suspect the delineation is somewhere >> >> > around >> >> > 5 bits (2.3 bits in the codepoint draft; 3 bits in >> reECN; 8 bits in >> >> > the TCP Option draft). Using 5 bits or less, a handshare >> mechanism >> >> > is required; using more than 5, and a simple counter suffices to >> >> > maintain exactness (until TCP suffers from loss of the >> ACK clock etc). >> >> >> >> No comment (yet)... >> >> >> >> > The signaling is another question; Perhaps a certain loss of >> >> > granularity is acceptable for the currently discussed >> protocols (i.e. >> >> > Conex; slight overestimating congestion is not as bad as >> >> > underestimating). But other (future) uses (e.g. DCTCP) would >> >> > probably require the full precision - with other words, >> "exact" signaling... >> >> >> >> "Exact" _is_ a reasonable goal... >> >> >> >> > However, we (authors), while discussing this internally, >> would also >> >> > be glad of any opinion regarding this! >> >> >> >> I will note that current ECN processing in TCP is >> awfully specialized: >> >> I can imagine congestion-control algorithms it would serve poorly. >> >> :^( But leaving that aside, ECN processing for other transport >> >> protocols almost certainly deserves a different treatment. >> >> >> >> It would be nice if our "greater precision" effort >> could serve the >> >> needs of yet-unseen future transport protocols. >> >> >> >> -- >> >> John Leslie >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Wed Aug 29 07:21:07 2012 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 58B0021F85C4 for ; Wed, 29 Aug 2012 07:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.714 X-Spam-Level: X-Spam-Status: No, score=-102.714 tagged_above=-999 required=5 tests=[AWL=-0.115, 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 DfLrQsESTnbh for ; Wed, 29 Aug 2012 07:21:05 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 6C08521F857E for ; Wed, 29 Aug 2012 07:21:05 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1T6j8g-0008Ds-A8 for tcpm@ietf.org; Wed, 29 Aug 2012 16:21:02 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1T6j8f-0005UH-SY for tcpm@ietf.org; Wed, 29 Aug 2012 16:21:02 +0200 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Aug 2012 16:21:00 +0200 Message-Id: To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 3 sum msgs/h 2 total rcpts 23152 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, RP_MATCHES_RCVD=-1.018, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1774A5D371A75224D509D6D4BE1809C8523B7066 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 9337 max/h 20 blacklist 0 greylist 0 ratelimit 0 Subject: [tcpm] Question and comments about draft-dukkipati-tcpm-tcp-loss-probe 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, 29 Aug 2012 14:21:07 -0000 Hi, In an effort to address the CPM chairs' suggestion to clarify how = draft-hurtig-tcpm-rtorestart related to = draft-dukkipati-tcpm-tcp-loss-probe, I finally got around to reading the = loss-probe draft - and I'm missing a key bit of information that would = help me make the distinction (and would probably be good to include in = your draft anyway - and: sorry if I missed it! but I think it's really = not there): what is the rationale for your choice of "2 * SRTT" in the = calculation of the probe timeout (PTO)? I mean, why not 3*RTT, 1.5*RTT, = whatever? If this is just the result of measurements, it would be good = to report that where you report the others. On a side note, I also think that it would be helpful for the reader to = know how you obtained the first results that you present, regarding the = large difference between RTO and RTT, in the introduction (par. starting = with "To get a sense...". I assume that this is the effect of a queue = growing on a short flow, giving a large variance in the RTO calculation, = but if that's what it is it would be good to say so. I also noticed an inconsistency: your draft is called "TCP Loss Probe", = whereas the slides at = http://www.ietf.org/proceedings/84/slides/slides-84-tcpm-14.pdf call it "Tail Loss Probe". Personally I prefer the latter term. Finally, I think that this draft raises the obvious question: if it's = beneficial to send an extra packet, why not 2, just to be safe? Or 3? Or = ... =3D> surely there is a point of where things get unacceptable. It = would be nice to see this trade-off quantified and evaluated, leading to = a conclusion that explains why 1 probe packet is a good choice (or maybe = even leading to a different number?). Cheers, Michael