From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Oct 5 05:11: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 8E87421F8CDC; Wed, 5 Oct 2011 05:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_40=-0.185, 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 H0u1KGVHaIn5; Wed, 5 Oct 2011 05:11:35 -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 C40CD21F8CD6; Wed, 5 Oct 2011 05:11:34 -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 D2F51633B1; Wed, 5 Oct 2011 14:14:40 +0200 (CEST) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id BF9BD59A8A; Wed, 5 Oct 2011 14:14:40 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: tcpm@ietf.org Date: Wed, 5 Oct 2011 14:14:40 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <4E802AF0.4040605@unice.fr> <133D9897FB9C5E4E9DF2779DC91E947C0680D62F@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0680D62F@SLFSNX.rcs.alcatel-research.de> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201110051414.40516.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: tsv-area@ietf.org Subject: Re: [tcpm] On the deployment of Explicit Rate Notification protocols 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, 05 Oct 2011 12:11:35 -0000 Hi, first, one general question from my side: I'm not sure if I understand the= =20 problem you are addressing. If you always take the smaller cwnd and be neve= r=20 more aggressive than standard TCP, how can you solve the problem that TCP i= s=20 too slow in large BDP networks? Even when all network nodes support your ER= N=20 protocol (and all endsystems using these nodes), you still will not increas= e=20 fast than standard TCP...? Then I don't understand how you change the E2E cwnd. If the sending rate is= =20 limited by the ERN protocol you should not increase the E2E cwnd as your E2= E=20 feedback would be related to the smaller cwnd of the ERN protocol. If you=20 don't increase the E2E any further and then halve on loss, you will probabl= y=20 underutilize the bottleneck link. Is this correct? Mirja On Monday 26 September 2011 14:07:45 SCHARF, Michael wrote: > Speaking not as researcher, but as TCPM co-chair: Since you are > proposing at least one new TCP option, please note that TCP option space > in particular in SYNs is somehow scarce. > > Michael > > > -----Original Message----- > > From: tsv-area-bounces@ietf.org > > [mailto:tsv-area-bounces@ietf.org] On Behalf Of Dino LOPEZ > > Sent: Monday, September 26, 2011 9:34 AM > > To: tsv-area@ietf.org > > Subject: On the deployment of Explicit Rate Notification protocols > > > > Dear all, > > > > We have submitted a new Internet draft which provides an > > architecture to allow the deployment of congestion control > > protocols with explicit rate notification from forwarding > > devices (Explicit Rate Notification protocols). > > > > This draft is currently available at > > http://www.ietf.org/internet-drafts/draft-lopez-ietf-tsvwg-ipe > > rn-00.txt > > > > It will be a pleasure to receive any feedback from you. > > > > Best Regards, > > > > The authors > > Lochin, Emmanuel (emmanuel.lochin@isae.fr) Lopez Pacheco, > > Dino (dino.lopez@unice.fr) Sathiaseelan, Arjuna > > (arjuna.sathiaseelan@gmail.com) > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm =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 Thu Oct 6 06:52: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 043FA21F8A7A for ; Thu, 6 Oct 2011 06:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.035, 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 DIBt3B0VCeqJ for ; Thu, 6 Oct 2011 06:52:47 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id E28D121F8A71 for ; Thu, 6 Oct 2011 06:52:46 -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 p96DrjJi001985 for ; Thu, 6 Oct 2011 15:53:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2011 15:49:33 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0680DBB9@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: Nomcom 2011-2012: Second Call for Nominations Thread-Index: AcyELWMBRPl+S5kfSuuM9YrwSps9TQAAR+wA From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Subject: [tcpm] Fwd: Nomcom 2011-2012: Second Call for Nominations 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, 06 Oct 2011 13:52:49 -0000 -------- Original Message -------- Subject: Nomcom 2011-2012: Second Call for Nominations Date: Sun, 18 Sep 2011 04:05:38 +0200 From: NomCom Chair To: IETF Announcement list CC: ietf@ietf.org Hi All, We are halfway through the nomination period (it ends on October 2, 2011) and we need more nominees than we have received so far. We appreciate the folks that have taken the time to nominate people and those who have accepted so far. But the fact remains that the number of nominations have been below average and the acceptance rates of those nominated has also been low. We need **YOUR** input and participation! We cannot properly execute the task of selecting the best candidates for these positions with so few nominations and acceptances. So, please consider making nominations for the open positions, in particular those for which we have so few nominations it takes just a few minutes of your time. Right now, we just need the names/email addresses. Why do we need more nominations? Well, even if you think a willing incumbent is doing a very good job and should be returned, his or her ability to serve again might be impacted by unforeseen circumstances between now and March. NomCom needs to consider multiple nominees to be prepared in the event one or more candidates is unable to serve come next March and to ensure we have chosen the best candidate. There are several ways you can help the Nomcom - You can nominate yourself. - You can nominate someone you know whom you think would do a good job. Don't worry about whether they might already be nominated. We would much prefer to receive the same nomination several times rather than miss a good person we should consider. How to submit Nominations: -------------------------- The list of positions we need to fill, and the provided Job Descriptions, and forms for nominations, can be found in the call for nominations at: https://datatracker.ietf.org/ann/nomcom/3049/ You can enter a nomination by going to the following URL: https://www.ietf.org/group/nomcom/2011/nominate You can also nominate someone by sending an email to nomcom11@ietf.org and giving us their name, email address and the open position you are nominating them for. We will take care of the rest. If you are asked for a user name and password, use an existing ietf login and password. If you need a login and password, request one from the following URL: https://datatracker.ietf.org/accounts/create/ Open List: ---------- As you already know, NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. Feedback Collection: -------------------- The open list is currently available on the Nomcom page and the entire community is invited to provide feedback on all nominees. You can provide your comments on all willing nominees at the following URL: https://www.ietf.org/group/nomcom/2011/input/ Suresh Krishnan Chair, NomCom 2011-2012 nomcom-chair@ietf.org suresh.krishnan@ericsson.com From dino.lopez@unice.fr Mon Oct 10 00:54:45 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 91F4921F8B18; Mon, 10 Oct 2011 00:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=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 ArK6SfR3Ke4J; Mon, 10 Oct 2011 00:54:45 -0700 (PDT) Received: from naxos2.unice.fr (naxos2.unice.fr [134.59.1.112]) by ietfa.amsl.com (Postfix) with ESMTP id 9F56021F8AEA; Mon, 10 Oct 2011 00:54:43 -0700 (PDT) Received: from [192.168.1.13] (ANice-751-1-3-196.w90-4.abo.wanadoo.fr [90.4.90.196]) (authenticated bits=0) by naxos2.unice.fr (8.13.8/8.13.8) with ESMTP id p9A7sZxV023101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Oct 2011 09:54:36 +0200 Message-ID: <4E92A4BB.4010407@unice.fr> Date: Mon, 10 Oct 2011 09:54:35 +0200 From: Dino LOPEZ User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Mirja Kuehlewind References: <4E802AF0.4040605@unice.fr> <133D9897FB9C5E4E9DF2779DC91E947C0680D62F@SLFSNX.rcs.alcatel-research.de> <201110051414.40516.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201110051414.40516.mirja.kuehlewind@ikr.uni-stuttgart.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tsv-area@ietf.org, tcpm@ietf.org Subject: Re: [tcpm] On the deployment of Explicit Rate Notification protocols 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, 10 Oct 2011 07:54:45 -0000 Hi Mirja, Thank you for your comments and questions. I hope this email will clarify the points where, we believe, IP-ERN can provide important benefits. One of the objectives of the IP-ERN architecture is to improve the performance of TCP by trying to use router-assisted protocols (more precisely, by mean of Explicit Rate Notification protocols). As reported in some papers (e.g. in [1], just to give an example), using such ERN protocols, it's possible to compute a cwnd which will allow to grab all the available bandwidth, remains stable at that point and avoid congestion. Hence, if we grab all the bottleneck capacity, avoid losses (we consider losses due to congestion), and therefore, retransmission and cwnd reductions, we improve the performance of TCP without being more aggressive. For instance, in links with high propagation delay (e.g. satellite links) the FastRet/FastRec mechanism of TCP has a strong impact on the performance of TCP. Getting the rigth cwnd value to fully use the available bandwidth and avoid FastRet/FastRec would be just great. It seems like is very difficult to agree about a level of aggressiveness which can be considered safe for Internet, so IP-ERN does not advise the use of any high speed TCP version, does not make TCP more aggressive. IP-ERN only makes mandatory to implement one E2E congestion control protocol. The choice of the E2E CC is taken by the user or the programmer (like in a Window Vista OS the user can enable CTCP if he wants, one can use IP-ERN with CTCP or CUBIC). Another good reason of allowing the deployment of ERN protocols is the convergence of flows (e.g. 1 CUBIC and 1 CTCP flows could never converge, but 1 CUBIC/RCP and 1 CTCP/RCP flows will do). Here, we suppose that convergence consist on equally sharing the bottleneck. Finally, another -no technical- benefit of IP-ERN is the fact that this architecture can be the first step in the difficult way of going beyond TCP and E2E CC protocols. Today ERN protocols are not considered like realistic solutions to the problems of TCP (periodic congestions, which causes the sawtooth behavior, and slow convergence in some cases). And actually, it seems like any information, explicitly sent by the network, is unusable. However, we believe that following the basic principle of being less or as aggressive as standard TCP, we can use any CC strategy (even ERN protocols). In that safe space IP-ERN is playing on. Concerning the question about the underutilization of resources, if the congestion window is driven by cwnd_ern_, then it means that the bottleneck is ERN-capable and, therefore, no losses should arrive (we consider that the physical and mac layers implement robust protocols and losses due to the medium do not happen) and therefore, no window reduction should be experienced. When the bottleneck is not ERN-capable, then the congestion window will be driven by the E2E congestion control protocol (i.e. before reaching the targeted cwnd_ern_ losses are experienced somewhere else, then TCP will handle the rate). Best Regards, The authors http://www.ietf.org/internet-drafts/draft-lopez-ietf-tsvwg-ipern-00.txt [1] Y. Zhang, S. Jain, and D. Loguinov, "Towards Experimental Evaluation of Explicit Congestion Control," Elsevier Computer Networks, vol. 53, no. 7, May 2009. On 10/05/2011 02:14 PM, Mirja Kuehlewind wrote: > Hi, > > first, one general question from my side: I'm not sure if I understand the > problem you are addressing. If you always take the smaller cwnd and be never > more aggressive than standard TCP, how can you solve the problem that TCP is > too slow in large BDP networks? Even when all network nodes support your ERN > protocol (and all endsystems using these nodes), you still will not increase > fast than standard TCP...? > > Then I don't understand how you change the E2E cwnd. If the sending rate is > limited by the ERN protocol you should not increase the E2E cwnd as your E2E > feedback would be related to the smaller cwnd of the ERN protocol. If you > don't increase the E2E any further and then halve on loss, you will probably > underutilize the bottleneck link. Is this correct? > > Mirja > > > On Monday 26 September 2011 14:07:45 SCHARF, Michael wrote: >> Speaking not as researcher, but as TCPM co-chair: Since you are >> proposing at least one new TCP option, please note that TCP option space >> in particular in SYNs is somehow scarce. >> >> Michael >> >>> -----Original Message----- >>> From: tsv-area-bounces@ietf.org >>> [mailto:tsv-area-bounces@ietf.org] On Behalf Of Dino LOPEZ >>> Sent: Monday, September 26, 2011 9:34 AM >>> To: tsv-area@ietf.org >>> Subject: On the deployment of Explicit Rate Notification protocols >>> >>> Dear all, >>> >>> We have submitted a new Internet draft which provides an >>> architecture to allow the deployment of congestion control >>> protocols with explicit rate notification from forwarding >>> devices (Explicit Rate Notification protocols). >>> >>> This draft is currently available at >>> http://www.ietf.org/internet-drafts/draft-lopez-ietf-tsvwg-ipe >>> rn-00.txt >>> >>> It will be a pleasure to receive any feedback from you. >>> >>> Best Regards, >>> >>> The authors >>> Lochin, Emmanuel (emmanuel.lochin@isae.fr) Lopez Pacheco, >>> Dino (dino.lopez@unice.fr) Sathiaseelan, Arjuna >>> (arjuna.sathiaseelan@gmail.com) >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > > From Michael.Scharf@alcatel-lucent.com Wed Oct 12 01:05:19 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 E9B4221F8C20; Wed, 12 Oct 2011 01:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 deWcZCP4XfzP; Wed, 12 Oct 2011 01:05:19 -0700 (PDT) Received: from mailrelay1.alcatel.de (mailrelay1.alcatel.de [194.113.59.95]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9F821F8C11; Wed, 12 Oct 2011 01:05:15 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay1.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p9C84xW1004233; Wed, 12 Oct 2011 10:05:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Oct 2011 09:58:04 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0680DDEB@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 82 presentation requests Thread-Index: AcyItKuadfxKjKy/QPy/+aMRkTts3Q== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.69 on 149.204.45.72 Cc: tcpm-chairs@ietf.org Subject: [tcpm] IETF 82 presentation requests 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, 12 Oct 2011 08:05:20 -0000 Hi all, I requested a session for a TCPM meeting in Taipei, and I have already received several requests for time slots. If you plan to present something during IETF 82, and haven't talked to me so far, please let me know: * Title / draft name * Presenter * Expected duration Please note that unfortunately I cannot travel to Taipei. I apologize for that, but I'll surely attend the Paris meeting. David apparently cannot attend IETF 82 neither. In order to still enable a face-to-face TCPM meeting, I talked to Yoshifumi Nishida, who agreed to help out during the TCPM session in Taipei. He will manage the local meeting logistics. Obviously, I will try to attend the meeting remotely. I will also take care of all the meeting preparations, the minutes, and everything else that I can do remotely. In case of any doubts, please do not hesitate to contact the TCPM chairs. I want to thank Yoshifumi for his kind offer to help the TCPM chairs during the Taipei meeting and to enable a face-to-face meeting that we would have to cancel otherwise. Michael From internet-drafts@ietf.org Mon Oct 17 11:44: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 C89A921F8B6C; Mon, 17 Oct 2011 11:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 q3NLfXidGXjY; Mon, 17 Oct 2011 11:44:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3251D21F8B5C; Mon, 17 Oct 2011 11:44:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111017184423.13144.67618.idtracker@ietfa.amsl.com> Date: Mon, 17 Oct 2011 11:44:23 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-initcwnd-02.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, 17 Oct 2011 18:44:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : Increasing TCP's Initial Window Author(s) : Jerry Chu Nandita Dukkipati Yuchung Cheng Matt Mathis Filename : draft-ietf-tcpm-initcwnd-02.txt Pages : 20 Date : 2011-10-16 This document proposes an increase in the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without risking congestion collapse. The document closes with a discussion of a list of concerns, and some results from recent studies to address the concerns. Terminology A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-initcwnd-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-initcwnd-02.txt From iesg-secretary@ietf.org Wed Oct 19 09:38:53 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 2102611E80AF; Wed, 19 Oct 2011 09:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 KFYgv0pkjdpk; Wed, 19 Oct 2011 09:38:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E35D21F8B7B; Wed, 19 Oct 2011 09:38:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111019163852.22738.78795.idtracker@ietfa.amsl.com> Date: Wed, 19 Oct 2011 09:38:52 -0700 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (Defending Against Sequence Number Attacks) 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: Wed, 19 Oct 2011 16:38:53 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Defending Against Sequence Number Attacks' 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-02. 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 This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc1948bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc1948bis/ No IPR declarations have been submitted directly on this I-D. From gettysjim@gmail.com Wed Oct 19 10:16: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 6A1F921F8B73 for ; Wed, 19 Oct 2011 10:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, 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 9khxtR3WWggy for ; Wed, 19 Oct 2011 10:16:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDF1711E80BA for ; Wed, 19 Oct 2011 10:16:36 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2112804vcb.31 for ; Wed, 19 Oct 2011 10:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=MvABd2U2b/EauiRuN/fYIMu8wooHgrFMAzEpiHnPaWY=; b=Phlvs6qfmpc1T8vYLLcYtVlGc83bOiSG8Syq9DiFpelH/X4r5ztpXZkWrDvuMbEQrZ EHTnNVJ1tpO08n2MSAN1DyYfM7hIZeerkXeNzXxjvFRvCm2wV/ES+CAebuqRz5qMtM5v 7vVlN+TCgBT8UaWSxTzn6ugKQHjY4pdCxlpas= Received: by 10.52.95.112 with SMTP id dj16mr7531252vdb.113.1319044596297; Wed, 19 Oct 2011 10:16:36 -0700 (PDT) Received: from [172.30.45.112] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id r5sm6109591vdw.2.2011.10.19.10.16.34 (version=SSLv3 cipher=OTHER); Wed, 19 Oct 2011 10:16:34 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E9F05F1.3070908@freedesktop.org> Date: Wed, 19 Oct 2011 13:16:33 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: tcpm@ietf.org, IRTF Congestion Control Research Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tcpm] "Classic congestion collapse": be on the lookout for.... 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, 19 Oct 2011 17:16:37 -0000 I have one credible report of a significant private network collapsing with symptoms of "classic" 1980's flavour congestion collapse, along with significant difficulty getting the network "up" again after collapse. Please let me know if you know of other examples you can share. Two trends are worrying: 1) the retirement of Windows XP is making it much easier to saturate networks in the first place. 2) bufferbloat may also be playing a role, as it can destroy TCP congestion avoidance. But we don't know, and can't get the data to know right now either. Buffers can hide in places we don't have AQM to control the problem. And this problem has been growing... Unfortunately, more information is probably unavailable about the events, causes, and cures for the time being. It's really hard to be "first" with such a report publicly; much easier if you know you have company. For extra bonus points (not related to the above report), look for time based congestion problems; we could end up hurting if there is self synchronising behaviour going on. I don't think I need to tell this audience about the RED manifesto, but you might need to remind your friends. But I'm worried, given the report, Jim Gettys Bell Labs From internet-drafts@ietf.org Sat Oct 22 10:24: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 72F9B21F85F1; Sat, 22 Oct 2011 10:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 97e+XqO6SozO; Sat, 22 Oct 2011 10:24:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36CA21F8573; Sat, 22 Oct 2011 10:24:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111022172434.22038.71005.idtracker@ietfa.amsl.com> Date: Sat, 22 Oct 2011 10:24:34 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc3782-bis-03.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: Sat, 22 Oct 2011 17:24:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : The NewReno Modification to TCP's Fast Recovery Algo= rithm Author(s) : Tom Henderson Sally Floyd Andrei Gurtov Yoshifumi Nishida Filename : draft-ietf-tcpm-rfc3782-bis-03.txt Pages : 16 Date : 2011-10-22 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" (A= CKs 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc3782-bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-rfc3782-bis-03.txt From touch@isi.edu Mon Oct 24 14:58: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 8ACEA21F8B09 for ; Mon, 24 Oct 2011 14:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.739 X-Spam-Level: X-Spam-Status: No, score=-104.739 tagged_above=-999 required=5 tests=[AWL=1.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 jHuMREi4pAkG for ; Mon, 24 Oct 2011 14:58:04 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 182C821F8AFC for ; Mon, 24 Oct 2011 14:58:04 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p9OLvpWT009055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Oct 2011 14:57:51 -0700 (PDT) Message-ID: <4EA5DF5F.8090407@isi.edu> Date: Mon, 24 Oct 2011 14:57:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20111024215310.10139.23464.idtracker@ietfa.amsl.com> In-Reply-To: <20111024215310.10139.23464.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111024215310.10139.23464.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [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, 24 Oct 2011 21:58:04 -0000 Hi, all, The following document describes an informal proposal I made on the list a while back. Hopefully we can discuss it in Taiwan. 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 From yoshifumi.nishida@gmail.com Tue Oct 25 02:39: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 BEE5E21F8C1F for ; Tue, 25 Oct 2011 02:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.605 X-Spam-Level: X-Spam-Status: No, score=-102.605 tagged_above=-999 required=5 tests=[AWL=0.372, 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 lHzdg1scBFDl for ; Tue, 25 Oct 2011 02:39:49 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4313F21F8C1D for ; Tue, 25 Oct 2011 02:39:49 -0700 (PDT) Received: by iabn5 with SMTP id n5so476739iab.31 for ; Tue, 25 Oct 2011 02:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=D8w+7XIn5g/wSZc8CkKffmFttWU5tzYjmPOP6k8an/U=; b=NL88w2Vujx4wdyu1sQnG4q/aQ7gWHhlFp2Am0CURr+KkggtOvSzUg35YjEIHJj21Ru Y0gZ7M7AMiReJiPJOBp1ZhB16q+OOBkyj3bo23J/xpKI2TpiipthDm8+RsTKc9J89ok1 9hN1fmKoOoXQ9uEmTqmWc48jfhWFqiNdh8MYE= MIME-Version: 1.0 Received: by 10.231.46.68 with SMTP id i4mr114002ibf.24.1319535588900; Tue, 25 Oct 2011 02:39:48 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.80 with HTTP; Tue, 25 Oct 2011 02:39:48 -0700 (PDT) Date: Tue, 25 Oct 2011 02:39:48 -0700 X-Google-Sender-Auth: jZ4TvZD1y15huPF84XbMZmXXPOw Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org\"" Content-Type: text/plain; charset=ISO-8859-1 Subject: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 25 Oct 2011 09:39:49 -0000 Hi, I've thought about this draft for a while. I think there should be some useful situations for this idea, although I have the following comments on the draft. 1: The draft presumes the primary target for TFO is HTTP, although it looks more generic approach to me. I'm wondering why applicability or limitations to other protocols are not mentioned at all. 2: If TFO is used for HTTP, I think there might be a risk that TFO promotes the use of concurrent connections since there's no 3WS overhead for them. I'm wondering it might be better to provide a certain limit for concurrent use for one TFO cookie. 3: According to http://dl.acm.org/citation.cfm?id=1879174, many middleboxs keep TCP bindings over 4mins. this doesn't seem to match the explanation in the section1 of the draft. Do you have any comments on this? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From ycheng@google.com Tue Oct 25 10:02: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 EFAA021F8B10 for ; Tue, 25 Oct 2011 10:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laLlWtF5DwQ3 for ; Tue, 25 Oct 2011 10:02:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C9D0821F8B0E for ; Tue, 25 Oct 2011 10:02:46 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p9PH2jnS017011 for ; Tue, 25 Oct 2011 10:02:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319562165; bh=CqBiM0h6PUoeE5ySDG6kLC+V/tQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=xtMaBbfftmRG6lIgkaWZhRNK+9glrOxOgH0kWC8faADX6/gtW+sNwAXHxejSXhKqw Gx/KpblnNhRi7Q/PS1Dog== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=Bfdrp7XD8PteP+Umz+7LthFwR+HSjyG0PY5PHdy3Vx5VkxvhdMGLZ6ezwEa4RyqIy 909w8N5djM632qnkk3aHQ== Received: from qabg14 (qabg14.prod.google.com [10.224.20.206]) by wpaz37.hot.corp.google.com with ESMTP id p9PH1FWJ006020 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 25 Oct 2011 10:02:44 -0700 Received: by qabg14 with SMTP id g14so1300157qab.11 for ; Tue, 25 Oct 2011 10:02:44 -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=JGB+H3qPprnsMdV5vgAWhRVcDfxdzCcXu6KYOFPTC2s=; b=tT3S386z0wqOfvRUORh9D4LSjz0PvTFBn2e1ofkgADBuZwR3Jgm282bipwp8X5kR9X noaFzlnGua1xwpdIsijw== Received: by 10.224.180.207 with SMTP id bv15mr6575293qab.36.1319562164254; Tue, 25 Oct 2011 10:02:44 -0700 (PDT) Received: by 10.224.180.207 with SMTP id bv15mr6575281qab.36.1319562164068; Tue, 25 Oct 2011 10:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.180.16 with HTTP; Tue, 25 Oct 2011 10:02:24 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Tue, 25 Oct 2011 10:02:24 -0700 Message-ID: To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=20cf303b430d0c607304b022823c X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" , sivasankariit , Arvind Jain Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 25 Oct 2011 17:02:48 -0000 --20cf303b430d0c607304b022823c Content-Type: text/plain; charset=ISO-8859-1 Hi Yoshifumi, These are great questions. The third one is highly related to Joe's questions regarding HTTP persistent connections. We collected measurement data and are updating the draft to address previous questions asked on the list. We will post our update soon. On Tue, Oct 25, 2011 at 2:39 AM, Yoshifumi Nishida wrote: > Hi, > I've thought about this draft for a while. I think there should be > some useful situations for this idea, although > I have the following comments on the draft. > > 1: The draft presumes the primary target for TFO is HTTP, although > it looks more generic approach to me. > I'm wondering why applicability or limitations to other > protocols are not mentioned at all. > sure, we have talked about other usage in the last meeting presentations. We'll include them in the new draft. > > 2: If TFO is used for HTTP, I think there might be a risk that TFO > promotes the use of > concurrent connections since there's no 3WS overhead for them. > I'm wondering it might be better > to provide a certain limit for concurrent use for one TFO cookie. > Do you mean TFO promotes "more" concurrent connections? The reverse is more likely: browsers no longer needs to keep tons of active parallel connections for future use to save 3WHS, especially on tiny transactions like ads, probes, and redirects. But this limit seems too application-specific and out of scope of this draft. Plus, unfortunately vendor/servers already ignore HTTP spec on parallel connections, they certain won't bother about another one :( 3: According to http://dl.acm.org/citation.cfm?id=1879174, many > middleboxs keep TCP bindings over 4mins. > this doesn't seem to match the explanation in the section1 of > the draft. Do you have any comments on this? > Our new draft will have a section on this part. > > Thanks, > Thanks for reviewing our draft > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --20cf303b430d0c607304b022823c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yoshifumi,

