From hagen@jauu.net Tue Nov 1 18:44:48 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27EF21F8DB3 for ; Tue, 1 Nov 2011 18:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6] 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 GDHH1SeCKz7w for ; Tue, 1 Nov 2011 18:44:48 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id 92B6A11E8095 for ; Tue, 1 Nov 2011 18:44:43 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id E0A6BF44145; Wed, 2 Nov 2011 02:44:41 +0100 (CET) Date: Wed, 2 Nov 2011 02:44:41 +0100 From: Hagen Paul Pfeifer To: tcpm@ietf.org Message-ID: <20111102014440.GB3987@nuttenaction> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Wed, 02 Nov 2011 01:44:48 -0000 Hey TFO'lers after reading 7.1 I don't really understand why pushing TFO forward. The benefit-cost-ratio seems unfavorable for TFO, compared to HTTP persistent connections. In the end: the major challenge is to increase the transactions per connection ratio. This can be reached by not closing the connection by frequent TCP keep-alive probes. The big advantage of HTTP persistent connections and TCP keep-alive probes is that they already widely deployed and the small TCP option space is not touched. Is power consumption really a real issue? A keep alive interval of several minutes should be fine for every mobile device doing HTTP. I.e. mobile webbrowsers can implement an adaptive keep-alive mechanism. Stop sending keep alive probes if the user stop browsing for several minutes. Therefore keep-alive probes would be send only when the browser is used. The second disadvantage is a larger memory consumption on server side, alright. But then maybe the Web Server should be optimized and state information reduced. Aside from all the disadvantages which occur by introducing new options. Like broken middleboxes dropping unknown TCP options, time until all vendors implement TFO, implementation bugs et cetera. I prefer to push HTTP persistent connection forward. IMHO it is a HTTP thing - it should be solved at HTTP level. Said that: I support the basic concept of TFO. It will work, I'm sure. But is it really worth that much if you can reuse HTTP connections? Hagen From hkchu@google.com Tue Nov 1 23:00:27 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384CD11E8085 for ; Tue, 1 Nov 2011 23:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, 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 if6xYeyfAfv9 for ; Tue, 1 Nov 2011 23:00:26 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8918911E807F for ; Tue, 1 Nov 2011 23:00:26 -0700 (PDT) Received: by ggnv1 with SMTP id v1so9311405ggn.31 for ; Tue, 01 Nov 2011 23:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=ba9b9N2V4GLxObjULbsPLeZCccGpdH3/CLMkM5p1Oqk=; b=uDKEmMRq83MN4vsr/8X0rlAJbiJLzUKqNvTpQL4PPneVYRbvg2Ca0b828s5Ts+U6TD erVJS/Wjql6eshSN06kQ== Received: by 10.150.165.19 with SMTP id n19mr3915277ybe.107.1320213624830; Tue, 01 Nov 2011 23:00:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.165.19 with SMTP id n19mr3915264ybe.107.1320213624667; Tue, 01 Nov 2011 23:00:24 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Tue, 1 Nov 2011 23:00:24 -0700 (PDT) In-Reply-To: <20111102014440.GB3987@nuttenaction> References: <20111102014440.GB3987@nuttenaction> Date: Tue, 1 Nov 2011 23:00:24 -0700 Message-ID: From: Jerry Chu To: Hagen Paul Pfeifer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Wed, 02 Nov 2011 06:00:27 -0000 On Tue, Nov 1, 2011 at 6:44 PM, Hagen Paul Pfeifer wrote: > Hey TFO'lers > > after reading 7.1 I don't really understand why pushing TFO forward. =A0T= he > benefit-cost-ratio seems unfavorable for TFO, compared to HTTP persistent > connections. I don't understand why section 7.1 led you to the above conclusion, after g= iving a long list of limitations of P-HTTP, and data showing P-HTTP in the real w= orld are not so persistent (averaging only 2-4 transactions per connection, likely due to one or more limitations described in the section). > > In the end: the major challenge is to increase the transactions per conne= ction > ratio. This can be reached by not closing the connection by frequent TCP > keep-alive probes. But keep-alive probes are a non-starter for power conscious mobile devices. > > The big advantage of HTTP persistent connections and TCP keep-alive probe= s is > that they already widely deployed and the small TCP option space is not This was the same argument by J. Mogul 16 years ago against T/TCP. 16 years later P-HTTP only attains 2-4 transaction per connection and you still beli= eve P-HTTP is the way to go? > touched. Is power consumption really a real issue? Yes from our Android partners. > A keep alive interval of > several minutes should be fine for every mobile device doing HTTP. I.e. m= obile Several minutes are eternity for mobile network. > webbrowsers can implement an adaptive keep-alive mechanism. And you think our Android/Chrome browser folks haven't tried? >Stop sending keep > alive probes if the user stop browsing for several minutes. Therefore > keep-alive probes would be send only when the browser is used. It's always easier said than done. Keep in mind keep alive probes serve to prevent NAT entries from being removed and it looks like you believe one can design= an adaptive algorithm to both minimize keep-alive frequency, while still preve= nting entry expiration, and avoiding NAT table and port/addr space depletion? > > The second disadvantage is a larger memory consumption on server side, > alright. But then maybe the Web Server should be optimized and state > information reduced. > > Aside from all the disadvantages which occur by introducing new options. = Like > broken middleboxes dropping unknown TCP options, Aren't there real data showing the above is rare? Perhaps you are suggesting IETF should stop publishing new TCP options altogether? >From our study P-HTTP seems much more problematic to middleboxes than unkno= wn TCP options. >time until all vendors > implement TFO, implementation bugs et cetera. We've already got a near-production, Linux-based TFO implementation. If we stop debating now and commit to TFO perhaps we'll see meaningful deploym= ent in a couple of years. >I prefer to push HTTP persistent > connection forward. I admire your patience but wonder after 16 years why you still believe ther= e is room for P-HTTP to go further. >IMHO it is a HTTP thing - it should be solved at HTTP > level. I beg to disagree. If you look closer none of the debates of P-HTTP vs TFO = have to do with HTTP, it's all about TCP, NAT, when to close a connection,..., e= tc. In fact when we designed TFO we never thought of HTTP. > > Said that: I support the basic concept of TFO. It will work, I'm sure. Bu= t is > it really worth that much if you can reuse HTTP connections? We have some real performance data showing the benefit of TFO in an upcomin= g ACM CoNext paper. Also we never intended TFO for HTTP only. Any transaction protocol with constraints on connection lifetime may benefit. Even TCP connections in our internal network may not have a long lifetime due to the resource constraint created by the large number of nodes and the N square problem. Jerry > > > Hagen > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From touch@isi.edu Tue Nov 1 23:36:37 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FF211E8083 for ; Tue, 1 Nov 2011 23:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.739 X-Spam-Level: X-Spam-Status: No, score=-105.739 tagged_above=-999 required=5 tests=[AWL=0.860, 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 QCXhs8jaNdNn for ; Tue, 1 Nov 2011 23:36:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEFE11E807F for ; Tue, 1 Nov 2011 23:36:37 -0700 (PDT) Received: from [192.168.1.94] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id pA26ZkwY023289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 Nov 2011 23:35:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: Date: Tue, 1 Nov 2011 23:35:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <45FC67B2-849B-4A95-8E56-372BF23DDBBF@isi.edu> References: <20111102014440.GB3987@nuttenaction> To: Jerry Chu X-Mailer: Apple Mail (2.1251.1) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Wed, 02 Nov 2011 06:36:37 -0000 On Nov 1, 2011, at 11:00 PM, Jerry Chu wrote: >> The big advantage of HTTP persistent connections and TCP keep-alive = probes is >> that they already widely deployed and the small TCP option space is = not >=20 > This was the same argument by J. Mogul 16 years ago against T/TCP. 16 = years > later P-HTTP only attains 2-4 transaction per connection and you still = believe > P-HTTP is the way to go? A better question is what the significant advantage is for fastopen = *assuming* P-HTTP. If you assume 2-4 transactions per connection, aren't you also getting = the bulk of the benefit too? >> Stop sending keep >> alive probes if the user stop browsing for several minutes. Therefore >> keep-alive probes would be send only when the browser is used. >=20 > It's always easier said than done. Keep in mind keep alive probes > serve to prevent > NAT entries from being removed and it looks like you believe one can = design an > adaptive algorithm to both minimize keep-alive frequency, while still = preventing > entry expiration, and avoiding NAT table and port/addr space = depletion? The socket pair isn't supposed to be reused for 2MSL anyway, so by using = persistent connections you're *preserving* the port space of the NAT, = rather than consuming it needlessly with a large number of short = connections. >> IMHO it is a HTTP thing - it should be solved at HTTP >> level. >=20 > I beg to disagree. If you look closer none of the debates of P-HTTP vs = TFO have > to do with HTTP, it's all about TCP, NAT, when to close a = connection,..., etc. > In fact when we designed TFO we never thought of HTTP. The error is in using TCP CLOSE as the dominant way to indicate EOF. = This is an error in the design of HTTP, as it is in many other = applications. There are other situations that need persistent connections as well - = notably the DNS, more lately with DNSSEC warranting the use of TCP = rather than UDP. In every case I've seen to date, the error seems much more like a = disconnect in the use of TCP than in the design of TCP itself - = *especially* considering that all the fast-open mechanisms (this one, = tcpcrypt, tcpct) reduce latency only for the "subsequent" connections to = a site, rather than the first one. Joe= From hagen@jauu.net Wed Nov 2 03:40:25 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4752B11E815D for ; Wed, 2 Nov 2011 03:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 9oE5HgdfdQlZ for ; Wed, 2 Nov 2011 03:40:24 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id 83DB411E815C for ; Wed, 2 Nov 2011 03:40:23 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 33) id 61A13F44145; Wed, 2 Nov 2011 11:40:22 +0100 (CET) To: Jerry Chu MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Wed, 02 Nov 2011 11:40:22 +0100 From: Hagen Paul Pfeifer In-Reply-To: References: <20111102014440.GB3987@nuttenaction> Message-ID: <52784d1883ad927db4607cc4b0f5af2e@localhost> X-Sender: hagen@jauu.net User-Agent: RoundCube Webmail/0.1-rc1 Cc: tcpm@ietf.org Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Wed, 02 Nov 2011 10:40:25 -0000 On Tue, 1 Nov 2011 23:00:24 -0700, Jerry Chu wrote: > I don't understand why section 7.1 led you to the above conclusion, after > giving > a long list of limitations of P-HTTP, and data showing P-HTTP in the real > world > are not so persistent (averaging only 2-4 transactions per connection, > likely due > to one or more limitations described in the section). To make it short: the major argument against P-HTTP is that only 2-4 transactions per connection are handled, right? This flaw is caused by "black-hearted" middleboxes not following the 124 minutes idle timeout, right? But this can be solved by sending TCP keep-alive probes (I address energy consumption later in this email). If it is solved, P-HTTP can do 10, 20, 100 transaction per connection. So if we can agree that this is the only disadvantage, then I see no real drawback of P-HTTP if the client sent keep-alive probes regularly. Jerry, I tried to find other real world blockers for P-HTTP, but I didn't found any additional blockers - except the NAT problem. > This was the same argument by J. Mogul 16 years ago against T/TCP. 16 years > later P-HTTP only attains 2-4 transaction per connection and you still > believe P-HTTP is the way to go? IMHO I imagine that HTTP performance was not on the list for several years. Everything over IP, I mean everything over HTTP generate some new pressure. ;-) > Yes from our Android partners. > Several minutes are eternity for mobile network. I mean sending a TCP keep-alive probe every several minutes. My "adaptive" approach say something like this: if the webbrowser is a foreground process group then send TCP-keep-alive probes (the browser assume that within the next couple of minutes a new HTTP request are generated), if the mobile phone is in power saving mode turn keep-alive probes off (the browser assume that within the next couple of minutes NO new HTTP request are generated, the connection can close). In other words: send TCP keep alive probes when the heuristic say that the browser is used or turn keep alive probes off otherwise. Or take the backlight as an indicator: if the backlight is on then generate keep-alive packets, turn off otherwise. I say sent Keep-alive probes context aware, not blindly generates them every 10 seconds. > And you think our Android/Chrome browser folks haven't tried? Yes ;-) For Google folks it is easier to modify TCP: you have control over _both_ TCP endpoints: server side and Android side. No annoying middle box ppeoblmes (TFO works fine, except that middleboxes eventually drop unknown TCP options, but this should be rare today), less HTTP server state, no interoperability problems - a fresh technology which just works. ;-) Jerry, as I wrote earlier: TFO is fine and functional - no doubt. But I can imagine that you can reach similar goals with P-HTTP without major TCP stack modifications. Hagen From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Nov 2 10:58:33 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554211F0CB6 for ; Wed, 2 Nov 2011 10:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.104, 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 yoaezM8wQNYU for ; Wed, 2 Nov 2011 10:58:32 -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 96D4F1F0CB7 for ; Wed, 2 Nov 2011 10:58:32 -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 D897A633B1 for ; Wed, 2 Nov 2011 18:58:31 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id CBA4959A8A for ; Wed, 2 Nov 2011 18:58:31 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: tcpm@ietf.org Date: Wed, 2 Nov 2011 18:58:30 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201111021858.30898.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: [tcpm] Fwd: New Version Notification for draft-kuehlewind-conex-accurate-ecn-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: Wed, 02 Nov 2011 17:58:33 -0000 Hi tcpm list, I'm working in the ConEx (congestion exposure) w-g. The congestion informat= ion=20 we want to expose to the network are based on loss and ECN. For this purpos= e=20 we would need a better ECN feedback information, than at max one feedback=20 signal per RTT as ECN is providing right now. Therefore we propose several= =20 solutions to extend ECN to provide a more accurate feedback in the draft=20 below. At the last ConEx meeting, we decided that the more appropriate environment= =20 for this draft probably is the tcpm group. I would be happy to get feedback= =20 from you and I will present an overview on the upcoming meeting. Mirja =2D--------- Forwarded Message ---------- Subject: New Version Notification for=20 draft-kuehlewind-conex-accurate-ecn-01.txt Date: Monday 31 October 2011, 12:54:46 =46rom: internet-drafts@ietf.org To: mirja.kuehlewind@ikr.uni-stuttgart.de CC: rs@netapp.com, mirja.kuehlewind@ikr.uni-stuttgart.de A new version of I-D, draft-kuehlewind-conex-accurate-ecn-01.txt has been=20 successfully submitted by Mirja Kuehlewind and posted to the IETF repositor= y. =46ilename: draft-kuehlewind-conex-accurate-ecn Revision: 01 Title: Accurate ECN Feedback in TCP Creation date: 2011-10-31 WG ID: Individual Submission Number of pages: 23 Abstract: Explicit Congestion Notification (ECN) is an IP/TCP mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN-capable receiver will feedback this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently new TCP mechanisms like ConEx or DCTCP need more accurate feedback information in the case where more than one marking is received in one RTT. = =20 The IETF Secretariat =2D------------------------------------------------------ =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 mirja.kuehlewind@ikr.uni-stuttgart.de Wed Nov 2 11:01:51 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAE911E8149 for ; Wed, 2 Nov 2011 11:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.096, 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 dGfELLDpJSo2 for ; Wed, 2 Nov 2011 11:01:50 -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 8BB0C11E8147 for ; Wed, 2 Nov 2011 11:01:50 -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 A97E7633B1; Wed, 2 Nov 2011 19:01:49 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 97AC859A8A; Wed, 2 Nov 2011 19:01:49 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: tcpm@ietf.org Date: Wed, 2 Nov 2011 19:01:48 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201111021901.48944.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: [tcpm] Fwd: New Version Notification for draft-kuehlewind-tcpm-accurate-ecn-option-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 18:01:51 -0000 Hi again, we also have a really short draft describing a possible TCP Option for=20 accurate ECN feedback. We see this an extension to a header based scheme, a= s=20 this solution could probably face deployment problem and need a lot more=20 header space. Anyway, the draft below! Mirja =2D--------- Forwarded Message ---------- Subject: New Version Notification for=20 draft-kuehlewind-tcpm-accurate-ecn-option-00.txt Date: Monday 24 October 2011, 18:26:39 =46rom: internet-drafts@ietf.org To: mirja.kuehlewind@ikr.uni-stuttgart.de CC: rs@netapp.com, mirja.kuehlewind@ikr.uni-stuttgart.de A new version of I-D, draft-kuehlewind-tcpm-accurate-ecn-option-00.txt has= =20 been successfully submitted by Mirja Kuehlewind and posted to the IETF=20 repository. =46ilename: draft-kuehlewind-tcpm-accurate-ecn-option Revision: 00 Title: Accurate ECN Feedback Option in TCP Creation date: 2011-10-24 WG ID: Individual Submission Number of pages: 7 Abstract: This document specifies an TCP option to get accurate Explicit Congestion Notification (ECN) feedback from the receiver. ECN is an IP/TCP mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN- capable receiver will feedback this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently new TCP mechanisms like ConEx or DCTCP need more accurate feedback information in the case where more than one marking is received in one RTT. This TCP extension can be used in addition to the classic ECN as well as with a more accurate ECN scheme recently proposed which reuses the ECN bit in the TCP header. = =20 The IETF Secretariat =2D------------------------------------------------------ =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 Michael.Scharf@alcatel-lucent.com Wed Nov 2 14:20:32 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4078C1F0C59; Wed, 2 Nov 2011 14:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_DE=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 nI-LyA-wuxAp; Wed, 2 Nov 2011 14:20:31 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 20AF01F0CC3; Wed, 2 Nov 2011 14:20:30 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id pA2LKR1I006744; Wed, 2 Nov 2011 22:20:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 22:20:26 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0693A416@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft TCPM agenda for IETF 82 Thread-Index: AcyZpT1pu6nhkIw6TDeyyLXXhBGKJg== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Cc: tcpm-chairs@ietf.org Subject: [tcpm] Draft TCPM agenda for IETF 82 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, 02 Nov 2011 21:20:32 -0000 Dear all, according to the requests I have received so far, I uploaded a draft agenda for the TCPM meeting in Taipei, which is also attached below. Please let the chairs know if you have any suggestions or comments, and in particular if I should have missed something. As a preparation for the meeting, the chairs would appreciate if all authors of individual drafts could let us know by beginning of next week if you plan to ask for WG adoption. Also, we would appreciate to get an early version of the presentations slides as soon as possible, in order to plan the meeting. Thanks Michael (TCPM co-chair) TCP Maintenance and Minor Extensions Working Group IETF 81 - Taipei, Taiwan Wednesday, November 16, 2011, 9:00-11:30 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Chairs (represented by Yoshifumi Nishida) WG status 10min WG items -------- Matt Mathies Proportional Rate Reduction for TCP draft-ietf-tcpm-proportional-rate-reduction 15min Non-WG items ------------ H.K. Jerry Chu=20 TCP Fast Open draft-cheng-tcpm-fastopen 15min Joe Touch Shared Use of Experimental TCP Options draft-touch-tcpm-experimental-options 15min Joe Touch Automating the Initial Window in TCP draft-touch-tcpm-automatic-iw 15min Mirja Kuehlewind Accurate ECN Feedback Option in TCP draft-kuehlewind-tcpm-accurate-ecn-option 15min Richard Scheffenegger Additional negotiation in the TCP Timestamp Option field during the TCP handshake draft-scheffenegger-tcpm-timestamp-negotiation 15min Per Hurtig TCP and SCTP RTO Restart draft-hurtig-tcpm-rtorestart 15min From hkchu@google.com Wed Nov 2 15:24:33 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68FA11E80B3 for ; Wed, 2 Nov 2011 15:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=0.150, 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 C1zZ9Yisn9R2 for ; Wed, 2 Nov 2011 15:24:32 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEA8711E8089 for ; Wed, 2 Nov 2011 15:24:32 -0700 (PDT) Received: by gye5 with SMTP id 5so693601gye.31 for ; Wed, 02 Nov 2011 15:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=huy0ogRR3PIeqCSzIm9Pd0cx9+5R9JR2MaEj37WfB0A=; b=cnHX+du21xPqiLHDU5SQ0xMwlb6lggulBSrvynb4FJ2IWzdmZ9GCHBg633N5Xef+07 8RBqpiH2UHFnIMpR/Urw== Received: by 10.150.165.19 with SMTP id n19mr7104610ybe.107.1320272672479; Wed, 02 Nov 2011 15:24:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.165.19 with SMTP id n19mr7104601ybe.107.1320272672308; Wed, 02 Nov 2011 15:24:32 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Wed, 2 Nov 2011 15:24:32 -0700 (PDT) In-Reply-To: <45FC67B2-849B-4A95-8E56-372BF23DDBBF@isi.edu> References: <20111102014440.GB3987@nuttenaction> <45FC67B2-849B-4A95-8E56-372BF23DDBBF@isi.edu> Date: Wed, 2 Nov 2011 15:24:32 -0700 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Wed, 02 Nov 2011 22:24:33 -0000 On Tue, Nov 1, 2011 at 11:35 PM, Joe Touch wrote: > > On Nov 1, 2011, at 11:00 PM, Jerry Chu wrote: > >>> The big advantage of HTTP persistent connections and TCP keep-alive pro= bes is >>> that they already widely deployed and the small TCP option space is not >> >> This was the same argument by J. Mogul 16 years ago against T/TCP. 16 ye= ars >> later P-HTTP only attains 2-4 transaction per connection and you still b= elieve >> P-HTTP is the way to go? > > A better question is what the significant advantage is for fastopen *assu= ming* P-HTTP. As I've mentioned in the -01 draft and previous email, we observed 10-40% improvement from TFO in the PLT in an emulated environment using a replay tool. And thi= s is WITH P-HTTP (or more accurately, with the default Chrome browser setting, which has P-HTTP enabled). We've seen in general about 90% of responses with Connection: Keep-Alive header. > If you assume 2-4 transactions per connection, aren't you also getting th= e bulk of the benefit too? We don't have data on how much improvement P-HTTP provides over HTTP1.0. We= only know TFO provides additional saving on top of P-HTTP as described above. We have provided more details on the performance data in an upcoming paper to ACM CoNEXT'11, which has just been announced at http://conferences.sigcomm.org/co-next/2011/program.html > >>> Stop sending keep >>> alive probes if the user stop browsing for several minutes. Therefore >>> keep-alive probes would be send only when the browser is used. >> >> It's always easier said than done. Keep in mind keep alive probes >> serve to prevent >> NAT entries from being removed and it looks like you believe one can des= ign an >> adaptive algorithm to both minimize keep-alive frequency, while still pr= eventing >> entry expiration, and avoiding NAT table and port/addr space depletion? > > The socket pair isn't supposed to be reused for 2MSL anyway, so by using = persistent connections you're *preserving* the port space of the NAT, rathe= r than consuming it needlessly with a large number of short connections. What you said is correct if NAT boxes preserver TIME-WAIT connections but I think the latter is highly implementation dependent. For those NAT boxes that don't preserve TIME-WAIT, its working set size is determined by how many established connections. The more connections persist, the more mapping entries it will demand. > >>> IMHO it is a HTTP thing - it should be solved at HTTP >>> level. >> >> I beg to disagree. If you look closer none of the debates of P-HTTP vs T= FO have >> to do with HTTP, it's all about TCP, NAT, when to close a connection,...= , etc. >> In fact when we designed TFO we never thought of HTTP. > > The error is in using TCP CLOSE as the dominant way to indicate EOF. This= is an error in the design of HTTP, as it is in many other applications. Yep, seems like expediency on the part of application protocols. > > There are other situations that need persistent connections as well - not= ably the DNS, more lately with DNSSEC warranting the use of TCP rather than= UDP. > > In every case I've seen to date, the error seems much more like a disconn= ect in the use of TCP than in the design of TCP itself - *especially* consi= dering that all the fast-open mechanisms (this one, tcpcrypt, tcpct) reduce= latency only for the "subsequent" connections to a site, rather than the f= irst one. We have been pondering on a "cookie-less" mode for TFO where the round trip saving can be attained on the 1st connect(). We may have to give back some portion of the round trip saving in order to avoid a security issue. Will need to get some performance data first. Jerry > > Joe From hkchu@google.com Wed Nov 2 16:46:39 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A5111E80AB for ; Wed, 2 Nov 2011 16:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 0Dz3dUtz5x0s for ; Wed, 2 Nov 2011 16:46:39 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC6C911E8073 for ; Wed, 2 Nov 2011 16:46:38 -0700 (PDT) Received: by ywt2 with SMTP id 2so773645ywt.31 for ; Wed, 02 Nov 2011 16:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=FJevbqdjse488wE2bn7Xr0Es/IaRGP8gmUgwb4GcxgE=; b=ikkNDwxPKk2QYs9pY8XglWjSel0WUG/v7SRTYknsnVqpq6/HIR5lqFK1ohEyEbxDey MRMLs+GZH2QlurWfh/uw== Received: by 10.150.238.6 with SMTP id l6mr7515738ybh.77.1320277598330; Wed, 02 Nov 2011 16:46:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.238.6 with SMTP id l6mr7515730ybh.77.1320277598146; Wed, 02 Nov 2011 16:46:38 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Wed, 2 Nov 2011 16:46:38 -0700 (PDT) In-Reply-To: <52784d1883ad927db4607cc4b0f5af2e@localhost> References: <20111102014440.GB3987@nuttenaction> <52784d1883ad927db4607cc4b0f5af2e@localhost> Date: Wed, 2 Nov 2011 16:46:38 -0700 Message-ID: From: Jerry Chu To: Hagen Paul Pfeifer Content-Type: multipart/alternative; boundary=000e0cd240843e0fc104b0c9158b X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Wed, 02 Nov 2011 23:46:40 -0000 --000e0cd240843e0fc104b0c9158b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 2, 2011 at 3:40 AM, Hagen Paul Pfeifer wrote: > > On Tue, 1 Nov 2011 23:00:24 -0700, Jerry Chu wrote: > > > I don't understand why section 7.1 led you to the above conclusion, > after > > giving > > a long list of limitations of P-HTTP, and data showing P-HTTP in the > real > > world > > are not so persistent (averaging only 2-4 transactions per connection, > > likely due > > to one or more limitations described in the section). > > To make it short: the major argument against P-HTTP is that only 2-4 > transactions per connection are handled, right? This flaw is caused by > "black-hearted" middleboxes not following the 124 minutes idle timeout, > right? No, not that simple. We don't know the cause. We just report the fact based on our logged data! The rest is all speculation. But come to think about it there are multiple forces involved here. Either end point can decide to close a connection due to resource constraint, some policy restriction (e.g., browsers allowing only X # of open connections), user's web surfing pattern, unexpected RST or timeout by the middleboxes,..., just naming a few (and I must have missed a whole bunch). > But this can be solved by sending TCP keep-alive probes (I address > energy consumption later in this email). If it is solved, P-HTTP can do > 10, 20, 100 transaction per connection. So if we can agree that this is the > only disadvantage, then I see no real drawback of P-HTTP if the client sent > keep-alive probes regularly. Jerry, I tried to find other real world > blockers for P-HTTP, but I didn't found any additional blockers - except > the NAT problem. > See my list above. And the more I dig, the more blockers I find. We are living in a complex world and more than one solutions are often needed. > > > > This was the same argument by J. Mogul 16 years ago against T/TCP. 16 > years > > later P-HTTP only attains 2-4 transaction per connection and you still > > believe P-HTTP is the way to go? > > IMHO I imagine that HTTP performance was not on the list for several > years. Everything over IP, I mean everything over HTTP generate some new > pressure. ;-) > > > > Yes from our Android partners. > > Several minutes are eternity for mobile network. > > I mean sending a TCP keep-alive probe every several minutes. My "adaptive" > approach say something like this: if the webbrowser is a foreground process > group then send TCP-keep-alive probes (the browser assume that within the > next couple of minutes a new HTTP request are generated), if the mobile > phone is in power saving mode turn keep-alive probes off (the browser > assume that within the next couple of minutes NO new HTTP request are > generated, the connection can close). In other words: send TCP keep alive > probes when the heuristic say that the browser is used or turn keep alive > probes off otherwise. Or take the backlight as an indicator: if the > backlight is on then generate keep-alive packets, turn off otherwise. I say > sent Keep-alive probes context aware, not blindly generates them every 10 > seconds. > Understood but that doesn't address the problem when NAT reclaims a translation entry while the device owning the connection has hibernated temporarily. Then, after waking up, the browser hangs until TCP timeout. This is one of the real world issues that our Chrome/Android folks is facing, forcing them to considering disabling P-HTTP completely. > > > And you think our Android/Chrome browser folks haven't tried? > > Yes ;-) For Google folks it is easier to modify TCP: you have control over > _both_ TCP endpoints: server side and Android side. No annoying middle box > ppeoblmes (TFO works fine, except that middleboxes eventually drop unknown > TCP options, but this should be rare today), less HTTP server state, no > interoperability problems - a fresh technology which just works. ;-) > > > Jerry, as I wrote earlier: TFO is fine and functional - no doubt. But I > can imagine that you can reach similar goals with P-HTTP without major TCP > stack modifications. > We've gone through this circle a few times. Long before we proposed IW10 our front end folks had tried to tune various parameters to attain better P-HTTP performance and discovered they can only go so far. Then we applied IW10 and get more performance mileage. We're attempting the same with TFO. Keep in mind we've never dismissed the usefulness of P-HTTP. It's the claim that P-HTTP solves world hunger problem that we can not agree. Best, Jerry > > Hagen > --000e0cd240843e0fc104b0c9158b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 2, 2011 at 3:40 AM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:

On Tue, 1 Nov 2011 23:00:24 -0700, Jerry Chu <hkchu@google.com> wrote:

> I don't understand why section 7.1 led you to the above conclusion= ,
after
> giving
> a long list of limitations of P-HTTP, and data showing P-HTTP in the real
> world
> are not so persistent (averaging only 2-4 transactions per connection,=
> likely due
> to one or more limitations described in the section).

To make it short: the major argument against P-HTTP is that only 2-4<= br> transactions per connection are handled, right? This flaw is caused by
"black-hearted" middleboxes not following the 124 minutes idle ti= meout,
right?

No, not that simple. We don't kn= ow the cause. We just report the fact
based on our logged data! T= he rest is all speculation. But come to think
about it=A0there ar= e multiple forces involved here. Either end point can
decide to close a connection due to resource constraint, some policy
restriction (e.g., browsers allowing only X # of open connections)= , user's
web surfing pattern,=A0unexpected RST or timeout by = the middleboxes,...,
just naming a few (and I must have missed a whole bunch).
= =A0
But this can be solved by sending = TCP keep-alive probes (I address
energy consumption later in this email). If it is solved, P-HTTP can do 10,= =A0
20, 100 transaction per connection. So if we can agree that this is the
only disadvantage, then I see no real drawback of P-HTTP if the client sent=
keep-alive probes regularly. Jerry, I tried to find other real world
blockers for P-HTTP, but I didn't found any additional blockers - excep= t
the NAT problem.

See my list above. And= the more I dig, the more blockers I find. We are living
in a com= plex world and more than one solutions are often needed.
=A0


> This was the same argument by J. Mogul 16 years ago against T/TCP. 16<= br> years
> later P-HTTP only attains 2-4 transaction per connection and you still=
> believe P-HTTP is the way to go?

IMHO I imagine that HTTP performance was not on the list for several<= br> years.
Everything over IP, I me= an everything over HTTP generate some new
pressure. ;-)


> Yes from our Android partners.
> Several minutes are eternity for mobile networ= k.

I mean sending a TCP keep-alive probe every several minutes. My "= ;adaptive"
approach say something like this: if the webbrowser is a foreground process=
group then send TCP-keep-alive probes (the browser assume that within the next couple of minutes a new HTTP request are generated), if the mobile
phone is in power saving mode turn keep-alive probes off (the browser
assume that within the next couple of minutes NO new HTTP request are
generated, the connection can close). In other words: send TCP keep alive probes when the heuristic say that the browser is used or turn keep alive probes off otherwise. Or take the backlight as an indicator: if the
backlight is on then generate keep-alive packets, turn off otherwise. I say=
sent Keep-alive probes context aware, not blindly generates them every 10 seconds.

Understood but that doesn'= t address the problem when NAT reclaims a
translation=A0entry whi= le the device owning the connection has hibernated
temporarily. T= hen, after waking up, the browser hangs until TCP timeout.
This is one of the real world issues that our Chrome/Android folks is = facing,
forcing them to considering disabling P-HTTP completely.<= /div>



> And you think our Android/Chrome browser folks haven't tried?

Yes ;-) For Google folks it is easier to modify TCP: you have control= over
_both_ TCP endpoints: server side and Android side. No annoying middle box<= br> ppeoblmes (TFO works fine, except that middleboxes eventually drop unknown<= br> TCP options, but this should be rare today), less HTTP server state, no
interoperability problems - a fresh technology which just works. =A0;-)


Jerry, as I wrote earlier: TFO is fine and functional - no doubt. But I
can imagine that you can reach similar goals with P-HTTP without major TCP<= br> stack modifications.

We've gone thr= ough this circle a few times. Long before we proposed IW10 our
fr= ont end folks had tried to tune various parameters to attain better P-HTTP<= /div>
performance and discovered they can only go so far. Then we applied IW= 10
and get more performance mileage. We're attempting the sam= e with TFO. Keep
in mind=A0we've never dismissed the usefulne= ss of P-HTTP. It's the claim that
P-HTTP=A0solves world hunger problem that we can not agree.
=
Best,

Jerry



Hagen