These are great questions. The third one i= s highly related to Joe's questions regarding HTTP persistent connectio= ns.=A0We collected measurement data and are updating the draft to address p= revious questions asked on the list. We will post our update soon.

On Tue, Oct 25, 2011 at 2:39= AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hi,
I've thought about this draft for a while. I think there should be
some useful situations for this idea, although
I have the following comments on the draft.

=A01: The draft presumes the primary target for TFO is HTTP, although
it looks more generic approach to me.
=A0 =A0 =A0I'm wondering why applicability or limitations to other
protocols are not mentioned at all.
sure, we have= talked about other usage in the last meeting presentations. We'll incl= ude them in the new draft.
=A0

=A02: =A0If TFO is used for HTTP, I think there might be a risk that TFO promotes the use of
=A0 =A0 =A0concurrent connections since there's no 3WS overhead for th= em.
I'm wondering it might be better
=A0 =A0 =A0to provide a certain limit for concurrent use for one TFO cooki= e.
Do you mean TFO promotes "more" concurren= t connections?=A0

The reverse is more likely: brow= sers no longer needs to keep tons of active parallel connections for future= use to save 3WHS, especially on tiny transactions like ads, probes, and re= directs.

But this limit seems too application-specific and out o= f scope of this draft. Plus, unfortunately=A0vendor/servers already ignore = HTTP spec on parallel connections, they certain won't bother about anot= her one :(

middleboxs keep TCP bindings over 4mins.
=A0 =A0 =A0this doesn't seem to match the explanation in the section1 = of
the draft. Do you have any comments on this?
Our new d= raft will have a section on this part.
=A0

Thanks,
Thanks for reviewing our draft
=A0
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--20cf303b430d0c607304b022823c-- From hkchu@google.com Tue Oct 25 12:27:20 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 B9D9E21F88B6 for ; Tue, 25 Oct 2011 12:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR326vyJfyFN for ; Tue, 25 Oct 2011 12:27:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id A797E21F88A0 for ; Tue, 25 Oct 2011 12:27:18 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p9PJRDYn024040 for ; Tue, 25 Oct 2011 12:27:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319570833; bh=toVzSGbq8irHkmdpRJJIWKDBrIs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=qnvaUscTyjmuRcOyGahqlgeQ0PtGC7eVRhZ9z0lAeVcHFjUoMX9m8ecl9MeyCs8wj IOJsOjOXreSZTqZVdB1+Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=PhcpbWBY9bj0FDofRttssmekhjwLP4hSmoTGUs9Ql+BXWh4fH/45nvZjQ2AJqlc3w vOjScqwkrPyBtK/h1lfhg== Received: from vcbfl15 (vcbfl15.prod.google.com [10.220.204.79]) by wpaz17.hot.corp.google.com with ESMTP id p9PJQGlF021418 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 25 Oct 2011 12:27:12 -0700 Received: by vcbfl15 with SMTP id fl15so1243949vcb.9 for ; Tue, 25 Oct 2011 12:27:12 -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=OXmQxfW52C2/ID181xkLLqur7shNeN4zbnp8xfiCWdU=; b=KX4VtiWFYexJANjGigi+/CEICLYSKnJxNNb45Sh1aBosJHxlnWa/KDlHdMcs/BD9P4 m2s6FrafKkl0ZPV5fxOQ== Received: by 10.150.188.9 with SMTP id l9mr9434341ybf.92.1319570832061; Tue, 25 Oct 2011 12:27:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.188.9 with SMTP id l9mr9434326ybf.92.1319570831901; Tue, 25 Oct 2011 12:27:11 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Tue, 25 Oct 2011 12:27:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Oct 2011 12:27:11 -0700 Message-ID: From: Jerry Chu To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=000e0cd6ad36b1041604b02486df X-System-Of-Record: true Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 25 Oct 2011 19:27:20 -0000 --000e0cd6ad36b1041604b02486df Content-Type: text/plain; charset=ISO-8859-1 Hi, On Tue, Oct 25, 2011 at 2:39 AM, Yoshifumi Nishida wrote: > Hi, > I've thought about this draft for a while. I think there should be > some useful situations for this idea, although > I have the following comments on the draft. > > 1: The draft presumes the primary target for TFO is HTTP, although > it looks more generic approach to me. > I'm wondering why applicability or limitations to other > protocols are not mentioned at all. > TFO's primary target is for short-lived connections for the obvious reason. HTTP just happens to fit in that short-lived connection category (because unfortunately the supposed-to-be long-lived, persistent HTTP has too many limitations limiting the level of persistency we've seen in the real world. More in our upcoming -01 draft revision). The real limitation of TFO is with duplicate SYN and its implication on TCP semantic as described in section 2.1. If the current draft gives the impression the primary target of TFO is HTTP we can fix it. > 2: If TFO is used for HTTP, I think there might be a risk that TFO > promotes the use of > concurrent connections since there's no 3WS overhead for them. > TFO may promote the use of "short-lived" connections, not "concurrent" connections because it removes some of the overhead with short-lived connections. I'm wondering it might be better > to provide a certain limit for concurrent use for one TFO cookie. > See above. Also the current cookie design tries to keep the amount of states on the server side at a minimum. Your suggestion above will require some book-keeping. Another problem is one cookie may be shared by many machines behind a single IP address due to NAT. > 3: According to http://dl.acm.org/citation.cfm?id=1879174, many > middleboxs keep TCP bindings over 4mins. > this doesn't seem to match the explanation in the section1 of > the draft. Do you have any comments on this? > As Yuchung mentioned we've done lots of studies/measurements on the effectiveness and limitation of P-HTTP since the IW10 days when questions were raised about why P-HTTP is not a viable solution to our IW10 proposal then and now the TFO proposal. The details will be better covered by our upcoming -01 draft and hopefully it can address or at least clarify the P-HTTP question raised by Joe Touch and others. Thanks for your thoughtful comments. Jerry > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000e0cd6ad36b1041604b02486df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

On Tue, Oct 25, 2011 at 2:39 AM, Yoshifum= i Nishida <n= ishida@sfc.wide.ad.jp> wrote:
Hi,
I've thought about this draft for a while. I think there should be
some useful situations for this idea, although
I have the following comments on the draft.

=A01: The draft presumes the primary target for TFO is HTTP, although
it looks more generic approach to me.
=A0 =A0 =A0I'm wondering why applicability or limitations to other
protocols are not mentioned at all.

TFO= 's primary target is for short-lived connections for the obvious reason= .
HTTP just happens to fit in that short-lived connection categor= y (because
unfortunately the supposed-to-be long-lived, persistent HTTP has too m= any
limitations limiting the level=A0of persistency we've see= n in the real world. More
in our upcoming -01 draft revision).

The real limitation of TFO is with duplicate SYN and it= s implication on TCP
semantic as described in section 2.1.
<= div>
If the current draft gives the impression the primary ta= rget of TFO is HTTP
we can=A0fix it.


=A02: =A0If TFO is used for HTTP, I think there might be a risk that TFO promotes the use of
=A0 =A0 =A0concurrent connections since there's no 3WS overhead for th= em.

TFO may promote the use of "sh= ort-lived" connections, not "concurrent"
connectio= ns=A0because it removes some of the overhead with short-lived
connections.

I'm wondering it might be better
=A0 =A0 =A0to provide a certain limit for concurrent use for one TFO cooki= e.

See above. Also the current cookie d= esign tries to keep the amount of
states on the server side at a = minimum. Your suggestion above will
require some book-keeping. Another problem is one cookie may be
<= div>shared by many machines behind a single IP address due to NAT.


=A03: According to http://dl.acm.org/citation.cfm?id=3D1879174, many middleboxs keep TCP bindings over 4mins.
=A0 =A0 =A0this doesn't seem to match the explanation in the section1 = of
the draft. Do you have any comments on this?

As Yuchung mentioned we've done lots of studies/measurements on t= he
effectiveness and limitation of P-HTTP=A0since the IW10 days w= hen
questions were raised about why P-HTTP is not a viable solution to our=
IW10 proposal then and now the TFO proposal. The details will be= better
covered=A0by our=A0upcoming -01 draft and hopefully it ca= n address or at least
clarify the=A0P-HTTP question raised by Joe Touch and others.

Thanks for your thoughtful comments.

<= div>Jerry


Thanks,
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--000e0cd6ad36b1041604b02486df-- From internet-drafts@ietf.org Tue Oct 25 13:48:56 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 CF1A021F8C44; Tue, 25 Oct 2011 13:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 OT1v9ZO6Y0l1; Tue, 25 Oct 2011 13:48:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480F721F8C46; Tue, 25 Oct 2011 13:48:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025204856.15275.86046.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 13:48:56 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-proportional-rate-reduction-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, 25 Oct 2011 20:48:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : Proportional Rate Reduction for TCP Author(s) : Matt Mathis Nandita Dukkipati Yuchung Cheng Filename : draft-ietf-tcpm-proportional-rate-reduction-00.txt Pages : 15 Date : 2011-10-24 This document describes an experimental algorithm, Proportional Rate Reduction (PPR) to improve the accuracy of the amount of data sent by TCP during loss recovery. Standard Congestion Control requires that TCP and other protocols reduce their congestion window in response to losses. This window reduction naturally occurs in the same round trip as the data retransmissions to repair the losses, and is implemented by choosing not to transmit any data in response to some ACKs arriving from the receiver. Two widely deployed algorithms are used to implement this window reduction: Fast Recovery and Rate Halving. Both algorithms are needlessly fragile under a number of conditions, particularly when there is a burst of losses that such that the number of ACKs returning to the sender is small. Proportional Rate Reduction avoids these excess window reductions such that at the end of recovery the actual window size will be as close as possible to ssthresh, the window size determined by the congestion control algorithm. It is patterned after Rate Halving, but using the fraction that is appropriate for target window chosen by the congestion control algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-proportional-rate-reduc= tion-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-proportional-rate-reduct= ion-00.txt From yoshifumi.nishida@gmail.com Wed Oct 26 02:54: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 6C32221F8B02 for ; Wed, 26 Oct 2011 02:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.729 X-Spam-Level: X-Spam-Status: No, score=-102.729 tagged_above=-999 required=5 tests=[AWL=0.248, 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 9QrBta4ibt6a for ; Wed, 26 Oct 2011 02:54:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E3D8F21F8AFC for ; Wed, 26 Oct 2011 02:54:40 -0700 (PDT) Received: by iabn5 with SMTP id n5so2001855iab.31 for ; Wed, 26 Oct 2011 02:54:39 -0700 (PDT) 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=oQepGgA5ZBACIkVBY2X+keJFNf3uSI6i0KWNoO9zVGs=; b=l+kf9jmDjuVXkIH5D/T18j+YZfVlMXRyelQmOf10s5cZRD9/F7pHRMp1VVc/zqLeLr XtKhPzTkjH6tPb3g94VdcDipyf2RV4ZfY6hhBz3R1B28EPXHiX/mRX4I7cDoRl+fzXPm 3/it4AFvtw/PUXqHWOHNZAzWMI0iqUM/r9QQM= MIME-Version: 1.0 Received: by 10.42.148.198 with SMTP id s6mr50721170icv.56.1319622879528; Wed, 26 Oct 2011 02:54:39 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.80 with HTTP; Wed, 26 Oct 2011 02:54:39 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Oct 2011 02:54:39 -0700 X-Google-Sender-Auth: dBl5cBjrTasZe4Pu_g8EKQwjYO8 Message-ID: From: Yoshifumi Nishida To: Jerry Chu , Yuchung Cheng Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 09:54:41 -0000 Hi Jerry, Yuchung, Thanks for the response. 2011/10/25 Jerry Chu : >> =A02: =A0If TFO is used for HTTP, I think there might be a risk that TFO >> promotes the use of >> =A0 =A0 =A0concurrent connections since there's no 3WS overhead for them= . > > TFO may promote the use of "short-lived" connections, not "concurrent" > connections=A0because it removes some of the overhead with short-lived > connections. I agree that TFO can promote the use of short-lived connections. My concern here is there might be no guarantee that TFO is used only for short-lived connection. (also, we have no clear definition for short-lived connection) I'm thinking that some TFO connections can be long and it might increase concurrent connections. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From perfgeek@mac.com Wed Oct 26 07:15: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 DDDB521F8B33 for ; Wed, 26 Oct 2011 07:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbK4T62nCvqi for ; Wed, 26 Oct 2011 07:15:29 -0700 (PDT) Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by ietfa.amsl.com (Postfix) with ESMTP id C4E9321F8A62 for ; Wed, 26 Oct 2011 07:15:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.65] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp013.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LTO00BBIFLMZX60@asmtp013.mac.com> for tcpm@ietf.org; Wed, 26 Oct 2011 07:15:23 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-10-26_04:2011-10-26, 2011-10-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110260125 From: rick jones In-reply-to: Date: Wed, 26 Oct 2011 07:15:21 -0700 Message-id: References: To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1084) Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 14:15:31 -0000 On Oct 26, 2011, at 2:54 AM, Yoshifumi Nishida wrote: > > I agree that TFO can promote the use of short-lived connections. > > My concern here is there might be no guarantee that TFO is used only for > short-lived connection. (also, we have no clear definition for > short-lived connection) > I'm thinking that some TFO connections can be long and it might increase > concurrent connections. While it is but anecdote I have heard people say "I'd use TCP if I could establish connections more quickly" but I don't think I've ever heard anyone say "If only I could establish connections more quickly, I would increase my concurrent connections." As for a definition of a short-lived connection, I'll go ahead and toss a stake in the ground at "less than or equal to 4 RTT" and/or perhaps "exchanges less than or equal to 2 window's worth of data" (ignoring those stacks which like to have a dynamic window size) No specific logic to it, just a starting point for discussion, if any. rick jones there is no rest for the wicked, yet the virtuous have no pillows From hkchu@google.com Wed Oct 26 10:24:42 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 D39B11F0C36 for ; Wed, 26 Oct 2011 10:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyZjIfGQziN6 for ; Wed, 26 Oct 2011 10:24:42 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id B4D3B1F0C34 for ; Wed, 26 Oct 2011 10:24:41 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p9QHOewb027123 for ; Wed, 26 Oct 2011 10:24:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319649880; bh=f1s3MK/sGHM6gOzsWbrNQq+2FNk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=hshxemtsJ9bYM7l55iI+tYBjUxRA+rcjEOVo3gs5EP/gynjkdvONTi23KI/p0JnYT yo+Iwd9R/CVnFDe0/TEdA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=dBIY35I/lgGAdzr/oxHGNYKo8wrFLrembF9XFCzXXNNfI/X4P2qkF1hfQkKjjDgpz iJTk898r2uIvOA6ItpQYA== Received: from vws18 (vws18.prod.google.com [10.241.21.146]) by wpaz24.hot.corp.google.com with ESMTP id p9QHO0gO008668 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 26 Oct 2011 10:24:39 -0700 Received: by vws18 with SMTP id 18so2707568vws.9 for ; Wed, 26 Oct 2011 10:24:35 -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=M320YOj7CISHI9V8/eKeRSjvmM3rZ2jkeVJnjpRnDko=; b=dmRZYD+Ke39IKh6Bebb3sn1ROtIr+BanVMSxMoq4cNWS/8hkPEQIjDdQe6ZV3h0TvO oxrF7Np2C+528UOpeNLg== Received: by 10.150.72.26 with SMTP id u26mr29381791yba.62.1319649875167; Wed, 26 Oct 2011 10:24:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.72.26 with SMTP id u26mr29381778yba.62.1319649875017; Wed, 26 Oct 2011 10:24:35 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Wed, 26 Oct 2011 10:24:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Oct 2011 10:24:34 -0700 Message-ID: From: Jerry Chu To: rick jones , Yoshifumi Nishida Content-Type: multipart/alternative; boundary=000e0cd592c807402804b036ee21 X-System-Of-Record: true Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 17:24:42 -0000 --000e0cd592c807402804b036ee21 Content-Type: text/plain; charset=ISO-8859-1 Hi Yoshifumi, Rick, On Wed, Oct 26, 2011 at 7:15 AM, rick jones wrote: > > On Oct 26, 2011, at 2:54 AM, Yoshifumi Nishida wrote: > > > > I agree that TFO can promote the use of short-lived connections. > > > > My concern here is there might be no guarantee that TFO is used only for > > short-lived connection. (also, we have no clear definition for > > short-lived connection) > Indeed. But people will quickly realize there is little or no benefit from TFO. > > I'm thinking that some TFO connections can be long and it might increase > > concurrent connections. > Still I don't see a strong correlation between TFO and increasing concurrent connections... > While it is but anecdote I have heard people say "I'd use TCP if I could > establish connections more quickly" but I don't think I've ever heard anyone > say "If only I could establish connections more quickly, I would increase my > concurrent connections." > Yep. TFO is ideal for latency sensitive, short-lived, request/response type of protocols (remember the "Transaction/TCP in the 90'), which are often based on UDP, with HTTP being one exception. (In fact our SPDY engrs often threaten to switch to UDP if we TCP engrs do not make TCP faster :)). Our goal is to make TFO a viable alternative to UDP in terms of latency. We're investigating, e.g., to replace our internal cluster heart-beat msgs over UDP to TFO. Jerry > As for a definition of a short-lived connection, I'll go ahead and toss a > stake in the ground at "less than or equal to 4 RTT" and/or perhaps > "exchanges less than or equal to 2 window's worth of data" (ignoring those > stacks which like to have a dynamic window size) No specific logic to it, > just a starting point for discussion, if any. > > rick jones > there is no rest for the wicked, yet the virtuous have no pillows > > --000e0cd592c807402804b036ee21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yoshifumi, Rick,