--000e0cd240843e0fc104b0c9158b-- From ycheng@google.com Wed Nov 2 17:25:03 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3DC11E80DB for ; Wed, 2 Nov 2011 17:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Oznfr2kfhWZe for ; Wed, 2 Nov 2011 17:25:03 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E6F0711E80BB for ; Wed, 2 Nov 2011 17:25:02 -0700 (PDT) Received: by qadc10 with SMTP id c10so894277qad.31 for ; Wed, 02 Nov 2011 17:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=7Zc3hXvYRMFIjugxpxgAqK8T0hXwOnQT6yikdXB0kLU=; b=gM/ft8L4gUmiCUD+/eQSRTb9lOo5HbRrLU2HCHlO6KIdSYJBdDBwMyIANKLTUdR9+1 XD5CRBUxnO1HHrvFJGJA== Received: by 10.224.180.207 with SMTP id bv15mr3339209qab.36.1320279901399; Wed, 02 Nov 2011 17:25:01 -0700 (PDT) Received: by 10.224.180.207 with SMTP id bv15mr3339203qab.36.1320279901265; Wed, 02 Nov 2011 17:25:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.76 with HTTP; Wed, 2 Nov 2011 17:24:40 -0700 (PDT) In-Reply-To: <52784d1883ad927db4607cc4b0f5af2e@localhost> References: <20111102014440.GB3987@nuttenaction> <52784d1883ad927db4607cc4b0f5af2e@localhost> From: Yuchung Cheng Date: Wed, 2 Nov 2011 17:24:40 -0700 Message-ID: To: Hagen Paul Pfeifer Content-Type: multipart/alternative; boundary=20cf303b430d84e0c704b0c99e73 X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" , =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Thu, 03 Nov 2011 00:25:03 -0000 --20cf303b430d84e0c704b0c99e73 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 2, 2011 at 3:40 AM, Hagen Paul Pfeifer wrote: > > On Tue, 1 Nov 2011 23:00:24 -0700, Jerry Chu wrote: > > > I don't understand why section 7.1 led you to the above conclusion, > after > > giving > > a long list of limitations of P-HTTP, and data showing P-HTTP in the > real > > world > > are not so persistent (averaging only 2-4 transactions per connection, > > likely due > > to one or more limitations described in the section). > > To make it short: the major argument against P-HTTP is that only 2-4 > transactions per connection are handled, right? This flaw is caused by > "black-hearted" middleboxes not following the 124 minutes idle timeout, > right? But this can be solved by sending TCP keep-alive probes (I address > energy consumption later in this email). If it is solved, P-HTTP can do 10, > 20, 100 transaction per connection. So if we can agree that this is the > To clarify: Chrome *already* sends keep-alive messages every 45s or so, but we still see an average of 3 requests per transaction. [NOTE: Chrome is not yet on Android which runs a different browser that disables keep-alive for power issue] > only disadvantage, then I see no real drawback of P-HTTP if the client sent > keep-alive probes regularly. Jerry, I tried to find other real world > blockers for P-HTTP, but I didn't found any additional blockers - except > the NAT problem. > You are right on the point. We don't see any drawback of P-HTTP. In fact we absoultely love it. We are arguing NAT, sadly but practically, is limiting p-HTTP for long run. Jerry has made the point clear, but let me restate: TFO's goal is never to replace p-HTTP. TFO is addressing the limitation of p-HTTP. They are complimentary. Joe asked the great question about how much limitation does TFO addresses. I am working on getting the paper online so we can discussion over data directly. > > And you think our Android/Chrome browser folks haven't tried? > > Yes ;-) For Google folks it is easier to modify TCP: you have control over > _both_ TCP endpoints: server side and Android side. No annoying middle box > ppeoblmes (TFO works fine, except that middleboxes eventually drop unknown > TCP options, but this should be rare today), less HTTP server state, no > interoperability problems - a fresh technology which just works. ;-) > It would just work if we also control the middleboxes too :( > > Jerry, as I wrote earlier: TFO is fine and functional - no doubt. But I > can imagine that you can reach similar goals with P-HTTP without major TCP > stack modifications. > Again I agree with u *if* p-HTTP can be used any time anywhere. Seriously we would not want to go the TCP route if we have seen a easier exit. Sadly we are seeing the trend is going backward: power issues, nat issues, blah blah, are zapping idle TCP asap. --20cf303b430d84e0c704b0c99e73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Nov 2, 2011 at 3:40 AM, Hagen Pa= ul Pfeifer <hagen@ja= uu.net> wrote:

On Tue, 1 Nov 2011 23:00:24 -0700, Jerry Chu <hkchu@google.com> wrote:

> I don't understand why section 7.1 led you to the above conclusion= ,
after
> giving
> a long list of limitations of P-HTTP, and data showing P-HTTP in the real
> world
> are not so persistent (averaging only 2-4 transactions per connection,=
> likely due
> to one or more limitations described in the section).

To make it short: the major argument against P-HTTP is that only 2-4<= br> transactions per connection are handled, right? This flaw is caused by
"black-hearted" middleboxes not following the 124 minutes idle ti= meout,
right? But this can be solved by sending TCP keep-alive probes (I address energy consumption later in this email). If it is solved, P-HTTP can do 10,=
20, 100 transaction per connection. So if we can agree that this is the
=
To clarify: Chrome *already* sends keep-alive messages= every 45s or so, but we still see an average of 3 requests per transaction= . [NOTE: Chrome is not yet on Android which runs a different browser that d= isables keep-alive for power issue]

=A0
only disadvantage, then I see no real drawback of P-HTTP if the client sent=
keep-alive probes regularly. Jerry, I tried to find other real world
blockers for P-HTTP, but I didn't found any additional blockers - excep= t
the NAT problem.
You are right on the point.=A0We don&= #39;t see any drawback of P-HTTP. In fact we absoultely love it. We are arg= uing NAT, sadly but practically, is limiting p-HTTP for long run.=A0

Jerry has made the point clear, but let me restate= :
TFO's goal is never to replace p-HTTP. =A0TFO is addressing= the limitation of p-HTTP. They are complimentary.

Joe asked the great question about how much limitat= ion does TFO addresses. I am working on getting the paper online so we can = discussion over data directly.


> And you think our Android/Chrome browser folks haven't tried?