On Wed, Oct 26, 2011= at 7:15 AM, rick jones <perfgeek@mac.com> wrote:

On Oct 26, 2011, at 2:54 AM, Yoshifumi Nishida wrote:
>
> I agree that TFO can promote the use of short-lived connections.
>
> My concern here is there might be no guarantee that TFO is used only f= or
> short-lived connection. (also, we have no clear definition for
> short-lived connection)

Inde= ed. But people will quickly realize there is little or no benefit from TFO.=
=A0
> I'm thinking that some TFO connections can be long and it might in= crease
> concurrent connections.

Stil= l I don't see a strong correlation between TFO and increasing concurren= t
connections...


While it is but anecdote I have heard people say "I'd use TC= P if I could establish connections more quickly" but I don't think= I've ever heard anyone say "If only I could establish connections= more quickly, I would increase my concurrent connections."

Yep. TFO is ideal for latency sensitive, s= hort-lived, request/response type of protocols
(remember the &quo= t;Transaction/TCP in the 90'), which are often based on UDP, with HTTP<= /div>
being=A0one exception. (In fact our SPDY engrs often threaten to switc= h to UDP if we
TCP engrs do not make TCP faster :)). Our goal is = to make TFO a viable alternative
to UDP in terms of latency. We&#= 39;re investigating, e.g., to replace our internal cluster
heart-beat msgs over UDP to TFO.

Jerry
<= div>

As for a definition of a short-lived connection, I'll go ahead and toss= a stake in the ground at "less than or equal to 4 RTT" and/or pe= rhaps "exchanges less than or equal to 2 window's worth of data&qu= ot; (ignoring those stacks which like to have a dynamic window size) No spe= cific logic to it, just a starting point for discussion, if any.

rick jones
there is no rest for the wicked, yet the virtuous have no pillows


--000e0cd592c807402804b036ee21-- From lars.eggert@nokia.com Wed Oct 26 10:35: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 D26F211E808D for ; Wed, 26 Oct 2011 10:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.703 X-Spam-Level: X-Spam-Status: No, score=-102.703 tagged_above=-999 required=5 tests=[AWL=-0.104, 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 Tk+SV9qPVssI for ; Wed, 26 Oct 2011 10:35:00 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC9E11E8086 for ; Wed, 26 Oct 2011 10:35:00 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9QHYsfU031525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2011 20:34:56 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.2 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_A46B553D-A8C2-4703-9449-0200983E39CA"; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Wed, 26 Oct 2011 20:34:51 +0300 Message-Id: <80092882-CE3C-4911-8106-40A24F7B9645@nokia.com> References: To: Jerry Chu X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.fit.nokia.com); Wed, 26 Oct 2011 20:34:52 +0300 (EEST) X-Nokia-AV: Clean Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 17:35:00 -0000 --Apple-Mail=_A46B553D-A8C2-4703-9449-0200983E39CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 2011-10-26, at 20:24, Jerry Chu wrote: > Yep. TFO is ideal for latency sensitive, short-lived, request/response = type > of protocols > (remember the "Transaction/TCP in the 90'), which are often based on = UDP, > with HTTP > being one exception. (In fact our SPDY engrs often threaten to switch = to UDP > if we > TCP engrs do not make TCP faster :)). Our goal is to make TFO a viable > alternative > to UDP in terms of latency. We're investigating, e.g., to replace our > internal cluster > heart-beat msgs over UDP to TFO. I'd be thrilled if an IETF activity in this space also addressed the = DNS-over-TCP use case, which is the other scenario where folks see many = repeated small connections. Lars= --Apple-Mail=_A46B553D-A8C2-4703-9449-0200983E39CA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEFN3YRH35M0FMeg36jxbcOIwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEwMTMwMDAwMDBaFw0x MjEwMTIyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0XBgP3mTed9BOw4AGDgVaaop cmXqyewt4NAj5j0upYg6EzEAlkUTt6ZHE8AxCQeXt6q9/4ZjnuJeKuifA4bgXEfgUwOmMFayCH6J ecSpkfbo0YMw0ivNBXBhdEKuwSRyaZ1sCEoWE6Nu9pksuHoPkP0BQJMylK7NoJAYG9DY1pXHr4DS F3BIpKVBsKLMrX2ls0GJCpb1Ull0mugJyH6XZ8eWIU/t9JVHtmCEFj7QS+/7eJDp9DrZ/s8+m35p YLYIi/Gwj8zOU/xtjxp9NzblzJDImXpsIxQIy/oM/bXDqqS/McBUw+V3F55PcxRnw2N0HpJaqq/o tBLAwjt6GnZAiQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQB2nb6FbBdGaVQ8srzOqr9gahXwkBl2+RMEaH/T3OS1o6Gf40Qi 1EvcW3tSBzefop/S4QfEbjLIidFWUdgSSBTQFV8LnbNFUnLLcc/6Wpn+1UdHlhbW3pC8rCuOPcGD QVCzCk9aMHDwUC6hq1KchGjpSd+K7X1gBwe3RfAWN2MafQBYq12rsV4YSe//9ye41/yvgMk3RQBW 3hUE3eIjKcg2+HZQQmSWSeaYd2YLfT6CDWd8r+ceMD925P3Ak/6ZvTpw06l8a3UgByiTJ5ID45dm eVfJkI2LLzlYdSe6PwqhgrArmtJxgs8g+X3WO9YexpnFYi+43kPXgid2GmjEXeKXMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBTd2ER9+TNBTHoN+o8W3DiMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTAyNjE3MzQ1MlowIwYJKoZIhvcNAQkE MRYEFFBGZXwnpIAS8gwlKl3zyQCnwSb/MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFN3YRH35M0FMeg36jxb cOIwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBTd2ER9+TNBTHoN+o8W3DiMA0GCSqGSIb3DQEBAQUABIIB AMD4tATPZztmWGWp8jACYjyMljRl7eSBqaJ6OxmJaQAPtgS5LBUTCYR3CvLuZXTesK5GbruZpNIl ySSV4WPkHgS68RDm7+uWJ/Tc0BqrvKhypVdjvhaKbpYC6aJnVfL/FdQZgcFW02tAXHrvgMbj8l9m UOZDXbQ2s4BvyjZlFwbSe2788m2+1D9q/zBL0o2xpRAfIOuv4lIj/YlF/CUwKLmjxzp9EFzCdRXb vPBw9af9DhBZB4bW8FMb7nvIsIv2X9bi6yLJt9CQPnYSgNZdl78j2rg7l1GR9vv7ITi/ddg9nmTX wu6NB9fsHTc1ha9MB11ERmeTh7XbjwKJoWESAD0AAAAAAAA= --Apple-Mail=_A46B553D-A8C2-4703-9449-0200983E39CA-- From hkchu@google.com Wed Oct 26 10:45: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 535C321F8B43 for ; Wed, 26 Oct 2011 10:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 wQgtPbZ7br3O for ; Wed, 26 Oct 2011 10:45:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 965CB21F8B34 for ; Wed, 26 Oct 2011 10:45:48 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p9QHjfmv021758 for ; Wed, 26 Oct 2011 10:45:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319651142; bh=p90WHBYz47fWZJVqQD/lpULGifc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ioa6GdKVLamCnZdSo1KwzWqev/TxNu0It3tDnyEEL9MXssHeRUjFNTr9lf55d1LnE ye3W6hE/34B2veWNSHmdw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=pyjyJx522UQad74BMgN6N1qP3mQ5ZfxuO9rAZgtfJQtalmyVa6w22StGMR/HEOrq/ Df0EmEnbQiuwvDwswvO6w== Received: from gyc15 (gyc15.prod.google.com [10.243.49.143]) by hpaq6.eem.corp.google.com with ESMTP id p9QHe4gs027580 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 26 Oct 2011 10:45:40 -0700 Received: by gyc15 with SMTP id 15so2703992gyc.1 for ; Wed, 26 Oct 2011 10:45:40 -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=F9YDmS1JRlwCPC4Nu38z5ATpNsbyDK07yNTEsH+jd2Y=; b=gBPS161TZPV4DbxM8AQNNkUFa96yo3hjEA1yREwzLiPFNBi9q3IEbW9daZ8DaplgKw oAAUjZ/+ZiRXHaOhLCtw== Received: by 10.151.87.12 with SMTP id p12mr11240507ybl.2.1319651140543; Wed, 26 Oct 2011 10:45:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.87.12 with SMTP id p12mr11240486ybl.2.1319651140303; Wed, 26 Oct 2011 10:45:40 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Wed, 26 Oct 2011 10:45:40 -0700 (PDT) In-Reply-To: <80092882-CE3C-4911-8106-40A24F7B9645@nokia.com> References: <80092882-CE3C-4911-8106-40A24F7B9645@nokia.com> Date: Wed, 26 Oct 2011 10:45:40 -0700 Message-ID: From: Jerry Chu To: Lars Eggert Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 17:45:49 -0000 Hi Lars, On Wed, Oct 26, 2011 at 10:34 AM, Lars Eggert wrote: > > Hi, > > On 2011-10-26, at 20:24, Jerry Chu wrote: > > Yep. TFO is ideal for latency sensitive, short-lived, request/response type > > of protocols > > (remember the "Transaction/TCP in the 90'), which are often based on UDP, > > with HTTP > > being one exception. (In fact our SPDY engrs often threaten to switch to UDP > > if we > > TCP engrs do not make TCP faster :)). Our goal is to make TFO a viable > > alternative > > to UDP in terms of latency. We're investigating, e.g., to replace our > > internal cluster > > heart-beat msgs over UDP to TFO. > > I'd be thrilled if an IETF activity in this space also addressed the DNS-over-TCP use case, which is the other scenario where folks see many repeated small connections. Yep, DNSSEC/TCP is on our radar screen too. We're thinking hard if the TFO cookie can be made optional for some use cases where the reflection attack is not an issue. TFO cookies require a prior regular 3WHS to acquire cookies hence limiting the benefit only to later connections to the same server. Jerry > > Lars From hkchu@google.com Wed Oct 26 11:27: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 2A14D21F8B49 for ; Wed, 26 Oct 2011 11:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6Ask9PmK0hM for ; Wed, 26 Oct 2011 11:27:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 12B1F21F84FD for ; Wed, 26 Oct 2011 11:27:39 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p9QIRZLN012116 for ; Wed, 26 Oct 2011 11:27:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319653655; bh=4m9oyj2i+o0kDJE/6xIwKqHVHHo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=vgeRxlPcQIWWAReaQaeG92DsGNOVn6/0poZ1eLhxiu2/ON/h4q2zL2AU1SysPrhfK wNMqLA+5dDtEY3wmZZuyQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=BF06DTNY7qpMswwKiO7N8k2NfSca495L+/yaTYlusEfiSkUUpPT4QGsBWTvGh73fl Yc7YkTPCJW/sdfo3BWBmQ== Received: from qyk2 (qyk2.prod.google.com [10.241.83.130]) by wpaz37.hot.corp.google.com with ESMTP id p9QIRYE3030839 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 26 Oct 2011 11:27:34 -0700 Received: by qyk2 with SMTP id 2so2681380qyk.0 for ; Wed, 26 Oct 2011 11:27:34 -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=10judcYJiJyJOrurXjv/L1/9LHEOJ2t/hBaOszN/7KI=; b=ZflOfzcYUekZk73it/aouQsS3ufuRUTEKAxHn/hfuzq9oKEoo7zGSLgknScWSc1YUE gUPXQyFQe3DV2S52pEWQ== Received: by 10.151.87.12 with SMTP id p12mr11366244ybl.2.1319653653981; Wed, 26 Oct 2011 11:27:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.87.12 with SMTP id p12mr11366233ybl.2.1319653653844; Wed, 26 Oct 2011 11:27:33 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Wed, 26 Oct 2011 11:27:33 -0700 (PDT) In-Reply-To: References: <4EA84493.2030003@isi.edu> Date: Wed, 26 Oct 2011 11:27:33 -0700 Message-ID: From: Jerry Chu To: touch@isi.edu Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 18:27:41 -0000 Hi Joe, On Wed, Oct 26, 2011 at 10:34 AM, Joe Touch wrote: > > > On 10/26/2011 10:24 AM, Jerry Chu wrote: > ... >> >> Indeed. But people will quickly realize there is little or no benefit >> from TFO. > > That's my concern. Both to play nice with NATs and as a simpler mechanism in > general, it's easier to use persistent connections AFAICT. Obviously my statement above (TFO provides little or no benefit) was meant for long-lived connections. It turns out persistent connections are not any easier for NAT than TFO is (with SYN pkts carrying data). Persistent connections can tie up large amount of resources, both on the end hosts and on the middleboxes. Our Chrome engrs for Android discovered a serious problem recently with long-lived HTTP connections when middleboxes, under pressure for free mapping space, either silently dropped, or sent RST to handsets already in power-saving mode when removing existing translation from persistent connections. The end result is HTTP connections from mobile devices may hang for a long time until TCP abort timeout (many middleboxes do not generate RST when receiving pkts that do not have any mapping entries for some reason). This problem was serious (browser hung) enough that our Chrome engrs are pondering about disabling P-HTTP. More on why persistent connections are not panacea can be found in our upcoming -01 draft revision. I have said this before for our IW10 proposal as well - if persistent connections had been a viable solution to our latency problem we would not have wasted our time looking for alternative solutions. Jerry > > Joe > From touch@isi.edu Wed Oct 26 12:32: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 828C721F86AA for ; Wed, 26 Oct 2011 12:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.27 X-Spam-Level: X-Spam-Status: No, score=-105.27 tagged_above=-999 required=5 tests=[AWL=1.329, 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 bNNLDx3wSCmm for ; Wed, 26 Oct 2011 12:32:25 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id F037121F86A6 for ; Wed, 26 Oct 2011 12:32:24 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p9QJW1LR028199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Oct 2011 12:32:01 -0700 (PDT) Message-ID: <4EA86031.50307@isi.edu> Date: Wed, 26 Oct 2011 12:32:01 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jerry Chu References: <4EA84493.2030003@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" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 19:32:25 -0000 Hi, Jerry, A lot of what you describe below sounds like clutching onto a single persistent connection too long. I wonder if a 90% solution would have resulted in the bulk of the benefit and avoided these issues. Joe On 10/26/2011 11:23 AM, Jerry Chu wrote: > Hi Joe, > > On Wed, Oct 26, 2011 at 10:34 AM, Joe Touch wrote: >> >> >> On 10/26/2011 10:24 AM, Jerry Chu wrote: >> ... >>> >>> Indeed. But people will quickly realize there is little or no benefit >>> from TFO. >> >> That's my concern. Both to play nice with NATs and as a simpler mechanism in >> general, it's easier to use persistent connections AFAICT. > > Obviously my statement above (TFO provides little or no benefit) was meant for > long-lived connections. > > It turns out persistent connections are not any easier for NAT than > TFO is (with SYN > pkts carrying data). Persistent connections can tie up large amount of > resources, > both on the end hosts and on the middleboxes. Our Chrome engrs for Android > discovered a serious problem recently with long-lived HTTP connections when > middleboxes, under pressure for free mapping space, either silently dropped, or > sent RST to handsets already in power-saving mode when removing existing > translation from persistent connections. The end result is HTTP connections > from mobile devices may hang for a long time until TCP abort timeout (many > middleboxes do not generate RST when receiving pkts that do not have any > mapping entries for some reason). > > This problem was serious (browser hung) enough that our Chrome engrs are > pondering about disabling P-HTTP. More on why persistent connections are not > panacea can be found in our upcoming -01 draft revision. > > I have said this before for our IW10 proposal as well - if persistent > connections > had been a viable solution to our latency problem we would not have wasted our > time looking for alternative solutions. > > Jerry > >> >> Joe >> From yoshifumi.nishida@gmail.com Wed Oct 26 13:24: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 193FB1F0C48 for ; Wed, 26 Oct 2011 13:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.791 X-Spam-Level: X-Spam-Status: No, score=-102.791 tagged_above=-999 required=5 tests=[AWL=0.186, 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 jBh95SEWRhrO for ; Wed, 26 Oct 2011 13:24:46 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE891F0C4D for ; Wed, 26 Oct 2011 13:24:46 -0700 (PDT) Received: by iabn5 with SMTP id n5so2703570iab.31 for ; Wed, 26 Oct 2011 13:24:46 -0700 (PDT) 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=XBYv4EqqLK2TVk3xSO3VgoLDJKu2Gxf+j7gcb5Uovbo=; b=m0pB76Iwa4SMWTLpnp1ty64b0XMV+mCPctUUCAA/Ed8aDQ8+de7gseEd38ROx+nbKD 4sSZ/GtPx4xUaf3RL5moLrOHzTtw5ZtVdTcFLWW475W79/BOWgTqbjpZ7f/nOdzkwDoz uSbC/Dw1dwBazimfVgFg8NxvVMnJcSnkgzSLE= MIME-Version: 1.0 Received: by 10.231.27.29 with SMTP id g29mr2435854ibc.11.1319660686199; Wed, 26 Oct 2011 13:24:46 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.80 with HTTP; Wed, 26 Oct 2011 13:24:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Oct 2011 13:24:46 -0700 X-Google-Sender-Auth: Dd71QQ86c4I8u6PESaQd5scJ5Qk Message-ID: From: Yoshifumi Nishida To: Jerry Chu Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 20:24:47 -0000 Hi Jerry, 2011/10/26 Jerry Chu : > Hi Yoshifumi, Rick, > On Wed, Oct 26, 2011 at 7:15 AM, rick jones wrote: >> >> On Oct 26, 2011, at 2:54 AM, Yoshifumi Nishida wrote: >> > >> > I agree that TFO can promote the use of short-lived connections. >> > >> > My concern here is there might be no guarantee that TFO is used only for >> > short-lived connection. (also, we have no clear definition for >> > short-lived connection) > > Indeed. But people will quickly realize there is little or no benefit from > TFO. > >> >> > I'm thinking that some TFO connections can be long and it might increase >> > concurrent connections. > > Still I don't see a strong correlation between TFO and increasing concurrent > connections... Probably, I should have asked how P-HTTP and TFO co-exist. If TFO pushes out P-HTTP, I'm guessing that it promotes concurrent connections as a consequence. I guess I should take a look at 01 version. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From ncardwell@google.com Wed Oct 26 13:45: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 8796421F8B84 for ; Wed, 26 Oct 2011 13:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jw59tCsSNWLw for ; Wed, 26 Oct 2011 13:45:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id A89A621F8B81 for ; Wed, 26 Oct 2011 13:45:31 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p9QKjQEL029849 for ; Wed, 26 Oct 2011 13:45:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319661926; bh=QG0hwWYX/NtVwWFvvZC37Wvi3vQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=s6iNN8+Hc7+9oLMWLFCSovjRMMa7js7UzLLGVIWK60Fi/x88OP2cY2M8wbTKaFJp2 i7iVC84YY1zxo7QTYsCTA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=AdHHnkt4enKXilc4rGdtEAmTed2o161PTEkcWP2ocsFcPCNSos65prbpzgBFCdKsY 21NJCeb/ZtdFD99hF960Q== Received: from ggnk4 (ggnk4.prod.google.com [10.218.97.68]) by wpaz21.hot.corp.google.com with ESMTP id p9QKfhmE027022 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 26 Oct 2011 13:45:25 -0700 Received: by ggnk4 with SMTP id k4so3142261ggn.11 for ; Wed, 26 Oct 2011 13:45:23 -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=FBiQ7gPEGIGAtTUeOdTgnZjcw1x8chM48KareJgoJj8=; b=rbuDmDb1nrRdVtOYBiVmPGlEgHKVOVlxK8S3mQUFpwRqlKy6jz1y3igTLHf7xPNJqq VR0n0P1zqn5+ZBKCm66A== Received: by 10.150.159.21 with SMTP id h21mr13286603ybe.27.1319661923107; Wed, 26 Oct 2011 13:45:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.159.21 with SMTP id h21mr13286588ybe.27.1319661922945; Wed, 26 Oct 2011 13:45:22 -0700 (PDT) Received: by 10.151.78.4 with HTTP; Wed, 26 Oct 2011 13:45:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Oct 2011 16:45:22 -0400 Message-ID: From: Neal Cardwell To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=000e0cd731fa240b3904b039bc06 X-System-Of-Record: true Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 20:45:32 -0000 --000e0cd731fa240b3904b039bc06 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 26, 2011 at 4:24 PM, Yoshifumi Nishida wrote: > > Still I don't see a strong correlation between TFO and increasing > concurrent > > connections... > > Probably, I should have asked how P-HTTP and TFO co-exist. > If TFO pushes out P-HTTP, I'm guessing that it promotes concurrent > connections > as a consequence. I guess I should take a look at 01 version. > I doubt TFO will displace P-HTTP where P-HTTP is already used widely. An already-open connection will almost always outperform a TFO connection, due to cwnd, RTT, RTO, etc. being "warmed-up" in the already-open case. In fact, browsers are already starting to choose between already-open connections based on estimated cwnd: http://blog.httpwatch.com/2011/06/10/investigating-the-network-performance-of-firefox-5/ Given the effort developers are already investing in picking the warmest of the already-open connections, it seems unlikely many applications will choose to cold-start using TFO unless they were forced to close a P-HTTP connection due to memory pressure. It seems like if/when TFO is in place most applications engineered for performance will have some sort of preference hierarchy like: 1) "warmed-up" P-HTTP connection 2) "cold" P-HTTP connection 3) new TFO connection 4) new 3-way-handshake connection neal --000e0cd731fa240b3904b039bc06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 26, 2011 at 4:24 PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
> Still I don't see a strong correlation between TFO and increasing = concurrent
> connections...