Yes ;-) For Google folks it is easier to modify TCP: you have control= over
_both_ TCP endpoints: server side and Android side. No annoying middle box<= br> ppeoblmes (TFO works fine, except that middleboxes eventually drop unknown<= br> TCP options, but this should be rare today), less HTTP server state, no
interoperability problems - a fresh technology which just works. =A0;-)
=
It would just work if we also control the middleboxes too= :(



Jerry, as I wrote earlier: TFO is fine and functional - no doubt. But I
can imagine that you can reach similar goals with P-HTTP without major TCP<= br> stack modifications.
Again I agree with u *if* p-HTTP = can be used any time anywhere. Seriously we would not want to go the TCP ro= ute if we have seen a easier exit.=A0Sadly we are seeing the trend is going= backward: power issues, nat issues, blah blah, are zapping idle TCP asap.<= /div>



--20cf303b430d84e0c704b0c99e73-- From rs@netapp.com Thu Nov 3 02:58:02 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F4411E80B1 for ; Thu, 3 Nov 2011 02:58:02 -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 xZVyIkEajwXF for ; Thu, 3 Nov 2011 02:58:01 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4D79A11E80AC for ; Thu, 3 Nov 2011 02:58:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,448,1315206000"; d="scan'208";a="594729703" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 03 Nov 2011 02:57:45 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id pA39viww016753; Thu, 3 Nov 2011 02:57:44 -0700 (PDT) Received: from VMWEXCEHT03-PRD.hq.netapp.com ([10.106.76.241]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 02:57:38 -0700 Received: from VMWEXCEHT05-PRD.hq.netapp.com (10.106.77.35) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 3 Nov 2011 02:57:32 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.16]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.01.0289.001; Thu, 3 Nov 2011 02:57:32 -0700 From: "Scheffenegger, Richard" To: "Per Hurtig (work)" Thread-Topic: [tcpm] Fwd: New Version Notification fordraft-hurtig-tcpm-rtorestart-01.txt Thread-Index: AcyXITXTHcLDuhm9Qquty2KxlNGsrQC69SCg Date: Thu, 3 Nov 2011 09:57:31 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F025ED3@SACEXCMBX02-PRD.hq.netapp.com> References: <20111029192848.4798.45100.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Nov 2011 09:57:38.0041 (UTC) FILETIME=[04AB1690:01CC9A0F] Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Fwd: New Version Notification fordraft-hurtig-tcpm-rtorestart-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: Thu, 03 Nov 2011 09:58:02 -0000 Hi Per, I was wondering if our proposed semantic changes of RFC1323 in draft-scheff= enegger-tcpm-timestamp-negotiation-03.txt would allow all the byte-oriented= , non-linux derived stacks to benefit from your proposal as well... With RFC1323, the timestamp value echoed back to the sender contains the TS= val of the oldest, in-sequence received segment. As such, the TSecr in an A= CK cannot directly be used to find the time when a particular segment was a= ctually sent and covered in the ACK. This leads to the very stateful approa= ch taken in linux (the 2nd issue is, that RFC1323 TSecr is not protected ag= ainst spoofing/alteration, opening a nice attack surface against any time-b= ased algorithm). Unfortunately, in my experience, the majority of tcp stacks does not hold p= er-segment state information. Our proposal is to also modify the semantics of RFC1323, which timestamp sh= ould be reflected in an ACK - provided the TCP session is also using SACK (= SCTP always uses SACK). Thus the TSecr will contain the exact timestamp whe= n the last segment triggering the ACK was sent. So each ACK gives a more accurate probe of the current network RTT, potenti= ally allowing better estimates of the RTO that may not need to artificially= delayed by 1 RTT before expiring... Best regards, Richard Scheffenegger > -----Original Message----- > From: Per Hurtig (work) [mailto:per.hurtig@kau.se] > Sent: Sonntag, 30. Oktober 2011 17:30 > To: tcpm > Subject: [tcpm] Fwd: New Version Notification fordraft-hurtig-tcpm- > rtorestart-01.txt >=20 > Hi all, >=20 > we've updated the TCP/SCTP RTO restart draft. The main difference > between this version and the previous one is that the modified restart > approach only is conducted for data-limited traffic and that the intended > status of the draft has changed to experimental. Hope we can discuss it i= n > Taipei. >=20 > Regards, > Per >=20 > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > Date: Sat, 29 Oct 2011 12:28:48 -0700 > Subject: New Version Notification for draft-hurtig-tcpm-rtorestart-01.txt > To: per.hurtig@kau.se > Cc: per.hurtig@kau.se, michawe@ifi.uio.no, apetlund@simula.no >=20 > A new version of I-D, draft-hurtig-tcpm-rtorestart-01.txt has been > successfully submitted by Per Hurtig and posted to the IETF repository. >=20 > Filename: draft-hurtig-tcpm-rtorestart > Revision: 01 > Title: TCP and SCTP RTO Restart > Creation date: 2011-10-29 > WG ID: Individual Submission > Number of pages: 9 >=20 > Abstract: > This document describes a modified algorithm for managing the TCP and > SCTP retransmission timers, that provides faster loss recovery when a > connection's amount of outstanding data is small. The modificatio= n > allows the transport to restart its retransmission timer more > aggressively in situations where fast retransmit can not be used. > This enables faster loss detection, and recovery, for connections > that are short-lived or application-limited. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From Michael.Scharf@alcatel-lucent.com Thu Nov 3 03:16:06 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A961F0C5F for ; Thu, 3 Nov 2011 03:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_DE=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 VhJYyUBtHl+w for ; Thu, 3 Nov 2011 03:16:06 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 263541F0C3C for ; Thu, 3 Nov 2011 03:16:05 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id pA3AG1RP017232; Thu, 3 Nov 2011 11:16:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Nov 2011 11:15:58 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0693A450@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions on draft-scheffenegger-tcpm-timestamp-negotiation Thread-Index: AcyaEZSKQd7IGerXTJ+zseySVsrtuA== From: "SCHARF, Michael" To: "Scheffenegger, Richard" , "Mirja Kuehlewind" X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Cc: tcpm@ietf.org Subject: [tcpm] Questions on draft-scheffenegger-tcpm-timestamp-negotiation 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, 03 Nov 2011 10:16:07 -0000 Richard, Mirja, I'd like to trigger a discussion of some aspects of draft-scheffenegger-tcpm-timestamp-negotiation, given that it proposes a negotiation feature that we currently don't have in TCP. Some questions that come into my mind (as individual) regarding the current draft test are: - Is there a (prototype) implementation and corresponding lessons learnt? - Are there some numbers on the benefit (regarding better OWD estimation, early spurious retransmit detection, early lost retransmission detection)? - What would be the pros and cons of only standardizing a part of what the draft currently proposes. For instance, what is the cost of not violating RFC 1323? Any insight would be helpful. Thanks Michael From hagen@jauu.net Thu Nov 3 03:18:52 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19EE11E80AC for ; Thu, 3 Nov 2011 03:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_73=0.6] 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 NZQtOYMRTRqG for ; Thu, 3 Nov 2011 03:18:51 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9BB11E80D2 for ; Thu, 3 Nov 2011 03:18:51 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 33) id 3CCBCF44145; Thu, 3 Nov 2011 11:18:50 +0100 (CET) To: Yuchung Cheng MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Thu, 03 Nov 2011 11:18:50 +0100 From: Hagen Paul Pfeifer In-Reply-To: References: <20111102014440.GB3987@nuttenaction> <52784d1883ad927db4607cc4b0f5af2e@localhost> Message-ID: <8d774518549a37065829878195bca23e@localhost> X-Sender: hagen@jauu.net User-Agent: RoundCube Webmail/0.1-rc1 Cc: "tcpm@ietf.org Extensions" , =?UTF-8?Q?William_Chan_=28=E9=99=88=E6=99=BA=E6=98=8C=29?= Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Thu, 03 Nov 2011 10:18:52 -0000 On Wed, 2 Nov 2011 17:24:40 -0700, Yuchung Cheng wrote: > To clarify: Chrome *already* sends keep-alive messages every 45s or so, > but we still see an average of 3 requests per transaction. [NOTE: Chrome > is not yet on Android which runs a different browser that disables > keep-alive for power issue] But then it would help to identify why only 3 req per transaction. I assume that the P-HTTP timeout is to short (my apache run with the default of 5 seconds). > You are right on the point. We don't see any drawback of P-HTTP. In > fact we absoultely love it. We are arguing NAT, sadly but practically, is > limiting p-HTTP for long run. > Jerry has made the point clear, but let me restate:TFO's goal is never > to replace p-HTTP. TFO is addressing the limitation of p-HTTP. They are > complimentary. I know, I consider TFO as a complimentary mechanism, not sticked to HTTP. > Joe asked the great question about how much limitation does TFO > addresses. I am working on getting the paper online so we can discussion > over data directly. It seems Joe know how to ask smart questions. ;-) Hagen BTW: thank you Jerry and Yuchung for clarification! From rs@netapp.com Thu Nov 3 03:33:28 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DA811E8088 for ; Thu, 3 Nov 2011 03:33:28 -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 JLZ4u9GhI+Ry for ; Thu, 3 Nov 2011 03:33:27 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id A9BFD11E80D3 for ; Thu, 3 Nov 2011 03:33:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,448,1315206000"; d="scan'208";a="594737818" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 03 Nov 2011 03:33:11 -0700 Received: from sacrsexc1-prd.hq.netapp.com (sacrsexc1-prd.hq.netapp.com [10.99.115.27]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id pA3AXAIw000505; Thu, 3 Nov 2011 03:33:10 -0700 (PDT) Received: from VMWEXCEHT02-PRD.hq.netapp.com ([10.106.76.240]) by sacrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 03:33:06 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.16]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.01.0289.001; Thu, 3 Nov 2011 03:33:05 -0700 From: "Scheffenegger, Richard" To: "SCHARF, Michael" , Mirja Kuehlewind Thread-Topic: Questions on draft-scheffenegger-tcpm-timestamp-negotiation Thread-Index: AcyaEZSKQd7IGerXTJ+zseySVsrtuAAARZPw Date: Thu, 3 Nov 2011 10:33:04 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F025F65@SACEXCMBX02-PRD.hq.netapp.com> References: <133D9897FB9C5E4E9DF2779DC91E947C0693A450@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0693A450@SLFSNX.rcs.alcatel-research.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Nov 2011 10:33:06.0192 (UTC) FILETIME=[F9252900:01CC9A13] Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Questions on draft-scheffenegger-tcpm-timestamp-negotiation 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, 03 Nov 2011 10:33:28 -0000 Hi Michael, > As individual: While it is clear that we have some empty > bits that we could use for this negotiation, I am a little=20 > wondering about why we really need that negotiation.=20 > Some questions that come into my mind: >=20 > - Is there a (prototype) implementation and corresponding > lessons learnt? Not in a kernel stack. The last few months I spent the time=20 understanding why some stacks (really mostly Linux) already violate=20 RFC1323 during the 3WHS. http://kerneltrap.org/mailarchive/linux-netdev/2009/4/10/5446374 http://permalink.gmane.org/gmane.linux.network/168864 (Basically, Linux has "TSval=3D=3D0" is invalid, while RFC1323 states=20 without valid TS, send TSval=3D0 (0 may mean the sender has no valid=20 timestamp available, or uses a genuine value of zero) . There are more messages floating around this issue in the=20 discussion around the "bug fix"). > - Are there some numbers on the benefit (regarding better OWD=20 > estimation, early spurious retransmit detection, early lost > retransmission detection)? The qualitative aspects are discussed in the draft. There are a few=20 (experimental) tcp improvements which use the value contained in TSval=20 for timing purposes on the receiver side. These fall into two categories: Assuming one particular timestamp=20 clock interval without training phase, or assume one interval from a=20 limited set after a short training phase. Both will fail when the sender uses some simple form of packet=20 counting or reserves a few low-order bits for sanity checking (i.e.=20 some experimental Cubic implementation). To quantify how much TCP=20 congestion control may go out of whack then, is really hard. For spurious retransmit detection (ie. Eifel) you need two different=20 timestamp values between original segment and it's retransmission; as=20 soon as RTT drops below the tcp timer (to be exact: timestamp clock)=20 granularity, these feature simply fails to work. So the performance=20 evaluation of Eifel can be used as quantitative impact analysis for=20 low latency (LAN) environments. The early lost retransmission aspect would be a protocol in it's own=20 right, building upon what Linux is been doing for about a decade now=20 (and which is not specified in RFCs). Qualitatively, Early LRD and Linux LRD relate to each other in a=20 similar way as Eifel and F-RTO do - the latter requires the sending=20 (and ACK) of a new segment, while the former work implicitly with=20 information contained in the timestamps. But frankly, we are definitely talking about the 99,9-something=20 percentile of segment delivery latency. I received an analysis from Google at one time of their RTOs at some=20 time - it was private only after the discussion around the "recovery"=20 retransmission to be included in the 3517bis: (all counters are in thousand) baseline sack-reno-recov Retransmits: 104187 104940 Fast: 16935 (16.3%) 17984 (17.1%) [+0,8%] Forward: 4178 ( 4.0%) 4162 ( 4.0%) After-RTO: 17395 (16.7%) 17238 (16.4%) [-0,3%] Timeouts: 65677 (63.0%) 65554 (62.5%) [-0,5%] 1st: 45096 43.3% 44992 42.9% Open 40688 39.1% 40718 38.8% Disorder 2581 2.5% 2607 2.5% Recovery 864 0.8% 715 0.7% 2nd+: 21542 20.7% 21513 20.5% LostRetrans: 1250 ( 1.2%) 1267 ( 1.2%) Note that the early LDR would address the row "LostRetrans", dealing=20 with perhaps 1% of the issues leading to RTOs in a public web server. I plan to collect similar data from NFS sessions, once we have the=20 appropriate instruments in our stack. (The NFS/iSCSI traffic is=20 qualitatively different from HTTP-ish traffic - not only because it's=20 traffic most likely encountered in private data centers instead of=20 across the public internet). > - What would be the pros and cons of only standardizing a > part of what the draft currently proposes. For instance, what > is the cost of not violating RFC 1323? Without the semantic change of RFC1323, OWD always included the=20 processing and delivery delay of a delayed acknowledged data segment.=20 So, OWD variance not only captures network related timing variance,=20 but also processing variance in the host. Agreed, some processing=20 variance of the host would always be part of the measurement, but with=20 the current semantics, this is artificially bloated so that OWD=20 variance is nearly meaningless for sufficiently low latency=20 environments (< ~20ms or so). Also, the improvements around early lost retransmission require a=20 unique timestamp signal also during SACK loss recovery. The current=20 RFC1323 semantics render the timestamp value inert during loss, so=20 that they effectively contribute no information around the current=20 network / receiver state to the sender (despite using up 12 bytes). This problem was mentioned by Luigi Rizzo already during=20 standardization of RFC1323 (see his TSACK idea: http://info.iet.unipi.it/~luigi/selack.ps ) 15 years ago, but declined=20 at the time (SACK was standardized only later, and as you know, there=20 is no interaction between TS and SACK, despite both enhancements=20 originally being part of a single proposal. So, without changing the RFC1323 (receiver) semantics, you get: Reduced fidelity on the OWD signal (but at least proper knowledge of the timestamp timer granularity) No improvement during loss episodes Simple RTO calculation as the input is already a worst-case estimate=20 RTT (including delayed ACK + processing delays, not just network=20 delay). Best regards, Richard From hagen@jauu.net Thu Nov 3 03:55:35 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C5F1F0C3C for ; Thu, 3 Nov 2011 03:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 GBgE3ZcwGxcU for ; Thu, 3 Nov 2011 03:55:35 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id 6607611E80A6 for ; Thu, 3 Nov 2011 03:55:35 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 33) id EAAF1F44145; Thu, 3 Nov 2011 11:55:32 +0100 (CET) To: =?UTF-8?Q?William_Chan_=28=E9=99=88=E6=99=BA=E6=98=8C=29?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 03 Nov 2011 11:55:32 +0100 From: Hagen Paul Pfeifer In-Reply-To: References: <20111102014440.GB3987@nuttenaction> <52784d1883ad927db4607cc4b0f5af2e@localhost> Message-ID: <81d577dac2ff693d59aec3284cf461c4@localhost> X-Sender: hagen@jauu.net User-Agent: RoundCube Webmail/0.1-rc1 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Thu, 03 Nov 2011 10:55:36 -0000 On Wed, 2 Nov 2011 19:53:09 -0700, William Chan (陈智昌) wrote: > Note that servers often close down connections due to resource > consumption.  More sockets mean more file descriptors to check, and more > kernel socket buffers, and potentially other per-connection state (SSL > context?). It's not free. Maybe we can push on servers to keep > connections open longer, but I suspect there's some limit to how far > they're willing to go. Sure, but holding state in TCP stack is also not for free (which is required by TFO). The difference is the amount of state information. But I am sure that there is room for optimization. But SSL state is a interesting aspect: at HTTP level you get them for free, saving TLS turnarounds. > I'm jumping in late, but it looks like this comment is wrt adaptive > keep-alive mechanisms, specifically in the mobile case. I'm not sure I > understand how an adaptive keep-alive mechanism fixes anything. You seem > to indicate we should turn off TCP keep-alives when the browser goes > idle. Do you propose keeping the connection open or not? If the > connection is open, then what happens when middleboxes drop the mapping > and blackhole the connection? If the connection is closed, then when the > browser becomes active again, then we need to establish a new connection > again, in which case TFO sounds useful. Forget the "adaptive keep alive mechanism". It was a quick example how to send TCP keep alive probes in a more clever way to reduce battery consumption. I just wanted to point out that there are smarter ways to send keep-alive probes. Hagen From hkchu@google.com Thu Nov 3 12:04:49 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D771F0CC0 for ; Thu, 3 Nov 2011 12:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.075, 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 5wnIcHDf-Qik for ; Thu, 3 Nov 2011 12:04:48 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 806A11F0CBF for ; Thu, 3 Nov 2011 12:04:48 -0700 (PDT) Received: by ywt2 with SMTP id 2so1894100ywt.31 for ; Thu, 03 Nov 2011 12:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=eZeLnl4KBFk1BTsHIC0HIT7QuRbCBsKHNVe9gTNc82o=; b=weLoqw088/XGYGeLQX37rG1TF/XHV7PPzOD1nRGCZ3cswND9ooHgigOi89Y/PGBmLs 9TniF9xuLG2hyjLoWbaQ== Received: by 10.150.147.6 with SMTP id u6mr11250741ybd.2.1320346717619; Thu, 03 Nov 2011 11:58:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.147.6 with SMTP id u6mr11218118ybd.2.1320346403510; Thu, 03 Nov 2011 11:53:23 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Thu, 3 Nov 2011 11:53:23 -0700 (PDT) In-Reply-To: <81d577dac2ff693d59aec3284cf461c4@localhost> References: <20111102014440.GB3987@nuttenaction> <52784d1883ad927db4607cc4b0f5af2e@localhost> <81d577dac2ff693d59aec3284cf461c4@localhost> Date: Thu, 3 Nov 2011 11:53:23 -0700 Message-ID: From: Jerry Chu To: Hagen Paul Pfeifer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" , =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Thu, 03 Nov 2011 19:04:49 -0000 On Thu, Nov 3, 2011 at 3:55 AM, Hagen Paul Pfeifer wrote: > > On Wed, 2 Nov 2011 19:53:09 -0700, William Chan (=E9=99=88=E6=99=BA=E6=98= =8C) wrote: > > >> Note that servers often close down connections due to resource >> consumption. =C2=A0More sockets mean more file descriptors to check, and= more >> kernel socket buffers, and potentially other per-connection state (SSL >> context?). It's not free. Maybe we can push on servers to keep >> connections open longer, but I suspect there's some limit to how far >> they're willing to go. > > Sure, but holding state in TCP stack is also not for free (which is > required by TFO). Pardon me? What states and which side are you alluding to? We've worked hard to keep TFO server side stateless, with the exception of perhaps 8 bytes for a per server master key. Or perhaps you're talking abou= t the client side TFO cache? But the # of cached connections will be at most hundreds so why does it matter? >The difference is the amount of state information. But I > am sure that there is room for optimization. But SSL state is a interesti= ng > aspect: at HTTP level you get them for free, saving TLS turnarounds. > > >> I'm jumping in late, but it looks like this comment is wrt adaptive >> keep-alive mechanisms, specifically in the mobile case. I'm not sure I >> understand how an adaptive keep-alive mechanism fixes anything. You seem >> to indicate we should turn off TCP keep-alives when the browser goes >> idle. Do you propose keeping the connection open or not? If the >> connection is open, then what happens when middleboxes drop the mapping >> and blackhole the connection? If the connection is closed, then when the >> browser becomes active again, then we need to establish a new connection >> again, in which case TFO sounds useful. > > Forget the "adaptive keep alive mechanism". It was a quick example how to > send TCP keep alive probes in a more clever way to reduce battery > consumption. I just wanted to point out that there are smarter ways to se= nd > keep-alive probes. I also want to point out there are people here whose day job is to solve th= ese difficult puzzles for a living therefore proposals from them have likely been well thought of, with some obvious alternatives already considered, so please do= n't dismiss them too quickly. Best, Jerry > > > > Hagen > From hagen@jauu.net Fri Nov 4 04:13:21 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6798121F8B7D for ; Fri, 4 Nov 2011 04:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] 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 9-FJGmPpVSEq for ; Fri, 4 Nov 2011 04:13:20 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4D321F8B71 for ; Fri, 4 Nov 2011 04:13:20 -0700 (PDT) Received: from [10.48.128.243] (ip-109-45-0-20.web.vodafone.de [109.45.0.20]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by geheimer.internetendpunkt.de (Postfix) with ESMTPSA id 30162F44129; Fri, 4 Nov 2011 12:13:16 +0100 (CET) References: <20111102014440.GB3987@nuttenaction> <52784d1883ad927db4607cc4b0f5af2e@localhost> <81d577dac2ff693d59aec3284cf461c4@localhost> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----L2BKO0V3MHWUOYUDP6KXXV2RB61TGF" From: Hagen Paul Pfeifer Date: Fri, 04 Nov 2011 12:12:31 +0100 To: Jerry Chu Message-ID: Cc: "tcpm@ietf.org Extensions" , =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 11:13:21 -0000 ------L2BKO0V3MHWUOYUDP6KXXV2RB61TGF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Jerry: don't get me wrong! I wrote it in _every_ email that I like TFO. But it helps nobody if we focus blindly on TFO. Therefore I summed up all implications. And TCP state is one. I never wrote that it has a huge impact, I wrote that for Willian, case I thought he miss that. P-HTTP and remembering TLS state is another aspect which should not underestimated. Jerry, to make it clear: I don't judge TFO, I try to understand the implications, the mechanism from high level. Focus on the problem - not one solution. Excuse me Jerry if you thought that I argue against TFO - that was and is not my intention. You and the other guys from Google make a really good job, pushing TCP forward! Trust me, I really like every new ID where the author is Jerry Chu. Hagen -- Hagen Paul Pfeifer || http://jauu.net Telephone: +49 174 5455209 ------L2BKO0V3MHWUOYUDP6KXXV2RB61TGF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Jerry: don't get me wrong! I wrote it in _every_ email that I like TFO. But it helps nobody if we focus blindly on TFO. Therefore I summed up all implications. And TCP state is one. I never wrote that it has a huge impact, I wrote that for Willian, case I thought he miss that. P-HTTP and remembering TLS state is another aspect which should not underestimated.

Jerry, to make it clear: I don't judge TFO, I try to understand the implications, the mechanism from high level. Focus on the problem - not one solution.

Excuse me Jerry if you thought that I argue against TFO - that was and is not my intention. You and the other guys from Google make a really good job, pushing TCP forward! Trust me, I really like every new ID where the author is Jerry Chu.

Hagen

--
Hagen Paul Pfeifer <hagen@jauu.net> || http://jauu.net
Telephone: +49 174 5455209

------L2BKO0V3MHWUOYUDP6KXXV2RB61TGF-- From hkchu@google.com Fri Nov 4 12:19:27 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2311F0C49 for ; Fri, 4 Nov 2011 12:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmERgzbSHCw5 for ; Fri, 4 Nov 2011 12:19:27 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id EDF5E1F0C40 for ; Fri, 4 Nov 2011 12:19:26 -0700 (PDT) Received: by ywt2 with SMTP id 2so3233194ywt.31 for ; Fri, 04 Nov 2011 12:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=Ti2spPecikDZ5zdlbcKeUOMjQmpE9bJkDOWjOunDllY=; b=SY7jrtzRCGuK0vDRG/0tDmC8iSAOBHyxFJdSJMiEX/EIKZm8PhrBVlbbxspfU1Nt07 nBz66+Vo3pjgWnkIG3fg== Received: by 10.150.253.14 with SMTP id a14mr15846863ybi.32.1320434366256; Fri, 04 Nov 2011 12:19:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.253.14 with SMTP id a14mr15846837ybi.32.1320434366076; Fri, 04 Nov 2011 12:19:26 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Fri, 4 Nov 2011 12:19:26 -0700 (PDT) In-Reply-To: References: <20111102014440.GB3987@nuttenaction> <52784d1883ad927db4607cc4b0f5af2e@localhost> <81d577dac2ff693d59aec3284cf461c4@localhost> Date: Fri, 4 Nov 2011 12:19:26 -0700 Message-ID: From: Jerry Chu To: Hagen Paul Pfeifer Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" , =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 19:19:27 -0000 Hi Hagen, On Fri, Nov 4, 2011 at 4:12 AM, Hagen Paul Pfeifer wrote: > Jerry: don't get me wrong! I wrote it in _every_ email that I like TFO. Does that mean you support TFO adoption as WG item? ;-) >But > it helps nobody if we focus blindly on TFO. Therefore I summed up all > implications. And TCP state is one. I never wrote that it has a huge impact, > I wrote that for Willian, case I thought he miss that. P-HTTP and > remembering TLS state is another aspect which should not underestimated. Understood. > > Jerry, to make it clear: I don't judge TFO, I try to understand the > implications, the mechanism from high level. Focus on the problem - not one > solution. Again like Yuchung said, we never intend to pit TFO against P-HTTP. We see both have their limits and can complement each other. Therefore we object to the statement that P-HTTP is ALL one will need. The key decision for the WG right now is whether to adopt TFO as a WG item. We have both data showing TFO adds performance benefits ON TOP OF P-HTTP, and all the technical reasons why P-HTTP alone is not sufficient. I hope for your support and the WG can proceed to adopt TFO asap. > > Excuse me Jerry if you thought that I argue against TFO - that was and is > not my intention. You and the other guys from Google make a really good job, > pushing TCP forward! Trust me, I really like every new ID where the author > is Jerry Chu. Please don't single me out - it's a lot of hard work from my colleagues. It has not been easy because at the end of the day Google judges our performance at work not by how many I-Ds we produce (easier part), but how much real performance improvement we have delivered (difficult). Jerry > > Hagen > > -- > Hagen Paul Pfeifer || http://jauu.net > Telephone: +49 174 5455209 > > From ycheng@google.com Mon Nov 7 14:17:12 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471BA21F8B0A for ; Mon, 7 Nov 2011 14:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.819 X-Spam-Level: X-Spam-Status: No, score=-102.819 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, 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 QmVaDRrJpm8m for ; Mon, 7 Nov 2011 14:17:11 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B27EA21F8AFF for ; Mon, 7 Nov 2011 14:17:11 -0800 (PST) Received: by qadc10 with SMTP id c10so4941767qad.31 for ; Mon, 07 Nov 2011 14:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=XfVK2TiVbfSakoUH6rVeVkl5ywO0q4F9DB/USJRovmI=; b=rbJqSttyWJbR4BpnPa22/ZzNF7VoOUf+aiRRcAE4FRJs+nH/1BFX/IgxZt44WCrz53 UM8s7vJHVdZhAkN6eWlw== Received: by 10.224.194.193 with SMTP id dz1mr13267353qab.62.1320704231257; Mon, 07 Nov 2011 14:17:11 -0800 (PST) Received: by 10.224.194.193 with SMTP id dz1mr13267345qab.62.1320704231124; Mon, 07 Nov 2011 14:17:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.54.137 with HTTP; Mon, 7 Nov 2011 14:16:50 -0800 (PST) In-Reply-To: <45FC67B2-849B-4A95-8E56-372BF23DDBBF@isi.edu> References: <20111102014440.GB3987@nuttenaction> <45FC67B2-849B-4A95-8E56-372BF23DDBBF@isi.edu> From: Yuchung Cheng Date: Mon, 7 Nov 2011 14:16:50 -0800 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 07 Nov 2011 22:17:12 -0000 On Tue, Nov 1, 2011 at 11:35 PM, Joe Touch wrote: > > A better question is what the significant advantage is for fastopen *assuming* P-HTTP. This is a great question! In our paper (section 2.2), we measure the TCP connection overhead of millions of HTTP transactions from the Chrome browser in 2011 over a period of 28 days. We find TFO can potentially improves the latency by 25% for 80% connections. This assumes Chrome keeps current p-HTTP setttings. Our paper is available at: http://research.google.com/pubs/archive/37517.pdf From iesg-secretary@ietf.org Mon Nov 7 19:37:23 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5758911E80EB; Mon, 7 Nov 2011 19:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 4ShsYkenJ2kl; Mon, 7 Nov 2011 19:37:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF60F11E80DA; Mon, 7 Nov 2011 19:37:22 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111108033722.13362.60275.idtracker@ietfa.amsl.com> Date: Mon, 07 Nov 2011 19:37:22 -0800 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (The NewReno Modification to TCP's Fast Recovery Algorithm) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 03:37:23 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'The NewReno Modification to TCP's Fast Recovery Algorithm' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-11-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc3782-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc3782-bis/ No IPR declarations have been submitted directly on this I-D. From yoshifumi.nishida@gmail.com Wed Nov 9 00:28:34 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1A921F8B3B for ; Wed, 9 Nov 2011 00:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.745 X-Spam-Level: X-Spam-Status: No, score=-102.745 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, 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 IPskojw6LNHW for ; Wed, 9 Nov 2011 00:28:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E62821F8AF2 for ; Wed, 9 Nov 2011 00:28:34 -0800 (PST) Received: by iaeo4 with SMTP id o4so1927089iae.31 for ; Wed, 09 Nov 2011 00:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PMWQOlO64sYCNTmtJx7bF+ZBnApO0IVsqEy2LIH9C7A=; b=hLj/t3zry/4xmN1KvhDbIAPMNJQXWabnEDIoXu9vx9+yP48Vq/T/6GGG1BPjAZLC1L MG7mKNWhxjZpD/ShjyLYGbpwE5NsJIj66tTtM5WyZqO4+Wa4WGqtlckv4vvvbb6DUHbO r6AXBbl4AK6W3+x9U1tNk4plgDWZ4rqtohUnM= MIME-Version: 1.0 Received: by 10.231.0.208 with SMTP id 16mr319032ibc.50.1320827313692; Wed, 09 Nov 2011 00:28:33 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.154.75 with HTTP; Wed, 9 Nov 2011 00:28:33 -0800 (PST) In-Reply-To: References: <20111102014440.GB3987@nuttenaction> <45FC67B2-849B-4A95-8E56-372BF23DDBBF@isi.edu> Date: Wed, 9 Nov 2011 00:28:33 -0800 X-Google-Sender-Auth: 3OJ7DSXZLiPIONqenJ_eZ0U0e_k Message-ID: From: Yoshifumi Nishida To: Yuchung Cheng Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Wed, 09 Nov 2011 08:28:34 -0000 Hi Yuchung, Jerry, I think the result for TFO in the paper is very good. But, I'm wondering why it's so good.. For example, in case of TCP wikipedia page, TFO reduces PLT 150msec with 20msec RTT. This is 7.5 RTTs. I can imagine the page consists of various resources from different hosts and there are some limits for the number of concurrent connections in Chrome. But, still.. 7.5 RTTs seems to be a bit big value to me.. Am I missing something? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/11/7 Yuchung Cheng : > On Tue, Nov 1, 2011 at 11:35 PM, Joe Touch wrote: >> >> A better question is what the significant advantage is for fastopen *assuming* P-HTTP. > > This is a great question! > > In our paper (section 2.2), we measure the TCP connection overhead of > millions of HTTP transactions from the Chrome browser in 2011 over a > period of 28 days. We find TFO can potentially improves the latency by > 25% for 80% connections. This assumes Chrome keeps current p-HTTP > setttings. > > Our paper is available at: http://research.google.com/pubs/archive/37517.pdf > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From wes@mti-systems.com Wed Nov 9 06:51:11 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DA721F8C4E for ; Wed, 9 Nov 2011 06:51:11 -0800 (PST) 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=[AWL=0.000, 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 UipPk0+LsO64 for ; Wed, 9 Nov 2011 06:51:11 -0800 (PST) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id DDEB921F8C4B for ; Wed, 9 Nov 2011 06:51:10 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pA9Ep7k5018055 for ; Wed, 9 Nov 2011 09:51:09 -0500 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.45.35.254] ([107.45.35.254:59846] helo=[68.245.171.115]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 46/15-05187-A539ABE4; Wed, 09 Nov 2011 09:51:07 -0500 Message-ID: <4EBA935D.9000503@mti-systems.com> Date: Wed, 09 Nov 2011 09:51:09 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Joe Touch References: <20111024215310.10139.23464.idtracker@ietfa.amsl.com> <4EA5DF5F.8090407@isi.edu> In-Reply-To: <4EA5DF5F.8090407@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-experimental-options-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 14:51:11 -0000 On 10/24/2011 5:57 PM, Joe Touch wrote: > Hi, all, > > The following document describes an informal proposal I made on the list > a while back. Hopefully we can discuss it in Taiwan. > After reading and thinking about it, I think we should adopt this. I think this should be more than just Informational, if people agree that it's the best way to disambiguate between concurrent experiments, then I would think that it should be a Best Current Practice. Some specific comments: - I believe there are other devices (e.g. Bluecoat) that are also using the experimental codepoints (not just the AO precursor and the TCP-CT code). - We might add some analysis that says: Hosts (or routers) that have deployed the pre-TCP-AO option using the experimental codepoints will generally be limited to BGP-speakers or other infrastructure, and not consumer devices or servers at the edges of the network that would be participating in other TCP experiments. There is not expected to be an issue with use of this nonce for new experimental options to conflict with these. Middleboxes deployed using the experimental codepoints for discovering each other are expected to pass-through experimental options using the nonce discussed in this document, based on discussion with the vendor. These middleboxes have their own mechanism for disambiguating their use of the codepoints from other uses. - I think we would encourage new experimental options to strongly make use of this nonce mechanism, but say something about the fact that if they don't, their odds of causing trouble for other experimental options that do use a nonce are small, however the odds of code that uses non-nonced options getting confused while attempting to parse nonced options may be greater! Thus, it's strongly encouraged to use a nonced format, and in one's best interest. - Consider borrowing (or adapting) some of the text from section 1 of draft-eddy-tcpm-addl-exp-options-00, in order to motivate why we need to encourage this rather than continue to allow the option space to be reduced by squatting. Thanks for writing this! -- Wes Eddy MTI Systems From Michael.Scharf@alcatel-lucent.com Thu Nov 10 11:22:05 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979DA21F8ADC; Thu, 10 Nov 2011 11:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_DE=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 eCq31xWc-oT6; Thu, 10 Nov 2011 11:22:04 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 7E79621F8A6C; Thu, 10 Nov 2011 11:22:04 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id pAAJM2Pt027319; Thu, 10 Nov 2011 20:22:02 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 10 Nov 2011 20:21:59 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0693A8B4@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Current status of TCPM Thread-Index: Acyf3gRspP5Rq7hWStOd1YdeEE1iVA== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Cc: tcpm-chairs@ietf.org Subject: [tcpm] Current status of TCPM 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, 10 Nov 2011 19:22:05 -0000 Dear all, please find below the current status of drafts in TCPM, as far as I am aware of it. Please let the chairs know if you have any comments, preferably before the TCPM meeting next week. Thanks Michael (TCPM co-chair) Recent RFCs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 WG Items Nearing RFC Publication =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Clarification of sender behavior in persist condition=20 draft-ietf-tcpm-persist Milestone Target: Informational Status: RFC Editor Queue 1948bis draft-ietf-tcpm-rfc1948bis Milestone Target: Proposed Standard in September 2011 Status: IESG processing The NewReno Modification to TCP's Fast Recovery Algorithm draft-ietf-tcpm-rfc3782-bis Milestone Target: Proposed Standard in April 2011 Status: IESG processing WG Items in WGLC or being revised after WGLC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MSS Option draft-ietf-tcpm-tcpmss Milestone Target: Proposed Standard in July 2009 Status: Needs revision Action: Action with David Borman Active WG Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1323bis draft-ietf-tcpm-1323bis Milestone Target: Proposed Standard in July 2009 Status: Needs revision Action: Action with David Borman SACK Entry / RFC 3517bis draft-blanton-tcpm-3517bis Milestone Target: Proposed Standard in October 2010 Status: Probably ready for WGLC Action: WGLC planned TCP Security draft-ietf-tcpm-tcp-security Milestone Target: BCP in August 2010 Status: Content needs work, draft expired Action: Potential removal of charter item Increasing the Initial Window draft-ietf-tcpm-initcwnd Milestone Target: Experimental in September 2011 Status: WG consensus on experimental track Action: Document update needed Proportional Rate Reduction for TCP draft-ietf-tcpm-proportional-rate-reduction Milestone Target: Experimental in May 2012 Status: Under active discussion / review Action: Continue discussion Documents Under a Poll to Become WG Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Active Internet-Drafts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TCP Fast Open draft-cheng-tcpm-fastopen Status: Discussions on list, some support for adoption in IETF 81, no clear consensus so far Action: Presentation at IETF 82 Shared Use of Experimental TCP Options draft-touch-tcpm-experimental-options Status: Some discussions on list Action: Presentation at IETF 82 Automating the Initial Window in TCP draft-touch-tcpm-automatic-iw Status: Interest in working group, but no consensus on adoption in IETF 81 Action: Document update needed, presentation at IETF 82 Accurate ECN Feedback in TCP draft-kuehlewind-conex-accurate-ecn Status: Discussion moved from CONEX to TCPM Action: Presentation at IETF 82 =20 Accurate ECN Feedback Option in TCP draft-kuehlewind-tcpm-accurate-ecn-option Status: New draft Action: Presentation at IETF 82 Additional negotiation in the TCP Timestamp Option field during the TCP handshake draft-scheffenegger-tcpm-timestamp-negotiation Status: Presented at IETF 80, discussions on list Action: Presentation at IETF 82 TCP and SCTP RTO Restart draft-hurtig-tcpm-rtorestart Status: New draft Action: Presentation at IETF 82 (+ many expired Internet-Drafts) From hkchu@google.com Sun Nov 13 23:37:41 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB40911E80C2 for ; Sun, 13 Nov 2011 23:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.093 X-Spam-Level: X-Spam-Status: No, score=-102.093 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 bHkp++q-vqkS for ; Sun, 13 Nov 2011 23:37:41 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id F317611E80B6 for ; Sun, 13 Nov 2011 23:37:40 -0800 (PST) Received: by gye5 with SMTP id 5so5576356gye.31 for ; Sun, 13 Nov 2011 23:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=ejOHVQNickIESxSLJhnDVv1es4CY108kPwDk1LJR4NQ=; b=KjRp7ksLeV3n+u1XNKaUsr0o3qk6cJMTgXZXeF+0UQoIZEqbV7xsqnKsLBWsQt2/F0 iAWeqCZukUsxRIN/3T0w== Received: by 10.236.180.101 with SMTP id i65mr12657937yhm.21.1321256258980; Sun, 13 Nov 2011 23:37:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.180.101 with SMTP id i65mr12657919yhm.21.1321256258772; Sun, 13 Nov 2011 23:37:38 -0800 (PST) Received: by 10.150.43.30 with HTTP; Sun, 13 Nov 2011 23:37:38 -0800 (PST) In-Reply-To: <4EA5DF5F.8090407@isi.edu> References: <20111024215310.10139.23464.idtracker@ietfa.amsl.com> <4EA5DF5F.8090407@isi.edu> Date: Sun, 13 Nov 2011 23:37:38 -0800 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: multipart/alternative; boundary=20cf305e27e3f61e8104b1acf1ce X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-experimental-options-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 07:37:42 -0000 --20cf305e27e3f61e8104b1acf1ce Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, On Mon, Oct 24, 2011 at 2:57 PM, Joe Touch wrote: > Hi, all, > > The following document describes an informal proposal I made on the list a > while back. Hopefully we can discuss it in Taiwan. > This sounds like a good idea, to remove IANA involvement hence encouraging more rapid experiments, at a small cost of using more bytes in the precious option space. I have only a couple of comments: 1. "The nonce is selected by the protocol designer when the experimental option is defined. The Nonce is selected any of a variety of ways, e.g., using the Unix time() command or bits selected by an arbitrary function (such as a hash)." Although the first sentence above was clear in saying the nonce was picked statically at the design time, the second sentence almost sounded like one picked dynamically. Also I wonder besides pure randomness, is there other idea the can be used to further minimize the chance of collision, e.g., including the length field as a differentiator or embedding some notion of calendar time in the nonce... 2. "The length of the nonce is intended to be 32 bit in network standard byte order. It can be shorter if desired (e.g., 16 bits), with a corresponding increased probability of collision and thus false positives." Is one byte nonce allowed, considering how tight the option space has become thus every byte of saving counts, or it's not worth the saving because most stack implementations choose to alight each option...? Also is the choice of the nonce size all up to the protocol designers? If so, perhaps some guideline can be provided on how to minimize the chance of collision. E.g., an experimental option with a data field containing possibly wide range of value may suffice with just one byte nonce because the chance of collision is low (?). Also should the length field be considered as a differentiator when choosing the size of the nonce? Jerry > Joe > > -------- Original Message -------- > Subject: New Version Notification for draft-touch-tcpm-experimental-** > options-00.txt > Date: Mon, 24 Oct 2011 14:53:10 -0700 > From: internet-drafts@ietf.org > To: touch@isi.edu > CC: touch@isi.edu > > A new version of I-D, draft-touch-tcpm-experimental-**options-00.txt has > been successfully submitted by Joe Touch and posted to the IETF repository. > > Filename: draft-touch-tcpm-experimental-**options > Revision: 00 > Title: Shared Use of Experimental TCP Options > Creation date: 2011-10-24 > WG ID: Individual Submission > Number of pages: 6 > > Abstract: > This document describes how TCP option codepoints can support > concurrent experiments. The suggested mechanism avoids the need for > a coordinated registry, and is backward-compatible with currently > known uses. > > > > > > The IETF Secretariat > ______________________________**_________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/**listinfo/tcpm > --20cf305e27e3f61e8104b1acf1ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joe,

On Mon, Oct 24, 2011 at 2:57 PM,= Joe Touch <touch@isi= .edu> wrote:
Hi, all,

The following document describes an informal proposal I made on the list a = while back. Hopefully we can discuss it in Taiwan.
This sounds like a good idea, to remove IANA involvement hence = encouraging more
rapid experiments, at a small cost of using more bytes in the precious= option space.

I have only a couple of comments:

1. "The nonce is selected by the protocol desi= gner when the experimental
=A0 =A0option is defined. The Nonce is selected any of a variety of wa= ys,
=A0 =A0e.g., using the Unix time() command or bits selected b= y an arbitrary
=A0 =A0function (such as a hash)."
=
Although the first sentence above was clear in saying the nonce was pi= cked
statically at the design time, the second sentence almost so= unded like one
picked dynamically.

Also = I wonder besides pure randomness, is there other idea=A0the can be used
to further minimize the chance of collision, e.g., including the lengt= h field as
a differentiator or embedding some notion of calendar = time in the nonce...

2. "The length of the no= nce is intended to be 32 bit in network standard
=A0 =A0byte order. It can be shorter if desired (e.g., 16 bits), with = a
=A0 =A0corresponding increased probability of collision and thu= s false
=A0 =A0positives."

Is one b= yte nonce allowed, considering how tight the option space has
become thus every byte of saving counts, or it's not worth the sav= ing
because most stack implementations choose to alight each opti= on...?

Also is the choice of the nonce size all up= to the protocol designers?
If so, perhaps some guideline can be provided on how to minimize the
chance of collision. E.g., an experimental option with a data fiel= d containing
possibly wide range of value may suffice with just o= ne byte nonce because
the chance of collision is low (?). Also should the length field be co= nsidered
as a differentiator when choosing the size of the nonce?=

Jerry


Joe

-------- Original Message --------
Subject: New Version Notification for draft-touch-tcpm-experimental-= options-00.txt
Date: Mon, 24 Oct 2011 14:53:10 -0700
From: interne= t-drafts@ietf.org
To: touch@isi.edu CC: touch@isi.edu
A new version of I-D, draft-touch-tcpm-experimental-options-00.txt h= as been successfully submitted by Joe Touch and posted to the IETF reposito= ry.

Filename: =A0 =A0 =A0 =A0draft-touch-tcpm-experimental-options
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Shared Use of Experimental TCP Options
Creation date: =A0 2011-10-24
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 6

Abstract:
=A0 This document describes how TCP option codepoints can support
=A0 concurrent experiments. The suggested mechanism avoids the need for =A0 a coordinated registry, and is backward-compatible with currently
=A0 known uses.





The IETF Secretariat
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--20cf305e27e3f61e8104b1acf1ce-- From per.hurtig@gmail.com Tue Nov 15 03:43:37 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AD41F0C80 for ; Tue, 15 Nov 2011 03:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 RvC61+2KXE3l for ; Tue, 15 Nov 2011 03:43:36 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 404641F0C76 for ; Tue, 15 Nov 2011 03:43:36 -0800 (PST) Received: by iaeo4 with SMTP id o4so10786601iae.31 for ; Tue, 15 Nov 2011 03:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2TFXEDwsvh38MQ/xdUOnTvJ/7G1Fw6KnP1DWytznawk=; b=mi/10sXWLkbcn9CJk0Pp4m3DEZd4//bNXXGTQauH5mmjl6G4lFvWvJEs4+II5VwwfY tq48XkMpluhAP4TOjclDobDCZGq+szB9B7E2FNVaO7SrzFmAcbksrVc6iBsq6mXNz8bA tN3TclIyR8US5KTulNzRvT5se4cxuhT7dIeAQ= MIME-Version: 1.0 Received: by 10.50.85.129 with SMTP id h1mr27390201igz.47.1321357412209; Tue, 15 Nov 2011 03:43:32 -0800 (PST) Sender: per.hurtig@gmail.com Received: by 10.231.15.201 with HTTP; Tue, 15 Nov 2011 03:43:32 -0800 (PST) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F025ED3@SACEXCMBX02-PRD.hq.netapp.com> References: <20111029192848.4798.45100.idtracker@ietfa.amsl.com> <012C3117EDDB3C4781FD802A8C27DD4F025ED3@SACEXCMBX02-PRD.hq.netapp.com> Date: Tue, 15 Nov 2011 12:43:32 +0100 X-Google-Sender-Auth: Z9YY0SAAxmeSfFPp1mI1VISxWzs Message-ID: From: "Per Hurtig (work)" To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] Fwd: New Version Notification fordraft-hurtig-tcpm-rtorestart-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: Tue, 15 Nov 2011 11:43:37 -0000 Hi Richard, I read your draft, and I really like it. I think it would be nice to to use your changes to simplify the implementation of the modified restart, at least for stacks that do not hold per-packet state info Regards, Per On Thu, Nov 3, 2011 at 10:57, Scheffenegger, Richard wrote: > Hi Per, > > > I was wondering if our proposed semantic changes of RFC1323 in draft-sche= ffenegger-tcpm-timestamp-negotiation-03.txt would allow all the byte-orient= ed, non-linux derived stacks to benefit from your proposal as well... > > With RFC1323, the timestamp value echoed back to the sender contains the = TSval of the oldest, in-sequence received segment. As such, the TSecr in an= ACK cannot directly be used to find the time when a particular segment was= actually sent and covered in the ACK. This leads to the very stateful appr= oach taken in linux (the 2nd issue is, that RFC1323 TSecr is not protected = against spoofing/alteration, opening a nice attack surface against any time= -based algorithm). > > Unfortunately, in my experience, the majority of tcp stacks does not hold= per-segment state information. > > > Our proposal is to also modify the semantics of RFC1323, which timestamp = should be reflected in an ACK - provided the TCP session is also using SACK= (SCTP always uses SACK). Thus the TSecr will contain the exact timestamp w= hen the last segment triggering the ACK was sent. > > So each ACK gives a more accurate probe of the current network RTT, poten= tially allowing better estimates of the RTO that may not need to artificial= ly delayed by 1 RTT before expiring... > > Best regards, > > > Richard Scheffenegger > > >> -----Original Message----- >> From: Per Hurtig (work) [mailto:per.hurtig@kau.se] >> Sent: Sonntag, 30. Oktober 2011 17:30 >> To: tcpm >> Subject: [tcpm] Fwd: New Version Notification fordraft-hurtig-tcpm- >> rtorestart-01.txt >> >> Hi all, >> >> we've updated the TCP/SCTP RTO restart draft. The main difference >> between this version and the previous one is that the modified restart >> approach only is conducted for data-limited traffic and that the intende= d >> status of the draft has changed to experimental. Hope we can discuss it = in >> Taipei. >> >> Regards, >> Per >> >> ---------- Forwarded message ---------- >> From: internet-drafts@ietf.org >> Date: Sat, 29 Oct 2011 12:28:48 -0700 >> Subject: New Version Notification for draft-hurtig-tcpm-rtorestart-01.tx= t >> To: per.hurtig@kau.se >> Cc: per.hurtig@kau.se, michawe@ifi.uio.no, apetlund@simula.no >> >> A new version of I-D, draft-hurtig-tcpm-rtorestart-01.txt has been >> successfully submitted by Per Hurtig and posted to the IETF repository. >> >> Filename: =A0 =A0 =A0draft-hurtig-tcpm-rtorestart >> Revision: =A0 =A0 =A001 >> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 TCP and SCTP RTO Restart >> Creation date: =A0 =A0 =A0 =A0 2011-10-29 >> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission >> Number of pages: 9 >> >> Abstract: >> =A0 =A0This document describes a modified algorithm for managing the TCP= and >> =A0 =A0SCTP retransmission timers, that provides faster loss recovery wh= en a >> =A0 =A0connection's amount of outstanding data is small. =A0The modi= fication >> =A0 =A0allows the transport to restart its retransmission timer more >> =A0 =A0aggressively in situations where fast retransmit can not be used. >> =A0 =A0This enables faster loss detection, and recovery, for connections >> =A0 =A0that are short-lived or application-limited. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > From ycheng@google.com Tue Nov 15 12:54:34 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64FA11E809B for ; Tue, 15 Nov 2011 12:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, 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 vTHW6JnIpEep for ; Tue, 15 Nov 2011 12:54:30 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2249E11E8073 for ; Tue, 15 Nov 2011 12:54:24 -0800 (PST) Received: by vws5 with SMTP id 5so8051983vws.31 for ; Tue, 15 Nov 2011 12:54:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=bJCTdezIG9rD5+0hp6L8hnsTnyzB0tqLwVrAssonhw8=; b=KLUWbpX8jyM7j7k5CxAYwH9aj3ThwaJaaX6i6xQ3DViDu4gdHcmYEOnBPzEplpGOE/ 8TzRwNnwGmn4OVEyHCaQ== Received: by 10.224.210.200 with SMTP id gl8mr19094444qab.26.1321390464364; Tue, 15 Nov 2011 12:54:24 -0800 (PST) Received: by 10.224.210.200 with SMTP id gl8mr19094431qab.26.1321390464097; Tue, 15 Nov 2011 12:54:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.54.137 with HTTP; Tue, 15 Nov 2011 12:54:03 -0800 (PST) In-Reply-To: References: <20111102014440.GB3987@nuttenaction> <45FC67B2-849B-4A95-8E56-372BF23DDBBF@isi.edu> From: Yuchung Cheng Date: Tue, 15 Nov 2011 12:54:03 -0800 Message-ID: To: Yoshifumi Nishida Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Tue, 15 Nov 2011 20:54:34 -0000 Hi Yoshifumi, Sorry for the late response. I hope it is =A0not too late for the meeting t= oday. The large improvement of the particular case in your email was due to the compounded effect of RTT savings.=A0Here is=A0the network latency waterfall graph of Chrome fetching "http://en.wikipedia.org/wiki/Transmission_Control_Protocol" using regular TCP with 200ms RTT. http://3.bp.blogspot.com/-8Jk-EpTjtvo/TsLNuybnRhI/AAAAAAAAAC0/b5uDDZEp25o/s= 1600/tcp-wiki-200ms.png The TCP wikipedia page has total 58 objects from 3 domains {en,bits,upload}.wikimedia.org.=A0The network latency of each object download is shown as a colored bar that includes DNS/TCP/server processing. I marked red points =A0on the cold requests that incur TCP handshakes. There are 14 total such cold requests, i.e., Chrome opens 14 TCP connections total. If TFO was used, these 14 cold requests will each gets 200ms faster. A majority of them help later requests to load earlier and the compounded saving becomes large. I am happy to share the steps to produce this graph if people are intereste= d. On Wed, Nov 9, 2011 at 12:28 AM, Yoshifumi Nishida wrote: > > Hi Yuchung, Jerry, > > I think the result for TFO in the paper is very good. But, I'm wondering = why > it's so good.. > For example, in case of TCP wikipedia page, TFO reduces PLT 150msec > with 20msec RTT. This is 7.5 RTTs. > I can imagine the page consists of various resources from different hosts= and > there are some limits for the number of concurrent connections in Chrome. > But, still.. 7.5 RTTs seems to be a bit big value to me.. > Am I missing something? > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > > 2011/11/7 Yuchung Cheng : > > On Tue, Nov 1, 2011 at 11:35 PM, Joe Touch wrote: > >> > >> A better question is what the significant advantage is for fastopen *a= ssuming* P-HTTP. > > > > This is a great question! > > > > In our paper (section 2.2), we measure the TCP connection overhead of > > millions of HTTP transactions from the Chrome browser in 2011 over a > > period of 28 days. We find TFO can potentially improves the latency by > > 25% for 80% connections. This assumes Chrome keeps current p-HTTP > > setttings. > > > > Our paper is available at: http://research.google.com/pubs/archive/3751= 7.pdf > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > From ycheng@google.com Tue Nov 15 13:06:55 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535E721F86F6 for ; Tue, 15 Nov 2011 13:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.898 X-Spam-Level: X-Spam-Status: No, score=-102.898 tagged_above=-999 required=5 tests=[AWL=0.079, 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 hw+ro6fAPMba for ; Tue, 15 Nov 2011 13:06:54 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C553E21F86DD for ; Tue, 15 Nov 2011 13:06:54 -0800 (PST) Received: by ywt34 with SMTP id 34so6877101ywt.31 for ; Tue, 15 Nov 2011 13:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=8WlxaXrDsNiprvPWnTS1Sydb5HwP9sPGzSmBHgTohS8=; b=XXxZjt2/Cv0r2hYsIZT3qZa54MeLvcqbO0loDN6xpwRD4dBC3Hu+QHguL3fovUVpMj 32fWU0cpzw982iRB0PWw== Received: by 10.224.73.4 with SMTP id o4mr17208363qaj.62.1321391214297; Tue, 15 Nov 2011 13:06:54 -0800 (PST) Received: by 10.224.73.4 with SMTP id o4mr17208353qaj.62.1321391214139; Tue, 15 Nov 2011 13:06:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.54.137 with HTTP; Tue, 15 Nov 2011 13:06:33 -0800 (PST) In-Reply-To: References: <20111024215310.10139.23464.idtracker@ietfa.amsl.com> <4EA5DF5F.8090407@isi.edu> From: Yuchung Cheng Date: Tue, 15 Nov 2011 13:06:33 -0800 Message-ID: To: Jerry Chu Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-experimental-options-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 21:06:55 -0000 I also support this draft and have similar comments to Jerry's plus: If we expect running implementations, shouldn't the target status be standard? From ycheng@google.com Tue Nov 15 13:50:07 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB8211E80ED for ; Tue, 15 Nov 2011 13:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.914 X-Spam-Level: X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=0.063, 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 zS6ffED8ytpf for ; Tue, 15 Nov 2011 13:50:03 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DAAEA11E80EB for ; Tue, 15 Nov 2011 13:50:02 -0800 (PST) Received: by vws5 with SMTP id 5so8117458vws.31 for ; Tue, 15 Nov 2011 13:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=j1diqfSzLaPZh5Xg2zMSFD6K9JJWj/FhPrOx8+Zsrlo=; b=XW7emlISUT9acTQ4kfLPDKS+z1Q8DAZzIxGXKI8/Xdas4H0pEeGlnS4h0aZPcvnbRV ipJ7PirN0BZfGYB+7fTg== Received: by 10.224.200.197 with SMTP id ex5mr18867818qab.88.1321393802243; Tue, 15 Nov 2011 13:50:02 -0800 (PST) Received: by 10.224.200.197 with SMTP id ex5mr18867807qab.88.1321393802099; Tue, 15 Nov 2011 13:50:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.54.137 with HTTP; Tue, 15 Nov 2011 13:49:41 -0800 (PST) In-Reply-To: References: <20111029192848.4798.45100.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Tue, 15 Nov 2011 13:49:41 -0800 Message-ID: To: "Per Hurtig (work)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm , mallman@icir.org Subject: Re: [tcpm] Fwd: New Version Notification for draft-hurtig-tcpm-rtorestart-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: Tue, 15 Nov 2011 21:50:07 -0000 I think this proposal is interesting but would like to see some larger-scale TCP measurements to support this argument, since it's been debated in several papers: [LS00] first discovered this "bug" In Ekstr=F6m, H., & Ludwig, R. (2004). The peak-hopper: A new endto-end retransmission timer for reliable unicast transport. In Proceedings of the IEEE INFOCOM. The author reverted his point in [LS00] and claimed it offers a safety margin due to two other under-estimation issues in current 2988 RTO calculation. Section 4.3 of your paper =A0"SCTP: designed for timely message delivery?", you seem to agree that this cushion make sense in TCP? Thanks. On Sun, Oct 30, 2011 at 9:30 AM, Per Hurtig (work) wrot= e: > Hi all, > > we've updated the TCP/SCTP RTO restart draft. The main difference > between this version and the previous one is that the modified restart > approach only is conducted for data-limited traffic and that the > intended status of the draft has changed to experimental. Hope we can > discuss it in Taipei. > > Regards, > Per > > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > Date: Sat, 29 Oct 2011 12:28:48 -0700 > Subject: New Version Notification for draft-hurtig-tcpm-rtorestart-01.txt > To: per.hurtig@kau.se > Cc: per.hurtig@kau.se, michawe@ifi.uio.no, apetlund@simula.no > > A new version of I-D, draft-hurtig-tcpm-rtorestart-01.txt has been > successfully submitted by Per Hurtig and posted to the IETF > repository. > > Filename: =A0 =A0 =A0 =A0draft-hurtig-tcpm-rtorestart > Revision: =A0 =A0 =A0 =A001 > Title: =A0 =A0 =A0 =A0 =A0 TCP and SCTP RTO Restart > Creation date: =A0 2011-10-29 > WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission > Number of pages: 9 > > Abstract: > =A0 This document describes a modified algorithm for managing the TCP and > =A0 SCTP retransmission timers, that provides faster loss recovery when a > =A0 connection's amount of outstanding data is small. =A0The modifica= tion > =A0 allows the transport to restart its retransmission timer more > =A0 aggressively in situations where fast retransmit can not be used. > =A0 This enables faster loss detection, and recovery, for connections > =A0 that are short-lived or application-limited. > > > > > The IETF Secretariat > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From touch@isi.edu Tue Nov 15 14:14:32 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F1D21F85A7 for ; Tue, 15 Nov 2011 14:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.292 X-Spam-Level: X-Spam-Status: No, score=-106.292 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, 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 ZFH2erdnKbwf for ; Tue, 15 Nov 2011 14:14:28 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id C6EF621F8573 for ; Tue, 15 Nov 2011 14:14:27 -0800 (PST) Received: from [172.20.0.82] (203-69-99-17.HINET-IP.hinet.net [203.69.99.17] (may be forged)) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id pAFMDSAl006023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Nov 2011 14:13:39 -0800 (PST) Message-ID: <4EC2E406.1040105@isi.edu> Date: Tue, 15 Nov 2011 14:13:26 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Yuchung Cheng References: <20111102014440.GB3987@nuttenaction> <45FC67B2-849B-4A95-8E56-372BF23DDBBF@isi.edu> 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 Extensions" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Tue, 15 Nov 2011 22:14:32 -0000 Some questions: - what kind of net connection are you using that has 200ms RTTs? - do you know that the request was always completely in the first packet? if not, you won't save the first RTT (though this is likely) - TCP-FO won't help with the truly "cold" opens of these 14, which ones are to places likely to be revisited by subsequent connections? - what is the overall benefit? look at the 6 sets that line up vertically and label them: A - connection 1 B - connection 2-4 C - connection 8 D - connection 11 E - connections 15, 17-22 F - connection 37 -- at best, those are the 6 200-ms chunks you're saving, not 14 However, you're ignoring the impact of other non-spedup connections; when you take them into account, you see a critical path of dependencies: 1, 9, 10, 23 in that path, you get to speedup only 1 *at best* So you will save 200ms out of this entire exchange, not 14*200. It's about time, not number. Joe On 11/15/2011 12:54 PM, Yuchung Cheng wrote: > Hi Yoshifumi, > > Sorry for the late response. I hope it is not too late for the meeting today. > > The large improvement of the particular case in your email was due to > the compounded effect of RTT savings. Here is the network latency > waterfall graph of Chrome fetching > "http://en.wikipedia.org/wiki/Transmission_Control_Protocol" using > regular TCP with 200ms RTT. > http://3.bp.blogspot.com/-8Jk-EpTjtvo/TsLNuybnRhI/AAAAAAAAAC0/b5uDDZEp25o/s1600/tcp-wiki-200ms.png > > The TCP wikipedia page has total 58 objects from 3 domains > {en,bits,upload}.wikimedia.org. The network latency of each object > download is shown as a colored bar that includes DNS/TCP/server > processing. I marked red points on the cold requests that incur TCP > handshakes. There are 14 total such cold requests, i.e., Chrome opens > 14 TCP connections total. > > If TFO was used, these 14 cold requests will each gets 200ms faster. A > majority of them help later requests to load earlier and the > compounded saving becomes large. > > I am happy to share the steps to produce this graph if people are interested. > > > > On Wed, Nov 9, 2011 at 12:28 AM, Yoshifumi Nishida > wrote: >> >> Hi Yuchung, Jerry, >> >> I think the result for TFO in the paper is very good. But, I'm wondering why >> it's so good.. >> For example, in case of TCP wikipedia page, TFO reduces PLT 150msec >> with 20msec RTT. This is 7.5 RTTs. >> I can imagine the page consists of various resources from different hosts and >> there are some limits for the number of concurrent connections in Chrome. >> But, still.. 7.5 RTTs seems to be a bit big value to me.. >> Am I missing something? >> >> Thanks, >> -- >> Yoshifumi Nishida >> nishida@sfc.wide.ad.jp >> >> 2011/11/7 Yuchung Cheng: >>> On Tue, Nov 1, 2011 at 11:35 PM, Joe Touch wrote: >>>> >>>> A better question is what the significant advantage is for fastopen *assuming* P-HTTP. >>> >>> This is a great question! >>> >>> In our paper (section 2.2), we measure the TCP connection overhead of >>> millions of HTTP transactions from the Chrome browser in 2011 over a >>> period of 28 days. We find TFO can potentially improves the latency by >>> 25% for 80% connections. This assumes Chrome keeps current p-HTTP >>> setttings. >>> >>> Our paper is available at: http://research.google.com/pubs/archive/37517.pdf >>> _______________________________________________ >>> 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 Michael.Scharf@alcatel-lucent.com Tue Nov 15 19:57:00 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21C611E8185 for ; Tue, 15 Nov 2011 19:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=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 1TalN-EKaRMD for ; Tue, 15 Nov 2011 19:57:00 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4C311E817F for ; Tue, 15 Nov 2011 19:56:59 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id pAG3uveE007128 for ; Wed, 16 Nov 2011 04:56:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 04:56:54 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0693AA51@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Many thanks to Yoshifumi and Matt Thread-Index: AcykE8ctamolJj3SQL2WxvRLKN4qOA== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Subject: [tcpm] Many thanks to Yoshifumi and Matt 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, 16 Nov 2011 03:57:00 -0000 I'd like to really thank again Yoshifumi and Matt for helping the TCPM chairs with the organization of the TCPM meeting. As fas as I could hear from the audio stream, they did a tremendous job. And apparently the discussions were really good and it was worth having held this face-to-face meeting. I apologize for not being there in person. Michael From rs@netapp.com Thu Nov 17 16:45:30 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE9C11E80E3 for ; Thu, 17 Nov 2011 16:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, 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 epXxPGuFHyJw for ; Thu, 17 Nov 2011 16:45:30 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1C14D11E80DD for ; Thu, 17 Nov 2011 16:45:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.69,530,1315206000"; d="scan'208";a="599817957" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 17 Nov 2011 16:45:29 -0800 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id pAI0jTbc000943 for ; Thu, 17 Nov 2011 16:45:29 -0800 (PST) Received: from VMWEXCEHT02-PRD.hq.netapp.com ([10.106.76.240]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 16:45:24 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.16]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.01.0289.001; Thu, 17 Nov 2011 16:44:32 -0800 From: "Scheffenegger, Richard" To: "tcpm@ietf.org" Thread-Topic: Timestamp semantic change Thread-Index: AcyliOMl3xGQqdUxSpiQkPNjMRBQtg== Date: Fri, 18 Nov 2011 00:45:18 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F036D2E@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: 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 X-OriginalArrivalTime: 18 Nov 2011 00:45:24.0764 (UTC) FILETIME=[5BE47DC0:01CCA58B] Subject: [tcpm] Timestamp semantic change 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, 18 Nov 2011 00:45:30 -0000 Hi, After this weeks TCPM session, Joe brought up an interesting observation. The draft proposes to change the semantics of timestamps under certain circ= umstances - i.e. when both TS capabilities and SACK is negotiated. Joe provided the following example, to perhaps revisit the way, which times= tamp to reflect during reordering events: At t0, a data segment is sent from the sender to the receiver; the receiver= ACKs with TSecr indicating t0. At t1, a data segment is sent, but delayed in the network. At t2, a data segment is sent, and received.=20 With RFC1323, the ACK would carry TSecr=3Dt0 (as that was the last in-sequ= ence data packet received).=20 The draft suggests to reflect TSecr=3Dt2 at this time, as that data packet= triggered the ACK. After the ACK was sent, the receiver now sees the data segment with t1. With RFC1323, the ACK triggered now has TSecr=3Dt1, similar to what the dr= aft stipulates. Now, the question is, which value to put into an unsolicited data packet se= nt at this time from the receiver to the sender... With RFC1323, the kept timestamp value (TS.recent) would be t1 (as the last= data segment to advance the window); however, that may lead to higher RTTv= ar and higher RTO at the sender side, that strictly necessary... It would be potentially better, to keep not the timestamp value of the last= segment that advanced the window in the receiver, but the *highest* receiv= ed Timestamp value. This would reduce the calculated RTTvar / RTO on the se= nder side, when the receiver sends data during reordering (loss) events. In= particular, when the delta between t1 and t2 is large, this can have a sig= nificant impact. I would like to discuss this with the group, if adding this to the semantic= modifications makes sense; so far, I assumed that TS.recent would be updat= ed just as with RFC1323 (whenever the window advances), but by the above de= scription, that minor change may be beneficial too.. Best regards, Richard Scheffenegger From rs@netapp.com Thu Nov 17 17:09:16 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6550111E809C for ; Thu, 17 Nov 2011 17:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Ls1jgzB62D5a for ; Thu, 17 Nov 2011 17:09:14 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0A621F90A9 for ; Thu, 17 Nov 2011 17:09:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.69,530,1315206000"; d="scan'208,217";a="599824286" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 17 Nov 2011 17:09:14 -0800 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id pAI19EoM014699 for ; Thu, 17 Nov 2011 17:09:14 -0800 (PST) Received: from VMWEXCEHT01-PRD.hq.netapp.com ([10.106.76.239]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 17:09:09 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.16]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.01.0289.001; Thu, 17 Nov 2011 17:07:53 -0800 From: "Scheffenegger, Richard" To: "tcpm (tcpm@ietf.org)" Thread-Topic: accurate ECN feedback Thread-Index: Acyli2JgdBJ7+eIHShSzX+4uWCpN/A== Date: Fri, 18 Nov 2011 01:09:02 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F036D5A@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F036D5ASACEXCMBX02PRDhqn_" MIME-Version: 1.0 X-OriginalArrivalTime: 18 Nov 2011 01:09:09.0592 (UTC) FILETIME=[AD27FD80:01CCA58E] Subject: [tcpm] accurate ECN 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, 18 Nov 2011 01:09:16 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F036D5ASACEXCMBX02PRDhqn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, To summarize what I gathered around accurate ECN feedback during this weeks= session: Mirja presented one draft in TCPM, talking about three different ways of de= livering more than a single CE event per RTT: * 1-bit feedback (triggering immediate ACKs when the received CE stat= e changes, and using ECE/CWR as "shift register" to signal CE state changes * 3-bit feedback (conveying a counter value in each ACK) * Code-point feedback (also conveying a counter value, but not loosin= g the ability to signal ECN Nonce) In addition, the slides presented in Conex mentioned * Standard ECN feedback * Simple compatibility mode - set CWR always on the sender, but loose= some CE marks * Advanced compatibility mode - set CWR in those data segments, that= will trigger an ACK, not loosing CE marks (but more complex to implement i= n the sender) Not presented, but also existing as http://tools.ietf.org/html/draft-kuehle= wind-tcpm-accurate-ecn-option * Use of a TCP option to convey the information (16 bit counters) - m= odeled after draft-ietf-avtcore-ecn-for-rtp Further discussions after the sessions added * Setting the CWR bit every n data segments (brought up by Matt) * Using a smaller TCP option of only a single byte or 16-bit word Naturally, the TCP options proposal would be able to convey nearly perfect = information even during ACK thinning / ACK loss. Furthermore, when the sign= al has enough bandwidth (ie. 16 bit counters), true Byte accounting can be = done on the receiver side, and the signal could truly convey data bytes, ra= ther than segments. Without severe ACK thinning / ACK loss (<5%), all of the above proposals w= ould be able to work on segment marks; However, in order to deliver true by= te accounting, 1-bit feedback relies on increasing the ACK ratio (1 ACK to = 1 data segment in the degenerate case when data segments arrive with CE / n= on-CE / CE / non-CE...). If some middlebox performs ACK thinning (as sugges= ted by Matt in the discussion), this could severely impact the accuracy of = the feedback signal. (DCTCP would have the same issue, btw). Other than the loss of payload data, a TCP option carrying only a single 8 = or 16 bit value to indicate the received CE-marked segments or payload byte= s, seems to be the most reliable and accurate way. I would like to learn, what the group thinks about these proposals. Best regards, Richard Scheffenegger --_000_012C3117EDDB3C4781FD802A8C27DD4F036D5ASACEXCMBX02PRDhqn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
To summarize what I gathered around accurate ECN feedback during this = weeks session:
 
Mirja presented one draft in TCPM, talking about three different ways = of delivering more than a single CE event per RTT:
  • 1-bit feedback (triggering immediate ACKs when the received CE state ch= anges, and using ECE/CWR as “shift register” to signal CE state= changes
  • 3-bit feedback (conveying a counter value in each ACK)
  • Code-point feedback (also conveying a counter value, but not loosing t= he ability to signal ECN Nonce)
 
In addition, the slides presented in Con= ex mentioned
  • Standard ECN feedback
  • Simple compatibility mode – set CWR= always on the sender, but loose some CE marks
  • Advanced compatibili= ty mode  - set CWR in those data segments, that will trigger an ACK, n= ot loosing CE marks (but more complex to implement in the sender)
 
  • Use of a TCP option to convey the information (16 bit counters) –= modeled after draft-ietf-avtcore-ecn-for-rtp
 
Further discussions after the sessions added
  • Setting the CWR bit every n data segments (brought up by Matt)
  • = Using a smaller TCP option of only a single byte or 16-bit word
 
 
Naturally, the TCP options proposal would be able to convey nearly per= fect information even during ACK thinning / ACK loss. Furthermore, when the= signal has enough bandwidth (ie. 16 bit counters), true Byte accounting ca= n be done on the receiver side, and the signal could truly convey data bytes, rather than segments.
 
 
Without severe ACK thinning / ACK loss (<5%),  all of the abov= e proposals would be able to work on segment marks; However, in order to de= liver true byte accounting, 1-bit feedback relies on increasing the ACK rat= io (1 ACK to 1 data segment in the degenerate case when data segments arrive with CE / non-CE / CE / non-CE…). If s= ome middlebox performs ACK thinning (as suggested by Matt in the discussion= ), this could severely impact the accuracy of the feedback signal. (DCTCP w= ould have the same issue, btw).
 
Other than the loss of payload data, a TCP option carrying only a sing= le 8 or 16 bit value to indicate the received CE-marked segments or payload= bytes, seems to be the most reliable and accurate way.
 
I would like to learn, what the group thinks about these proposals.
 
Best regards,
 
Richard Scheffenegger
 
 --_000_012C3117EDDB3C4781FD802A8C27DD4F036D5ASACEXCMBX02PRDhqn_-- From touch@isi.edu Thu Nov 17 18:35:41 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E6611E8098 for ; Thu, 17 Nov 2011 18:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.906 X-Spam-Level: X-Spam-Status: No, score=-104.906 tagged_above=-999 required=5 tests=[AWL=1.093, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, 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 21Q7kRJ4r0KC for ; Thu, 17 Nov 2011 18:35:40 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 90F8021F94B4 for ; Thu, 17 Nov 2011 18:35:40 -0800 (PST) Received: from [130.129.66.136] (dhcp-4288.meeting.ietf.org [130.129.66.136]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id pAI2YvTs024644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Nov 2011 18:35:08 -0800 (PST) Message-ID: <4EC5C44E.1070000@isi.edu> Date: Thu, 17 Nov 2011 18:34:54 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <012C3117EDDB3C4781FD802A8C27DD4F036D2E@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F036D2E@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Timestamp semantic change 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, 18 Nov 2011 02:35:41 -0000 Hi, all, To clarify, we had converged to two different suggestions: - TCP should retain the highest TS seen for use on emitting new segments - when ACKing, TCP should use the TS from the packet causing the ACK I.e., in the first case it's "highest"; in the second it's "most recently received". Joe On 11/17/2011 4:45 PM, Scheffenegger, Richard wrote: > Hi, > > After this weeks TCPM session, Joe brought up an interesting observation. > > The draft proposes to change the semantics of timestamps under certain circumstances - i.e. when both TS capabilities and SACK is negotiated. > > Joe provided the following example, to perhaps revisit the way, which timestamp to reflect during reordering events: > > At t0, a data segment is sent from the sender to the receiver; the receiver ACKs with TSecr indicating t0. > At t1, a data segment is sent, but delayed in the network. > At t2, a data segment is sent, and received. > With RFC1323, the ACK would carry TSecr=t0 (as that was the last in-sequence data packet received). > The draft suggests to reflect TSecr=t2 at this time, as that data packet triggered the ACK. > After the ACK was sent, the receiver now sees the data segment with t1. > With RFC1323, the ACK triggered now has TSecr=t1, similar to what the draft stipulates. > Now, the question is, which value to put into an unsolicited data packet sent at this time from the receiver to the sender... > > With RFC1323, the kept timestamp value (TS.recent) would be t1 (as the last data segment to advance the window); however, that may lead to higher RTTvar and higher RTO at the sender side, that strictly necessary... > > It would be potentially better, to keep not the timestamp value of the last segment that advanced the window in the receiver, but the *highest* received Timestamp value. This would reduce the calculated RTTvar / RTO on the sender side, when the receiver sends data during reordering (loss) events. In particular, when the delta between t1 and t2 is large, this can have a significant impact. > > I would like to discuss this with the group, if adding this to the semantic modifications makes sense; so far, I assumed that TS.recent would be updated just as with RFC1323 (whenever the window advances), but by the above description, that minor change may be beneficial too.. > > Best regards, > > Richard Scheffenegger > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Thu Nov 17 19:04:30 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D581F0C61 for ; Thu, 17 Nov 2011 19:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LbbkOMBQxuoX for ; Thu, 17 Nov 2011 19:04:29 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8197F1F0C34 for ; Thu, 17 Nov 2011 19:04:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.69,530,1315206000"; d="scan'208,217";a="599847715" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 17 Nov 2011 19:04:29 -0800 Received: from sacrsexc1-prd.hq.netapp.com (sacrsexc1-prd.hq.netapp.com [10.99.115.27]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id pAI34T3W013944 for ; Thu, 17 Nov 2011 19:04:29 -0800 (PST) Received: from VMWEXCEHT02-PRD.hq.netapp.com ([10.106.76.240]) by sacrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 19:04:24 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.16]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.01.0289.001; Thu, 17 Nov 2011 19:03:37 -0800 From: "Scheffenegger, Richard" To: "tcpm (tcpm@ietf.org)" Thread-Topic: Timestamp negotiation - next steps Thread-Index: AcylnXtKS+tVvpHHTQ2pQs6lVILiqQ== Date: Fri, 18 Nov 2011 03:04:23 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F036EA3@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F036EA3SACEXCMBX02PRDhqn_" MIME-Version: 1.0 X-OriginalArrivalTime: 18 Nov 2011 03:04:24.0467 (UTC) FILETIME=[C6BE2E30:01CCA59E] Subject: [tcpm] Timestamp negotiation - next steps 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, 18 Nov 2011 03:04:31 -0000 --_000_012C3117EDDB3C4781FD802A8C27DD4F036EA3SACEXCMBX02PRDhqn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During the WG meeting I gathered that the group is quite interested that th= is work continues, even though the current draft is not yet ready for adopt= ion as a WG item. There is one thing that I missed to mention during my talk, which is very i= mportant I believe. Michio Honda has volunteered to include some active tests around timestamp= capability negotiation into his last version of the active TCP behavior te= sting tool: http://web.sfc.wide.ad.jp/~micchie/middlebox/cfc.html The viability of deploying the timestamp negotiation depends on middleboxes= not rewriting timestamps in an active session, and also not to remove unex= pected values (ie. the TSecr value will not be zero or the TSval = from the ). Also, this will be a snapshot of the current state of the = internet, and therefore much more valuable than my investigation as to the = already existing "stretch" of RFC1323 as seen by non-zero TSecrs in w= hich I presented. I would like to ask anyone who reads this message to run the testing tool -= if at all possible, also from as many different places as possible (home, = office, public area wifi, vpn...). It really is quick and easy to run. Also, I want to express my gratitude to Michio to have come forward to this= task! Greatly appreciated! Best regards, Richard Scheffenegger --_000_012C3117EDDB3C4781FD802A8C27DD4F036EA3SACEXCMBX02PRDhqn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
During the WG meeting I gathered that the group is quite interested th= at this work continues, even though the current draft is not yet ready for = adoption as a WG item.
 
There is one thing that I missed to mention during my talk, which is v= ery important I believe.
 
Michio Honda has volunteered to include some active tests  around= timestamp capability negotiation into his last version of the active TCP b= ehavior testing tool:
 
 
 
 
 
The viability of deploying the timestamp negotiation depends on middle= boxes not rewriting timestamps in an active session, and also not to remove= unexpected values (ie. the <SYN,ACK> TSecr value will not be zero or= the TSval from the <SYN>). Also, this will be a snapshot of the current state of the internet, and therefore much= more valuable than my investigation as to the already existing “stre= tch” of RFC1323 as seen by non-zero TSecrs in <SYN> which I pre= sented.
 
I would like to ask anyone who reads this message to run the testing t= ool – if at all possible, also from as many different places as possi= ble (home, office, public area wifi, vpn…). It really is quick and ea= sy to run.
 
Also, I want to express my gratitude to Michio to have come forward to= this task! Greatly appreciated!
 
Best regards,
 
Richard Scheffenegger
 
--_000_012C3117EDDB3C4781FD802A8C27DD4F036EA3SACEXCMBX02PRDhqn_-- From micchie@sfc.wide.ad.jp Thu Nov 17 22:43:13 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9228921F94B8; Thu, 17 Nov 2011 22:43:13 -0800 (PST) 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 vFsvC3FW5o2z; Thu, 17 Nov 2011 22:43:12 -0800 (PST) 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 322DE21F9485; Thu, 17 Nov 2011 22:43:04 -0800 (PST) Received: from dhcp-13c3.meeting.ietf.org (dhcp-13c3.meeting.ietf.org [130.129.19.195]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 986E1278092; Fri, 18 Nov 2011 15:43:00 +0900 (JST) From: Michio Honda Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2011 14:42:56 +0800 Message-Id: <75C10E82-2AA7-45A0-8E60-868B9E3880BA@sfc.wide.ad.jp> To: ietf@ietf.org, tcpm@ietf.org, mptcp Mailing List TCP Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [tcpm] 2nd round of call for contribution to middlebox measurement 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, 18 Nov 2011 06:43:13 -0000 Hi,=20 Thank you for a lot of contributions to the middlebox measurement that I = asked you in the autumn last year to run our measurement tool. =20 I'd like to report that we measured ~150 paths with your collaboration, = and figured out quite interesting middlebox behaviors in the wild.=20 The results are published in the last Internet Measurement Conference: = http://conferences.sigcomm.org/imc/2011/docs/p181.pdf We're very happy if this paper is somehow helpful for IETFers to = investigate the future Internet. =20 This work was also awarded ANRP by IRTF in this meeting, so I'd like to = say thank you again for that. =20 =20 We obviously should continue this work as success of the last = measurement. =20 Based on feedback from many people and current proposals of new TCP = extensions, we added new tests, and improved experiment procedure. =20 So, I'd like to ask you again to run our measurement tool anywhere in = your networks, such as your home, WiFi hotspots, mobile, coffee shops = etc. =20 As the tests include new ones, re-testing the network you previously = measured is welcome.=20 (please check the box in the submission form for such places) Our tool runs in Mac OSX, Linux and FreeBSD, and experiment will finish = approximately in 10-15 min.=20 The tool is self-contained; you don't need to install any additional = applications. The procedures are (easier than the last version): 1.Download tool from = http://web.sfc.wide.ad.jp/~micchie/middlebox/for_distrib.tar.gz 2.Execute the script > tar xzf for_distrib.tar.gz > cd for_distrib > sudo python run-all.py 3. Post the result (logxxxxxxxxx.tar.gz) from = http://web.sfc.wide.ad.jp/~micchie/middlebox/submit.cgi Then you will see the summarized results for your network (e.g., Unknown = TCP option is OK, segments are coalesced, etc) Please see our official announcement page = http://web.sfc.wide.ad.jp/~micchie/middlebox/cfc.html for more details = of experiment. =20 Best regards, - Michio= From Michael.Scharf@alcatel-lucent.com Thu Nov 24 14:49:47 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313FD11E8091 for ; Thu, 24 Nov 2011 14:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_26=0.6, 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 ngzprBPzYJ4Y for ; Thu, 24 Nov 2011 14:49:46 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD5811E808A for ; Thu, 24 Nov 2011 14:49:45 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id pAOMnh2J011794; Thu, 24 Nov 2011 23:49:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Nov 2011 23:49:40 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0693AF0C@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <4EC5C44E.1070000@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Timestamp semantic change Thread-Index: AcylmuqUk3umesBmQN2WgG3whjm+2gFV9XPw References: <012C3117EDDB3C4781FD802A8C27DD4F036D2E@SACEXCMBX02-PRD.hq.netapp.com> <4EC5C44E.1070000@isi.edu> From: "SCHARF, Michael" To: "Joe Touch" , "Scheffenegger, Richard" X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Cc: tcpm@ietf.org Subject: Re: [tcpm] Timestamp semantic change 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, 24 Nov 2011 22:49:47 -0000 Richard, joe, I am trying to understand the motivation for these suggestions. According to RFC 1323, the TSecr value received in a segment is used to update the averaged RTT measurement only if the segment acknowledges some new data. In your scenario, the unsolicitated packet wouldn't advance the window in the sender, right? If this was correct, why would it matter what value to put into TSecr, if the sender doesn't use it to update its RTT measurement? Or do I miss something? There may be corner cases e. g. if ACKs get lost, but in that case it probably makes really sense to have a conservative RTO - which is the design rationale of RFC 1323. Is there a simple example in which your suggestion really improves the RTT estimation? BTW, this might also be related to the question how to actually update RTTvar with timestamps. As noted by RFC 6298, this is not well understood so far... For instance, a sender doesn't have to use every TSecr... Michael > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Joe Touch > Sent: Friday, November 18, 2011 3:35 AM > To: Scheffenegger, Richard > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Timestamp semantic change >=20 > Hi, all, >=20 > To clarify, we had converged to two different suggestions: >=20 > - TCP should retain the highest TS seen > for use on emitting new segments >=20 > - when ACKing, TCP should use the TS from the packet causing the ACK >=20 > I.e., in the first case it's "highest"; in the second it's=20 > "most recently received". >=20 > Joe >=20 > On 11/17/2011 4:45 PM, Scheffenegger, Richard wrote: > > Hi, > > > > After this weeks TCPM session, Joe brought up an=20 > interesting observation. > > > > The draft proposes to change the semantics of timestamps=20 > under certain circumstances - i.e. when both TS capabilities=20 > and SACK is negotiated. > > > > Joe provided the following example, to perhaps revisit the=20 > way, which timestamp to reflect during reordering events: > > > > At t0, a data segment is sent from the sender to the=20 > receiver; the receiver ACKs with TSecr indicating t0. > > At t1, a data segment is sent, but delayed in the network. > > At t2, a data segment is sent, and received. > > With RFC1323, the ACK would carry TSecr=3Dt0 (as that was=20 > the last in-sequence data packet received). > > The draft suggests to reflect TSecr=3Dt2 at this time, as=20 > that data packet triggered the ACK. > > After the ACK was sent, the receiver now sees the data=20 > segment with t1. > > With RFC1323, the ACK triggered now has TSecr=3Dt1,=20 > similar to what the draft stipulates. > > Now, the question is, which value to put into an=20 > unsolicited data packet sent at this time from the receiver=20 > to the sender... > > > > With RFC1323, the kept timestamp value (TS.recent) would be=20 > t1 (as the last data segment to advance the window); however,=20 > that may lead to higher RTTvar and higher RTO at the sender=20 > side, that strictly necessary... > > > > It would be potentially better, to keep not the timestamp=20 > value of the last segment that advanced the window in the=20 > receiver, but the *highest* received Timestamp value. This=20 > would reduce the calculated RTTvar / RTO on the sender side,=20 > when the receiver sends data during reordering (loss) events.=20 > In particular, when the delta between t1 and t2 is large,=20 > this can have a significant impact. > > > > I would like to discuss this with the group, if adding this=20 > to the semantic modifications makes sense; so far, I assumed=20 > that TS.recent would be updated just as with RFC1323=20 > (whenever the window advances), but by the above description,=20 > that minor change may be beneficial too.. > > > > Best regards, > > > > Richard Scheffenegger > > > > _______________________________________________ > > 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 From rs@netapp.com Fri Nov 25 00:59:41 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC5F21F8A58 for ; Fri, 25 Nov 2011 00:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, 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 q3RCjtrfIEtg for ; Fri, 25 Nov 2011 00:59:40 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1B26421F8A55 for ; Fri, 25 Nov 2011 00:59:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.69,570,1315206000"; d="scan'208";a="602036047" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 25 Nov 2011 00:59:38 -0800 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id pAP8xbF0015069; Fri, 25 Nov 2011 00:59:37 -0800 (PST) Received: from VMWEXCEHT04-PRD.hq.netapp.com ([10.106.77.34]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Nov 2011 00:59:31 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.16]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.01.0289.001; Fri, 25 Nov 2011 00:59:29 -0800 From: "Scheffenegger, Richard" To: "SCHARF, Michael" , Joe Touch Thread-Topic: [tcpm] Timestamp semantic change Thread-Index: AcyliOMl3xGQqdUxSpiQkPNjMRBQtgAVNJ0AAVgsewAAA4YioA== Date: Fri, 25 Nov 2011 08:59:28 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F03AEDD@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F036D2E@SACEXCMBX02-PRD.hq.netapp.com> <4EC5C44E.1070000@isi.edu> <133D9897FB9C5E4E9DF2779DC91E947C0693AF0C@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0693AF0C@SLFSNX.rcs.alcatel-research.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2011 08:59:31.0906 (UTC) FILETIME=[8BDB9A20:01CCAB50] Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Timestamp semantic change 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, 25 Nov 2011 08:59:41 -0000 Hi Michael, You are absolutely correct. In the context of RFC1323,the sole purpose of T= imestamps (to the sender) is to deliver a conservative lower bound of the R= TT. This is again used for the single purpose of calculating the RTO on the= sender side. Thus, there was no point of discussing which timestamp to reflect (during R= FC1323 time), when it's basically ignored on the sender side. But even back then, there were proposals to use the timestamps for more tha= n simple RTO calculation - at the time, the lack of SACK signaling stopped = these though. Timestamps were seen as a pure, self-contained signal for onl= y one single purpose to the sender. But perhaps my perception of these long= past events is wrong - if so, there are still members on that DL who could= set the record straight. However, the proposal in the draft would enable the use of timestamps as a = valuable signal for additional heuristics - one way delay variance, pure ne= twork RTT during special events (reordering, loss, L2 recovery...). Thus it= may be worthwhile to redefine the semantics of which timestamps to reflect= under what circumstances, to deliver a higher quality signal (more informa= tion) back to the sender. Which is what the draft tries to do, and Joe's su= ggestion improves upon this general idea. Applying the very same rules as in RFC1323 to arrive at a conservative RTO = measurement would not benefit from these changes, but they would not signif= icantly suffer either (or at all). The RTO calculation would only deliberat= ely throw away Information at the sender side, instead of masking it alrea= dy on the receiver side.=20 So I believe the question for an improved RTT (for the purpose of arriving = at a conservative RTO) is not the correct one - and I admit the second part= was implicit by the context of your message. But if we leave out the impli= ed second part, and disentangle RTT measurement from RTO calculation, that = would be a valid question indeed... What heuristics / algorithms could benefit from a more instantaneous sampli= ng of network RTT, which are simply not possible today? The draft names two (LEDBAT, TCP Chirp) which would benefit; Others (i.e. N= on-congestion loss events) may as well, but that territory appears to be mu= ch less well explored.=20 This leads to the question you raised last - when should the sender actuall= y update the variables used to calculate the RTO in a conservative way. The= draft is not trying to answer this at this point in time though, instead h= inting on how to interface the legacy RTO calculation with the newly availa= ble signals by evaluating SACK information. The signals available within an (SACK-enabled) TCP sessions ACK should be e= nough to gate this decisions on the sender side, without the need that the = receiver deliberately withholds information... Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > SCHARF, Michael > Sent: Donnerstag, 24. November 2011 23:50 > To: Joe Touch; Scheffenegger, Richard > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Timestamp semantic change >=20 > Richard, joe, >=20 > I am trying to understand the motivation for these suggestions. >=20 > According to RFC 1323, the TSecr value received in a segment is used to > update the averaged RTT measurement only if the segment acknowledges > some new data. >=20 > In your scenario, the unsolicitated packet wouldn't advance the window in > the sender, right? If this was correct, why would it matter what value to= put > into TSecr, if the sender doesn't use it to update its RTT measurement? O= r do > I miss something? >=20 > There may be corner cases e. g. if ACKs get lost, but in that case it pro= bably > makes really sense to have a conservative RTO - which is the design ratio= nale > of RFC 1323. Is there a simple example in which your suggestion really > improves the RTT estimation? >=20 > BTW, this might also be related to the question how to actually update > RTTvar with timestamps. As noted by RFC 6298, this is not well understood= so > far... For instance, a sender doesn't have to use every TSecr... >=20 > Michael >=20 >=20 > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf > > Of Joe Touch > > Sent: Friday, November 18, 2011 3:35 AM > > To: Scheffenegger, Richard > > Cc: tcpm@ietf.org > > Subject: Re: [tcpm] Timestamp semantic change > > > > Hi, all, > > > > To clarify, we had converged to two different suggestions: > > > > - TCP should retain the highest TS seen > > for use on emitting new segments > > > > - when ACKing, TCP should use the TS from the packet causing the ACK > > > > I.e., in the first case it's "highest"; in the second it's "most > > recently received". > > > > Joe > > > > On 11/17/2011 4:45 PM, Scheffenegger, Richard wrote: > > > Hi, > > > > > > After this weeks TCPM session, Joe brought up an > > interesting observation. > > > > > > The draft proposes to change the semantics of timestamps > > under certain circumstances - i.e. when both TS capabilities and SACK > > is negotiated. > > > > > > Joe provided the following example, to perhaps revisit the > > way, which timestamp to reflect during reordering events: > > > > > > At t0, a data segment is sent from the sender to the > > receiver; the receiver ACKs with TSecr indicating t0. > > > At t1, a data segment is sent, but delayed in the network. > > > At t2, a data segment is sent, and received. > > > With RFC1323, the ACK would carry TSecr=3Dt0 (as that was > > the last in-sequence data packet received). > > > The draft suggests to reflect TSecr=3Dt2 at this time, as > > that data packet triggered the ACK. > > > After the ACK was sent, the receiver now sees the data > > segment with t1. > > > With RFC1323, the ACK triggered now has TSecr=3Dt1, > > similar to what the draft stipulates. > > > Now, the question is, which value to put into an > > unsolicited data packet sent at this time from the receiver to the > > sender... > > > > > > With RFC1323, the kept timestamp value (TS.recent) would be > > t1 (as the last data segment to advance the window); however, that may > > lead to higher RTTvar and higher RTO at the sender side, that strictly > > necessary... > > > > > > It would be potentially better, to keep not the timestamp > > value of the last segment that advanced the window in the receiver, > > but the *highest* received Timestamp value. This would reduce the > > calculated RTTvar / RTO on the sender side, when the receiver sends > > data during reordering (loss) events. > > In particular, when the delta between t1 and t2 is large, this can > > have a significant impact. > > > > > > I would like to discuss this with the group, if adding this > > to the semantic modifications makes sense; so far, I assumed that > > TS.recent would be updated just as with RFC1323 (whenever the window > > advances), but by the above description, that minor change may be > > beneficial too.. > > > > > > Best regards, > > > > > > Richard Scheffenegger > > > > > > _______________________________________________ > > > 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 Michael.Scharf@alcatel-lucent.com Wed Nov 30 06:35:32 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51C121F8B64 for ; Wed, 30 Nov 2011 06:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 GBLusQE+b-LS for ; Wed, 30 Nov 2011 06:35:32 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 32D3121F8B36 for ; Wed, 30 Nov 2011 06:35:31 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id pAUEZQqb025271 for ; Wed, 30 Nov 2011 15:35:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2011 15:35:22 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0693B10D@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft TCPM minutes of IETF 82 Thread-Index: AcyvbUqut3nAVY0yRgeT4AHcmociXg== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Subject: [tcpm] Draft TCPM minutes of IETF 82 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, 30 Nov 2011 14:35:33 -0000 Dear all, I uploaded draft minutes of the meeting in Taipei, based on minutes and input from Andrew McGregor, Murari Sridharan, Wes Eddy, and Yoshifumi Nishida (thanks!): http://www.ietf.org/proceedings/82/minutes/tcpm.txt Please take a look and let me know if you have any comments or suggestions. Michael (TCPM co-chair) From Michael.Scharf@alcatel-lucent.com Wed Nov 30 06:42:04 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403DE21F8B2A for ; Wed, 30 Nov 2011 06:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 yN9MlVinmLtj for ; Wed, 30 Nov 2011 06:42:03 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 8C46221F84ED for ; Wed, 30 Nov 2011 06:42:03 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id pAUEg2R2026243 for ; Wed, 30 Nov 2011 15:42:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2011 15:41:59 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0693B110@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working group acceptance of draft-cheng-tcpm-fastopen Thread-Index: AcyvbjcI+iGrEsoyRK21ij9dIxu3yQ== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Subject: [tcpm] Working group acceptance of draft-cheng-tcpm-fastopen 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, 30 Nov 2011 14:42:04 -0000 Dear all, there was significant support on the mailing list and during the IETF 82 meeting to adopt draft-cheng-tcpm-fastopen as TCPM working group item, heading towards Experimental. I'd like to confirm that this is the consensus of TCPM. Please speak up before December 15 if you have any concerns or comments regarding the acceptance of this draft. We recently had a lot of discussions whether there is indeed a significant benefit compared to persistent HTTP connections. I think that these concerns can be addressed by an additional section in the draft that documents pros and cons of TCP fast open. Also, my current understanding is that the allocation of an own option codepoint is not necessarily required for experimental use. Michael (TCPM co-chair) From Michael.Scharf@alcatel-lucent.com Wed Nov 30 06:43:09 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D579B21F8B2A for ; Wed, 30 Nov 2011 06:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 NSFwrRkoyxuX for ; Wed, 30 Nov 2011 06:43:09 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 353BA21F84ED for ; Wed, 30 Nov 2011 06:43:09 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id pAUEh8H0026433 for ; Wed, 30 Nov 2011 15:43:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2011 15:43:04 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0693B111@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working group acceptance of draft-touch-tcpm-experimental-options Thread-Index: Acyvbl4ZrCI1KbF4SXGFAE2qlEWI2Q== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Subject: [tcpm] Working group acceptance of draft-touch-tcpm-experimental-options 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, 30 Nov 2011 14:43:10 -0000 Dear all, according to the discussion on the mailing list and during the IETF 82 meeting, there seems to be significant interest in TCPM to improve the shared use of experimental use of TCP options, based on draft-touch-tcpm-experimental-options. This draft was submitted as Informational, but a Standards Track document might be needed instead (or, alternatively, BCP - this can be sorted out later). I'd like to confirm that TCPM wants do adopt draft-touch-tcpm-experimental-options, possibly on Standards Track. Please speak up before December 15 if you have any concerns or comments regarding the acceptance of this draft. Michael (TCPM co-chair)