Probably, I should have asked how P-HTTP and TFO co-exist.
If TFO pushes out P-HTTP, I'm guessing that it promotes concurrent conn= ections
as a consequence. I guess I should take a look at 01 version.

I doubt TFO will displace P-HTTP where P-HTTP is alr= eady used widely. An already-open connection will almost always outperform = a TFO connection, due to cwnd, RTT, RTO, etc. being "warmed-up" i= n the already-open case.

In fact, browsers are already starting to choose betwee= n already-open connections based on estimated cwnd:

Given the effort developers are already investing in pi= cking the warmest of the already-open connections, it seems unlikely many a= pplications will choose to cold-start using TFO unless they were forced to = close a P-HTTP connection due to memory pressure.

It seems like if/when TFO is in place most applications= engineered for performance will have some sort of preference hierarchy lik= e:

1) "warmed-up" P-HTTP connection
2) "cold" P-HTTP connection
3) new TFO connection<= /div>
4) new 3-way-handshake connection

neal

--000e0cd731fa240b3904b039bc06-- From hagen@jauu.net Wed Oct 26 14:27:10 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 8646E21F8B35 for ; Wed, 26 Oct 2011 14:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 7jE2xNqPmwRs for ; Wed, 26 Oct 2011 14:27:09 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7D80821F8B34 for ; Wed, 26 Oct 2011 14:27:09 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id AA37AF44143; Wed, 26 Oct 2011 23:27:06 +0200 (CEST) Date: Wed, 26 Oct 2011 23:27:05 +0200 From: Hagen Paul Pfeifer To: Neal Cardwell Message-ID: <20111026212705.GA3478@nuttenaction> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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) Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 21:27:10 -0000 * Neal Cardwell | 2011-10-26 16:45:22 [-0400]: >I doubt TFO will displace P-HTTP where P-HTTP is already used widely. An >already-open connection will almost always outperform a TFO connection, due >to cwnd, RTT, RTO, etc. being "warmed-up" in the already-open case. For Linux the connection is often "warmed-up" because of the metric cache (TCP congestion window, RTT estimates). Furthermore, IW10 will relax this one more time and IW10 may adequate for a lot of HTTP transfers. Not sure if an open connection will outperform a new established connection nowadays (except the 3WHS, of course - which is addresses by TFO ;). One question Yuchung, Jerry: are there any limitation not to exchange data bidirectional in the SYN AND SYN-ACK packet? To cite the abstract: "allows data to be carried in the SYN or SYN-ACK packets and consumed" ^^ I see no real limitation that the "or" cannot be replaced by "and"? Did I miss something? ;) Hagen From hkchu@google.com Wed Oct 26 14:42: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 0197A21F84C9 for ; Wed, 26 Oct 2011 14:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WQ6IZw9qqdI for ; Wed, 26 Oct 2011 14:42:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id E9CFB21F84A5 for ; Wed, 26 Oct 2011 14:42:47 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p9QLgkes011758 for ; Wed, 26 Oct 2011 14:42:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319665367; bh=PfGM6VH4dW/kAgALWN+wOHglWFo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Ketj8c/ttrVavbYmGIt6LZMwpnmcf5GsXpR1YfztvsUuA/zDBhF5DRWn1DyoD+Lsq Cg8Az1bDqpZduvqb1GjxA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=F5YoozlKxd1u7BUg0F2NlFM2rMweD+Vg6xkJZLsJh8YSA4s6SeUoTHw6XHxTJFEMY qSjAbC4iWMHtYt7k/E2/g== Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by wpaz21.hot.corp.google.com with ESMTP id p9QLfCLQ017680 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 26 Oct 2011 14:42:45 -0700 Received: by qyk30 with SMTP id 30so3006724qyk.1 for ; Wed, 26 Oct 2011 14:42:41 -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=ZZcI1zwtgBQHOpk2QRTAQeWr+c4tsn7s97hOYHgyfNQ=; b=OjHMFnjt2S50tPMWq+Kz2RmiJ2q0e5jVcxyXDy8x6tAJ1R8rqKH0Ecfh2R5ixlckbW EpjZh8eN1zR68vPLZ7rg== Received: by 10.150.60.10 with SMTP id i10mr27530933yba.77.1319665361485; Wed, 26 Oct 2011 14:42:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.60.10 with SMTP id i10mr27530919yba.77.1319665361300; Wed, 26 Oct 2011 14:42:41 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Wed, 26 Oct 2011 14:42:41 -0700 (PDT) In-Reply-To: <4EA86031.50307@isi.edu> References: <4EA84493.2030003@isi.edu> <4EA86031.50307@isi.edu> Date: Wed, 26 Oct 2011 14:42:41 -0700 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: multipart/alternative; boundary=000e0cd6aeac152e2504b03a8999 X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 21:42:49 -0000 --000e0cd6aeac152e2504b03a8999 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, On Wed, Oct 26, 2011 at 12:32 PM, Joe Touch wrote: > Hi, Jerry, > > A lot of what you describe below sounds like clutching onto a single > persistent connection too long. > Correct except what is considered "too long" is getting shorter and shorter. > > I wonder if a 90% solution would have resulted in the bulk of the benefit > and avoided these issues. Many practical considerations over the year have constrained how long a connection can remain open without getting into trouble. In the past the effectiveness of persistent connections were limited by the locality of url references, memory constraints on the endhosts, and IP address/port number space and translation table size on the middleboxes. (We have observed from Chrome browers more than one third of HTTP requests were made on new TCP connections.) With mobile network, aggressive power saving algorithms are putting more constraint on the length of TCP connections in order to avoid any unnecessary traffic (http ping, keepalive...) to wake up radio links... Jerry > > Joe > > > On 10/26/2011 11:23 AM, Jerry Chu wrote: > >> Hi Joe, >> >> On Wed, Oct 26, 2011 at 10:34 AM, Joe Touch wrote: >> >>> >>> >>> On 10/26/2011 10:24 AM, Jerry Chu wrote: >>> ... >>> >>>> >>>> Indeed. But people will quickly realize there is little or no benefit >>>> from TFO. >>>> >>> >>> That's my concern. Both to play nice with NATs and as a simpler mechanism >>> in >>> general, it's easier to use persistent connections AFAICT. >>> >> >> Obviously my statement above (TFO provides little or no benefit) was meant >> for >> long-lived connections. >> >> It turns out persistent connections are not any easier for NAT than >> TFO is (with SYN >> pkts carrying data). Persistent connections can tie up large amount of >> resources, >> both on the end hosts and on the middleboxes. Our Chrome engrs for Android >> discovered a serious problem recently with long-lived HTTP connections >> when >> middleboxes, under pressure for free mapping space, either silently >> dropped, or >> sent RST to handsets already in power-saving mode when removing existing >> translation from persistent connections. The end result is HTTP >> connections >> from mobile devices may hang for a long time until TCP abort timeout (many >> middleboxes do not generate RST when receiving pkts that do not have any >> mapping entries for some reason). >> >> This problem was serious (browser hung) enough that our Chrome engrs are >> pondering about disabling P-HTTP. More on why persistent connections are >> not >> panacea can be found in our upcoming -01 draft revision. >> >> I have said this before for our IW10 proposal as well - if persistent >> connections >> had been a viable solution to our latency problem we would not have wasted >> our >> time looking for alternative solutions. >> >> Jerry >> >> >>> Joe >>> >>> --000e0cd6aeac152e2504b03a8999 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Wed, Oct 26, 2011 at 12:32 PM, Joe Touc= h <touch@isi.edu&= gt; wrote:
Hi, Jerry,

A lot of what you describe below sounds like clutching onto a single persis= tent connection too long.

Correct excep= t what is considered "too long" is getting shorter and shorter.
=A0

I wonder if a 90% solution would have resulted in the bulk of the benefit a= nd avoided these issues.

Many practical con= siderations over the year have constrained how long a connection can remain= open without getting into trouble. In the past the effectiveness of persis= tent connections were limited by the locality of url references, memory con= straints on the endhosts, and IP address/port number space and translation = table size on the middleboxes. (We have observed from Chrome browers more t= han one third of HTTP requests were made on new TCP connections.)

With mobile network, aggressive power saving algorithms= are putting more constraint on the length of TCP connections in order to a= void any unnecessary traffic (http ping, keepalive...) to wake up radio lin= ks...

Jerry



Joe


On 10/26/2011 11:23 AM, Jerry Chu wrote:
Hi Joe,

On Wed, Oct 26, 2011 at 10:34 AM, Joe Touch<touch@isi.edu> =A0wrote:


On 10/26/2011 10:24 AM, Jerry Chu wrote:
...

Indeed. But people will quickly realize there is little or no benefit
from TFO.

That's my concern. Both to play nice with NATs and as a simpler mechani= sm in
general, it's easier to use persistent connections AFAICT.

Obviously my statement above (TFO provides little or no benefit) was meant = for
long-lived connections.

It turns out persistent connections are not any easier for NAT than
TFO is (with SYN
pkts carrying data). Persistent connections can tie up large amount of
resources,
both on the end hosts and on the middleboxes. Our Chrome engrs for Android<= br> discovered a serious problem recently with long-lived HTTP connections when=
middleboxes, under pressure for free mapping space, either silently dropped= , or
sent RST to handsets already in power-saving mode when removing existing translation from persistent connections. The end result is HTTP connections=
from mobile devices may hang for a long time until TCP abort timeout (many<= br> middleboxes do not generate RST when receiving pkts that do not have any mapping entries for some reason).

This problem was serious (browser hung) enough that our Chrome engrs are pondering about disabling P-HTTP. More on why persistent connections are no= t
panacea can be found in our upcoming -01 draft revision.

I have said this before for our IW10 proposal as well - if persistent
connections
had been a viable solution to our latency problem we would not have wasted = our
time looking for alternative solutions.

Jerry


Joe


--000e0cd6aeac152e2504b03a8999-- From hkchu@google.com Wed Oct 26 14:49:26 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 2A79721F8B6E for ; Wed, 26 Oct 2011 14:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft+3y-cBI2L4 for ; Wed, 26 Oct 2011 14:49:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7162C21F8B6D for ; Wed, 26 Oct 2011 14:49:25 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p9QLnKph000890 for ; Wed, 26 Oct 2011 14:49:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319665760; bh=E2zZbp+C8cc6CiYyfjqATN6AuDE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=pF7ao60psmaHPwTAGEm6vrKbyp3pJWlmQlpUMguj7QCJShWO/+dWUMurD+8LiOOeZ bethHMm0VkPu0TtRy0Qww== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=DoZd9NDaYXng5J8mp3pt6qTzlayTS0ZxdaRKFNG98hV2I5n4DMPsCrpu5SVTE16Je AMcVnGJIFkZqIyd+7hEVw== Received: from vws18 (vws18.prod.google.com [10.241.21.146]) by wpaz21.hot.corp.google.com with ESMTP id p9QLmbf0024224 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 26 Oct 2011 14:49:19 -0700 Received: by vws18 with SMTP id 18so3022724vws.1 for ; Wed, 26 Oct 2011 14:49:19 -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=UstLnTCww/+in5KOm5lPnYqJIc+4mC+7a7Rar2FgysI=; b=T0b4BJqt0TxmNLaeW2vm7ILpsSz0meY9CcLAq1ov6Gr6vEkib5Mufg7kHcK1vHCrYR WmFY/6RhyAs1EL0RtrWw== Received: by 10.151.9.13 with SMTP id m13mr3098884ybi.47.1319665759585; Wed, 26 Oct 2011 14:49:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.9.13 with SMTP id m13mr3098874ybi.47.1319665759402; Wed, 26 Oct 2011 14:49:19 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Wed, 26 Oct 2011 14:49:19 -0700 (PDT) In-Reply-To: <20111026212705.GA3478@nuttenaction> References: <20111026212705.GA3478@nuttenaction> Date: Wed, 26 Oct 2011 14:49:19 -0700 Message-ID: From: Jerry Chu To: Hagen Paul Pfeifer Content-Type: multipart/alternative; boundary=000e0cd483f0cfbc4404b03aa0db X-System-Of-Record: true Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 21:49:26 -0000 --000e0cd483f0cfbc4404b03aa0db Content-Type: text/plain; charset=ISO-8859-1 Hi Hagen, On Wed, Oct 26, 2011 at 2:27 PM, Hagen Paul Pfeifer wrote: > * Neal Cardwell | 2011-10-26 16:45:22 [-0400]: > > >I doubt TFO will displace P-HTTP where P-HTTP is already used widely. An > >already-open connection will almost always outperform a TFO connection, > due > >to cwnd, RTT, RTO, etc. being "warmed-up" in the already-open case. > > For Linux the connection is often "warmed-up" because of the metric cache > (TCP > congestion window, RTT estimates). Furthermore, IW10 will relax this one > more > time and IW10 may adequate for a lot of HTTP transfers. Not sure if an open > connection will outperform a new established connection nowadays (except > the > 3WHS, of course - which is addresses by TFO ;). > > > One question Yuchung, Jerry: are there any limitation not to exchange data > bidirectional in the SYN AND SYN-ACK packet? To cite the abstract: "allows > data to be carried in the SYN or SYN-ACK packets and consumed" > > ^^ > I see no real limitation that the "or" cannot be replaced by "and"? Did I > miss > something? ;) > Yes it should be "and" not "or". Thanks for the correction. Jerry > > Hagen > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000e0cd483f0cfbc4404b03aa0db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hagen,

On Wed, Oct 26, 2011 at 2:27 PM, Hagen P= aul Pfeifer <hagen@j= auu.net> wrote:
* Neal Cardwell | 2011-10-26 16:45:22 [-0400]:

>I doubt TFO will displace P-HTTP where P-HTTP is already used widely. A= n
>already-open connection will almost always outperform a TFO connection,= due
>to cwnd, RTT, RTO, etc. being "warmed-up" in the already-open= case.

For Linux the connection is often "warmed-up" because of th= e metric cache (TCP
congestion window, RTT estimates). Furthermore, IW10 will relax this one mo= re
time and IW10 may adequate for a lot of HTTP transfers. Not sure if an open=
connection will outperform a new established connection nowadays (except th= e
3WHS, of course - which is addresses by TFO ;).


One question Yuchung, Jerry: are there any limitation not to exchange data<= br> bidirectional in the SYN AND SYN-ACK packet? To cite the abstract: "al= lows
data to be carried in the SYN or SYN-ACK packets and consumed"

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^
I see no real limitation that the "or" cannot be replaced by &quo= t;and"? Did I miss
something? ;)

Yes it should be "an= d" not "or".

Thanks for the correct= ion.

Jerry



Hagen
_____________________= __________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--000e0cd483f0cfbc4404b03aa0db-- From hkchu@google.com Wed Oct 26 15:00: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 CDB6B21F8A6C for ; Wed, 26 Oct 2011 15:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCsSA+RNH4qJ for ; Wed, 26 Oct 2011 15:00:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 16C9821F8A58 for ; Wed, 26 Oct 2011 15:00:31 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p9QM0SFN031709 for ; Wed, 26 Oct 2011 15:00:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319666429; bh=emLFIavansFNQ+XabCLm+/Z6pMU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=rUCTugBnO93RUDMlnRNJ9ONJyfJkZGSrO5/cVtOBykYSj/ejVPpToeNbmLjesEmnG 5WqFeb0c+hhlxSl6AwQGQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=I6JMXgfDADfZZ23OkDS+3DNnTA+5O/iy9YRSmmyUzFpbcm0AnXG6k5+7SJcrJaYgl Ex3YOoP/XV08UnjHrd/oA== Received: from ggnp4 (ggnp4.prod.google.com [10.218.98.68]) by hpaq5.eem.corp.google.com with ESMTP id p9QLxQYD009354 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 26 Oct 2011 15:00:27 -0700 Received: by ggnp4 with SMTP id p4so3171612ggn.6 for ; Wed, 26 Oct 2011 15:00:27 -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=JglvxFUX15IaDbS/bx/bxkRSRgLgyzs9LH0DwPlFyuc=; b=AAKD4OY9kkUtqSY2mR0hqbSayPviGgINiSnVreMbD7/ILdSD48KXKt5F5CZ4Ktm37J 6Sl3MuajEJE6zrNJ8eOg== Received: by 10.150.253.14 with SMTP id a14mr27178359ybi.32.1319666427669; Wed, 26 Oct 2011 15:00:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.253.14 with SMTP id a14mr27178351ybi.32.1319666427541; Wed, 26 Oct 2011 15:00:27 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Wed, 26 Oct 2011 15:00:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Oct 2011 15:00:27 -0700 Message-ID: From: Jerry Chu To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=000e0cd306b6a2ba9504b03ac8fc X-System-Of-Record: true Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 22:00:33 -0000 --000e0cd306b6a2ba9504b03ac8fc Content-Type: text/plain; charset=ISO-8859-1 Hi Yoshifumi, On Wed, Oct 26, 2011 at 1:24 PM, Yoshifumi Nishida wrote: > Hi Jerry, > > 2011/10/26 Jerry Chu : > > Hi Yoshifumi, Rick, > > On Wed, Oct 26, 2011 at 7:15 AM, rick jones wrote: > >> > >> On Oct 26, 2011, at 2:54 AM, Yoshifumi Nishida wrote: > >> > > >> > I agree that TFO can promote the use of short-lived connections. > >> > > >> > My concern here is there might be no guarantee that TFO is used only > for > >> > short-lived connection. (also, we have no clear definition for > >> > short-lived connection) > > > > Indeed. But people will quickly realize there is little or no benefit > from > > TFO. > > > >> > >> > I'm thinking that some TFO connections can be long and it might > increase > >> > concurrent connections. > > > > Still I don't see a strong correlation between TFO and increasing > concurrent > > connections... > > Probably, I should have asked how P-HTTP and TFO co-exist. > A past paper "The Case for Persistent-Connection HTTP" by J. Mogul considered Transaction TCP, which enables data-in-SYN like TFO, a competing proposal. The main hurdle for T/TCP then and TFO now is deployment since both require non-trivial amount of stack changes. Personally I see P-HTTP and HTTP/TFO are complementary solutions. Jerry If TFO pushes out P-HTTP, I'm guessing that it promotes concurrent > connections > as a consequence. I guess I should take a look at 01 version. > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > --000e0cd306b6a2ba9504b03ac8fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yoshifumi,

On Wed, Oct 26, 2011 at 1:2= 4 PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hi Jerry,

2011/10/26 Jerry Chu <hkchu@google.c= om>:
> Hi Yoshifumi, Rick,
> On Wed, Oct 26, 2011 at 7:15 AM, rick jones <perfgeek@mac.com> wrote:
>>
>> On Oct 26, 2011, at 2:54 AM, Yoshifumi Nishida wrote:
>> >
>> > I agree that TFO can promote the use of short-lived connectio= ns.
>> >
>> > My concern here is there might be no guarantee that TFO is us= ed only for
>> > short-lived connection. (also, we have no clear definition fo= r
>> > short-lived connection)
>
> Indeed. But people will quickly realize there is little or no benefit = from
> TFO.
>
>>
>> > I'm thinking that some TFO connections can be long and it= might increase
>> > concurrent connections.
>
> Still I don't see a strong correlation between TFO and increasing = concurrent
> connections...

Probably, I should have asked how P-HTTP and TFO co-exist.

A past paper "The Case for Persistent-Connec= tion HTTP" by J. Mogul considered
Transaction TCP, which ena= bles data-in-SYN like TFO, a competing proposal.
The main hurdle for T/TCP then and TFO now is deployment since both re= quire
non-trivial amount of stack changes. Personally I see P-HTT= P and HTTP/TFO
are complementary solutions.

Jerry

If TFO pushes out P-HTTP, I'm guessing that it promotes concurrent conn= ections
as a consequence. I guess I should take a look at 01 version.=A0

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

--000e0cd306b6a2ba9504b03ac8fc-- From touch@isi.edu Thu Oct 27 07:37:53 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 2776821F8541 for ; Thu, 27 Oct 2011 07:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.832 X-Spam-Level: X-Spam-Status: No, score=-103.832 tagged_above=-999 required=5 tests=[AWL=-1.233, 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 T9GIIka7mel4 for ; Thu, 27 Oct 2011 07:37:52 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id ABF9A21F8538 for ; Thu, 27 Oct 2011 07:37:52 -0700 (PDT) Received: from [192.168.1.90] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p9REbMmf000372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Oct 2011 07:37:26 -0700 (PDT) Message-ID: <4EA96CA2.40202@isi.edu> Date: Thu, 27 Oct 2011 07:37:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jerry Chu References: <4EA84493.2030003@isi.edu> <4EA86031.50307@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" Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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: Thu, 27 Oct 2011 14:37:53 -0000 Hi, Jerry, On 10/26/2011 2:42 PM, Jerry Chu wrote: > Hi Joe, > > On Wed, Oct 26, 2011 at 12:32 PM, Joe Touch > wrote: > > Hi, Jerry, > > A lot of what you describe below sounds like clutching onto a single > persistent connection too long. > > Correct except what is considered "too long" is getting shorter and shorter. Some of the same problems with keeping a single connection open too long are shared by fastopen and persistent connection approaches, e.g., at the endpoints. > I wonder if a 90% solution would have resulted in the bulk of the > benefit and avoided these issues. > > Many practical considerations over the year have constrained how long a > connection can remain open without getting into trouble. In the past the > effectiveness of persistent connections were limited by the locality of > url references, memory constraints on the endhosts, and IP address/port > number space and translation table size on the middleboxes. (We have > observed from Chrome browers more than one third of HTTP requests were > made on new TCP connections.) Those same locality issues also limit the utility of fastopen approaches. > With mobile network, aggressive power saving algorithms are putting more > constraint on the length of TCP connections in order to avoid any > unnecessary traffic (http ping, keepalive...) to wake up radio links... That sounds again like "too long". We do need to see how this plays out on real traffic in an experiment. There's a tradeoff between persistent connections and fastopen that needs to be explored better - esp. since persistency is free (already supported) and fastopen requires TCP mods. E.g., if we're talking about a TCP mod to help the first of 10 connections in every 'burst', it's not worth the effort/complexity IMO. The jury is still out until we see more substantial data, IMO. Joe From touch@isi.edu Wed Oct 26 10:35: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 ACE2711E809C for ; Wed, 26 Oct 2011 10:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.168 X-Spam-Level: X-Spam-Status: No, score=-105.168 tagged_above=-999 required=5 tests=[AWL=1.431, 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 wEQJajJ-IzyS for ; Wed, 26 Oct 2011 10:35:21 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4628B11E8099 for ; Wed, 26 Oct 2011 10:35:21 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p9QHYBg6007637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Oct 2011 10:34:14 -0700 (PDT) Message-ID: <4EA84493.2030003@isi.edu> Date: Wed, 26 Oct 2011 10:34:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jerry Chu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Thu, 27 Oct 2011 08:19:16 -0700 Cc: " " "@isi.edu Subject: Re: [tcpm] comments for draft-cheng-tcpm-fastopen-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, 26 Oct 2011 17:35:21 -0000 On 10/26/2011 10:24 AM, Jerry Chu wrote: ... > Indeed. But people will quickly realize there is little or no benefit > from TFO. That's my concern. Both to play nice with NATs and as a simpler mechanism in general, it's easier to use persistent connections AFAICT. Joe From hkchu@google.com Thu Oct 27 15:39:46 2011 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4F821F84D9 for ; Thu, 27 Oct 2011 15:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5e2OoSlcnPu for ; Thu, 27 Oct 2011 15:39:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 36FCD21F84AB for ; Thu, 27 Oct 2011 15:39:42 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p9RMdbul011142 for ; Thu, 27 Oct 2011 15:39:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319755178; bh=cUJnxjf0bqZPiQb+8gTI7r7U15g=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=noHdeDMFBfZvqEkhHbIgz6tIFSJCkQn99WU92/ApXyNIo4qVrnd/Ffs6xE376NxUS Qq+ARFlnnlhFpmoMjwBOg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=PtBL5v5LZ/QhCZZSvxQLAfSK64Zbenx1HsocurrmZJWy+s727bf9wZHjWdDwr2yq+ gHiq7+oDhM5JGEdLdxetQ== Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by hpaq13.eem.corp.google.com with ESMTP id p9RMaE14027797 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 27 Oct 2011 15:39:36 -0700 Received: by qyk30 with SMTP id 30so4720212qyk.1 for ; Thu, 27 Oct 2011 15:39:35 -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=kSpiyh9dhaGsQIZI62dtoT2pZayF7taOTc6phWGIkN8=; b=aSmHb3rmjFOVoHp+bCKXJVSxSi0q18JFc45yFm+vae1TuA0RV+hoTt8TCwy8HTT37I PoZM7R+oH1G4TmOXgwiA== Received: by 10.150.188.9 with SMTP id l9mr317954ybf.92.1319755175957; Thu, 27 Oct 2011 15:39:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.188.9 with SMTP id l9mr317938ybf.92.1319755175749; Thu, 27 Oct 2011 15:39:35 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Thu, 27 Oct 2011 15:39:35 -0700 (PDT) In-Reply-To: <4EA96CA2.40202@isi.edu> References: <4EA84493.2030003@isi.edu> <4EA86031.50307@isi.edu> <4EA96CA2.40202@isi.edu> Date: Thu, 27 Oct 2011 15:39:35 -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-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: Thu, 27 Oct 2011 22:39:46 -0000 Hi Joe, On Thu, Oct 27, 2011 at 7:37 AM, Joe Touch wrote: > Hi, Jerry, > > On 10/26/2011 2:42 PM, Jerry Chu wrote: >> >> Hi Joe, >> >> On Wed, Oct 26, 2011 at 12:32 PM, Joe Touch > > wrote: >> >> =A0 =A0Hi, Jerry, >> >> =A0 =A0A lot of what you describe below sounds like clutching onto a sin= gle >> =A0 =A0persistent connection too long. >> >> Correct except what is considered "too long" is getting shorter and >> shorter. > > Some of the same problems with keeping a single connection open too long = are > shared by fastopen and persistent connection approaches, e.g., at the > endpoints. > >> =A0 =A0I wonder if a 90% solution would have resulted in the bulk of the >> =A0 =A0benefit and avoided these issues. >> >> Many practical considerations over the year have constrained how long a >> connection can remain open without getting into trouble. In the past the >> effectiveness of persistent connections were limited by the locality of >> url references, memory constraints on the endhosts, and IP address/port >> number space and translation table size on the middleboxes. (We have >> observed from Chrome browers more than one third of HTTP requests were >> made on new TCP connections.) > > Those same locality issues also limit the utility of fastopen approaches. Correct if TFO cookie is mandatory - it will require one regular 3WHS to ac= quire a valid cookie per local/remote IP addr pair before data is allowed to be consumed during 3WHS. We have been exploring the possibility of making the TFO cookie optional, only required by those servers where a amplified reflection attack is possi= ble (see my slides at the last IETF but we haven't added anything in the -01 draft as we need more time to firm up the idea). If we succeed, TFO will be truly competitive against other RR protocol running on top of UDP. > >> With mobile network, aggressive power saving algorithms are putting more >> constraint on the length of TCP connections in order to avoid any >> unnecessary traffic (http ping, keepalive...) to wake up radio links... > > That sounds again like "too long". Here what is considered "too long" has come down to just a few seconds and a handful of HTTP transactions, not very "persistent" IMO. > > We do need to see how this plays out on real traffic in an experiment. > There's a tradeoff between persistent connections and fastopen that needs= to > be explored better - esp. since persistency is free (already supported) a= nd > fastopen requires TCP mods. E.g., if we're talking about a TCP mod to hel= p > the first of 10 connections in every 'burst', it's not worth the > effort/complexity IMO. First I think it's better to have the technology ready so applications can = have a choice, rather than us debating here forever based on our own, possibly b= iased opinions and incomplete/erroneous data. BTW, from our own data Google has decided TFO is a worthy technology to pursue. (That's why we are here.) Second, 15 years ago when T/TCP was considered a serious contender in addition to P-HTTP as a solution to the unnecessary delay of HTTP caused by TCP's 3WHS, deployment problem was cited as #1 hurdle to the viability of T/TCP. Had we taken some action then, we've had long gone over the deployment hurdle in the past 15 years. Granted T/TCP has some fatal design flaw, focusing itself too much on the intractable duplication SYN problem hence adding too much complexity. I believe we've taken the right approach, to treat the data-in-SYN as an engineering problem hence proposing an imperfect solution balancing the right tradoffs, rather than to treat it as a math or science problem and tr= y to find a perfect but incomprehensible solution. Jerry > > The jury is still out until we see more substantial data, IMO. > > Joe > From ycheng@google.com Sat Oct 29 13:15: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 BC51D21F84CB for ; Sat, 29 Oct 2011 13:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.143 X-Spam-Level: X-Spam-Status: No, score=-105.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 OR5RWnj0FWjf for ; Sat, 29 Oct 2011 13:15:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D558121F84BD for ; Sat, 29 Oct 2011 13:15:24 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p9TKFNbr004628 for ; Sat, 29 Oct 2011 13:15:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319919323; bh=xeaHgmuhGHYhUca2CDTim5RS9bY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=uoGmOaDlXdH47a4UxZfpf6Rqg6zvdH9J8+0nnjr84gLYDfoYM4RSlYPvpQaViE+xg kCGnp840j1hRbyh4+2+Kg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=h5PmfldgfA/EZV5aEvXKZ61Vsbq1T+9LNmz1sb+4VIKx7WvWDf+ijQW/84/M0rQEA Vr+/rvqhNro7QkeWcL7Dg== Received: from qabj40 (qabj40.prod.google.com [10.224.21.168]) by wpaz1.hot.corp.google.com with ESMTP id p9TKFMQ1015274 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 29 Oct 2011 13:15:22 -0700 Received: by qabj40 with SMTP id j40so10786493qab.6 for ; Sat, 29 Oct 2011 13:15:22 -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=FhVtyoVqYkeTiQw3tmfPQ/AsrA8MqABqQ+F224P3T3Q=; b=ng2CWEtRkoJjBp2rGh+IS7zaC7v8nwrI2a1MKWuUvh1njYq4IuJofsPNjx8xoRGjq1 ZMsQ8iqSPjVTgLheAYAw== Received: by 10.224.17.136 with SMTP id s8mr7210034qaa.75.1319919322188; Sat, 29 Oct 2011 13:15:22 -0700 (PDT) Received: by 10.224.17.136 with SMTP id s8mr7210026qaa.75.1319919322069; Sat, 29 Oct 2011 13:15:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.180.16 with HTTP; Sat, 29 Oct 2011 13:15:01 -0700 (PDT) In-Reply-To: <4EA5DF5F.8090407@isi.edu> References: <20111024215310.10139.23464.idtracker@ietfa.amsl.com> <4EA5DF5F.8090407@isi.edu> From: Yuchung Cheng Date: Sat, 29 Oct 2011 13:15:01 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=bcaec517add052f8c504b075aae6 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: Sat, 29 Oct 2011 20:15:25 -0000 --bcaec517add052f8c504b075aae6 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, Kinda obvious but I assume the option "length" field now includes the nonce? Yuchung 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. > > 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 > --bcaec517add052f8c504b075aae6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joe,

Kinda obvious but I assume the option "leng= th" field now includes the nonce?=A0

Yuchung<= br>
On Mon, Oct 24, 2011 at 2:57 PM, Joe Touc= h <touch@isi.edu&= gt; 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.

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

--bcaec517add052f8c504b075aae6-- From per.hurtig@gmail.com Sun Oct 30 09:30: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 8D3FB21F850B for ; Sun, 30 Oct 2011 09:30:12 -0700 (PDT) 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 8WU-jk3bVcNc for ; Sun, 30 Oct 2011 09:30:12 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 124AC21F84A5 for ; Sun, 30 Oct 2011 09:30:12 -0700 (PDT) Received: by iabn5 with SMTP id n5so7892961iab.31 for ; Sun, 30 Oct 2011 09:30:11 -0700 (PDT) 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=4DdOYa9IA/n3D/ZBSapRkgNyA76rfJBnsCJfnPw64tg=; b=nuzg9HzXpYovRfiRjsvU/RjCRGk9uoBLYtdGt5VdxJ0e+uCHkOe4NiiAolcKbTvzTk Z80TOcedJeAMxo0fndaq6nlzuvT/NmpPQo4VUDRYqnm2CvAnvHm9M8YjrbSfqiKMJikj mnh+BtvLhWykHf+mXE1ymnK4O2RnheZWWELA0= MIME-Version: 1.0 Received: by 10.231.28.30 with SMTP id k30mr3987839ibc.25.1319992211658; Sun, 30 Oct 2011 09:30:11 -0700 (PDT) Sender: per.hurtig@gmail.com Received: by 10.231.15.201 with HTTP; Sun, 30 Oct 2011 09:30:11 -0700 (PDT) In-Reply-To: <20111029192848.4798.45100.idtracker@ietfa.amsl.com> References: <20111029192848.4798.45100.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2011 17:30:11 +0100 X-Google-Sender-Auth: 46AGfHtpN1-_HkDU4wtxp7awg8E Message-ID: From: "Per Hurtig (work)" To: tcpm Content-Type: text/plain; charset=ISO-8859-1 Subject: [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: Sun, 30 Oct 2011 16:30:12 -0000 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: 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 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 modification 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. The IETF Secretariat From touch@isi.edu Sun Oct 30 23:41: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 4034011E80BE for ; Sun, 30 Oct 2011 23:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.524 X-Spam-Level: X-Spam-Status: No, score=-105.524 tagged_above=-999 required=5 tests=[AWL=1.075, 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 IohvZqMEvKjM for ; Sun, 30 Oct 2011 23:41:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4E60311E80B7 for ; Sun, 30 Oct 2011 23:41:26 -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 p9V6eWiR000234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 30 Oct 2011 23:40:42 -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: Sun, 30 Oct 2011 23:40:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3373C6BB-B90B-42E5-9E6A-A37FC61B0284@isi.edu> References: <20111024215310.10139.23464.idtracker@ietfa.amsl.com> <4EA5DF5F.8090407@isi.edu> To: Yuchung Cheng 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] 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, 31 Oct 2011 06:41:27 -0000 Hi, Yuchung, Yes, the length field includes the size of the entire option, including = the KIND, LENGTH, and NONCE fields. This will be made clear in the next = version. Joe On Oct 29, 2011, at 1:15 PM, Yuchung Cheng wrote: > Hi Joe, >=20 > Kinda obvious but I assume the option "length" field now includes the = nonce?=20 >=20 > Yuchung >=20 > On Mon, Oct 24, 2011 at 2:57 PM, Joe Touch wrote: > Hi, all, >=20 > The following document describes an informal proposal I made on the = list a while back. Hopefully we can discuss it in Taiwan. >=20 > Joe >=20 > -------- 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 >=20 > 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. >=20 > 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 >=20 > 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. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From hkchu@google.com Mon Oct 31 01:25: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 C49DF21F85DB for ; Mon, 31 Oct 2011 01:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IIjQ4hxE0a8 for ; Mon, 31 Oct 2011 01:25:00 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1656721F84B2 for ; Mon, 31 Oct 2011 01:24:59 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p9V8Osbq022415 for ; Mon, 31 Oct 2011 01:24:56 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1320049497; bh=z+x5VjGjHp9Du450b+Q+kyUDLRU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type:Content-Transfer-Encoding; b=wHhz2ArYzoMHamJiCfr4vD6HoKA7Vf1w91pIMPd0n8wW+maP3FIWtCd58P0dmlZep zuBui9oZZ04ThOHy8Vd1w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:content-type: content-transfer-encoding:x-system-of-record; b=U2OHsaaVgqmaeBAJKT0o+E5caAqQIfZwJJQuCDo9AjsBsO8+ey//w9C1MUI/YEAFw w6yHLWzsr6dSjYlT6mlAw== Received: from vws14 (vws14.prod.google.com [10.241.21.142]) by wpaz37.hot.corp.google.com with ESMTP id p9V8MXDs024330 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 31 Oct 2011 01:24:53 -0700 Received: by vws14 with SMTP id 14so586557vws.3 for ; Mon, 31 Oct 2011 01:24:53 -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 :content-type:content-transfer-encoding:x-system-of-record; bh=D4P4gT3AsdqkUzkYWL6ARU1nxMBpAgtP0hgqUx0iA8I=; b=TMWQtB6qo5ek6AQx0+Y4QV5EXp3R3ktSZy0izmCSDKQ5CsVdHAmgKpooRicvJmSOHF U13RwJonZXvFFieK6Qaw== Received: by 10.150.165.19 with SMTP id n19mr9402444ybe.107.1320049493594; Mon, 31 Oct 2011 01:24:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.165.19 with SMTP id n19mr9402436ybe.107.1320049493426; Mon, 31 Oct 2011 01:24:53 -0700 (PDT) Received: by 10.150.186.1 with HTTP; Mon, 31 Oct 2011 01:24:53 -0700 (PDT) In-Reply-To: <20111031080017.25112.38505.idtracker@ietfa.amsl.com> References: <20111031080017.25112.38505.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 01:24:53 -0700 Message-ID: From: Jerry Chu To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Subject: [tcpm] Fwd: New Version Notification 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, 31 Oct 2011 08:25:00 -0000 This revision incorporates comments from Rick Jones and others,=A0some fine tuning on the Fast Open protocol and cookie processing, a discussion on the limitation of persistent HTTP, and why TFO is an attractive alternative= . It concludes with some performance numbers showing TFO improves page load time by 10% to 40%. Note that more details about TCP Fast Open will be available in an upcoming paper to be published at the 7th ACM CoNEXT Conference, December 2011. Jerry ---------- Forwarded message ---------- From: Date: Mon, Oct 31, 2011 at 1:00 AM Subject: New Version Notification for draft-cheng-tcpm-fastopen-01.txt To: hkchu@google.com Cc: hkchu@google.com, ycheng@google.com, sivasankar@cs.ucsd.edu, arvind@google.com A new version of I-D, draft-cheng-tcpm-fastopen-01.txt has been successfully submitted by Jerry Chu and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-cheng-tcpm-fastopen Revision: =A0 =A0 =A0 =A001 Title: =A0 =A0 =A0 =A0 =A0 TCP Fast Open Creation date: =A0 2011-10-31 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 21 Abstract: =A0 TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK =A0 packets and consumed by the receiving end during the initial =A0 connection handshake, thus providing a saving of up to one full round =A0 trip time (RTT) compared to standard TCP requiring a three-way =A0 handshake (3WHS) to complete before data can be exchanged. Terminology The IETF Secretariat From rs@netapp.com Mon Oct 31 03:42:31 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 11A2021F8D97 for ; Mon, 31 Oct 2011 03:42:31 -0700 (PDT) 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, 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 xdh26-R1zsvf for ; Mon, 31 Oct 2011 03:42:30 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfa.amsl.com (Postfix) with ESMTP id 58BB821F8D60 for ; Mon, 31 Oct 2011 03:42:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,431,1315206000"; d="scan'208";a="271219134" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 31 Oct 2011 03:42:29 -0700 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p9VAgSWd013475 for ; Mon, 31 Oct 2011 03:42:29 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Oct 2011 11:42:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 31 Oct 2011 10:40:23 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A10D92BE7@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification fordraft-scheffenegger-tcpm-timestamp-negotiation-03.txt Thread-Index: AcyXuX43QdYH9cn3RxGDPZOFhUipqA== From: "Scheffenegger, Richard" To: X-OriginalArrivalTime: 31 Oct 2011 10:42:28.0999 (UTC) FILETIME=[C95D7170:01CC97B9] Subject: [tcpm] New Version Notification fordraft-scheffenegger-tcpm-timestamp-negotiation-03.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, 31 Oct 2011 10:42:31 -0000 DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc2NoZWZmZW5lZ2dlci10Y3BtLXRpbWVzdGFt cC1uZWdvdGlhdGlvbi0wMy50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBS aWNoYXJkIFNjaGVmZmVuZWdnZXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpGaWxlbmFtZToJIGRyYWZ0LXNjaGVmZmVuZWdnZXItdGNwbS10aW1lc3RhbXAtbmVnb3RpYXRp b24NClJldmlzaW9uOgkgMDMNClRpdGxlOgkJIEFkZGl0aW9uYWwgbmVnb3RpYXRpb24gaW4gdGhl IFRDUCBUaW1lc3RhbXAgT3B0aW9uIGZpZWxkIGR1cmluZyB0aGUgVENQIGhhbmRzaGFrZQ0KQ3Jl YXRpb24gZGF0ZToJIDIwMTEtMTAtMzENCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K TnVtYmVyIG9mIHBhZ2VzOiAzNQ0KDQpBYnN0cmFjdDoNCiAgIEEgbnVtYmVyIG9mIFRDUCBlbmhh bmNlbWVudHMgaW4gc28gZGl2ZXJzZSBmaWVsZHMgYXMgY29uZ2VzdGlvbg0KICAgY29udHJvbCwg bG9zcyByZWNvdmVyeSBvciBzaWRlLWJhbmQgc2lnbmFsaW5nIGNvdWxkIGJlIGltcHJvdmVkIGJ5 DQogICBhbGxvd2luZyBib3RoIGVuZHMgb2YgYSBUQ1Agc2Vzc2lvbiB0byBpbnRlcnByZXQgdGhl IHZhbHVlcyBjYXJyaWVkDQogICBpbiB0aGUgVGltZXN0YW1wIG9wdGlvbi4gIEZ1cnRoZXIgZW5o YW5jZW1lbnRzIGFyZSBlbmFibGVkIGJ5DQogICBjaGFuZ2luZyB0aGUgcmVjZWl2ZXIgc2lkZSBw cm9jZXNzaW5nIG9mIHRpbWVzdGFtcHMgaW4gdGhlIHByZXNlbmNlDQogICBvZiBTZWxlY3RpdmUg QWNrbm93bGVkZ2VtZW50cy4NCg0KICAgVGhpcyBkb2N1bWVudHMgdXBkYXRlcyBSRkMxMzIzIGFu ZCBzcGVjaWZpZXMgYSBiYWNrd2FyZHMgY29tcGF0aWJsZQ0KICAgd2F5IG9mIG5lZ290aWF0aW5n IGZvciBUaW1lc3RhbXAgY2FwYWJpbGl0aWVzLCBhbmQgbGlzdHMgYSBudW1iZXIgb2YNCiAgIGJl bmVmaXRzIGFuZCBkcmF3YmFja3Mgb2YgdGhpcyBhcHByb2FjaC4NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From rs@netapp.com Mon Oct 31 03:49:38 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 3292521F8A4B for ; Mon, 31 Oct 2011 03:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 RIOzBqDVN28d for ; Mon, 31 Oct 2011 03:49:37 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfa.amsl.com (Postfix) with ESMTP id 19D2621F888A for ; Mon, 31 Oct 2011 03:49:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,431,1315206000"; d="scan'208";a="271219568" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 31 Oct 2011 03:49:36 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p9VAnaHT014439 for ; Mon, 31 Oct 2011 03:49:36 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 10:49:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Oct 2011 10:47:30 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A10D92BEF@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notificationfordraft-scheffenegger-tcpm-timestamp-negotiation-03.txt Thread-Index: AcyXuX43QdYH9cn3RxGDPZOFhUipqAAADSSg From: "Scheffenegger, Richard" To: X-OriginalArrivalTime: 31 Oct 2011 10:49:36.0030 (UTC) FILETIME=[C7E533E0:01CC97BA] Subject: Re: [tcpm] New Version Notificationfordraft-scheffenegger-tcpm-timestamp-negotiation-03.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, 31 Oct 2011 10:49:38 -0000 We have submitted this updated version of the timestamp capability negotiation draft. The main difference to the previous draft is a more clear-cut differentiation between common and version-specific contents, and a change in the version 0 fields to simplify decoding and differentiation against an IEEE 754 float representations to prevent implementation bugs. Furthermore, we want to discuss the findings of an extensive investigation around the prevalence of && TSecr !=3D 0 at IETF82, and possible mitigation. These are not yet part of this draft. Best regards, Richard > -----Original Message----- > From: Scheffenegger, Richard > Sent: Montag, 31. Oktober 2011 11:40 > To: tcpm@ietf.org > Subject: [tcpm] New Version Notificationfordraft-scheffenegger-tcpm- > timestamp-negotiation-03.txt >=20 >=20 > A new version of I-D, draft-scheffenegger-tcpm-timestamp-negotiation- > 03.txt has been successfully submitted by Richard Scheffenegger and posted > to the IETF repository. >=20 > Filename: draft-scheffenegger-tcpm-timestamp-negotiation > Revision: 03 > Title: Additional negotiation in the TCP Timestamp Option field > during the TCP handshake > Creation date: 2011-10-31 > WG ID: Individual Submission > Number of pages: 35 >=20 > Abstract: > A number of TCP enhancements in so diverse fields as congestion > control, loss recovery or side-band signaling could be improved by > allowing both ends of a TCP session to interpret the values carried > in the Timestamp option. Further enhancements are enabled by > changing the receiver side processing of timestamps in the presence > of Selective Acknowledgements. >=20 > This documents updates RFC1323 and specifies a backwards compatible > way of negotiating for Timestamp capabilities, and lists a number of > benefits and drawbacks of this approach. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm