From wesley.m.eddy@nasa.gov Wed Nov 3 18:59:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6F13A6407 for ; Wed, 3 Nov 2010 18:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggs8L-tI9VCe for ; Wed, 3 Nov 2010 18:59:37 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 30D033A677D for ; Wed, 3 Nov 2010 18:59:37 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 3DB7F180978; Wed, 3 Nov 2010 20:59:45 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id oA41xjMv027871; Wed, 3 Nov 2010 20:59:45 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Wed, 3 Nov 2010 20:59:44 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "Anantha Ramaiah (ananth)" , "tcpm@ietf.org" Date: Wed, 3 Nov 2010 20:59:44 -0500 Thread-Topic: [tcpm] Readiness of "draft-ietf-tcpm-persist-00.txt" for last call. Thread-Index: ActzJT9QGtH7B9o5SQqL8a5TsmkFAwIm//3R Message-ID: References: <0C53DCFB700D144284A584F54711EC580AFDD963@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580AFDD963@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-11-03_07:2010-11-03, 2010-11-03, 1970-01-01 signatures=0 Subject: Re: [tcpm] Readiness of "draft-ietf-tcpm-persist-00.txt" for last call. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 01:59:38 -0000 Replying to this as an individual (not WG co-chair), my feeling about this = "Programming Considerations" section is that if it stays in, it at least ne= eds more introduction to explain that this socket API extension is only nee= ded in the case where you want to make the TCP implementation (i.e. in the = kernel) capable of taking this action on its own and allow it to reap socke= ts on behalf of the application. It should be clearly noted that other pro= tection can be implemented in the application as an alternative and that so= cket support described here is not mandatory. I wasn't quite comfortable with the way that section 5 ("Conclusion") point= s to this as the implementation guidelines, rather than a potential impleme= ntation. As WG co-chair, I hope more people can share their views on this, so we can= see consensus and wrap this draft up in the near term. Especially if peop= le plan to implement (or have already implemented) the API extension descri= bed here, it would be good to know (or if people explicitly don't plan to i= mplement it). ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Anantha Ra= maiah (ananth) [ananth@cisco.com] Sent: Saturday, October 23, 2010 10:43 PM To: tcpm@ietf.org Subject: [tcpm] Readiness of "draft-ietf-tcpm-persist-00.txt" for last call= . Hi, Following is the summary (from the authors perspective) as to where we stand w.r.t this draft. We believe, this short and harmless draft is ready for the last call. During the last review of the persist draft, some folks were not happy about the API section (section 7) of the document. The authors discussed this concern among themselves and also have received some other reviews (both internal and external) and are kind of confused as to why the presence of an API guideline (for illustration purpose mainly) should be of any concern. Following reasons as to why we think why some illustration (like API) would be nicer to have :- - This is an informational draft. The purpose of the API section is to illustrate what how an application can do something about connections which are stuck in persist state. The objective is NOT to recommend any sockets API syntax or format (again we are not standardizing anything), it is purely there to illustrate the essence of the draft. - There was some talk about SO_LINGER API etc.,. I think we have clarified earlier that SO_LINGER comes into play only when the application tries to close the socket. SO_LINGER with 0 value is like causing an abort of the TCP connection. Here we acknowledge that there is a way (possibly more ways) that exists which can be used to abort the TCP connection. This is orthogonal to the current API discussion which we are having which simply illustrates how an application can abort the TCP connection without violating any RFC (793 or 1122) In a nutshell, we don't see any reason why mentioning an API example is violation of the RFC. We believe adding an API example would not deter that simplicity in any way, but that is just our take. Maybe there is some scope to rewrite that section if folks think otherwise. We would like to move forward on getting closure on this aspect as this seems to be the last hurdle in getting this draft to the last call process. Sorry about the delay in getting back. Thanks, -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm= From hkchu@google.com Wed Nov 3 19:29:42 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614603A6807 for ; Wed, 3 Nov 2010 19:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frS42Nnd5U42 for ; Wed, 3 Nov 2010 19:29:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E4EF03A67D4 for ; Wed, 3 Nov 2010 19:29:38 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id oA42TlTV019420 for ; Wed, 3 Nov 2010 19:29:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288837787; bh=OKsJ8gfelJQWumlFMq7g5ngn104=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=boaHyP0kjpzKoHdfkV28wO86OsoU9df/SpxSwGPH0aN1wzEbUdAaBRYgbp5J7F/wk BctYO+3AS1NDnc1tiJzKA== Received: from yxp4 (yxp4.prod.google.com [10.190.4.196]) by wpaz29.hot.corp.google.com with ESMTP id oA42Tjh2010543 for ; Wed, 3 Nov 2010 19:29:46 -0700 Received: by yxp4 with SMTP id 4so1050439yxp.31 for ; Wed, 03 Nov 2010 19:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=F0hzdjNSXPCvMpdENgz0ctjKuD6BzynumWf6xm3jTwI=; b=AmpKHTNRNLBEPKZ4PxUceMW2ie1wP30gByqOJXOVWKl9Cq0MtnSOKjpYlM9+Mm6iiu /EljbDHmvr/5jxJ/7zcA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Yc9//Gs2jkjo3LbhtS9s/9PZZWNjYrkiWzD1fD7SSOXpjtqjgz1oeamGueK0lJtHLR NftARG1aNG+Uj/JDi9LA== MIME-Version: 1.0 Received: by 10.150.53.2 with SMTP id b2mr269479yba.348.1288837785473; Wed, 03 Nov 2010 19:29:45 -0700 (PDT) Received: by 10.150.145.4 with HTTP; Wed, 3 Nov 2010 19:29:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Nov 2010 19:29:44 -0700 Message-ID: From: Jerry Chu To: Fred Baker Content-Type: multipart/mixed; boundary=000e0cd31074605638049430ee35 X-System-Of-Record: true Cc: Lachlan Andrew , tcpm@ietf.org, ywang15@ncsu.edu, tmrg , Matt Mathis Subject: Re: [tcpm] [Tmrg] Proposal to increase TCP initial CWND X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2010 02:29:42 -0000 --000e0cd31074605638049430ee35 Content-Type: multipart/alternative; boundary=000e0cd31074605626049430ee33 --000e0cd31074605626049430ee33 Content-Type: text/plain; charset=ISO-8859-1 +tcpm@ietf.org, ywang15@ncsu.edu [resume an old but unfinished thread that was partly hampered by tmrg list problems] We've been working hard in the past couple of months to study a number of questions/concerns/issues people have brought up. We were glad to continue to have Yaogong Wang, a PhD student of Prof. Injong Rhee of NCSU to collaborate with us after his internship finished in the summer, to setup a 2nd testbed at Dr. Rhee's lab. The test result from his testbed is near complete and can be seen at http://research.csc.ncsu.edu/netsrv/?q=content/iw10 In the meantime we continue to run tests and compare results from both sides. Unfortunately tests on slow links have been especially time-consuming simply because they run very slow. It takes a long time to get quality data (and we still see large variations). But in light of the upcoming IETF meeting we will try to conclude and post some summarized remarks soon. I do want to answer a simple question you brought up a while back below, just how many RTTs might IW10 save compared to IW3? Your argument of max 3 RTTs below has neglected delayed acks, which will affect the formula. I'm including a graph showing majority of 3RTT savings, followed by 2RTT, then 1 and 4RTTs. (The same numbers can be found at section 5.2 of draft-ietf-tcpm-initcwnd-00.txt.) These numbers assume somewhat "pure" and long delayed ack timers. In reality implementations tweak the delayed ack logic in different ways. Linux has a "quick ack" mode at the beginning of a new connection. Windows stack has its own delayed-ack heuristics. So in real life I believe the number of RTT savings will be somewhat in between. (Ideally I'd like to do measurements against real stacks to count the numbers but I just don't have the time to do it right now.) Jerry On Mon, Jul 19, 2010 at 8:35 AM, Fred Baker wrote: > > On Jul 18, 2010, at 2:58 AM, Lachlan Andrew wrote: > > > Regarding whether it is a "single flow" or not, I'd argue that even if > > it is multiple TCP connections, they're all really part of the same > > "flow", since they're aiming to carry (different parts of) the same > > map. > > Arg. We return to definitions of a flow... > > I think the important thing here is the mathematics of it. If I look for an > image at images.google.com, for example, I will download an html file > followed by 20-or-so separate images. In tests I have run, those are often > separate TCP sessions, all of them going through slow-start and possible > later saw-toothing simultaneously. That basically means: > > client sends 20-or-so SYNs > ... > client receives 20-or-so SYN-ACKS > sends 20-or-so Acks > sends 20-or-so HTTP GET requests > ... > client access interface starts receiving IW*20-or-so datagrams comprising > those 20-or-so images. > > That behavior should be fairly apparent in the attached, which is a > graphical representation of exactly this between Firefox at my home and > images.google.com. I'll attach also a comment I made to Nandita last > April; it references a number of other files which I don't have any more but > could recreate if folks are interested. > > Comparing that to the behavior of a single SCTP session with 20 streams, or > the behavior of a single pipelined TCP session, I think the point should be > apparent that these are mathematically not very similar, and that the value > of IW is important. > > Now, one will argue that getting a zillion thumbnail images is not much of > an issue, as thumbnails are small. My concern is more essentially about > discarding congestion control. If the average file moved is on the order of > 15,000 bytes, IW=10, and typical message size is about 1500 bytes, my four > function calculator says that we have in the typical case discarded > congestion control entirely and instead are simply looking at the issues of > retransmission. The average file is put entirely in flight during the first > RTT. > > In my email with Nandita and company, I asked about the possibilities of > putting up a TCP Discard stream (representing competing traffic), letting it > get established, and observing the effect on it when a flash crowd like this > is imposed. I still think it would be an interesting test... > > > Begin forwarded message: > > > From: Fred Baker > > Date: April 1, 2010 3:33:43 PM PDT > > To: Nandita Dukkipati > > Cc: draft-hkchu-tcpm-initcwnd@tools.ietf.org, Jerry Chu < > hkchu@google.com>, Yuchung Cheng > > Subject: Re: cwnd=10 > > > > > > On Mar 31, 2010, at 6:50 PM, Nandita Dukkipati wrote: > > > >> Fred, Hi. > >> Some responses inline... > >> > >>> Where I get concerned, as I mentioned last week, is when the receiver > is outside the high bandwidth corridor that stretches from Australia and > eastern Asia across anglophone north America and through western Europe. I > have attached a map showing the corridor in very general terms, and making > an error (oversimplifying) with respect to Mexico and the Caribbean. > Geographically, this is a fairly narrow scope, as it leaves out the entire > continents of South America and Africa and most of Asia (and btw polynesia > and Antarctica). It does represent the more developed countries of the > world, however, and much of Google's markets. I'd be willing to bet that the > vast majority of your tests have been to places in that corridor. Outside > the corridor, I have some grave concerns. > >> > >> Great point! Knowing that this may in fact be the Achilles Heel in > standardization of cwnd=10, we deliberately chose the test data-centers that > also serve traffic to the above regions, including Africa and South America. > The data presented (link: paper) is sliced and diced by network properties > such as bandwidth (BW), RTT, and BDP. Assuming that the primary cause for > concern in developing countries is low BW connectivity, the paper > specifically lists the observations for low BW subnets including those with > <=56Kbps. That said, we can also break the performance down by specific > countries/continents, something that we are in the process of performing. We > are also actively pursuing tests with clients in Africa to further validate > our original numbers (that IW=10 doesn't hurt). > > > > In the paper and in the slides, what I observed you testing was the > impact to your sessions of changing the initial window. Did you do any > testing of the impact on other sessions? For example, on a 56 KBPS link with > its (Cisco low end default) 40 packet buffers, setting up half a dozen ten > packet bursts should show up in a loss rate to the sixth session. If there > was a competing session, say an FTP that had been happily moving a file for > several seconds and found itself dumped on with sixty 125 millisecond > packets (7.5 seconds worth of traffic), I could imagine the competing TCP > session being lost entirely or at least being badly hurt. Dod you try > setting up a TCP Discard session in parallel and testing the impact on other > users? > > > > You might be aware of issues between BitTorrent and Comcast, currently > under discussion in the FCC, around the impact of BitTorrent on other users. > It could extend to Google. > > > >>> There are two things I have suggested in the past and would note for > the record: > >>> > >>> 1) I think any give host would do well to maintain a certain amount of > history somewhere; if cwnd/rtt is an approximation of "a reasonable > connection's characteristics" available to a destination, then recording > that ratio and referring to it when starting a TCP session would go a long > way in the direction you are suggesting. If you share a LAN with a device, I > could imagine setting cwnd=rwin and let SACK and the fast retransmit > heuristic pick up the pieces. More generally, if you were to record the > ratio (as I believe Linux does) and initially set cwnd to some fraction of > it times the RTT measured on the syn/syn-ack exchange, I imagine you would > find cwnd low when it needs to be low and high when it is likely to work > out. The secret sauce, so to speak, is in the fraction - is that half? > >>> > >>> 2) A major problem that TCP/SCTP have in the initial burst is that it > is a burst. Ack-paced traffic tends to be spread out throughout the RTT, but > the first few bursts tend to pile up, which can result in a momentary > overload of switch/router/modem queues. Which makes me wonder: what would > happen if we presumed some basic rate (perhaps derived from the saved cwnd > and rtt or cwnd/rtt mentioned in [1]) and sent the initial burst > *at*that*rate*? Picking numbers out of the air that happen to be simple to > calculate with, if we found that someone typically had 1.2 MBPS to use and > that their mss was 1500 bytes (12000 bits), that would suggest that we might > try sending one segment every 10 ms until we got the first Ack and followed > our favorite congestion control algorithm after that. If someone has a long > RTT, that results in us having a lot of segments (in separate packet trains) > in flight pretty quickly, but if the RTT is short it starts with an initial > amount more appropriate to the RTT. > >> > >> We have tried the approach in [1] and the presentation slides to > ICCRG/TCPM cover the pros and cons of the approach. Overall, there is a > tradeoff between the cache size used and the hit rate; cache hit rate is low > because of load balancers before the front-ends. > > > > Looking through the presentation and paper... > > > > "IW=10 saves up to four round trips" seems like an interesting statement. > If IW=1, the second RTT carries 2, the third four, and the fourth 8. IW=10 > takes 1+2+4+3 segments in the first RTT and the other five from the fourth > RTT (plus however many more) in the second RTT. If IW=2, the sequence is 2, > 4, 8, and conversion to IW=10 means that the first 2+4+4 segments go in the > first RTT and the next six (plus whatever) in the second RTT. With CUBIC, It > could rise more quickly. I see a reduction of two or three RTTs; where is > there a reduction of four? > > > > More importantly, the statement on slide 5 is that this reduces the trend > of browsers opening up multiple TCP sessions. I'm not sure I see that. Take > a look if you would at > > ftp://ftpeng.cisco.com/fred/google/firefox-tcp.pdf > > ftp://ftpeng.cisco.com/fred/google/safari-tcp.pdf > > ftp://ftpeng.cisco.com/fred/google/google-images-firefox.zip > > ftp://ftpeng.cisco.com/fred/google/google-images-safari.zip > > ftp://ftpeng.cisco.com/fred/google/google-images.xlsx.zip > > > > The two pdfs are the graphics; the others are the supporting data. I > spoke for an hour with Mike Belshe at the IETF, and he called out Google > Images as an example of a web browser opening lots of sessions. OK, great > example, let's play. So, I opened Safari, looked up "April Fools Pictures" > on Google Images, cleared my cache, opened a tcpdump, hit "refresh", and > turned off the tcpdump. Then I repeated the experiment with firefox. What I > see is signature HTTP behavior: > > > > - the browser downloaded the main page > > - the browser opened some number of TCP sessions to "get" objects > > SYN, SYN-ACK, ACK, "GET" > > - the browser received each of the objects in question > > Data, Ack, Data, Data, Ack, ... > > > > You can see that very clearly in the pdfs. I have to ask. What would the > fact that Google has bumped IW=10 got to do with how many sessions the > browser opened? Google didn't even *try* to deliver the first of the > requested objects until the last of the sessions was open. > > > > Had it used SCTP, those would be streams in a session. I think I can > figure out (your slide 5) how one builds the congestion control for that. > > > > > > BTW, it looks like you have already increased the initial burst at > google. Picking up one of those sessions at random, and noting that my RTT > to Google is very long compared to my RTT to work (I have a split tunnel, so > that means that the google data center is really far away) > > > > --- bw-in-f104.1e100.net ping statistics --- > > 10 packets transmitted, 10 packets received, 0.0% packet loss > > round-trip min/avg/max/stddev = 186.227/198.954/209.654/8.509 ms > > > > --- irp-view13.cisco.com ping statistics --- > > 10 packets transmitted, 10 packets received, 0.0% packet loss > > round-trip min/avg/max/stddev = 19.579/25.110/36.951/5.107 ms > > > > I see four bursts of activity in this session: > > > > #1: SYN > > 09:53:38.102027 IP stealth-10-32-244-219.cisco.com.61348 > > bw-in-f104.1e100.net.http: Flags [S], seq 567668515, win 65535, options [mss > 1460,nop,wscale 3,nop,nop,TS val 418428163 ecr 0,sackOK,eol], length 0 > > > > #2: SYN-ACK, ACK, "GET" > > 09:53:38.303788 IP bw-in-f104.1e100.net.http > > stealth-10-32-244-219.cisco.com.61348: Flags [S.], seq 1496444701, ack > 567668516, win 5672, options [mss 1360,sackOK,TS val 765576747 ecr > 418428163,nop,wscale 6], length 0 > > 09:53:38.303856 IP stealth-10-32-244-219.cisco.com.61348 > > bw-in-f104.1e100.net.http: Flags [.], ack 1, win 65535, options [nop,nop,TS > val 418428166 ecr 765576747], length 0 > > 09:53:38.303956 IP stealth-10-32-244-219.cisco.com.61348 > > bw-in-f104.1e100.net.http: Flags [P.], seq 1:742, ack 1, win 65535, options > [nop,nop,TS val 418428166 ecr 765576747], length 741 > > > > #3: I get five data segments and ack them > > 09:53:38.507269 IP bw-in-f104.1e100.net.http > > stealth-10-32-244-219.cisco.com.61348: Flags [.], ack 742, win 112, options > [nop,nop,TS val 765576951 ecr 418428166], length 0 > > 09:53:38.509821 IP bw-in-f104.1e100.net.http > > stealth-10-32-244-219.cisco.com.61348: Flags [.], seq 1:1349, ack 742, win > 112, options [nop,nop,TS val 765576952 ecr 418428166], length 1348 > > 09:53:38.509824 IP bw-in-f104.1e100.net.http > > stealth-10-32-244-219.cisco.com.61348: Flags [.], seq 1349:2697, ack 742, > win 112, options [nop,nop,TS val 765576952 ecr 418428166], length 1348 > > 09:53:38.509894 IP stealth-10-32-244-219.cisco.com.61348 > > bw-in-f104.1e100.net.http: Flags [.], ack 2697, win 65209, options > [nop,nop,TS val 418428168 ecr 765576952], length 0 > > 09:53:38.510106 IP bw-in-f104.1e100.net.http > > stealth-10-32-244-219.cisco.com.61348: Flags [.], seq 2697:4045, ack 742, > win 112, options [nop,nop,TS val 765576952 ecr 418428166], length 1348 > > 09:53:38.510204 IP stealth-10-32-244-219.cisco.com.61348 > > bw-in-f104.1e100.net.http: Flags [.], ack 4045, win 65535, options > [nop,nop,TS val 418428168 ecr 765576952], length 0 > > 09:53:38.510470 IP bw-in-f104.1e100.net.http > > stealth-10-32-244-219.cisco.com.61348: Flags [.], seq 4045:5393, ack 742, > win 112, options [nop,nop,TS val 765576952 ecr 418428166], length 1348 > > 09:53:38.510508 IP stealth-10-32-244-219.cisco.com.61348 > > bw-in-f104.1e100.net.http: Flags [.], ack 5393, win 65378, options > [nop,nop,TS val 418428168 ecr 765576952], length 0 > > > > #4: I get a final segment and ack it > > 09:53:38.714801 IP bw-in-f104.1e100.net.http > > stealth-10-32-244-219.cisco.com.61348: Flags [P.], seq 5393:5966, ack 742, > win 112, options [nop,nop,TS val 765577158 ecr 418428168], length 573 > > 09:53:38.714924 IP stealth-10-32-244-219.cisco.com.61348 > > bw-in-f104.1e100.net.http: Flags [.], ack 5966, win 65474, options > [nop,nop,TS val 418428170 ecr 765577158], length 0 > > > > No final (FIN) > > > >> We understand the potential of pkt pacing as a way to mitigate bursts, > but are also concerned with the complexity that pacing introduces to the OS > implementations. There hasn't been any evidence so far of its necessity for > a modest IW increase in the order of 10 segments and so we'd like to leave > pacing as the last resort (if need be). > > > > OK. What does it take to get you to look at SCTP? > > > >> -Nandita > > > > --000e0cd31074605626049430ee33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

[resume an ol= d but unfinished thread that was partly hampered by tmrg list problems]
We've been working hard in the past couple of months to stud= y a number of
questions/concerns/issues people have brought up. W= e were glad to continue
to have Yaogong Wang, a PhD student of Pr= of. Injong Rhee of NCSU to
collaborate with us after his internship finished in the summer, to se= tup
a 2nd testbed at Dr. Rhee's lab. The test result from his= testbed is near complete
and can be seen at


<= div>In the meantime we continue to run tests and compare results from both = sides.
Unfortunately tests on slow=A0links have been especially time-consumin= g simply
because they run very slow. It=A0takes a long time to ge= t quality data (and we still
see large variations). But=A0in ligh= t=A0of the upcoming IETF meeting we will try to
conclude and post some=A0summarized remarks soon.

=
I do want to answer a simple question you brought up a while back belo= w, just
how many RTTs=A0might IW10 save compared to IW3?

Your argument of max 3 RTTs below has neglected delayed acks= , which will=A0affect
the formula. I'm including a graph show= ing majority of 3RTT savings, followed by
2RTT, then 1 and 4RTTs.= (The same numbers can be found at section 5.2 of
draft-ietf-tcpm-initcwnd-00.txt.) These numbers assume somewhat "= pure" and
long delayed ack timers. In=A0reality implementati= ons tweak the delayed ack logic
in different ways. Linux has a &q= uot;quick ack" mode at the beginning of a new connection.
Windows stack has its own delayed-ack heuristics.=A0So in real life I = believe the
number of=A0RTT savings will be somewhat in between. = (Ideally I'd like to do
measurements against real stacks=A0to= count the numbers but I just don't have the
time to do it right now.)

Jerry
On Mon, Jul 19, 2010 at 8:35 AM, Fred Baker <fred@cisco.com>= wrote:

On Jul 18, 2010, at 2:58 AM, Lachlan Andrew wrote:

> Regarding whether it is a "single flow" or not, I'd argu= e that even if
> it is multiple TCP connections, they're all really part of the sam= e
> "flow", since they're aiming to carry (different parts o= f) the same
> map.

Arg. We return to definitions of a flow...

I think the important thing here is the mathematics of it. If I look for an= image at images.goo= gle.com, for example, I will download an html file followed by 20-or-so= separate images. In tests I have run, those are often separate TCP session= s, all of them going through slow-start and possible later saw-toothing sim= ultaneously. That basically means:

client sends 20-or-so SYNs
=A0 ...
client receives 20-or-so SYN-ACKS
=A0 =A0 =A0 sends 20-or-so Acks
=A0 =A0 =A0 sends 20-or-so HTTP GET requests
=A0 ...
client access interface starts receiving IW*20-or-so datagrams comprising t= hose 20-or-so images.

That behavior should be fairly apparent in the attached, which is a graphic= al representation of exactly this between Firefox at my home and images.google.com. I'l= l attach also a comment I made to Nandita last April; it references a numbe= r of other files which I don't have any more but could recreate if folk= s are interested.

Comparing that to the behavior of a single SCTP session with 20 streams, or= the behavior of a single pipelined TCP session, I think the point should b= e apparent that these are mathematically not very similar, and that the val= ue of IW is important.

Now, one will argue that getting a zillion thumbnail images is not much of = an issue, as thumbnails are small. My concern is more essentially about dis= carding congestion control. If the average file moved is on the order of 15= ,000 bytes, IW=3D10, and typical message size is about 1500 bytes, my four = function calculator says that we have in the typical case discarded congest= ion control entirely and instead are simply looking at the issues of retran= smission. The average file is put entirely in flight during the first RTT.<= br>
In my email with Nandita and company, I asked about the possibilities of pu= tting up a TCP Discard stream (representing competing traffic), letting it = get established, and observing the effect on it when a flash crowd like thi= s is imposed. I still think it would be an interesting test...


Begin forwarded message:

> From: Fred Baker <fred@cisco.com<= /a>>
> Date: April 1, 2010 3:33:43 PM PDT
> To: Nandita Dukkipati <nandi= tad@google.com>
> Cc: draft-= hkchu-tcpm-initcwnd@tools.ietf.org, Jerry Chu <hkchu@google.com>, Yuchung Cheng <ycheng@google.com>
> Subject: Re: cwnd=3D10
>
>
> On Mar 31, 2010, at 6:50 PM, Nandita Dukkipati wrote:
>
>> Fred, Hi.
>> Some responses inline...
>>
>>> Where I get concerned, as I mentioned last week, is when the r= eceiver is outside the high bandwidth corridor that stretches from Australi= a and eastern Asia across anglophone north America and through western Euro= pe. I have attached a map showing the corridor in very general terms, and m= aking an error (oversimplifying) with respect to Mexico and the Caribbean. = Geographically, this is a fairly narrow scope, as it leaves out the entire = continents of South America and Africa and most of Asia (and btw polynesia = and Antarctica). It does represent the more developed countries of the worl= d, however, and much of Google's markets. I'd be willing to bet tha= t the vast majority of your tests have been to places in that corridor. Out= side the corridor, I have some grave concerns.
>>
>> Great point! Knowing that this may in fact be the Achilles Heel in= standardization of cwnd=3D10, we deliberately chose the test data-centers = that also serve traffic to the above regions, including Africa and South Am= erica. The data presented (link: paper) is sliced and diced by network prop= erties such as bandwidth (BW), RTT, and BDP. Assuming that the primary caus= e for concern in developing countries is low BW connectivity, the paper spe= cifically lists the observations for low BW subnets including those with &l= t;=3D56Kbps. That said, we can also break the performance down by specific = countries/continents, something that we are in the process of performing. W= e are also actively pursuing tests with clients in Africa to further valida= te our original numbers (that IW=3D10 doesn't hurt).
>
> In the paper and in the slides, what I observed you testing was the im= pact to your sessions of changing the initial window. Did you do any testin= g of the impact on other sessions? For example, on a 56 KBPS link with its = (Cisco low end default) 40 packet buffers, setting up half a dozen ten pack= et bursts should show up in a loss rate to the sixth session. If there was = a competing session, say an FTP that had been happily moving a file for sev= eral seconds and found itself dumped on with sixty 125 millisecond packets = (7.5 seconds worth of traffic), I could imagine the competing TCP session b= eing lost entirely or at least being badly hurt. Dod you try setting up a T= CP Discard session in parallel and testing the impact on other users?
>
> You might be aware of issues between BitTorrent and Comcast, currently= under discussion in the FCC, around the impact of BitTorrent on other user= s. It could extend to Google.
>
>>> There are two things I have suggested in the past and would no= te for the record:
>>>
>>> 1) I think any give host would do well to maintain a certain a= mount of history somewhere; if cwnd/rtt is an approximation of "a reas= onable connection's characteristics" available to a destination, t= hen recording that ratio and referring to it when starting a TCP session wo= uld go a long way in the direction you are suggesting. If you share a LAN w= ith a device, I could imagine setting cwnd=3Drwin and let SACK and the fast= retransmit heuristic pick up the pieces. More generally, if you were to re= cord the ratio (as I believe Linux does) and initially set cwnd to some fra= ction of it times the RTT measured on the syn/syn-ack exchange, I imagine y= ou would find cwnd low when it needs to be low and high when it is likely t= o work out. The secret sauce, so to speak, is in the fraction - is that hal= f?
>>>
>>> 2) A major problem that TCP/SCTP have in the initial burst is = that it is a burst. Ack-paced traffic tends to be spread out throughout the= RTT, but the first few bursts tend to pile up, which can result in a momen= tary overload of switch/router/modem queues. Which makes me wonder: what wo= uld happen if we presumed some basic rate (perhaps derived from the saved c= wnd and rtt or cwnd/rtt mentioned in [1]) and sent the initial burst *at*th= at*rate*? Picking numbers out of the air that happen to be simple to calcul= ate with, if we found that someone typically had 1.2 MBPS to use and that t= heir mss was 1500 bytes (12000 bits), that would suggest that we might try = sending one segment every 10 ms until we got the first Ack and followed our= favorite congestion control algorithm after that. If someone has a long RT= T, that results in us having a lot of segments (in separate packet trains) = in flight pretty quickly, but if the RTT is short it starts with an initial= amount more appropriate to the RTT.
>>
>> We have tried the approach in [1] and the presentation slides to I= CCRG/TCPM cover the pros and cons of the approach. Overall, there is a trad= eoff between the cache size used and the hit rate; cache hit rate is low be= cause of load balancers before the front-ends.
>
> Looking through the presentation and paper...
>
> "IW=3D10 saves up to four round trips" seems like an interes= ting statement. If IW=3D1, the second RTT carries 2, the third four, and th= e fourth 8. IW=3D10 takes 1+2+4+3 segments in the first RTT and the other f= ive from the fourth RTT (plus however many more) in the second RTT. If IW= =3D2, the sequence is 2, 4, 8, and conversion to IW=3D10 means that the fir= st 2+4+4 segments go in the first RTT and the next six (plus whatever) in t= he second RTT. With CUBIC, It could rise more quickly. I see a reduction of= two or three RTTs; where is there a reduction of four?
>
> More importantly, the statement on slide 5 is that this reduces the tr= end of browsers opening up multiple TCP sessions. I'm not sure I see th= at. Take a look if you would at
> =A0 =A0ftp://ftpeng.cisco.com/fred/google/firefox-tcp.pdf > =A0 =A0ftp://ftpeng.cisco.com/fred/google/safari-tcp.pdf
> =A0 =A0ftp://ftpeng.cisco.com/fred/google/google-image= s-firefox.zip
> =A0 =A0ftp://ftpeng.cisco.com/fred/google/google-images= -safari.zip
> =A0 =A0ftp://ftpeng.cisco.com/fred/google/google-images.x= lsx.zip
>
> The two pdfs are the graphics; the others are the supporting data. I s= poke for an hour with Mike Belshe at the IETF, and he called out Google Ima= ges as an example of a web browser opening lots of sessions. OK, great exam= ple, let's play. So, I opened Safari, looked up "April Fools Pictu= res" on Google Images, cleared my cache, opened a tcpdump, hit "r= efresh", and turned off the tcpdump. Then I repeated the experiment wi= th firefox. What I see is signature HTTP behavior:
>
> - the browser downloaded the main page
> - the browser opened some number of TCP sessions to "get" ob= jects
> =A0 =A0 =A0 =A0SYN, SYN-ACK, ACK, "GET"
> - the browser received each of the objects in question
> =A0 =A0 =A0 =A0Data, Ack, Data, Data, Ack, ...
>
> You can see that very clearly in the pdfs. I have to ask. What would t= he fact that Google has bumped IW=3D10 got to do with how many sessions the= browser opened? Google didn't even *try* to deliver the first of the r= equested objects until the last of the sessions was open.
>
> Had it used SCTP, those would be streams in a session. I think I can f= igure out (your slide 5) how one builds the congestion control for that. >
>
> BTW, it looks like you have already increased the initial burst at goo= gle. Picking up one of those sessions at random, and noting that my RTT to = Google is very long compared to my RTT to work (I have a split tunnel, so t= hat means that the google data center is really far away)
>
> --- bw-in-f1= 04.1e100.net ping statistics ---
> 10 packets transmitted, 10 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev =3D 186.227/198.954/209.654/8.509 ms
>
> --- irp-view= 13.cisco.com ping statistics ---
> 10 packets transmitted, 10 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev =3D 19.579/25.110/36.951/5.107 ms
>
> I see four bursts of activity in this session:
>
> #1: SYN
> 09:53:38.102027 IP stealth-10-32-244-219.cisco.com.61348 > bw-in-f1= 04.1e100.net.http: Flags [S], seq 567668515, win 65535, options [mss 1460,n= op,wscale 3,nop,nop,TS val 418428163 ecr 0,sackOK,eol], length 0
>
> #2: SYN-ACK, ACK, "GET"
> 09:53:38.303788 IP bw-in-f104.1e100.net.http > stealth-10-32-244-21= 9.cisco.com.61348: Flags [S.], seq 1496444701, ack 567668516, win 5672, opt= ions [mss 1360,sackOK,TS val 765576747 ecr 418428163,nop,wscale 6], length = 0
> 09:53:38.303856 IP stealth-10-32-244-219.cisco.com.61348 > bw-in-f1= 04.1e100.net.http: Flags [.], ack 1, win 65535, options [nop,nop,TS val 418= 428166 ecr 765576747], length 0
> 09:53:38.303956 IP stealth-10-32-244-219.cisco.com.61348 > bw-in-f1= 04.1e100.net.http: Flags [P.], seq 1:742, ack 1, win 65535, options [nop,no= p,TS val 418428166 ecr 765576747], length 741
>
> #3: I get five data segments and ack them
> 09:53:38.507269 IP bw-in-f104.1e100.net.http > stealth-10-32-244-21= 9.cisco.com.61348: Flags [.], ack 742, win 112, options [nop,nop,TS val 765= 576951 ecr 418428166], length 0
> 09:53:38.509821 IP bw-in-f104.1e100.net.http > stealth-10-32-244-21= 9.cisco.com.61348: Flags [.], seq 1:1349, ack 742, win 112, options [nop,no= p,TS val 765576952 ecr 418428166], length 1348
> 09:53:38.509824 IP bw-in-f104.1e100.net.http > stealth-10-32-244-21= 9.cisco.com.61348: Flags [.], seq 1349:2697, ack 742, win 112, options [nop= ,nop,TS val 765576952 ecr 418428166], length 1348
> 09:53:38.509894 IP stealth-10-32-244-219.cisco.com.61348 > bw-in-f1= 04.1e100.net.http: Flags [.], ack 2697, win 65209, options [nop,nop,TS val = 418428168 ecr 765576952], length 0
> 09:53:38.510106 IP bw-in-f104.1e100.net.http > stealth-10-32-244-21= 9.cisco.com.61348: Flags [.], seq 2697:4045, ack 742, win 112, options [nop= ,nop,TS val 765576952 ecr 418428166], length 1348
> 09:53:38.510204 IP stealth-10-32-244-219.cisco.com.61348 > bw-in-f1= 04.1e100.net.http: Flags [.], ack 4045, win 65535, options [nop,nop,TS val = 418428168 ecr 765576952], length 0
> 09:53:38.510470 IP bw-in-f104.1e100.net.http > stealth-10-32-244-21= 9.cisco.com.61348: Flags [.], seq 4045:5393, ack 742, win 112, options [nop= ,nop,TS val 765576952 ecr 418428166], length 1348
> 09:53:38.510508 IP stealth-10-32-244-219.cisco.com.61348 > bw-in-f1= 04.1e100.net.http: Flags [.], ack 5393, win 65378, options [nop,nop,TS val = 418428168 ecr 765576952], length 0
>
> #4: I get a final segment and ack it
> 09:53:38.714801 IP bw-in-f104.1e100.net.http > stealth-10-32-244-21= 9.cisco.com.61348: Flags [P.], seq 5393:5966, ack 742, win 112, options [no= p,nop,TS val 765577158 ecr 418428168], length 573
> 09:53:38.714924 IP stealth-10-32-244-219.cisco.com.61348 > bw-in-f1= 04.1e100.net.http: Flags [.], ack 5966, win 65474, options [nop,nop,TS val = 418428170 ecr 765577158], length 0
>
> No final (FIN)
>
>> We understand the potential of pkt pacing as a way to mitigate bur= sts, but are also concerned with the complexity that pacing introduces to t= he OS implementations. There hasn't been any evidence so far of its nec= essity for a modest IW increase in the order of 10 segments and so we'd= like to leave pacing as the last resort (if need be).
>
> OK. What does it take to get you to look at SCTP?
>
>> -Nandita




--000e0cd31074605626049430ee33-- --000e0cd31074605638049430ee35 Content-Type: image/png; name="IW-vs-RTT.png" Content-Disposition: attachment; filename="IW-vs-RTT.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gg30nfl81 iVBORw0KGgoAAAANSUhEUgAAA2wAAAJ9CAYAAABJkfHbAAAgAElEQVR4nOzdeXxU1f3/8feFhKwQ giZICIso8AVRQFQMaom1BhTQYiuLWAhgBVoVZKkFURCLCypuYN0LVCnqz6LUWgSLgARFRZCAyCKg EJYkJoGQPZnz+wOZkpBMZiaZzE3m9fQxD5m5c8/53CWTeeeee69ljDECAAAAANhKTuZRBeVkHvV3 HQAAAACASjTydwEAAAAAgMoR2AAAAADApghsAAAAAGBTBDYAAAAAsCnbBLat32xT0+bn+LsMNFDs XwAAAKiPgtx9478/XKm3310uSZpw51hd2fsKnxXlS5+sXadrE/v6uwyvfLRqtVZ+vE6ff71FP3y/ V207XKgre/XUDb/qq35J19OfD73+t8V6Y+nLSjucqdEjx2j8uPFq3jzKZ/398OOPWr36v/rXv1O0 /8ABZWUdU7Nm0WrXto3Gjv6Nfn3zTQoKcvvHFwAAAPWUlZ1xpMr7sKVu/0Jr17+qqOaZ2rq1mUpK GsnhaKSwsDJdcslx5WTH6JeJ49TtoktrXMjWb7bpmr7XKjfnpxq1k5Z2WHOemK9v9+yXJDVuZGna hDs04Mb+2vjZ5/rNkNt05OC+Gtcb06qNMo4cdPvfNfFTVpbunjJdX23frfMHjFP0BT3U5LwLdfSH vTq6e6tyPn5JCZd00gvzH9U5LVrQXyVqun8dPnxE/W68XoP7Zevo98FKL+2mf/5zhRo18s1B6ti4 9mrceKgKCwdJ+j9JMQoLO6ImTXYrOPglxcZma82q5QoJCfFJ/wAAALAHl4HtuYXj9MCDeZKkpUuD ZYxkjCWHw2jkyBJJ0pxZEZp4z0s1LqSmX6jz8vL00GNP6o1l/09lV/9Bxa0SJYek4hyFrZqma3p1 UcrnnysvK1PZGUdqXG9dBbafsrLUp2+S2lx7q371h0cVGRYqh6S8Eim7SDpWIKXlFOr7v09X46/f 0aZ1q2oUohpqf97sXydPnlRERIQsy5Ik7dmzV31+0Vd5HznU755wXT1ogqZMmepxLe6IadVepaU5 ksokbVWTJifUtOnVahrZWBERZcrKvkP9kyI1/8m5PukfAAAA9uAysP196a266+7K/4LvyCtT6YkS LXypRGPufr/GhdQksDkcDt08fJS+zItV0YV3SoeOSGVxUmg3KTJaapqvJrvuU3GPJOnlm2sU2GJa tZEklZaWOoekVffvZs2a6vtd33rV322jxymzaQf9ZtrTOidUCguSHEY6USylF0qH86RDedIPudIP f7tXVwft01uLvA/Q/ujvWEi8vvvoTTWy/ve6OeP/xkilRgq6coSuCT3kVX/e7F9vLP2Hdu36Vg8/ 9LCkU0dvr+t3tY7+u0BffyANX3yeNn2xxeNa3BHTqr0aNxoi6T21bdtRwU2C9f33e9S2baqimkXI mK06ln6HUrd86pP+AQAAYA8uT4Jp3Pjs1xyFDpUeL1HZ8WKVniiR8q2z31THXnt9kVLWfqKQqFid s3+9ul/SU4czjumH/fvkiPydijpOU/FFz0txNe/Lk6NqNT3C9tGq1fpq+26Ne/MttQyXzguXvv30 P5p550gV5GXqjmeWK7r3r3WiWIoMlsJ+86g2PNRTH61a7dU5X5X1F9VEOnb0qEb2aCWrcSNdecdM tf71g4oMblxr/Y168SXtWvWGDv74g1RYKH3wgdSsmZSU5Hxvq/h2Ch30gDY8ca3X/XlqQ8oqvb9i lYKDm+jii7tr9+49at8+WAov0HkxUnbOSZ/1HRkZoZG3n6PJk75SVFQzSdJvh47Vnr3/VGjobWrS JFap2w/5rH8AAADYg9tXLTAlRqXHi1V6vORUYDtx6v+lJ5v4sj63LHxtsc5r216LXnhaV1x+ufP1 3bv3qM8vfinld5dCR0r17HSflR+vU+dB49Q8IlThVokWPzxD7/19mQoL31Vwk/l6ddLgcu+3QqJk bpqtDz9e51WgOd3fvH4xKj5ZPow0jg1W2eYSfXX7U/ruvhW64I//VEjY+fqpz7ga9xcVHqpGlqXm zZpJ114rnXOOlJYmrVwpvf76zwtnKSQkVNk16M9TR44c0Zw5Dm3a9Df9eKiRQpo4NGJEsRQuRcdI ObkF5Y6o1qbNmzaoRYto5/OfsrK0desWtY7/k8LCHMrP367/+7+La71fAAAA2Ev13zTLjEpPh7Of H7+c1Eh9+/7y1PQQafZfHjtrtnXr1umT1f+p7XrPkrLxM/2i92V67JGHFR4e7nzd4XDo3j8/JBPZ RorcJ+2dLR2teX9nDol099/eDonc9PUWdR57u7LT9uvZScOUcehcFRZukXSuSop/UeHdOTKO9lJ8 D3328d+9WrbT/TmsUilbUvP/TSvTqXMWSz7JU878VH3954vV7NaFtdKfcyjkG29IUVHSxx9LRUVS 27bSDz9I7dpJkiypRv15aurkBzR52kh9+22+goPPmJAhhUVLAy9tot/fMVqvvPq3Wg9tZ4a1rKxs DbhpuCIib1fMuRepSZM8pW6fq3snDq3VPgEAAGA/Lr9lOoqMig4XlAtrpcdL1LfvjXpm7lxpxw4p LExq0eLUUZHQUOe8kyZN8nnxktSx44V67pmnznp9167duubKHrrmyh6S8v43YdqUGvVXl0MiD3y/ Vxc1b6XnR/9SuZmtZRz/UrW3zou9UAf37/W6vx6tLnT9JksyU8pkzstTzu3J0m/n17i/Aoek0lJp 4kRpxYpTE0NCpNtvl157TZozR5JUYlSj5fPU1Vf1Ua9LE5WQsE5Ll+apU6efJ4Sferw9rkC/fTFF d/5+jF559W9qXNkY4hoqKi7WLbeOUn7etbrggvsUElKob3fepSt7X6A77xhd6/0BAADAXlwGttLc EhWlFZcPbCdKpFWrTn2R7tLl1DlHGRlSbq70yCPSPfdIkg7oQF3Ur9iYGD0278lKp908aKC6dPm/ s15Pz8hQbEyMr0ursXYXXKif0o9o6F/X6F9/GqastEEqLlws6dzKZzCS0veqzfnVhC4X/R39Ya+q vArN6T7mN5Y1N1QhYxeqsFm7Gvd3blQPmcaNpb17TwX/0/74R6lPH+nPf5YkFZapRsvnqRM/HdSC pxdq2f97V717P6DCwiKVFBvddHOw3p5RrKDG0jvjCvSbv27Qnb8fo5dfeb3WQ9us2Y/rWHo7der4 oEJDS7Rr90S1ic/TXxc8X6v9AAAAwJ5cHq4pyy1VUVrBWQ8lJEg//aQjX7yvfdvek44ckbZvl955 R5owQTu1U6u1uq6WQY8/8ZQeT4849TgaoSeW/FOffrlVnTt3Kve+/Px83TNpivbs8f4ITUyrNopp 1cY53NGdf1/QuatXffW+tKfSvtuq4ujzNXzRBl36664KCukpab0aB/9apwYJnn5ES40lHdqqhMt6 1qg/yxEkRZdvvlFssHRIanxthML/drFaPZCqwstH1Up/mYWSkVU+rElShw7Sb38rXXmlrLJSnSyp 2fJ5qqy0SAe+26Su7Zrp5fkPaeGTs/TXp2cp42hHDXsgTKVNpOAg6d0JBSpK+1Tj7hyrsrKyWq3h Px/9V+e1/KPCwsp0Mu9TlZWl6q2lryv0jKPZAAAAaLhcBrbi3LLyYe3wz4GtaVPtbfKjev/83zRN k9q3l1avllJStOFvY9VTdfOl2mnUbOn62VJJB1mZB/X03Fnlbmr8xZdf6rK+SVq/6Std1SfB624y jhxUxpGDCgoKcvvf3l7S/4Zf9dWxVS/pYHahDhcGq9v4J9TvLy8rOOw3Kit5X70fXK6r3zPq+A+j iFeN9ORRhW98STf+qm+N+vvFkgwNXW10x1qjP3xqNGr5ETkySqT2jRQXP0VxM77S8WbnSyWFtdLf oZxCGWOUk5Nz9uMvf1HOgw/KIavG/XkqsnmcHMahkpJilTkcKiouVfbJAg0aMEAZJzvpthfDVOY4 Fdr++YcC5R9cr/Hj7qjV0JaZeVjf7Rqk9esv0KZNv9M1V11BWAMAAAggLodE5pbEqijt8M9DIf83 NFJx0st6WcM0TDM0Q71+/m9Y6DDtffsR3XLNTdpy47C6WoZTjko6KCkkSUEX3K3EpFvUrl0HxcW1 1DffbFFecZmKctP1+Nw5dVtXDfRLul5XLv1/2vq36eow9mmFB0nBXW/QL9/JUFGZlFsipedJGYVS XqnUZMV0dT6vqZKu/1Xt9ddIMsHnKfF9o9wSKatIOlrL/X395sMqNZZatWl/1ntO34etzGqsJh89 rC6tm9fJFSIlqUlohNp2ukzFO79SflGZGuWV6viJXJUZo4H9+utfHxqNeGWP3vx9gZoEScv/UKCb F67ThPF36K8vvlorwyO//GxduQAYElrPLnUKAACAGnF54+xtW77Sh6/NV5P0H6SiUunn740nrhys lc+s1FIt1aW6VNu1XdfpOiUpSau0SstfuF5vP/xfzU51/6bCNblxdnRMK2ni+2ryxSoVX/i4dChc 2p8tpW+Xmh6W4lopJP9lXd4qXe+/tbjckTdP1fWNs3/KylLvvkkqu/RWNR/yqJqEhMpIKi47FZqO F0slRYVqsmK6GqW8qsL8kxr3+zv02CMPN7j+Gm98TQV5ubrnrj/ooVkPeNRPTfav08rKSvWvf72n 7w/sV3REiKIiQ7R46T/VutEevXFHgRo3kopKpK4PhuuVxe/q0p49vO7rtAs6X6L8/AI1siwZ41Dz 6Ob6dttXNW4XAAAA9YPL5HJJz8v05wVLNfntFE1+f5Mmf3DqcVInlaEM9dCpL6Td1E1btVXX6Bqt 0ir1+cMbUseOdbIAp0UsGavE6B8UtrK7ZL0ntf5G6lamJjE7Fbb3txqZ2EzLFr1Yo7Am1e2QSEk6 p0ULbVq3SldY+5R+f0/tXf6Mvv9yrX44eEiZ36xVyepnFP5YT/Uq2KKSogJJ0kuvvKon5z/T4Por Kjh1tc/nFryg5xf+1av+aqJx4yANHDRY3bt2UmREE0WEhWryXck6VNpRv3vt1PDItGzpeL5RzLlV XBjGQw6HdGP/9RoxYruGDfuPjMPlJWEAAADQwHh186hd2qV+6qdGZ+S9VmqlO3Xn/9506aU1Ls5d oaFhenvxK+qTcKX+/eFKPbHwKZWVnfpi2/Xi8/XgGx+pdeu4Wu2zWbOmHv27Js5p0UJvLXpJH61a rQ8/XqfPVv9dB/efulpiwmU9deO8GeqXdL3e/Mcy3XXPvZKkvPz8Btff3xYt0eRp90mSjh6thZvq eSGocWNde91Abf1yjfJP/KSIiHA9Mnuy7n9ovq58dJ9+zCjVn6dPV5s28bXWZ2iYQ+FhDpWUOH6+ GR0AAAAChcshkVXpcH1X3dz3ZkUpqsr3eHrj7JoMWftk7Tpdm1g3F6Kwu+cWvCBHWZkmTby7Qfb3 xFNPq6ysTH/+01SP5quNIZFncjjKtP+7L1VSeFIREZGKbtVRX369Xc2bN1fPHt1rpQ9JuvD/LlZ+ fqEaWZYcxqHo5s21gyGRAAAAAcOrwAYAAAAA8L2andAFAAAAAPAZAhsAAAAA2BSBDQAAAABsisAG AAAAADZFYAMAAAAAmwra++1Wf9cAAAAAAKjgwq49ZBljuKw/AAAAANgQQyIBAAAAwKYIbAAAAABg UwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAAmyKwAQAAAIBNEdgAAAAAwKYI bAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAAmyKwAQAAAIBNEdgA AAAAwKYIbAAAAABgUwQ2oJZZluXvErRu3Tq1bdvWFrW4Yqf66mqdVdX+6tWrdd555zmnV3wO2JUn +6g/92df9V3ffkbXrFmjli1b2qJuf9RQ231W154d1jPqPwIb0ABNmzZNCxYskDHG36XUOl/98vPH OjtzWWbMmKE33njD2X/F54GMLzyeYX0FHk+2+YwZM/Tmm286P1vqS+D2l0BcZtgPgQ0NkmVZ6t+/ f6VfdgPhwzc1NVU33HCDv8vwiLvbxVcBxh/r7Mxl2bFjhxITE6t87g/ubBPLspSRkaGWLVuqqKio 3LTBgweXe15YWKjY2FhlZGR4VAeh1TOsr/pr06ZNuuKKKxQSEqKOHTvqjTfecGs+T7b5tm3byn22 eDLvme8NhN+lkmfrJ1DWCeoegQ0NVosWLbRw4UJ/l+EXhYWFCg4O9ncZ9Yq/11lBQYGCgoKqfG5n MTExSkhI0IoVK5yvZWVlacWKFcrMzHS+tnz5cvXp00cxMTH+KBOwvSFDhmj8+PE6fvy4li9frvff f7/W+6hPny0ATiGwocF64YUXtGDBAn333XdVvqeyv4ad+ZplWfrrX/+qDh06KCQkRN26ddOGDRu0 aNEiderUSU2aNFHPnj2Vmpparo158+apZcuWioiI0JgxY8odeSgrK9P06dMVGxur8PBwDRs2TLm5 ueX6fPrpp9WmTRs1alT5j2hhYaF+//vfKyoqSlFRUbrzzjtVWFhYrn7Lsqr8a19lfbhq09119eKL L6p9+/bO9bJ161bn9KKiIo0ePVoRERE677zz9MQTT5zVTsWaK6uz4nRX6/o///mPunXrpiZNmqh9 +/Z69dVXq1wfFft3Z31Ut51cLXPFfs/sv7J6vNlv3Jmnqm3mzn50puTkZC1ZssT5fOPGjXI4HNq4 caPztUWLFik5ObnS+V1tq4rbvOLjtOqW1939oTL79u3TTTfdpKZNmyo0NFQ33HCD0tPT3Wrb3WWr ank9/Qzy5OeyoKBAo0aNcu6j8+bNc7m9q9unq9sG7q7TX/ziF1q2bFm59//444+Ki4vT8ePHq+2n ujo9qUWSSkpKNHnyZMXExCg6OlpPPfVUpe1s3rxZ8fHxevbZZyV5vs8VFBSoT58+Cg0NVbdu3fTO O++4fP9p7m7zyj5rPNlfqvrMOs2T7X+aq8/w6rZLTX7vXHjhhdqxY4fz+eLFi53/3rFjhy688MKz 1q03v8ckuawRcAeBDQ1W8+bN9eKLL+p3v/udSkpKvG7n448/1rp165Sdna3bbrtNN954oz788EP9 97//VU5Ojm699Vbdeeed5eZZv369UlNTtX//fh07dkwPPvigc9ojjzyizZs36+uvv9axY8cUFham ++67r9z8mzZt0tdffy2Hw1FpTTNnztThw4e1Z88e7d69Wz/++KMeeOABSf8bvmGMcTmUo2Ifrtp0 19q1a5WSkqLs7GwNHjy43Hp54IEHlJGRof379+ubb77RmjVrnNNc1VzdunC1rkeOHKmHHnpIubm5 Wr9+vT7//PNK26isf3fWR3W1uVpmV/1XVo83+40781S1zdzdj04bMGCANm/e7PwylZKSoqSkJKWk pEiS0tLStG3bNg0YMKDS+T3ZVqcfL7/8sgYOHOicVt3yuttHZQYNGqRJkyYpPT1dx44dU+fOnTV5 8mS32q5Jv5J3n0Fnqu7n8vjx4zpw4IBSU1O1YcMGl7VUt0+7s8+d5mqd3n///ZozZ065n605c+Zo 4sSJioqKqrYfd3/23KlFkmbPnq0dO3Zoy5Yt2r9/vw4dOnRWGx988IFuuOEGLVy4UBMnTpTk+bbv 16+frr/++rP+COgpd3+uK/vZdrW/nFbV54Mn2/80V5/h1W2X6up1tR/069dP69evlyQdOnRId999 tzNcrlu3Tv379z+rVm9/j7mzTgGXDNAAnblrT5s2zUyfPr3SaZX9CFScnpmZ6Xyel5dX6WtBQUHl 5tmzZ4/z+e7du018fLzzebt27cx3333nfH706FHTsmXLcvOnpaW5XL64uDize/du5/Ndu3aZ1q1b u1yuistYsQ9v2qy4rn766Sfn84rrpXXr1uXWy65du9zaFhXrrDiPq3Xdpk0b8/zzz5uDBw+e1bar ZTHGvfVR3XbyZJkr9l/xuTf7jTvzuNpm7vyKOPM9EydONE8//bQxxphrrrnGbNy40Vx11VXGGGMe eeQRM3HixCrbcbWtKqtj9erVpmfPnubEiRPO16pbXk/2h+rk5eWZmJgYt9r2dNlq4zPozH9X93P5 /fffO5/v2bPH5Xavbp92Z5+rSsV1evnll5s333zTGPO/n+28vDy3+qmuzupUrCU+Pt7s2rWr0vdK MgsWLDBxcXHmiy++KDfNk33u6aefNh07djTPPPOMadWqlfnkk0+c0w4fPmzOPffcKuf1ZJu7+qzx ZN7K1md126Wyul19hldUcbvU5PfO+++/b4YOHWqMMeaxxx4zMTEx5pVXXjHGGDNkyBCzYsWKs5bT 299jrmoE3EFgQ4N05odmUVGR6dWrl/n000/PmubOlyVX06uap7S01Pm8pKSk3IdzUFCQkVTuYVmW y/Yraty4scs+3AlstdGmJ+uqsvZ9va6/+OILM2jQIHPOOeeYDh06OH8BV6ZiXzVdx1W14W1g82a/ 8Wae6raJq/dv2bLF9OjRwxQVFZlu3boZY4zp0qWLKSwsNJ07dzZbtmypsh1X26piHTt27DAdO3Y0 Bw4c8Gh5PdkfKkpJSTFXX321iYiI8LhtT5at4mve/ly4+97q9tGKqnu/J/tcdev0vffeM507dzal paVm+PDh5rnnnnO7H0+Xq7paGjdubEpKSiqdV5Lp0KFDuT8MnubJPhcXF2dSU1ONMcZs3rzZXHDB Bebtt982xhjzwgsvmNtuu63KeWvye83beb35zKmsbVefs9Vtl5rs37m5uaZt27bGGGMuvvhi88EH H5g+ffoYY4xp27atOXnypEftuVOPq9cAV9hj0CBV9gWvS5cu5sSJE2d9uTj9F1tjjMnMzKyVL0tn /gVuz5495Y7MtGnTxhw6dMjt2isTFxd31l/54uLi3G6jsunVtVnTdVXxL5O7d+/2+bo+zeFwmH// +9/mvPPOO2taVX3VdB0b49kyVxfYvNlvvJmnJoHNGGN69OhhXnrpJTN27FhjjDHJycnmySefNN27 d6+2LWMq31Zn9nHs2DHTuXNns2HDhrPmrW55XfVRndatW5tly5aZnJwc43A4zPHjxytdP67armya rz6D3H1vXFxcjY6wVdynPdnnqlunDofDXHzxxWbatGmmffv2pqioyO1+qquzsve7qqW6I2wHDx40 F154oZk3b16l73FnnwsPDy93JO7IkSMmISHBPPfcc+aKK65w+QcPuwQ2d38Gz2zD1Wd4ddulpr93 EhMTzVtvvWWuuOIKY4wxV1xxhXnvvffMtdde61V7BDb4CuewISB07dpV48eP1913313u9e7du+vJ J59Ufn6+0tLSNH78+Frpb/LkycrIyFBGRobuvfde3Xbbbc5p48eP15133qnvv/9epaWlSk1N1bBh wzxqf+jQoc5x/enp6Zo4caLHbXjaZk3X1fDhw53rJT09XZMmTSo3vXnz5tq1a5fHdbta18OHD9e3 336rkpISGWNUWlrqdru1sY6rW2ZPeLPf1HRf82abjBo1SjNmzHBeNjwxMVGzZ8+u8mIjp7m7rW6+ +WZNnz5dV1111VnTqlve6vpwdbGNgoIChYaGKjQ0VPv37z/rHBRXbbua5qvPIHcNGzZMU6ZMUWZm pjIzM886P6ii6vZpT/a56tapZVm6//779cQTT2jmzJlq0qSJ2/14+rNXXS2jRo3S3XffrUOHDikn J0f33ntvuenx8fFat26dXnvtNT366KPl6nD3M+i3v/2thg4dqi1btqisrEwOh0P9+/fXpEmTtGPH Dp177rkul6GuVfb54M1njqvP8Oq2S3Wq2w/69++vyZMn6/bbb5ckjRgxQnfddVel56+50563v8eA avkzLQK+Utmu7XA4TL9+/cpN+/rrr03Pnj1NUFCQadeunXnhhRdq5a/bjz/+uImNjTXh4eFm1KhR pqCgwDm9rKzMPPLII6Zdu3YmODjYdOvWzSxbtsxl+xXl5+ebMWPGmKZNm5qmTZuaMWPGmPz8fLfb qGx6dW3WdF0VFBSYkSNHmrCwMBMbG2vmzZtXbvpf/vIXExkZ6fFfe12t63/84x+mc+fOJigoyFx0 0UVm5cqVbq+Tmq5jd5bZ1bJWfO7NfuPNPNVtE1fvN8aY9PR0Exwc7DxSsH//fhMcHGzS09OrbMMY 19uq4nqq+HB3eV31sWHDBuf5dpVZvny56dChg2ncuLFp27atee6558r17aptV9N89Rnk7nvz8vLM 7bff7txH586da4KDg6tcD9Xt057sc9WtU2OMeeedd0zHjh3PGo5YXT/V1VlRdbUUFxebiRMnmhYt Wpjo6Ggzf/78SpfpyJEjpkuXLmbOnDnGGM8+g/Ly8sy9995r2rRpY4KCgkyrVq3MhAkTzHfffWde fPFFc8stt1Q5r6efm7Uxb2WfD9Vtl8radvUZXt12qenvnS1btpigoCDn59OxY8dMUFCQ2bp1q1ft efN7DHCHZYwxNYt8AOAflmWJjzDUhl/+8pd64IEHdO211/q7FL/67rvvdOONN2rfvn3+LkXSqSOq w4YN0/Dhw/1dCgD4DUMiAQABb82aNQEb1u69915lZ2fr6NGjmjJlin7961/7uyQ5HA698sor2rt3 r4YOHervcgDAr7jVPQAAAax9+/bq1KmTCgsLddNNN2nOnDn+LkmNGzdW+/bt9dZbb1V5Y3oACBQM iQQAAAAAm+LPVgAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAAmyKw AQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZV7wKb ZVnOR1UyMzPVtm1bl+8BAAAAALurd4HNGCNjjMv3zJo1SxMmTKijigAAAADANyxTXfqxKcuyKg1u O3fu1KBBg7R9+3aFhYVVG+4AAAAAwK7q3RG26kydOlVz5sxRaGiov0sBAAAA0JClp0snT/q0iyCf tl7HVq9erczMTA0fPtyj+TjXDQAAAIC3THCtQXAAACAASURBVFKSNHDgqcf559dq2w1qSOQll1yi F154QVdffXWV73G3LQAAAACQJFmWVEVe8HWWaFCBraojZdUtIoENAAAAQJX8GNga1JDIygIcQQwA AABAfVXvAtuZR9FO/5tQBgAAAKAhqneBzZNwRpADAAAAUJ81uMv6AwAAAEBDQWADAAAAAJsisAEA AACATRHYAAAAAMCmCGwAAAAAYFMENh+wLEsZGRlq2bKlioqKyk0bPHhwueeFhYWKjY1VRkaGPvzw Q/Xt21ehoaE655xzNGzYMKWlpdVl6QAAAABshMDmIzExMUpISNCKFSucr2VlZWnFihXKzMx0vrZ8 +XL16dNHMTExevLJJzVp0iQdPXpUBw4c0MUXX6xbb73VH+UDAAAAsAECmw8lJydryZIlzucbN26U w+HQxo0bna8tWrRIycnJkqQ1a9Zo8ODBat68uZo2barJkydry5YtdV02AAAAAJsgsPnQgAEDtHnz ZqWnp0uSUlJSlJSUpJSUFElSWlqatm3bpgEDBpw1b15enp599lldd911dVozAAAAAPsI8ncBDVlw cLCGDBmipUuXatKkSUpJSdHjjz+uadOmSZKWLFmioUOHKjg4uNx8lmVJkmJjY53hzqWf329bxvi7 AgAAAKBe4gibjyUnJ2vx4sUqLi5Wdna2EhISlJWVpaKiIi1evNg5HPJMxhgdP35cd911l8aMGVN9 J8bY+wEAAADAKwQ2H+vRo4ekU+eq9e7dW5LUu3dvLViwQKGhoc7pFTVr1kxTp07VF198UWe1AgAA ALAXAlsdGDVqlGbMmKHExERJUmJiombPnn3W0bWRI0dq586dKi0t1dGjRzVz5kwlJCTUfcEAAAAA bIHAVgdGjBihEydOOANb3759VVRUpBEjRpR736BBgzRs2DCFhYWpe/fu+umnn/TWW2/5oWIAAAAA dmAZw0lGlmWJ1QAAAACgUpZV5bUZfJ0lOMIGAAAAADZFYAMAAAAAmyKwAQAAAIBNEdgAAAAAwKYI bAAAAABgUwQ2AAAAALApAhsAAAAA2BSBzQcsy1JGRoZatmypoqKictMGDx5c7nlhYaFiY2OVkZEh Sfrmm2/Ur18/RUZGqnXr1nr99dfrrG4AAAAA9kJg85GYmBglJCRoxYoVzteysrK0YsUKZWZmOl9b vny5+vTpo5iYGO3evVs33XSTxo0bp/T0dH322WfasGGDP8oHAAAAYAMENh9KTk7WkiVLnM83btwo h8OhjRs3Ol9btGiRkpOTJUmzZ8/WrFmzdMsttyg8PFxt27blCBsAAAAQwAhsPjRgwABt3rxZ6enp kqSUlBQlJSUpJSVFkpSWlqZt27ZpwIABkqQ1a9bo6NGjiouLU0REhIYMGaLs7Gy/1Q8AAADAvwhs PhQcHKwhQ4Zo6dKlkk4FttmzZzsD25IlSzR06FAFBwdLkjIzM7Vv3z5t375dBw8eVHh4uCZMmFBt P5bN/wMAAADgHcsYY/xdhL9ZlqXaXA1ntrd161aNHj1amzZtUq9evZSamqquXbtqy5Yt6t69u5Yt W6YePXpIkqKionTgwAFFR0dLOnXOW7t27ZSbm1trtQEAAADwkGVJVeSF2s4SFQX5rGVIkjOMLVq0 SL1795Yk9e7dWwsWLFBoaKhzuiRdcsklZ81vWRyhAgAAQAPA91qvMCSyDowaNUozZsxQYmKiJCkx MVGzZ892XmzktNGjR2vq1KnKzs5Wdna2Jk+erIEDB9Z9wQAAAIAvGFN/H35CYKsDI0aM0IkTJ5yB rW/fvioqKtKIESPKvW/MmDGKj49Xp06dFB8fr7y8PC1cuNAPFQMAAACwA85hk+/HnQIAAAABz8V5 YPWZr7MER9gAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMA AAAAmyKwecGyLGVkZKhly5YqKioqN23w4MHlnhcWFio2NlYZGRnOeU8/KjLG6L777lN0dLRatGih 6dOnc384AAAAIIAR2LwUExOjhIQErVixwvlaVlaWVqxYoczMTOdry5cvV58+fRQTEyPpVCirKoS9 /PLLWr9+vXbs2KHt27dr7dq1eu2113y7IAAAAABsi8BWA8nJyVqyZInz+caNG+VwOLRx40bna4sW LVJycrJb7S1evFhz585VXFyc4uLiNHfuXC1atKiWqwYAAABQXxDYamDAgAHavHmz0tPTJUkpKSlK SkpSSkqKJCktLU3btm3TgAED3Gpvx44duuyyy5zPe/XqpR07dtR+4QAAAADqBQJbDQQHB2vIkCFa unSppFOBbfbs2c7AtmTJEg0dOlTBwcFutXfy5ElFRkY6nzdt2lS5ubnVzmdZ9n4AAAAA8A6BrYaS k5O1ePFiFRcXKzs7WwkJCcrKylJRUZEWL17s9nBISYqMjNTJkyedz3Nzc9W0adNq5zPG3g8AAAAA 3iGw1VCPHj0knTpXrXfv3pKk3r17a8GCBQoNDXVOd8dFF12kr776yvl88+bNuuiii2q3YAAAAAD1 BoGtFowaNUozZsxQYmKiJCkxMVGzZ8/26OiaJI0cOVIzZ87U4cOHdfjwYc2cOdPjNgAAAAA0HJbh Rl+yLMuj+51VfH9GRoZat26tffv2KT4+XgcOHFCnTp2UlpbmvJz/mfNWdLqt0/dhe+WVVyRJ48aN 06OPPlrpPAAAAEC9YlkN8nwZT7OEx+0T2Hy/kgEAAICAR2DzCkMiAQAAAMCmCGwAAAAAYFMENgAA AACwKQIbAAAAANgUgQ0AAAAAbIrABgAAAAA2RWADAAAAAJsisHnBsixlZGSoZcuWKioqKjdt8ODB 5Z4XFhYqNjZWGRkZznlPPyrzzTffqF+/foqMjFTr1q31+uuv+2YhAAAAANgegc1LMTExSkhI0IoV K5yvZWVlacWKFcrMzHS+tnz5cvXp00cxMTGSJGNMlTfW2717t2666SaNGzdO6enp+uyzz7Rhwwbf LggAAAAA26p3gc3VEaqVK1fquuuuU1hYmM455xzdfvvtSk9P91ktycnJWrJkifP5xo0b5XA4tHHj RudrixYtUnJyslvtzZ49W7NmzdItt9yi8PBwtW3bliNsAAAAQACrd4HN1RGq+fPna+rUqcrIyNDO nTsVFRWl4cOH+6yWAQMGaPPmzc5QmJKSoqSkJKWkpEiS0tLStG3bNg0YMMCt9tasWaOjR48qLi5O ERERGjJkiLKzs31WPwAAAAB7q3eBzZVVq1bphhtuUGRkpGJjY/XEE084w5MvBAcHa8iQIVq6dKmk U4Ft9uzZzj6XLFmioUOHKjg42K32MjMztW/fPm3fvl0HDx5UeHi4JkyYUP2Mls0fAAAAALximaoO V9mcZVlVHmk77f3339czzzyjTz75pMZtVfX+rVu3avTo0dq0aZN69eql1NRUde3aVVu2bFH37t21 bNky9ejRw60+o6KidODAAUVHR0s6dU5cu3btlJub63ZtAAAAgC1ZllQ/o4dLnmYJTwX5rGU/27p1 q+69916tXLnSrfdXddVGSS43wOkwtmjRIvXu3VuS1Lt3by1YsEChoaGVhrWqXHLJJR7VBQAAgADE 98M6ZbkxZOxDfagbdaNP+m9QQyJPW7t2rW6++WYtW7ZMnTp1cmue0+fGVfaozqhRozRjxgwlJiZK khITEzV79my3LzZy2ujRozV16lRlZ2crOztbkydP1sCBAz1qAwAAAAHAmPr5qKdMFf99rs8lyWdh TWqAge2tt97SiBEj9O677+qKK66okz5HjBihEydOOANb3759VVRUpBEjRpz13jOvcFnxapdjxoxR fHy8OnXqpPj4eOXl5WnhwoV1sgwAAAAAPNNbvX3eR4M6h23+/Pl69tlntXLlSnXp0qVGbQEAAAC2 1EDPBbMrS5aMql7fvs4S9S6wVXZO1+lFqOp8r9zcXEVGRrpss56tBgAAAAQqAlud8ndgq3cXHXG1 MghdAAAAABqSBncOGwAAAAA0FAQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAA myKwAQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZF YAMAAAAAmyKwAQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAG AAAAADZFYAMAAAAAmyKwAQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAA AABsisAGAAAAADYV5O8CAAAAgDpnWf6uIKBYYn17i8AGAACAwGSMvysIKEasb28wJBIAAAAAbIrA BgAAAAA2RWADAAAAAJsisAEAAACATRHYAAAAAMCmCGwAAAAAYFMENgAAAACwKQIbAAAAANgUgQ0A AAAAbIrABgAAAAA2RWADAAAAAJsisAEAAACATRHYAAAAAMCmCGwAAAAAYFMENgAAAACwKQIbAAAA ANgUgQ0AAAAAbIrABgAAAAA2RWADAAAAAJsisAEAAACATRHYAAAAAMCmCGwAAAAAYFMENgAAAACw KQIbAAAAANgUgQ0AAAAAbIrABgAAAAA2RWADAAAAAJsisAEAAACATdW7wGZZlvNRkTFG9913n6Kj o9WiRQtNnz5dxhg/VAkAAAAANVfvApsxpsoQ9vLLL2v9+vXasWOHtm/frrVr1+q1116r4woBAAAA oHbUu8DmyuLFizV37lzFxcUpLi5Oc+fO1aJFi/xdFgAAAAB4xTL1dMygZVlnHWmLiorSwYMH1axZ M0nS8ePH1b59e2VnZ3vcFgAAABowy5L4/ldnLFkyapjr29dZokEFtsaNG6ukpESNGp06cOhwONSk SROVlpZW25Yr9XQVAQAA+FY136Fsr559x7NUv9d3TQKbvXc1Sz17Gl1+udSrl3TZZdLFF0vBwbXT elDtNGMPkZGROnnypPMIW25urpo2berWvIQyAAAAL/Adqk411KNU7rDjrpaTI0VHS19/7bs+GtQ5 bBdddJG++uor5/PNmzfroosu8mNFAAAAABqq5s1930eDCmwjR47UzJkzdfjwYR0+fFgzZ85UcnKy v8sCAAAAAK/UuyGRZ55vdvrfp4czjhs3Tvv27XMeVRs3bpzGjh1b90UCAAAAQC2otxcdqU1cJRIA AMALXGmxTjXkKy1Wx867mq+zRIMaEgkAAAAADQmBDQAAAABsisAGAAAAADZFYAMAAAAAmyKwAQAA AIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAA myKwAQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZF YAMAAAAAmyKwAQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAG AAAAADZFYAMAAAAAmwrydwEAAAABy7L8XUFAsRS46ztgdjV/LecyScN807RljDG+abr+sCxLrAYA AFDnLEviO0idsWTJKDDXd8DsapZUp5t4q2T19G2WILCJwAYAAPwkYL5F2wOBzd9V1IG6DmzyfZbg HDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANkVgAwAAAACbIrABAAAAgE0R2AAAAADApghs AAAAAGBTBDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANkVgAwAAAACbIrABAAAAgE0R2AAA AADApghsAAAAAGBTBDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANkVgAwAAAACbIrABAAAA gE0R2AAAAADApghsAAAAAGBTBDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANtWgAtvu3buV lJSkiIgIRUREKCkpSbt37/Z3WQAAAADglQYV2IYOHao+ffooLS1NaWlp6t27t4YNG+bvsgAAAADA K5Yxxvi7iNoSFhamnJwchYSESJIKCwvVokUL5efnu5zPsiw1oNUAAADqC8uS+A5SZyxZMgrM9R0w u5ol1fUm9nWW8PoI2yuvvKI77rhDkvSvf/1LrVq1UkxMjD766KNaK85TAwcO1OOPP67jx48rJydH jz32mAYMGOC3egAAAACgJrw+wta+fXutX79ebdu2VYcOHbRw4UKVlJTo/vvvV2pqam3X6Za0tDRd ddVV+uGHHyRJ7dq108aNGxUXF+dyPsuyXE7n6BsAADZUze/veqMefc+wVP/XubdH2BrC7ubWrtYA lrOhHWHzOrAFBwfr5MmTSk9P16WXXqqMjAwVFRWpadOmKi4uru063XL99dcrISFBkydPliQ99dRT +vzzz7V69WqX8zEkEgCAeihgxnjZB0MK/V1FHfDDkML6ztdZIsjbGTt27KgPPvhAaWlp6tOnjyTp +++/1wUXXFBrxXnq008/1QcffOA8h+3+++9X8+bN/VYPAAAAANSE14Ft3rx5Sk5OVnh4uN59911J 0sMPP6xZs2bVWnGe6tq1qx599FFNmjRJkjR//nx169bNb/UAAAAAQE00qKtE7ty5U3/84x/1+eef S5ISEhL0wgsvqHPnzi7nY0gkAAD1UMCMUbMPhkT6u4o6wJBIj9n2HLaGhMAGAEA9FDDfoO2DwObv KuoAgc1jtr2sf2Fhof70pz8pPj5ewcHBatOmje677z4VFRXVZn0AAAAAELC8Dmzjx4/Xzp07tXbt WhUUFGjNmjXavn27JkyYUJv1AQAAAEDA8npIZEREhA4cOKCYmBjna+np6Tr//POVl5dXawXWBYZE AgBQDwXMGDX7YEikv6uoAwyJ9Jhth0RGRkZ69DoAAAAAwDNeB7YpU6Zo7Nix2rt3r8rKyrR3716N GTNGU6ZMqc36AAAAACBgeT0k0rIst95XH4YaMiQSAIB6KGDGqNkHQyL9XUUdYEikx3ydJby+cTYB BwAAAAB8y+shkQAAAAAA3/LoCNuZh/tcDYnk6BsAAAAA1JxHge3MIEYoAwAAAADf8npIZKNGjKYE AAAAAF/yOnXFxcUpMzOzNmsBAAAAAJyhRvdhu+eee3TkyJHarAcAAAAA8DOf3Ietvp3fxn3YAACo hwLmxlj2wX3Y/F1FHeA+bB6z3X3YThdEwAEAAAAA3+LKIQAAAABgUwQ2AAAAALApj4dESq7PX5Pq 3zlsAAAAAGBHXgU2AhkAAAAA+B5DIgEAAADApghsAAAAAGBTHgc2hkMCAAAAQN3gCBsAAAAA2BSB DQAAAABsisAGAAAAADZFYAMAAAAAm3L7PmzV3Sz7TFyYBAAAAABqzu0jbMaYco958+bpxhtv1O7d u1VSUqJdu3apf//+mjdvni/rBQAAAICAYRkvD4e1bNlSqampio2Ndb527Ngxde/eXUePHq21AuuC ZVkcFQQABB4PRs/YVj35/W2pAazrnxl5vs4bwq4mubG7NZDl9GITBzRfZwm3h0RWlJube9YwScuy lJubW+OiAABAHakngach8CboNCQBs6sFynKiznh90ZFbb71VY8eO1d69e1VWVqa9e/dqzJgxGjJk SG3WBwAAAAABy+vA9tJLL6lz585KTExUSEiIEhMT1bVrV7344ou1WR8AAAAABCyvz2FrSDiHDQAQ kCwrgMap+ZclK6CHRAbMrmaJIZEByNdZgvuwAQAAAIBNeR3YtmzZossvv1zBwcGyLKvcAwAAAABQ c14HtjFjxmjQoEE6fvz4WfdoAwAAAADUnNfnsAUHB+v48eMKDw+v7ZrqHOewAQACUsCcWOR/nMMW ILsa57AFJNuew9a6dWvl5OTUZi0AAAAAgDN4Hdjuu+8+TZ48WVlZWbVZDwAAAADgZ14PiXR1cZH6 NryQIZEAgIAUMOPU/I8hkQGyqzEkMiD5OksEeTsjAQcAAAAAfIv7sAEAAACATXl9hK0hDYkEAAAA ADuqtSGRP/30k8aPH6/rrruuxkUBAAAAAGpw0ZHKHDp0SFdffbUOHDhQW03WCS46AgAISAFzJQj/ 46IjAbKrcdGRgOTrLFGrgS0/P1/NmzdXcXFxbTVZJwhsAICAFDDfov2PwBYguxqBLSDZ9sbZFeXn 5+vJJ59Ut27daqtJAAAAAAhotXbRkaCgIHXv3l2vvfZajYsCAAAAAHAfNgAAAACwLe7DBgAAAAA2 5XVgKygo0JQpU9S6dWsFBwcrPj5e06ZNU2FhYW3WBwAAAAABy+vAdtddd+nbb7/VJ598ooKCAq1Z s0apqam65557arM+AAAAAAhYXl/Wv1mzZtq7d69iY2Odrx07dkydOnXS8ePHa63AusBl/QEAASlg rrXuf1zWP0B2NS7rH5DqzWX9pbOvHAkAAAAA8J7Xge3WW2/VmDFjtHfvXpWVlWnPnj0aPXq0hgwZ Upv1AQAAAEDA8jqwLViwQJ06dVLfvn0VEhKixMREdenSRc8//3xt1gcAAAAAAcvrc9gaEs5hAwAE pIA5scj/OIctQHY1zmELSPXmHLbc3Fy99NJL6tWrV201CQAAAAABzePAtn37dvXs2VMhISG68sor 9cMPP2j58uXq1KmTPv74Yz366KO+qNNt33zzjfr166fIyEi1bt1ar7/+ul/rAQAAAABveRzY7rnn Hv3mN7/RiRMn1L9/fyUkJOjZZ5/Vl19+qXfeeUdJSUm+qNMtu3fv1k033aRx48YpPT1dn332mTZs 2OC3egAAAACgJjw+hy0iIkKHDx9WVFSUcnJyFB0drb179+qCCy7wVY1uu+222/SrX/1KY8aM8Wg+ zmEDAASkgDmxyP84hy1AdjXOYQtItjuHLT8/X1FRUZKk5s2bS5I6dOhQu1V5ac2aNTp69Kji4uIU ERGhIUOGKDs7299lAQAAAIBXauWiI3a5YXZmZqb27dun7du36+DBgwoPD9eECRPcmteyrCofAACU Y1kN42FjVgP7z6t1YINdxOe7mtXAHoAPeDwk0p0A46/hhVFRUTpw4ICio6MlSVlZWWrXrp1yc3Nd zseQSACARwJmfJf/BPoQQilAdjNLDCFEvefrLBHk6Qx2DjaXXHLJWa9xhAwAAABAfVVr92Gzg9Gj R2vq1KnKzs5Wdna2Jk+erIEDB/q7LAAAAADwSoMKbGPGjFF8fLw6deqk+Ph45eXlaeHChf4uCwAA AAC84vE5bA0R57ABADwSECcX+RfnsAXIbsY5bGgAbHdZfwAAAABA3SCwAQAAAIBNEdgAAAAAwKYI bAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAAmyKwAQAAAIBNEdgA AAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAAmyKwAQAA AIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAA myKwAQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALCpIH8XAAAIEJbl7woaLEuBvW4b/K7V0JcP gEsENgBA3THG3xU0WEaBvW4b/K7V0JcPQJUYEgkAAAAANkVgAwAAAACbIrABAAAAgE0R2AAAAADA pghsAAAAAGBTBDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANkVgAwAAAACbIrABAAAAgE0R 2AAAAADApghsAAAAAGBTBDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANkVgAwAAAACbIrAB AAAAgE0R2AAAAADApghsAAAAAGBTBDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANkVgAwAA AACbIrABAAAAgE0R2AAAAADAphpkYMvMzFTbtm1lWZa/SwEAAAAArzXIwDZr1ixNmDDB32UAAAAA QI1Yxhjj7yJq086dOzVo0CBt375dYWFhcmfxLMty630AgBqwLInPWp+wZMkocNdtg9+1LCmANy9g e77OEg3uCNv/b+/eg6yu6z6Af87DLrCCXFMLCMQZdAp1aiY10y4EmRkkTigXHUidgZpnpkApdQaz MG8zSVlm89DY5a9I62nm+YOYEFMxyUzJIG6GOUPocnNBYoFh5fv8YazLsnvO2cPlfPfs6zWzM5zL 73c+5/P7nu+e9/6+5zB//vxYuHBh9O3bt9qlAAAAHJe6ahdwIi1fvjx27twZ06dP7/K2xT7v5uwb cEL4XO0pVYie1++eMMQ6+o2cIqIHHm6gh6ipJZEXXnhhPPLII3H55ZdHRPmnJy2JBE6Jml+3lZee uEywRwwxywOBzJzsLFFTga2zs2SlnqLABpwSPeLddD4EtholsAGZOdlZoqaWRLZvlCAGAAB0ZzX3 pSMAAAC1oqYDm7NrAABAd1bTgQ0AAKA7E9gAAAAyJbABAABkSmADAADIlMAGAACQKYENAAAgUwIb AABApgQ2AACATAlsAAAAmRLYAAAAMiWwAQAAZEpgAwAAyJTABgAAkCmBDQAAIFMCGwAAQKYENgAA gEwJbAAAAJkS2AAAADIlsAEAAGRKYAMAAMiUwAYAAJApgQ0AACBTAhsAAECmBDYAAIBMCWwAAACZ EtgAAAAyJbABAABkSmADAADIVF21CwC6mUKh2hVQQiF6yDEqpBJ3SN2uE6WeUVnbd7cnDUBRAhvQ del431ZysqXjfuufv0LU4FAsxPGnNgBqiiWRAAAAmRLYAAAAMiWwAQAAZEpgAwAAyJTABgAAkCmB DQAAIFMCGwAAQKYENgAAgEwJbAAAAJkS2AAAADIlsAEAAGRKYAMAAMiUwAYAAJApgQ0AACBTAhsA AECmBDYAAIBMCWwAAACZEtgAAAAy0pVPBQAAErpJREFUJbABAABkSmADAADIlMAGAACQKYENAAAg UwIbAABApgQ2AACATAlsAAAAmRLYAAAAMiWwAQAAZEpgAwAAyJTABgAAkKmaCmzLli2L8ePHR0ND QwwdOjRuuOGG2L59e7XLAgAAqEhNBbZFixbF/PnzY8eOHbF+/foYOHBgTJ8+vdplAQAAVKSQUkrV LuJkaW5ujiFDhsSBAweK3q9QKEQNtwFOrEIhwusla4UoRIraP0Y1ORQLET3g0AHUlJOdJWrqDFt7 y5cvj0svvbTaZQAAAFSkrtoFnCx//etfY968ebFs2bKy7l8oFDq9zdm3GlTkeFNcIUW8cxqgxhW6 8+s+dXqEuvOzaq+nDEUAeraaDGxPPfVUzJo1Kx5//PE499xzy9pGKOuBHPMK9ZDldlGjQ8SSOwDo VmpuSeSvfvWruP766+M3v/lNXHzxxdUuBwAAoGI1dYZt0aJF8dBDD8UTTzwRH/jAB6pdDgAAwHGp qW+J7OxzaHv37o3+/fsX3a6G2kA5avLr5U4N30DYzVkSCQAn1MnOEjV1hk3oAgAAaknNfYYNAACg VghsAAAAmRLYAAAAMiWwAQAAZEpgAwAAyJTABgAAkCmBDQAAIFMCGwAAQKYENgAAgEwJbAAAAJkS 2AAAADIlsAEAAGRKYAMAAMiUwAYAAJApgQ0AACBTAhsAAECmBDYAAIBMCWwAAACZEtgAAAAyJbAB AABkSmADAADIlMAGAACQKYENAAAgUwIbAABApgQ2AACATAlsAAAAmRLYAAAAMiWwAQAAZKqu2gVk o1DtAji1kmNeoRSp2iWcEinCGAEAqk5gO6JnvAcFAAC6EUsiAQAAMiWwAQAAZEpgAwAAyJTABgAA kCmBDQAAIFMCGwAAQKYENgAAgEwJbAAAAJkS2AAAADIlsAEAAGRKYAMAAMiUwAYAAJApgQ0AACBT AhsAAECmBDYAAIBMCWwAAACZEtgAAAAyJbABAABkSmADAADIlMAGAACQKYENAAAgUwIbAABApgQ2 AACATAlsAAAAmRLYAAAAMiWwcVwKhUK1S+i29K5yelc5vauc3lVO7yqnd5XRt8rpXX4ENgAAgEwJ bAAAAJmqqcCWUorbbrstBg8eHEOGDIk77rgjUkrVLgsAAKAiNRXYFi9eHM8880z8/e9/j7Vr18ZT Tz0Vjz76aLXLAgAAqEhNBbZf/OIXcc8998SwYcNi2LBhcc8998TPf/7zapcFAABQkUKqoTWDAwcO jC1btsSAAQMiImLPnj1x9tlnR1NTU9HtCoWCpZMV0rvK6V3l9K5yelc5vauc3lVO7yqjb5XTu647 2T2rqcDWq1evOHToUPzXf71z4vDw4cPRu3fvaGlpKbqdry8FAAAqdTIjVd1J23MV9O/fP/7973+3 nmHbu3dvnH766SW3q6HMCgAA1JCa+gzb2LFj4y9/+Uvr5RdffDHGjh1bxYoAAAAqV1OBbebMmbFg wYJ4/fXX4/XXX48FCxbEl770pWqXBQAAUJGaWhI5Z86cePXVV1vPqs2ZMyduvvnmKlcFAABQmZr6 0hEAAIBaUlNLIgEAAGqJwAYAAJApgQ0AACBTAhsAAECmBDYAAIBMCWwAAACZEtgAAAAyJbD9R6FQ aP2hfMuWLYvx48dHQ0NDDB06NG644YbYvn17tcvqVnbu3BkjR4409rpg06ZNccUVV0S/fv2iX79+ ccUVV8SmTZuqXVaWSs1tL7/8cnz2s5+N/v37x/Dhw+OnP/3pKa4wT0uXLo1PfvKT0bdv3xg6dGhM mzYttm7d2nq7ua+4csaVue8dxV6jpcZZT54LS/WmbV87629Pnf/K6c3xjEtOPIHtP1JK4f8Q77pF ixbF/PnzY8eOHbF+/foYOHBgTJ8+vdpldSt33XVXfOUrX6l2Gd3K1KlT42Mf+1hs3bo1tm7dGpdc cklMmzat2mVlqdjctmnTpvjCF74Qc+bMie3bt8eqVavi2WefPcUV5um73/1uzJ07NxobG+O1116L Cy64IK699trW2819nSt3XJn73lHsNVpqnPXkubCc1+CR3nbU454+/xXrTdvbO2L+O/UKSUo5SqFQ ENyOQ3NzcwwZMiQOHDhQ7VK6hfXr18ekSZNi7dq10dDQYOyVqaGhIXbv3h19+vSJiIgDBw7EkCFD orm5ucqV5aujuW3GjBkxYcKEuOmmm6pUVfexf//+GDJkSOzfv7/D28197ypnXJn7jlXO+4/248xc +K72vSnVz548/3XlvW4l45ITzxk2Tqjly5fHpZdeWu0yuo358+fHwoULo2/fvtUupVuZOHFiPPDA A7Fnz57YvXt33H///fH5z3++2mV1O08++WQ0NjbGsGHDol+/fnHddddFU1NTtcvKzr59++Khhx6K 8ePHd3ofc9+7yhlX5r7KtB9n5sJ3dfQaHDp0aPTu3TvOO++8uO++++Ltt99uva2nz3/FetNV5r9T IHEULanc6tWr0+jRo9PGjRurXUq38Pvf/z5dfPHF6fDhwyklY68r/vWvf6VRo0aliEgRkUaNGpW2 bt1a7bKy1tH46tWrV7r55pvTrl270q5du9KsWbPS1KlTq1Bdvo6MsTPPPDO98sorHd7H3He0UuPK 3NexUn3oaJyZC99R7DXY0tKSXn755TRu3Lg0d+7c1uvNf533pq1KxiUnnlmyHb84KvOHP/whjRw5 Mj3//PPVLqXbuOCCC9LKlStbLxt75ZswYUK68847U1NTU2pqakoLFixIEyZMqHZZWetofA0YMCC9 +eabrZd37dqV+vfvfyrL6hb27NmTFi5cmD7+8Y8fc5u571ilxpW5r2PF+tDZODMXlv8afOONN9Kg QYNaL5v/3tW+N21VMi458cyS7fjF0XVLlixJw4YNSy+88EK1S+lWjvxFtP0PpfXp0ycdOHCg9fL+ /ftTnz59qlhR/joaW5dffvkxb1hOP/30U1lWt9Hc3HzMGDP3dazUuDL3dayzHhQbZz19LuzKa3Db tm1pwIABrZfNf+9q35u2KhmXnHg+w8ZxWbRoUXzjG9+IJ554Ij7ykY9Uu5xuJXXwDU3JB+/L8sEP fjDuu+++2L17d+zevTvuvffeOP/886tdVrdz4403xvz586OpqSmamprilltuiYkTJ1a7rCzMnDkz 1q9fHy0tLdHY2BgLFiw46jMa5r7OlRpX5r7ylRpnPXkuLNWb6dOnx9q1a6OlpSU2b94cN954Y0yZ MqX19p48/5XqTSnmvyqoVlLMTfhrX0U66ltEpL1791a7tG7HmCvfunXr0rhx41JDQ0NqaGhIn/70 p9OGDRuqXVaWSs1t3/zmN9N73vOedNppp6UpU6Yc9Rfnnuyxxx5LF154Yaqrq0tnnnlmmjVrVtq2 bVvr7ea+4royrnr63FfsNVpqnPXkubBUb9q+hocPH57mzZuXmpubj9pHT53/yunN8YxLTjxf6w8A AJApSyIBAAAyJbABAABkSmADAADIlMAGAACQKYENAAAgUwIbAABApgQ2AACATAlsAAAAmRLYAAAA MiWwAQAAZEpgAwAAyJTABgAAkCmBDQAAIFMCGwCdevrpp2PkyJFRKBSqXQoA9EgCGwCd+vrXvx4P P/xwpJRO6eNWIyAKpQDkSGADyEyhUOj051Rbs2ZNfO5znzuh+9yzZ0/MnTs3Ro8eHfX19TFkyJCY PHlyrFixovU+pzogHs9jlnO8NmzYEF/84hdj6NCh0adPn7jooovi17/+dYf7GDRoUFx33XWxY8eO Th+znB52R0IzwLEENoDMpJRafzq6fCodOHAg6uvrT+g+p06dGocOHYonn3wyDhw4EBs3bowZM2bE 3XfffUIf51QpdbxeeeWVGDduXEyYMCE2bdoUb731Vjz88MOxZMmSDvezadOm6NOnT8yZM6fTx6y1 HgJQRAIgW+2n6YhIixYtSiNGjEiFQiGllNLmzZvTpEmTUv/+/VOfPn3SlVdembZt23bUNj/+8Y/T qFGjUn19ffrQhz6UVq9e3Xr70qVL09ixY1N9fX0aNWpU+slPftK6XduflFJqaWlJt99+ezrjjDNS Q0NDmjp1anrrrbeK1tde79690969e8t+3u3raHtbqXo6e27lPGaxnpWzjyNmzJiRvve973Vpu127 dqV+/fp1ev9yeliqN83NzWnmzJnptNNOS2eddVZ64IEHjunBI488kkaPHp169+6dxo4dm1auXJl+ 9rOfpTFjxrT25W9/+1vZj1msr50d464cQ4Ba5AwbQDfz/PPPx0svvRSHDx+OiIhJkybF3LlzY/v2 7bFt27Y477zz4pZbbjlqm6eeeir++Mc/RlNTU1xzzTUxe/bs1ttmzpwZ3/72t2Pv3r3xzDPPxJ/+ 9KeIiGPOGEVE3HvvvfHiiy/GSy+9FNu2bYuGhoa47bbbitbX3mWXXRazZ8+OVatWxf79+0s+39Tm jNXixYtj4sSJrbeVqqez51aOYj3rihUrVsTUqVO7tE2ppYHl9LBUb+68887Ys2dPvPbaa7FmzZp4 9tlnj9nHE088EU8//XQ0NTXFjBkz4qqrroqlS5fGihUrYvfu3XHttdce1Zdyxkdnfe1ovEUc3zEE qAlVi4oAlNR+mo6ItHXr1qLb7Nu3L51xxhlHbbNr166jbq+rq2u9/P73vz/98Ic/TFu2bCn5+KNG jUobNmxovdzY2JjOOuusLtXX1NSUbr/99jR27NjUt2/fNHLkyPS1r30tvfnmm50+bkopLV++PH34 wx8+6oxNqXqKPbdiz7VUz8rZxxF1dXXp0KFDZW+3ffv2NGvWrHT11Vd3ev9yeliqN8OHD0+bN29u vfzKK68c04OdO3e2Xt63b1+H17XtSznjo1hfO+pfV44hQC0qpFSFD0UAUJZCoXDU2Yb2lyMinnvu ubjtttti9erVsW/fvtb7HTnD1dE2ba974YUX4u67747nnnsuBg4cGN///vdj0qRJHW5bX18fLS0t x+yr2GMVk1KKjRs3xoMPPhivvfZaLF++vMP9rFu3LiZPnhzLly+PUaNGlV1PsefWXtvHLNWzznR0 n/e+972xevXqeN/73ld0uyMGDBgQn/nMZ+JHP/pRnHXWWUUfL6LzHpbqTV1dXRw8eDB69eoVEREt LS1RX1/f5R60va6S8VGq7105hgC1SGADyFg5gW3EiBHx4IMPxpVXXhkDBgyIvXv3xsCBA7v8xjul FL/73e/i5ptvjjfeeKPD+40cOTJWrVoVw4cPL6vecjU3N8fgwYPj4MGDx+xn+/bt8YlPfCIeffTR uOyyy47arlQ9xZ5bsdpPZGC7/vrr45JLLomvfvWrXdquq9r3sFRvhg8fHitXroxzzjknIiL+8Y9/ xJgxY44rsFUyPkr1/YhyjiFALfIZNoBubv/+/dG3b9/o27dv/POf/+zyZ62mT58e69ati0OHDkVK 6ZgzJG19+ctfjtmzZ8fmzZujpaUl1qxZE9OmTevS433qU5+Kxx57LLZt2xZvv/12bNmyJW6//fb4 6Ec/2uH9r7766rjjjjuOCWvl1NOV53ayfOtb34r7778/Fi9eHG+++WYcPHgw/vznP8eUKVMq3mc5 PSzVm2nTpsWtt94aO3fujJ07dx7zucdKHO/4GDRoUGzcuPGo63I4hgBVdaLXWAJw4rSfpjuatn/7 29+mc845J/Xq1SuNHDky/eAHPzjms0jF9vvLX/4ynXfeeamuri6NHTs2LVu2rNNt33777XTvvfe2 fsvf+eefn5YsWVL0sdpbsWJFuuaaa9LgwYNTr1690ogRI9JNN92UGhsbO9xPFPmWyFL1FHtuxXpS qmfl7KOtdevWpWuuuSYNGjQo9e7dO1100UXp8ccf79K+2yqnh6V6s2/fvnTDDTekhoaGdOaZZ6Z7 7rkn1dfXF62p1HWVjI+2133nO99J/fv3L3t8AvQElkQCALFhw4a46qqr4tVXX612KQC0YUkkAPRQ 8+bNi6ampmhsbIxbb701Jk+eXO2SAGhHYAOAHurss8+Oc889N8aMGRODBg2KhQsXVrskANqxJBIA ACBTdbt3Nla7BgAAADpgSSQAAECm6o7846Ef/U816wAAAOA/7rrrrti9s/HdwBYR8bX/nlOtegAA AGjHkkgAAIBMCWwAAACZEtgAAAAyJbABAABkSmADAADIlMAGAACQKYENAAAgUwIbAABApgQ2AACA DDz2v/8Xg97z3qOuE9gAAAAyMHv27GOuq6tCHQAAALSze2fjMdc5wwYAAFAlbZdBWhIJAACQkbbL IC2JBAAAyEjbZZCWRAIAAFRZZ8sgLYkEAACoss6WQVoSCQAAUGWdLYO0JBIAAKAKylkGaUkkAABA FZSzDLLkksj2aQ4AAIATp23mKuffhaYdb6RTUxoAAABd8f/NT+6Q0+o4gwAAAABJRU5ErkJggg== --000e0cd31074605638049430ee35-- From rs@netapp.com Thu Nov 4 17:29:50 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5214A28C0DB for ; Thu, 4 Nov 2010 17:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcrFY9keh86k for ; Thu, 4 Nov 2010 17:29:49 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id A52D43A6A61 for ; Thu, 4 Nov 2010 17:29:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,299,1286175600"; d="scan'208,217";a="224922041" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 04 Nov 2010 17:29:46 -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 oA50Tkxe005754 for ; Thu, 4 Nov 2010 17:29:46 -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); Fri, 5 Nov 2010 01:29:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7C80.8C2ED442" Date: Fri, 5 Nov 2010 00:29:45 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B41E46D@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TS & SACK Thread-Index: Act8YSg7EGfNTDWRRTi7JSTzkC4EjA== From: "Scheffenegger, Richard" To: X-OriginalArrivalTime: 05 Nov 2010 00:29:46.0411 (UTC) FILETIME=[8C71AFB0:01CB7C80] Subject: [tcpm] TS & SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 00:29:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7C80.8C2ED442 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi group, I would like to learn your thoughts revolving around the following though - and I admit, that most likely, there are some angels that I haven't looked at yet: According to RFC1323: Sender: TSecr is to be ignored for RTTM purposes, if the ACK carrying it cumulatively acks some new data. Receiver: Section 3.4 defines, which TS the receiver should echo. Especially case B is very important, if no further information is available. Overall, this section 3.4 seems to again specify, that the receiver should only echo the TS of the data segment, that lead to an cumulative ack of new data (except for delayed ACKs, where the TS of the first new data segment is to be used). It appears to me, that with the exception of rule 3.4 / A, talking about the delayed ack case, the cases B and C are redundant with what a sender can use for RTTM (PAWS) anyway. Now, since 3.3 (sender RTTM calculation) and 3.4/B | 3.4/C seem to be redundant, having a SACK-enabled TCP receiver to continue to reflect back the TS of the last received (and newly SACKed) data segment should not have a detrimential effect (proper implementations assumed).=20 The upside of having the TS is to gain more insight into the state of the network, as the combination of SACK + TS information can reveal exactly, if reordering or loss exists in the network, allowing a TCP sender a more targeted response during SACK loss recovery. (Some of this is also possible by using DSACK, of course). The basic idea (brought up by D. Damjanovic in a discussion) is to know more which segment is newly SACKed - with TS delivering the necessary tag - so that spurious retransmissions can be avoided, while lost retransmissions can be detected at the earliest possibility. If a TCP receiver doesn't reflect the TS option on ACK+SACKs, a TCP sender making use of this scheme would revert to the current scheme used by Linux to recover lost retransmissions (which requires a cumulative ACK beyond RP, and incidentially carries a new TSecr). Is the above assesment, that the two sections 3.3 and 3.4 are largely redundant in RFC1323, correct? Or did I skip some important line, that explains why it's defined that way (w/ redundancy). Thanks a lot, =20 Richard Scheffenegger ------_=_NextPart_001_01CB7C80.8C2ED442 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TS & SACK

 Hi = group,


I would like to = learn your thoughts revolving around the following though - and I admit, = that most likely, there are some angels that I haven't looked at = yet:

According to = RFC1323:

Sender:
TSecr is to be = ignored for RTTM purposes, if the ACK carrying it cumulatively acks some = new data.
Receiver:

Section 3.4 = defines, which TS the receiver should echo. Especially case B is very = important, if no further information is available. Overall, this section = 3.4 seems to again specify, that the receiver should only echo the TS of = the data segment, that lead to an cumulative ack of new data (except for = delayed ACKs, where the TS of the first new data segment is to be = used).

It appears to me, = that with the exception of rule 3.4 / A, talking about the delayed ack = case, the cases B and C are redundant with what a sender can use for = RTTM (PAWS) anyway.



Now, since 3.3 = (sender RTTM calculation) and 3.4/B | 3.4/C seem to be redundant, having = a SACK-enabled TCP receiver to continue to reflect back the TS of the = last received (and newly SACKed) data segment should not have a = detrimential effect (proper implementations assumed).

The upside of = having the TS is to gain more insight into the state of the network, as = the combination of SACK + TS information can reveal exactly, if = reordering or loss exists in the network, allowing a TCP sender a more = targeted response during SACK loss recovery. (Some of this is also = possible by using DSACK, of course).

The basic idea = (brought up by D. Damjanovic in a discussion) is to know more which = segment is newly SACKed - with TS delivering the necessary tag - so that = spurious retransmissions can be avoided, while lost retransmissions can = be detected at the earliest possibility.

If a TCP receiver = doesn't reflect the TS option on ACK+SACKs, a TCP sender making use of = this scheme would revert to the current scheme used by Linux to recover = lost retransmissions (which requires a cumulative ACK beyond RP, and = incidentially carries a new TSecr).



Is the above = assesment, that the two sections 3.3 and 3.4 are largely redundant in = RFC1323, correct? Or did I skip some important line, that explains why = it's defined that way (w/ redundancy).

Thanks a = lot,
 

Richard = Scheffenegger

------_=_NextPart_001_01CB7C80.8C2ED442-- From alexander.zimmermann@comsys.rwth-aachen.de Fri Nov 5 01:37:43 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFCEF3A691A for ; Fri, 5 Nov 2010 01:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DGWbGzvLPJn for ; Fri, 5 Nov 2010 01:37:42 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id F11C03A6916 for ; Fri, 5 Nov 2010 01:37:41 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LBE004CELB5XGE0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Fri, 05 Nov 2010 09:37:53 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.58,301,1286143200"; d="sig'?scan'208,217";a="79888122" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 05 Nov 2010 09:37:53 +0100 Received: from [137.226.12.58] ([unknown] [137.226.12.58]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LBE00GKWLB5ZD70@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Fri, 05 Nov 2010 09:37:53 +0100 (CET) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-8--746052958 From: Alexander Zimmermann In-reply-to: <5FDC413D5FA246468C200652D63E627A0B41E46D@LDCMVEXC1-PRD.hq.netapp.com> Date: Fri, 05 Nov 2010 09:37:55 +0100 Message-id: References: <5FDC413D5FA246468C200652D63E627A0B41E46D@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" Content-transfer-encoding: 7bit X-Pgp-Agent: GPGMail 1.3.0 X-Mailer: Apple Mail (2.1081) Cc: tcpm@ietf.org Subject: Re: [tcpm] TS & SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 08:37:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-8--746052958 Content-Type: multipart/alternative; boundary=Apple-Mail-7--746052987 --Apple-Mail-7--746052987 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Richard, just my 2cents... Am 05.11.2010 um 01:29 schrieb Scheffenegger, Richard: > Hi group, >=20 >=20 > I would like to learn your thoughts revolving around the following = though - and I admit, that most likely, there are some angels that I = haven't looked at yet: >=20 > According to RFC1323: >=20 You know that Section 3.4 of RFC1323 is wrong and that an update exists: http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-1323bis/ > Sender:=20 > TSecr is to be ignored for RTTM purposes, if the ACK carrying it = cumulatively acks some new data.=20 > Receiver: >=20 I'm sure you mean the opposite... Copied from Section 3.3 A TSecr value received in a segment is used to update the averaged RTT = measurement only if the segment acknowledges some new data, i.e., only if it = advances the left edge of the send window. > Section 3.4 defines, which TS the receiver should echo. Especially = case B is very important, if no further information is available. = Overall, this section 3.4 seems to again specify, that the receiver = should only echo the TS of the data segment, that lead to an cumulative = ack of new data (except for delayed ACKs, where the TS of the first new = data segment is to be used). >=20 > It appears to me, that with the exception of rule 3.4 / A, talking = about the delayed ack case, the cases B and C are redundant with what a = sender can use for RTTM (PAWS) anyway. >=20 I don't think that cases b and c are redundant. In my point of view case = b explains why we should "artificially inflate" the RTT, while case c explains why we can stop = with this and can each back the "real" value. Moreover, all 3 cases are only explanations, the real = algorithm comes later (steps 1, 2, 3) >=20 > Now, since 3.3 (sender RTTM calculation) and 3.4/B | 3.4/C seem to be = redundant, having a SACK-enabled TCP receiver to continue to reflect = back the TS of the last received (and newly SACKed) data segment should = not have a detrimential effect (proper implementations assumed). >=20 > The upside of having the TS is to gain more insight into the state of = the network, as the combination of SACK + TS information can reveal = exactly, if reordering or loss exists in the network, allowing a TCP = sender a more targeted response during SACK loss recovery. (Some of this = is also possible by using DSACK, of course). >=20 > The basic idea (brought up by D. Damjanovic in a discussion) is to = know more which segment is newly SACKed - with TS delivering the = necessary tag - so that spurious retransmissions can be avoided, while = lost retransmissions can be detected at the earliest possibility. >=20 > If a TCP receiver doesn't reflect the TS option on ACK+SACKs, a TCP = sender making use of this scheme would revert to the current scheme used = by Linux to recover lost retransmissions (which requires a cumulative = ACK beyond RP, and incidentially carries a new TSecr). >=20 >=20 >=20 > Is the above assesment, that the two sections 3.3 and 3.4 are largely = redundant in RFC1323, correct? Or did I skip some important line, that = explains why it's defined that way (w/ redundancy). >=20 > Thanks a lot,=20 > =20 >=20 > Richard Scheffenegger >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-7--746052987 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Richard,

just my = 2cents...

Am 05.11.2010 um 01:29 schrieb = Scheffenegger, Richard:

 Hi group,


I would like = to learn your thoughts revolving around the following though - and I = admit, that most likely, there are some angels that I haven't looked at = yet:

According to RFC1323:


You know that Section 3.4 of = RFC1323 is wrong and that an update exists:

Sender:
TSecr is to be = ignored for RTTM purposes, if the ACK carrying it cumulatively acks some = new data.
Receiver:

I'm = sure you mean the opposite...

Copied from = Section 3.3

A TSecr value received in a segment = is used to update the averaged RTT measurement
only if the = segment acknowledges some new data, i.e., only if it advances the = left edge of
the send window.

Section 3.4 defines, which TS the receiver should echo. = Especially case B is very important, if no further information is = available. Overall, this section 3.4 seems to again specify, that the = receiver should only echo the TS of the data segment, that lead to an = cumulative ack of new data (except for delayed ACKs, where the TS of the = first new data segment is to be used).

It appears to me, that = with the exception of rule 3.4 / A, talking about the delayed ack case, = the cases B and C are redundant with what a sender can use for RTTM = (PAWS) anyway.

I don't think = that cases b and c are redundant. In my point of view case b explains = why we should
"artificially inflate" the RTT, while case c explains = why we can stop with this and can each back
the "real" = value. Moreover, all 3 cases are only explanations, the real = algorithm comes later
(steps 1, 2, = 3)


Now, since = 3.3 (sender RTTM calculation) and 3.4/B | 3.4/C seem to be redundant, = having a SACK-enabled TCP receiver to continue to reflect back the TS of = the last received (and newly SACKed) data segment should not have a = detrimential effect (proper implementations assumed). =

The upside of having the TS is to gain more insight into = the state of the network, as the combination of SACK + TS information = can reveal exactly, if reordering or loss exists in the network, = allowing a TCP sender a more targeted response during SACK loss = recovery. (Some of this is also possible by using DSACK, of = course).

The basic idea (brought up by D. Damjanovic in a = discussion) is to know more which segment is newly SACKed - with TS = delivering the necessary tag - so that spurious retransmissions can be = avoided, while lost retransmissions can be detected at the earliest = possibility.

If a TCP receiver doesn't reflect the TS option on = ACK+SACKs, a TCP sender making use of this scheme would revert to the = current scheme used by Linux to recover lost retransmissions (which = requires a cumulative ACK beyond RP, and incidentially carries a new = TSecr).



Is the above = assesment, that the two sections 3.3 and 3.4 are largely redundant in = RFC1323, correct? Or did I skip some important line, that explains why = it's defined that way (w/ redundancy).

Thanks a = lot,
 

Richard = Scheffenegger

_______________________________________________
tcpm mailing = list
tcpm@ietf.org
https://www.ietf.org/m= ailman/listinfo/tcpm

//
// Dipl.-Inform. Alexander = Zimmermann
// Department of Computer Science, Informatik = 4
// Ahornstr. 55, 52056 Aachen, = Germany
// phone: (49-241) 80-21422, fax: (49-241) = 80-22222
X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm-chairs@tools.ietf.org" , Joe Touch Subject: [tcpm] Revised version of draft-ietf-tcpm-tcp-timestamps X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 16:00:48 -0000 Folks, I have produced a revised version of the aforementioned document, which I think and hope addresses the WGLC comments sent by Joe Touch, John Heffner, and Wesley Eddy. Since I cannot post it at the IETF repository (we're past the draft submission cut-off), meanwhile I have posted the I-D on my web site: http://www.gont.com.ar/drafts/tcp-timestamps/draft-ietf-tcpm-tcp-timestamps-01.txt Please let me know if this version addresses the issues that you had raised during the WGLC, and if you think some remain to be addressed, please specific which ones, and suggest how to address them. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rs@netapp.com Fri Nov 5 14:15:59 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D863A67A3 for ; Fri, 5 Nov 2010 14:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCg0vlemvUtL for ; Fri, 5 Nov 2010 14:15:57 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 743033A6951 for ; Fri, 5 Nov 2010 14:15:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,305,1286175600"; d="scan'208,217";a="217936617" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 05 Nov 2010 14:16:08 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oA5LG8NE015799; Fri, 5 Nov 2010 14:16:08 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Nov 2010 21:16:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7D2E.A9DE7F66" Date: Fri, 5 Nov 2010 21:16:08 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B41E905@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TS & SACK Thread-Index: Act8xL90I0x2BmXMQHuNmrhwtTk4igAZNTsw References: <5FDC413D5FA246468C200652D63E627A0B41E46D@LDCMVEXC1-PRD.hq.netapp.com> From: "Scheffenegger, Richard" To: "Alexander Zimmermann" X-OriginalArrivalTime: 05 Nov 2010 21:16:08.0759 (UTC) FILETIME=[AA326C70:01CB7D2E] Cc: tcpm@ietf.org Subject: Re: [tcpm] TS & SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2010 21:15:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7D2E.A9DE7F66 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi Alexander, ________________________________ From: Alexander Zimmermann [mailto:alexander.zimmermann@comsys.rwth-aachen.de]=20 Sent: Freitag, 05. November 2010 09:38 To: Scheffenegger, Richard Cc: tcpm@ietf.org Subject: Re: [tcpm] TS & SACK =09 =09 Hi Richard,=20 =09 =09 just my 2cents... =09 =09 Am 05.11.2010 um 01:29 schrieb Scheffenegger, Richard: Hi group,=20 I would like to learn your thoughts revolving around the following though - and I admit, that most likely, there are some angels that I haven't looked at yet: According to RFC1323:=20 =09 =09 You know that Section 3.4 of RFC1323 is wrong and that an update exists: http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-1323bis/=20 =20 =09 =20 Thanks for the hint with the revised version!=20 Sender:=20 TSecr is to be ignored for RTTM purposes, if the ACK carrying it cumulatively acks some new data.=20 Receiver: I'm sure you mean the opposite... =09 =09 Copied from Section 3.3 =09 =09 A TSecr value received in a segment is used to update the averaged RTT measurement only if the segment acknowledges some new data, i.e., only if it advances the left edge of the send window.=20 =20 =20 certainly, i did some editing and forgot to proof-read before i hit send. Section 3.4 defines, which TS the receiver should echo. Especially case B is very important, if no further information is available. Overall, this section 3.4 seems to again specify, that the receiver should only echo the TS of the data segment, that lead to an cumulative ack of new data (except for delayed ACKs, where the TS of the first new data segment is to be used). It appears to me, that with the exception of rule 3.4 / A, talking about the delayed ack case, the cases B and C are redundant with what a sender can use for RTTM (PAWS) anyway. I don't think that cases b and c are redundant. In my point of view case b explains why we should "artificially inflate" the RTT, while case c explains why we can stop with this and can each back the "real" value. Moreover, all 3 cases are only explanations, the real algorithm comes later (steps 1, 2, 3)=20 =20 Well, redundant in the sense, that the sender will ignore any timestamp as per section 3.3 rule, as long as no new data is cumulatively acked.=20 =20 For point B, if the sender ignores the TS anyway (section 3.3), there is no point in reporting an inflated RTT. (The TS of the ACK for an out-of-order segment is to be ignored - for RTTM -, as it doesn't advance the left edge of the window, correct?). For all a RFC1323(bis) sender cares, the timestamp could be any number, which only fullfils the PAWS requirements, but has no further RTTM function. =20 For point C, the ACK advances, and the RTTM should be updated with a reasonable RTTM estimate, that is not artifically inflated, thus the TS of the data segment which filled the (leftmost?) hole. Or does point C also apply when a hole further right (thus not advancing cumulative ACK) is filled? (Per 3.3, that TS should be ignored again; but point C is IMHO ambigious here). =20 =20 =20 So, my question is this: As a sender should ignore a TS for RTTM purposes if the cumulative ACK is not advanced, why go though the hassle of defining point B in section 3.4 to that length?; and how is point C to be interpreted - any hole being filled, only the leftmost hole? (The pseudo-code (2) implicitly only allows for the leftmost hole :) ). =20 =20 Thanks for bearing with me! =20 Best regards, Richard=20 =20 =20 =09 =09 =09 Now, since 3.3 (sender RTTM calculation) and 3.4/B | 3.4/C seem to be redundant, having a SACK-enabled TCP receiver to continue to reflect back the TS of the last received (and newly SACKed) data segment should not have a detrimential effect (proper implementations assumed).=20 The upside of having the TS is to gain more insight into the state of the network, as the combination of SACK + TS information can reveal exactly, if reordering or loss exists in the network, allowing a TCP sender a more targeted response during SACK loss recovery. (Some of this is also possible by using DSACK, of course). The basic idea (brought up by D. Damjanovic in a discussion) is to know more which segment is newly SACKed - with TS delivering the necessary tag - so that spurious retransmissions can be avoided, while lost retransmissions can be detected at the earliest possibility. If a TCP receiver doesn't reflect the TS option on ACK+SACKs, a TCP sender making use of this scheme would revert to the current scheme used by Linux to recover lost retransmissions (which requires a cumulative ACK beyond RP, and incidentially carries a new TSecr). Is the above assesment, that the two sections 3.3 and 3.4 are largely redundant in RFC1323, correct? Or did I skip some important line, that explains why it's defined that way (w/ redundancy). Thanks a lot,=20 =20 Richard Scheffenegger =09 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm =09 =09 =09 =09 // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // ------_=_NextPart_001_01CB7D2E.A9DE7F66 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi Alexander,

From: Alexander Zimmermann=20 [mailto:alexander.zimmermann@comsys.rwth-aachen.de]
Sent: = Freitag,=20 05. November 2010 09:38
To: Scheffenegger, = Richard
Cc:=20 tcpm@ietf.org
Subject: Re: [tcpm] TS & = SACK

Hi Richard,

just my 2cents...

Am 05.11.2010 um 01:29 schrieb Scheffenegger, Richard:

 Hi = group,


I would like to = learn your=20 thoughts revolving around the following though - and I admit, that = most=20 likely, there are some angels that I haven't looked at=20 yet:

According to=20 RFC1323:


You know that Section 3.4 of RFC1323 is wrong and that an update=20 exists:
http://to= ols.ietf.org/wg/tcpm/draft-ietf-tcpm-1323bis/ 
 
 
Thanks for the hint with the revised=20 version! 

Sender:
TSecr is to be ignored for = RTTM purposes,=20 if the ACK carrying it cumulatively acks some new = data.=20
Receiver:

I'm sure you mean the opposite...

Copied from Section 3.3

A TSecr value received in a segment is used to update the = averaged RTT=20 measurement
only if the segment acknowledges some new data, i.e., only = if it=20 advances the left edge of
the send window. 
 
 
certainly, i did some editing and forgot to proof-read = before i=20 hit send.

Section 3.4 = defines, which TS=20 the receiver should echo. Especially case B is very important, if no = further=20 information is available. Overall, this section 3.4 seems to again = specify,=20 that the receiver should only echo the TS of the data segment, that = lead to=20 an cumulative ack of new data (except for delayed ACKs, where the TS = of the=20 first new data segment is to be used).

It appears to me, = that with the=20 exception of rule 3.4 / A, talking about the delayed ack case, the = cases B=20 and C are redundant with what a sender can use for RTTM (PAWS)=20 anyway.

I don't think that cases b and c are redundant. In my point of = view case=20 b explains why we should
"artificially inflate" the RTT, while case = c=20 explains why we can stop with this and can each back
the "real"=20 value. Moreover, all 3 cases are only explanations, the real = algorithm=20 comes later
(steps 1, 2, 3) 
 
Well,=20 redundant in the sense, that the sender will ignore any timestamp as per = section=20 3.3 rule, as long as no new data is cumulatively acked.=20
 
For=20 point B, if the sender ignores the TS anyway (section 3.3),=20 there is no point in reporting an inflated RTT. (The TS of the = ACK for=20 an out-of-order segment is to be ignored - for RTTM -, as = it doesn't=20 advance the left edge of the window, correct?). For all a RFC1323(bis) sender = cares, the=20 timestamp could be any number, which only fullfils the PAWS = requirements, but=20 has no further RTTM function.
 
For=20 point C, the ACK advances, and the RTTM should be updated with a = reasonable RTTM=20 estimate, that is not artifically inflated, thus the TS of the data = segment=20 which filled the (leftmost?) hole. Or does point C also apply when a = hole=20 further right (thus not advancing cumulative ACK) is filled? (Per 3.3, = that TS=20 should be ignored again; but point C is IMHO ambigious=20 here).
 
 
 
So, my=20 question is this: As a sender should ignore a TS for RTTM purposes if = the=20 cumulative ACK is not advanced, why go though the hassle of defining = point B in=20 section 3.4 to that length?; and how is point C to be interpreted - any = hole=20 being filled, only the leftmost hole? (The pseudo-code = (2) implicitly only=20 allows for the leftmost hole :) ).
 
 
Thanks=20 for bearing with me!
 
Best=20 regards,
   Richard
 
 


Now, since 3.3 = (sender RTTM=20 calculation) and 3.4/B | 3.4/C seem to be redundant, having a = SACK-enabled=20 TCP receiver to continue to reflect back the TS of the last received = (and=20 newly SACKed) data segment should not have a detrimential effect = (proper=20 implementations assumed).

The upside of = having the TS is=20 to gain more insight into the state of the network, as the = combination of=20 SACK + TS information can reveal exactly, if reordering or loss = exists in=20 the network, allowing a TCP sender a more targeted response during = SACK loss=20 recovery. (Some of this is also possible by using DSACK, of=20 course).

The basic idea = (brought up by D.=20 Damjanovic in a discussion) is to know more which segment is newly = SACKed -=20 with TS delivering the necessary tag - so that spurious = retransmissions can=20 be avoided, while lost retransmissions can be detected at the = earliest=20 possibility.

If a TCP receiver = doesn't=20 reflect the TS option on ACK+SACKs, a TCP sender making use of this = scheme=20 would revert to the current scheme used by Linux to recover lost=20 retransmissions (which requires a cumulative ACK beyond RP, and=20 incidentially carries a new TSecr).



Is the above = assesment, that the=20 two sections 3.3 and 3.4 are largely redundant in RFC1323, correct? = Or did I=20 skip some important line, that explains why it's defined that way = (w/=20 redundancy).

Thanks a = lot,=20
 

Richard=20 Scheffenegger

__________________________________________= _____
tcpm=20 mailing list
tcpm@ietf.org
https://www.ietf.org/= mailman/listinfo/tcpm

//
// Dipl.-Inform. = Alexander=20 Zimmermann
// Department of = Computer=20 Science, Informatik 4
// RWTH Aachen = University
// Ahornstr. 55, = 52056 Aachen,=20 Germany
// phone: (49-241) = 80-21422,=20 fax: (49-241) 80-22222
// email: zimmermann@cs.rwth-aachen.de=
// web: http://www.umic-mesh.net
//
------_=_NextPart_001_01CB7D2E.A9DE7F66-- From fernando.gont.netbook.win@gmail.com Sat Nov 6 09:41:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3223A689A for ; Sat, 6 Nov 2010 09:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZqmKdKwqCs7 for ; Sat, 6 Nov 2010 09:41:00 -0700 (PDT) Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.214.194]) by core3.amsl.com (Postfix) with ESMTP id 3D5683A6878 for ; Sat, 6 Nov 2010 09:41:00 -0700 (PDT) Received: by iwn35 with SMTP id 35so1177765iwn.1 for ; Sat, 06 Nov 2010 09:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=pcA75St4O72tKql+b3yX3pgVPq1ltCDPLRYMvvZjwjw=; b=b03udQZJDQkOuLZqlpT6VQOPSNUlhy4nDRW7E+fhEa5LOreshiRp2foFWfBoMpZuWP 6pAOW8owuE683fRBz4S4cyyUuiE8+b2jaywnRomp8zXUHuY8/999wDI9PJyBxTXTPalI HUIu3eDdTm+2bBksSA0cQc5y29xv4pJ4s7sTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=fdvLBHSKMB+74TnvfuQ5HYkbAO27y33+WArfrbZARtPc0XIgMjv3lW2B2b7R42c6XN vWM95GDCUBJAKuSQfhEBEFYCbHw/HtfbEiccXIyJFYm/euXB9/TjOrtH0lFBx7TS1K5W VIG72nH9EbGzRUeb/vQT/0z1/pEvMpyGcglxs= Received: by 10.231.167.70 with SMTP id p6mr2648162iby.100.1289061665965; Sat, 06 Nov 2010 09:41:05 -0700 (PDT) Received: from [222.128.202.193] ([222.128.202.193]) by mx.google.com with ESMTPS id i16sm1130919ibl.6.2010.11.06.09.41.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Nov 2010 09:41:03 -0700 (PDT) Sender: Fernando Gont Message-ID: <4CD5851F.9040702@gont.com.ar> Date: Sat, 06 Nov 2010 13:41:03 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Fernando Gont References: <4CD42A2F.9060509@gont.com.ar> In-Reply-To: <4CD42A2F.9060509@gont.com.ar> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] Revised version of draft-ietf-tcpm-tcp-timestamps X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 16:41:03 -0000 Folks, BTW, if you get a "403" error message while trying to access the draft from my web site, that's probably because you're using wget (*). Please try a different browser or use the "user-agent" option to "forge" a different "User-agent" tag. e.g., wget --user-agent='Mozilla/4.0 (compatible; MSIE 5.5; OMG MB; Windows 98)' http://www.gont.com.ar/drafts/tcp-timestamps/draft-ietf-tcpm-tcp-timestamps-01.txt (*) My web-hosting provider is currently blocking "wget" for stupid reasons. (and yes, I'm in the process of switching to another hosting provider). Thanks, and apologizes, Fernando > Folks, > > I have produced a revised version of the aforementioned document, which > I think and hope addresses the WGLC comments sent by Joe Touch, John > Heffner, and Wesley Eddy. > > Since I cannot post it at the IETF repository (we're past the draft > submission cut-off), meanwhile I have posted the I-D on my web site: > http://www.gont.com.ar/drafts/tcp-timestamps/draft-ietf-tcpm-tcp-timestamps-01.txt > > Please let me know if this version addresses the issues that you had > raised during the WGLC, and if you think some remain to be addressed, > please specific which ones, and suggest how to address them. > > Thanks! > > Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From david.borman@windriver.com Sun Nov 7 06:20:20 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67DF53A63EC for ; Sun, 7 Nov 2010 06:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.39 X-Spam-Level: X-Spam-Status: No, score=-103.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjYE95h28jVR for ; Sun, 7 Nov 2010 06:20:19 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 5A7DD3A6403 for ; Sun, 7 Nov 2010 06:20:19 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id oA7EKYNC029375; Sun, 7 Nov 2010 06:20:34 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Nov 2010 06:20:33 -0800 Received: from [172.31.18.89] ([147.11.69.4]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Nov 2010 06:20:33 -0800 From: David Borman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Nov 2010 22:20:28 +0800 Message-Id: <78DB0ABC-24D1-41E1-BCC5-F70A950AD9C0@windriver.com> To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 07 Nov 2010 14:20:34.0359 (UTC) FILETIME=[F0F66C70:01CB7E86] Cc: Fernando Gont Subject: [tcpm] Side meeting to discuss TCP Security document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 14:20:20 -0000 In Anaheim we had a small session to look at the TCP Security document, = attended by a hand full of people. We are interested in doing this = again here in Beijing. The goal is to go through some more of the = document and come up with some recommendations for how to move forward = with revising/editing the document, which will then be brought back to = the list. So, there are 2 questions: 1) Who is interested in attending? 2) When should we meet? My recommendations for possibilities are, in = order of preference: 1) Tuesday morning (NFSv4 meets at this time) 2) Wednesday after lunch (No TSV groups meet at this time) 3) Thursday morning (Congestion Exposure WG meets at this time) Please reply to me or the list if you are interested in this, and if so, = which of those 3 periods you are available. Once we see who is = interested and when they would be available, I'll see about finding a = place to meet, but it won't be a regular session room, i.e. there won't = be any remote participation. -David Borman, TCPM co-chair= From alexander.zimmermann@comsys.rwth-aachen.de Mon Nov 8 10:56:28 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C6A3A682A for ; Mon, 8 Nov 2010 10:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.5 X-Spam-Level: X-Spam-Status: No, score=-4.5 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJIJCOgPeTQG for ; Mon, 8 Nov 2010 10:56:26 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id C12493A6800 for ; Mon, 8 Nov 2010 10:56:25 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LBK001J7XYMHJC0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 08 Nov 2010 19:56:46 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.59,169,1288566000"; d="sig'?scan'208,217";a="80281310" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 08 Nov 2010 19:56:47 +0100 Received: from [137.226.12.58] ([unknown] [137.226.12.58]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LBK00KCHXYM3X10@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 08 Nov 2010 19:56:46 +0100 (CET) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-25--449723251 From: Alexander Zimmermann In-reply-to: <5FDC413D5FA246468C200652D63E627A0B41E905@LDCMVEXC1-PRD.hq.netapp.com> Date: Mon, 08 Nov 2010 19:56:45 +0100 Message-id: <196C11B7-5685-4FA2-BE61-4B5B406492E0@comsys.rwth-aachen.de> References: <5FDC413D5FA246468C200652D63E627A0B41E46D@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0B41E905@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" Content-transfer-encoding: 7bit X-Pgp-Agent: GPGMail 1.3.0 X-Mailer: Apple Mail (2.1081) Cc: tcpm@ietf.org Subject: Re: [tcpm] TS & SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 18:56:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-25--449723251 Content-Type: multipart/alternative; boundary=Apple-Mail-24--449723294 --Apple-Mail-24--449723294 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 05.11.2010 um 22:16 schrieb Scheffenegger, Richard: >> Section 3.4 defines, which TS the receiver should echo. Especially = case B is very important, if no further information is available. = Overall, this section 3.4 seems to again specify, that the receiver = should only echo the TS of the data segment, that lead to an cumulative = ack of new data (except for delayed ACKs, where the TS of the first new = data segment is to be used). >>=20 >> It appears to me, that with the exception of rule 3.4 / A, talking = about the delayed ack case, the cases B and C are redundant with what a = sender can use for RTTM (PAWS) anyway. >>=20 > I don't think that cases b and c are redundant. In my point of view = case b explains why we should > "artificially inflate" the RTT, while case c explains why we can stop = with this and can each back > the "real" value. Moreover, all 3 cases are only explanations, the = real algorithm comes later > (steps 1, 2, 3)=20 > =20 > Well, redundant in the sense, that the sender will ignore any = timestamp as per section 3.3 rule, as long as no new data is = cumulatively acked. > =20 > For point B, if the sender ignores the TS anyway (section 3.3), there = is no point in reporting an inflated RTT. (The TS of the ACK for an = out-of-order segment is to be ignored - for RTTM -, as it doesn't = advance the left edge of the window, correct?). For all a RFC1323(bis) = sender cares, the timestamp could be any number, which only fullfils the = PAWS requirements, but has no further RTTM function. > =20 > For point C, the ACK advances, and the RTTM should be updated with a = reasonable RTTM estimate, that is not artifically inflated, thus the TS = of the data segment which filled the (leftmost?) hole. IMO leftmost. > Or does point C also apply when a hole further right (thus not = advancing cumulative ACK) is filled? IMO no. > (Per 3.3, that TS should be ignored again; but point C is IMHO = ambigious here). Yes, (maybe) it is ambiguous. RFC5681, Section 4.2. Generating = Acknowledgments, next-to-last paragraph has the same "hole-ambiguous-problem". But on the other hand, the problem is maybe that we have the = "SACK-Glass" on. Without SACK in mind, the wording is OK. (But can improved in 1323bis) > =20 > =20 > So, my question is this: As a sender should ignore a TS for RTTM = purposes if the cumulative ACK is not advanced, why go though the hassle = of defining point B in section 3.4 to that length?; Hmm, good question. I have to think about it. At first glance, your = reasoning sounds good and I cannot see a mistake. However, I have also the feeling that V. Jacobson is = cleverer that I... Did you take a look into the bible? (Stevens TCP/IP Illustrated) > and how is point C to be interpreted - any hole being filled, only the = leftmost hole? (The pseudo-code (2) implicitly only allows for the = leftmost hole :) ). > =20 > =20 > Thanks for bearing with me! > =20 > Best regards, > Richard > =20 // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-24--449723294 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Section = 3.4 defines, which TS=20 the receiver should echo. Especially case B is very important, if no = further=20 information is available. Overall, this section 3.4 seems to again = specify,=20 that the receiver should only echo the TS of the data segment, that = lead to=20 an cumulative ack of new data (except for delayed ACKs, where the TS = of the=20 first new data segment is to be used).

It appears to me, that = with the=20 exception of rule 3.4 / A, talking about the delayed ack case, the = cases B=20 and C are redundant with what a sender can use for RTTM (PAWS)=20 anyway.

I don't think that cases b and c are redundant. In my point of = view case=20 b explains why we should
"artificially inflate" the RTT, while case = c=20 explains why we can stop with this and can each back
the "real"=20 value. Moreover, all 3 cases are only explanations, the real = algorithm=20 comes later
(steps 1, 2, 3) 
 
=
Well,=20 redundant in the sense, that the sender will ignore any timestamp as per = section=20 3.3 rule, as long as no new data is cumulatively acked.=20
 
For=20 point B, if the sender ignores the TS = anyway (section 3.3),=20 there is no point in reporting an inflated RTT. (The TS of the = ACK for=20 an out-of-order segment is to be ignored - for RTTM -, as = it doesn't=20 advance the left edge of the window, correct?). For all a RFC1323(bis) = sender cares, the=20 timestamp could be any number, which only fullfils the PAWS = requirements, but=20 has no further RTTM function.
 
For=20 point C, the ACK advances, and the RTTM should be updated with a = reasonable RTTM=20 estimate, that is not artifically inflated, thus the TS of the data = segment=20 which filled the (leftmost?) = hole.

IMO = leftmost.

Or does point C also apply = when a hole=20 further right (thus not advancing cumulative ACK) is = filled?

IMO = no.

(Per 3.3, that TS=20 should be ignored again; but point C is IMHO ambigious=20 here).

Yes, = (maybe) it is ambiguous. RFC5681, Section 4.2. Generating = Acknowledgments, next-to-last paragraph has
the same = "hole-ambiguous-problem".

But on the other = hand, the problem is maybe that we have the "SACK-Glass" on. Without = SACK in mind, the wording
is OK. (But can improved in = 1323bis)

 
 
So, my=20 question is this: As a sender should ignore a TS for RTTM purposes if = the=20 cumulative ACK is not advanced, why go though the hassle of defining = point B in=20 section 3.4 to that = length?;

Hmm, good = question. I have to think about it. At first glance, your reasoning = sounds good and I cannot
see a mistake. However, I have also = the feeling that V. Jacobson is cleverer that = I...

Did you take a look into the bible? = (Stevens TCP/IP Illustrated)


and how is point C to be interpreted - any hole=20 being filled, only the leftmost hole? (The pseudo-code = (2) implicitly only=20 allows for the leftmost hole :) ).
 
 
Thanks=20 for bearing with me!
 
Best=20 regards,
   Richard
 

//
// Dipl.-Inform. Alexander = Zimmermann
// Department of Computer Science, Informatik = 4
// Ahornstr. 55, 52056 Aachen, = Germany
// phone: (49-241) 80-21422, fax: (49-241) = 80-22222
In-Reply-To: <196C11B7-5685-4FA2-BE61-4B5B406492E0@comsys.rwth-aachen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TS & SACK Thread-Index: Act/drRBGnHzckXcR56hhmYgb7NJmgAMKzwQ References: <5FDC413D5FA246468C200652D63E627A0B41E46D@LDCMVEXC1-PRD.hq.netapp.com> <5FDC413D5FA246468C200652D63E627A0B41E905@LDCMVEXC1-PRD.hq.netapp.com> <196C11B7-5685-4FA2-BE61-4B5B406492E0@comsys.rwth-aachen.de> From: "Scheffenegger, Richard" To: "Alexander Zimmermann" X-OriginalArrivalTime: 09 Nov 2010 01:13:56.0159 (UTC) FILETIME=[617824F0:01CB7FAB] Cc: tcpm@ietf.org Subject: Re: [tcpm] TS & SACK X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 01:13:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7FAB.613904FC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 HI Alexander, =20 ________________________________ From: Alexander Zimmermann [mailto:alexander.zimmermann@comsys.rwth-aachen.de]=20 =09 Am 05.11.2010 um 22:16 schrieb Scheffenegger, Richard: =09 Section 3.4 defines, which TS the receiver should echo. Especially case B is very important, if no further information is available. Overall, this section 3.4 seems to again specify, that the receiver should only echo the TS of the data segment, that lead to an cumulative ack of new data (except for delayed ACKs, where the TS of the first new data segment is to be used). It appears to me, that with the exception of rule 3.4 / A, talking about the delayed ack case, the cases B and C are redundant with what a sender can use for RTTM (PAWS) anyway. I don't think that cases b and c are redundant. In my point of view case b explains why we should "artificially inflate" the RTT, while case c explains why we can stop with this and can each back the "real" value. Moreover, all 3 cases are only explanations, the real algorithm comes later (steps 1, 2, 3)=20 =20 Well, redundant in the sense, that the sender will ignore any timestamp as per section 3.3 rule, as long as no new data is cumulatively acked.=20 =20 For point B, if the sender ignores the TS anyway (section 3.3), there is no point in reporting an inflated RTT. (The TS of the ACK for an out-of-order segment is to be ignored - for RTTM -, as it doesn't advance the left edge of the window, correct?). For all a RFC1323(bis) sender cares, the timestamp could be any number, which only fullfils the PAWS requirements, but has no further RTTM function. =20 For point C, the ACK advances, and the RTTM should be updated with a reasonable RTTM estimate, that is not artifically inflated, thus the TS of the data segment which filled the (leftmost?) hole. =09 =09 IMO leftmost. Or does point C also apply when a hole further right (thus not advancing cumulative ACK) is filled? IMO no. (Per 3.3, that TS should be ignored again; but point C is IMHO ambigious here). Yes, (maybe) it is ambiguous. RFC5681, Section 4.2. Generating Acknowledgments, next-to-last paragraph has the same "hole-ambiguous-problem". But on the other hand, the problem is maybe that we have the "SACK-Glass" on. Without SACK in mind, the wording is OK. (But can improved in 1323bis)=20 =20 Let's keep that aspect aside; it's pretty clear that the leftmost hole (which will result in a changed cumulative ACK) is meant. =20 So, my question is this: As a sender should ignore a TS for RTTM purposes if the cumulative ACK is not advanced, why go though the hassle of defining point B in section 3.4 to that length?; =09 =09 Hmm, good question. I have to think about it. At first glance, your reasoning sounds good and I cannot see a mistake. However, I have also the feeling that V. Jacobson is cleverer that I... =09 =09 Did you take a look into the bible? (Stevens TCP/IP Illustrated) =20 Just did. However, RFC1323 is not discussed there in that detail to yield the insight I'm looking for. Perhaps V. Jacobson could provide the background - it might be as simple as a belt-and-suspenders additional safety net, if either receiver or sender have implementation bugs... =20 =20 Best regards, Richard=20 ------_=_NextPart_001_01CB7FAB.613904FC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
HI Alexander,
 

From: Alexander Zimmermann=20 [mailto:alexander.zimmermann@comsys.rwth-aachen.de] =

Am 05.11.2010 um 22:16 schrieb Scheffenegger, Richard:

Section 3.4 = defines, which=20 TS the receiver should echo. Especially case B is very = important, if no=20 further information is available. Overall, this section 3.4 = seems to=20 again specify, that the receiver should only echo the TS of the = data=20 segment, that lead to an cumulative ack of new data (except for = delayed=20 ACKs, where the TS of the first new data segment is to be=20 used).

It appears to = me, that with=20 the exception of rule 3.4 / A, talking about the delayed ack = case, the=20 cases B and C are redundant with what a sender can use for RTTM = (PAWS)=20 anyway.

I don't think that cases b and c are redundant. In my point = of view=20 case b explains why we should
"artificially inflate" the RTT, = while=20 case c explains why we can stop with this and can each back
the = "real"=20 value. Moreover, all 3 cases are only explanations, the real=20 algorithm comes later
(steps 1, 2, 3) 
 
Well, redundant in the sense, that the sender will = ignore any=20 timestamp as per section 3.3 rule, as long as no new data=20 is cumulatively acked.
 
For point B, if the sender ignores the TS = anyway (section=20 3.3), there is no point in reporting an inflated RTT. (The = TS of=20 the ACK for an out-of-order segment is to be ignored - for RTTM -, = as=20 it doesn't advance the left edge of the=20 window, correct?). For all a RFC1323(bis) sender cares, the timestamp = could be any=20 number, which only fullfils the PAWS requirements, but has no = further RTTM=20 function.
 
For point C, the ACK advances, and the RTTM should be = updated=20 with a reasonable RTTM estimate, that is not artifically inflated, = thus the=20 TS of the data segment which filled the (leftmost?)=20 hole.

IMO leftmost.

Or=20 does point C also apply when a hole further right (thus not = advancing=20 cumulative ACK) is filled?

IMO no.

(Per 3.3, that TS should be ignored again; but point C = is IMHO=20 ambigious here).

Yes, (maybe) it is ambiguous. RFC5681, Section 4.2. = Generating=20 Acknowledgments, next-to-last paragraph has
the same "hole-ambiguous-problem".

But on the other hand, the problem is maybe that we have the = "SACK-Glass"=20 on. Without SACK in mind, the wording
is OK. (But can improved in 1323bis) 
 
Let's=20 keep that aspect aside; it's pretty clear that the leftmost hole (which = will=20 result in a changed cumulative ACK) is meant.
 
So, my=20 question is this: As a sender should ignore a TS for RTTM purposes = if the=20 cumulative ACK is not advanced, why go though the hassle of defining = point B=20 in section 3.4 to that length?;

Hmm, good question. I have to think about it. At first glance, = your=20 reasoning sounds good and I cannot
see a mistake. However, I have also the feeling that V. Jacobson = is=20 cleverer that I...

Did you take a look into the bible? (Stevens TCP/IP=20 Illustrated) 
 
Just=20 did. However, RFC1323 is not discussed there in that detail to yield the = insight=20 I'm looking for. Perhaps V. Jacobson could provide = the background - it=20 might be as simple as a belt-and-suspenders additional safety net, if = either=20 receiver or sender have implementation=20 bugs...   
 
Best=20 regards,
   = Richard 
------_=_NextPart_001_01CB7FAB.613904FC-- From dab@weston.borman.com Tue Nov 9 16:43:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75D6D3A69B3; Tue, 9 Nov 2010 16:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO+gOBaaUEGU; Tue, 9 Nov 2010 16:43:39 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id AB0243A68FD; Tue, 9 Nov 2010 16:43:39 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id oAA0i00D028005; Tue, 9 Nov 2010 16:44:00 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Nov 2010 16:43:59 -0800 Received: from dhcp-32f8.meeting.ietf.org ([147.11.69.7]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Nov 2010 16:43:58 -0800 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <78DB0ABC-24D1-41E1-BCC5-F70A950AD9C0@windriver.com> Date: Wed, 10 Nov 2010 08:43:53 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2BFC5B36-F3B2-410B-845B-6F71B212EE8A@weston.borman.com> References: <78DB0ABC-24D1-41E1-BCC5-F70A950AD9C0@windriver.com> To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 10 Nov 2010 00:43:59.0449 (UTC) FILETIME=[5CF5B490:01CB8070] Cc: tcpm-chairs@tools.ietf.org, Fernando Gont , TSV Dir Subject: Re: [tcpm] Side meeting to discuss TCP Security document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 00:43:40 -0000 We have Diamond 2 reserved from 1:00-3:00 today, Wednesday. Anyone who = is interested is welcome. -David Borman, TCPM co-chair On Nov 7, 2010, at 10:20 PM, David Borman wrote: > In Anaheim we had a small session to look at the TCP Security = document, attended by a hand full of people. We are interested in doing = this again here in Beijing. The goal is to go through some more of the = document and come up with some recommendations for how to move forward = with revising/editing the document, which will then be brought back to = the list. >=20 > So, there are 2 questions: > 1) Who is interested in attending? > 2) When should we meet? My recommendations for possibilities are, in = order of preference: > 1) Tuesday morning (NFSv4 meets at this time) > 2) Wednesday after lunch (No TSV groups meet at this time) > 3) Thursday morning (Congestion Exposure WG meets at this time) > Please reply to me or the list if you are interested in this, and if = so, which of those 3 periods you are available. Once we see who is = interested and when they would be available, I'll see about finding a = place to meet, but it won't be a regular session room, i.e. there won't = be any remote participation. >=20 > -David Borman, TCPM co-chair > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From wesley.m.eddy@nasa.gov Tue Nov 9 16:55:31 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25B23A696C for ; Tue, 9 Nov 2010 16:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1rr37p7hUMu for ; Tue, 9 Nov 2010 16:55:30 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 6E5EB3A6919 for ; Tue, 9 Nov 2010 16:55:30 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id B6060A80CF for ; Tue, 9 Nov 2010 18:55:55 -0600 (CST) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id oAA0ttPN018904 for ; Tue, 9 Nov 2010 18:55:55 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Tue, 9 Nov 2010 18:55:55 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Tue, 9 Nov 2010 18:54:50 -0600 Thread-Topic: WG status update Thread-Index: AQHLgHIHUw43nIWZ1Ei4oXaJ2dgBYA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_C304DB494AC0C04C87C6A6E2FF5603DB4821F155C3NDJSSCC01ndcn_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2010-11-09_15:2010-11-09, 2010-11-09, 1970-01-01 signatures=0 Subject: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 00:55:31 -0000 --_002_C304DB494AC0C04C87C6A6E2FF5603DB4821F155C3NDJSSCC01ndcn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, for those of you who aren't in Beijing, here's a snapshot of the TCPM W= G status.= --_002_C304DB494AC0C04C87C6A6E2FF5603DB4821F155C3NDJSSCC01ndcn_ Content-Type: text/plain; name="TCPM-status-101103.txt" Content-Description: TCPM-status-101103.txt Content-Disposition: attachment; filename="TCPM-status-101103.txt"; size=7629; creation-date="Tue, 09 Nov 2010 18:54:50 GMT"; modification-date="Tue, 09 Nov 2010 18:54:50 GMT" Content-Transfer-Encoding: base64 UmVjZW50IFJGQ3MNCj09PT09PT09PT09DQoNCk4vQQ0KDQoNCldHIEl0ZW1zIE5lYXJpbmcgUkZD IFB1YmxpY2F0aW9uDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpMb25nIENv bm5lY3Rpdml0eSBEaXNydXB0aW9ucw0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRm LXRjcG0tdGNwLWxjZC0wMy50eHQNCk1pbGVzdG9uZSBUYXJnZXQ6IEV4cGVyaW1lbnRhbCBpbiBP Y3RvYmVyIDIwMTANClN0YXR1czogSW4gUkZDIEVkaXRvcidzIHF1ZXVlIHNpbmNlIDkvMTQvMjAx MA0KDQpVcmdlbnQgRGF0YQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXRjcG0t dXJnZW50LWRhdGEtMDUudHh0DQpNaWxlc3RvbmUgVGFyZ2V0OiBQcm9wb3NlZCBTdGFuZGFyZCBp biBKYW51YXJ5IDIwMTANClN0YXR1czogaW4gUkZDIEVkaXRvcidzIHF1ZXVlIHNpbmNlIDEwLzE1 LzIwMTANCg0KDQoNCldHIEl0ZW1zIGluIFdHTEMgb3IgYmVpbmcgcmV2aXNlZCBhZnRlciBXR0xD DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpNU1MgT3B0 aW9uDQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtdGNwbS10Y3Btc3MtMDMudHh0 DQpNaWxlc3RvbmUgVGFyZ2V0OiBQcm9wb3NlZCBTdGFuZGFyZCBpbiBKdWx5IDIwMDkNClN0YXR1 czogV0dMQyBzdGFydGVkIDgvMTksIGVuZGVkIDkvOCAoZXh0ZW5kZWQpDQogICAgICAgIDJuZCBX R0xDIHN0YXJ0ZWQgYXQgSUVURiA3NywgYW5kIGlzIGVuZGVkIHdpdGggZmV3IGNvbW1lbnRzDQpB Y3Rpb246IERhdmlkIHdpbGwgY2hlY2sgd2l0aCBjb21tZW50ZXJzIGZyb20gZmlyc3QgV0dMQyB0 byBzZWUNCiAgICAgICAgICBpZiBpc3N1ZXMgYXJlIGNsb3NlZA0KICAgICAgICBXZXMgd2lsbCB3 cml0ZSBQUk9UTyBhbmQgc2VuZCB0byB0aGUgSUVTRywgYWZ0ZXIgV0dMQyBzdGFydHMNCiAgICAg ICAgICBhbmQgY29tcGxldGVzDQoNCmRyYWZ0LWVnZ2VydC10Y3BtLWhpc3RvcmljaXplLTAwDQpN aWxlc3RvbmUgVGFyZ2V0OiBJbmZvcm1hdGlvbmFsIGluIE9jdG9iZXIgMjAxMA0KU3RhdHVzOiBw b2xsIHN0YXJ0ZWQgNi8yNDsgZ2VuZXJhbGx5IHBvc2l0aXZlIHJlc3BvbnNlcw0KICAgICAgICBX R0xDIHN0YXJ0ZWQgb24gOC8xOSwgdG8gY2xvc2UgOS8xNyAtIHNvbWUgcG9zaXRpdmUgYW5kIG5v IG5lZ2F0aXZlDQogICAgICAgICAgcmVzcG9uc2VzDQpBY3Rpb246IFBST1RPIHN0YXRlbWVudCBp cyByZWFkeSB0byBzdWJtaXQ7IFdlcyB0byBzdWJtaXQNCg0KVGltZXN0YW1wcw0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtdGNwbS10Y3AtdGltZXN0YW1wcy0wMC50eHQNCk1p bGVzdG9uZSBUYXJnZXQ6IG5lZWRzIHRvIGJlIGFkZGVkIHRvIGNoYXJ0ZXINClN0YXR1czogV2Fz IGluIFdHTEMgdW50aWwgMTAvMSAtIHNvbWUgZmVlZGJhY2sgcmVjZWl2ZWQ7IEZlcm5hbmRvIGFz a2VkIGZvcg0KICAgICAgICBjb25maXJtYXRpb24gdGhhdCB0aGUgdXBkYXRlIGFuc3dlcnMgdGhl IGZlZWRiYWNrDQoNCg0KQWN0aXZlIFdHIEl0ZW1zDQo9PT09PT09PT09PT09PT0NCg0KMTMyM2Jp cw0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXRjcG0tMTMyM2Jpcy0wMS50eHQN Ck1pbGVzdG9uZSBUYXJnZXQ6IFByb3Bvc2VkIFN0YW5kYXJkIGluIEp1bHkgMjAwOQ0KU3RhdHVz OiBOZWVkcyByZXZpc2lvbg0KQWN0aW9uOiBSZXZpc2UgJiBXR0xDIChhY3Rpb24gd2l0aCBELiBC b3JtYW4pDQoNClRDUCBTZWN1cml0eQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRm LXRjcG0tdGNwLXNlY3VyaXR5LTAxLnR4dA0KTWlsZXN0b25lIFRhcmdldDogQkNQIGluIEF1Z3Vz dCAyMDEwDQpTdGF0dXM6IGNvbnRlbnQgbmVlZHMgd29yaw0KQWN0aW9uOiBwcm9ncmVzcyBvbiBy ZWNvbW1lbmRhdGlvbnMgbWFkZSBhdCBJRVRGIDc3IG5lZWRzIHRvIGJlIHdvcmtlZCBpbnRvDQog ICAgICAgICAgdGhlIG5leHQgdmVyc2lvbiBvZiBkcmFmdCAoRC4gQm9ybWFuIHRvIHdvcmsgdy8g RmVybmFuZG8pDQogICAgICAgIHBsYW4gdG8gbWVldCBvbiB0aGlzIGluIEJlaWppbmcgKFdlZG5l c2RheSBAIDEgUE0sIERpYW1vbmQgMiBSb29tKQ0KICAgICAgICBEYXZpZCBCb3JtYW4gdG8gcGFz cyBub3RlcyBmcm9tIEFuYWhlaW0gdG8gRmVybmFuZG8NCg0KU0FDSyBFbnRyeSAvIFJGQyAzNTE3 YmlzDQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWJsYW50b24tdGNwbS0zNTE3YmlzLTAw DQpNaWxlc3RvbmUgVGFyZ2V0OiBQcm9wb3NlZCBTdGFuZGFyZCBpbiBPY3RvYmVyIDIwMTANCkFj dGlvbjogbmVlZCB0byBjaGVjayBvbiB0aW1lZnJhbWUgd2l0aCBhdXRob3JzIG5vdyB0aGF0IFJG QyAzNTE3YmlzIGhhcw0KICAgICAgICBiZWVuIG1lcmdlZCB3aXRoIHRoZSBTQUNLLWVudHJ5IGRy YWZ0LiAgTWF5IGJlIHJlYWR5IGZvciBXR0xDIGluDQogICAgICAgIG5lYXIgdGVybT8NCg0KQ2xh cmlmaWNhdGlvbiBvZiBzZW5kZXIgYmVoYXZpb3IgaW4gcGVyc2lzdCBjb25kaXRpb24NCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXRjcG0tcGVyc2lzdC0wMC50eHQNCk1pbGVz dG9uZSBUYXJnZXQ6IG5lZWRzIHRvIGJlIGFkZGVkIHRvIGNoYXJ0ZXINClN0YXR1czogaW5pdGlh bCBkcmFmdCBzdWJtaXR0ZWQNCkFjdGlvbjogQXV0aG9ycyB3b3JraW5nIG9uIGFuIHVwZGF0ZSB0 byBjbGFyaWZ5IGludGVudCBvZiBzb2NrZXQgb3B0aW9uDQogICAgICAgIGRlc2NyaXB0aW9uLiAg VXBkYXRlIHBsYW5uZWQgdG8gZW50ZXIgV0dMQy4NCg0KSW5jcmVhc2luZyB0aGUgSW5pdGlhbCBX aW5kb3cNCmRyYWZ0LWhrY2h1LXRjcG0taW5pdGN3bmQtMDENCk1pbGVzdG9uZSBUYXJnZXQ6IEF1 Z3VzdCAyMDExIHRvIGRldGVybWluZSBpbnRlbmRlZCBzdGF0dXMNCiAgICAgICAgICAgICAgICAg IFNlcHRlbWJlciAyMDExIHRvIHB1Ymxpc2ggZG9jdW1lbnQNClN0YXR1czogdW5kZXIgYWN0aXZl IGRpc2N1c3Npb24gLyByZXZpZXcNCkFjdGlvbjogZGV0ZXJtaW5lIGludGVuZGVkIHN0YXR1cyB0 aHJvdWdoIGNvbnRpbnVlZCBXRyBkaXNjdXNzaW9uDQogICAgICAgIHBsYW4gdG8gcHJlc2VudC9k aXNjdXNzIGZ1cnRoZXIgZGF0YSBpbiBCZWlqaW5nIChhbmQgb24tbGlzdCkNCg0KDQpDb21wdXRp bmcgVENQJ3MgUmV0cmFuc21pc3Npb24gVGltZXINCmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9k cmFmdC1wYXhzb24tdGNwbS1yZmMyOTg4YmlzLTAwLnR4dA0KU3RhdHVzOiBwcmVzZW50ZWQgYnJp ZWZseSBhdCBJRVRGIDc3LCBhbHNvIHdlbGwtZGlzY3Vzc2VkIG9uIG1haWxpbmcgbGlzdA0KICAg ICAgICAgIGVhcmxpZXIgYW5kIGF0IElFVEYgNzUNCiAgICAgICAgY29uZmlybWF0aW9uIHBvbGwg Zm9yIGFkb3B0aW9uIHN0YXJ0ZWQgb24gOS8xNywgY2xvc2VkIDEwLzENCkFjdGlvbjogU3VibWl0 IFdHIGRvY3VtZW50IHZlcnNpb24NCiAgICAgICAgQ2hhaXJzIHRvIGFkZCBtaWxlc3RvbmUgdG8g Y2hhcnRlcg0KDQpOZXdSZW5vIFVwZGF0ZQ0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1oZW5kZXJzb24tdGNwbS1yZmMzNzgyLWJpcy8NClN0YXR1czogYWRvcHRlZCBhcyBX RyBpdGVtDQpNaWxlc3RvbmUgVGFyZ2V0OiBQcm9wb3NlZCBTdGFuZGFyZCBpbiBBdWd1c3QgMjAx MQ0KRG9lcyB0aGUgZHJhZnQtbmlzaGlkYS1uZXdyZW5vLW1vZGlmaWNhdGlvbiBsb2dpYyBuZWVk IHRvIGJlIGFkZGVkIGFzIGFuDQphcHBlbmRpeCwgcHVibGlzaGVkIHNlcGFyYXRlbHksIG9yIG90 aGVyPw0KDQoNCkRvY3VtZW50cyBVbmRlciBhIFBvbGwgdG8gQmVjb21lIFdHIEl0ZW1zDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpOL0ENCg0KDQpPdGhlciBQ cm9wb3NhbHMgTm90IFlldCBEZWNpZGVkIE9uDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQoNCmRyYWZ0LWFudW1pdGEtdGNwbS1zdHJvbmdlci1jaGVja3N1bS0wMA0KU3RhdHVz OiBkaXNjdXNzZWQgb24tbGlzdCwgbWluZ2xlZCB3aXRoIGhpc3RvcmljaXplIGRyYWZ0IGRpc2N1 c3Npb24NCg0KZHJhZnQtZHVhbi10Y3BtLXRjcC1hby1yZWtleWluZy0wMA0KU3RhdHVzOiBkaXNj dXNzZWQgaW4gQW5haGVpbSBhbmQgb24tbGlzdDsgbW90aXZhdGlvbnMgYW5kIHVzZWZ1bG5lc3Mg d2FzDQogICAgICAgIHF1ZXN0aW9uZWQNCg0KZHJhZnQtaHVhbmctdGNwbS10Y3AtZWFjay0wMA0K U3RhdHVzOiBkaXNjdXNzZWQgb24tbGlzdDsgdGhlcmUgc2VlbXMgdG8gYmUgYWdyZWVtZW50IHRo YXQgQUNLIGNvbmdlc3Rpb24NCiAgICAgICAgY29udHJvbCAoUkZDIDU2OTApIHdpbGwgbWl0aWdh dGUgdGhlIGlzc3VlDQoNCkFPIE5BVA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtdG91Y2gtdGNwLWFvLW5hdC0wMC50eHQNClN0YXR1czogSUVURiA3NyBkaXNjdXNz aW9uIGRldGVybWluZWQgdGhpcyBzaG91bGQgYmUgRXhwZXJpbWVudGFsLCB3aGV0aGVyIG9yDQog ICAgICAgICAgbm90IGl0IGlzIGEgV0cgZG9jdW1lbnQ7IG5lZWQgdG8gYXNrIFRDUE0gbGlzdA0K QWN0aW9uOiBuZWVkIHRvIHBvbGwgbWFpbGluZyBsaXN0IGFib3V0IHBhdGggZm9yd2FyZA0KDQoN Ck9sZGVyICYgRXhwaXJlZCBEb2N1bWVudHMgRGlzY3Vzc2VkDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KDQpkaXNjdXNzaW9ucyBvbiBSYXRlLUhhbHZpbmcNCmh0dHA6Ly90 b29scy5pZXRmLm9yZy9pZC9kcmFmdC1tYXRoaXMtdGNwLXJhdGVoYWx2aW5nLTAwLnR4dA0KQWN0 aW9uOiBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiBhYm91dCB0aGUgaGlzdG9yeSBvZiB0aGlzLCBh bmQgd2hldGhlcg0KICAgICAgICBpdCBuZWVkcyB0byBiZSByZXZpdmVkDQoNCkZhc3RlciBBcHBs aWNhdGlvbiBIYW5kc2hha2VzIHdpdGggU1lOL0FDSyBQYXlsb2Fkcw0KZXhwaXJlZCBkcmFmdC1h Z2wtdGNwbS1zYWRhdGEtMDENClN0YXR1czogZXhwaXJlZDsgbm90IHNwZWNpZmljYWxseSBwb2xs ZWQgZm9yIGFkb3B0aW9uIGluIFdHDQoNCmRyYWZ0LXljaGVuZy10Y3BtLXJ0b3N5bnJ0dC0wMA0K U3RhdHVzOiBoYXMgYmVlbiBzdWdnZXN0ZWQgYXMgZWl0aGVyIGFuIGFkZGl0aW9uIHRvIDI5ODhi aXMgb3IgdG8gaW5pdGN3bmQNCiAgICAgICAgZG9jdW1lbnRzDQpBY3Rpb246IGRpc2N1c3Npb24g d2l0aCBhdXRob3JzIGluZGljYXRlcyB0aGF0IHRoaXMgaXMgc3VwZXJjZWRlZCBieSB0aGUNCiAg ICAgICAgICBvdGhlciBjaGFuZ2VzIGluIHRoZSAyOTg4YmlzIGRvY3VtZW50DQoNCg0KRG9jdW1l bnRzIE5vdCBBZG9wdGVkIGJ5IFdHDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KVENQ IE9wdGlvbiBmb3IgVHJhbnNwYXJlbnQgTWlkZGxlYm94IERpc2NvdmVyeQ0KaHR0cDovL3d3dy5p ZXRmLm9yZy9pZC9kcmFmdC1rbnV0c2VuLXRjcG0tbWlkZGxlYm94LWRpc2NvdmVyeS0wNC50eHQN ClN0YXR1czogZGlzY3Vzc2VkIG9uIG1haWxpbmcgbGlzdCBhbmQgdXBkYXRlZCBpbiByZXNwb25z ZQ0KICAgICAgICBwb2xsIGZvciB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIG9wZW5lZCBvbiAxMi85 LCByZXNwb25zZXMNCiAgICAgICAgICBkZXNpcmVkIGJ5IDEyLzIzDQogICAgICAgIGRlY2lzaW9u IG5vdCB0byBhZG9wdCBieSBXRzsgSUVTRyBtYXkgYWxsb3cgcHVibGljYXRpb24gYW5kDQogICAg ICAgICAgb3B0aW9uIG51bWJlciBhc3NpZ25tZW50IGF0IHRoZWlyIGRpc2NyZXRpb24sIGJ1dCBU Q1BNIGRvZXMNCiAgICAgICAgICBub3QgaGF2ZSBjb25zZW5zdXMgdG8gZG8gdGhpcyB3b3JrDQog ICAgICAgIGJhY2tncm91bmQgcHJlc2VudGVkIGF0IElFVEYgNzcNCiAgICAgICAgYXV0aG9ycyBh cmUgd29ya2luZyB3aXRoIG90aGVyIHZlbmRvcnMgb24gYSBzZXBhcmF0ZSBtYWlsaW5nIGxpc3QN Cg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3JpZGhhcmFuLXRjcG0tY3RjcC0w Mg0KU3RhdHVzOiBwb2xsZWQgZm9yIGludGVyZXN0IG9uIDYvMTYvMTANCiAgICAgICAgb25lIHBv c2l0aXZlIHJlc3BvbnNlOyBubyBuZWdhdGl2ZSAtIHRvbyB3ZWFrIGZvciBhZG9wdGlvbg0KDQoN Ck90aGVyIFRDUCBEb2N1bWVudHMNCj09PT09PT09PT09PT09PT09PT0NCg0KVENQIENvb2tpZSBU cmFuc2FjdGlvbnMgKFRDUENUKQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtc2ltcHNvbi10Y3BjdC0wMi50eHQNClN0YXR1czogc3VibWl0dGVkIGZvciBFeHBlcmlt ZW50YWwgUkZDIHRocm91Z2ggSW5kZXBlbmRlbnQgU3RyZWFtDQogICAgICAgIGluIEFVVEg0OA0K DQoNCk90aGVyIFdHIEFjdGl2aXRpZXMNCj09PT09PT09PT09PT09PT09PT0NCg0KRXJyYXRhIFJl dmlldyBmb3IgbGVnYWN5IFRDUCBSRkNzOg0KDQpSRkMwNzkzICgxNDk2KSAgMy45ICAgICAgVGVj aG5pY2FsICAgICAgICBMZWdhY3kgIFlpbiBTaHVtaW5nICAgICAgICAgICAgICAyMDA4LTA4LTI3 DQpSRkMwNzkzICgxNTYxKSAgIDMuMiAgICAgIFRlY2huaWNhbCAgICAgICAgTGVnYWN5ICAgQ29u c3RhbnRpbiBIYWdlbWVpZXIgICAgIDIwMDgtMTAtMTENClJGQzA3OTMgKDE1NjIpICAgMy4zICAg ICAgVGVjaG5pY2FsICAgICAgICBMZWdhY3kgICBDb25zdGFudGluIEhhZ2VtZWllciAgICAgMjAw OC0xMC0xMQ0KUkZDMDc5MyAoMTU2MykgICAzLjQgICAgICBUZWNobmljYWwgICAgICAgIExlZ2Fj eSAgIENvbnN0YW50aW4gSGFnZW1laWVyICAgICAyMDA4LTEwLTExDQpSRkMwNzkzICgxNTY0KSAg IDMuNyAgICAgIFRlY2huaWNhbCAgICAgICAgTGVnYWN5ICAgQ29uc3RhbnRpbiBIYWdlbWVpZXIg ICAgIDIwMDgtMTAtMTENClJGQzA3OTMgKDE1NjUpICAgMy44ICAgICAgVGVjaG5pY2FsICAgICAg ICBMZWdhY3kgICBDb25zdGFudGluIEhhZ2VtZWllciAgICAgMjAwOC0xMC0xMQ0KUkZDMDc5MyAo MTU2NikgICAzLjkgICAgICBUZWNobmljYWwgICAgICAgIExlZ2FjeSAgIENvbnN0YW50aW4gSGFn ZW1laWVyICAgICAyMDA4LTEwLTExDQpSRkMwNzkzICgxNTY3KSAgIDMuOSAgICAgIFRlY2huaWNh bCAgICAgICAgTGVnYWN5ICAgQ29uc3RhbnRpbiBIYWdlbWVpZXIgICAgIDIwMDgtMTAtMTENClJG QzA3OTMgKDE1NjgpICAgMy45ICAgICAgVGVjaG5pY2FsICAgICAgICBMZWdhY3kgICBDb25zdGFu dGluIEhhZ2VtZWllciAgICAgMjAwOC0xMC0xMQ0KUkZDMDc5MyAoMTU2OSkgICAyLjQgICAgICBU ZWNobmljYWwgICAgICAgIExlZ2FjeSAgIENvbnN0YW50aW4gSGFnZW1laWVyICAgICAyMDA4LTEw LTExDQpSRkMwNzkzICgxNTcwKSAgIDIuNyAgICAgIFRlY2huaWNhbCAgICAgICAgTGVnYWN5ICAg Q29uc3RhbnRpbiBIYWdlbWVpZXIgICAgIDIwMDgtMTAtMTENClJGQzA3OTMgKDE1NzEpICAgMy4x ICAgICAgVGVjaG5pY2FsICAgICAgICBMZWdhY3kgICBDb25zdGFudGluIEhhZ2VtZWllciAgICAg MjAwOC0xMC0xMQ0KUkZDMDc5MyAoMTU3MikgICAzLjQgICAgICBUZWNobmljYWwgICAgICAgIExl Z2FjeSAgIENvbnN0YW50aW4gSGFnZW1laWVyICAgICAyMDA4LTEwLTExDQoNCg0K --_002_C304DB494AC0C04C87C6A6E2FF5603DB4821F155C3NDJSSCC01ndcn_-- From bruno.mongazon-cazavet@alcatel-lucent.com Tue Nov 9 23:53:56 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086C43A6802 for ; Tue, 9 Nov 2010 23:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5Hfxnt+ijLe for ; Tue, 9 Nov 2010 23:53:55 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 09E943A6784 for ; Tue, 9 Nov 2010 23:53:54 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAA7sIBb026500 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Nov 2010 08:54:18 +0100 Received: from [172.27.205.223] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 10 Nov 2010 08:54:18 +0100 Message-ID: <4CDA4FA9.4050006@alcatel-lucent.com> Date: Wed, 10 Nov 2010 08:54:17 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: tcpm@ietf.org Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 07:53:56 -0000 Le 10/11/2010 01:54, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] a écrit : > Hi, for those of you who aren't in Beijing, here's a snapshot of the TCPM WG status. Hi, I have posted a 00 draft that might be of interest for your working group. I don't see any mention in your snapshot. http://www.ietf.org/id/draft-mongazon-tcpm-tcp-rehash-00.txt I will not be in Beijing to present it but i hope to be in Prague to do so. I would appreciate the working group can look at it and let me know if it could be of any interest and how i shall pursue my contribution. I have done a Linux kernel implementation of the draft and be ready for a demo in Prague. Best Regards, Bruno. From rs@netapp.com Wed Nov 10 04:34:47 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903083A67FF for ; Wed, 10 Nov 2010 04:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUFhs8vScdNb for ; Wed, 10 Nov 2010 04:34:46 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 6C8C128C0E7 for ; Wed, 10 Nov 2010 04:34:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,177,1288594800"; d="scan'208";a="225587521" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 10 Nov 2010 04:35:07 -0800 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oAACZ6rv004515; Wed, 10 Nov 2010 04:35:06 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Nov 2010 13:35:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 12:35:04 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B54DF67@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WG status update Thread-Index: AQHLgHIHUw43nIWZ1Ei4oXaJ2dgBYJNqoylw References: From: "Scheffenegger, Richard" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-OriginalArrivalTime: 10 Nov 2010 12:35:06.0260 (UTC) FILETIME=[B45C6540:01CB80D3] Cc: tcpm@ietf.org Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 12:34:47 -0000 http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02 Status: polled for interest on 6/16/10 one positive response; no negative - too weak for adoption I have been under the impression, that Lars specifically approached the authors to update and resubmit a new revision of the draft, before this can move forward. For the record, I share the opinion of Anumita (adopt this as WG item, updated with the most recent studies on stability / ICCRG input). Ditto for draft-rhee-tcpm-cubic Richard Scheffenegger From rs@netapp.com Wed Nov 10 04:50:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7563A6407 for ; Wed, 10 Nov 2010 04:50:40 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nzZYzEeww7P for ; Wed, 10 Nov 2010 04:50:39 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id F332D3A677D for ; Wed, 10 Nov 2010 04:50:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,177,1288594800"; d="scan'208";a="225588677" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 10 Nov 2010 04:51:05 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oAACp4GP008500; Wed, 10 Nov 2010 04:51:04 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Nov 2010 12:51:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 12:51:01 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4CDA4FA9.4050006@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WG status update Thread-Index: AcuArJQDlJswgExrQymw/Iie15u40wAKCH1w References: <4CDA4FA9.4050006@alcatel-lucent.com> From: "Scheffenegger, Richard" To: "Bruno Mongazon-Cazavet" , "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-OriginalArrivalTime: 10 Nov 2010 12:51:04.0874 (UTC) FILETIME=[EFBD48A0:01CB80D5] Cc: tcpm@ietf.org Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 12:50:40 -0000 Hi Bruno, After a casual look, it appears to me that a lightweight implementation = of MP-TCP can have the same benefits, but does not require the opaque = exchange of IPv4 addresses... Your use case - that the old L3 address is already no longer available = at the time of the rehash - may need to be looked at in MPTCP though = (iirc, they do a graceful session setup first (thus can work with NAT = mostly), and move data transport only after the successful establishment = of the 2nd L3 connectivity, and only then tear down the original L3 = connectivity). Perhaps the effort would be better placed on making sure that such = light-weight MPTCP implementations remain feasible, instead of defining = an alternate method that is addressing only this one aspect, but = incompatible with MPTCP otherwise? Richard Scheffenegger =20 > -----Original Message----- > From: Bruno Mongazon-Cazavet=20 > [mailto:bruno.mongazon-cazavet@alcatel-lucent.com]=20 > Sent: Mittwoch, 10. November 2010 08:54 > To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] > Cc: tcpm@ietf.org > Subject: Re: [tcpm] WG status update >=20 >=20 > Le 10/11/2010 01:54, Eddy, Wesley M. (GRC-MS00)[ASRC=20 > AEROSPACE CORP] a =E9crit : > > Hi, for those of you who aren't in Beijing, here's a=20 > snapshot of the TCPM WG status. >=20 > Hi, >=20 > I have posted a 00 draft that might be of interest for your working=20 > group. I don't see any mention in your snapshot. > http://www.ietf.org/id/draft-mongazon-tcpm-tcp-rehash-00.txt >=20 > I will not be in Beijing to present it but i hope to be in=20 > Prague to do so. > I would appreciate the working group can look at it and let=20 > me know if=20 > it could be of any interest and how i shall pursue my contribution. >=20 > I have done a Linux kernel implementation of the draft and be=20 > ready for=20 > a demo in Prague. >=20 > Best Regards, > Bruno. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From hagen@jauu.net Wed Nov 10 07:28:47 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCAA93A681F for ; Wed, 10 Nov 2010 07:28:47 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1T8SMQyxaq4 for ; Wed, 10 Nov 2010 07:28:47 -0800 (PST) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id 724593A694F for ; Wed, 10 Nov 2010 07:28:46 -0800 (PST) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 220C9F44195; Wed, 10 Nov 2010 16:29:12 +0100 (CET) Date: Wed, 10 Nov 2010 16:29:02 +0100 From: Hagen Paul Pfeifer To: Jerry Chu , tmrg , Matt Mathis , tcpm , Lars Eggert Message-ID: <20101110152857.GA5094@hell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 15:28:47 -0000 Cause tomorrow Jerry will talk about the IW10 topic my 50 cents in advance. First some skeptical notes, secondly a alternative approach to increase the IW. I am skeptical about this draft because IMHO renounce the conservative principle towards a aggressive and HTML centric approach (the HTML example is a bad allegation, but for FTP and friends slow start is fast enough ;-). My costumer, and probably other networks too, operates multi-hop radio networks with a bandwidth of less then 100kB/s. An increased IW of 10 define 10*~MSS byte as the smallest atomic in-flight value. New data are always pushed into the network in this quantum - a way to much for the standard TCP CC mechanism to tune into a steady state for network with a low BDP. In the discussion I miss the impact of the proposed modification regarding networks that operates already at a functioning boundary. Are we at a time where we loss these types of networks? Where are the simulation results that show that the impact at this kind of networks is acceptable? Alternative idea: can we shift the idea towards a more robust basis. What about a increased IW of 10 if we know that the path is capable of an increased IW? Pseudo Algorithm for a new connection: a) No cached CC data available IW = 4 (standard mechanism a la RFC 5681, 3390) CC mechanism as usual but save CC parameters - especially cwnd - per route b) CC data per route is available IF (cached_cwnd >= 10) IW = 10 else IW = 4 After n minutes, previously saved CC data is marked as invalid, similar to the existing "back to slow start after n minutes idle" mechanism. Idea: networks with a low BDP will signal by packet drop or ECN marking that congestion occur and the BDP is saturated. Why not use actual network information to setup the IW but preserve the conservative nature of TCP? Maybe this is an approach for further discussions, I have a curious feeling that in 2 years the same discussion will start with a IW of 23 ... So maybe we should drop the static IW approach completely and define IW as cached_steady_state_cwnd / 2 for cached routes and IW = 4 for startup all other cases. Best regards, Hagen From ananth@cisco.com Wed Nov 10 08:04:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7353A6950 for ; Wed, 10 Nov 2010 08:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKfH3QutXKw3 for ; Wed, 10 Nov 2010 08:04:43 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A3A4D3A689E for ; Wed, 10 Nov 2010 08:04:43 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPNR2kyrR7H+/2dsb2JhbACiNXGiWpsyhUoEhFqJD4gD X-IronPort-AV: E=Sophos;i="4.59,178,1288569600"; d="scan'208";a="215012043" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2010 16:04:50 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAAG4ndA017115; Wed, 10 Nov 2010 16:04:49 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 08:04:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: ASZ0 DapS NqcF RnJv SkHJ S8KT Yutx dfAJ lBjm njXc pINK wpgg xAMh 1mfR 17DO 9XCe; 6; aABhAGcAZQBuAEAAagBhAHUAdQAuAG4AZQB0ADsAaABrAGMAaAB1AEAAZwBvAG8AZwBsAGUALgBjAG8AbQA7AGwAYQByAHMALgBlAGcAZwBlAHIAdABAAG4AbwBrAGkAYQAuAGMAbwBtADsAbQBhAHQAdABtAGEAdABoAGkAcwBAAGcAbwBvAGcAbABlAC4AYwBvAG0AOwB0AGMAcABtAEAAaQBlAHQAZgAuAG8AcgBnADsAdABtAHIAZwAtAGkAbgB0AGUAcgBlAHMAdABAAGkAYwBzAGkALgBiAGUAcgBrAGUAbABlAHkALgBlAGQAdQA=; Sosha1_v1; 7; {6E6098FC-5B89-4491-8A43-F49FF6154DEF}; YQBuAGEAbgB0AGgAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Wed, 10 Nov 2010 15:42:38 GMT; UgBFADoAIABbAHQAYwBwAG0AXQAgAEkAbgBjAHIAZQBhAHMAaQBuAGcAIAB0AGgAZQAgAEkAbgBpAHQAaQBhAGwAIABXAGkAbgBkAG8AdwAgAC0AIABOAG8AdABlAHMA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {6E6098FC-5B89-4491-8A43-F49FF6154DEF} Content-class: urn:content-classes:message Date: Wed, 10 Nov 2010 08:04:48 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580B242496@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20101110152857.GA5094@hell> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Increasing the Initial Window - Notes Thread-Index: AcuA7AoZzPtSN90tRk2mj/AeCuX+bwAAEzqw References: <20101110152857.GA5094@hell> From: "Anantha Ramaiah (ananth)" To: "Hagen Paul Pfeifer" , "Jerry Chu" , "tmrg" , "Matt Mathis" , "tcpm" , "Lars Eggert" X-OriginalArrivalTime: 10 Nov 2010 16:04:48.0867 (UTC) FILETIME=[002DDB30:01CB80F1] Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 16:04:45 -0000 I think the stuff which you are suggesting below has already been mentioned in earlier conversations (mailing lists, online during the earlier presentations). Things like "tomorrow someone will come with IW =3D 23 etc.,", using the cached information also has been mentioned. The IW=3D10 is a fundamental change to TCP and hence the suggestion of = moving this work item to ICCRG also was mentioned before. Someone also pointed out "will this work in Africa"? Also using a TCP option to agree upon the IW was mentioned (which is probably less useful since you have to wait for the 3 way HS to complete and also it is not about end hosts supporting higher IW, it is about the network property as you rightly mention below) Actually it would be nicer if the authors mention these things in the document and respond with what their stance is on each of the questions. This way anyone who reads the document are well informed of the current stance.=20 $0.02, -Anantha -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Hagen Paul Pfeifer Sent: Wednesday, November 10, 2010 7:29 AM To: Jerry Chu; tmrg; Matt Mathis; tcpm; Lars Eggert Subject: [tcpm] Increasing the Initial Window - Notes Cause tomorrow Jerry will talk about the IW10 topic my 50 cents in advance. First some skeptical notes, secondly a alternative approach to increase the IW. I am skeptical about this draft because IMHO renounce the conservative principle towards a aggressive and HTML centric approach (the HTML example is a bad allegation, but for FTP and friends slow start is fast enough ;-). My costumer, and probably other networks too, operates multi-hop radio networks with a bandwidth of less then 100kB/s. An increased IW of 10 define 10*~MSS byte as the smallest atomic in-flight value. New data are always pushed into the network in this quantum - a way to much for the standard TCP CC mechanism to tune into a steady state for network with a low BDP. In the discussion I miss the impact of the proposed modification regarding networks that operates already at a functioning boundary. Are we at a time where we loss these types of networks? Where are the simulation results that show that the impact at this kind of networks is acceptable? Alternative idea: can we shift the idea towards a more robust basis. What about a increased IW of 10 if we know that the path is capable of an increased IW? Pseudo Algorithm for a new connection: a) No cached CC data available IW =3D 4 (standard mechanism a la RFC 5681, 3390) CC mechanism as usual but save CC parameters - especially cwnd - per route b) CC data per route is available IF (cached_cwnd >=3D 10) IW =3D 10 else IW =3D 4 After n minutes, previously saved CC data is marked as invalid, similar to the existing "back to slow start after n minutes idle" mechanism. Idea: networks with a low BDP will signal by packet drop or ECN marking that congestion occur and the BDP is saturated. Why not use actual network information to setup the IW but preserve the conservative nature of TCP? Maybe this is an approach for further discussions, I have a curious feeling that in 2 years the same discussion will start with a IW of 23 ... So maybe we should drop the static IW approach completely and define IW as cached_steady_state_cwnd / 2 for cached routes and IW =3D 4 for startup all other cases. Best regards, Hagen _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From hagen@jauu.net Wed Nov 10 08:29:05 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFFB03A6978 for ; Wed, 10 Nov 2010 08:29:05 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZNichcbFACr for ; Wed, 10 Nov 2010 08:29:05 -0800 (PST) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id D571F3A694A for ; Wed, 10 Nov 2010 08:29:04 -0800 (PST) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 9525EF44195; Wed, 10 Nov 2010 17:29:31 +0100 (CET) Date: Wed, 10 Nov 2010 17:29:24 +0100 From: Hagen Paul Pfeifer To: "Anantha Ramaiah (ananth)" Message-ID: <20101110162922.GE5094@hell> References: <20101110152857.GA5094@hell> <0C53DCFB700D144284A584F54711EC580B242496@xmb-sjc-21c.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C53DCFB700D144284A584F54711EC580B242496@xmb-sjc-21c.amer.cisco.com> 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.20 (2009-06-14) Cc: tmrg , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 16:29:05 -0000 * Anantha Ramaiah (ananth) | 2010-11-10 08:04:48 [-0800]: >I think the stuff which you are suggesting below has already been >mentioned in earlier conversations (mailing lists, online during the >earlier presentations). Things like "tomorrow someone will come with IW >= 23 etc.,", using the cached information also has been mentioned. The >IW=10 is a fundamental change to TCP and hence the suggestion of moving >this work item to ICCRG also was mentioned before. Someone also pointed >out "will this work in Africa"? Also using a TCP option to agree upon >the IW was mentioned (which is probably less useful since you have to >wait for the 3 way HS to complete and also it is not about end hosts >supporting higher IW, it is about the network property as you rightly >mention below) I am aware about "IW >= 23" and the Africa discussion. For me the later is a strong reason for a refusal of the draft. I am not aware of the discussion of the _cached cwnd_ approach. Hagen From perfgeek@mac.com Wed Nov 10 08:33:55 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73383A6A59 for ; Wed, 10 Nov 2010 08:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVtYDuY-TZkw for ; Wed, 10 Nov 2010 08:33:17 -0800 (PST) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by core3.amsl.com (Postfix) with ESMTP id D45AA3A6950 for ; Wed, 10 Nov 2010 08:33:13 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0LBO00FISGNWM570@asmtp016.mac.com> for tcpm@ietf.org; Wed, 10 Nov 2010 08:33:33 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1011100094 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-10_06:2010-11-10, 2010-11-10, 1970-01-01 signatures=0 Message-id: <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> From: rick jones To: Hagen Paul Pfeifer In-reply-to: <20101110152857.GA5094@hell> Date: Wed, 10 Nov 2010 08:33:30 -0800 References: <20101110152857.GA5094@hell> X-Mailer: Apple Mail (2.936) Cc: tmrg , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 16:33:55 -0000 On Nov 10, 2010, at 7:29 AM, Hagen Paul Pfeifer wrote: > Cause tomorrow Jerry will talk about the IW10 topic my 50 cents in > advance. > First some skeptical notes, secondly a alternative approach to > increase the > IW. > > I am skeptical about this draft because IMHO renounce the > conservative principle > towards a aggressive and HTML centric approach (the HTML example is > a bad > allegation, but for FTP and friends slow start is fast enough ;-). Sure, if all one is doing is pushing <=3MSS and >100MSS files around :) > My costumer, > and probably other networks too, operates multi-hop radio networks > with a > bandwidth of less then 100kB/s. > > An increased IW of 10 define 10*~MSS byte as the smallest atomic in- > flight > value. New data are always pushed into the network in this quantum - > a way to > much for the standard TCP CC mechanism to tune into a steady state > for network > with a low BDP. Do your customers run systems with support for TSO and/or LRO enabled, or do they disable that today? TSO can/may/will cause 10*MSS or larger blobs of data to be injected into the network at one time no? And LRO can/may induce stretch ACK behaviour not unlike the ACK avoidance heuristics of stacks such as those in HP-UX or Solaris. What I've seen so far has suggested the goal is to get IW10 "blessed" not to make IW10 mandatory. rick jones http://homepage.mac.com/perfgeek From hagen@jauu.net Wed Nov 10 09:00:18 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0993A689E for ; Wed, 10 Nov 2010 09:00:18 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXxfPUjwaAgI for ; Wed, 10 Nov 2010 09:00:04 -0800 (PST) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id E934E3A67B2 for ; Wed, 10 Nov 2010 09:00:03 -0800 (PST) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 6391FF44195; Wed, 10 Nov 2010 18:00:30 +0100 (CET) Date: Wed, 10 Nov 2010 18:00:20 +0100 From: Hagen Paul Pfeifer To: rick jones Message-ID: <20101110170017.GF5094@hell> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> 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.20 (2009-06-14) Cc: tmrg , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 17:00:18 -0000 * rick jones | 2010-11-10 08:33:30 [-0800]: >Do your customers run systems with support for TSO and/or LRO >enabled, or do they disable that today? TSO can/may/will cause >10*MSS or larger blobs of data to be injected into the network at one >time no? No, TSO does not change the packet behavior on the wire. At least no CC related mechanisms. Packet spacing and stuff like that ignored here. >And LRO can/may induce stretch ACK behaviour not unlike the >ACK avoidance heuristics of stacks such as those in HP-UX or Solaris. >What I've seen so far has suggested the goal is to get IW10 "blessed" >not to make IW10 mandatory. If the IETF "blessed" IW10 every vendor will enable it ... Hagen From touch@isi.edu Wed Nov 10 09:04:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4EBE3A6919 for ; Wed, 10 Nov 2010 09:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsgtLzl4N4wO for ; Wed, 10 Nov 2010 09:04:48 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DE2B33A6928 for ; Wed, 10 Nov 2010 09:04:47 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAAH4gKK022215 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 10 Nov 2010 09:04:51 -0800 (PST) Message-ID: <4CDAD0AB.109@isi.edu> Date: Wed, 10 Nov 2010 09:04:43 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hagen Paul Pfeifer References: <20101110152857.GA5094@hell> <0C53DCFB700D144284A584F54711EC580B242496@xmb-sjc-21c.amer.cisco.com> <20101110162922.GE5094@hell> In-Reply-To: <20101110162922.GE5094@hell> 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 , tmrg , "Anantha Ramaiah \(ananth\)" , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 17:04:48 -0000 On 11/10/2010 8:29 AM, Hagen Paul Pfeifer wrote: > I am aware about "IW>= 23" and the Africa discussion. For me the later is a > strong reason for a refusal of the draft. I am not aware of the discussion of > the _cached cwnd_ approach. See RFC2140. Joe From touch@isi.edu Wed Nov 10 09:05:50 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635E43A6978 for ; Wed, 10 Nov 2010 09:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4kGxDnBtbEs for ; Wed, 10 Nov 2010 09:05:49 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 8DBFD3A6949 for ; Wed, 10 Nov 2010 09:05:49 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAAH63wR022729 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 10 Nov 2010 09:06:03 -0800 (PST) Message-ID: <4CDAD0FB.6060602@isi.edu> Date: Wed, 10 Nov 2010 09:06:03 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hagen Paul Pfeifer References: <20101110152857.GA5094@hell> In-Reply-To: <20101110152857.GA5094@hell> 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: tmrg , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 17:05:50 -0000 FWIW, I'd like to add another point to the discussion. There has been recent concern with "buffer bloat", where home OS's, home routers, etc. all have either poorly optimized or incomplete implementations of fair queuing and socket buffering. The basic problem can be seen as follows: - run a continuous ping anywhere - start a large upload The latencies go from 10-100 milliseconds up t 0.5-5 seconds. This happens because the outbound buffers get stuffed with data. Although a single connection can cause this to happen (it optimizes for rate, not throughput), we know how to handle that - use RED, fair queuing, etc. I'm wondering if increasing the IW can defeat these corrective measures, and recreate the problem in a way that has no effective solution. Has that been considered? Joe From hagen@jauu.net Wed Nov 10 09:19:50 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBCC33A6924 for ; Wed, 10 Nov 2010 09:19:50 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bb4K3aSWpgh for ; Wed, 10 Nov 2010 09:19:50 -0800 (PST) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id C7C643A681D for ; Wed, 10 Nov 2010 09:19:49 -0800 (PST) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 98C43F44195; Wed, 10 Nov 2010 18:20:15 +0100 (CET) Date: Wed, 10 Nov 2010 18:20:08 +0100 From: Hagen Paul Pfeifer To: Joe Touch Message-ID: <20101110172006.GG5094@hell> References: <20101110152857.GA5094@hell> <0C53DCFB700D144284A584F54711EC580B242496@xmb-sjc-21c.amer.cisco.com> <20101110162922.GE5094@hell> <4CDAD0AB.109@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CDAD0AB.109@isi.edu> 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.20 (2009-06-14) Cc: tcpm , tmrg , "Anantha Ramaiah \(ananth\)" , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 17:19:50 -0000 * Joe Touch | 2010-11-10 09:04:43 [-0800]: >See RFC2140. Thank you Joe, this was the source of the idea. I thought about the Linux destination cache and to reuse RTAX_CWND from this metric. Hagen From perfgeek@mac.com Wed Nov 10 09:20:00 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882C63A697F for ; Wed, 10 Nov 2010 09:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRrCHHWNJlF7 for ; Wed, 10 Nov 2010 09:19:59 -0800 (PST) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by core3.amsl.com (Postfix) with ESMTP id BC1593A6956 for ; Wed, 10 Nov 2010 09:19:59 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0LBO00HTKIU2L930@asmtp016.mac.com> for tcpm@ietf.org; Wed, 10 Nov 2010 09:20:27 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1011100104 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-10_06:2010-11-10, 2010-11-10, 1970-01-01 signatures=0 Message-id: <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> From: rick jones To: Hagen Paul Pfeifer In-reply-to: <20101110170017.GF5094@hell> Date: Wed, 10 Nov 2010 09:20:23 -0800 References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> X-Mailer: Apple Mail (2.936) Cc: tmrg , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 17:20:00 -0000 On Nov 10, 2010, at 9:00 AM, Hagen Paul Pfeifer wrote: > * rick jones | 2010-11-10 08:33:30 [-0800]: > >> Do your customers run systems with support for TSO and/or LRO >> enabled, or do they disable that today? TSO can/may/will cause >> 10*MSS or larger blobs of data to be injected into the network at one >> time no? > > No, TSO does not change the packet behavior on the wire. At least no > CC > related mechanisms. Packet spacing and stuff like that ignored here. Earlier you wrote "New data are always pushed into the network in this quantum - a way to much for the standard TCP CC mechanism to tune into a steady state for network with a low BDP." I read that as implying a concern about how much data any one connection injects into the network at any moment in time. TSO does not change what any one packet looks like on the wire, but it certainly does change how many of them rush the wire at one time, yes bounded by cwnd - something those effectively infinite data sources like FTP will be pushing as far as it will go. And depending on whether the stack receiving the LRO-stretched ACKs is counting bytes ACKed or number of ACKs the LRO can induce similar bursty behaviour. >> And LRO can/may induce stretch ACK behaviour not unlike the >> ACK avoidance heuristics of stacks such as those in HP-UX or Solaris. >> What I've seen so far has suggested the goal is to get IW10 "blessed" >> not to make IW10 mandatory. > > If the IETF "blessed" IW10 every vendor will enable it ... And I presume, make it configurable. It is already configurable on a per-route basis in the Linux stack. rick jones http://homepage.mac.com/perfgeek From touch@isi.edu Wed Nov 10 09:29:00 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6533A68BA for ; Wed, 10 Nov 2010 09:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id it82qTdC13v8 for ; Wed, 10 Nov 2010 09:28:59 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id CE2653A689A for ; Wed, 10 Nov 2010 09:28:59 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oAAHS8x6021400 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 10 Nov 2010 09:28:08 -0800 (PST) Message-ID: <4CDAD628.30209@isi.edu> Date: Wed, 10 Nov 2010 09:28:08 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hagen Paul Pfeifer References: <20101110152857.GA5094@hell> <0C53DCFB700D144284A584F54711EC580B242496@xmb-sjc-21c.amer.cisco.com> <20101110162922.GE5094@hell> <4CDAD0AB.109@isi.edu> <20101110172006.GG5094@hell> In-Reply-To: <20101110172006.GG5094@hell> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: oAAHS8x6021400 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm , tmrg , "Anantha Ramaiah \(ananth\)" , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 17:29:00 -0000 On 11/10/2010 9:20 AM, Hagen Paul Pfeifer wrote: > * Joe Touch | 2010-11-10 09:04:43 [-0800]: > >> See RFC2140. > > Thank you Joe, this was the source of the idea. I thought about the Linux > destination cache and to reuse RTAX_CWND from this metric. Yup - FWIW, I think the Linux cache is basically an implementation of what 2140 proposed. Joe From hagen@jauu.net Wed Nov 10 09:40:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489CA3A69C3 for ; Wed, 10 Nov 2010 09:40:40 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKFotkQ5uINC for ; Wed, 10 Nov 2010 09:40:39 -0800 (PST) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id 9FF6A3A6949 for ; Wed, 10 Nov 2010 09:40:37 -0800 (PST) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id A6D8BF44195; Wed, 10 Nov 2010 18:41:04 +0100 (CET) Date: Wed, 10 Nov 2010 18:40:58 +0100 From: Hagen Paul Pfeifer To: rick jones Message-ID: <20101110174056.GH5094@hell> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> 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.20 (2009-06-14) Cc: tmrg , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 17:40:40 -0000 * rick jones | 2010-11-10 09:20:23 [-0800]: >Earlier you wrote "New data are always pushed into the network in >this quantum - a way to much for the standard TCP CC mechanism to tune into a >steady state for network with a low BDP." I read that as implying a concern >about how much data any one connection injects into the network at any moment >in time. To clarify this: I especially focus on the start phase of the connection. If the CC algorithm detects during slow start, congestion avoidance that the available BDP is larger then the IW it is fine. But if the IW is 10, how should _new connections_ react, they always will initially transmit 10 packets - which can be too much - the problem is the initial quantum. >And I presume, make it configurable. It is already configurable on a >per-route basis in the Linux stack. Yes, and you know the statement of davem and other guys if the discussion goes in this direction. Davem is aware of the impact of this knob and I am not sure if everybody is happy about it. I remember a discussion with davem about a HOT-TO-AGGRESSIVELY-TUNE-YOUR-NETWORK-STACK-HOWTO.xml. If these option are available they can be misused. I am happy that the per route knobs are a little bit tricky usable. ;-) Hagen From ycheng@google.com Wed Nov 10 11:15:18 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24DD3A68BA for ; Wed, 10 Nov 2010 11:15:18 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnynJV8wLJS1 for ; Wed, 10 Nov 2010 11:15:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2E88E3A68E4 for ; Wed, 10 Nov 2010 11:15:15 -0800 (PST) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id oAAJFgaY030182 for ; Wed, 10 Nov 2010 11:15:43 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289416543; bh=LhMDVqb+XkD7w0Veziw90marjak=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=bQ/mjdUUC7Fq2gnwDmB3/YTARHVPlvY/tjx0Pbh4/QVL29NKLZnrKtOSQ4E7cofCe rC84kfrGiPIhJ8I/JACuA== Received: from pzk6 (pzk6.prod.google.com [10.243.19.134]) by kpbe19.cbf.corp.google.com with ESMTP id oAAJFTLA030504 for ; Wed, 10 Nov 2010 11:15:41 -0800 Received: by pzk6 with SMTP id 6so288278pzk.18 for ; Wed, 10 Nov 2010 11:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=knfhafxJB1c6Mgcp7obdPww7CPSX4Sr6zc/Pgs8EXn4=; b=ycwliVVw4SR/b+vl+VKGtZtT7elpgIviNFr8KGImSAct8Go2JgzcHu2xeabLC5vuVx 6hl9HGYDn6WqsCRaXXyw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lvImKfzrJtn2mIf7YA93qdTwBJ1wPFDWo2KHm4V2sGx2hHY1iMEvUZ1saX4e1ZImpT K5gnADE9kpIoA8ziyLqw== Received: by 10.142.223.4 with SMTP id v4mr7744887wfg.82.1289416541268; Wed, 10 Nov 2010 11:15:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.194.9 with HTTP; Wed, 10 Nov 2010 11:15:19 -0800 (PST) In-Reply-To: <0C53DCFB700D144284A584F54711EC580B242496@xmb-sjc-21c.amer.cisco.com> References: <20101110152857.GA5094@hell> <0C53DCFB700D144284A584F54711EC580B242496@xmb-sjc-21c.amer.cisco.com> From: Yuchung Cheng Date: Wed, 10 Nov 2010 11:15:19 -0800 Message-ID: To: "Anantha Ramaiah (ananth)" Content-Type: multipart/alternative; boundary=000e0cd25534e8eaf30494b7ae10 X-System-Of-Record: true Cc: tcpm , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 19:15:18 -0000 --000e0cd25534e8eaf30494b7ae10 Content-Type: text/plain; charset=ISO-8859-1 We have done some prior work to address the Africa instance or in general IW10 and IW3 fairness issues. But because we didn't present in the last tcpm but instead iccrg so even we cc'd tcpm of the slides, people may not be aware: We did both live and testbed experiments for the Africa case. The testbed experiment is configured to simulate the links of a particular university in Africa that an IETF member administrates. http://code.google.com/speed/protocols/Increasing_TCPs_Initial_Window_IETF78.pdf Unfortunately, we didn't find much fairness issues. Fred raised concerns using IW10 on residential low-bandwidth network with many flows and/or background in the meeting. We went back and worked on this experiment and Jerry is going to present it in tcpm soon. Independently Michael Scharf also studied IW3 and IW10 issues in his PhD research and reached similar conclusion. We presented his slides in the last ICCRG meeting but due to some copyright issue, please contact him privately for a copy. We plan to include all the feedbacks and our responses/experimental results in the next draft revision, since we want to minimize the revisions and also collect feedback from this meeting as well. Lastly, we do not discuss caching IWs b/c essentially that's a duplication of RFC 2140 and there is no point to write another draft for that. Thanks, Yuchung On Wed, Nov 10, 2010 at 8:04 AM, Anantha Ramaiah (ananth) wrote: > I think the stuff which you are suggesting below has already been > mentioned in earlier conversations (mailing lists, online during the > earlier presentations). Things like "tomorrow someone will come with IW > = 23 etc.,", using the cached information also has been mentioned. The > IW=10 is a fundamental change to TCP and hence the suggestion of moving > this work item to ICCRG also was mentioned before. Someone also pointed > out "will this work in Africa"? Also using a TCP option to agree upon > the IW was mentioned (which is probably less useful since you have to > wait for the 3 way HS to complete and also it is not about end hosts > supporting higher IW, it is about the network property as you rightly > mention below) > > Actually it would be nicer if the authors mention these things in the > document and respond with what their stance is on each of the questions. > This way anyone who reads the document are well informed of the current > stance. > > $0.02, > -Anantha > > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Hagen Paul Pfeifer > Sent: Wednesday, November 10, 2010 7:29 AM > To: Jerry Chu; tmrg; Matt Mathis; tcpm; Lars Eggert > Subject: [tcpm] Increasing the Initial Window - Notes > > Cause tomorrow Jerry will talk about the IW10 topic my 50 cents in > advance. > First some skeptical notes, secondly a alternative approach to increase > the > IW. > > I am skeptical about this draft because IMHO renounce the conservative > principle > towards a aggressive and HTML centric approach (the HTML example is a > bad > allegation, but for FTP and friends slow start is fast enough ;-). My > costumer, > and probably other networks too, operates multi-hop radio networks with > a > bandwidth of less then 100kB/s. > > An increased IW of 10 define 10*~MSS byte as the smallest atomic > in-flight > value. New data are always pushed into the network in this quantum - a > way to > much for the standard TCP CC mechanism to tune into a steady state for > network > with a low BDP. > > In the discussion I miss the impact of the proposed modification > regarding > networks that operates already at a functioning boundary. Are we at a > time > where we loss these types of networks? Where are the simulation results > that > show that the impact at this kind of networks is acceptable? > > > > Alternative idea: can we shift the idea towards a more robust basis. > What about > a increased IW of 10 if we know that the path is capable of an increased > IW? > > Pseudo Algorithm for a new connection: > > a) No cached CC data available > > IW = 4 (standard mechanism a la RFC 5681, 3390) > CC mechanism as usual but save CC parameters - > especially cwnd - per route > > > b) CC data per route is available > > IF (cached_cwnd >= 10) > IW = 10 > else > IW = 4 > > > After n minutes, previously saved CC data is marked as invalid, similar > to the > existing "back to slow start after n minutes idle" mechanism. > > Idea: networks with a low BDP will signal by packet drop or ECN marking > that > congestion occur and the BDP is saturated. Why not use actual network > information to setup the IW but preserve the conservative nature of TCP? > > Maybe this is an approach for further discussions, I have a curious > feeling > that in 2 years the same discussion will start with a IW of 23 ... So > maybe we > should drop the static IW approach completely and define IW as > cached_steady_state_cwnd / 2 for cached routes and IW = 4 for startup > all other > cases. > > > Best regards, Hagen > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000e0cd25534e8eaf30494b7ae10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We have done some prior work to address the Africa instance or in gene= ral IW10 and IW3 fairness issues. But because we didn't present in the = last tcpm but instead iccrg so even we cc'd tcpm of the slides, people = may not be aware:

We did=A0both live and testbed experiments for the Afri= ca case. The testbed experiment is configured to simulate the links of a pa= rticular university in Africa that an IETF member administrates.=A0
http://code.google.com/speed/protocols/Increasing_TCPs_Init= ial_Window_IETF78.pdf

Unfortunately, we didn't find much fairness issues.= Fred raised concerns using IW10 on residential low-bandwidth network with = many flows and/or background in the meeting. We went back and worked on thi= s experiment and Jerry is going to present it in tcpm soon.

Independently Michael Scharf also studied IW3 and IW10 = issues in his PhD research and reached similar conclusion. We presented his= slides in the last ICCRG meeting but due to some copyright issue, please c= ontact him privately for a copy.

We plan to include all the feedbacks and our responses/= experimental results in the next draft revision, since we want to minimize = the revisions and also collect feedback from this meeting as well.

Lastly, we do not discuss caching IWs b/c essentially t= hat's a duplication of RFC 2140 and there is no point to write another = draft for that.

Thanks,

Yuchung










On Wed, Nov 10, 2010 at 8:04 AM, Anantha Ramaiah (an= anth) <ananth@cisc= o.com> wrote:
I think the stuff which you are suggesting = below has already been
mentioned in earlier conversations (mailing lists, online during the
earlier presentations). Things like "tomorrow someone will come with I= W
=3D 23 etc.,", using the cached information also has been mentioned. T= he
IW=3D10 is a fundamental change to TCP and hence the suggestion of moving this work item to ICCRG also was mentioned before. Someone also pointed
out "will this work in Africa"? =A0Also using a TCP option to agr= ee upon
the IW was mentioned (which is probably less useful since you have to
wait for the 3 way HS to complete and also it is not about end hosts
supporting higher IW, it is about the network property as you rightly
mention below)

Actually it would be nicer if the authors mention these things in the
document and respond with what their stance is on each of the questions. This way anyone who reads the document are well informed of the current
stance.

$0.02,
-Anantha

-----Original Message-----
From: tcpm-bounces@ietf.org [m= ailto:tcpm-bounces@ietf.org] O= n Behalf Of
Hagen Paul Pfeifer
Sent: Wednesday, November 10, 2010 7:29 AM
To: Jerry Chu; tmrg; Matt Mathis; tcpm; Lars Eggert
Subject: [tcpm] Increasing the Initial Window - Notes

Cause tomorrow Jerry will talk about the IW10 topic my 50 cents in
advance.
First some skeptical notes, secondly a alternative approach to increase
the
IW.

I am skeptical about this draft because IMHO renounce the conservative
principle
towards a aggressive and HTML centric approach (the HTML example is a
bad
allegation, but for FTP and friends slow start is fast enough ;-). My
costumer,
and probably other networks too, operates multi-hop radio networks with
a
bandwidth of less then 100kB/s.

An increased IW of 10 define 10*~MSS byte as the smallest atomic
in-flight
value. New data are always pushed into the network in this quantum - a
way to
much for the standard TCP CC mechanism to tune into a steady state for
network
with a low BDP.

In the discussion I miss the impact of the proposed modification
regarding
networks that operates already at a functioning boundary. Are we at a
time
where we loss these types of networks? Where are the simulation results
that
show that the impact at this kind of networks is acceptable?



Alternative idea: can we shift the idea towards a more robust basis.
What about
a increased IW of 10 if we know that the path is capable of an increased IW?

Pseudo Algorithm for a new connection:

=A0 =A0 =A0 =A0a) No cached CC data available

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IW =3D 4 (standard mechanism a la RFC 5681,= 3390)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CC mechanism as usual but save CC parameter= s -
especially cwnd - per route


=A0 =A0 =A0 =A0b) CC data per route is available

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IF (cached_cwnd >=3D 10)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IW =3D 10
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IW =3D 4


After n minutes, previously saved CC data is marked as invalid, similar
to the
existing "back to slow start after n minutes idle" mechanism.

Idea: networks with a low BDP will signal by packet drop or ECN marking
that
congestion occur and the BDP is saturated. Why not use actual network
information to setup the IW but preserve the conservative nature of TCP?
Maybe this is an approach for further discussions, I have a curious
feeling
that in 2 years the same discussion will start with a IW of 23 ... So
maybe we
should drop the static IW approach completely and define IW as
cached_steady_state_cwnd / 2 for cached routes and IW =3D 4 for startup
all other
cases.


Best regards, Hagen
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--000e0cd25534e8eaf30494b7ae10-- From rs@netapp.com Wed Nov 10 11:29:21 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E385E3A69D8 for ; Wed, 10 Nov 2010 11:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKxmrlJ9cn0R for ; Wed, 10 Nov 2010 11:29:21 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id A69F43A6821 for ; Wed, 10 Nov 2010 11:29:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,179,1288594800"; d="scan'208";a="225635505" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 10 Nov 2010 11:29:47 -0800 Received: from ldcrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oAAJTl0o019918; Wed, 10 Nov 2010 11:29:47 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Nov 2010 19:29:46 +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: Wed, 10 Nov 2010 19:27:29 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B65C814@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Increasing TCP's Initial Congestion Thread-Index: AcuBDVCuBA27FU5TSZaEq60S69mRKg== From: "Scheffenegger, Richard" To: "Jerry Chu" , "Yaogong Wang" X-OriginalArrivalTime: 10 Nov 2010 19:29:46.0905 (UTC) FILETIME=[A2618890:01CB810D] Cc: Arvind Jain , tcpm , Matt Mathis Subject: [tcpm] Increasing TCP's Initial Congestion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 19:29:22 -0000 Hi Jerry, Yaogong, Reading your slides (i won't be online when you give your talk): http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf | Is SACK required for IW10 to Perform? |=20 | * From the testbed at Google | - SACK does help reducing UCT but only by a small | percentage for both IW10 and IW3 | * 24 hours, 3-way parallel experiment at Google's | frontend servers | - IW10+NewReno still beats IW3+SACK | | Photos download Avg response time Retransmission rate | IW10+SACK 2.6secs 4.1% | IW10+NewReno 2.8secs 4.1% | IW3+SACK 3.0secs 3.3% | November 11, 2010 79th IETF, Beijing China 19 First, let me thank you for conducting these experiments with SACK and NewReno.=20 My comment at IETF78 was that Linux SACK (since 2.4.xx) can detect lost retransmissions, and recover from them;=20 On the 2nd slide you paraphrase this: | How does IW10 perform | when SACK is either not available, or not adequately | implemented? Did you disable this aspect of Linux SACK during your tests (to have a RFC3517 compliant SACK sender)? Also, IIRC, Linux 2.6.2x already implements draft-jarvinen-tcpm-sack-recovery-entry-02.txt // RFC3517bis. I assume the fraction of lost retransmissions and early recovery entries was small (afaik, Linux records these events individually). If these counters were zero during your the testing, I'm fully satisfied. I'm just worried that a good fraction of loss recovery was due to these recent features (not widely available on other stacks), causing grief if one simply tries to do IW10 without these other modifications. Also, this comment on slide 13 indicates, that some flows had to do RTO-based loss recovery, correct? | * Under heavy load IW10 lost UCT advantage due to high PLR | * IW10 UCT exhibits long tails=20 Did you get traces off your testbed to investigate these long tail flows further? One of the reasons might be the recent observation, that with short flows, NewReno can sometimes recover more speedy than SACK ( http://www.ietf.org/mail-archive/web/tcpm/current/msg05875.html ). (RecoveryPoint is close to the end-of-stream, and at least the last segment prior to RP was lost). The other reason could be, that SACK retransmissions are lost, but Linux can not recover them any more. (RecoveryPoint is at the end-of-stream). There might be additional cases causing RTO, though... I would be very interested in looking at these long tail (high latency) flow traces myself. Richard Scheffenegger From rs@netapp.com Wed Nov 10 11:29:31 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8E53A68F9 for ; Wed, 10 Nov 2010 11:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSkC5NgTumJr for ; Wed, 10 Nov 2010 11:29:30 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 1679C3A6821 for ; Wed, 10 Nov 2010 11:29:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,179,1288594800"; d="scan'208";a="218847960" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 10 Nov 2010 11:29:46 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oAAJTkLK019913; Wed, 10 Nov 2010 11:29:46 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Nov 2010 19:29:46 +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: Wed, 10 Nov 2010 19:29:45 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B65C812@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20101110162922.GE5094@hell> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Increasing the Initial Window - Notes Thread-Index: AcuA9HixOjzJUF7WTS64TEl0UUfiLQABJ6Fw References: <20101110152857.GA5094@hell><0C53DCFB700D144284A584F54711EC580B242496@xmb-sjc-21c.amer.cisco.com> <20101110162922.GE5094@hell> From: "Scheffenegger, Richard" To: "Hagen Paul Pfeifer" , "Anantha Ramaiah (ananth)" X-OriginalArrivalTime: 10 Nov 2010 19:29:46.0364 (UTC) FILETIME=[A20EFBC0:01CB810D] Cc: tcpm , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 19:29:31 -0000 Hagen, Regarding cached cwnd: that would assume that you already have some past expirience with the host (a), but also that your previous interaction was transporting enough (bulk) data to arrive at some steady state(b)... >From my understanding, for the suggested use case (minimize delivery latency of "small" flows, sent out of big server farms), that might not be possible to achive. Or am I wrong? For your use case (networks with small BDP), shouldn't the receiver be able to signal an accordingly small window (in comparison with the window which is likely being signalled when the user is connected to a fat pipe)? (Is there are correlation between configured tcp receive window size, and maximum bulk transfer speeds within the public internet? Or are default parameters used without correlation to the actual possible bulk transfer speeds?) I have mentioned this earlier (but got swayed a bit) that some cheap home gateways may have very small buffer sizes, which could be overwhelmed as well if initcwnd=3D10 is used. OTOH, your average server does not reside beind a home gateway box (and if, you may be inclined to upgrade that box for more reliable service anyway)... As you say, bursting 10 MSS segments at wirespeed onto a bottleneck might not be all that bright an idea, especially if the bottleneck is close to the sender, and runs at a significantly lower speed (ie. 1Gbps internal, 54Mbps phys public, rate limited to 1Mbps) Just a thought: Perhaps pacing or chirping (inverse chirping, to be specific) can be used to address the issue of burst overloading a small first hop queue; for internet RTTs, the pacing interval would still be minuscle, but would allow the queues to drain somewhat... __ __ __ __ __ __ __ __ __ __ __ __|S |_/~/_ _|D |D |D |D ||D |_|D |__|D |___|D |____|D |_____|D |_/~/_ _/~/_ .... |SA| |A| |A| =20 Obviously, that would need somewhat more fine-grained tcp timers (ie. 1ms, with the pacing/chirping interval increasing by some factor for each additional segment sent, until a new, higher initcwnd is reached, or the ACK from the receiver starts the ACK clock...) That would be similar to the RTO backoff, just with a couple magnitude smaller timescales, and the sending of new data instead of the resending of the same data... Also, we wouldn't necessarily have a discussion for any arbitrary initcwnd soon again ;) Wasn't there a study to be conducted on the behavior of home gateways (queue depths, forwarding rates, behavior on unknown tcp options etc)? I think for Africa / South America, if initcwnd is used on server side (and the bottleneck bandwidht likely to be approched in multiple, small steps) there was some research presented since maastricht, not? Richard Scheffenegger =20 > -----Original Message----- > From: Hagen Paul Pfeifer [mailto:hagen@jauu.net]=20 > Sent: Mittwoch, 10. November 2010 17:29 > To: Anantha Ramaiah (ananth) > Cc: tmrg; Matt Mathis; tcpm > Subject: Re: [tcpm] Increasing the Initial Window - Notes >=20 > * Anantha Ramaiah (ananth) | 2010-11-10 08:04:48 [-0800]: >=20 > >I think the stuff which you are suggesting below has already been=20 > >mentioned in earlier conversations (mailing lists, online during the=20 > >earlier presentations). Things like "tomorrow someone will=20 > come with IW=20 > >=3D 23 etc.,", using the cached information also has been=20 > mentioned. The=20 > >IW=3D10 is a fundamental change to TCP and hence the=20 > suggestion of moving=20 > >this work item to ICCRG also was mentioned before. Someone=20 > also pointed=20 > >out "will this work in Africa"? Also using a TCP option to=20 > agree upon=20 > >the IW was mentioned (which is probably less useful since=20 > you have to=20 > >wait for the 3 way HS to complete and also it is not about end hosts=20 > >supporting higher IW, it is about the network property as=20 > you rightly=20 > >mention below) >=20 > I am aware about "IW >=3D 23" and the Africa discussion. For me=20 > the later is a strong reason for a refusal of the draft. I am=20 > not aware of the discussion of the _cached cwnd_ approach. >=20 > Hagen >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From ycheng@google.com Wed Nov 10 12:04:47 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10C53A6852 for ; Wed, 10 Nov 2010 12:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.976 X-Spam-Level: X-Spam-Status: No, score=-109.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVC2RCSRHISW for ; Wed, 10 Nov 2010 12:04:46 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A827B3A698D for ; Wed, 10 Nov 2010 12:04:45 -0800 (PST) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id oAAK5Chx010761 for ; Wed, 10 Nov 2010 12:05:12 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289419512; bh=/J14nPyGBHYQ8grws/8qncchMzI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=cryX6HGnua69khoRJz+S/nxIlQ9DCedh8xfJ0dj8KAxgKDxdpg6jJ/zRdjgTzkx8f MTgKO9/n8d5wyfEnzZM8A== Received: from ywk9 (ywk9.prod.google.com [10.192.11.9]) by hpaq1.eem.corp.google.com with ESMTP id oAAK4SoR006280 for ; Wed, 10 Nov 2010 12:05:11 -0800 Received: by ywk9 with SMTP id 9so711188ywk.30 for ; Wed, 10 Nov 2010 12:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=45kY66hF2XNn/rd63n9CTAjb2mug+GQJGjtZdDx2/nM=; b=hLgjaXoAtbtb4bWaU/VFX6OYr1CuBrDO2MjMCk0WH9ZLSo+BAMxtrPjVCjOf1FJD2j 0Ufn74QJt/h1H1N3Kq2A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=xQxhK29nvYO6lToiPqQCg7s17cTja2+bDfZLpbio2Fbz1zoono2R0vqfZzTO22f6ir q03ul2FJ0lXcEFpaEDOA== Received: by 10.42.225.196 with SMTP id it4mr1788084icb.392.1289419509839; Wed, 10 Nov 2010 12:05:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.194.9 with HTTP; Wed, 10 Nov 2010 12:04:48 -0800 (PST) In-Reply-To: <20101110152857.GA5094@hell> References: <20101110152857.GA5094@hell> From: Yuchung Cheng Date: Wed, 10 Nov 2010 12:04:48 -0800 Message-ID: To: Hagen Paul Pfeifer Content-Type: multipart/alternative; boundary=20cf30549fd1d9c1b40494b85fb2 X-System-Of-Record: true Cc: Mike Belshe , tcpm , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 20:04:47 -0000 --20cf30549fd1d9c1b40494b85fb2 Content-Type: text/plain; charset=ISO-8859-1 Hagen, Please see my earlier response to the caching suggestions and simulation/experiment questions. Our draft suggests TCP MAY set the initial window of 10. The host can pick their best initial cwnd based on their network properties if appropriate or implement RFC2140. If raising IW upper bound is too aggressive and should be rejected as a MAY clause, I argue IW3 is also too aggressive for some networks too. But RFC 3390 suggests raising IW3 primarily because of web objects size distribution at that time. Further, we do not propose changing the response function of TCP, which is the most critical part of maintaining the network stable. Let's do a reality check: today browsers open tens of flows simultaneously to work around small TCP IW (http://www.browserscope.org/ the "network tab). A study from AT&T and U of Mich also show 15% TCP flows observed in AT&T network already go over IW3. We want to bring this issue to the IETF community/experts to stop this downward spiral of sneaky unfair latency "tune-ups". Cheers, Yuchung On Wed, Nov 10, 2010 at 7:29 AM, Hagen Paul Pfeifer wrote: > Cause tomorrow Jerry will talk about the IW10 topic my 50 cents in advance. > First some skeptical notes, secondly a alternative approach to increase the > IW. > > I am skeptical about this draft because IMHO renounce the conservative > principle > towards a aggressive and HTML centric approach (the HTML example is a bad > allegation, but for FTP and friends slow start is fast enough ;-). My > costumer, > and probably other networks too, operates multi-hop radio networks with a > bandwidth of less then 100kB/s. > > An increased IW of 10 define 10*~MSS byte as the smallest atomic in-flight > value. New data are always pushed into the network in this quantum - a way > to > much for the standard TCP CC mechanism to tune into a steady state for > network > with a low BDP. > > In the discussion I miss the impact of the proposed modification regarding > networks that operates already at a functioning boundary. Are we at a time > where we loss these types of networks? Where are the simulation results > that > show that the impact at this kind of networks is acceptable? > > > > Alternative idea: can we shift the idea towards a more robust basis. What > about > a increased IW of 10 if we know that the path is capable of an increased > IW? > > Pseudo Algorithm for a new connection: > > a) No cached CC data available > > IW = 4 (standard mechanism a la RFC 5681, 3390) > CC mechanism as usual but save CC parameters - especially > cwnd - per route > > > b) CC data per route is available > > IF (cached_cwnd >= 10) > IW = 10 > else > IW = 4 > > > After n minutes, previously saved CC data is marked as invalid, similar to > the > existing "back to slow start after n minutes idle" mechanism. > > Idea: networks with a low BDP will signal by packet drop or ECN marking > that > congestion occur and the BDP is saturated. Why not use actual network > information to setup the IW but preserve the conservative nature of TCP? > > Maybe this is an approach for further discussions, I have a curious feeling > that in 2 years the same discussion will start with a IW of 23 ... So maybe > we > should drop the static IW approach completely and define IW as > cached_steady_state_cwnd / 2 for cached routes and IW = 4 for startup all > other > cases. > > > Best regards, Hagen > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --20cf30549fd1d9c1b40494b85fb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hagen,

Please see my earlier response to the = caching suggestions and simulation/experiment questions.

Our draft suggests TCP MAY set the initial window of 10. The host ca= n pick their best initial cwnd based on their network properties if appropr= iate or implement =A0RFC2140.

If raising IW upper bound is too aggressive and should = be rejected as a MAY clause, I argue IW3 is also too aggressive for some ne= tworks too. But RFC 3390 suggests raising IW3 primarily because of web obje= cts size distribution at that time. Further, we do not propose changing the= response function of TCP, which is the most critical part of maintaining t= he network stable.

Let's do a reality check: today browsers open tens = of flows simultaneously to work around small TCP IW (http://www.browserscope.org/=A0=A0the "network = tab). A study from AT&T and U of Mich also show 15% TCP flows observed = in AT&T network already go over IW3. We want to bring this issue to the= IETF community/experts to stop this downward spiral of sneaky unfair laten= cy "tune-ups".

Cheers,

Yuchung

=


On Wed, Nov = 10, 2010 at 7:29 AM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
Cause tomorrow Jerry will talk about the IW= 10 topic my 50 cents in advance.
First some skeptical notes, secondly a alternative approach to increase the=
IW.

I am skeptical about this draft because IMHO renounce the conservative prin= ciple
towards a aggressive and HTML centric approach (the HTML example is a bad allegation, but for FTP and friends slow start is fast enough ;-). My costu= mer,
and probably other networks too, operates multi-hop radio networks with a bandwidth of less then 100kB/s.

An increased IW of 10 define 10*~MSS byte as the smallest atomic in-flight<= br> value. New data are always pushed into the network in this quantum - a way = to
much for the standard TCP CC mechanism to tune into a steady state for netw= ork
with a low BDP.

In the discussion I miss the impact of the proposed modification regarding<= br> networks that operates already at a functioning boundary. Are we at a time<= br> where we loss these types of networks? Where are the simulation results tha= t
show that the impact at this kind of networks is acceptable?



Alternative idea: can we shift the idea towards a more robust basis. What a= bout
a increased IW of 10 if we know that the path is capable of an increased IW= ?

Pseudo Algorithm for a new connection:

=A0 =A0 =A0 =A0a) No cached CC data available

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IW =3D 4 (standard mechanism a la RFC 5681,= 3390)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CC mechanism as usual but save CC parameter= s - especially cwnd - per route


=A0 =A0 =A0 =A0b) CC data per route is available

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IF (cached_cwnd >=3D 10)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IW =3D 10
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IW =3D 4


After n minutes, previously saved CC data is marked as invalid, similar to = the
existing "back to slow start after n minutes idle" mechanism.

Idea: networks with a low BDP will signal by packet drop or ECN marking tha= t
congestion occur and the BDP is saturated. Why not use actual network
information to setup the IW but preserve the conservative nature of TCP?
Maybe this is an approach for further discussions, I have a curious feeling=
that in 2 years the same discussion will start with a IW of 23 ... So maybe= we
should drop the static IW approach completely and define IW as
cached_steady_state_cwnd / 2 for cached routes and IW =3D 4 for startup all= other
cases.


Best regards, Hagen
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--20cf30549fd1d9c1b40494b85fb2-- From hkchu@google.com Wed Nov 10 14:39:28 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097C53A679F for ; Wed, 10 Nov 2010 14:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.977 X-Spam-Level: X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgUMkXfVxgNx for ; Wed, 10 Nov 2010 14:39:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id B19FF3A6781 for ; Wed, 10 Nov 2010 14:38:07 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id oAAMcYxN004923 for ; Wed, 10 Nov 2010 14:38:34 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289428715; bh=Adeet5c0RMF7z7k0WAjx9ux0zQE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=CfuBlW7oC3LsGc89YWt9CAeDp3NMKVWjokEneG8vtv1HbH9Ws40vBk7kj8Jc7AdYZ RkkqC+pEkXHRZefTQdE6A== Received: from ywa8 (ywa8.prod.google.com [10.192.1.8]) by kpbe14.cbf.corp.google.com with ESMTP id oAAMbrTj007538 for ; Wed, 10 Nov 2010 14:38:33 -0800 Received: by ywa8 with SMTP id 8so303208ywa.27 for ; Wed, 10 Nov 2010 14:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JEqBYSlntnQeQGt2Eo5ZUwRmmDvHmfga5X4WGpLfCng=; b=AennuV93oW/psY/hqsRwKI9a+k3Ppp40g1CoGzWGmv5GI2K208djrN+m4wfk4cBTXv Dzf8XuoUtIUAukWvEYlg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TMWp5fs82taR0eNQPQaEzjYsi0M8p7vX1AHrzjezk99bNO/D45A51+5gAFLdFhNUMQ H7ObHUmI7o6DHaWmE3IA== MIME-Version: 1.0 Received: by 10.150.91.13 with SMTP id o13mr431068ybb.6.1289428711845; Wed, 10 Nov 2010 14:38:31 -0800 (PST) Received: by 10.150.145.4 with HTTP; Wed, 10 Nov 2010 14:38:31 -0800 (PST) In-Reply-To: <20101110152857.GA5094@hell> References: <20101110152857.GA5094@hell> Date: Wed, 10 Nov 2010 14:38:31 -0800 Message-ID: From: Jerry Chu To: Hagen Paul Pfeifer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 22:39:28 -0000 On Wed, Nov 10, 2010 at 7:29 AM, Hagen Paul Pfeifer wrote: > > Cause tomorrow Jerry will talk about the IW10 topic my 50 cents in advanc= e. > First some skeptical notes, secondly a alternative approach to increase t= he > IW. > > I am skeptical about this draft because IMHO renounce the conservative pr= inciple > towards a aggressive and HTML centric approach (the HTML example is a bad > allegation, but for FTP and friends slow start is fast enough ;-). My cos= tumer, TCP's slow start being too slow for not just HTTP traffic but also median size data transfers has been a well-known issue in the community and active research = on faster startup schemes has been ongoing for years. But you seem to be again= st the rest of us and saying this is not a problem at all? > > and probably other networks too, operates multi-hop radio networks with a > bandwidth of less then 100kB/s. Folks from Nokia have been actively investigating the effect of IW10 in a r= adio network so I'll defer to their findings. I'd only make two points from our testbed study on slow (96Kbps) links: 1. There is no denying that IW10 tends to cause higher packet drop rate dur= ing congestion. (Don't get too turned off by some high packet drop rate in my s= lides because some of the testcases were designed to be extreme in order to get t= o the worst case, and it looks like the worst case we've found for IW10, it w= as also terrible for IW3 (e.g., UCT > 50secs). 2. Regardless of IW10's higher packet drop rate, it's flow completion time = has been consistently better, or at least not worse than IW3's. Some explanatio= n of it was given in my slides. 3. In a multi-hop multi-congestion-point mobile network the high packet dro= p rate may cause more damage due to the waste of bandwidth on the path leading to the final congestion drop point. Our testbed has only one conges= tion point so doesn't exhibit this problem. I think folks from Nokia are concern= ed with this problem and I'll defer this to them. > > An increased IW of 10 define 10*~MSS byte as the smallest atomic in-fligh= t > value. New data are always pushed into the network in this quantum - a wa= y to > much for the standard TCP CC mechanism to tune into a steady state for ne= twork > with a low BDP. Do you have any real numbers to backup your claim here? Numbers from our li= ve tests at Google's frontends seem to contradict to your statement here. > > In the discussion I miss the impact of the proposed modification regardin= g > networks that operates already at a functioning boundary. Are we at a tim= e > where we loss these types of networks? Where are the simulation results t= hat > show that the impact at this kind of networks is acceptable? See past email threads and slides. > > > > Alternative idea: can we shift the idea towards a more robust basis. What= about > a increased IW of 10 if we know that the path is capable of an increased = IW? > > Pseudo Algorithm for a new connection: > > =A0 =A0 =A0 =A0a) No cached CC data available > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IW =3D 4 (standard mechanism a la RFC 5681= , 3390) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CC mechanism as usual but save CC paramete= rs - especially cwnd - per route > > > =A0 =A0 =A0 =A0b) CC data per route is available > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IF (cached_cwnd >=3D 10) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IW =3D 10 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IW =3D 4 > > > After n minutes, previously saved CC data is marked as invalid, similar t= o the > existing "back to slow start after n minutes idle" mechanism. > > Idea: networks with a low BDP will signal by packet drop or ECN marking t= hat > congestion occur and the BDP is saturated. Why not use actual network > information to setup the IW but preserve the conservative nature of TCP? > > Maybe this is an approach for further discussions, I have a curious feeli= ng > that in 2 years the same discussion will start with a IW of 23 ... So may= be we > should drop the static IW approach completely and define IW as > cached_steady_state_cwnd / 2 for cached routes and IW =3D 4 for startup a= ll other > cases. You are late to the party :). All the above and more has been presented/discussed/ debated in the past already. To make it short, we first tried tweaking Linu= x dst cache like you described above but found it not very effective (e.g., cache= hit rate was low...) Then we tried an off-line history database approach but found it too complicated. Finally we decided a moderate increase of IW is the right,= and timely solution (until someone else like you could find the optimal or completely scalable solution to solve the global warming problem :). Following the KIS= S principle, we'd open to any amendment based on info collected during 3WHS but will be prejudiced against any other states that need to collected and = kept from the past. I see your name on the attendee list. If you like to chat more you can find= me at CONEX this morning. I'll probably take a front row seat there. Best, Jerry > > > Best regards, Hagen From hkchu@google.com Wed Nov 10 14:47:13 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6AB3A6784 for ; Wed, 10 Nov 2010 14:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.977 X-Spam-Level: X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9In0QSLiwjqZ for ; Wed, 10 Nov 2010 14:47:00 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 906D53A6783 for ; Wed, 10 Nov 2010 14:46:57 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id oAAMlOK6019368 for ; Wed, 10 Nov 2010 14:47:25 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289429245; bh=coCnPAP+cKf52F8J5YMOPXL5mOg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=FaN8t80zPKq4EMAJZ3VcSWXstcDltN3bwPddAQlkVK6l7MAJhzvqxMaQtGGZw/MJ8 H4oJ1FePAoP/P920HMe/A== Received: from yxt33 (yxt33.prod.google.com [10.190.5.225]) by wpaz29.hot.corp.google.com with ESMTP id oAAMlNCp023218 for ; Wed, 10 Nov 2010 14:47:23 -0800 Received: by yxt33 with SMTP id 33so475996yxt.9 for ; Wed, 10 Nov 2010 14:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RfkUC4xuRPipeTmKmEGSePUCMO++MVDH4B/rh3MMS9U=; b=OA4xPvLAwp6QodiI7qrqQSOm9jhbyijho6jY5wqZxa1QkeK+lnDJfk9BKIZ5xFEldA Jh+4lFWAbcV2AHj0571Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qJvnOBQTLrSV7JVpFkATCvVgdZS7Zo7CZKM9eZvDEuk2+nw2lq2YWtWQgxeCTbeQez UkNKzf1Wdyve91kVcCsw== MIME-Version: 1.0 Received: by 10.150.205.20 with SMTP id c20mr355504ybg.405.1289429242991; Wed, 10 Nov 2010 14:47:22 -0800 (PST) Received: by 10.150.145.4 with HTTP; Wed, 10 Nov 2010 14:47:22 -0800 (PST) In-Reply-To: <0C53DCFB700D144284A584F54711EC580B242496@xmb-sjc-21c.amer.cisco.com> References: <20101110152857.GA5094@hell> <0C53DCFB700D144284A584F54711EC580B242496@xmb-sjc-21c.amer.cisco.com> Date: Wed, 10 Nov 2010 14:47:22 -0800 Message-ID: From: Jerry Chu To: "Anantha Ramaiah (ananth)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tmrg , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 22:47:13 -0000 Anantha, Thanks for point out the following to Hagen. Yes I must apologize. The draft has been overdue for a major revision for a while. We first tried to do it after summer IETF but were all busy with other work (and some involves new "Make the Web Faster" proposal to IETF that we will present in the near future). We will try to get a major revision done and published before year end. In the meantime one has to go back to the list and slides from the past. Thanks, Jerry On Wed, Nov 10, 2010 at 8:04 AM, Anantha Ramaiah (ananth) wrote: > I think the stuff which you are suggesting below has already been > mentioned in earlier conversations (mailing lists, online during the > earlier presentations). Things like "tomorrow someone will come with IW > =3D 23 etc.,", using the cached information also has been mentioned. The > IW=3D10 is a fundamental change to TCP and hence the suggestion of moving > this work item to ICCRG also was mentioned before. Someone also pointed > out "will this work in Africa"? =A0Also using a TCP option to agree upon > the IW was mentioned (which is probably less useful since you have to > wait for the 3 way HS to complete and also it is not about end hosts > supporting higher IW, it is about the network property as you rightly > mention below) > > Actually it would be nicer if the authors mention these things in the > document and respond with what their stance is on each of the questions. > This way anyone who reads the document are well informed of the current > stance. > > $0.02, > -Anantha > > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Hagen Paul Pfeifer > Sent: Wednesday, November 10, 2010 7:29 AM > To: Jerry Chu; tmrg; Matt Mathis; tcpm; Lars Eggert > Subject: [tcpm] Increasing the Initial Window - Notes > > Cause tomorrow Jerry will talk about the IW10 topic my 50 cents in > advance. > First some skeptical notes, secondly a alternative approach to increase > the > IW. > > I am skeptical about this draft because IMHO renounce the conservative > principle > towards a aggressive and HTML centric approach (the HTML example is a > bad > allegation, but for FTP and friends slow start is fast enough ;-). My > costumer, > and probably other networks too, operates multi-hop radio networks with > a > bandwidth of less then 100kB/s. > > An increased IW of 10 define 10*~MSS byte as the smallest atomic > in-flight > value. New data are always pushed into the network in this quantum - a > way to > much for the standard TCP CC mechanism to tune into a steady state for > network > with a low BDP. > > In the discussion I miss the impact of the proposed modification > regarding > networks that operates already at a functioning boundary. Are we at a > time > where we loss these types of networks? Where are the simulation results > that > show that the impact at this kind of networks is acceptable? > > > > Alternative idea: can we shift the idea towards a more robust basis. > What about > a increased IW of 10 if we know that the path is capable of an increased > IW? > > Pseudo Algorithm for a new connection: > > =A0 =A0 =A0 =A0a) No cached CC data available > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IW =3D 4 (standard mechanism a la RFC 5681= , 3390) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CC mechanism as usual but save CC paramete= rs - > especially cwnd - per route > > > =A0 =A0 =A0 =A0b) CC data per route is available > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IF (cached_cwnd >=3D 10) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IW =3D 10 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IW =3D 4 > > > After n minutes, previously saved CC data is marked as invalid, similar > to the > existing "back to slow start after n minutes idle" mechanism. > > Idea: networks with a low BDP will signal by packet drop or ECN marking > that > congestion occur and the BDP is saturated. Why not use actual network > information to setup the IW but preserve the conservative nature of TCP? > > Maybe this is an approach for further discussions, I have a curious > feeling > that in 2 years the same discussion will start with a IW of 23 ... So > maybe we > should drop the static IW approach completely and define IW as > cached_steady_state_cwnd / 2 for cached routes and IW =3D 4 for startup > all other > cases. > > > Best regards, Hagen > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From hkchu@google.com Wed Nov 10 15:13:17 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928543A67A1 for ; Wed, 10 Nov 2010 15:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.47 X-Spam-Level: X-Spam-Status: No, score=-104.47 tagged_above=-999 required=5 tests=[AWL=1.508, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+HuQh-j7odJ for ; Wed, 10 Nov 2010 15:13:16 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3F1293A67A3 for ; Wed, 10 Nov 2010 15:13:16 -0800 (PST) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id oAANDhlb026613 for ; Wed, 10 Nov 2010 15:13:43 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289430824; bh=BJlMaPA/R9a8/7+4tN/CV1CRT4w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Ky6WeNut7nlTvPK8Z+Rg3S4M6+dB+Opu6FQ1Gi/G6E6wmnCpMBSQinKfxzG5uVLzM gDhO7RvgL0s41FuHSgK9A== Received: from gwj15 (gwj15.prod.google.com [10.200.10.15]) by hpaq5.eem.corp.google.com with ESMTP id oAANDfZD020450 for ; Wed, 10 Nov 2010 15:13:42 -0800 Received: by gwj15 with SMTP id 15so876562gwj.21 for ; Wed, 10 Nov 2010 15:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3TkkNjNZSw5QIcOlipEVUKeeNMb/HP2AEz+ey4B8nNY=; b=t0DJHemUPORrTspt9W+24oEtwjUrWtypLaXVlDzHJogKGoCcaBkIDdtyfL8ofc1/M6 dSOZt34sm8wdcfszYorw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Oa7pXF6tLkWbYIsSWhejcoGxJDrg5csK+BST8/tf1Vz3iXiVfKA33YiRDRSUmqUwHR rvW9INk8g4xt7GOclL2Q== MIME-Version: 1.0 Received: by 10.150.91.13 with SMTP id o13mr485614ybb.6.1289430821461; Wed, 10 Nov 2010 15:13:41 -0800 (PST) Received: by 10.150.145.4 with HTTP; Wed, 10 Nov 2010 15:13:41 -0800 (PST) In-Reply-To: <4CDAD0FB.6060602@isi.edu> References: <20101110152857.GA5094@hell> <4CDAD0FB.6060602@isi.edu> Date: Wed, 10 Nov 2010 15:13:41 -0800 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 , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 23:13:17 -0000 + yaogong Joe, You brought up a good question. We don't have any direct data on the scenar= io you described. Also we've used FIFO tail drop so far hence haven't tried an= y AQM algorithm on the router. Otherwise our testbed data showed under high load and some extreme case (e.g., a constantly 5-simultaneous open bursts) the average qlen of IW10 can get much longer than that of IW3, although und= er those loaded conditions IW3 is already bad enough. To really answer your question, I'd suggest you to go to http://research.csc.ncsu.edu/netsrv/?q=3Dcontent/iw10 and tell us how to modify the test setup/parameters/programs to emulate the exact condition you have in mind. I'm sure our collaboration Yaogong Wang f= rom NCSU will be happy to run some results for you. Thanks, Jerry On Wed, Nov 10, 2010 at 9:06 AM, Joe Touch wrote: > FWIW, I'd like to add another point to the discussion. > > There has been recent concern with "buffer bloat", where home OS's, home > routers, etc. all have either poorly optimized or incomplete implementati= ons > of fair queuing and socket buffering. > > The basic problem can be seen as follows: > =A0 =A0 =A0 =A0- run a continuous ping anywhere > =A0 =A0 =A0 =A0- start a large upload > > The latencies go from 10-100 milliseconds up t 0.5-5 seconds. This happen= s > because the outbound buffers get stuffed with data. > > Although a single connection can cause this to happen (it optimizes for > rate, not throughput), we know how to handle that - use RED, fair queuing= , > etc. > > I'm wondering if increasing the IW can defeat these corrective measures, = and > recreate the problem in a way that has no effective solution. > > Has that been considered? > > Joe > From touch@isi.edu Wed Nov 10 15:23:32 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7383D3A67C2 for ; Wed, 10 Nov 2010 15:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrNQtKmV-BOA for ; Wed, 10 Nov 2010 15:23:31 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6ABFB3A67B5 for ; Wed, 10 Nov 2010 15:23:31 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAANNfwq014504 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 10 Nov 2010 15:23:41 -0800 (PST) Message-ID: <4CDB297D.7060304@isi.edu> Date: Wed, 10 Nov 2010 15:23:41 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jerry Chu References: <20101110152857.GA5094@hell> <4CDAD0FB.6060602@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 , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 23:23:32 -0000 On 11/10/2010 3:13 PM, Jerry Chu wrote: > + yaogong > > Joe, > > You brought up a good question. We don't have any direct data on the scenario > you described. Also we've used FIFO tail drop so far hence haven't tried any > AQM algorithm on the router. Otherwise our testbed data showed under high > load and some extreme case (e.g., a constantly 5-simultaneous open bursts) > the average qlen of IW10 can get much longer than that of IW3, although under > those loaded conditions IW3 is already bad enough. > > To really answer your question, I'd suggest you to go to > http://research.csc.ncsu.edu/netsrv/?q=content/iw10 > > and tell us how to modify the test setup/parameters/programs to emulate the > exact condition you have in mind. I'm sure our collaboration Yaogong Wang from > NCSU will be happy to run some results for you. Your collaborators need to learn more about the situation of buffer bloat - it might be useful to contact Jim Gettys on this, and see what he can point you to that would help you understand how you need to configure the testbed to consider this issue. I'm following it, but only peripherally. Joe > > Thanks, > > Jerry > > On Wed, Nov 10, 2010 at 9:06 AM, Joe Touch wrote: >> FWIW, I'd like to add another point to the discussion. >> >> There has been recent concern with "buffer bloat", where home OS's, home >> routers, etc. all have either poorly optimized or incomplete implementations >> of fair queuing and socket buffering. >> >> The basic problem can be seen as follows: >> - run a continuous ping anywhere >> - start a large upload >> >> The latencies go from 10-100 milliseconds up t 0.5-5 seconds. This happens >> because the outbound buffers get stuffed with data. >> >> Although a single connection can cause this to happen (it optimizes for >> rate, not throughput), we know how to handle that - use RED, fair queuing, >> etc. >> >> I'm wondering if increasing the IW can defeat these corrective measures, and >> recreate the problem in a way that has no effective solution. >> >> Has that been considered? >> >> Joe >> From Internet-Drafts@ietf.org Wed Nov 10 15:30:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737DC3A67A3; Wed, 10 Nov 2010 15:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.145 X-Spam-Level: X-Spam-Status: No, score=-102.145 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hTEk2ptdyW0; Wed, 10 Nov 2010 15:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EFBB3A67A1; Wed, 10 Nov 2010 15:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101110233001.8668.54122.idtracker@localhost> Date: Wed, 10 Nov 2010 15:30:01 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-persist-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 23:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Clarification of sender behaviour in persist condition. Author(s) : M. Bashyam, et al. Filename : draft-ietf-tcpm-persist-01.txt Pages : 11 Date : 2010-11-10 This document attempts to clarify the notion of the Zero Window Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The motivation for this document stems from the belief that TCP implementations strictly adhering to the current RFC language have the potential to become vulnerable to Denial of Service (DoS) scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-persist-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-persist-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-10152022.I-D@ietf.org> --NextPart-- From hkchu@google.com Wed Nov 10 15:48:22 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDEAA3A67BD for ; Wed, 10 Nov 2010 15:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.977 X-Spam-Level: X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT7+tGZ8Vjkh for ; Wed, 10 Nov 2010 15:48:20 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 611673A67A1 for ; Wed, 10 Nov 2010 15:48:20 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id oAANmleJ029701 for ; Wed, 10 Nov 2010 15:48:47 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289432928; bh=uV2V2mxgdAMnZtkKqCnucid7Bc4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=bpUBvTqgdkPCP+24rAn7xdW59v1z1XQB3lsX2VHqG7tOL7oPEq2jEgqOiqU1tr77/ fD0PWOlIbEHBJAfz8XXrA== Received: from gxk25 (gxk25.prod.google.com [10.202.11.25]) by wpaz21.hot.corp.google.com with ESMTP id oAANmeCJ017047 for ; Wed, 10 Nov 2010 15:48:46 -0800 Received: by gxk25 with SMTP id 25so835723gxk.8 for ; Wed, 10 Nov 2010 15:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HM3ggYOWSOH803WSGeQ5uRyYU3gaQ8aTh9tGBhn9kjY=; b=Z1uxQGb2P7+9PzG6WYf615rlGrasvFoTDVFCAx2Op1SBC8WaI3yWbbS0RX6vh6sabe 9EjORNvFRZS59aG7bqBg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CMT9eizbpvq+VXeMPVADDV9vvJn0UyNosriPKZM0jj6DQKDxEHK4XdVtla82HqGeYV zVxlpWRsSJ/RqZJ5Iqig== MIME-Version: 1.0 Received: by 10.150.147.3 with SMTP id u3mr492575ybd.234.1289432926027; Wed, 10 Nov 2010 15:48:46 -0800 (PST) Received: by 10.150.145.4 with HTTP; Wed, 10 Nov 2010 15:48:45 -0800 (PST) In-Reply-To: <20101110174056.GH5094@hell> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> Date: Wed, 10 Nov 2010 15:48:45 -0800 Message-ID: From: Jerry Chu To: Hagen Paul Pfeifer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 23:48:22 -0000 On Wed, Nov 10, 2010 at 9:40 AM, Hagen Paul Pfeifer wrote: > * rick jones | 2010-11-10 09:20:23 [-0800]: > >>Earlier you wrote "New data are always pushed into the network in >>this quantum - a way to much for the standard TCP CC mechanism to tune in= to a >>steady state for network with a low BDP." =A0I read that as implying a co= ncern >>about how much data any one connection injects into the network at any mo= ment >>in time. > > To clarify this: I especially focus on the start phase of the connection.= If > the CC algorithm detects during slow start, congestion avoidance that the > available BDP is larger then the IW it is fine. But if the IW is 10, how > should _new connections_ react, they always will initially transmit 10 pa= ckets > - which can be too much - the problem is the initial quantum. I wonder what factors will argue that the initial quantum can't be changed? Someone has argued in the past IW10 effectively "disable CC algorithm". But haven't we already done that years ago when moving up IW from 1 to 3 if one insisted then that the initial quantum must be 1? The bottom line is, the right initial quantum is likely to be a function of b/w for the most part. So the concern has been on the slow links where the b/w is l= ow. But for all the practical purpose the slow links to be considered today are 56Kbps, which is 6 times larger than 9.6Kbps, the de-facto slow links back in the 90' when we increased IW from 1 to 3. Why are we so concerned about IW10, which is << than 6*3=3D18? Our testbed data confirmed that even on 56Kbps link IW10's saving on the roundtrips seems to more than compensate for the damage caused by higher retransmission rate and longer queuing delay so its flow completion time seems always better, or at least no worse than IW3's Jerry > >>And I presume, make it configurable. =A0It is already configurable on a >>per-route basis in the Linux stack. > > Yes, and you know the statement of davem and other guys if the discussion= goes > in this direction. Davem is aware of the impact of this knob and I am not= sure > if everybody is happy about it. I remember a discussion with davem about = a > HOT-TO-AGGRESSIVELY-TUNE-YOUR-NETWORK-STACK-HOWTO.xml. If these option ar= e > available they can be misused. I am happy that the per route knobs are a > little bit tricky usable. ;-) > > Hagen > From hagen@jauu.net Wed Nov 10 16:26:29 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0063A6876 for ; Wed, 10 Nov 2010 16:26:29 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH8gec5cZYUg for ; Wed, 10 Nov 2010 16:26:28 -0800 (PST) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id AF9853A6811 for ; Wed, 10 Nov 2010 16:26:28 -0800 (PST) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 88678F44195; Thu, 11 Nov 2010 01:26:55 +0100 (CET) Date: Thu, 11 Nov 2010 01:26:50 +0100 From: Hagen Paul Pfeifer To: Jerry Chu Message-ID: <20101111002621.GA2485@hell> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> 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.20 (2009-06-14) Cc: tcpm , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 00:26:29 -0000 * Jerry Chu | 2010-11-10 15:48:45 [-0800]: >The bottom line is, the right initial quantum is likely to be a >function of b/w for >the most part. So the concern has been on the slow links where the b/w is low. >But for all the practical purpose the slow links to be considered today are >56Kbps, which is 6 times larger than 9.6Kbps, the de-facto slow links back >in the 90' when we increased IW from 1 to 3. Why are we so concerned about >IW10, which is << than 6*3=18? I think you miss one crucial fact: the last-mile link may be 9.6Kbps but the overall network links where definitely broader then 9.6Kbps. In the mentioned scenario _all_ links are 100kB/s. You are completly right: the ideal IW is a function of the bandwidth of all links. But we are blind regarding the bandwidth of all links in advance. Simple overshoting the available bandwith and disable the CC algorithm is not my favorite ... ;) HGN From hagen@jauu.net Wed Nov 10 17:24:33 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65AD3A689C for ; Wed, 10 Nov 2010 17:24:33 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFeB7DC4jry1 for ; Wed, 10 Nov 2010 17:24:33 -0800 (PST) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id CF7033A6870 for ; Wed, 10 Nov 2010 17:24:32 -0800 (PST) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id B15F4F44195; Thu, 11 Nov 2010 02:25:00 +0100 (CET) Date: Thu, 11 Nov 2010 02:24:55 +0100 From: Hagen Paul Pfeifer To: Yuchung Cheng Message-ID: <20101111012453.GB2691@hell> References: <20101110152857.GA5094@hell> 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.20 (2009-06-14) Cc: Mike Belshe , tcpm , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 01:24:33 -0000 * Yuchung Cheng | 2010-11-10 12:04:48 [-0800]: >Let's do a reality check: today browsers open tens of flows simultaneously >to work around small TCP IW (http://www.browserscope.org/ the "network >tab). A study from AT&T and U of Mich also show 15% TCP flows observed in >AT&T network already go over IW3. We want to bring this issue to the IETF >community/experts to stop this downward spiral of sneaky unfair latency >"tune-ups". Let's do a reality check: we talk about TCP not HTTP. ;-) To clearify it: the draft address TCP, including FTP and all protocol built on top of TCP. I know google paradigm is "everything over HTTP" ;) but customers of mine do not use HTTP at all. TCP based file transfer and UDP based protocols are the lion share. Hagen From lars.eggert@nokia.com Wed Nov 10 17:45:01 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566F23A68D3 for ; Wed, 10 Nov 2010 17:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75G0zBwQ8AQS for ; Wed, 10 Nov 2010 17:45:00 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 2D03B3A68CF for ; Wed, 10 Nov 2010 17:45:00 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oAB1jQJH021020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2010 03:45:26 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Lars Eggert In-Reply-To: <5FDC413D5FA246468C200652D63E627A0B54DF67@LDCMVEXC1-PRD.hq.netapp.com> Date: Thu, 11 Nov 2010 09:45:09 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FDC413D5FA246468C200652D63E627A0B54DF67@LDCMVEXC1-PRD.hq.netapp.com> To: Richard Scheffenegger , Murari Sridharan X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 11 Nov 2010 03:45:15 +0200 (EET) X-Nokia-AV: Clean Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 01:45:01 -0000 Hi, I may be confused, but I thought Murari said that an updater was = pending. If there isn't, this can of course be adopted now. And as an individual contributor, I'd like to see that, as well as = Cubic. Lars On 2010-11-10, at 20:35, Scheffenegger, Richard wrote: >=20 >=20 > http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02 > Status: polled for interest on 6/16/10 > one positive response; no negative - too weak for adoption >=20 >=20 > I have been under the impression, that Lars specifically approached = the > authors to update and resubmit a new revision of the draft, before = this > can move forward. >=20 > For the record, I share the opinion of Anumita (adopt this as WG item, > updated with the most recent studies on stability / ICCRG input). >=20 > Ditto for draft-rhee-tcpm-cubic >=20 >=20 > Richard Scheffenegger > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From muraris@microsoft.com Wed Nov 10 17:48:08 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72663A68A2 for ; Wed, 10 Nov 2010 17:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+znGbX1tpZS for ; Wed, 10 Nov 2010 17:48:08 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 06E313A6895 for ; Wed, 10 Nov 2010 17:48:05 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 10 Nov 2010 17:48:33 -0800 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.54]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Wed, 10 Nov 2010 17:48:33 -0800 From: Murari Sridharan To: Lars Eggert , Richard Scheffenegger Thread-Topic: [tcpm] WG status update Thread-Index: AQHLgHIHUw43nIWZ1Ei4oXaJ2dgBYJNqoylwgAFmNID//3pUUA== Date: Thu, 11 Nov 2010 01:48:33 +0000 Message-ID: References: <5FDC413D5FA246468C200652D63E627A0B54DF67@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 01:48:09 -0000 There is one equation that has an error baring that there isn't much of an = update. I'll make that edit today or tomorrow and submit. But that edit sho= uldn't really block this from being adopted in my opinion as it is well und= erstood and discussed earlier. Since I never got a chance to resubmit the I= D to TCPM till now I hadn't formally made that change.=20 Thanks -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Lar= s Eggert Sent: Wednesday, November 10, 2010 5:45 PM To: Richard Scheffenegger; Murari Sridharan Cc: tcpm@ietf.org Subject: Re: [tcpm] WG status update Hi, I may be confused, but I thought Murari said that an updater was pending. I= f there isn't, this can of course be adopted now. And as an individual contributor, I'd like to see that, as well as Cubic. Lars On 2010-11-10, at 20:35, Scheffenegger, Richard wrote: >=20 >=20 > http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02 > Status: polled for interest on 6/16/10 > one positive response; no negative - too weak for adoption >=20 >=20 > I have been under the impression, that Lars specifically approached=20 > the authors to update and resubmit a new revision of the draft, before=20 > this can move forward. >=20 > For the record, I share the opinion of Anumita (adopt this as WG item,=20 > updated with the most recent studies on stability / ICCRG input). >=20 > Ditto for draft-rhee-tcpm-cubic >=20 >=20 > Richard Scheffenegger > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From hkchu@google.com Wed Nov 10 18:05:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F0D3A68C8 for ; Wed, 10 Nov 2010 18:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.977 X-Spam-Level: X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRSujjfeNtxY for ; Wed, 10 Nov 2010 18:05:01 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C1A453A68A8 for ; Wed, 10 Nov 2010 18:05:00 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id oAB25RFJ024563 for ; Wed, 10 Nov 2010 18:05:28 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289441128; bh=1gFxkNrgbMG8bI5XlBrIYPdix5c=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=pvmlqFRHn7mZKkM3BPfy5t4g2k6nE4+qWu6E3ZcAhaGo+haeAL5gj37dUz7qEE5yC 8c57G7F/d+ilsc/aYKKcA== Received: from gwb17 (gwb17.prod.google.com [10.200.2.17]) by wpaz9.hot.corp.google.com with ESMTP id oAB25Q1B018439 for ; Wed, 10 Nov 2010 18:05:26 -0800 Received: by gwb17 with SMTP id 17so228799gwb.32 for ; Wed, 10 Nov 2010 18:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1uN5Vra6tMyk3BZzhPBwLp60xcK01g2/2peZDXsch2Y=; b=GcbV1OUKi9P7hRDfa3FoSX8NSlIMpGrsbWvq8sqpDYgPRToeSXNDjLp5Afem6U/54t LpbHqalZKMZuc01Ph6pg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f/1CANxSVgLiygLd4iCOA2O/adA+HqQ98X8asfgG3eRLpkg36Y5NDe9zWKXOJhNlrR uCiki9nZyaGFe6elrbHQ== MIME-Version: 1.0 Received: by 10.150.53.2 with SMTP id b2mr651862yba.348.1289441125605; Wed, 10 Nov 2010 18:05:25 -0800 (PST) Received: by 10.150.145.4 with HTTP; Wed, 10 Nov 2010 18:05:25 -0800 (PST) In-Reply-To: <20101111012453.GB2691@hell> References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> Date: Wed, 10 Nov 2010 18:05:25 -0800 Message-ID: From: Jerry Chu To: Hagen Paul Pfeifer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Mike Belshe , tcpm , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 02:05:02 -0000 On Wed, Nov 10, 2010 at 5:24 PM, Hagen Paul Pfeifer wrote: > * Yuchung Cheng | 2010-11-10 12:04:48 [-0800]: > >>Let's do a reality check: today browsers open tens of flows simultaneousl= y >>to work around small TCP IW (http://www.browserscope.org/ =A0the "network >>tab). A study from AT&T and U of Mich also show 15% TCP flows observed in >>AT&T network already go over IW3. We want to bring this issue to the IETF >>community/experts to stop this downward spiral of sneaky unfair latency >>"tune-ups". > > Let's do a reality check: we talk about TCP not HTTP. ;-) To clearify it:= the > draft address TCP, including FTP and all protocol built on top of TCP. I = know > google paradigm is "everything over HTTP" ;) but customers of mine do not= use > HTTP at all. TCP based file transfer and UDP based protocols are the lion > share. Let's assume IW's effect diminishes as flows run longer, so you're probably not concerned about your flows running IW10 but more concerned about any collateral damage IW10 might bring to your ftp flows. Do you realize browsers have silently increased the # of simultaneous connections opened from 2 to 6 in the past few years, partly to get an effective boost to IW without any plan for standardization. Have you been concerned about the equivalent effect to your customers in the past few years? Browsers may continue to increase # of simultaneous opens if it helps performance. If they do, are y= ou going to do something about it? Jerry > > Hagen > From ilpo.jarvinen@helsinki.fi Wed Nov 10 18:19:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3FBA3A68E7 for ; Wed, 10 Nov 2010 18:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYSgBCF2W8zh for ; Wed, 10 Nov 2010 18:19:57 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id D362E3A6900 for ; Wed, 10 Nov 2010 18:19:56 -0800 (PST) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 11 Nov 2010 04:20:23 +0200 id 0009C836.4CDB52E7.0000625D Date: Thu, 11 Nov 2010 04:20:23 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: Joe Touch In-Reply-To: <4CDAD0FB.6060602@isi.edu> Message-ID: References: <20101110152857.GA5094@hell> <4CDAD0FB.6060602@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tcpm , Matt Mathis , tmrg Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 02:19:58 -0000 On Wed, 10 Nov 2010, Joe Touch wrote: > FWIW, I'd like to add another point to the discussion. > > There has been recent concern with "buffer bloat", where home OS's, home > routers, etc. all have either poorly optimized or incomplete implementations > of fair queuing and socket buffering. > > The basic problem can be seen as follows: > - run a continuous ping anywhere > - start a large upload > > The latencies go from 10-100 milliseconds up t 0.5-5 seconds. This happens > because the outbound buffers get stuffed with data. > > Although a single connection can cause this to happen (it optimizes for rate, > not throughput), we know how to handle that - use RED, fair queuing, etc. > > I'm wondering if increasing the IW can defeat these corrective measures, and > recreate the problem in a way that has no effective solution. > > Has that been considered? Please stay tuned, I intend to try to answer this question in my upcoming presentation. ...Or if curious enough, you can find my slides already among the tcpm material. -- i. From hagen@jauu.net Wed Nov 10 18:20:37 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D8D3A6920 for ; Wed, 10 Nov 2010 18:20:37 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4vWbRpTIGPq for ; Wed, 10 Nov 2010 18:20:35 -0800 (PST) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id 1A4903A691F for ; Wed, 10 Nov 2010 18:20:35 -0800 (PST) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 2926BF44195; Thu, 11 Nov 2010 03:21:03 +0100 (CET) Date: Thu, 11 Nov 2010 03:20:56 +0100 From: Hagen Paul Pfeifer To: Jerry Chu Message-ID: <20101111022055.GC2691@hell> References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> 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.20 (2009-06-14) Cc: Mike Belshe , tcpm , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 02:20:37 -0000 * Jerry Chu | 2010-11-10 18:05:25 [-0800]: >Let's assume IW's effect diminishes as flows run longer, so you're probably >not concerned about your flows running IW10 but more concerned about any >collateral damage IW10 might bring to your ftp flows. Do you realize browsers >have silently increased the # of simultaneous connections opened from 2 to 6 >in the past few years, partly to get an effective boost to IW without any >plan for standardization. Have you been concerned about the equivalent effect >to your customers in the past few years? Browsers may continue to increase # >of simultaneous opens if it helps performance. If they do, are you going to >do something about it? If the number of browser flow is the problem then do you think the draft which address TCP fundamentally is the right answer? Not sure, you are right that I worry about collateral damage for some kind of networks. IMHO we should act careful with increasing the IW, I am skeptical and all material that I saw does not appease me. I started to build a multi-hop ns-3 test setup, no dumpbell scenario, a flat multi-hop test setup but it stocked because of lack of time. Hagen From david.borman@windriver.com Wed Nov 10 18:54:00 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF5B3A697B for ; Wed, 10 Nov 2010 18:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.483 X-Spam-Level: X-Spam-Status: No, score=-103.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6Y5pWWcuK+7 for ; Wed, 10 Nov 2010 18:54:00 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 2DE053A693E for ; Wed, 10 Nov 2010 18:54:00 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id oAB2sSfS014998 for ; Wed, 10 Nov 2010 18:54:28 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Nov 2010 18:54:28 -0800 Received: from dhcp-32f8.meeting.ietf.org ([147.11.69.2]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Nov 2010 18:54:28 -0800 From: David Borman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 10:54:24 +0800 Message-Id: <2250D47A-F1B3-4F9A-A75B-675E8A5C3939@windriver.com> To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 11 Nov 2010 02:54:28.0731 (UTC) FILETIME=[C1FD14B0:01CB814B] Subject: [tcpm] Meeting materials are all uploaded X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 02:54:00 -0000 All the meeting materials for the TCPM meeting today have been uploaded = to the meeting materials site: https://datatracker.ietf.org/meeting/79/materials.html TCPM is near the bottom of the page. -David Borman, TCPM co-chair= From hkchu@google.com Wed Nov 10 20:44:26 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12A53A683A for ; Wed, 10 Nov 2010 20:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.977 X-Spam-Level: X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wbnxprUyF1t for ; Wed, 10 Nov 2010 20:44:25 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 88CD83A682C for ; Wed, 10 Nov 2010 20:44:25 -0800 (PST) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id oAB4iqBT018520 for ; Wed, 10 Nov 2010 20:44:53 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289450693; bh=4fdQMMQXOYotXEb7yPCE7OSXugM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=HBOXybtvPHdp54DQECfQWrfeN6vjQD85FS7ebv+GblY9ZiAyQ92kUsXlB7m4Wii2Q 55lSDe0YIySawGD7C9Rqw== Received: from gxk27 (gxk27.prod.google.com [10.202.11.27]) by kpbe18.cbf.corp.google.com with ESMTP id oAB4ip21007627 for ; Wed, 10 Nov 2010 20:44:51 -0800 Received: by gxk27 with SMTP id 27so1027524gxk.31 for ; Wed, 10 Nov 2010 20:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/hcwAXRFqlZMD3qSoIPyHa22GA5lq4DYPu9P6TC17m8=; b=m/r982cM3YgfUiuCg1/l5j+jB7X2BE2zNAgg7jUcfduW4SYQiGYq14TAXld51Fya+F gT89jXOkRjVUTaW7Phww== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fpIGQMsUtpvWGyqE5UPjtao9nRfuccYsKCBmfTqR1GFG+C7wfvK3aC/+R5osKxASrg f1hkFRFmz8G0Xh6ngG/Q== MIME-Version: 1.0 Received: by 10.150.205.20 with SMTP id c20mr893541ybg.405.1289450690103; Wed, 10 Nov 2010 20:44:50 -0800 (PST) Received: by 10.150.145.4 with HTTP; Wed, 10 Nov 2010 20:44:50 -0800 (PST) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0B65C814@LDCMVEXC1-PRD.hq.netapp.com> References: <5FDC413D5FA246468C200652D63E627A0B65C814@LDCMVEXC1-PRD.hq.netapp.com> Date: Wed, 10 Nov 2010 20:44:50 -0800 Message-ID: From: Jerry Chu To: "Scheffenegger, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Arvind Jain , tcpm , Yaogong Wang , Matt Mathis Subject: Re: [tcpm] Increasing TCP's Initial Congestion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 04:44:27 -0000 Hi Richard, On Wed, Nov 10, 2010 at 11:27 AM, Scheffenegger, Richard wr= ote: > > Hi Jerry, Yaogong, > > Reading your slides (i won't be online when you give your talk): > > > http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf > > > | Is SACK required for IW10 to Perform? > | > | * From the testbed at Google > | =A0- SACK does help reducing UCT but only by a small > | =A0 =A0percentage for both IW10 and IW3 > | * 24 hours, 3-way parallel experiment at Google's > | =A0 frontend servers > | =A0- IW10+NewReno still beats IW3+SACK > | > | Photos download Avg response time Retransmission rate > | IW10+SACK =A0 =A0 =A0 2.6secs =A0 =A0 =A0 =A0 =A0 4.1% > | IW10+NewReno =A0 =A02.8secs =A0 =A0 =A0 =A0 =A0 4.1% > | IW3+SACK =A0 =A0 =A0 =A03.0secs =A0 =A0 =A0 =A0 =A0 3.3% > | November 11, 2010 =A0 =A0 79th IETF, Beijing China =A0 =A0 =A019 > > > First, let me thank you for conducting these experiments with SACK and > NewReno. > > > My comment at IETF78 was that Linux SACK (since 2.4.xx) can detect lost > retransmissions, and recover from them; Understood. I haven't thought too deeply on this but on the surface I wonde= r=A0how critical will the efficient recovery of lost retransmissions be, or it's mainly a secondary concern? > > On the 2nd slide you paraphrase this: > > | How does IW10 perform > | =A0when SACK is either not available, or not adequately > | =A0implemented? > > Did you disable this aspect of Linux SACK during your tests (to have a > RFC3517 compliant SACK sender)? Also, IIRC, Linux 2.6.2x already > implements draft-jarvinen-tcpm-sack-recovery-entry-02.txt // RFC3517bis. No I didn't get the time to study SACK details to run the tests. Both Yuchu= ng and I simply disabled SACK altogether (sysctl_tcp_sack =3D 0). > > I assume the fraction of lost retransmissions and early recovery entries > was small (afaik, Linux records these events individually). If these > counters were zero during your the testing, I'm fully satisfied. > > I'm just worried that a good fraction of loss recovery was due to these > recent features (not widely available on other stacks), causing grief if > one simply tries to do IW10 without these other modifications. Understood. Unfortunately I didn't get the time to study the case you brought up in details. The tests so far were more to address Matt's concern about SACK (or lack of) in general for IW10. > > Also, this comment on slide 13 indicates, that some flows had to do > RTO-based loss recovery, correct? I think so but I don't have the numbers with me, nor are they on the web page. We used to collect netstat -s output but we discovered the former wasn't valid anymore when we switched to slow link tests - normal background traffic become significant portion of "netstat -s" compared to 64Kbps rate to obscure the numbers. > > | * Under heavy load IW10 lost UCT advantage due to high PLR > | * IW10 UCT exhibits long tails > > > Did you get traces off your testbed to investigate these long tail flows > further? One of the reasons might be the recent observation, that with > short flows, NewReno can sometimes recover more speedy than SACK ( > http://www.ietf.org/mail-archive/web/tcpm/current/msg05875.html ). Yes I do see this but wasn't sure if it's due to the large variation of num= bers for 64Kbps links (and it could still be the case). > (RecoveryPoint is close to the end-of-stream, and at least the last > segment prior to RP was lost). > > The other reason could be, that SACK retransmissions are lost, but Linux > can not recover them any more. (RecoveryPoint is at the end-of-stream). > > There might be additional cases causing RTO, though... > > I would be very interested in looking at these long tail (high latency) > flow traces myself. Ok, will arrange to send you the trace dumps. Thanks, Jerry > > > > Richard Scheffenegger From Michael.Scharf@alcatel-lucent.com Thu Nov 11 00:42:43 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93AC83A6A5E for ; Thu, 11 Nov 2010 00:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+cs5h6TLF9L for ; Thu, 11 Nov 2010 00:42:42 -0800 (PST) Received: from mailrelay1.alcatel.de (mailrelay1.alcatel.de [194.113.59.95]) by core3.amsl.com (Postfix) with ESMTP id 723C63A6A44 for ; Thu, 11 Nov 2010 00:42:42 -0800 (PST) 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 oAB8gpnG012499; Thu, 11 Nov 2010 09:42:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB817C.6D091858" Date: Thu, 11 Nov 2010 09:42:51 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C026F6271@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Increasing the Initial Window - Notes Thread-Index: AcuBC7JZui5D6DSHQ4WoNGtusgIrZgAbpT57 References: <20101110152857.GA5094@hell><0C53DCFB700D144284A584F54711EC580B242496@xmb-sjc-21c.amer.cisco.com> From: "SCHARF, Michael" To: "Yuchung Cheng" , "Anantha Ramaiah (ananth)" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.72 Cc: tmrg , tcpm , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 08:42:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB817C.6D091858 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Independently Michael Scharf also studied IW3 and IW10 issues in his = PhD > research and reached similar conclusion. We presented his slides in = the last > ICCRG meeting but due to some copyright issue, please contact him = privately > for a copy. Just two small notes on this: First, my studies mainly focused on typical broadband Internet access = links (several Mbit/s). I did not comprehensively study networks with = rather low bandwidth. Second, unfortunately, my PhD thesis is still not published. In case = that there is interest, I will offer a presentation about my findings = once I am able to do so (e. g., in ICCRG or TCPM). Thanks Michael ------_=_NextPart_001_01CB817C.6D091858 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [tcpm] Increasing the Initial Window - Notes

> Independently Michael Scharf also studied IW3 and = IW10 issues in his PhD
> research and reached similar conclusion. We presented his slides in = the last
> ICCRG meeting but due to some copyright issue, please contact him = privately
> for a copy.

Just two small notes on this:

First, my studies mainly focused on typical broadband Internet access = links (several Mbit/s). I did not comprehensively study networks with = rather low bandwidth.

Second, unfortunately, my PhD thesis is still not published. In case = that there is interest, I will offer a presentation about my findings = once I am able to do so (e. g., in ICCRG or TCPM).

Thanks

Michael

------_=_NextPart_001_01CB817C.6D091858-- From michawe@ifi.uio.no Thu Nov 11 02:28:52 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515B23A6904 for ; Thu, 11 Nov 2010 02:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVSXpKs3DWIv for ; Thu, 11 Nov 2010 02:28:51 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id E0CC93A686B for ; Thu, 11 Nov 2010 02:28:50 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1PGUP9-000148-12; Thu, 11 Nov 2010 11:29:19 +0100 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from ) id 1PGUP8-0004YZ-FE; Thu, 11 Nov 2010 11:29:18 +0100 Message-Id: <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> From: Michael Welzl To: Hagen Paul Pfeifer In-Reply-To: <20101111012453.GB2691@hell> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Nov 2010 11:28:56 +0100 References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 4 sum rcpts/h 14 sum msgs/h 5 total rcpts 4102 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 68C5B46CE2F040F6F92C2091D6472DB27A35C37D X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 123 max/h 7 blacklist 0 greylist 0 ratelimit 0 Cc: tmrg , Mike Belshe , tcpm , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:28:52 -0000 This just gave me an idea: On Nov 11, 2010, at 2:24 AM, Hagen Paul Pfeifer wrote: > * Yuchung Cheng | 2010-11-10 12:04:48 [-0800]: > >> Let's do a reality check: today browsers open tens of flows >> simultaneously >> to work around small TCP IW (http://www.browserscope.org/ the >> "network >> tab). A study from AT&T and U of Mich also show 15% TCP flows >> observed in >> AT&T network already go over IW3. We want to bring this issue to >> the IETF >> community/experts to stop this downward spiral of sneaky unfair >> latency >> "tune-ups". > > Let's do a reality check: we talk about TCP not HTTP. ;-) To > clearify it: the > draft address TCP, including FTP and all protocol built on top of > TCP. I know > google paradigm is "everything over HTTP" ;) but customers of mine > do not use > HTTP at all. TCP based file transfer and UDP based protocols are the > lion > share. I've seen this argumentation again and again, going back and forth. So it seems that we have a lot of data, and many proponents saying that it might be worth trying to use IW=10 for the web... but a lot of people who argue against the IW=10 keep pointing out that HTTP isn't everything. Why not make this something that could be enabled on a per-socket basis? I mean, I can decide whether my socket does Nagle or not, why not let the programmer decide where in the range from 4 to 10 the IW should be, with a socket option or something? Cheers, Michael From hkchu@google.com Thu Nov 11 02:36:27 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAAA23A69B1 for ; Thu, 11 Nov 2010 02:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.223 X-Spam-Level: X-Spam-Status: No, score=-105.223 tagged_above=-999 required=5 tests=[AWL=0.754, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5fdnwdj4+t4 for ; Thu, 11 Nov 2010 02:36:24 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 13FEF3A694C for ; Thu, 11 Nov 2010 02:36:20 -0800 (PST) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id oABAan5f012807 for ; Thu, 11 Nov 2010 02:36:49 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289471810; bh=uL4LmpMuLxeTfufNha6LTc3LoZE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=H75m0EibvIqnynhWcEbMoM7eMZCn7haf5qtUpZn86ZotC3VrHYPLWXyZOmmSWtMHR 6GeXkLVOLDryry41/THwg== Received: from gxk9 (gxk9.prod.google.com [10.202.11.9]) by hpaq3.eem.corp.google.com with ESMTP id oABAalVP029719 for ; Thu, 11 Nov 2010 02:36:47 -0800 Received: by gxk9 with SMTP id 9so1311475gxk.41 for ; Thu, 11 Nov 2010 02:36:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JQ0n73Zo6lcdnfwrHolqH0vV7HM1Mo0Kq/TnbRA9Rgs=; b=ObU6qsUCikek+tUCwoRNuwTyPmNhhPubxEQzsTUWwG2u8LCaIyJOgvfIj+COKUHSs8 WSpN5Dslls9DvCVSJ6Mw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tS5Uj7D0nRhWiHT9xS9V9HFpRrrwYQaLlTWw5mUTcm/mDCNd+Bu25iXKVQx6L1EMCx Nn/8BWjX2xaGjX0dTASA== MIME-Version: 1.0 Received: by 10.150.53.2 with SMTP id b2mr1429805yba.348.1289471806244; Thu, 11 Nov 2010 02:36:46 -0800 (PST) Received: by 10.150.145.4 with HTTP; Thu, 11 Nov 2010 02:36:46 -0800 (PST) In-Reply-To: <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> Date: Thu, 11 Nov 2010 02:36:46 -0800 Message-ID: From: Jerry Chu To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tmrg , Mike Belshe , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:36:27 -0000 On Thu, Nov 11, 2010 at 2:28 AM, Michael Welzl wrote: > > This just gave me an idea: > > On Nov 11, 2010, at 2:24 AM, Hagen Paul Pfeifer wrote: > >> * Yuchung Cheng | 2010-11-10 12:04:48 [-0800]: >> >>> Let's do a reality check: today browsers open tens of flows simultaneou= sly >>> to work around small TCP IW (http://www.browserscope.org/ =A0the "netwo= rk >>> tab). A study from AT&T and U of Mich also show 15% TCP flows observed = in >>> AT&T network already go over IW3. We want to bring this issue to the IE= TF >>> community/experts to stop this downward spiral of sneaky unfair latency >>> "tune-ups". >> >> Let's do a reality check: we talk about TCP not HTTP. ;-) To clearify it= : the >> draft address TCP, including FTP and all protocol built on top of TCP. I= know >> google paradigm is "everything over HTTP" ;) but customers of mine do no= t use >> HTTP at all. TCP based file transfer and UDP based protocols are the lio= n >> share. > > I've seen this argumentation again and again, going back and forth. So it= seems that we have a lot of data, and many proponents saying that it might= be worth trying to use IW=3D10 for the web... but a lot of people who argu= e against the IW=3D10 keep pointing out that HTTP isn't everything. > > Why not make this something that could be enabled on a per-socket basis? = I mean, I can decide whether my socket does Nagle or not, why not let the p= rogrammer decide where in the range from 4 to 10 the IW should be, with a s= ocket option or something? I certainly won't object to this, if that's all it takes for standardization. Unfortunately the point for the non-convinced is they don't want ANY flows to use IW10 for fear of hurting the performance of their flows. Jerry > > Cheers, > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Thu Nov 11 02:39:29 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43D43A68C6 for ; Thu, 11 Nov 2010 02:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHPFyO+Yx9qO for ; Thu, 11 Nov 2010 02:39:28 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 039E93A68C5 for ; Thu, 11 Nov 2010 02:39:28 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1PGUZN-0004W7-1L; Thu, 11 Nov 2010 11:39:53 +0100 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from ) id 1PGUZM-0001FV-ET; Thu, 11 Nov 2010 11:39:52 +0100 Message-Id: <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> From: Michael Welzl To: Jerry Chu In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Nov 2010 11:39:31 +0100 References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 20 msgs/h 7 sum rcpts/h 24 sum msgs/h 8 total rcpts 4112 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AFB40C239C3B7C265BD27B2E43B803B3C08194C3 X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 7 total 126 max/h 7 blacklist 0 greylist 0 ratelimit 0 Cc: tmrg , Mike Belshe , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:39:30 -0000 On Nov 11, 2010, at 11:36 AM, Jerry Chu wrote: > On Thu, Nov 11, 2010 at 2:28 AM, Michael Welzl > wrote: >> >> This just gave me an idea: >> >> On Nov 11, 2010, at 2:24 AM, Hagen Paul Pfeifer wrote: >> >>> * Yuchung Cheng | 2010-11-10 12:04:48 [-0800]: >>> >>>> Let's do a reality check: today browsers open tens of flows >>>> simultaneously >>>> to work around small TCP IW (http://www.browserscope.org/ the >>>> "network >>>> tab). A study from AT&T and U of Mich also show 15% TCP flows >>>> observed in >>>> AT&T network already go over IW3. We want to bring this issue to >>>> the IETF >>>> community/experts to stop this downward spiral of sneaky unfair >>>> latency >>>> "tune-ups". >>> >>> Let's do a reality check: we talk about TCP not HTTP. ;-) To >>> clearify it: the >>> draft address TCP, including FTP and all protocol built on top of >>> TCP. I know >>> google paradigm is "everything over HTTP" ;) but customers of mine >>> do not use >>> HTTP at all. TCP based file transfer and UDP based protocols are >>> the lion >>> share. >> >> I've seen this argumentation again and again, going back and forth. >> So it seems that we have a lot of data, and many proponents saying >> that it might be worth trying to use IW=10 for the web... but a lot >> of people who argue against the IW=10 keep pointing out that HTTP >> isn't everything. >> >> Why not make this something that could be enabled on a per-socket >> basis? I mean, I can decide whether my socket does Nagle or not, >> why not let the programmer decide where in the range from 4 to 10 >> the IW should be, with a socket option or something? > > I certainly won't object to this, if that's all it takes for > standardization. Unfortunately the > point for the non-convinced is they don't want ANY flows to use IW10 > for fear of hurting > the performance of their flows. ... but here, your "browsers open tens of flows" argument totally holds. How is a web flow with IW10 worse than a browser opening tens of flows? If people only use it for the web, like Google has been successfully doing, this seems to be quite safe, based on experience. I'm curious what the opposition says to this :) Cheers, Michael From lars.eggert@nokia.com Thu Nov 11 02:44:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A0D3A68C6 for ; Thu, 11 Nov 2010 02:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Hid8SKa07kK for ; Thu, 11 Nov 2010 02:44:37 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 5DE063A689C for ; Thu, 11 Nov 2010 02:44:37 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oABAiuA4019408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2010 12:44:56 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Lars Eggert In-Reply-To: <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> Date: Thu, 11 Nov 2010 18:44:48 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <73BF99B9-B55E-41AA-951D-E6B902160632@nokia.com> References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 11 Nov 2010 12:44:54 +0200 (EET) X-Nokia-AV: Clean Cc: tmrg , Mike Belshe , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:44:38 -0000 Hi, we currently seem to be a bit stuck. The Google folks have gathered a = lot of data, but at the moment it's still not quite clear - to me at = least - what data-based argument would convince the WG to either permit = IW10 and under what considerations, or which argument would convince us = to not do it. I talked to a few folks after the meeting and made this suggestion: * Google makes the raw data available. Yoshifumi requested this at the = mike, and Jerry said he'd see if this was possible. * We plan a TCPM interim in a few months, with the only topic being = IW10. * Folks (other than Google) who like IW10 crunch down the raw Google = data in an attempt to provide a convincing argument to allow it, and = under which conditions. (Obviously, folks can also generate their own = data, if they like.) * Folks sceptical about IW10 crunch down the Google data in an attempt = to find problematic cases that'd make the WG lean against IW10. = (Obviously, folks can also generate their own data, if they like.) * We hold the interim with these folks presenting, and see what shakes = out. The idea here is that we really need a more diverse set of folks playing = with IW10. Thoughts? Lars= From lars.eggert@nokia.com Thu Nov 11 02:45:33 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4393A69D9 for ; Thu, 11 Nov 2010 02:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7TQHHZuciQn for ; Thu, 11 Nov 2010 02:45:32 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id C01B53A69BC for ; Thu, 11 Nov 2010 02:45:31 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oABAjsC7020994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2010 12:45:55 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Lars Eggert In-Reply-To: <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> Date: Thu, 11 Nov 2010 18:45:49 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 11 Nov 2010 12:45:53 +0200 (EET) X-Nokia-AV: Clean Cc: tmrg , Mike Belshe , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:45:33 -0000 On 2010-11-11, at 18:28, Michael Welzl wrote: > Why not make this something that could be enabled on a per-socket = basis? I mean, I can decide whether my socket does Nagle or not, why not = let the programmer decide where in the range from 4 to 10 the IW should = be, with a socket option or something? It will be REALLY hard to explain to folks why they should limit = themselves to 10, if we make this a generic socket option. Lars= From mellia@tlc.polito.it Thu Nov 11 02:49:30 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D14A3A69AD for ; Thu, 11 Nov 2010 02:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbsFi3yYX10H for ; Thu, 11 Nov 2010 02:49:28 -0800 (PST) Received: from mail.tlc.polito.it (baobab.polito.it [130.192.9.198]) by core3.amsl.com (Postfix) with SMTP id 290353A6929 for ; Thu, 11 Nov 2010 02:49:27 -0800 (PST) Received: (qmail 14640 invoked by uid 88); 11 Nov 2010 10:49:51 -0000 Received: from gramigna.polito.it (HELO gramigna.polito.it) (130.192.9.144) (smtp-auth username mellia@tlc.polito.it, mechanism cram-md5) by mail.tlc.polito.it (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Thu, 11 Nov 2010 11:49:51 +0100 Message-ID: <4CDBCA4E.8000705@tlc.polito.it> Date: Thu, 11 Nov 2010 11:49:50 +0100 From: Marco Mellia User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; it; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Michael Welzl References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> In-Reply-To: <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TLC-MailScanner-Information: Please contact the ISP for more information X-TLC-MailScanner: Found to be clean X-TLC-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.739, required 4, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.66, BAYES_00 -2.60) X-TLC-MailScanner-From: mellia@tlc.polito.it Cc: Mike Belshe , tmrg , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:49:30 -0000 >> I certainly won't object to this, if that's all it takes for >> standardization. Unfortunately the >> point for the non-convinced is they don't want ANY flows to use IW10 >> for fear of hurting >> the performance of their flows. > > ... but here, your "browsers open tens of flows" argument totally > holds. How is a web flow with IW10 worse than a browser opening tens > of flows? If people only use it for the web, like Google has been > successfully doing, this seems to be quite safe, based on experience. > > I'm curious what the opposition says to this :) If today a brower opens 10 flows with a server using IW=1 you gets 10 packets equivalent IW. Increasing the IW to 10 leads to an equivalent IW of 100 packets. At that point, you DSL modem will definitively start dropping most of them... -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Skypeid: mgmellia | | Tel: +39-011-564-4173 | | Cel: +39-340-9674888 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www.telematica.polito.it | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux. From michawe@ifi.uio.no Thu Nov 11 02:53:27 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E18F3A69DA for ; Thu, 11 Nov 2010 02:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dpXYUMcaUtz for ; Thu, 11 Nov 2010 02:53:26 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id BC7D93A6905 for ; Thu, 11 Nov 2010 02:53:26 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1PGUmx-00006i-1l; Thu, 11 Nov 2010 11:53:55 +0100 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from ) id 1PGUmw-0002bE-LN; Thu, 11 Nov 2010 11:53:55 +0100 Message-Id: From: Michael Welzl To: Lars Eggert In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Nov 2010 11:53:33 +0100 References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 26 msgs/h 8 sum rcpts/h 30 sum msgs/h 9 total rcpts 4118 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7B6418A42B658B8076920807659AA64C856E269E X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 8 total 127 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: tmrg , Mike Belshe , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:53:27 -0000 On Nov 11, 2010, at 11:45 AM, Lars Eggert wrote: > On 2010-11-11, at 18:28, Michael Welzl wrote: >> Why not make this something that could be enabled on a per-socket >> basis? I mean, I can decide whether my socket does Nagle or not, >> why not let the programmer decide where in the range from 4 to 10 >> the IW should be, with a socket option or something? > > It will be REALLY hard to explain to folks why they should limit > themselves to 10, if we make this a generic socket option. Provide 4-10 available in the option, not more, based on Google's data? From michawe@ifi.uio.no Thu Nov 11 02:58:21 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6409C3A6A00 for ; Thu, 11 Nov 2010 02:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isyAJQgEfSrX for ; Thu, 11 Nov 2010 02:58:20 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 4F7493A69E5 for ; Thu, 11 Nov 2010 02:58:20 -0800 (PST) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1PGUrg-0001Sm-ES; Thu, 11 Nov 2010 11:58:48 +0100 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from ) id 1PGUrf-0007DP-Qe; Thu, 11 Nov 2010 11:58:48 +0100 Message-Id: <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> From: Michael Welzl To: Marco Mellia In-Reply-To: <4CDBCA4E.8000705@tlc.polito.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Nov 2010 11:58:26 +0100 References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 32 msgs/h 9 sum rcpts/h 36 sum msgs/h 10 total rcpts 4124 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: CDD9CD8C51CA19400CDE978456C7594050C5F5B1 X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 9 total 128 max/h 9 blacklist 0 greylist 0 ratelimit 0 Cc: Mike Belshe , tmrg , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:58:21 -0000 On Nov 11, 2010, at 11:49 AM, Marco Mellia wrote: > > >>> I certainly won't object to this, if that's all it takes for >>> standardization. Unfortunately the >>> point for the non-convinced is they don't want ANY flows to use IW10 >>> for fear of hurting >>> the performance of their flows. >> >> ... but here, your "browsers open tens of flows" argument totally >> holds. How is a web flow with IW10 worse than a browser opening >> tens of flows? If people only use it for the web, like Google has >> been successfully doing, this seems to be quite safe, based on >> experience. >> >> I'm curious what the opposition says to this :) > > If today a brower opens 10 flows with a server using IW=1 you gets > 10 packets equivalent IW. > Increasing the IW to 10 leads to an equivalent IW of 100 packets. At > that point, you DSL modem will definitively start dropping most of > them... ... which is a good reason to open fewer connections. So that's a matter of bringing of bringing out an update of a web client with a different behavior for the case that a web server uses a larger IW. But how does the web browser know what the web server is doing? I guess they could exchange this information with HTTP. Hm. Are we getting somewhere here, or is this a dead end? Cheers, Michael From hkchu@google.com Thu Nov 11 02:58:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0C23A6933 for ; Thu, 11 Nov 2010 02:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.977 X-Spam-Level: X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4C38gqP3JRq for ; Thu, 11 Nov 2010 02:58:56 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C740B3A689C for ; Thu, 11 Nov 2010 02:58:55 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id oABAxOGG021115 for ; Thu, 11 Nov 2010 02:59:24 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289473164; bh=xtOhY26in8PKGzm6gatqgpF0OO4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=pQindrfFSf1ZzmmsSiLbup6gOqi1bd1oRnmRNgKAAFwtpFKIeTic8RPvZhariurUc L2gNwsBWuBCGfJaN3PPjw== Received: from gwj17 (gwj17.prod.google.com [10.200.10.17]) by wpaz13.hot.corp.google.com with ESMTP id oABAxNrt023203 for ; Thu, 11 Nov 2010 02:59:23 -0800 Received: by gwj17 with SMTP id 17so1053795gwj.8 for ; Thu, 11 Nov 2010 02:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iSbF9CvO22S8IK+H9oBWAJkGLUSiWausI5qlxfD8LNg=; b=qYvHTmOH4swDJ/fj/klwb1HDG78Tm0IPAnoIiTpArb/KzHCy6RaIc0xLFEoYxJ69w2 QVHGURfXULSYyPaqgrCg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wabFNqqg0tsh/DfJMNrsyidnxCWj8L1W2WiTwnP6E3vHfwjZpD2UVhv6hHaku4Lbgr NryfUV21cCgwiCtjUI7A== MIME-Version: 1.0 Received: by 10.150.53.2 with SMTP id b2mr1465165yba.348.1289473162575; Thu, 11 Nov 2010 02:59:22 -0800 (PST) Received: by 10.150.145.4 with HTTP; Thu, 11 Nov 2010 02:59:22 -0800 (PST) In-Reply-To: <4CDBCA4E.8000705@tlc.polito.it> References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> Date: Thu, 11 Nov 2010 02:59:22 -0800 Message-ID: From: Jerry Chu To: Marco Mellia Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm , Mike Belshe , tmrg , Matt Mathis , Michael Welzl Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:58:57 -0000 On Thu, Nov 11, 2010 at 2:49 AM, Marco Mellia wrote: > > >>> I certainly won't object to this, if that's all it takes for >>> standardization. Unfortunately the >>> point for the non-convinced is they don't want ANY flows to use IW10 >>> for fear of hurting >>> the performance of their flows. >> >> ... but here, your "browsers open tens of flows" argument totally holds.= How is a web flow with IW10 worse than a browser opening tens of flows? If= people only use it for the web, like Google has been successfully doing, t= his seems to be quite safe, based on experience. >> >> I'm curious what the opposition says to this =A0:) > > If today a brower opens 10 flows with a server using IW=3D1 you gets 10 p= ackets equivalent IW. > Increasing the IW to 10 leads to an equivalent IW of 100 packets. At that= point, you DSL modem will definitively start dropping most of them... But if we don't start thinking about how to scale these TCP parameters, tomorrow (ok, maybe in a couple of years) when browsers decide to open 20 or 30 flows because they are frustrated with low TCP parameters like IW, it will effectively be equivalent to increasing IW to 10 today. So do we want to do nothing and leave it all to apps, or try to take some control of some key TCP parameters back into TCP itself? Jerry > > -- > > Ciao, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/\/\/\rco > > +-----------------------------------+ > | Marco Mellia - Assistant Professor| > | Skypeid: mgmellia =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > | Tel: +39-011-564-4173 =A0 =A0 =A0 =A0 =A0 =A0 | > | Cel: +39-340-9674888 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 /"\ =A0.. . . . .= . . . . . . . . > | Politecnico di Torino =A0 =A0 =A0 =A0 =A0 =A0 | =A0 \ / =A0. ASCII Ribb= on Campaign =A0. > | Corso Duca degli Abruzzi 24 =A0 =A0 =A0 | =A0 =A0X =A0 .- NO HTML/RTF i= n e-mail . > | Torino - 10129 - Italy =A0 =A0 =A0 =A0 =A0 =A0| =A0 / \ =A0.- NO Word d= ocs in e-mail. > | http://www.telematica.polito.it =A0 | =A0 =A0 =A0 =A0.. . . . . . . . .= . . . . > +-----------------------------------+ > The box said "Requires Windows 95 or Better." So I installed Linux. > From michawe@ifi.uio.no Thu Nov 11 03:00:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5F53A693F for ; Thu, 11 Nov 2010 03:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYyWRANJQl8O for ; Thu, 11 Nov 2010 03:00:39 -0800 (PST) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 160443A6933 for ; Thu, 11 Nov 2010 03:00:39 -0800 (PST) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1PGUtv-0001cQ-DV; Thu, 11 Nov 2010 12:01:07 +0100 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from ) id 1PGUtu-0007Vy-U9; Thu, 11 Nov 2010 12:01:07 +0100 Message-Id: <580AACC8-1BAB-4971-ABA1-2E65FCA7F7F8@ifi.uio.no> From: Michael Welzl To: Lars Eggert In-Reply-To: <73BF99B9-B55E-41AA-951D-E6B902160632@nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Nov 2010 12:00:45 +0100 References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <73BF99B9-B55E-41AA-951D-E6B902160632@nokia.com> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 23 sum msgs/h 5 total rcpts 4130 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 59C46217B90A462D3E691744FDDB8DA1D4F3C891 X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 129 max/h 9 blacklist 0 greylist 0 ratelimit 0 Cc: tmrg , Mike Belshe , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 11:00:40 -0000 > The idea here is that we really need a more diverse set of folks > playing with IW10. Thoughts? Isn't this what Experimental RFCs encourage? Cheers, Michael From lars.eggert@nokia.com Thu Nov 11 03:06:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B453A69BC for ; Thu, 11 Nov 2010 03:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AyKUXzELKb4 for ; Thu, 11 Nov 2010 03:06:56 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id C8D123A68D3 for ; Thu, 11 Nov 2010 03:06:55 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oABB7Iju032329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2010 13:07:18 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Lars Eggert In-Reply-To: <580AACC8-1BAB-4971-ABA1-2E65FCA7F7F8@ifi.uio.no> Date: Thu, 11 Nov 2010 19:07:09 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <768329AE-9FC1-405E-90A5-070901542D08@nokia.com> References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <73BF99B9-B55E-41AA-951D-E6B902160632@nokia.com> <580AACC8-1BAB-4971-ABA1-2E65FCA7F7F8@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 11 Nov 2010 13:07:16 +0200 (EET) X-Nokia-AV: Clean Cc: tmrg , Mike Belshe , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 11:06:57 -0000 On 2010-11-11, at 19:00, Michael Welzl wrote: >> The idea here is that we really need a more diverse set of folks = playing with IW10. Thoughts? >=20 > Isn't this what Experimental RFCs encourage? We don't really need an RFC to specify how to set IW to 10 - that should = be pretty straightforward to implementors. We also don't need an RFC for lab experiments with IW10. My impression is that Google et al. would like to experiment with IW10 = *on the Internet*, and the WG is asked whether that type of = experimentation is considered to be safe. Lars= From rs@netapp.com Thu Nov 11 03:51:32 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616643A6A5C for ; Thu, 11 Nov 2010 03:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIOcWWnB82QO for ; Thu, 11 Nov 2010 03:51:31 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id D71F13A699E for ; Thu, 11 Nov 2010 03:51:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,182,1288594800"; d="scan'208,217";a="225742607" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 11 Nov 2010 03:51:59 -0800 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oABBpuon028112; Thu, 11 Nov 2010 03:51:58 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 12:51:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8196.D74BD40E" Date: Thu, 11 Nov 2010 11:51:56 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B65CA86@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] dctcp Thread-Index: AcuBltbo7I+MgezEQZ2g0gAvp3gRgQ== From: "Scheffenegger, Richard" To: "tcpm" , "Murari Sridharan" X-OriginalArrivalTime: 11 Nov 2010 11:51:57.0324 (UTC) FILETIME=[D7A5DCC0:01CB8196] Cc: Andrew McGregor Subject: [tcpm] dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 11:51:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB8196.D74BD40E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I just listened to the recorded TCPM meeting, and wanted to follow up on the rather rushed talk about DCTCP. Who made the comment about NFSv4 being prone to the same (incast) issues? (After Andrew made his comment about RED defaults) Also, the recording gave the impression, that there was high interest in doing a I-D. Reading the TSVAREA material, it was also pointed out (storage teaser - NFSv4, iSCSI) that TCPM may need to look closer at datacenter environments rather soon. Were there any other offline discussions outside the meeting room, which would be worthwhile to document here on the list? Best regards, Richard Scheffenegger ------_=_NextPart_001_01CB8196.D74BD40E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [tcpm] dctcp

Hi,

I just listened to the recorded TCPM = meeting, and wanted to follow up on the rather rushed talk about = DCTCP.

Who made the comment about NFSv4 being = prone to the same (incast) issues? (After Andrew made his comment about = RED defaults)

Also, the recording gave the = impression, that there was high interest in doing a I-D.

Reading the TSVAREA material, it was = also pointed out (storage teaser - NFSv4, iSCSI) that TCPM may need to = look closer at datacenter environments rather soon.


Were there any other offline = discussions outside the meeting room, which would be worthwhile to = document here on the list?


Best regards,

Richard = Scheffenegger

------_=_NextPart_001_01CB8196.D74BD40E-- From rs@netapp.com Thu Nov 11 04:14:03 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0EBF3A6A2E for ; Thu, 11 Nov 2010 04:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.366 X-Spam-Level: X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-pWJYkUa0nB for ; Thu, 11 Nov 2010 04:14:02 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 81D0A3A6A0E for ; Thu, 11 Nov 2010 04:14:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,182,1288594800"; d="scan'208";a="219004518" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 11 Nov 2010 04:14:31 -0800 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oABCEQFW003555; Thu, 11 Nov 2010 04:14:30 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 13:14:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 12:14:25 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B65CABA@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Increasing the Initial Window - Notes Thread-Index: AcuBj28lQ2S/LnLvTK+JK/QeEwT5kgAB66fg References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no><4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> From: "Scheffenegger, Richard" To: "Michael Welzl" , "Marco Mellia" X-OriginalArrivalTime: 11 Nov 2010 12:14:26.0996 (UTC) FILETIME=[FC1D7740:01CB8199] Cc: tcpm , Mike Belshe , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 12:14:03 -0000 Michael, I believe that there are numerous other appliactions already deployed, which could make use of IW10... Two particular ones I have in mind is NFS & iSCSI - there you also run into the same issue about short flow completion times - even though the TCP session itself is much more persistent than a typical http/1.1 session. But every once in a while, you have the same cwnd=3Dinitwindow issue when the session was idle for a brief period. I don't know the traffic patterns of IMAP close enough, but it would appear that you also have small objects every once in a while to transport there (even though the real-time requirements are much reduced). Application level signalling would not do it, IMHO. For other applications, that would mean redeploying millions of commercial OS. In comparison, redeploying all the web browsers out there is an fairly easy task. Although I agree that for the public internet, you rarely run NFS/iSCSI over it directly ;) And somehow I think a TCP-level heuristic based on port numbers wouldn't be nice either... Richard Scheffenegger =20 > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no]=20 > Sent: Donnerstag, 11. November 2010 11:58 > To: Marco Mellia > Cc: Mike Belshe; tmrg; Matt Mathis; tcpm > Subject: Re: [tcpm] Increasing the Initial Window - Notes >=20 >=20 > On Nov 11, 2010, at 11:49 AM, Marco Mellia wrote: >=20 > > > > > >>> I certainly won't object to this, if that's all it takes for=20 > >>> standardization. Unfortunately the point for the non-convinced is=20 > >>> they don't want ANY flows to use IW10 for fear of hurting the=20 > >>> performance of their flows. > >> > >> ... but here, your "browsers open tens of flows" argument totally=20 > >> holds. How is a web flow with IW10 worse than a browser=20 > opening tens=20 > >> of flows? If people only use it for the web, like Google has been=20 > >> successfully doing, this seems to be quite safe, based on=20 > experience. > >> > >> I'm curious what the opposition says to this :) > > > > If today a brower opens 10 flows with a server using IW=3D1=20 > you gets 10=20 > > packets equivalent IW. > > Increasing the IW to 10 leads to an equivalent IW of 100=20 > packets. At=20 > > that point, you DSL modem will definitively start dropping most of=20 > > them... >=20 > ... which is a good reason to open fewer connections. So=20 > that's a matter of bringing of bringing out an update of a=20 > web client with a different behavior for the case that a web=20 > server uses a larger IW. =20 > But how does the web browser know what the web server is=20 > doing? I guess they could exchange this information with=20 > HTTP. Hm. Are we getting somewhere here, or is this a dead end? >=20 > Cheers, > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From rs@netapp.com Thu Nov 11 04:26:52 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B463A68F2 for ; Thu, 11 Nov 2010 04:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.515 X-Spam-Level: X-Spam-Status: No, score=-10.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faqKW8H-HtN4 for ; Thu, 11 Nov 2010 04:26:51 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id A1E853A6899 for ; Thu, 11 Nov 2010 04:26:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,183,1288594800"; d="scan'208";a="219005778" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 11 Nov 2010 04:27:19 -0800 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 oABCRFLY005555; Thu, 11 Nov 2010 04:27:19 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Nov 2010 12:27:18 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 12:27:17 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B65CAD6@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Increasing the Initial Window - Notes Thread-Index: AcuBj4Z/Ibn4v6ZoQEid3hB4+9E5lAACn1Og References: <20101110152857.GA5094@hell><20101111012453.GB2691@hell><29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no><824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no><4CDBCA4E.8000705@tlc.polito.it> From: "Scheffenegger, Richard" To: "Jerry Chu" , "Marco Mellia" X-OriginalArrivalTime: 11 Nov 2010 12:27:18.0990 (UTC) FILETIME=[C84266E0:01CB819B] Cc: tmrg , Mike Belshe , tcpm , Matt Mathis , Michael Welzl Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 12:26:52 -0000 Jerry, After some thoughts, I have the following summarization for me: Simulating small pipes is very tricky (concerns about timing effects of = simulator, selection of queuing parameters which are realistic...) Traffic rarely comes in via 1GE, and drops down to a 64kbps bottleneck = link. Only in the direction homeuser->webserver this huge bandwidth = disparity might be encountered in a single step (but even then I doubt = it). Web server traffic probably runs over a series of shrinking pipes (ie = 10G/1G/OC12/OC3/T3/T1/64k) - so in the typical web server environment, = even if each link has only small buffers, the server->homeuser direction = will less likely show bad effects I would think. Which alignes with the = data you presented at ICCSG, correct? Deploying IW10 with NewReno shows almost the same benefits as with Linux = SACK (within 10% of the numbers shown). AFAIK, Linux Newreno is fairly = standards-compatible (at least much more than Linux SACK).=20 For the record, based on my comments regarding non-web traffic, I'm in = support for this proposal, even though I think it should not be deployed = just by itself.=20 I would like to know if the pacing suggestion would make a difference = for the opposition, as that would result in a natural limit of the = burstiness and IW (even beyond 10)? Regards, Richard Scheffenegger =20 > -----Original Message----- > From: Jerry Chu [mailto:hkchu@google.com]=20 > Sent: Donnerstag, 11. November 2010 11:59 > To: Marco Mellia > Cc: tcpm; Mike Belshe; tmrg; Matt Mathis; Michael Welzl > Subject: Re: [tcpm] Increasing the Initial Window - Notes >=20 > On Thu, Nov 11, 2010 at 2:49 AM, Marco Mellia=20 > wrote: > > > > > >>> I certainly won't object to this, if that's all it takes for=20 > >>> standardization. Unfortunately the point for the non-convinced is=20 > >>> they don't want ANY flows to use IW10 for fear of hurting the=20 > >>> performance of their flows. > >> > >> ... but here, your "browsers open tens of flows" argument=20 > totally holds. How is a web flow with IW10 worse than a=20 > browser opening tens of flows? If people only use it for the=20 > web, like Google has been successfully doing, this seems to=20 > be quite safe, based on experience. > >> > >> I'm curious what the opposition says to this =A0:) > > > > If today a brower opens 10 flows with a server using IW=3D1=20 > you gets 10 packets equivalent IW. > > Increasing the IW to 10 leads to an equivalent IW of 100=20 > packets. At that point, you DSL modem will definitively start=20 > dropping most of them... >=20 > But if we don't start thinking about how to scale these TCP=20 > parameters, tomorrow (ok, maybe in a couple of years) when=20 > browsers decide to open 20 or 30 flows because they are=20 > frustrated with low TCP parameters like IW, it will=20 > effectively be equivalent to increasing IW to 10 today. > So do we want to do nothing and leave it all to apps, or try=20 > to take some control of some key TCP parameters back into TCP itself? >=20 > Jerry >=20 > > > > -- > > > > Ciao, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/\/\/\rco > > > > +-----------------------------------+ > > | Marco Mellia - Assistant Professor| > > | Skypeid: mgmellia =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > | Tel: +39-011-564-4173 =A0 =A0 =A0 =A0 =A0 =A0 | > > | Cel: +39-340-9674888 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 /"\ =A0.. . = . . . . .=20 > . . . . . . > > | Politecnico di Torino =A0 =A0 =A0 =A0 =A0 =A0 | =A0 \ / =A0. ASCII = Ribbon=20 > Campaign =A0. > > | Corso Duca degli Abruzzi 24 =A0 =A0 =A0 | =A0 =A0X =A0 .- NO = HTML/RTF=20 > in e-mail . > > | Torino - 10129 - Italy =A0 =A0 =A0 =A0 =A0 =A0| =A0 / \ =A0.- NO = Word=20 > docs in e-mail. > > | http://www.telematica.polito.it =A0 | =A0 =A0 =A0 =A0.. . . . . . = .=20 > . . . . . . > > +-----------------------------------+ > > The box said "Requires Windows 95 or Better." So I installed Linux. > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From ananth@cisco.com Thu Nov 11 07:25:41 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CA33A683F for ; Thu, 11 Nov 2010 07:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGUTQ2fRH6XH for ; Thu, 11 Nov 2010 07:25:40 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 676EE3A68C4 for ; Thu, 11 Nov 2010 07:25:40 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANeZ20yrR7H+/2dsb2JhbACiRXGlMZtVhUoEhFqJDw X-IronPort-AV: E=Sophos;i="4.59,183,1288569600"; d="scan'208";a="618222228" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2010 15:26:10 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oABFQA4O010764; Thu, 11 Nov 2010 15:26:10 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 07:26:10 -0800 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, 11 Nov 2010 07:26:09 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580B2429FA@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <768329AE-9FC1-405E-90A5-070901542D08@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Increasing the Initial Window - Notes Thread-Index: AcuBkKOB8rs1IHpdSsOsiAhUSS9deAAIcf0w References: <20101110152857.GA5094@hell><20101111012453.GB2691@hell><29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no><73BF99B9-B55E-41AA-951D-E6B902160632@nokia.com><580AACC8-1BAB-4971-ABA1-2E65FCA7F7F8@ifi.uio.no> <768329AE-9FC1-405E-90A5-070901542D08@nokia.com> From: "Anantha Ramaiah (ananth)" To: "Lars Eggert" , "Michael Welzl" X-OriginalArrivalTime: 11 Nov 2010 15:26:10.0337 (UTC) FILETIME=[C4A40110:01CB81B4] Cc: tcpm , Mike Belshe , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 15:25:41 -0000 Lars, I have said these things before, again I'll bite. Firstly, who should answer such a question (safety of choosing a particular empirical value for IW) : TCPM or ICCRG?. My book says, ICCRG recommends such a thing to TCPM. Secondly, sometimes we say that "the bar is too high for changing TCP", if we have to go by that golden rule, IW=3D10 is very aggressive change without any knobs to control it, IMO. -Anantha -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Lars Eggert Sent: Thursday, November 11, 2010 3:07 AM To: Michael Welzl Cc: tmrg; Mike Belshe; Matt Mathis; tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes On 2010-11-11, at 19:00, Michael Welzl wrote: >> The idea here is that we really need a more diverse set of folks playing with IW10. Thoughts? >=20 > Isn't this what Experimental RFCs encourage? We don't really need an RFC to specify how to set IW to 10 - that should be pretty straightforward to implementors. We also don't need an RFC for lab experiments with IW10. My impression is that Google et al. would like to experiment with IW10 *on the Internet*, and the WG is asked whether that type of experimentation is considered to be safe. Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From mallman@icir.org Thu Nov 11 09:42:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C853A6A0B for ; Thu, 11 Nov 2010 09:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQcCrqY+kahJ for ; Thu, 11 Nov 2010 09:42:36 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 7A9323A6954 for ; Thu, 11 Nov 2010 09:42:36 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oABHgIEG029974; Thu, 11 Nov 2010 09:42:18 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3568A247BF2B; Thu, 11 Nov 2010 12:42:18 -0500 (EST) To: Hagen Paul Pfeifer From: Mark Allman In-Reply-To: <20101110152857.GA5094@hell> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Layla MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma10999-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 11 Nov 2010 12:42:18 -0500 Sender: mallman@icir.org Message-Id: <20101111174218.3568A247BF2B@lawyers.icir.org> Cc: tmrg , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 17:42:38 -0000 ----------ma10999-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have inhaled the initial window thread and have some thoughts ... + Altering the initial window is not a *fundamental* change to TCP. It is a *parameter* tweak. Certainly parameter tweaks can have negative and broad implications, but lets show some perspective here. + Likewise, changing the initial cwnd **does not remove CC**. As a connection gets feedback from the network path it does what it has always done and reacts to its observations. So, a problematic initial window size will in fact get corrected. + It is not true that somehow using an initial cwnd of 10 packets makes that the minimum cwnd size. TCP has mechanisms to lower the cwnd if that is necessary. + Nobody is mandating using a cwnd of 10 packets. If a host is in a particular situation whereby less would be better then it can use less (either by tuning its own initial cwnd or by appropriately setting the advertised window). + Is this HTTP-centric? Well, maybe. It is medium transfer size-centric. HTTP is a big component of those transfers at present. But, I don't follow why this is a big deal. This seems like a red herring to me. + Adjusting a parameter is not renouncing the conservativeness principle. It is perfectly natural for a parameter like this to evolve over time as networks evolve. Just because there used to be excessively low speed networks doesn't mean that somehow we need to be bound by that for the entire future. And, adjusting for "inflation" doesn't somehow abdicate the principle of being conservative. Put another way, conservativeness and aggressiveness are relative and we are merely trying to find a reasonable tradeoff here. + Further, there are always *current* networks that lag behind. At some point we have to decide that our engineering is going to be for the 99.9% common case and the outliers are going to have to deal with it. People lodged the complaint that there were slow networks when we moved from one packet to three. That will always be the case. I'm not saying if you're in the minority we forget you here. If this change is good for only 51% of the cases then it is not a good change. But, because we have an existence proof of some spot that cannot cope with a 10 packet burst does not mean this is a bad idea. + Just because IW=10 causes loss doesn't mean it hurts performance. Jerry, et.al. have testbed experiments that show this. The steady state loss rate of a TCP is a key component of performance. But, that doesn't mean loss in the initial window dictates long-term performance. If a network can only support a window of three packets then the performance is going to be lousy regardless of the initial window. A larger initial window is not likely to change the overall performance---as the experiments illustrate. (There is the chance that in the case of multiple congested gateways that the extra packets will consume scarce resources and therefore impact other flows. But, with excessively low capacity networks it is really hard to envision the initial cwnd as being the thing that makes the network lousy.) + Maybe this exacerbates the case of long queues in home networks. But, (1) I doubt its a big deal and (2) that isn't exactly TCP's problem. On my DSL line I never build a perceptible queue on the downlink. On the uplink I do. If I am doing the math right my uplink would build a 1sec queue at 10 parallel connections using IW=10 and starting at the same time. But, that seems like a pretty thin use case. I.e., I never start that many connections and pump data into them in that fashion. I might start that many connections / second, but I put 300 bytes of HTTP GET in there or the like. In the cases where I can think of that you would start connections at a high rate (at least in a burst) and then pump data into them (e.g. BitTorrent) you're going to build this queue anyway. And, it just isn't clear to me that we need to somehow make TCP "solve" this problem because fundamentally we just need less buffering. + Allowing apps to tune the IW via a socket option seems pretty pointless to me. I doubt the application is in any sort of position to pick wisely. If they do anything but turn it to the maximum allowed it would be pretty surprising, I think. While perhaps we can say the onus is on the proposers to convince us, it seems as though Jerry et.al. have done all the experiments that comments have pointed to. If you have a concrete problem with the proposal it'd be nice to see that in concrete terms---experiments---instead of hand waves. FWIW. allman ----------ma10999-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzcKvkACgkQWyrrWs4yIs4nDwCffqUSSsfoWF8EA0KyKNubluHi x4EAnjT21dqo3iI2SMfF+Px64OEVoCSZ =bKkJ -----END PGP SIGNATURE----- ----------ma10999-1-- From johnwheffner@gmail.com Thu Nov 11 11:32:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D6C3A68C3 for ; Thu, 11 Nov 2010 11:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNOWnKUATWRZ for ; Thu, 11 Nov 2010 11:32:42 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 242263A68BD for ; Thu, 11 Nov 2010 11:32:41 -0800 (PST) Received: by bwz12 with SMTP id 12so2812222bwz.31 for ; Thu, 11 Nov 2010 11:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u/Xs4li8oHGS5DtF0UxkiS1YTvDAYw/wZiP7O9BTvDg=; b=dF71SUuO+BAIZK+d3JFOTeevhcDS3rJ7xHftG/5NedTqeu05a63Lg2aVTRU7yrc6rp Q+NxJs/R90peww9HTRV9qDIBrA6eti5G410VSlT4BmXZ3gpUU3i8pUYCaMO2jvtFzMdR 5/wPmIK+azdjN0K8FLCQnnFvmJl/8MjXhiGy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=d7GY1x5IYOC8OUiT9wB/3j0+qdxdye0SzG7qlfrlgNPI/Q/h0Uku7bHqGsWh76HZZD DVCfG7zucdpC8uf7DTITWs1oQnU6H92pjIontTk3o2Nxx9xDv/BBCfZP3nUTKViRKn/W yQwdWJOMvpuFf04A3PjalTCTmxEve/UX2iubo= MIME-Version: 1.0 Received: by 10.204.64.139 with SMTP id e11mr1812975bki.212.1289503991238; Thu, 11 Nov 2010 11:33:11 -0800 (PST) Received: by 10.204.118.67 with HTTP; Thu, 11 Nov 2010 11:33:10 -0800 (PST) In-Reply-To: <20101111174218.3568A247BF2B@lawyers.icir.org> References: <20101110152857.GA5094@hell> <20101111174218.3568A247BF2B@lawyers.icir.org> Date: Thu, 11 Nov 2010 14:33:10 -0500 Message-ID: From: John Heffner To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tmrg , tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 19:32:44 -0000 I completely agree with everything Mark said. A couple questions, though: Do we have to go through this every ten years? Do implementors really need the IETF's blessing on some particular IW value? Do we want to put ourselves in that position? The IETF is not terribly good at weighing trade-offs, where a change might benefit some at the expense of others. Maybe we can issue some broader and longer-lasting guidance. Thanks, -John On Thu, Nov 11, 2010 at 12:42 PM, Mark Allman wrote: > > I have inhaled the initial window thread and have some thoughts ... > > =A0+ Altering the initial window is not a *fundamental* change to TCP. > =A0 =A0It is a *parameter* tweak. =A0Certainly parameter tweaks can have > =A0 =A0negative and broad implications, but lets show some perspective > =A0 =A0here. > > =A0+ Likewise, changing the initial cwnd **does not remove CC**. =A0As a > =A0 =A0connection gets feedback from the network path it does what it has > =A0 =A0always done and reacts to its observations. =A0So, a problematic > =A0 =A0initial window size will in fact get corrected. > > =A0+ It is not true that somehow using an initial cwnd of 10 packets > =A0 =A0makes that the minimum cwnd size. =A0TCP has mechanisms to lower t= he > =A0 =A0cwnd if that is necessary. > > =A0+ Nobody is mandating using a cwnd of 10 packets. =A0If a host is in a > =A0 =A0particular situation whereby less would be better then it can use > =A0 =A0less (either by tuning its own initial cwnd or by appropriately > =A0 =A0setting the advertised window). > > =A0+ Is this HTTP-centric? =A0Well, maybe. =A0It is medium transfer > =A0 =A0size-centric. =A0HTTP is a big component of those transfers at > =A0 =A0present. =A0But, I don't follow why this is a big deal. =A0This se= ems > =A0 =A0like a red herring to me. > > =A0+ Adjusting a parameter is not renouncing the conservativeness > =A0 =A0principle. =A0It is perfectly natural for a parameter like this to > =A0 =A0evolve over time as networks evolve. =A0Just because there used to= be > =A0 =A0excessively low speed networks doesn't mean that somehow we need t= o > =A0 =A0be bound by that for the entire future. =A0And, adjusting for > =A0 =A0"inflation" doesn't somehow abdicate the principle of being > =A0 =A0conservative. =A0Put another way, conservativeness and aggressiven= ess > =A0 =A0are relative and we are merely trying to find a reasonable tradeof= f > =A0 =A0here. > > =A0+ Further, there are always *current* networks that lag behind. =A0At > =A0 =A0some point we have to decide that our engineering is going to be f= or > =A0 =A0the 99.9% common case and the outliers are going to have to deal > =A0 =A0with it. =A0People lodged the complaint that there were slow netwo= rks > =A0 =A0when we moved from one packet to three. =A0That will always be the > =A0 =A0case. =A0I'm not saying if you're in the minority we forget you he= re. > =A0 =A0If this change is good for only 51% of the cases then it is not a > =A0 =A0good change. =A0But, because we have an existence proof of some sp= ot > =A0 =A0that cannot cope with a 10 packet burst does not mean this is a ba= d > =A0 =A0idea. > > =A0+ Just because IW=3D10 causes loss doesn't mean it hurts performance. > =A0 =A0Jerry, et.al. have testbed experiments that show this. =A0The stea= dy > =A0 =A0state loss rate of a TCP is a key component of performance. =A0But= , > =A0 =A0that doesn't mean loss in the initial window dictates long-term > =A0 =A0performance. =A0If a network can only support a window of three > =A0 =A0packets then the performance is going to be lousy regardless of th= e > =A0 =A0initial window. =A0A larger initial window is not likely to change= the > =A0 =A0overall performance---as the experiments illustrate. > > =A0 =A0(There is the chance that in the case of multiple congested gatewa= ys > =A0 =A0that the extra packets will consume scarce resources and therefore > =A0 =A0impact other flows. =A0But, with excessively low capacity networks= it > =A0 =A0is really hard to envision the initial cwnd as being the thing tha= t > =A0 =A0makes the network lousy.) > > =A0+ Maybe this exacerbates the case of long queues in home networks. > =A0 =A0But, (1) I doubt its a big deal and (2) that isn't exactly TCP's > =A0 =A0problem. =A0On my DSL line I never build a perceptible queue on th= e > =A0 =A0downlink. =A0On the uplink I do. =A0If I am doing the math right m= y > =A0 =A0uplink would build a 1sec queue at 10 parallel connections using > =A0 =A0IW=3D10 and starting at the same time. =A0But, that seems like a p= retty > =A0 =A0thin use case. =A0I.e., I never start that many connections and pu= mp > =A0 =A0data into them in that fashion. =A0I might start that many connect= ions > =A0 =A0/ second, but I put 300 bytes of HTTP GET in there or the like. = =A0In > =A0 =A0the cases where I can think of that you would start connections at= a > =A0 =A0high rate (at least in a burst) and then pump data into them > =A0 =A0(e.g. BitTorrent) you're going to build this queue anyway. =A0And,= it > =A0 =A0just isn't clear to me that we need to somehow make TCP "solve" th= is > =A0 =A0problem because fundamentally we just need less buffering. > > =A0+ Allowing apps to tune the IW via a socket option seems pretty > =A0 =A0pointless to me. =A0I doubt the application is in any sort of posi= tion > =A0 =A0to pick wisely. =A0If they do anything but turn it to the maximum > =A0 =A0allowed it would be pretty surprising, I think. > > While perhaps we can say the onus is on the proposers to convince us, it > seems as though Jerry et.al. have done all the experiments that comments > have pointed to. =A0If you have a concrete problem with the proposal it'd > be nice to see that in concrete terms---experiments---instead of hand > waves. > > FWIW. > > allman > > > > > _______________________________________________ > Tmrg-interest mailing list > Tmrg-interest@ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest > > From mallman@icir.org Thu Nov 11 11:33:32 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12B6B3A68C3 for ; Thu, 11 Nov 2010 11:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaLVvEkKzDlk for ; Thu, 11 Nov 2010 11:33:30 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 2A82B3A68BD for ; Thu, 11 Nov 2010 11:33:30 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oABJXvsC011374; Thu, 11 Nov 2010 11:33:58 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AE17E247DF4F; Thu, 11 Nov 2010 14:33:57 -0500 (EST) To: Lars Eggert From: Mark Allman In-Reply-To: <73BF99B9-B55E-41AA-951D-E6B902160632@nokia.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Layla MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma17701-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 11 Nov 2010 14:33:57 -0500 Sender: mallman@icir.org Message-Id: <20101111193357.AE17E247DF4F@lawyers.icir.org> Cc: tcpm , Mike Belshe , tmrg , Matt Mathis , Michael Welzl Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 19:33:32 -0000 ----------ma17701-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Lars- > we currently seem to be a bit stuck. The Google folks have gathered a > lot of data, but at the moment it's still not quite clear - to me at > least - what data-based argument would convince the WG to either > permit IW10 and under what considerations, or which argument would > convince us to not do it. OK. Hard to argue with that. But then ... > I talked to a few folks after the meeting and made this suggestion: > > * Google makes the raw data available. Yoshifumi requested this at the > mike, and Jerry said he'd see if this was possible. > > * We plan a TCPM interim in a few months, with the only topic being > IW10. ... this seems a bit weird. I.e., you can't envision data-based cases either way and then you propose a whole meeting around trying to build them. > * Folks (other than Google) who like IW10 crunch down the raw Google > data in an attempt to provide a convincing argument to allow it, and > under which conditions. (Obviously, folks can also generate their > own data, if they like.) > > * Folks sceptical about IW10 crunch down the Google data in an attempt > to find problematic cases that'd make the WG lean against > IW10. (Obviously, folks can also generate their own data, if they > like.) > > * We hold the interim with these folks presenting, and see what shakes > out. > > The idea here is that we really need a more diverse set of folks > playing with IW10. Thoughts? It would be great if a more diverse set of folks was playing with this, but haven't the Google folk answered the questions that have been posed with their data? So, what good is it to put that data in other people's hands? Do we think Google is botching the analysis or lying to us? I'd have framed this differently: it'd be nice to see a more diverse set of folks playing with empirical data from a diverse set of vantage points. Just getting more people to mess about in the data that Google has analyzed in all requested ways (as far as I can tell) doesn't seem particularly useful. That is not to say that Google has drawn all possible insight from their data. But, it seems they have at least gotten the high-order bits. And, my hunch is that giving away data in any sort of fine-grained way is not going to be easy. And, further, this is all just fishing. In other words, if we hand out the data then we're hoping someone will be able to analyze it and get some additional insight out of it. I'd feel much better about this sort of interim effort if there were at least a strawman set of Big Questions that folks were going to go after. And, further, if there are people who will in fact put in the time to analyze the data in a non-glib fashion. I have an entirely different proposal... Someone should start a list of questions that give folks pause about IW=10. Just make this an I-D that is meant to move the process along and not meant to be published as an RFC. Let the proponents---or anyone with handy data that bears on them---address these issues. Maybe that resolves the question. Maybe it doesn't. But, at least this (1) moves us beyond fuzzy notions of it "not feeling right" to move to IW=10 by forcing folks to state possible issues in concrete terms and (2) it provides a clear path to what the WG wants to understand before taking some action on this proposal. The questions in this mythical I-D can then be annotated with pointers to answers or possible answers. I'll (begrudgingly) keep the list if folks want. allman ----------ma17701-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzcRSUACgkQWyrrWs4yIs7K1gCfQSWAxWpeQCmEHd2pOGtR4XLh vP4AnA227t78e31k7HAN4UakTihzHggw =90H9 -----END PGP SIGNATURE----- ----------ma17701-1-- From hkchu@google.com Thu Nov 11 14:56:33 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311CB3A687A for ; Thu, 11 Nov 2010 14:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.474 X-Spam-Level: X-Spam-Status: No, score=-105.474 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9-pwTj6+8EI for ; Thu, 11 Nov 2010 14:56:32 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CFE253A6A69 for ; Thu, 11 Nov 2010 14:56:31 -0800 (PST) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id oABMv1Xj030468 for ; Thu, 11 Nov 2010 14:57:01 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289516222; bh=+D86RsUBtb1B2ydxa4Le67v0mGM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=viowDaxCgEODi7Fw31RqXMzE3I/b4HwojpiyTJA+Am50QybmOK/rgWkcuCQ9byITi pQAh3pg/ScgJWS6Xkd3bA== Received: from gyd12 (gyd12.prod.google.com [10.243.49.204]) by hpaq12.eem.corp.google.com with ESMTP id oABMuxJ5027658 for ; Thu, 11 Nov 2010 14:57:00 -0800 Received: by gyd12 with SMTP id 12so1591249gyd.30 for ; Thu, 11 Nov 2010 14:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=rG8t9lyp9Z8YEsImOc/SOzuVoO3YArlYuXn01jgrqLA=; b=XlkYDHfBETYJe+WE8iOBctBkOQym1PJhRhHrNbu/OApTelcWSnhz4tkyrGyxLPA/PH TrVKrkSKtlRC/w6DbJPg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fhQtG7Cm24yJlVZbNPcX2SgMhTn/BNPCgtevtD3H02/P0Jp1mAe+37aRk3HJ28TGjt j/cJdcgSZlmWNKSZ6GyQ== MIME-Version: 1.0 Received: by 10.150.91.13 with SMTP id o13mr2721617ybb.6.1289516219317; Thu, 11 Nov 2010 14:56:59 -0800 (PST) Received: by 10.150.145.4 with HTTP; Thu, 11 Nov 2010 14:56:59 -0800 (PST) In-Reply-To: <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> Date: Thu, 11 Nov 2010 14:56:59 -0800 Message-ID: From: Jerry Chu To: Michael Welzl Content-Type: multipart/alternative; boundary=000e0cd47d9a2f402b0494cee411 X-System-Of-Record: true Cc: tmrg , Mike Belshe , Marco Mellia , Matt Mathis , tcpm Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 22:56:33 -0000 --000e0cd47d9a2f402b0494cee411 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 11, 2010 at 2:58 AM, Michael Welzl wrote: > > On Nov 11, 2010, at 11:49 AM, Marco Mellia wrote: > > >> >> I certainly won't object to this, if that's all it takes for >>>> standardization. Unfortunately the >>>> point for the non-convinced is they don't want ANY flows to use IW10 >>>> for fear of hurting >>>> the performance of their flows. >>>> >>> >>> ... but here, your "browsers open tens of flows" argument totally holds. >>> How is a web flow with IW10 worse than a browser opening tens of flows? If >>> people only use it for the web, like Google has been successfully doing, >>> this seems to be quite safe, based on experience. >>> >>> I'm curious what the opposition says to this :) >>> >> >> If today a brower opens 10 flows with a server using IW=1 you gets 10 >> packets equivalent IW. >> Increasing the IW to 10 leads to an equivalent IW of 100 packets. At that >> point, you DSL modem will definitively start dropping most of them... >> > > ... which is a good reason to open fewer connections. So that's a matter of > bringing of bringing out an update of a web client with a different behavior > for the case that a web server uses a larger IW. But how does the web > browser know what the web server is doing? I guess they could exchange this > information with HTTP. Hm. Are we getting somewhere here, or is this a dead > end? > One solution to safely migrate to IW10 for browsers opening multiple connections is to mandate browsers that open X connections, when X is, e.g., > 4 to set the initial receive window to 3 (assuming OSes allow initrwnd to be set on a per connection basis). But I don't know how this can be enforced... Jerry > Cheers, > Michael > > --000e0cd47d9a2f402b0494cee411 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Nov 11, 2010 at 2:58 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

On Nov 11, 2010, at 11:49 AM, Marco Mellia wrote:



I certainly won't object to this, if that's all it takes for
standardization. Unfortunately the
point for the non-convinced is they don't want ANY flows to use IW10 for fear of hurting
the performance of their flows.

... but here, your "browsers open tens of flows" argument totally= holds. How is a web flow with IW10 worse than a browser opening tens of fl= ows? If people only use it for the web, like Google has been successfully d= oing, this seems to be quite safe, based on experience.

I'm curious what the opposition says to this =A0:)

If today a brower opens 10 flows with a server using IW=3D1 you gets 10 pac= kets equivalent IW.
Increasing the IW to 10 leads to an equivalent IW of 100 packets. At that p= oint, you DSL modem will definitively start dropping most of them...

... which is a good reason to open fewer connections. So that's a matte= r of bringing of bringing out an update of a web client with a different be= havior for the case that a web server uses a larger IW. But how does the we= b browser know what the web server is doing? I guess they could exchange th= is information with HTTP. Hm. Are we getting somewhere here, or is this a d= ead end?

One solution to safely migrate to IW10 for= browsers opening multiple connections is to mandate browsers that open X c= onnections, when X is, e.g., > 4 to set the initial receive window to 3 = (assuming OSes allow initrwnd to be set on a per connection basis). But I d= on't know how this can be enforced...

Jerry


Cheers,
Michael


--000e0cd47d9a2f402b0494cee411-- From hagen@jauu.net Thu Nov 11 19:51:24 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91633A67B8 for ; Thu, 11 Nov 2010 19:51:24 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+a2RrWxMjvu for ; Thu, 11 Nov 2010 19:51:24 -0800 (PST) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id D3BBD3A67E5 for ; Thu, 11 Nov 2010 19:51:23 -0800 (PST) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id A1A1DF44191; Fri, 12 Nov 2010 04:51:53 +0100 (CET) Date: Fri, 12 Nov 2010 04:51:46 +0100 From: Hagen Paul Pfeifer To: Lars Eggert Message-ID: <20101112035144.GA2740@hell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: tcpm , Fernando Gont Subject: [tcpm] TCP User Timeout Option Implementation - RFC 5482 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 03:51:24 -0000 Hallo TCPM, due to some free-time here in Beijing I finally complete the UTO implementation for Linux. A follow up posting will include a patch which applies on top of Davem's net-next HEAD. A description on the systctl and socket options is included. I will push the patch upstream in a couple of days. Until then I will clean up the code, optimize the code path, update the commit message and kernel related stuff. Additionally I will proof that a transmitted packet - with UTO - is ACKed and if not transmit the packet with UTO again, the keepalive timer must - depending on the UTO value - adjusted as well. Furthermore I will verify the functionality based on the RFC and do some testings. If someone is interested on my KVM/QEMU/NETEM testbed setup - I can post this too. The later, the testing and verification, will probably takes some time because the tests are not that trivial. Cheers, Hagen From hagen@jauu.net Thu Nov 11 21:13:51 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10CBD28C0D7 for ; Thu, 11 Nov 2010 21:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mejZxhaemwFO for ; Thu, 11 Nov 2010 21:13:45 -0800 (PST) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id F18C03A6A97 for ; Thu, 11 Nov 2010 21:13:44 -0800 (PST) Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 2228FF44191; Fri, 12 Nov 2010 06:14:16 +0100 (CET) Date: Fri, 12 Nov 2010 06:14:10 +0100 From: Hagen Paul Pfeifer To: Lars Eggert Message-ID: <20101112051408.GA18246@hell> References: <20101112035144.GA2740@hell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101112035144.GA2740@hell> 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.20 (2009-06-14) Cc: tcpm , Fernando Gont Subject: Re: [tcpm] TCP User Timeout Option Implementation - RFC 5482 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 05:13:51 -0000 * Hagen Paul Pfeifer | 2010-11-12 04:51:46 [+0100]: >I will push the patch upstream in a couple of days. Until then I will clean up [...] it seems [tcpm] drop patches/larger emails. The patch can be grabbed from http://git.jauu.net/?p=net-2.6-topics.git;a=log;h=refs/heads/tcp-uto (tcp-uto topic branch) Hagen From L.Wood@surrey.ac.uk Fri Nov 12 01:48:09 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968603A6B14 for ; Fri, 12 Nov 2010 01:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z65gA2lnnIUG for ; Fri, 12 Nov 2010 01:48:08 -0800 (PST) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id BD9F23A6B27 for ; Fri, 12 Nov 2010 01:47:57 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-15.tower-78.messagelabs.com!1289555308!20472307!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.43] Received: (qmail 5852 invoked from network); 12 Nov 2010 09:48:29 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-15.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 12 Nov 2010 09:48:29 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Fri, 12 Nov 2010 09:48:28 +0000 From: To: , Date: Fri, 12 Nov 2010 09:48:30 +0000 Thread-Topic: [tcpm] Increasing the Initial Window - Notes Thread-Index: AcuB88ko5Jn6AxYzQP+bRw5o38p4XQAVzjRQ Message-ID: References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_FD7B10366AE3794AB1EC5DE97A93A37316BF44877DEXMB01CMSsurr_" MIME-Version: 1.0 Cc: tcpm@ietf.org, mbelshe@google.com, tmrg-interest@icsi.berkeley.edu, mattmathis@google.com, mellia@tlc.polito.it Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 09:48:09 -0000 --_000_FD7B10366AE3794AB1EC5DE97A93A37316BF44877DEXMB01CMSsurr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > If today a brower opens 10 flows with a server using IW=3D1 you gets 10 p= ackets equivalent IW And the browser is ignoring RFC 2068 section 8.1: Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD maintain AT MOST 2 connections with any server or proxy. --_000_FD7B10366AE3794AB1EC5DE97A93A37316BF44877DEXMB01CMSsurr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
> If today a brower opens 10 flows= with=20 a server using IW=3D1 you gets 10 packets equivalent IW
 
And=20 the browser is ignoring RFC 2068 section 8.1:
   Clients that use persistent connections SH=
OULD limit the number of
   simultaneous connections that they maintain to a given server. A
   single-user client SHOULD maintain AT MOST 2 connections with any
   server or proxy.
--_000_FD7B10366AE3794AB1EC5DE97A93A37316BF44877DEXMB01CMSsurr_-- From mellia@tlc.polito.it Fri Nov 12 06:03:27 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B93D3A6A06 for ; Fri, 12 Nov 2010 06:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.073 X-Spam-Level: X-Spam-Status: No, score=-0.073 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxL-hWuSSLUN for ; Fri, 12 Nov 2010 06:03:20 -0800 (PST) Received: from mail.tlc.polito.it (baobab.polito.it [130.192.9.198]) by core3.amsl.com (Postfix) with SMTP id DECC23A67DB for ; Fri, 12 Nov 2010 06:03:19 -0800 (PST) Received: (qmail 12481 invoked by uid 88); 12 Nov 2010 14:03:46 -0000 Received: from rucola.polito.it (HELO [130.192.9.140]) (130.192.9.140) (smtp-auth username mellia@tlc.polito.it, mechanism plain) by mail.tlc.polito.it (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Fri, 12 Nov 2010 15:03:46 +0100 Message-ID: <4CDD493B.6000201@tlc.polito.it> Date: Fri, 12 Nov 2010 15:03:39 +0100 From: Marco Mellia User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TLC-MailScanner-Information: Please contact the ISP for more information X-TLC-MailScanner: Found to be clean X-TLC-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.759, required 4, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.64, BAYES_00 -2.60) X-TLC-MailScanner-From: mellia@tlc.polito.it Cc: tcpm@ietf.org, tmrg-interest@icsi.berkeley.edu Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 14:03:27 -0000 well... check this then http://www.browserscope.org/ in the networking statistics... Il 12/11/2010 10:48, L.Wood@surrey.ac.uk ha scritto: > > If today a brower opens 10 flows with a server using IW=1 you gets 10 > packets equivalent IW > And the browser is ignoring RFC 2068 section 8.1: > Clients that use persistent connections SHOULD limit the number of > simultaneous connections that they maintain to a given server. A > single-user client SHOULD maintain AT MOST 2 connections with any > server or proxy. -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Skypeid: mgmellia | | Tel: +39-011-090-4173 | | Cel: +39-331-6714789 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www.telematica.polito.it | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux. From L.Wood@surrey.ac.uk Fri Nov 12 06:07:10 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16353A6886 for ; Fri, 12 Nov 2010 06:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r09YM1S-wdqZ for ; Fri, 12 Nov 2010 06:07:04 -0800 (PST) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id AD7F53A68A6 for ; Fri, 12 Nov 2010 06:07:03 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-2.tower-78.messagelabs.com!1289570855!39868194!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 13469 invoked from network); 12 Nov 2010 14:07:35 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-2.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 12 Nov 2010 14:07:35 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Fri, 12 Nov 2010 14:07:35 +0000 From: To: Date: Fri, 12 Nov 2010 14:05:28 +0000 Thread-Topic: [tcpm] Increasing the Initial Window - Notes Thread-Index: AcuCcnjMFe/7Uj+qRBOR8mATXl3QhQAADCMw Message-ID: References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> , <4CDD493B.6000201@tlc.polito.it> In-Reply-To: <4CDD493B.6000201@tlc.polito.it> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tmrg-interest@icsi.berkeley.edu, tcpm@ietf.org Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 14:07:10 -0000 The point is that implementations don't toe the lne on number of connection= s per host (6 connections per hostname? Not persistent flows, but actual TC= P connections?), and we're not going to move the line to suit them. The same goes for initial window, I think. Lloyd Wood http://tinyurl.com/lloydwood-ccsr ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Marco Mell= ia [mellia@tlc.polito.it] Sent: 12 November 2010 14:03 Cc: tcpm@ietf.org; tmrg-interest@icsi.berkeley.edu Subject: Re: [tcpm] Increasing the Initial Window - Notes well... check this then http://www.browserscope.org/ in the networking statistics... Il 12/11/2010 10:48, L.Wood@surrey.ac.uk ha scritto: > > If today a brower opens 10 flows with a server using IW=3D1 you gets 10 > packets equivalent IW > And the browser is ignoring RFC 2068 section 8.1: > Clients that use persistent connections SHOULD limit the number of > simultaneous connections that they maintain to a given server. A > single-user client SHOULD maintain AT MOST 2 connections with any > server or proxy. -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Skypeid: mgmellia | | Tel: +39-011-090-4173 | | Cel: +39-331-6714789 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www.telematica.polito.it | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From mellia@tlc.polito.it Fri Nov 12 07:13:52 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5433A6917 for ; Fri, 12 Nov 2010 07:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjfAGNfl1pRa for ; Fri, 12 Nov 2010 07:13:44 -0800 (PST) Received: from mail.tlc.polito.it (baobab.polito.it [130.192.9.198]) by core3.amsl.com (Postfix) with SMTP id 67DCE3A6912 for ; Fri, 12 Nov 2010 07:13:44 -0800 (PST) Received: (qmail 17235 invoked by uid 88); 12 Nov 2010 15:14:12 -0000 Received: from rucola.polito.it (HELO [130.192.9.140]) (130.192.9.140) (smtp-auth username mellia@tlc.polito.it, mechanism plain) by mail.tlc.polito.it (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Fri, 12 Nov 2010 16:14:12 +0100 Message-ID: <4CDD59BE.60704@tlc.polito.it> Date: Fri, 12 Nov 2010 16:14:06 +0100 From: Marco Mellia User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> , <4CDD493B.6000201@tlc.polito.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TLC-MailScanner-Information: Please contact the ISP for more information X-TLC-MailScanner: Found to be clean X-TLC-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.759, required 4, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.64, BAYES_00 -2.60) X-TLC-MailScanner-From: mellia@tlc.polito.it Cc: tcpm@ietf.org, tmrg-interest@icsi.berkeley.edu Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 15:13:52 -0000 Definitively agree with you. Eventually, the question is if the IEFT should suggest a switch to a more aggressive setting when non standard solutions are common practice and can possibly interfere (badly) with this change. I mean, let's say now all linux/windows/bsd servers start switching to IW 10, so that 99% of server traffic now arrives with a definitively increase burstines. What are the global implication of this switch coupled with today common practice of already tweaking the TCP limits when IW is more conservative? Say today those tweaks are used by 10% of traffic, so they do not interfere too much. What happens tomorrow when all traffic becomes more aggressive? My intuition is that the increase the default IW to 10 would benefit in some cases where there is lot of bandwidth, but in some cases it would definitively hurt, especially when thinking about mobile terminals, which btw seems to me being very important in these days. This is just my 2c. Ciao Marco Il 12/11/2010 15:05, L.Wood@surrey.ac.uk ha scritto: > The point is that implementations don't toe the lne on number of connections per host (6 connections per hostname? Not persistent flows, but actual TCP connections?), and we're not going to move the line to suit them. > > The same goes for initial window, I think. > > Lloyd Wood > http://tinyurl.com/lloydwood-ccsr > ________________________________________ > From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Marco Mellia [mellia@tlc.polito.it] > Sent: 12 November 2010 14:03 > Cc: tcpm@ietf.org; tmrg-interest@icsi.berkeley.edu > Subject: Re: [tcpm] Increasing the Initial Window - Notes > > well... > check this then > http://www.browserscope.org/ > in the networking statistics... > > > Il 12/11/2010 10:48, L.Wood@surrey.ac.uk ha scritto: > >>> If today a brower opens 10 flows with a server using IW=1 you gets 10 >>> >> packets equivalent IW >> And the browser is ignoring RFC 2068 section 8.1: >> Clients that use persistent connections SHOULD limit the number of >> simultaneous connections that they maintain to a given server. A >> single-user client SHOULD maintain AT MOST 2 connections with any >> server or proxy. >> > -- > > Ciao, /\/\/\rco > > +-----------------------------------+ > | Marco Mellia - Assistant Professor| > | Skypeid: mgmellia | > | Tel: +39-011-090-4173 | > | Cel: +39-331-6714789 | /"\ .. . . . . . . . . . . . . > | Politecnico di Torino | \ / . ASCII Ribbon Campaign . > | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . > | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. > | http://www.telematica.polito.it | .. . . . . . . . . . . . . > +-----------------------------------+ > The box said "Requires Windows 95 or Better." So I installed Linux. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Skypeid: mgmellia | | Tel: +39-011-090-4173 | | Cel: +39-331-6714789 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www.telematica.polito.it | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux. From rs@netapp.com Fri Nov 12 08:54:35 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7693A69A2 for ; Fri, 12 Nov 2010 08:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnMQ45S5W6w3 for ; Fri, 12 Nov 2010 08:54:27 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id A9F9E3A6A02 for ; Fri, 12 Nov 2010 08:54:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,188,1288594800"; d="scan'208";a="219287219" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 12 Nov 2010 08:54:58 -0800 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oACGsv0j000266; Fri, 12 Nov 2010 08:54:57 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Nov 2010 17:54:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Nov 2010 16:54:54 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B65D203@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4CDD59BE.60704@tlc.polito.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Increasing the Initial Window - Notes Thread-Index: AcuCfFqzWJ33qcj3StmFl5Mokz2s7wACcWUg References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> , <4CDD493B.6000201@tlc.polito.it> <4CDD59BE.60704@tlc.polito.it> From: "Scheffenegger, Richard" To: "Marco Mellia" , X-OriginalArrivalTime: 12 Nov 2010 16:54:56.0926 (UTC) FILETIME=[55F2BBE0:01CB828A] Cc: tmrg-interest@icsi.berkeley.edu, tcpm@ietf.org Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 16:54:35 -0000 Hi Marco, I'm not so sure I follow the argument with the mobile end devices - especially with that data from browserscope which has been brought up. Opera Mini 5.1.21566 11 connections/hostname Nokia 75 12 connections/hostname Blackberry 8900 12 connections/hostname Opera Mini 4.2.15227 21 connections/hostname Sony Ericsson K800i 24 connections/hostname More of the outliers seem to be browsers on mobile devices... Even though the majority of desktop browsers runs at 6 connections/host. (My inititive guess is, that these browsers don't sort objects by size when downloading, but prefer to present most of a page at the same time - with TCP head of line blocking subsequent pipelined objects, multiple objects would be delayed if only few sessions are used. With only one object per session, but 20+ in parallel, only the objects of directly impacted flows are delayed). I think of IW10 more in terms of minimizing latency for small objects (regardless of application protocol). After all, with IW10 fast recovery does have a chance to get triggered, whereas with IW3, only Early Retransmit and RTO are available but no fast retransmit. My original concerns about IW10 were based on my (obviously unfounded) assumption, that IW10 will only show better latency for small objects when the server is also making use of advanced features (sack, early retransmit, lost retransmit detection, F-RTO, Eifel...). But the most recent dataset shows, that this goal - minimizing latency - can be achived even with standard NewReno, and higher packet loss ratios (which are expected). It appears to me, that we are now discussing if the undoubtedly increased packet loss rate (~ +24%) is more troublesome (to the network) than the faster delivery of objects (to the clients) (~ -13%). And, as mentioned above, will the increased aggressiveness of flows (because fast recovery may be leading to more load early on) hurt the network beyond that... And as Mark pointed out, this effects are really only transient, for bulk transfers the behavior is unchanged. And, senders who are adjacent to links with very small queues would tend to hurt themselves the most - potentially causing a change to IW3 locally if it improves their sending performance. Does that make sense, or am I off track? Thanks, Richard Scheffenegger =20 > -----Original Message----- > From: Marco Mellia [mailto:mellia@tlc.polito.it]=20 > Sent: Freitag, 12. November 2010 16:14 > To: L.Wood@surrey.ac.uk > Cc: tcpm@ietf.org; tmrg-interest@icsi.berkeley.edu > Subject: Re: [tcpm] Increasing the Initial Window - Notes >=20 >=20 > Definitively agree with you. >=20 > Eventually, the question is if the IEFT should suggest a=20 > switch to a more aggressive setting when non standard=20 > solutions are common practice and can possibly interfere=20 > (badly) with this change. >=20 > I mean, let's say now all linux/windows/bsd servers start=20 > switching to IW 10, so that 99% of server traffic now arrives=20 > with a definitively increase burstines. What are the global=20 > implication of this switch coupled with today common practice=20 > of already tweaking the TCP limits when IW is more=20 > conservative? Say today those tweaks are used by 10% of=20 > traffic, so they do not interfere too much. What happens=20 > tomorrow when all traffic becomes more aggressive? >=20 > My intuition is that the increase the default IW to 10 would=20 > benefit in some cases where there is lot of bandwidth, but in=20 > some cases it would definitively hurt, especially when=20 > thinking about mobile terminals, which btw seems to me being=20 > very important in these days. >=20 > This is just my 2c. >=20 > Ciao > Marco >=20 > Il 12/11/2010 15:05, L.Wood@surrey.ac.uk ha scritto: > > The point is that implementations don't toe the lne on=20 > number of connections per host (6 connections per hostname?=20 > Not persistent flows, but actual TCP connections?), and we're=20 > not going to move the line to suit them. > > > > The same goes for initial window, I think. > > > > Lloyd Wood > > http://tinyurl.com/lloydwood-ccsr > > ________________________________________ > > From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On=20 > Behalf Of Marco=20 > > Mellia [mellia@tlc.polito.it] > > Sent: 12 November 2010 14:03 > > Cc: tcpm@ietf.org; tmrg-interest@icsi.berkeley.edu > > Subject: Re: [tcpm] Increasing the Initial Window - Notes > > > > well... > > check this then > > http://www.browserscope.org/ > > in the networking statistics... > > > > > > Il 12/11/2010 10:48, L.Wood@surrey.ac.uk ha scritto: > > =20 > >>> If today a brower opens 10 flows with a server using IW=3D1=20 > you gets=20 > >>> 10 > >>> =20 > >> packets equivalent IW > >> And the browser is ignoring RFC 2068 section 8.1: > >> Clients that use persistent connections SHOULD limit=20 > the number of > >> simultaneous connections that they maintain to a=20 > given server. A > >> single-user client SHOULD maintain AT MOST 2=20 > connections with any > >> server or proxy. > >> =20 > > -- > > > > Ciao, /\/\/\rco > > > > +-----------------------------------+ > > | Marco Mellia - Assistant Professor| > > | Skypeid: mgmellia | > > | Tel: +39-011-090-4173 | > > | Cel: +39-331-6714789 | /"\ .. . . . . . .=20 > . . . . . . > > | Politecnico di Torino | \ / . ASCII Ribbon=20 > Campaign . > > | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF=20 > in e-mail . > > | Torino - 10129 - Italy | / \ .- NO Word=20 > docs in e-mail. > > | http://www.telematica.polito.it | .. . . . . . .=20 > . . . . . . > > +-----------------------------------+ > > The box said "Requires Windows 95 or Better." So I installed Linux. > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > =20 >=20 > --=20 >=20 > Ciao, /\/\/\rco >=20 > +-----------------------------------+ > | Marco Mellia - Assistant Professor| > | Skypeid: mgmellia | > | Tel: +39-011-090-4173 | > | Cel: +39-331-6714789 | /"\ .. . . . . . . .=20 > . . . . . > | Politecnico di Torino | \ / . ASCII Ribbon=20 > Campaign . > | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF=20 > in e-mail . > | Torino - 10129 - Italy | / \ .- NO Word docs=20 > in e-mail. > | http://www.telematica.polito.it | .. . . . . . . .=20 > . . . . . > +-----------------------------------+ > The box said "Requires Windows 95 or Better." So I installed Linux. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From touch@isi.edu Fri Nov 12 12:06:45 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548393A69A5 for ; Fri, 12 Nov 2010 12:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq5d4QE-PjJI for ; Fri, 12 Nov 2010 12:06:44 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A4AE83A697A for ; Fri, 12 Nov 2010 12:06:44 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oACK5qFB016501 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 12 Nov 2010 12:05:52 -0800 (PST) Message-ID: <4CDD9E20.8030308@isi.edu> Date: Fri, 12 Nov 2010 12:05:52 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <5FDC413D5FA246468C200652D63E627A0B65CA86@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0B65CA86@LDCMVEXC1-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Murari Sridharan , tcpm , Andrew McGregor Subject: Re: [tcpm] dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 20:06:45 -0000 On 11/11/2010 3:51 AM, Scheffenegger, Richard wrote: ... > Reading the TSVAREA material, it was also pointed out (storage teaser - > NFSv4, iSCSI) that TCPM may need to look closer at datacenter > environments rather soon. Tuning TCP for private networks (i.e., not using the Internet, or competing with Internet flows) seems out of scope for TCPM. It might not even be relevant elsewhere in the IETF, except as an issue of common interest. Protocols running over private networks don't need to adhere to standards. Joe From mellia@tlc.polito.it Sat Nov 13 05:36:41 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7963A6A46 for ; Sat, 13 Nov 2010 05:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGcKd1f96uwf for ; Sat, 13 Nov 2010 05:36:40 -0800 (PST) Received: from mail.tlc.polito.it (baobab.polito.it [130.192.9.198]) by core3.amsl.com (Postfix) with SMTP id 131043A6A43 for ; Sat, 13 Nov 2010 05:36:39 -0800 (PST) Received: (qmail 4732 invoked by uid 88); 13 Nov 2010 13:37:06 -0000 Received: from dynamic-adsl-94-34-217-180.clienti.tiscali.it (HELO MacMGM.local) (94.34.217.180) (smtp-auth username mellia@tlc.polito.it, mechanism cram-md5) by mail.tlc.polito.it (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Sat, 13 Nov 2010 14:37:06 +0100 Message-ID: <4CDE947F.6070600@tlc.polito.it> Date: Sat, 13 Nov 2010 14:37:03 +0100 From: Marco Mellia User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; it; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> , <4CDD493B.6000201@tlc.polito.it> <4CDD59BE.60704@tlc.polito.it> <5FDC413D5FA246468C200652D63E627A0B65D203@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0B65D203@LDCMVEXC1-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TLC-MailScanner-Information: Please contact the ISP for more information X-TLC-MailScanner: Found to be clean X-TLC-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.388, required 4, autolearn=not spam, AWL 0.07, BAYES_00 -2.60, FORGED_RCVD_HELO 0.14, RCVD_IN_PBL 0.00) X-TLC-MailScanner-From: mellia@tlc.polito.it Cc: tmrg-interest@icsi.berkeley.edu, tcpm@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 13:36:41 -0000 > It appears to me, that we are now discussing if the undoubtedly > increased packet loss rate (~ +24%) is more troublesome (to the network) > than the faster delivery of objects (to the clients) (~ -13%). And, as > mentioned above, will the increased aggressiveness of flows (because > fast recovery may be leading to more load early on) hurt the network > beyond that... Ciao Richard, My concern related to mobile device is not about them, but about the network. Which is pretty much what you sat above... Today, 3G networks are already overloaded, with the bottleneck being the downlink capacity at the baystation. If servers move from IW3 to IW10, that would definitively impact that bottleneck. The problem is not what happens on gigabit per second, uncongested paths. The problem is what happens on low capacity, already congested paths. And mobile networks seems to me to be a good example of the latter. Ciao Marco From mellia@tlc.polito.it Sat Nov 13 05:50:47 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7DE03A6B94 for ; Sat, 13 Nov 2010 05:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOg6lES-e+qI for ; Sat, 13 Nov 2010 05:50:46 -0800 (PST) Received: from mail.tlc.polito.it (baobab.polito.it [130.192.9.198]) by core3.amsl.com (Postfix) with SMTP id 153083A6B98 for ; Sat, 13 Nov 2010 05:50:45 -0800 (PST) Received: (qmail 5367 invoked by uid 88); 13 Nov 2010 13:51:16 -0000 Received: from dynamic-adsl-94-34-217-180.clienti.tiscali.it (HELO MacMGM.local) (94.34.217.180) (smtp-auth username mellia@tlc.polito.it, mechanism cram-md5) by mail.tlc.polito.it (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Sat, 13 Nov 2010 14:51:16 +0100 Message-ID: <4CDE97D2.7010005@tlc.polito.it> Date: Sat, 13 Nov 2010 14:51:14 +0100 From: Marco Mellia User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; it; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Yuchung Cheng References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> <4CDD493B.6000201@tlc.polito.it> <4CDD59BE.60704@tlc.polito.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TLC-MailScanner-Information: Please contact the ISP for more information X-TLC-MailScanner: Found to be clean X-TLC-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.389, required 4, autolearn=not spam, AWL 0.07, BAYES_00 -2.60, FORGED_RCVD_HELO 0.14, RCVD_IN_PBL 0.00) X-TLC-MailScanner-From: mellia@tlc.polito.it Cc: "tcpm@ietf.org Extensions" , L.Wood@surrey.ac.uk Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 13:50:47 -0000 > Browsers open lots of connections these days and we always try to cope > that in all our experiments. > > live: > To get the best possible apple-to-apple comparison when comparing > IW10/IW3 performance on our live frontends, we split the client IPs > into two (same size) pools to serve IW10 and IW3 simultaneously. To > our own surprise, mobile hosts are among the big winners (even their > browsers still open >2 streams per domain). See slide 19 in our IETF > 77 presentation Not surprised at all... since mobile terminal suffer higher RTT, it is quite straight forward to see larger benefit there. The point is that you cannot see the impairment of other traffic... It it easy to gain 20% when 20% of flows goes IW10. But what about the other 80% flows that were still using IW3? Was there any impairment for them? Easy answer: if there is no congestion and there is enough buffer space at the bottleneck link, then no impairment is expected. But if there is already some congestion, and then the bottleneck queue is already overloaded, then I expect lot of impairment (and unfairness). And what would be the gain if 100% of flows goes IW10? Are the benefit larger than impairments? Then go for IW10, or even IW16. Those are questions that your data cannot answer I would say. Has someone run at least some simulations to see what can happen on a congested path? Ciao Marco From touch@isi.edu Sat Nov 13 06:49:09 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719BB3A6BAB for ; Sat, 13 Nov 2010 06:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNUyhRjKU848 for ; Sat, 13 Nov 2010 06:49:08 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 95F133A6BA9 for ; Sat, 13 Nov 2010 06:49:08 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oADEmvWb016278 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 13 Nov 2010 06:49:07 -0800 (PST) Message-ID: <4CDEA55A.3050304@isi.edu> Date: Sat, 13 Nov 2010 06:48:58 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Andrew McGregor References: <5FDC413D5FA246468C200652D63E627A0B65CA86@LDCMVEXC1-PRD.hq.netapp.com> <4CDD9E20.8030308@isi.edu> <8A78D89F-F754-4A7B-A2EC-7B871B351E5A@gmail.com> In-Reply-To: <8A78D89F-F754-4A7B-A2EC-7B871B351E5A@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm , Murari Sridharan Subject: Re: [tcpm] dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 14:49:10 -0000 On 11/13/2010 1:59 AM, Andrew McGregor wrote: > That's true, but if it can be made to happen automatically that would, I suspect, be in scope. Automatic isn't the issue. Impact with the rest of the Internet is. A general autotuning TCP would be one thing, but even that wouldn't be a 'minor' mod to TCP; it's a generic issue common to all reactive transports (DCCP, SCTP, etc.) The two issues are: - is this a TCPM issue? - is this an IETF issue at all? I have questions on both counts. Keep in mind, e.g., that there's no "IP for SCSI" (there was a time when that was assumed as required). Joe > On 13/11/2010, at 4:05 AM, Joe Touch wrote: > >> >> >> On 11/11/2010 3:51 AM, Scheffenegger, Richard wrote: >> ... >>> Reading the TSVAREA material, it was also pointed out (storage teaser - >>> NFSv4, iSCSI) that TCPM may need to look closer at datacenter >>> environments rather soon. >> >> Tuning TCP for private networks (i.e., not using the Internet, or competing with Internet flows) seems out of scope for TCPM. >> >> It might not even be relevant elsewhere in the IETF, except as an issue of common interest. Protocols running over private networks don't need to adhere to standards. >> >> Joe > From ananth@cisco.com Sat Nov 13 08:45:34 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544E63A6BC7 for ; Sat, 13 Nov 2010 08:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+h+aDglszxB for ; Sat, 13 Nov 2010 08:45:27 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 580ED3A6B7F for ; Sat, 13 Nov 2010 08:45:27 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN1P3kyrRN+K/2dsb2JhbACiVXGiQ5puhUoEhFqJD4gF X-IronPort-AV: E=Sophos;i="4.59,191,1288569600"; d="scan'208";a="285569556" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2010 16:46:03 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id oADGk3aC028652; Sat, 13 Nov 2010 16:46:03 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 13 Nov 2010 08:46:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Nov 2010 08:46:01 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580B2CD428@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4CDD9E20.8030308@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] dctcp Thread-Index: AcuCpTmpCgCrEwNrRv+yJ0jXNLbPigABOkEw References: <5FDC413D5FA246468C200652D63E627A0B65CA86@LDCMVEXC1-PRD.hq.netapp.com> <4CDD9E20.8030308@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Scheffenegger, Richard" X-OriginalArrivalTime: 13 Nov 2010 16:46:02.0819 (UTC) FILETIME=[42023930:01CB8352] Cc: Murari Sridharan , tcpm , Andrew McGregor Subject: Re: [tcpm] dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 16:45:34 -0000 Well, My thoughts here are :- - If someone is using a protocol defined by IETF, then it is desirable to abide by the standards, irrespective of the type of network.=20 - interoperability across different devices (may be coming from different vendors), using the same protocol, is one of the reason you need standards!=20 - From an implementation perspective you don't want "private TCP" and "public TCP" in the same stack since the same stack needs to cater to TCP connections from *both* private and public networks! - The problems and the solutions which are posed by the data center environments may not be unique. The question to ask is : "what is the problem and whether the problems and solutions would have a generic applicability. =20 - Also how do you draw a boundary as to a what is private network and what isn't ? Why is data center environment considered a "private network" ? IMO, it is an issue that can be well addressed (if there is a need) by the IETF, if changes are being planned with TCP protocol, yes TCPM is the right place for such efforts. $0.02, -Anantha -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch Sent: Friday, November 12, 2010 12:06 PM To: Scheffenegger, Richard Cc: Murari Sridharan; tcpm; Andrew McGregor Subject: Re: [tcpm] dctcp On 11/11/2010 3:51 AM, Scheffenegger, Richard wrote: ... > Reading the TSVAREA material, it was also pointed out (storage teaser - > NFSv4, iSCSI) that TCPM may need to look closer at datacenter > environments rather soon. Tuning TCP for private networks (i.e., not using the Internet, or=20 competing with Internet flows) seems out of scope for TCPM. It might not even be relevant elsewhere in the IETF, except as an issue=20 of common interest. Protocols running over private networks don't need=20 to adhere to standards. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Sat Nov 13 10:13:24 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932C23A6C10 for ; Sat, 13 Nov 2010 10:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.53 X-Spam-Level: X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuN1nggjFVal for ; Sat, 13 Nov 2010 10:13:17 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 679BE3A6C07 for ; Sat, 13 Nov 2010 10:13:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,191,1288594800"; d="scan'208";a="219525246" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 13 Nov 2010 10:13:50 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oADIDnXg010819; Sat, 13 Nov 2010 10:13:50 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 13 Nov 2010 18:13:49 +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: Sat, 13 Nov 2010 18:13:48 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B65D288@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4CDE97D2.7010005@tlc.polito.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Increasing the Initial Window - Notes Thread-Index: AcuDOd6HpH373SHJQcmoIqQg+j7sBAAIwXqw References: <20101110152857.GA5094@hell><20101111012453.GB2691@hell><29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no><824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no><4CDBCA4E.8000705@tlc.polito.it><9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no><4CDD493B.6000201@tlc.polito.it><4CDD59BE.60704@tlc.polito.it> <4CDE97D2.7010005@tlc.polito.it> From: "Scheffenegger, Richard" To: "Marco Mellia" , "Yuchung Cheng" X-OriginalArrivalTime: 13 Nov 2010 18:13:49.0770 (UTC) FILETIME=[855B2AA0:01CB835E] Cc: tcpm@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 18:13:24 -0000 Marco, Isn't then what you are really asking for AQM at the basestation downlink path? Obviously, running FIFO queues there is no the brightest of ideas. With any decent AQM, the impact to any one flow should be proportional to it's consumed bandwidth. In the degenerate case of IW3 and IW10 initial transmission burst and an overloaded downlink, shouldn't the basestation queue drop 10/3 as many packets belonging to IW10 flows, than packets belonging to IW3 flows, so that each flow is allowed an approximate fair share of downlink capacity? And it's been a long time that it's known that "any" AQM scheme will be beneficial over FIFO tail-drop queuing... Even then IW10 will be beneficial, as it is easier, and more packet-conserving, for IW10 flow TCP to recovery that loss in a timely and work-conserving fashinon... IIRC, the recent data did contain data points showing the relative effects of IW3 vs. IW10 vs. bulk transfers over a "shared" bottleneck link - although only a very limited number of clients being busy at the same time (4-6 flows in total). Richard Scheffenegger =20 > -----Original Message----- > From: Marco Mellia [mailto:mellia@tlc.polito.it]=20 > Sent: Samstag, 13. November 2010 14:51 > To: Yuchung Cheng > Cc: tcpm@ietf.org Extensions; L.Wood@surrey.ac.uk > Subject: Re: [tcpm] Increasing the Initial Window - Notes >=20 >=20 >=20 > > Browsers open lots of connections these days and we always=20 > try to cope=20 > > that in all our experiments. > > > > live: > > To get the best possible apple-to-apple comparison when comparing > > IW10/IW3 performance on our live frontends, we split the client IPs=20 > > into two (same size) pools to serve IW10 and IW3 simultaneously. To=20 > > our own surprise, mobile hosts are among the big winners=20 > (even their=20 > > browsers still open >2 streams per domain). See slide 19=20 > in our IETF > > 77 presentation >=20 > Not surprised at all... since mobile terminal suffer higher=20 > RTT, it is quite straight forward to see larger benefit there. > The point is that you cannot see the impairment of other traffic... > It it easy to gain 20% when 20% of flows goes IW10. >=20 > But what about the other 80% flows that were still using IW3?=20 > Was there any impairment for them? > Easy answer: if there is no congestion and there is enough=20 > buffer space at the bottleneck link, then no impairment is expected. > But if there is already some congestion, and then the=20 > bottleneck queue is already overloaded, then I expect lot of=20 > impairment (and unfairness). >=20 > And what would be the gain if 100% of flows goes IW10? >=20 > Are the benefit larger than impairments? Then go for IW10, or=20 > even IW16. >=20 > Those are questions that your data cannot answer I would say. > Has someone run at least some simulations to see what can=20 > happen on a congested path? >=20 > Ciao > Marco > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From perfgeek@mac.com Sat Nov 13 11:10:22 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727103A6C23 for ; Sat, 13 Nov 2010 11:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBTgPOmOWp27 for ; Sat, 13 Nov 2010 11:10:19 -0800 (PST) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by core3.amsl.com (Postfix) with ESMTP id 256763A6949 for ; Sat, 13 Nov 2010 11:10:13 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0LBU000XK7Y01O40@asmtp017.mac.com> for tcpm@ietf.org; Sat, 13 Nov 2010 11:10:49 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1011130136 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-13_07:2010-11-12, 2010-11-13, 1970-01-01 signatures=0 Message-id: <10936993-8969-4F64-87BB-F5473CAB95B2@mac.com> From: rick jones To: Marco Mellia In-reply-to: <4CDE947F.6070600@tlc.polito.it> Date: Sat, 13 Nov 2010 11:10:48 -0800 References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> <4CDD493B.6000201@tlc.polito.it> <4CDD59BE.60704@tlc.polito.it> <5FDC413D5FA246468C200652D63E627A0B65D203@LDCMVEXC1-PRD.hq.netapp.com> <4CDE947F.6070600@tlc.polito.it> X-Mailer: Apple Mail (2.936) Cc: tmrg-interest@icsi.berkeley.edu, L.Wood@surrey.ac.uk, tcpm@ietf.org Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 19:10:22 -0000 On Nov 13, 2010, at 5:37 AM, Marco Mellia wrote: > Today, 3G networks are already overloaded, with the bottleneck being > the downlink capacity at the baystation. Is there any way to know how much of that overload is what one might call "do overs?" Where a "do over" is not a TCP retransmission, but an application-level resending of data because the consumer got impatient and re-issued the request. rick jones From lachlan.andrew@gmail.com Fri Nov 12 13:14:24 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FBF73A6A82 for ; Fri, 12 Nov 2010 13:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oJc-ck4ZIWA for ; Fri, 12 Nov 2010 13:14:18 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3FEA03A6978 for ; Fri, 12 Nov 2010 13:14:18 -0800 (PST) Received: by iwn40 with SMTP id 40so4142208iwn.31 for ; Fri, 12 Nov 2010 13:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=umHN18PUcSOmIC7zEEVOptZ0GWAEbiVN0n2oXeii6ZI=; b=MYmsmTCsZk1t6kKuEcV5tPSyZEVobzwrp75GOTfFC1zoTF/SeHasOEJCeQnaxXVOYR i59I8uz+VNQMjX3R7jZsFmnwV2diCOyYP8DGgcCXgpCTHKLVYvC8rto2Dl/OZo1/AODE WwByJ0dqx/a4AT2loDaOfNfZCEuHVrVj/JVpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YrxxVOCbvucc0vr94IKu4PhpE+mLmvmmNBLFh05OS1Pn33zcauOn1b5CnE89mrqVI+ zmflhZ8BRtssoFv98GWZcbkbjbnBBCU0WQAIPCUbT3rgOX39k5TdWFH0DdKzTR5g3SWq mJTQD7hAiGQeRzbwoPTYNp+fcvQ9kGgQWA4go= MIME-Version: 1.0 Received: by 10.231.37.6 with SMTP id v6mr2591776ibd.46.1289596490746; Fri, 12 Nov 2010 13:14:50 -0800 (PST) Received: by 10.231.140.32 with HTTP; Fri, 12 Nov 2010 13:14:50 -0800 (PST) In-Reply-To: <4CDD72F8.5040409@gmx.at> References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <4CDD72F8.5040409@gmx.at> Date: Sat, 13 Nov 2010 08:14:50 +1100 Message-ID: From: Lachlan Andrew To: Stefan Hirschmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 14 Nov 2010 10:20:01 -0800 Cc: tcpm , tmrg , Michael Welzl Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 21:14:24 -0000 On 13 November 2010 04:01, Stefan Hirschmann wrote: > > To be honest. I don't like the idea that an application behaves > different depending on the used TCP variant. For me, TCP is kernel stuff > and an application should use it without thinking. Applications very often check the version of OS or CPU they are running on, and behave differently accordingly. Doing this for TCP wouldn't be setting a precedent. Of course, we would need a very clear benefit to justify such an increase in complexity, and it isn't clear that a factor of 3 in the IW is enough justification. $0.02 Lachlan --=20 Lachlan Andrew=A0 Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From andrewmcgr@gmail.com Sat Nov 13 02:04:08 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7DC28C0CE for ; Sat, 13 Nov 2010 02:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIjnKeZe8FSI for ; Sat, 13 Nov 2010 02:04:07 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 9FB0028B797 for ; Sat, 13 Nov 2010 02:04:07 -0800 (PST) Received: by iwn40 with SMTP id 40so4762996iwn.31 for ; Sat, 13 Nov 2010 02:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=sbOHOdAyalf4fnvZu33zIR/Atk5gG1WPyI8JtaTHHm0=; b=aM3QEVNjNbNpg+tEF/Fp5nd2ZS7lhf01G14WpHkRajslC/LvBrv8jSvv6OyE3vuenv gjGbJpwanyKytVGk5ILeQ/k1Mwr0oubh1+lq6bKSAB5hRYQuZ0s2t+6DP+63OGA1Zffg X9CWDUiAnzcZv6C54ByYhI+vLi5mlWSar82HY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=mryi8hP5Y4YX/lZQVBrTUUd8BGB5QldXOGFCaomMOswxOr4UVfD+BZFsvgfu96Cc9R 6XV6X50IjVVf2yI/p+a3zBL4idxdcJ+O8BRFpHk+oS3FaAzH9GbpKhwSTVcC9fjJvWsk bBAeHBpffCL7YIPYdQ7qgxjcKY+XeydFQrtDI= Received: by 10.231.37.201 with SMTP id y9mr2888392ibd.76.1289642681846; Sat, 13 Nov 2010 02:04:41 -0800 (PST) Received: from n11648178139.netvigator.com (n11648178139.netvigator.com [116.48.178.139]) by mx.google.com with ESMTPS id d21sm4689312ibg.9.2010.11.13.02.04.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 13 Nov 2010 02:04:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Andrew McGregor In-Reply-To: <4CDD9E20.8030308@isi.edu> Date: Sat, 13 Nov 2010 17:59:28 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8A78D89F-F754-4A7B-A2EC-7B871B351E5A@gmail.com> References: <5FDC413D5FA246468C200652D63E627A0B65CA86@LDCMVEXC1-PRD.hq.netapp.com> <4CDD9E20.8030308@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 14 Nov 2010 10:20:02 -0800 Cc: tcpm , Murari Sridharan Subject: Re: [tcpm] dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 10:04:08 -0000 That's true, but if it can be made to happen automatically that would, I = suspect, be in scope. Andrew On 13/11/2010, at 4:05 AM, Joe Touch wrote: >=20 >=20 > On 11/11/2010 3:51 AM, Scheffenegger, Richard wrote: > ... >> Reading the TSVAREA material, it was also pointed out (storage teaser = - >> NFSv4, iSCSI) that TCPM may need to look closer at datacenter >> environments rather soon. >=20 > Tuning TCP for private networks (i.e., not using the Internet, or = competing with Internet flows) seems out of scope for TCPM. >=20 > It might not even be relevant elsewhere in the IETF, except as an = issue of common interest. Protocols running over private networks don't = need to adhere to standards. >=20 > Joe From hkchu@google.com Mon Nov 15 00:02:53 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015A63A6C68 for ; Mon, 15 Nov 2010 00:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.6 X-Spam-Level: X-Spam-Status: No, score=-105.6 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mnobljj0MEmD for ; Mon, 15 Nov 2010 00:02:46 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1700E3A6B7B for ; Mon, 15 Nov 2010 00:02:45 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id oAF83Q00030513 for ; Mon, 15 Nov 2010 00:03:26 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289808206; bh=UUITJv5bPiwlmwWJQGMo9sxrVz0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=xkrTI04K1KDpLks9prDBkwWSu0Wa5HJn1fg45o0eLr4+lqttpIWN1mCVGRj3bDNwP 8RfsCsBfbeLspnC0KLRKQ== Received: from ywi6 (ywi6.prod.google.com [10.192.9.6]) by wpaz24.hot.corp.google.com with ESMTP id oAF83Oh7012948 for ; Mon, 15 Nov 2010 00:03:25 -0800 Received: by ywi6 with SMTP id 6so1122478ywi.14 for ; Mon, 15 Nov 2010 00:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Wgvzx+B5LLy+tyoN0N+LKpx2pntGtNdwMikPx4YtT/Q=; b=yHTeWG3WlOCg8pOBuowXoGIH9Gd1CIIjg30L6J8w4y74SCzJ7ErPAVHv54gZUIxw+A DHyICLoC7ZgRT8imD+sw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pTdTvyneAcof4bouIlZd8YG91cIUPXnQ9510r/TPI8r2K8MYs8fEnjdwmpEqkIcHeR pHQalLeWLqwy4Ed1zkOA== MIME-Version: 1.0 Received: by 10.150.91.13 with SMTP id o13mr9006212ybb.6.1289808204530; Mon, 15 Nov 2010 00:03:24 -0800 (PST) Received: by 10.150.145.4 with HTTP; Mon, 15 Nov 2010 00:03:24 -0800 (PST) In-Reply-To: <4CDE97D2.7010005@tlc.polito.it> References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> <4CDD493B.6000201@tlc.polito.it> <4CDD59BE.60704@tlc.polito.it> <4CDE97D2.7010005@tlc.polito.it> Date: Mon, 15 Nov 2010 00:03:24 -0800 Message-ID: From: Jerry Chu To: Marco Mellia Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" , L.Wood@surrey.ac.uk Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 08:02:53 -0000 On Sat, Nov 13, 2010 at 5:51 AM, Marco Mellia wrote: > > >> Browsers open lots of connections these days and we always try to cope >> that in all our experiments. >> >> live: >> To get the best possible apple-to-apple comparison when comparing IW10/I= W3 >> performance on our live frontends, we split the client IPs into two (sam= e >> size) pools to serve IW10 and IW3 simultaneously. To our own surprise, >> mobile hosts are among the big winners (even their browsers still open >= 2 >> streams per domain). =A0See slide 19 in our IETF 77 presentation > > Not surprised at all... since mobile terminal suffer higher RTT, it is qu= ite > straight forward to see larger benefit there. > The point is that you cannot see the impairment of other traffic... > It it easy to gain 20% when 20% of flows goes IW10. > > But what about the other 80% flows that were still using IW3? Was there a= ny > impairment for them? > Easy answer: if there is no congestion and there is enough buffer space a= t > the bottleneck link, then no impairment is expected. > But if there is already some congestion, and then the bottleneck queue is > already overloaded, then I expect =A0lot of impairment (and unfairness). > > And what would be the gain if 100% of flows goes IW10? > > Are the benefit larger than impairments? Then go for IW10, or even IW16. > > Those are questions that your data cannot answer I would say. > Has someone run at least some simulations to see what can happen on a > congested path? Have you at least checked the title of our most recent presentation in Beijing to know it might contain some relevant data for your question? Best, Jerry > > Ciao > Marco > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From bruno.mongazon-cazavet@alcatel-lucent.com Mon Nov 15 02:27:07 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7EF3A6B6B for ; Mon, 15 Nov 2010 02:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxLZkzeP6gZ3 for ; Mon, 15 Nov 2010 02:27:00 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 6DEF43A6AB0 for ; Mon, 15 Nov 2010 02:26:58 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAFAOUBM029720 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 15 Nov 2010 11:27:35 +0100 Received: from [172.27.205.223] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 15 Nov 2010 11:27:24 +0100 Message-ID: <4CE10B0C.1040705@alcatel-lucent.com> Date: Mon, 15 Nov 2010 11:27:24 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <4CDA4FA9.4050006@alcatel-lucent.com> <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 10:27:08 -0000 Dear Richard; Thank you for looking at TCP-Rehash. Please see my comments inline. Regards, Bruno Mongazon Le 10/11/2010 13:51, Scheffenegger, Richard a écrit : > Hi Bruno, > > After a casual look, it appears to me that a lightweight implementation of MP-TCP can have the same benefits, but does not require the opaque exchange of IPv4 addresses... Yes an idea would be to have TCP-Rehash == lightweigth MPTCP There are a few design diffferences that need to be looked at. > Your use case - that the old L3 address is already no longer available at the time of the rehash - may need to be looked at in MPTCP though (iirc, they do a graceful session setup first (thus can work with NAT mostly), and move data transport only after the successful establishment of the 2nd L3 connectivity, and only then tear down the original L3 connectivity). Right but... there is no real constraint on old address availability, thus the old address might still be available. A key difference between TCP-Rehash and MPTCP is the session setup. With TCP-Rehash there is no setup, it is a straight move. If it fails, the connection is broken, this would happen anyway if L3 address changes and there is no "move" mechanism. Doing so is just opportunistic but deterministic. MPTCP is more complex since a new connection is setup before the old connection is being "moved". From design perspective, would it be that complex for MPTCP to handle rehash design ? NAT is a different story (orthogonal i would say) and issue. > Perhaps the effort would be better placed on making sure that such light-weight MPTCP implementations remain feasible, instead of defining an alternate method that is addressing only this one aspect, but incompatible with MPTCP otherwise? To be honest i have both TCP-Rehash and MPTCP linux kernel source code... my intention is not to define an alternate method ! Rather i posted the TCP-Rehash draft with the intention to provide some additional work on the topic. Convergence and collaboration is of course to be considered. I think my work, although it was not disclosed, started sometimes ago, almost at early MPTCP. Please let me know, if from the design point of view, the WG would consider the opportunity to have a lightweight MPTCP that would look like TCP-Rehash. > Richard Scheffenegger > > > >> -----Original Message----- >> From: Bruno Mongazon-Cazavet >> [mailto:bruno.mongazon-cazavet@alcatel-lucent.com] >> Sent: Mittwoch, 10. November 2010 08:54 >> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] WG status update >> >> >> Le 10/11/2010 01:54, Eddy, Wesley M. (GRC-MS00)[ASRC >> AEROSPACE CORP] a écrit : >>> Hi, for those of you who aren't in Beijing, here's a >> snapshot of the TCPM WG status. >> >> Hi, >> >> I have posted a 00 draft that might be of interest for your working >> group. I don't see any mention in your snapshot. >> http://www.ietf.org/id/draft-mongazon-tcpm-tcp-rehash-00.txt >> >> I will not be in Beijing to present it but i hope to be in >> Prague to do so. >> I would appreciate the working group can look at it and let >> me know if >> it could be of any interest and how i shall pursue my contribution. >> >> I have done a Linux kernel implementation of the draft and be >> ready for >> a demo in Prague. >> >> Best Regards, >> Bruno. >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From lars.eggert@nokia.com Mon Nov 15 04:54:03 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984ED3A6B72 for ; Mon, 15 Nov 2010 04:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWcGJcPfksR4 for ; Mon, 15 Nov 2010 04:54:02 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 88CBB3A6935 for ; Mon, 15 Nov 2010 04:54:02 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oAFCsagp025244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Nov 2010 14:54:36 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-11-133341024; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4CE10B0C.1040705@alcatel-lucent.com> Date: Mon, 15 Nov 2010 14:54:29 +0200 Message-Id: <9EAEB61A-6E43-4EB2-B89F-32A3957814AB@nokia.com> References: <4CDA4FA9.4050006@alcatel-lucent.com> <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com> <4CE10B0C.1040705@alcatel-lucent.com> To: Bruno Mongazon-Cazavet X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 15 Nov 2010 14:54:30 +0200 (EET) X-Nokia-AV: Clean Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 12:54:03 -0000 --Apple-Mail-11-133341024 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-11-15, at 12:27, Bruno Mongazon-Cazavet wrote: > Please let me know, if from the design point of view, the WG would = consider the opportunity to have a lightweight MPTCP that would look = like TCP-Rehash. given that the IETF is already working on MPTCP, it's a bit difficult to = see why we should work on another extension to TCP that does some of = what MPTCP does, but not all of it, and in a way that is not = interoperable with it. It's not like MPTCP will significantly increase the footprint of the = network stack. Lars=20= --Apple-Mail-11-133341024 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag 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 aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTExNTEyNTQzMFowIwYJKoZIhvcNAQkE MRYEFK+mAGjkfxQL1muSL6wO0S//9HyJMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AL/ay4uupH0CxRuR5/2FVYUqCcaTvaMWF7mXmojYUvnBTObHdzXs8GIrV3Ucl/+2fHOyYLq1koZ5 keYYxX9TOKHlhIoMH8CJM5y4jdXZXEHt2qhn+q02nmNwUsKZCJo4yOUejr1l66m45P2VBZWd4P8j Ob8W/mfipLRMOpVszf+2BpSierSgdBwq6BrA8uTSk+gz3Wry6HrrrxENVoS3VDf7nCcY///swHBA g5LLGQJtiATZf8Vla+DQ0m2mvjrRX0BSoXb2XRlzpP53K1tOOq52j2gokVJvEDS/s8Yk6YIttU2n 8aP9RYgIPACV2hV4GnGHcR0offJOBN5iOj67qyUAAAAAAAA= --Apple-Mail-11-133341024-- From bruno.mongazon-cazavet@alcatel-lucent.com Mon Nov 15 06:03:52 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17EEC3A6A70 for ; Mon, 15 Nov 2010 06:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-YFMQIUU6vl for ; Mon, 15 Nov 2010 06:03:50 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 536F63A6993 for ; Mon, 15 Nov 2010 06:03:49 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAFE1slf010756 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 15 Nov 2010 15:04:28 +0100 Received: from [172.27.205.223] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 15 Nov 2010 15:03:41 +0100 Message-ID: <4CE13DBD.5010706@alcatel-lucent.com> Date: Mon, 15 Nov 2010 15:03:41 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Lars Eggert References: <4CDA4FA9.4050006@alcatel-lucent.com> <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com> <4CE10B0C.1040705@alcatel-lucent.com> <9EAEB61A-6E43-4EB2-B89F-32A3957814AB@nokia.com> In-Reply-To: <9EAEB61A-6E43-4EB2-B89F-32A3957814AB@nokia.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 14:03:52 -0000 Le 15/11/2010 13:54, Lars Eggert a écrit : > Hi, > > On 2010-11-15, at 12:27, Bruno Mongazon-Cazavet wrote: >> Please let me know, if from the design point of view, the WG would consider the opportunity to have a lightweight MPTCP that would look like TCP-Rehash. > given that the IETF is already working on MPTCP, it's a bit difficult to see why we should work on another extension to TCP that does some of what MPTCP does, but not all of it, and in a way that is not interoperable with it. > > It's not like MPTCP will significantly increase the footprint of the network stack. Sorry but yes it does. The numbers are currently the following: MP-TCP patch on 2.6.28 => 16270 Line Of Code TCP-Rehash on 2.6.34 => 2357 Line Of Code Percentages are currently the following (net/ipv4 sub-directory C files only, not counting the core nor header files): MP-TCP on 2.6.28 => (16270 / 82925) * 100 ~= 20 % TCP-Rehash on 2.6.34 => (2357 / 80977) * 100 ~= 3% Giving the fact that the MP-TCP code i use does not provide yet "coupled congestion control" there are a few chance the trend can change. So numbers do actually tell something logical: TCP-Rehash is designed with minimal functionality, MP-TCP provides more functionality. I just wonder if MP-TCP can benefit from a behavior that would only cost a little (if ever, need to be checked) and provide a minimal behavior that can sometimes be sufficient. I am free to discuss this and other's opinions are welcome. Bruno. > Lars From lars.eggert@nokia.com Mon Nov 15 07:18:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED8928C120 for ; Mon, 15 Nov 2010 07:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxnC0mj87S+A for ; Mon, 15 Nov 2010 07:18:47 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 7CB7028C13F for ; Mon, 15 Nov 2010 07:18:47 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oAFFJOom014668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Nov 2010 17:19:24 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-3-142033059; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4CE13DBD.5010706@alcatel-lucent.com> Date: Mon, 15 Nov 2010 17:19:21 +0200 Message-Id: <1642C18A-EDF4-4B5F-920C-05F66F3C0F15@nokia.com> References: <4CDA4FA9.4050006@alcatel-lucent.com> <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com> <4CE10B0C.1040705@alcatel-lucent.com> <9EAEB61A-6E43-4EB2-B89F-32A3957814AB@nokia.com> <4CE13DBD.5010706@alcatel-lucent.com> To: Bruno Mongazon-Cazavet X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 15 Nov 2010 17:19:22 +0200 (EET) X-Nokia-AV: Clean Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 15:18:48 -0000 --Apple-Mail-3-142033059 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-11-15, at 16:03, Bruno Mongazon-Cazavet wrote: > MP-TCP on 2.6.28 =3D> (16270 / 82925) * 100 ~=3D 20 % > TCP-Rehash on 2.6.34 =3D> (2357 / 80977) * 100 ~=3D 3% I don't believe that the MPTCP developers at the moment have made an = attempt at minimizing their diff, so those numbers aren't very = conclusive. I also don't think that the binary size of the final kernel = will be much affected. But that line of argumentation isn't very = fruitful to continue anyway.=20 Does TCP-Rehash provide interesting functionality? Sure. Does it provide = anything that MPTCP doesn't provide? No. If we weren't already doing = MPTCP, then TCP-Rehash might have been interesting. But since we are = doing MPTCP, I simply don't see the point of specifying a subset of it = in a way that is incompatible. Lars= --Apple-Mail-3-142033059 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag 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 aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTExNTE1MTkyMlowIwYJKoZIhvcNAQkE MRYEFME/NvPY/1YdIsDK6JTnkQGJcLOAMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AHaPkj+/KR+RQJaTdL0CZQLZ3t1Z+H10sXeqU+CB7ohEYBonTW0Pxh5ls0oS5Pt3NlLyQTRoYDOr SABSgVU0ZrmN/fcMU0vO5UHSHHPdCctf65gbgGJBIIGiMlO1dUsREkD/7RkK0lm3eVJpj3reUx7I fRMBruBvxhG+FUpAYW3//FcU242b+vM72Ay3TFGjutl8wPRSf+p+9S7uhyTqfX+6Dapx9xcyuZYo nCVPFWzksVkFNMp7gXXajB2LTckN0GBdnQGXEbO0MDX5zJXQyFZxxIOIPVhB0C1k/+8QwHuyW0Em 6bANZblOv5oPxdSV7wqIIOaIyLSHLp8JPgHssRYAAAAAAAA= --Apple-Mail-3-142033059-- From L.Wood@surrey.ac.uk Mon Nov 15 07:39:06 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AEE3A6CC0 for ; Mon, 15 Nov 2010 07:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgHgZA-V2gGK for ; Mon, 15 Nov 2010 07:39:05 -0800 (PST) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with ESMTP id 1275D3A6CB9 for ; Mon, 15 Nov 2010 07:39:04 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-6.tower-78.messagelabs.com!1289835585!19625175!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.39] Received: (qmail 21209 invoked from network); 15 Nov 2010 15:39:45 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-6.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 15 Nov 2010 15:39:45 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Mon, 15 Nov 2010 15:39:45 +0000 From: To: , Date: Mon, 15 Nov 2010 15:39:43 +0000 Thread-Topic: [tcpm] WG status update Thread-Index: AcuE2IRWbG8LLNh3TfiFSVpJ65409AAARsfQ Message-ID: References: <4CDA4FA9.4050006@alcatel-lucent.com> <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com> <4CE10B0C.1040705@alcatel-lucent.com> <9EAEB61A-6E43-4EB2-B89F-32A3957814AB@nokia.com> <4CE13DBD.5010706@alcatel-lucent.com> <1642C18A-EDF4-4B5F-920C-05F66F3C0F15@nokia.com> In-Reply-To: <1642C18A-EDF4-4B5F-920C-05F66F3C0F15@nokia.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 15:39:06 -0000 > I don't believe that the MPTCP developers at the moment have made an atte= mpt at minimizing their diff, by running all the statements;on;the;same;line;separated;by;semi-colons;to;= get;linecount;down? > Does TCP-Rehash provide interesting functionality? Sure. Does it provide = anything that MPTCP doesn't provide? No. And it's fewer lines. A better question would be 'Is TCP-rehash missing any= thing important/necessary?' > If we weren't already doing MPTCP, then TCP-Rehash might have been intere= sting. That's not a good justification for not examining TCP-rehash. I've seen other groups settle on a single solution very early, and then sti= ck doggedly to that single solution and ignore other approaches. Fine for p= oint solutions, but when there's a very large potential impact on the insta= lled base, more due diligence on other approaches is called for imo. > But since we are doing MPTCP, I simply don't see the point of specifying = a > subset of it in a way that is incompatible. Lars, are you speaking as an individual contributor or as Area director her= e? thanks L.= From anyrhine@cs.helsinki.fi Mon Nov 15 09:07:23 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2513A6BB5 for ; Mon, 15 Nov 2010 09:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYtFYVQJbb1c for ; Mon, 15 Nov 2010 09:07:22 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 5016328C1B6 for ; Mon, 15 Nov 2010 09:07:17 -0800 (PST) Received: from [192.168.10.3] (cs109108001124.pp.htv.fi [109.108.1.124]) (AUTH: PLAIN anyrhine, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 15 Nov 2010 19:07:57 +0200 id 00093E6C.4CE168ED.000061A8 From: Aki Nyrhinen To: "Scheffenegger, Richard" In-Reply-To: <5FDC413D5FA246468C200652D63E627A0B65CAD6@LDCMVEXC1-PRD.hq.netapp.com> References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <5FDC413D5FA246468C200652D63E627A0B65CAD6@LDCMVEXC1-PRD.hq.netapp.com> Date: Mon, 15 Nov 2010 20:08:42 +0200 Message-Id: <1289844522.5097.407.camel@papana.nyrhi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution 2.22.3.1 Cc: Mike Belshe , Marco Mellia , Michael Welzl , tcpm , tmrg , Matt Mathis Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 17:07:23 -0000 On Thu, 2010-11-11 at 12:27 +0000, Scheffenegger, Richard wrote: > Traffic rarely comes in via 1GE, and drops down to a 64kbps bottleneck > link. Only in the direction homeuser->webserver this huge bandwidth > disparity might be encountered in a single step (but even then I doubt > it). > Web server traffic probably runs over a series of shrinking pipes (ie > 10G/1G/OC12/OC3/T3/T1/64k) - so in the typical web server environment, > even if each link has only small buffers, the server->homeuser > direction will less likely show bad effects I would think. Which > alignes with the data you presented at ICCSG, correct? i don't know what is common and what is not, but my understanding is that here, a dsl access network is typically quite fast optical down to the dslam, which provides dsl access to large number of customers over their dedicated coppers. on the dslam you have exactly the dslam manufacturers default magic number of fifo queuing, which is most likely 64KB or 40 packets regardless of the customer sla. this is likely to be the first place where queuing occurs after the servers uplink, given the 'valley free' characteristic etc. cable network has a similar story, the amount of cpe served by a single cmts is large so cmts will sit in a very fast network, so the queuing takes place there. for wwan (gprs, edge, 3g, etc.), my experience of queuing delays suggests 128KB is typical here (worst case queuing delay beyond 10 seconds at 60kbps). perhaps modem pools aside, i have yet to see the access network were too little buffering is a problem. i have been hoping for quite a while that the buffering would go down to improve interactive performance during bulk transfers but it just does not seem to happen so i have given up hope. instead, i have started hoping they keep the defaults because bandwidths are rising. above 10Mbps, 64KB is quite tolerable. Aki From mallman@icir.org Mon Nov 15 09:39:05 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F373128C1D2 for ; Mon, 15 Nov 2010 09:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4inr0uU9aYG for ; Mon, 15 Nov 2010 09:38:57 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 976C328C1D3 for ; Mon, 15 Nov 2010 09:38:57 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAFHdc9M017518 for ; Mon, 15 Nov 2010 09:39:38 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 86AA424C0EB8 for ; Mon, 15 Nov 2010 12:39:38 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Hotel California MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma28760-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Nov 2010 12:39:38 -0500 Sender: mallman@icir.org Message-Id: <20101115173938.86AA424C0EB8@lawyers.icir.org> Subject: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 17:39:05 -0000 ----------ma28760-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dumb idea: http://www.ietf.org/id/draft-allman-tcpm-bump-initcwnd-00.txt I.e., - Stop waving our hands about where things might break. - Be less aggressive than the 10 segment IW proposed by Jerry, et.al. - Do something. And, start observing how it actually works. - Get to 10 segments in 3 years. But, with much less fluffy discussion and hand waving. - Don't stop at 10 segments, but go all the way to 15 segments over the course of the next 9 years (which is how long it has been since we last increased the IW). allman, stirin' the pot ----------ma28760-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzhcFoACgkQWyrrWs4yIs416wCfQOuWgF9FfSS1nQWBYSGshbo0 dagAnivFAX7lj1S+GNjUuiX5bGpcbyu+ =ROqy -----END PGP SIGNATURE----- ----------ma28760-1-- From alexander.zimmermann@comsys.rwth-aachen.de Mon Nov 15 10:13:36 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E3D28C120 for ; Mon, 15 Nov 2010 10:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf+Zn0btgA7W for ; Mon, 15 Nov 2010 10:13:29 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 66AF728C1CB for ; Mon, 15 Nov 2010 10:13:29 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LBX00LTNUNMJE40@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Mon, 15 Nov 2010 19:14:10 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.59,200,1288566000"; d="sig'?scan'208";a="81268968" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 15 Nov 2010 19:14:08 +0100 Received: from [137.226.12.58] ([unknown] [137.226.12.58]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LBX002USUNKHQ40@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Mon, 15 Nov 2010 19:14:08 +0100 (CET) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-17-152518538 From: Alexander Zimmermann In-reply-to: <20101111174218.3568A247BF2B@lawyers.icir.org> Date: Mon, 15 Nov 2010 19:14:07 +0100 Content-transfer-encoding: 7bit Message-id: <9B50CA85-80C5-40DB-87BB-0D3769ED1FBA@comsys.rwth-aachen.de> References: <20101111174218.3568A247BF2B@lawyers.icir.org> To: "tcpm@ietf.org WG" X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 18:13:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-17-152518538 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi folks, three points I really want to say: * Please stop the discussion about IRTF versus IETF. We (TCPM) had = decided to discuss this doc in TCPM and we adopted the doc as an WG item. So, the = time is over and the discussion about that is wasting time. * We've been going in circles. During the last couples of IETF Meetings, = the following happened: Jerry presented slides and a bunch of = measurements, folks came and raised issues a, b, c. Next Meeting, Jerry answered a, b, c = and folks came with issue d, e, f. Again, next meeting, Jerry ... Stop. Please. =20 * I think we have have a rough consensus that IW=3D10 is something that = we want Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-17-152518538 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzheG8ACgkQdyiq39b9uS4NLACgqjZUmjOgPoth7cn324cCU9i4 1M4AnjWR9vK4UPQEJUA0x7+42kxSYTHr =vZ9y -----END PGP SIGNATURE----- --Apple-Mail-17-152518538-- From rs@netapp.com Mon Nov 15 11:33:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4243A6CF8 for ; Mon, 15 Nov 2010 11:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDwc58EaareW for ; Mon, 15 Nov 2010 11:32:56 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id EC2D73A6CF4 for ; Mon, 15 Nov 2010 11:32:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,201,1288594800"; d="scan'208";a="219915463" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 15 Nov 2010 11:33:33 -0800 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oAFJXXk1018455; Mon, 15 Nov 2010 11:33:33 -0800 (PST) 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, 15 Nov 2010 20:33:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Nov 2010 19:33:31 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B7BCC3F@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <9B50CA85-80C5-40DB-87BB-0D3769ED1FBA@comsys.rwth-aachen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Increasing the Initial Window - Notes Thread-Index: AcuE8PTu28uk9mtaTgGsTNg2e2bu1gACvXOg References: <20101111174218.3568A247BF2B@lawyers.icir.org> <9B50CA85-80C5-40DB-87BB-0D3769ED1FBA@comsys.rwth-aachen.de> From: "Scheffenegger, Richard" To: "Alexander Zimmermann" X-OriginalArrivalTime: 15 Nov 2010 19:33:33.0013 (UTC) FILETIME=[FD37A050:01CB84FB] Cc: tcpm@ietf.org Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 19:33:02 -0000 +1 Richard Scheffenegger =20 > -----Original Message----- > From: Alexander Zimmermann=20 > [mailto:alexander.zimmermann@comsys.rwth-aachen.de]=20 > Sent: Montag, 15. November 2010 19:14 > To: tcpm@ietf.org WG > Subject: Re: [tcpm] Increasing the Initial Window - Notes >=20 > Hi folks, >=20 > three points I really want to say: >=20 > * Please stop the discussion about IRTF versus IETF. We=20 > (TCPM) had decided to > discuss this doc in TCPM and we adopted the doc as an WG=20 > item. So, the time > is over and the discussion about that is wasting time. >=20 > * We've been going in circles. During the last couples of=20 > IETF Meetings, the > following happened: Jerry presented slides and a bunch of=20 > measurements, folks > came and raised issues a, b, c. Next Meeting, Jerry=20 > answered a, b, c and folks > came with issue d, e, f. Again, next meeting, Jerry ... > Stop. Please. > =20 > * I think we have have a rough consensus that IW=3D10 is=20 > something that we want >=20 > Alex >=20 > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 // RWTH=20 > Aachen University // Ahornstr. 55, 52056 Aachen, Germany //=20 > phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email:=20 > zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // >=20 >=20 From rs@netapp.com Mon Nov 15 11:41:15 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811373A6CF4 for ; Mon, 15 Nov 2010 11:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8fT8qA7RR0n for ; Mon, 15 Nov 2010 11:41:08 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 3BFFC3A6BDB for ; Mon, 15 Nov 2010 11:41:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,201,1288594800"; d="scan'208";a="219916306" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 15 Nov 2010 11:41:49 -0800 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oAFJfm0g019217; Mon, 15 Nov 2010 11:41:49 -0800 (PST) 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, 15 Nov 2010 20:41:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Nov 2010 19:41:46 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B7BCC48@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] end-of-stream loss recovery (TCP SACK) Thread-Index: ActzRniX4FJkRTZDQTyNnfWsY3iN0wRtcz3A References: <5254FC29-AD81-4B83-8AC9-7C03A7F4E74C@comsys.rwth-aachen.de><49576D00-CF67-4A91-A00A-9B6CD37EEA46@windriver.com><5FDC413D5FA246468C200652D63E627A0AC76DED@LDCMVEXC1-PRD.hq.netapp.com><5FDC413D5FA246468C200652D63E627A0B02D269@LDCMVEXC1-PRD.hq.netapp.com><20101023014200.GD12426@colt><5FDC413D5FA246468C200652D63E627A0B02D296@LDCMVEXC1-PRD.hq.netapp.com><20101023132527.GE12426@colt> From: "Scheffenegger, Richard" To: , , "Matt Mathis" , "Ethan Blanton" X-OriginalArrivalTime: 15 Nov 2010 19:41:48.0154 (UTC) FILETIME=[245825A0:01CB84FD] Subject: Re: [tcpm] end-of-stream loss recovery (TCP SACK) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 19:41:15 -0000 Hi group, Following up on the discussion prior to IETF79, I submitted a draft spec = to discuss TCP SACK loss recovery at end-of-stream. I believe there was also split concensus if that should be refined = further to get into RFC3517bis (as it is - IMHO - a minor change under = very specific circumstances to TCP SACK), or as a standalone document. I = have one preference, but refrain from pursuing it actively, as there are = more senior members who know better than me on these details. Thanks a lot for your time! Richard Scheffenegger A new version of I-D, draft-scheffenegger-tcpm-sack-loss-recovery-00.txt = has been successfully submitted by Richard Scheffenegger and posted to = the IETF repository. Filename: draft-scheffenegger-tcpm-sack-loss-recovery Revision: 00 Title: Improving SACK-based loss recovery for TCP Creation_date: 2010-11-15 WG ID: Independent Submission Number_of_pages: 12 Abstract: This note clarifies the behavior of TCP SACK while doing loss recovery = close to the end-of-stream. This allows TCP SACK to never exhibit worse = loss recovery characteristics than TCP NewReno under identical = circumstances. = =20 =20 > -----Original Message----- > From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]=20 > Sent: Sonntag, 24. Oktober 2010 08:41 > To: tcpm@ietf.org > Subject: Re: [tcpm] end-of-stream loss recovery (RFC2018 SACK errata?) >=20 > 2010/10/23 Ethan Blanton : >=20 > > S1 ... S7 are sent. =A0S1, S6, and S7 are lost. =A0The sender=20 > retransmits=20 > > S1, gets a cumulative ACK for S6, retransmits S6, then gets a=20 > > cumulative ACK for S7. =A0Should it retransmit S7? =A0Did the = original=20 > > transmission or the retransmission trigger the cum ACK for S7? > > Consider the case were S6 was not lost in the first place,=20 > but delayed=20 > > in the network for ~1RTT. =A0Now consider interaction with=20 > timestamps,=20 > > DSACK, etc. where this potentially *can* be disambiguated. >=20 > In my feeling, this depends on the pipe size. > if cwnd - pipe >=3D 1 SMSS, we can send at least 1 packet. > In this example, S8 will be sent. ( rule (2) in NextSeg()=20 > will be applied) If S8 can arrive at the receiver=20 > successfully, the sender can get good estimation for lost=20 > packets by the ACK for S8. Then, it can retransmit proper packets. >=20 > However, as Richard already pointed out, if this is the end=20 > of transmission, there is no S8. > In this case, I think retransmitting S7 will not be harmful so much. >=20 > If this is not the end of transmission (e.g. application=20 > stall), I'm not very sure whether we should retransmit a packet. >=20 > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From ananth@cisco.com Mon Nov 15 11:45:14 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B593A6D21 for ; Mon, 15 Nov 2010 11:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgwF4RDGf9gM for ; Mon, 15 Nov 2010 11:45:13 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 41B963A6D1E for ; Mon, 15 Nov 2010 11:45:13 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD8d4UyrRN+J/2dsb2JhbACiXHGkS5sXhUoEhFqJDw X-IronPort-AV: E=Sophos;i="4.59,201,1288569600"; d="scan'208";a="217837378" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 15 Nov 2010 19:45:50 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oAFJjoU4006813 for ; Mon, 15 Nov 2010 19:45:50 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Nov 2010 11:45:50 -0800 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, 15 Nov 2010 11:45:49 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580B2CD80F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20101115173938.86AA424C0EB8@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] alternate IW proposal Thread-Index: AcuE7C6/WG/eIa2aSQaLaHfSZo/ykgABS58Q References: <20101115173938.86AA424C0EB8@lawyers.icir.org> From: "Anantha Ramaiah (ananth)" To: X-OriginalArrivalTime: 15 Nov 2010 19:45:50.0339 (UTC) FILETIME=[B4B2A530:01CB84FD] Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 19:45:14 -0000 Folks, I am not sure my response to this may be construed as "hand waving". Basically, I have some general process questions to begin with and later some comments about the document :- ONE REQUEST : Please read this short email in its entirety and provide comments, sometimes the case being made is spread across multiple points, so just please don't pick on one word or sentence and snip the rest. The hope is, I don't want to create a big thread and start a fiery discussion on this aspect (mostly process oriented ) - what is considered a minor change versus a major to TCP? Can the charter be modified to explicitly clarify (best effort would do) this. - IW change, some may feel that it is a fundamental change, but for some it is a minor change or a "parameter change". Well, all of these can be argued as hand waving, IMO. - Just for the illustration lets divide TCP into multiple segments :- The API interface, the protocol semantics, TCP options, TCP congestion and flow control, TCP security, TCP integrity (like checksum etc.,) and some more.. TCP is pervasive protocol and if you really look at each and every aspect of this is equally important and fixing those would generally benefit a lot of applications and hence the "internet".=20 - IRTF versus IETF :- When IW=3D10 was brought up I assumed that it sounded like IRTF work. Why should we keep asking such questions if the charter clearly spells out : "what is construed as a minor change to TCP"?=20 Now there seems to be good interest in getting IW=3D10 adopted and move on, when folks say, "isn't it aggressive" ? (maybe it is a repeat question, causing annoyance, but see below), which is a fair question, IMO, I am baffled to learn that it is construed as hand waving WHEREAS changes that fall into other categories are generally met with stiff resistance with some folks conveniently changing hats and proclaim "the bar is very high for changing TCP". This is double standards, IMO.=20 It would be expedient to analyze merits and de-merits and not "hand wave".. if there is need for more data, then let's call it out explicitly. Once data is collected and the issues are resolved the next revision of the document should acknowledge such a discussion took place and the consensus was "so and so". This way any new entrant who has same questions ( a new entrant is not necessarily new to TCP, it is just that (s)he may not have been following that draft) Makes sense since, if such issues are considered as roadblocks for forwarding momentum of the document, then it is very beneficial to state such things in the document.=20 Some earlier documents used to have an appendix which listed the changes from prior versions and the open issues and consensus of each of them. Later on it was removed when published as an RFC, when the essence got captured into the main document. In fact, in some cases multiple email threads of each open item were started and later posted the resolutions of each of the items. I think for the current document such a methodology may be useful. In the current case, most of the questions are met "we have collected data, go look for it". I clearly want to state something here : I fully understand that Google has done a good job on collecting the data, and that needs to be done since they are proposing an important (for the lack of a better word in my thought process) change. Isn't it fairly obvious that folks reviewing the document may not have all the information gathered and can ask some fundamental questions? Well, if this isn't the expectation, I am surprised. Well, when was the data collected? At different times of the day, peak hours versus no-peak hours?, continents or topologies, how was the burstiness controlled (the document does acknowledge something to this effect), also can we get the traceroute of the paths being simulated? (well, let's not pick on words here, I am not asking for such a thing, but the data collection needs to list them). The document in its existing form doesn't answer these questions, but the pointers provided also don't discuss these stuff exhaustively. That said, I should point out that for anyone who wants to do a better job in reviewing this document, needs to study the data being collected and come up with questions.=20 FWIW, I not opposed to this document, I am just trying to question the "extra protection" this document seems to enjoy, even though this seems like a important change to TCP and needs more scrutiny. One thing for sure, this document needs an applicability statement, i/e,. under what circumstances this IW =3D 10 can be used, and which cases it may be = risky, in other words if definitely needs to be based on a configurable knob. Just my few bits..=20 Thanks, Anantha From mallman@icir.org Mon Nov 15 12:46:19 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61723A6C26 for ; Mon, 15 Nov 2010 12:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJgos+g-eR3G for ; Mon, 15 Nov 2010 12:46:18 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id D795C3A6C88 for ; Mon, 15 Nov 2010 12:46:07 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAFKf9YK008051; Mon, 15 Nov 2010 12:41:10 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C9C0324D1DAB; Mon, 15 Nov 2010 15:41:09 -0500 (EST) To: Lachlan Andrew From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Back in the Saddle MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma39653-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Nov 2010 15:41:09 -0500 Sender: mallman@icir.org Message-Id: <20101115204109.C9C0324D1DAB@lawyers.icir.org> Cc: tcpm , tmrg , Michael Welzl , Stefan Hirschmann Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 20:46:20 -0000 ----------ma39653-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > On 13 November 2010 04:01, Stefan Hirschmann wrote: > > > > To be honest. I don't like the idea that an application behaves > > different depending on the used TCP variant. For me, TCP is kernel > > stuff and an application should use it without thinking. > > Applications very often check the version of OS or CPU they are > running on, and behave differently accordingly. Doing this for TCP > wouldn't be setting a precedent. I am not sure that analogy holds. An app that looks at the OS or the CPU can get a complete story of what's up. Checking on TCP seems a little more tenuous because it isn't really TCP that we're concerned about, but rather the state of the path relative to the TCP config. And, its hard to understand the state of the path. allman ----------ma39653-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzhmuUACgkQWyrrWs4yIs4eUwCglaF5memdRmwhnhEbUzjY+OaI bmsAmgMzPLv58jNiXMjmB/MIRuBe4td3 =MVpf -----END PGP SIGNATURE----- ----------ma39653-1-- From touch@isi.edu Mon Nov 15 13:29:15 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873AF3A6D3B for ; Mon, 15 Nov 2010 13:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fC15l+Dg9YUY for ; Mon, 15 Nov 2010 13:29:14 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B264B3A6C3B for ; Mon, 15 Nov 2010 13:28:51 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAFLTMJN004434 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 15 Nov 2010 13:29:22 -0800 (PST) Message-ID: <4CE1A632.2070202@isi.edu> Date: Mon, 15 Nov 2010 13:29:22 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20101115173938.86AA424C0EB8@lawyers.icir.org> <0C53DCFB700D144284A584F54711EC580B2CD80F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580B2CD80F@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 21:29:15 -0000 On 11/15/2010 11:45 AM, Anantha Ramaiah (ananth) wrote: ... > - IRTF versus IETF :- When IW=10 was brought up I assumed that it > sounded like IRTF work. Why should we keep asking such questions if the > charter clearly spells out : "what is construed as a minor change to > TCP"? I didn't read what happened this way. AFAIR, we only said "the CCRG ought to look at this too", not that the IRTF was the place it should happen once it was reviewed. As to the hurdle, I think it ought to be high for this, perhaps higher than for other changes we've discussed. Some of the TCPM changes don't affect anyone except those who use them; this one affects congestion everywhere, potentially. I'm not uncomfortable with a fairly high bar on such things. Joe From touch@isi.edu Mon Nov 15 13:30:05 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E728B3A693B for ; Mon, 15 Nov 2010 13:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2iIdGm26i8h for ; Mon, 15 Nov 2010 13:29:57 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id F24A23A6C3B for ; Mon, 15 Nov 2010 13:29:56 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAFLU9qd004531 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 15 Nov 2010 13:30:09 -0800 (PST) Message-ID: <4CE1A661.9010507@isi.edu> Date: Mon, 15 Nov 2010 13:30:09 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: mallman@icir.org References: <20101115173938.86AA424C0EB8@lawyers.icir.org> In-Reply-To: <20101115173938.86AA424C0EB8@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 21:30:06 -0000 FWIW, I like this idea better, with the caveat that the doc needs to explain: - what does "observing" mean? - what is the metric of "breaks"? Just putting an idea out there, with no metric for repeal or success, is asking for trouble. Joe On 11/15/2010 9:39 AM, Mark Allman wrote: > > Dumb idea: > > http://www.ietf.org/id/draft-allman-tcpm-bump-initcwnd-00.txt > > I.e., > > - Stop waving our hands about where things might break. > > - Be less aggressive than the 10 segment IW proposed by Jerry, et.al. > > - Do something. And, start observing how it actually works. > > - Get to 10 segments in 3 years. But, with much less fluffy > discussion and hand waving. > > - Don't stop at 10 segments, but go all the way to 15 segments over > the course of the next 9 years (which is how long it has been since > we last increased the IW). > > allman, stirin' the pot > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From lachlan.andrew@gmail.com Mon Nov 15 15:57:10 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6753428C154 for ; Mon, 15 Nov 2010 15:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7UPpSi84PfG for ; Mon, 15 Nov 2010 15:57:03 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E234028C1F1 for ; Mon, 15 Nov 2010 15:57:02 -0800 (PST) Received: by iwn40 with SMTP id 40so65351iwn.31 for ; Mon, 15 Nov 2010 15:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F/xmPO0N+iu1WLwCnyVKtTlU2czAZJFkad1jC6OWRcA=; b=fjjgG/dbVFxu3W7nZ/lS3LUJLOMu06BXTzv+zcnzF5ihCLX2D+m5/qQis+cBrhEa6s 8q0jNZH94bMlZa0AhzbVchxQY67kjV0ExsfxCAkeD+sUPM2bUuxAR4up0m1WMO0ZVSgX wSHWmdui0DijN6io2vO69eV6Q8N6JTtnKNMgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tfIzhFIyT2fFH6zac3JvJZapv0oz++Pj17d+mggqE+s9vxXpfeopfF/dj44vSDaXWm M6oRu4Qgy87sMg7NcZUXz6tANxOVtxD0vctdyhSNa6Zt2Jz+me7vzHA5y9ZFPV9IqOAd l2pTmMpjXJEw+DUJ5IAHkD1Ku844FmVneb5JY= MIME-Version: 1.0 Received: by 10.42.178.6 with SMTP id bk6mr1246925icb.80.1289865463650; Mon, 15 Nov 2010 15:57:43 -0800 (PST) Received: by 10.231.173.210 with HTTP; Mon, 15 Nov 2010 15:57:43 -0800 (PST) In-Reply-To: <20101115204109.C9C0324D1DAB@lawyers.icir.org> References: <20101115204109.C9C0324D1DAB@lawyers.icir.org> Date: Mon, 15 Nov 2010 15:57:43 -0800 Message-ID: From: Lachlan Andrew To: mallman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tmrg , tcpm , Michael Welzl , Stefan Hirschmann Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 23:57:10 -0000 On 15 November 2010 12:41, Mark Allman wrote: > >> On 13 November 2010 04:01, Stefan Hirschmann wrote: >> > >> > To be honest. I don't like the idea that an application behaves >> > different depending on the used TCP variant. For me, TCP is kernel >> > stuff and an application should use it without thinking. >> >> Applications very often check the version of OS or CPU they are >> running on, and behave differently accordingly. =A0Doing this for TCP >> wouldn't be setting a precedent. > > I am not sure that analogy holds. =A0An app that looks at the OS or the > CPU can get a complete story of what's up. =A0Checking on TCP seems a > little more tenuous because it isn't really TCP that we're concerned > about, but rather the state of the path relative to the TCP config. > And, its hard to understand the state of the path. I agree the application shouldn't follow the TCP state, but that is different from adapting to which variant is used. I thought the issue was "If we fix problem X of TCP (very slow to start), should applications be able to test whether that fix has been made, and disable their old work-arounds (opening multiple connections) if it has?" Of course, it isn't that simple, because the work-around of opening many connections may give selfish users additional benefits even if underlying issues are fixed and so the incentives are wrong. However, I don't see a problem in principle with an app adapting to the flavour of TCP, any more than an app getting a choice of DCCP congestion control algorithm, or using DCCP if it is available and UDP otherwise. Cheers, Lachlan --=20 Lachlan Andrew=A0 Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From mallman@icir.org Mon Nov 15 17:58:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81D43A6D81 for ; Mon, 15 Nov 2010 17:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6IKIeHTqNEj for ; Mon, 15 Nov 2010 17:58:38 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id DD1C13A6AB9 for ; Mon, 15 Nov 2010 17:58:37 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAG1uV7N018076; Mon, 15 Nov 2010 17:56:32 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B67C624D6257; Mon, 15 Nov 2010 20:56:31 -0500 (EST) To: Lachlan Andrew From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Back in the Saddle MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma58572-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Nov 2010 20:56:31 -0500 Sender: mallman@icir.org Message-Id: <20101116015631.B67C624D6257@lawyers.icir.org> Cc: tmrg , tcpm , Michael Welzl , Stefan Hirschmann Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 01:58:39 -0000 ----------ma58572-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I thought the issue was "If we fix problem X of TCP (very slow to > start), should applications be able to test whether that fix has been > made, and disable their old work-arounds (opening multiple > connections) if it has?" OK. So, the client wants to issue small requests to some server and expects content in return (a la HTTP). How many connections should it open? The server controls the initial cwnd that matters and the client controls the number of parallel connections. allman ----------ma58572-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzh5M4ACgkQWyrrWs4yIs5+QQCglKRz4rzJIYmWAqMCGH/OJSg3 fL0AoI+Nt3xGyysYxzyB9M7F4ojOCFA8 =2M7O -----END PGP SIGNATURE----- ----------ma58572-1-- From lachlan.andrew@gmail.com Mon Nov 15 18:17:04 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8D0928C120 for ; Mon, 15 Nov 2010 18:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1WmNs5PtEVo for ; Mon, 15 Nov 2010 18:16:38 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 332E43A6D82 for ; Mon, 15 Nov 2010 18:16:37 -0800 (PST) Received: by iwn40 with SMTP id 40so191557iwn.31 for ; Mon, 15 Nov 2010 18:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1iuq39vwc4Q0QJa7g8L0WWTABM6rzhV1qOmKvE6Pt6c=; b=cFZRpWGfyl2cYdgris3WpD/D9r/bzIP/WJU4YEq8/cczSVUGV0ok9X1stFI0AkHSe8 RGk90PoyoFHGhh/SyHcm9KmU3Pnc9KjspZKJFussQpo3MnJSfeQgqsgRnvRb031WK9e+ N2S93IWaPkEXfZBKlqo03TJzH2KfStd4Y02bE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DGrxWlklh+aU3BTFilYGeohx+ayF2bDO0GH8iVzo97JIkTVUajiBuxSyNN10mK4MOj VwXJGn5+NjAglTeua22W5xRNB2oAjy4oH/bEvmm/nlNN43zV3MjRY1ANoNSg9+Qcslsq ToFgSoBTPX+KZTNeCUAfqMDm4fVUdP32qPQAc= MIME-Version: 1.0 Received: by 10.42.224.4 with SMTP id im4mr5576631icb.147.1289873838788; Mon, 15 Nov 2010 18:17:18 -0800 (PST) Received: by 10.231.173.210 with HTTP; Mon, 15 Nov 2010 18:17:18 -0800 (PST) In-Reply-To: <20101116015631.B67C624D6257@lawyers.icir.org> References: <20101116015631.B67C624D6257@lawyers.icir.org> Date: Mon, 15 Nov 2010 18:17:18 -0800 Message-ID: From: Lachlan Andrew To: mallman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tmrg , tcpm , Michael Welzl , Stefan Hirschmann Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 02:17:04 -0000 On 15 November 2010 17:56, Mark Allman wrote: > >> I thought the issue was "If we fix problem X of TCP (very slow to >> start), should applications be able to test whether that fix has been >> made, and disable their old work-arounds (opening multiple >> connections) if it has?" > > OK. =A0So, the client wants to issue small requests to some server and > expects content in return (a la HTTP). =A0How many connections should it > open? =A0The server controls the initial cwnd that matters and the client > controls the number of parallel connections. Good point. That is a compelling argument. I was only refuting the argument that for an app to talk to its own kernel about its TCP variant is some sort of layering violation. Perhaps I misunderstood the original poster. Cheers, Lachlan --=20 Lachlan Andrew=A0 Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From johnwheffner@gmail.com Mon Nov 15 19:44:58 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E503A6C63 for ; Mon, 15 Nov 2010 19:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqiJHXs7wTiK for ; Mon, 15 Nov 2010 19:44:57 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 0121B3A6A5B for ; Mon, 15 Nov 2010 19:44:56 -0800 (PST) Received: by bwz12 with SMTP id 12so248474bwz.31 for ; Mon, 15 Nov 2010 19:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=R5DriJgUshq8OLzomlMx7VjxiTXlCWeQ2CeW6N9HV8c=; b=O/Py35ZS4egCRfVtO7Ene6ksnHJU2WQs0opTBEqmhamVMIT3wFU0nH/H+zcTWKPOGU K/TZlqF33M5PGDrqo3rd8w61zbkuDCyA1FmHy5jMsoUpR6kE0KyhTo922cAJx09jXnjs nbbYYdjPx5gBevZvW6jbPkc3avU6vCoabUv+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hei3L1yNvrfkacOHSnbXkLM6HUf3ZemRx6ztlICDdjcTMmk6B6jaUfgM1+mWTZU67H zSSB/KTZFMkq8FidWoT8GgZgRpoJ/SMIIzBlOS0eZGTPlPI2S2lQXY1GwtIdh9WKoZl7 jm94N8tks3Sf9YO7O6CSdk8YHCptg62iL5dpA= MIME-Version: 1.0 Received: by 10.204.64.139 with SMTP id e11mr6955075bki.212.1289879138141; Mon, 15 Nov 2010 19:45:38 -0800 (PST) Received: by 10.204.118.67 with HTTP; Mon, 15 Nov 2010 19:45:37 -0800 (PST) In-Reply-To: References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> Date: Mon, 15 Nov 2010 22:45:37 -0500 Message-ID: From: John Heffner To: Jerry Chu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm , tmrg Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 03:44:58 -0000 On Thu, Nov 11, 2010 at 5:56 PM, Jerry Chu wrote: > On Thu, Nov 11, 2010 at 2:58 AM, Michael Welzl wrote= : >> >> On Nov 11, 2010, at 11:49 AM, Marco Mellia wrote: >> >>> >>> >>>>> I certainly won't object to this, if that's all it takes for >>>>> standardization. Unfortunately the >>>>> point for the non-convinced is they don't want ANY flows to use IW10 >>>>> for fear of hurting >>>>> the performance of their flows. >>>> >>>> ... but here, your "browsers open tens of flows" argument totally hold= s. >>>> How is a web flow with IW10 worse than a browser opening tens of flows= ? If >>>> people only use it for the web, like Google has been successfully doin= g, >>>> this seems to be quite safe, based on experience. >>>> >>>> I'm curious what the opposition says to this =A0:) >>> >>> If today a brower opens 10 flows with a server using IW=3D1 you gets 10 >>> packets equivalent IW. >>> Increasing the IW to 10 leads to an equivalent IW of 100 packets. At th= at >>> point, you DSL modem will definitively start dropping most of them... >> >> ... which is a good reason to open fewer connections. So that's a matter >> of bringing of bringing out an update of a web client with a different >> behavior for the case that a web server uses a larger IW. But how does t= he >> web browser know what the web server is doing? I guess they could exchan= ge >> this information with HTTP. Hm. Are we getting somewhere here, or is thi= s a >> dead end? > > One solution to safely migrate to IW10 for browsers opening multiple > connections is to mandate browsers that open X connections, when X is, e.= g., >> 4 to set the initial receive window to 3 (assuming OSes allow initrwnd t= o > be set on a per connection basis). But I don't know how this can be > enforced... > Jerry I'm not a Googler, so you probably have better insight into this than I do, but my impression is that one big reason (if not the *primary* reason) browsers open multiple connections is being able to submit requests in parallel. HTTP pipelining can help some, but (a) most browsers disable this because of some buggy and widely deployed servers, and (b) it is still susceptible to head-of-line blocking on responses. Might limiting the number of simultaneous connections based on IW hurt more than it helps? The solution would seem to be shared congestion state on the server. Like the "congestion manager" (http://nms.lcs.mit.edu/cm/), or using multiple channels in SCTP. Of course, this may not be practical with a lot of load-balancing systems. Thanks, -John From fred@cisco.com Mon Nov 15 20:06:55 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE883A6D8F for ; Mon, 15 Nov 2010 20:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.263 X-Spam-Level: X-Spam-Status: No, score=-110.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04ZBMlNY6WFy for ; Mon, 15 Nov 2010 20:06:54 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 30A6E3A6D8A for ; Mon, 15 Nov 2010 20:06:54 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG+S4UxAaMHG/2dsb2JhbACiW3GkHpskhUoEhFiFf4MM X-IronPort-AV: E=Sophos;i="4.59,203,1288569600"; d="scan'208";a="287084561" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2010 04:07:35 +0000 Received: from Freds-Computer.local (hkidc-vpn-client-233-38.cisco.com [10.75.233.38]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAG47Tjn024066; Tue, 16 Nov 2010 04:07:33 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 16 Nov 2010 12:07:34 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 16 Nov 2010 12:07:34 +0900 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Tue, 16 Nov 2010 12:07:21 +0800 Message-Id: References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> To: Jerry Chu X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: tcpm , tmrg Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 04:06:55 -0000 On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > I wonder what factors will argue that the initial quantum can't be = changed? > Someone has argued in the past IW10 effectively "disable CC = algorithm". > But haven't we already done that years ago when moving up IW from 1 to = 3 if > one insisted then that the initial quantum must be 1? Actually, no. I may be the person who said that this effectively = disables congestion control in the average case; my reason for saying = that is that per what little data I have, the average TCP transfer is on = the order of 15K bytes, which is about ten 1460 byte segments.=20 Now, the median is much smaller - on the order of two or three data = segments each direction, which is where you get your comment. But the = fact that browsers, Bittorrent, and other applications open multiple = sessions simultaneously argues that a given endpoint having multiple = packets in flight simultaneously doesn't hurt, and research done at the = time by Mark Allman and others showed that IW=3D2..4 wasn't a problem = and did in fact reduce the median session to a single RTT for data. But = the median session doesn't create a congestion problem. The question I have been asking is how IW=3D10 affects parallel sessions = on relatively low speed links. My sense is that the sudden arrival of = O(15K) bytes at a 56 KBPS line, which is to say the insertion of a tad = over two seconds delay in all competing sessions plus an increase in = their probability of loss, is likely to cause them all to be disrupted. = You told me verbally that in your tests it is net beneficial to the = parallel sessions, but in thought experiments I'm not sure how that can = be true; I'd be fascinated to see the data that shows that competing = voice/video sees no frame loss or induced noise, that competing file = transfers slow down but do not see redundant retransmissions, and so on. So, IW=3D2..4 demonstrably works pretty well everywhere, but IW=3D10 = seems to me only sensible on MPBS and GBPS, not KBPS, scale links.=20= From touch@isi.edu Mon Nov 15 21:43:46 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559243A6C71 for ; Mon, 15 Nov 2010 21:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAlSFBHr4fpk for ; Mon, 15 Nov 2010 21:43:45 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3ACD63A6C77 for ; Mon, 15 Nov 2010 21:43:45 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAG5htcY020566 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 15 Nov 2010 21:44:05 -0800 (PST) Message-ID: <4CE21A0F.8000309@isi.edu> Date: Mon, 15 Nov 2010 21:43:43 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: John Heffner References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> 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 , tmrg Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 05:43:46 -0000 On 11/15/2010 7:45 PM, John Heffner wrote: ... > The solution would seem to be shared congestion state on the server. > Like the "congestion manager" (http://nms.lcs.mit.edu/cm/), or using > multiple channels in SCTP. Of course, this may not be practical with > a lot of load-balancing systems. Or RFC2140, at least part of which is already in Linux. The 2140 approach can be aggregated across machines: We also note that per-host-pair associations are not the limit of these techniques. It is possible that TCBs could be similarly shared between hosts on a LAN, because the predominant path can be LAN-LAN, rather than host-host. Joe From L.Wood@surrey.ac.uk Tue Nov 16 00:22:53 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487F83A6DAB for ; Tue, 16 Nov 2010 00:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ko8x9JgBbyRa for ; Tue, 16 Nov 2010 00:22:52 -0800 (PST) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 663753A6BDA for ; Tue, 16 Nov 2010 00:22:51 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-11.tower-82.messagelabs.com!1289895811!29714127!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 21349 invoked from network); 16 Nov 2010 08:23:31 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-11.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 16 Nov 2010 08:23:31 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Tue, 16 Nov 2010 08:23:31 +0000 From: To: Date: Tue, 16 Nov 2010 08:23:28 +0000 Thread-Topic: [tcpm] [Tmrg] Increasing the Initial Window - Notes Thread-Index: AcuFZ401rPnlLDB+RGWgMEJATqIs+w== Message-ID: <814F0E13-A993-4E24-AB6D-473BE36A1094@surrey.ac.uk> References: <20101116015631.B67C624D6257@lawyers.icir.org> In-Reply-To: <20101116015631.B67C624D6257@lawyers.icir.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_814F0E13A9934E24AB6D473BE36A1094surreyacuk_" MIME-Version: 1.0 Cc: lachlan.andrew@gmail.com, tcpm@ietf.org, L.Wood@surrey.ac.uk, michawe@ifi.uio.no, krasnoj@gmx.at, tmrg@irtf.org Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 08:22:53 -0000 --_000_814F0E13A9934E24AB6D473BE36A1094surreyacuk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 16 Nov 2010, at 01:56, Mark Allman wrote: I thought the issue was "If we fix problem X of TCP (very slow to start), should applications be able to test whether that fix has been made, and disable their old work-arounds (opening multiple connections) if it has?" OK. So, the client wants to issue small requests to some server and expects content in return (a la HTTP). How many connections should it open? RFC 2068 section 8.1: Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD maintain AT MOST 2 connections with any server or proxy. The server controls the initial cwnd that matters and the client controls the number of parallel connections. allman Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood --_000_814F0E13A9934E24AB6D473BE36A1094surreyacuk_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On 16 Nov 2010, at 01:56, Mark Allm= an wrote:


I = thought the issue was "If we fix problem X of TCP (very slow to
start), should applications be able to test = whether that fix has been
made, a= nd disable their old work-arounds (opening multiple
connections) if it has?"

OK.  S= o, the client wants to issue small requests to some server and
expects c= ontent in return (a la HTTP).  How many connections should it
open?=  


RFC 2068 section 8.1:
=    Clients that use persistent connections SHOULD limit the numbe= r of
   simultaneous connections that they maintain to a given= server. A
   single-user client SHOULD maintain AT MOST 2 con= nections with any
   server or proxy.


The server controls the initial cwnd that matters and t= he client
controls the number of parallel connections.

allman
=

Lloyd Wo= od
L.Wood@surrey.ac.uk
htt= p://sat-net.com/L.Wood



= --_000_814F0E13A9934E24AB6D473BE36A1094surreyacuk_-- From michawe@ifi.uio.no Tue Nov 16 01:17:35 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1383A6BDE for ; Tue, 16 Nov 2010 01:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJK27BkW9iDX for ; Tue, 16 Nov 2010 01:17:34 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 779FB3A6A3C for ; Tue, 16 Nov 2010 01:17:33 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1PIHg7-0005rm-Ph for tcpm@ietf.org; Tue, 16 Nov 2010 10:18:15 +0100 Received: from div-8021x-dhcp216.uio.no ([193.157.176.225]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.69) (envelope-from ) id 1PIHg7-0002YJ-BV for tcpm@ietf.org; Tue, 16 Nov 2010 10:18:15 +0100 Message-Id: From: Michael Welzl To: "tcpm@ietf.org WG" In-Reply-To: <4CE1A661.9010507@isi.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Nov 2010 10:18:15 +0100 References: <20101115173938.86AA424C0EB8@lawyers.icir.org> <4CE1A661.9010507@isi.edu> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 7 sum msgs/h 4 total rcpts 4201 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6CCB460C5A9BFA0032A30884C8DD6F8B4E2D285C X-UiO-SPAM-Test: remote_host: 193.157.176.225 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1433 max/h 11 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 09:17:35 -0000 Hi, I agree that this is a neat idea. BTW I also agree with the various comments regarding my proposal to let applications decide the IW; it was just an idea, for trying to find an easy compromise, but you guys convinced me that it was a stupid one. Cheers, Michael On Nov 15, 2010, at 10:30 PM, Joe Touch wrote: > FWIW, I like this idea better, with the caveat that the doc needs to > explain: > > - what does "observing" mean? > > - what is the metric of "breaks"? > > Just putting an idea out there, with no metric for repeal or > success, is asking for trouble. > > Joe > > On 11/15/2010 9:39 AM, Mark Allman wrote: >> >> Dumb idea: >> >> http://www.ietf.org/id/draft-allman-tcpm-bump-initcwnd-00.txt >> >> I.e., >> >> - Stop waving our hands about where things might break. >> >> - Be less aggressive than the 10 segment IW proposed by Jerry, >> et.al. >> >> - Do something. And, start observing how it actually works. >> >> - Get to 10 segments in 3 years. But, with much less fluffy >> discussion and hand waving. >> >> - Don't stop at 10 segments, but go all the way to 15 segments over >> the course of the next 9 years (which is how long it has been >> since >> we last increased the IW). >> >> allman, stirin' the pot >> >> >> >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From c.raiciu@cs.ucl.ac.uk Tue Nov 16 01:21:11 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6BE3A69CE; Tue, 16 Nov 2010 01:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xX8wMLADFg7; Tue, 16 Nov 2010 01:21:09 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 7206D3A6BDE; Tue, 16 Nov 2010 01:21:09 -0800 (PST) Received: from [141.85.37.251] (helo=[10.38.219.64]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1PIHRP-000PYG-Lw; Tue, 16 Nov 2010 09:03:03 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Costin Raiciu In-Reply-To: <4CE10B0C.1040705@alcatel-lucent.com> Date: Tue, 16 Nov 2010 11:21:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CDA4FA9.4050006@alcatel-lucent.com> <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com> <4CE10B0C.1040705@alcatel-lucent.com> To: Bruno Mongazon-Cazavet X-Mailer: Apple Mail (2.1081) Cc: Multipath TCP Mailing List , tcpm@ietf.org Subject: [tcpm] MPTCP vs Rehash (was TCPM WG status update) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 09:21:11 -0000 Bruno, I've read your draft too and I agree with Richard, it seems to support a = subset of what MPTCP does, only focusing on connection mobility.=20 On top of that MPTCP allows connections to use multiple paths in = parallel (providing reordering, congestion control, etc).=20 Re-hash's aim seems to be increasing robustness for mobile client = applications. I personally think multipath TCP is a better solution than = re-hash because it can probe multiple paths in parallel and literally = get the best service at any time. In contrast, re-hash allows = connections to use a single address (e.g. 3g/wifi) at any time; this = will give significantly worse performance when devices are truly mobile = and link properties change quickly e.g. people driving or walking (this = is a handwaving argument, we have not run any tests to prove this). More importantly, I'd like to point out that this type of connection = mobility is already implemented in mobile devices as far as I = understand: the stack forcibly terminates all connections when their = interface goes down and a new one is available, and the applications = reopen connections which will use the new interface. The apps have = already been changed to support this. The apps that haven't been changed = already probably don't care about this type of robustness that much. = With this in mind, I reluctantly admit that MPTCP itself will bring = little improvement to apps robustness; re-hash will bring none. As a clarifying note to richard's comment earlier: MPTCP does support = break-before-make mobility, as long as the new subflow is opened while = both endpoints have state about the connection (i.e. the original = subflow has not reach max timeouts). In practice, this means that if a = client is mobile, loses its address and gains a new one in a reasonable = amount of time, it will be able to add a subflow to the existing = connection, hence supporting break-before-make mobilty. As rehash, = MPTCP does not support simultaneous mobility. Cheers, Costin On 15 Nov 2010, at 12:27, Bruno Mongazon-Cazavet wrote: > Dear Richard; >=20 > Thank you for looking at TCP-Rehash. > Please see my comments inline. >=20 > Regards, > Bruno Mongazon >=20 > Le 10/11/2010 13:51, Scheffenegger, Richard a =E9crit : >> Hi Bruno, >>=20 >> After a casual look, it appears to me that a lightweight = implementation of MP-TCP can have the same benefits, but does not = require the opaque exchange of IPv4 addresses... >=20 > Yes an idea would be to have TCP-Rehash =3D=3D lightweigth MPTCP > There are a few design diffferences that need to be looked at. >=20 >> Your use case - that the old L3 address is already no longer = available at the time of the rehash - may need to be looked at in MPTCP = though (iirc, they do a graceful session setup first (thus can work with = NAT mostly), and move data transport only after the successful = establishment of the 2nd L3 connectivity, and only then tear down the = original L3 connectivity). >=20 > Right but... there is no real constraint on old address availability, = thus the old address might still be available. > A key difference between TCP-Rehash and MPTCP is the session setup. = With TCP-Rehash there is no setup, it is a straight move. If it fails, = the connection is broken, this would happen anyway if L3 address changes = and there is no "move" mechanism. Doing so is just opportunistic but = deterministic. MPTCP is more complex since a new connection is setup = before the old connection is being "moved". > =46rom design perspective, would it be that complex for MPTCP to = handle rehash design ? >=20 > NAT is a different story (orthogonal i would say) and issue. >=20 >> Perhaps the effort would be better placed on making sure that such = light-weight MPTCP implementations remain feasible, instead of defining = an alternate method that is addressing only this one aspect, but = incompatible with MPTCP otherwise? >=20 > To be honest i have both TCP-Rehash and MPTCP linux kernel source = code... my intention is not to define an alternate method ! Rather i = posted the TCP-Rehash draft with the intention to provide some = additional work on the topic. Convergence and collaboration is of course = to be considered. I think my work, although it was not disclosed, = started sometimes ago, almost at early MPTCP. >=20 > Please let me know, if from the design point of view, the WG would = consider the opportunity to have a lightweight MPTCP that would look = like TCP-Rehash. >=20 >> Richard Scheffenegger >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Bruno Mongazon-Cazavet >>> [mailto:bruno.mongazon-cazavet@alcatel-lucent.com] >>> Sent: Mittwoch, 10. November 2010 08:54 >>> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >>> Cc: tcpm@ietf.org >>> Subject: Re: [tcpm] WG status update >>>=20 >>>=20 >>> Le 10/11/2010 01:54, Eddy, Wesley M. (GRC-MS00)[ASRC >>> AEROSPACE CORP] a =E9crit : >>>> Hi, for those of you who aren't in Beijing, here's a >>> snapshot of the TCPM WG status. >>>=20 >>> Hi, >>>=20 >>> I have posted a 00 draft that might be of interest for your working >>> group. I don't see any mention in your snapshot. >>> http://www.ietf.org/id/draft-mongazon-tcpm-tcp-rehash-00.txt >>>=20 >>> I will not be in Beijing to present it but i hope to be in >>> Prague to do so. >>> I would appreciate the working group can look at it and let >>> me know if >>> it could be of any interest and how i shall pursue my contribution. >>>=20 >>> I have done a Linux kernel implementation of the draft and be >>> ready for >>> a demo in Prague. >>>=20 >>> Best Regards, >>> Bruno. >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From bruno.mongazon-cazavet@alcatel-lucent.com Tue Nov 16 03:25:54 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A3A3A6DD8; Tue, 16 Nov 2010 03:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zP3pAhxjVX1E; Tue, 16 Nov 2010 03:25:53 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 5F3C03A6DDA; Tue, 16 Nov 2010 03:25:53 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAGBQUWp027892 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 Nov 2010 12:26:30 +0100 Received: from [172.27.205.223] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 16 Nov 2010 12:26:30 +0100 Message-ID: <4CE26A65.5090702@alcatel-lucent.com> Date: Tue, 16 Nov 2010 12:26:29 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Costin Raiciu References: <4CDA4FA9.4050006@alcatel-lucent.com> <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com> <4CE10B0C.1040705@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: Multipath TCP Mailing List , "tcpm@ietf.org" Subject: Re: [tcpm] MPTCP vs Rehash (was TCPM WG status update) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 11:25:55 -0000 Costin, Thanks for having read the draft. I did not want to go into MPTCP vs Rehash considerations (and that's the reason i posted in TCPM wg) but it seems ineluctable. So let's go deeper and please see inline. I would also be interested to have additional opinions from wg members. Regards, Bruno Le 16/11/2010 10:21, Costin Raiciu a écrit : > Bruno, > > I've read your draft too and I agree with Richard, it seems to support a subset of what MPTCP does, only focusing on connection mobility. [bm] Yes. But connection mobility in the wide sense, including mobility and load-balancing. > > On top of that MPTCP allows connections to use multiple paths in parallel (providing reordering, congestion control, etc). [bm] Yes. MPTCP relies on the "path" and "parallelism" concepts. TCP-Rehash excludes these concepts from the beginning of design. In particular, TCP-Rehash has not been designed according to a rule which states that a TCP connection can get benefits in using multiple paths in parallel. Moreover i would say that TCP-Rehash has been designed with exactly the reverse opinion in mind (philosophy): We don't know if and how we can take advantage using parallelism, so just provide a simple and lightweight mechanism to allow each TCP connection to be migrated on both ends agreement. > > > Re-hash's aim seems to be increasing robustness for mobile client applications. I personally think multipath TCP is a better solution than re-hash because it can probe multiple paths in parallel and literally get the best service at any time. In contrast, re-hash allows connections to use a single address (e.g. 3g/wifi) at any time; this will give significantly worse performance when devices are truly mobile and link properties change quickly e.g. people driving or walking (this is a handwaving argument, we have not run any tests to prove this). [bm] Right, MPTCP provide more functionnalities. However there is a cost (probing, TCP options overhead on all data). TCP-Rehash only aims to provide the minimal capability at the minimal cost. I personally think that providing alternatives is always a good option. As far as performance are concerned we probably need a closed look. I would not bet TCP-Rehash is not suited fro "truly mobile", since connection rehash involves only sending a TCP option in a outgoing packet. > More importantly, I'd like to point out that this type of connection mobility is already implemented in mobile devices as far as I understand: the stack forcibly terminates all connections when their interface goes down and a new one is available, and the applications reopen connections which will use the new interface. The apps have already been changed to support this. [bm] TCP-Rehash is exactly done to avoid this by bringing the capability at transport level to the benefit of all applications. There are still a bunch of applications that do not implement such behavior, why should they ? > The apps that haven't been changed already probably don't care about this type of robustness that much. With this in mind, I reluctantly admit that MPTCP itself will bring little improvement to apps robustness; re-hash will bring none. [bm] I disagree. Applications do care about robustness. Most of them need to handle socket() errors and in most case they fall into unavailability or interruption. With either MPTCP or TCP-Rehash they could keep the same code but just do not execute it because the transport has been improved. So MPTCP could bring minimal to high improvement and TCP-Rehash only minimal (but essential?) improvement. > As a clarifying note to richard's comment earlier: MPTCP does support break-before-make mobility, as long as the new subflow is opened while both endpoints have state about the connection (i.e. the original subflow has not reach max timeouts). In practice, this means that if a client is mobile, loses its address and gains a new one in a reasonable amount of time, it will be able to add a subflow to the existing connection, hence supporting break-before-make mobilty. As rehash, MPTCP does not support simultaneous mobility. [bm] TCP-Rehash can be synced with address management in different and open manners. What could trigger an individual connection rehash is outside the scope of my draft. Trigger can be the address change of a single interface or additional interface(s) addition. There is no restriction although there might be strategies of common sense. For example i tried rehash in the following situations: -pure handoff -offloading some connections when multiple interfaces are available Both rely on the same TCP enhancements (rehash) but the music is played in a different way. Just a matter of the director. In all cases, you cannot say Rehash does not support simultaneous mobility. Regards, Bruno. > Cheers, > Costin > > On 15 Nov 2010, at 12:27, Bruno Mongazon-Cazavet wrote: > >> Dear Richard; >> >> Thank you for looking at TCP-Rehash. >> Please see my comments inline. >> >> Regards, >> Bruno Mongazon >> >> Le 10/11/2010 13:51, Scheffenegger, Richard a écrit : >>> Hi Bruno, >>> >>> After a casual look, it appears to me that a lightweight implementation of MP-TCP can have the same benefits, but does not require the opaque exchange of IPv4 addresses... >> Yes an idea would be to have TCP-Rehash == lightweigth MPTCP >> There are a few design diffferences that need to be looked at. >> >>> Your use case - that the old L3 address is already no longer available at the time of the rehash - may need to be looked at in MPTCP though (iirc, they do a graceful session setup first (thus can work with NAT mostly), and move data transport only after the successful establishment of the 2nd L3 connectivity, and only then tear down the original L3 connectivity). >> Right but... there is no real constraint on old address availability, thus the old address might still be available. >> A key difference between TCP-Rehash and MPTCP is the session setup. With TCP-Rehash there is no setup, it is a straight move. If it fails, the connection is broken, this would happen anyway if L3 address changes and there is no "move" mechanism. Doing so is just opportunistic but deterministic. MPTCP is more complex since a new connection is setup before the old connection is being "moved". >> From design perspective, would it be that complex for MPTCP to handle rehash design ? >> >> NAT is a different story (orthogonal i would say) and issue. >> >>> Perhaps the effort would be better placed on making sure that such light-weight MPTCP implementations remain feasible, instead of defining an alternate method that is addressing only this one aspect, but incompatible with MPTCP otherwise? >> To be honest i have both TCP-Rehash and MPTCP linux kernel source code... my intention is not to define an alternate method ! Rather i posted the TCP-Rehash draft with the intention to provide some additional work on the topic. Convergence and collaboration is of course to be considered. I think my work, although it was not disclosed, started sometimes ago, almost at early MPTCP. >> >> Please let me know, if from the design point of view, the WG would consider the opportunity to have a lightweight MPTCP that would look like TCP-Rehash. >> >>> Richard Scheffenegger >>> >>> >>> >>>> -----Original Message----- >>>> From: Bruno Mongazon-Cazavet >>>> [mailto:bruno.mongazon-cazavet@alcatel-lucent.com] >>>> Sent: Mittwoch, 10. November 2010 08:54 >>>> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >>>> Cc: tcpm@ietf.org >>>> Subject: Re: [tcpm] WG status update >>>> >>>> >>>> Le 10/11/2010 01:54, Eddy, Wesley M. (GRC-MS00)[ASRC >>>> AEROSPACE CORP] a écrit : >>>>> Hi, for those of you who aren't in Beijing, here's a >>>> snapshot of the TCPM WG status. >>>> >>>> Hi, >>>> >>>> I have posted a 00 draft that might be of interest for your working >>>> group. I don't see any mention in your snapshot. >>>> http://www.ietf.org/id/draft-mongazon-tcpm-tcp-rehash-00.txt >>>> >>>> I will not be in Beijing to present it but i hope to be in >>>> Prague to do so. >>>> I would appreciate the working group can look at it and let >>>> me know if >>>> it could be of any interest and how i shall pursue my contribution. >>>> >>>> I have done a Linux kernel implementation of the draft and be >>>> ready for >>>> a demo in Prague. >>>> >>>> Best Regards, >>>> Bruno. >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From lars.eggert@nokia.com Tue Nov 16 03:47:37 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25BC03A6A73 for ; Tue, 16 Nov 2010 03:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVt4OOl7L85R for ; Tue, 16 Nov 2010 03:47:36 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 23A073A695E for ; Tue, 16 Nov 2010 03:47:35 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oAGBmE7f003763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Nov 2010 13:48:15 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-9-215763525; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Tue, 16 Nov 2010 13:48:12 +0200 Message-Id: References: <4CDA4FA9.4050006@alcatel-lucent.com> <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com> <4CE10B0C.1040705@alcatel-lucent.com> <9EAEB61A-6E43-4EB2-B89F-32A3957814AB@nokia.com> <4CE13DBD.5010706@alcatel-lucent.com> <1642C18A-EDF4-4B5F-920C-05F66F3C0F15@nokia.com> To: L.Wood@surrey.ac.uk X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 16 Nov 2010 13:48:12 +0200 (EET) X-Nokia-AV: Clean Cc: tcpm@ietf.org Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 11:47:37 -0000 --Apple-Mail-9-215763525 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-11-15, at 17:39, L.Wood@surrey.ac.uk wrote: >> But since we are doing MPTCP, I simply don't see the point of = specifying a >> subset of it in a way that is incompatible. >=20 > Lars, are you speaking as an individual contributor or as Area = director here? Individual. (Thanks for reminding me to make this clear.) Lars= --Apple-Mail-9-215763525 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag 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 aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTExNjExNDgxMlowIwYJKoZIhvcNAQkE MRYEFOEwzg2ncpTzVGKzmwTskiQYge26MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AA9V03ng5O+s2Y2hJtWUNOKSXQVjHNbwoMRHP0sNc3a6x9jRDFL8xD1enQAMVGCp0N+ub3uz36d3 NNlLiey8A0pQ8T8mpnXHGEyo9AaWpu/bul7kqj5s+Me8GHpg2npNNneE+Yf7YSD9zzrFv+XhRuh+ 3VcMMqfD16Fryr8sK8ihgAM5ZVaacA5UknxOPBcB1Jl8e26R6g0hNey18PEwk6W87svfMygy75gG OZGyno0XD1Tk7cSOZhlG4Rmh49Cq4qOPQQdG4Azf5Iddq0XrIS1JsZP4KKD1q+SFyZtEe5qGO5k4 gQnq28+KjFSKO+nnfWMk99njhaedB8s+QQ+XaI0AAAAAAAA= --Apple-Mail-9-215763525-- From Internet-Drafts@ietf.org Tue Nov 16 04:45:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89173A6D8C; Tue, 16 Nov 2010 04:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB++JHABYwVQ; Tue, 16 Nov 2010 04:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9F43A6C83; Tue, 16 Nov 2010 04:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101116124501.2400.2831.idtracker@localhost> Date: Tue, 16 Nov 2010 04:45:01 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-timestamps-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 12:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Reducing the TIME-WAIT state using TCP timestamps Author(s) : F. Gont Filename : draft-ietf-tcpm-tcp-timestamps-01.txt Pages : 11 Date : 2010-11-16 This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-timestamps-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-timestamps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-16043345.I-D@ietf.org> --NextPart-- From ilpo.jarvinen@helsinki.fi Tue Nov 16 06:00:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA903A69F3 for ; Tue, 16 Nov 2010 06:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9ZeISwuC1K4 for ; Tue, 16 Nov 2010 06:00:38 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5283A688E for ; Tue, 16 Nov 2010 06:00:36 -0800 (PST) Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 16 Nov 2010 16:01:19 +0200 id 00093D18.4CE28EAF.00007A89 Date: Tue, 16 Nov 2010 16:01:19 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi To: Fred Baker In-Reply-To: Message-ID: References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tcpm , tmrg Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 14:00:39 -0000 On Tue, 16 Nov 2010, Fred Baker wrote: > On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > > > I wonder what factors will argue that the initial quantum can't be changed? > > Someone has argued in the past IW10 effectively "disable CC algorithm". > > But haven't we already done that years ago when moving up IW from 1 to 3 if > > one insisted then that the initial quantum must be 1? > > Actually, no. I may be the person who said that this effectively > disables congestion control in the average case; my reason for saying > that is that per what little data I have, the average TCP transfer is on > the order of 15K bytes, which is about ten 1460 byte segments. It only "disables" it if there was no congestion to control in the first place. > Now, the median is much smaller - on the order of two or three data > segments each direction, which is where you get your comment. But the > fact that browsers, Bittorrent, and other applications open multiple > sessions simultaneously argues that a given endpoint having multiple > packets in flight simultaneously doesn't hurt, and research done at the > time by Mark Allman and others showed that IW=2..4 wasn't a problem and > did in fact reduce the median session to a single RTT for data. But the > median session doesn't create a congestion problem. > > The question I have been asking is how IW=10 affects parallel sessions > on relatively low speed links. Could you on your behalf answer how does IW=3 affect parallel sessions on the same kind of environment? ...I've done research on this (and Jerry has too) and I know that the answer is not an intuitive one. Then we changed to IW10 in the same environment and observe no (consistent) change. The results are driven by problems already with IW3 so IW10 won't make it any worse or the effect is just too small to be measured among the other troubles that happen. > My sense is that the sudden arrival of > O(15K) bytes at a 56 KBPS line, which is to say the insertion of a tad > over two seconds delay in all competing sessions plus an increase in > their probability of loss, is likely to cause them all to be disrupted. Again, the existing research points to exactly _opposite_ thing to happen, ie., IW10 hurts mostly itself, not the others! We'll never get anywhere if these same "fuzzy feelings" (like Mark put it) just get repeated and the existing _evidence_ overlooked. Jerry has tested a case that is very close to what you're specifying and his results don't agree what you think would happen. My results also confirm Jerry's observations for the low end links though in my case it was a bit higher bw already (160kbps). I personally don't anymore believe we will find a convincing case against IW10 from the very lowest end of links, afaict, it doesn't help but doesn't really hurt significantly either. ...I understand this is quite non-intuitive claim but it is what the performed studies seem to point out (and I expect new guys every now and then to jump in with this same argument if IW10 is to proceed). ...I'm more concerned about mid-ranged links where it could be possible (at least in theory if AQM in use) to have both TCP and low-latency requiring audio/video in parallel. > You told me verbally that in your tests it is net beneficial to the > parallel sessions, but in thought experiments I'm not sure how that can > be true; I'd be fascinated to see the data that shows that competing > voice/video sees no frame loss or induced noise, that competing file > transfers slow down but do not see redundant retransmissions, and so on. In this I somewhat agree with you. The delay increase was confirmed by my measurements, however, I think you also end up too cleverly mixing IW3+IW10 and voice/video cases here. It seems that even if delay increases and as a result voice/video could possible experience more losses (I'm yet to confirm that losses actually happen as I didn't have actual CBR traffic running), IW3 TCP in mixed case is not affected in a similar way. Instead, IW3 TCP might actually get a boost in its performance against IW10 because also IW10 TCP needs to respond to the congestion it caused. Also, regardless of IW, TCP is well capable of leaving audio/video in ruins as it will fill all buffers you give to it, so I find this exercise quite pointless anyway unless there is some form of AQM in use. > So, IW=2..4 demonstrably works pretty well everywhere, but IW=10 seems > to me only sensible on MPBS and GBPS, not KBPS, scale links. IW3 doesn't work that well if you have parallel connections over 56kbps but since the latencies are high anyway, you just won't notice that. -- i. From fred@cisco.com Tue Nov 16 06:09:10 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C5C3A69F3 for ; Tue, 16 Nov 2010 06:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.18 X-Spam-Level: X-Spam-Status: No, score=-110.18 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rR3qrv+SAfV for ; Tue, 16 Nov 2010 06:09:10 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 18E793A688E for ; Tue, 16 Nov 2010 06:09:10 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMMf4kxAaMHG/2dsb2JhbACiX3GjPZslhUsEhFiGAIMM X-IronPort-AV: E=Sophos;i="4.59,206,1288569600"; d="scan'208";a="620931565" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 16 Nov 2010 14:09:52 +0000 Received: from Freds-Computer.local (hkidc-vpn-client-235-169.cisco.com [10.75.235.169]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAGE9k3J024471; Tue, 16 Nov 2010 14:09:51 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 16 Nov 2010 22:09:51 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 16 Nov 2010 22:09:51 +0900 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Tue, 16 Nov 2010 22:09:38 +0800 Message-Id: References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> To: =?iso-8859-1?Q?=22Ilpo_J=E4rvinen=22?= X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm , tmrg Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 14:09:11 -0000 On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote: > On Tue, 16 Nov 2010, Fred Baker wrote: >=20 >> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: >>=20 >>> I wonder what factors will argue that the initial quantum can't be = changed? >>> Someone has argued in the past IW10 effectively "disable CC = algorithm". >>> But haven't we already done that years ago when moving up IW from 1 = to 3 if >>> one insisted then that the initial quantum must be 1? >>=20 >> Actually, no. I may be the person who said that this effectively=20 >> disables congestion control in the average case; my reason for saying=20= >> that is that per what little data I have, the average TCP transfer is = on=20 >> the order of 15K bytes, which is about ten 1460 byte segments.=20 >=20 > It only "disables" it if there was no congestion to control in the = first=20 > place. How do you turn off something that's not on? I refer to this as in the average case turning off congestion control = because the transmission requires ten data packets and they all get sent = in a single burst. There is no congestion control, with IW=3D10, in the = case of the average-sized (which is actually gar above the median-sized) = file transfer. > Could you on your behalf answer how does IW=3D3 affect parallel = sessions on=20 > the same kind of environment? ...I've done research on this (and Jerry = has=20 > too) and I know that the answer is not an intuitive one. Then we = changed=20 > to IW10 in the same environment and observe no (consistent) change. = The=20 > results are driven by problems already with IW3 so IW10 won't make it = any=20 > worse or the effect is just too small to be measured among the other=20= > troubles that happen. That may be true. I have asked to see data describing the impact. I = haven't seen the data. Maybe I missed something?= From rs@netapp.com Tue Nov 16 08:41:11 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B68D3A6DAC for ; Tue, 16 Nov 2010 08:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.395 X-Spam-Level: X-Spam-Status: No, score=-10.395 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZPMLAIcc6ci for ; Tue, 16 Nov 2010 08:41:10 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 320D33A6CAF for ; Tue, 16 Nov 2010 08:41:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,206,1288594800"; d="scan'208";a="226414235" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 16 Nov 2010 08:41:53 -0800 Received: from amsrsexc1-prd.hq.netapp.com (amsrsexc1-prd.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oAGGfq59013276; Tue, 16 Nov 2010 08:41:52 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Nov 2010 17:41:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Nov 2010 16:41:50 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] [Tmrg] Increasing the Initial Window - Notes Thread-Index: AcuFl/R9FHH+teIJTDOD4FwQKyqpcgAE27wQ References: <20101110152857.GA5094@hell><804D02FE-39AF-4437-BB15-C2247842E120@mac.com><20101110170017.GF5094@hell><97C75EA8-6CC7-444C-A19D-370148B81918@mac.com><20101110174056.GH5094@hell> From: "Scheffenegger, Richard" To: "Fred Baker" , =?iso-8859-1?Q?=22Ilpo_J=E4rvinen=22?= X-OriginalArrivalTime: 16 Nov 2010 16:41:51.0914 (UTC) FILETIME=[2BB268A0:01CB85AD] Cc: tcpm , tmrg Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 16:41:11 -0000 Group, Just one additional data point: Obviously, there are already = applications in the wild, that use persistent connections and disable = the slow-start-restart mechanism on these sessions. The expectations of = the programmers making use of these socket options is to reduce the = latency for their appliaction... In effect, these Apps seem use IW=3D44 = (and hurting themselves more than anybody else). See "Profiling Network Performance in Multi-Tier Data Center = Applications", Section 6.1, "cwnd failing to prevent sudden bursts", = http://www.cs.princeton.edu/~jrex/papers/snap10.pdf IMHO this is evidence that some action in this space is absolutely = needed (even if it is "only" strong advice to apps programmers), or = there will be even more proliferation of clumsy workarounds that are = even less well understood and investigated than IW10 already is. Keeping = IW3 "forever" may be more problematic than addressing emerging = application needs with well-tested transport-layer approaches... Richard Scheffenegger > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Dienstag, 16. November 2010 15:10 > To: "Ilpo J=E4rvinen" > Cc: tcpm; tmrg > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >=20 >=20 > On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote: >=20 > > On Tue, 16 Nov 2010, Fred Baker wrote: > >=20 > >> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > >>=20 > >>> I wonder what factors will argue that the initial quantum=20 > can't be changed? > >>> Someone has argued in the past IW10 effectively "disable=20 > CC algorithm". > >>> But haven't we already done that years ago when moving up=20 > IW from 1=20 > >>> to 3 if one insisted then that the initial quantum must be 1? > >>=20 > >> Actually, no. I may be the person who said that this effectively=20 > >> disables congestion control in the average case; my reason=20 > for saying=20 > >> that is that per what little data I have, the average TCP=20 > transfer is=20 > >> on the order of 15K bytes, which is about ten 1460 byte segments. > >=20 > > It only "disables" it if there was no congestion to control in the=20 > > first place. >=20 > How do you turn off something that's not on? >=20 > I refer to this as in the average case turning off congestion=20 > control because the transmission requires ten data packets=20 > and they all get sent in a single burst. There is no=20 > congestion control, with IW=3D10, in the case of the=20 > average-sized (which is actually gar above the median-sized)=20 > file transfer. >=20 > > Could you on your behalf answer how does IW=3D3 affect=20 > parallel sessions=20 > > on the same kind of environment? ...I've done research on this (and=20 > > Jerry has > > too) and I know that the answer is not an intuitive one. Then we=20 > > changed to IW10 in the same environment and observe no (consistent)=20 > > change. The results are driven by problems already with IW3 so IW10=20 > > won't make it any worse or the effect is just too small to=20 > be measured=20 > > among the other troubles that happen. >=20 > That may be true. I have asked to see data describing the=20 > impact. I haven't seen the data. Maybe I missed something? > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From idris.rai@gmail.com Tue Nov 16 09:35:41 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4C73A6CA6 for ; Tue, 16 Nov 2010 09:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbwG4hlb+QpY for ; Tue, 16 Nov 2010 09:35:39 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id DE5A63A6DC0 for ; Tue, 16 Nov 2010 09:35:38 -0800 (PST) Received: by wyb29 with SMTP id 29so949877wyb.31 for ; Tue, 16 Nov 2010 09:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:references:from :content-transfer-encoding:content-type:in-reply-to:message-id:date :cc:to:mime-version:x-mailer; bh=D6NwSABLqE+2Eo55UCB6XAVnQSW613HP1Mg+3oOsahM=; b=BmHO+QtovYefYIi/ypRCgaQSL6VaYQXsl4mWAaDuq0AGkY+86+Zk/l26qUdfrQ4Tke WB6XdrNxAU5eYsiwkJq6tqQVTngvKUUWYVwWFPuPblCmFpWJDz59dPvrsrjy9hVaZX08 +ygIjXOr8xg2XlQlCCXM5EFU+zmZXZCQlTomg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:references:from:content-transfer-encoding:content-type :in-reply-to:message-id:date:cc:to:mime-version:x-mailer; b=v+6ihGJhcm1j9kcYbn9iTIGV25ftRW+Uw5pZ8HNFYHYR3JU9+lMWnrN5kWzbC0cvwm kxeo5Ad/+0/sIaKMIhX2DAqoiW3W94VGkrh6b6rAXZV+vt7mRtV2UT1edTfy0RImvqql GrDGbvRaKFzNPX+qbHYash9SRHgd88d7SG64w= Received: by 10.216.25.9 with SMTP id y9mr434153wey.83.1289928980701; Tue, 16 Nov 2010 09:36:20 -0800 (PST) Received: from [10.205.165.64] ([41.202.225.146]) by mx.google.com with ESMTPS id l51sm690404wer.26.2010.11.16.09.36.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Nov 2010 09:36:19 -0800 (PST) References: From: Idris Rai Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: <0A03BFFA-9C68-44F3-8DAA-0A1DFD36A9BB@gmail.com> Date: Tue, 16 Nov 2010 20:18:36 +0300 Cc: "tcpm@ietf.org" To: "tcpm@ietf.org" Mime-Version: 1.0 (iPhone Mail 8A400) X-Mailer: iPhone Mail (8A400) Subject: Re: [tcpm] tcpm Digest, Vol 79, Issue 24 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 17:35:41 -0000 The results presented by Jerry in Beijing for IW10 show an improved response= time and increase in loss rate at low speed links -- but the buffer used w= as too large (about double the DBP). Can we get the same results at lower, more acceptable buffer sizes??. Not in= tuitive at all to me. Perhaps this is one experiment we need to do next=20 =20 Idris Sent from my iPhone On 16 Nov 2010, at 19:41, tcpm-request@ietf.org wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to=20 >=20 > https://www.ietf.org/mailman/listinfo/tcpm >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send tcpm mailing list submissions to > tcpm@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/tcpm > or, via email, send a message with subject or body 'help' to > tcpm-request@ietf.org >=20 > You can reach the person managing the list at > tcpm-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tcpm digest..." >=20 >=20 > Today's Topics: >=20 > 1. Re: WG status update (Lars Eggert) > 2. I-D Action:draft-ietf-tcpm-tcp-timestamps-01.txt > (Internet-Drafts@ietf.org) > 3. Re: [Tmrg] Increasing the Initial Window - Notes > ( Ilpo J?rvinen ) > 4. Re: [Tmrg] Increasing the Initial Window - Notes (Fred Baker) > 5. Re: [Tmrg] Increasing the Initial Window - Notes > (Scheffenegger, Richard) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Tue, 16 Nov 2010 13:48:12 +0200 > From: Lars Eggert > Subject: Re: [tcpm] WG status update > To: L.Wood@surrey.ac.uk > Cc: tcpm@ietf.org > Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" >=20 > On 2010-11-15, at 17:39, L.Wood@surrey.ac.uk wrote: >>> But since we are doing MPTCP, I simply don't see the point of specifying= a >>> subset of it in a way that is incompatible. >>=20 >> Lars, are you speaking as an individual contributor or as Area director h= ere? >=20 > Individual. (Thanks for reminding me to make this clear.) >=20 > Lars > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 4367 bytes > Desc: not available > Url : >=20 > ------------------------------ >=20 > Message: 2 > Date: Tue, 16 Nov 2010 04:45:01 -0800 > From: Internet-Drafts@ietf.org > Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-timestamps-01.txt > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Message-ID: <20101116124501.2400.2831.idtracker@localhost> > Content-Type: text/plain; charset=3D"us-ascii" >=20 >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Tue, 16 Nov 2010 16:01:19 +0200 (EET) > From: " Ilpo J?rvinen " > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > To: Fred Baker > Cc: tcpm , tmrg > Message-ID: > > Content-Type: text/plain; charset=3Dus-ascii >=20 > On Tue, 16 Nov 2010, Fred Baker wrote: >=20 >> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: >>=20 >>> I wonder what factors will argue that the initial quantum can't be chang= ed? >>> Someone has argued in the past IW10 effectively "disable CC algorithm". >>> But haven't we already done that years ago when moving up IW from 1 to 3= if >>> one insisted then that the initial quantum must be 1? >>=20 >> Actually, no. I may be the person who said that this effectively=20 >> disables congestion control in the average case; my reason for saying=20 >> that is that per what little data I have, the average TCP transfer is on=20= >> the order of 15K bytes, which is about ten 1460 byte segments.=20 >=20 > It only "disables" it if there was no congestion to control in the first=20= > place. >=20 >> Now, the median is much smaller - on the order of two or three data=20 >> segments each direction, which is where you get your comment. But the=20 >> fact that browsers, Bittorrent, and other applications open multiple=20 >> sessions simultaneously argues that a given endpoint having multiple=20 >> packets in flight simultaneously doesn't hurt, and research done at the=20= >> time by Mark Allman and others showed that IW=3D2..4 wasn't a problem and= =20 >> did in fact reduce the median session to a single RTT for data. But the=20= >> median session doesn't create a congestion problem. >>=20 >> The question I have been asking is how IW=3D10 affects parallel sessions=20= >> on relatively low speed links. >=20 > Could you on your behalf answer how does IW=3D3 affect parallel sessions o= n=20 > the same kind of environment? ...I've done research on this (and Jerry has= =20 > too) and I know that the answer is not an intuitive one. Then we changed=20= > to IW10 in the same environment and observe no (consistent) change. The=20= > results are driven by problems already with IW3 so IW10 won't make it any=20= > worse or the effect is just too small to be measured among the other=20 > troubles that happen. >=20 >> My sense is that the sudden arrival of=20 >> O(15K) bytes at a 56 KBPS line, which is to say the insertion of a tad=20= >> over two seconds delay in all competing sessions plus an increase in=20 >> their probability of loss, is likely to cause them all to be disrupted.=20= >=20 > Again, the existing research points to exactly _opposite_ thing to=20 > happen, ie., IW10 hurts mostly itself, not the others! We'll never get=20 > anywhere if these same "fuzzy feelings" (like Mark put it) just get=20 > repeated and the existing _evidence_ overlooked. Jerry has tested a case=20= > that is very close to what you're specifying and his results don't agree=20= > what you think would happen. My results also confirm Jerry's observations=20= > for the low end links though in my case it was a bit higher bw already=20 > (160kbps). >=20 > I personally don't anymore believe we will find a convincing case against=20= > IW10 from the very lowest end of links, afaict, it doesn't help but=20 > doesn't really hurt significantly either. ...I understand this is quite=20= > non-intuitive claim but it is what the performed studies seem to point=20 > out (and I expect new guys every now and then to jump in with this same=20= > argument if IW10 is to proceed). ...I'm more concerned about mid-ranged=20= > links where it could be possible (at least in theory if AQM in use) to=20 > have both TCP and low-latency requiring audio/video in parallel.=20 >=20 >> You told me verbally that in your tests it is net beneficial to the=20 >> parallel sessions, but in thought experiments I'm not sure how that can=20= >> be true; I'd be fascinated to see the data that shows that competing=20 >> voice/video sees no frame loss or induced noise, that competing file=20 >> transfers slow down but do not see redundant retransmissions, and so on. >=20 > In this I somewhat agree with you. The delay increase was confirmed by my=20= > measurements, however, I think you also end up too cleverly mixing=20 > IW3+IW10 and voice/video cases here. It seems that even if delay increases= =20 > and as a result voice/video could possible experience more losses (I'm yet= =20 > to confirm that losses actually happen as I didn't have actual CBR traffic= =20 > running), IW3 TCP in mixed case is not affected in a similar way. Instead,= =20 > IW3 TCP might actually get a boost in its performance against IW10 because= =20 > also IW10 TCP needs to respond to the congestion it caused. >=20 > Also, regardless of IW, TCP is well capable of leaving audio/video in=20 > ruins as it will fill all buffers you give to it, so I find this exercise=20= > quite pointless anyway unless there is some form of AQM in use. >=20 >> So, IW=3D2..4 demonstrably works pretty well everywhere, but IW=3D10 seem= s=20 >> to me only sensible on MPBS and GBPS, not KBPS, scale links.=20 >=20 > IW3 doesn't work that well if you have parallel connections over 56kbps=20= > but since the latencies are high anyway, you just won't notice that. >=20 >=20 > --=20 > i. >=20 >=20 > ------------------------------ >=20 > Message: 4 > Date: Tue, 16 Nov 2010 22:09:38 +0800 > From: Fred Baker > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > To: "Ilpo J?rvinen" > Cc: tcpm , tmrg > Message-ID: > Content-Type: text/plain; charset=3Diso-8859-1 >=20 >=20 > On Nov 16, 2010, at 10:01 PM, Ilpo J?rvinen wrote: >=20 >> On Tue, 16 Nov 2010, Fred Baker wrote: >>=20 >>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: >>>=20 >>>> I wonder what factors will argue that the initial quantum can't be chan= ged? >>>> Someone has argued in the past IW10 effectively "disable CC algorithm".= >>>> But haven't we already done that years ago when moving up IW from 1 to 3= if >>>> one insisted then that the initial quantum must be 1? >>>=20 >>> Actually, no. I may be the person who said that this effectively=20 >>> disables congestion control in the average case; my reason for saying=20= >>> that is that per what little data I have, the average TCP transfer is on= =20 >>> the order of 15K bytes, which is about ten 1460 byte segments.=20 >>=20 >> It only "disables" it if there was no congestion to control in the first=20= >> place. >=20 > How do you turn off something that's not on? >=20 > I refer to this as in the average case turning off congestion control beca= use the transmission requires ten data packets and they all get sent in a si= ngle burst. There is no congestion control, with IW=3D10, in the case of the= average-sized (which is actually gar above the median-sized) file transfer.= >=20 >> Could you on your behalf answer how does IW=3D3 affect parallel sessions o= n=20 >> the same kind of environment? ...I've done research on this (and Jerry ha= s=20 >> too) and I know that the answer is not an intuitive one. Then we changed=20= >> to IW10 in the same environment and observe no (consistent) change. The=20= >> results are driven by problems already with IW3 so IW10 won't make it any= =20 >> worse or the effect is just too small to be measured among the other=20 >> troubles that happen. >=20 > That may be true. I have asked to see data describing the impact. I haven'= t seen the data. Maybe I missed something? >=20 > ------------------------------ >=20 > Message: 5 > Date: Tue, 16 Nov 2010 16:41:50 -0000 > From: "Scheffenegger, Richard" > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > To: "Fred Baker" , "Ilpo J?rvinen" > > Cc: tcpm , tmrg > Message-ID: > <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 >=20 > Group, >=20 > Just one additional data point: Obviously, there are already applications i= n the wild, that use persistent connections and disable the slow-start-resta= rt mechanism on these sessions. The expectations of the programmers making u= se of these socket options is to reduce the latency for their appliaction...= In effect, these Apps seem use IW=3D44 (and hurting themselves more than an= ybody else). >=20 > See "Profiling Network Performance in Multi-Tier Data Center Applications"= , Section 6.1, "cwnd failing to prevent sudden bursts", http://www.cs.prince= ton.edu/~jrex/papers/snap10.pdf >=20 >=20 > IMHO this is evidence that some action in this space is absolutely needed (= even if it is "only" strong advice to apps programmers), or there will be ev= en more proliferation of clumsy workarounds that are even less well understo= od and investigated than IW10 already is. Keeping IW3 "forever" may be more p= roblematic than addressing emerging application needs with well-tested trans= port-layer approaches... >=20 >=20 > Richard Scheffenegger >=20 >=20 >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com]=20 >> Sent: Dienstag, 16. November 2010 15:10 >> To: "Ilpo J?rvinen" >> Cc: tcpm; tmrg >> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >>=20 >>=20 >> On Nov 16, 2010, at 10:01 PM, Ilpo J?rvinen wrote: >>=20 >>> On Tue, 16 Nov 2010, Fred Baker wrote: >>>=20 >>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: >>>>=20 >>>>> I wonder what factors will argue that the initial quantum=20 >> can't be changed? >>>>> Someone has argued in the past IW10 effectively "disable=20 >> CC algorithm". >>>>> But haven't we already done that years ago when moving up=20 >> IW from 1=20 >>>>> to 3 if one insisted then that the initial quantum must be 1? >>>>=20 >>>> Actually, no. I may be the person who said that this effectively=20 >>>> disables congestion control in the average case; my reason=20 >> for saying=20 >>>> that is that per what little data I have, the average TCP=20 >> transfer is=20 >>>> on the order of 15K bytes, which is about ten 1460 byte segments. >>>=20 >>> It only "disables" it if there was no congestion to control in the=20 >>> first place. >>=20 >> How do you turn off something that's not on? >>=20 >> I refer to this as in the average case turning off congestion=20 >> control because the transmission requires ten data packets=20 >> and they all get sent in a single burst. There is no=20 >> congestion control, with IW=3D10, in the case of the=20 >> average-sized (which is actually gar above the median-sized)=20 >> file transfer. >>=20 >>> Could you on your behalf answer how does IW=3D3 affect=20 >> parallel sessions=20 >>> on the same kind of environment? ...I've done research on this (and=20 >>> Jerry has >>> too) and I know that the answer is not an intuitive one. Then we=20 >>> changed to IW10 in the same environment and observe no (consistent)=20 >>> change. The results are driven by problems already with IW3 so IW10=20 >>> won't make it any worse or the effect is just too small to=20 >> be measured=20 >>> among the other troubles that happen. >>=20 >> That may be true. I have asked to see data describing the=20 >> impact. I haven't seen the data. Maybe I missed something? >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 > End of tcpm Digest, Vol 79, Issue 24 > ************************************ From muraris@microsoft.com Tue Nov 16 09:39:24 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6753A6CDE for ; Tue, 16 Nov 2010 09:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-idWqRfoUUZ for ; Tue, 16 Nov 2010 09:39:23 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id C20883A6CAF for ; Tue, 16 Nov 2010 09:39:23 -0800 (PST) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 16 Nov 2010 09:40:07 -0800 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.54]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi id 14.01.0255.003; Tue, 16 Nov 2010 09:39:59 -0800 From: Murari Sridharan To: "Anantha Ramaiah (ananth)" , Joe Touch , "Scheffenegger, Richard" Thread-Topic: [tcpm] dctcp Thread-Index: AcuBltbo7I+MgezEQZ2g0gAvp3gRgQBUTjsAACtPzoAAh6NokA== Date: Tue, 16 Nov 2010 17:39:54 +0000 Message-ID: References: <5FDC413D5FA246468C200652D63E627A0B65CA86@LDCMVEXC1-PRD.hq.netapp.com> <4CDD9E20.8030308@isi.edu> <0C53DCFB700D144284A584F54711EC580B2CD428@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580B2CD428@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm , Andrew McGregor Subject: Re: [tcpm] dctcp X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 17:39:24 -0000 I agree. We believe that DCTCP has certain properties that are generally ap= plicable and personally I see DCTCP as an enabler for ECN even if in privat= e or enterprise networks as it makes the switch side configuration rather t= rivial. I also think the ideas in the paper have broad applicability which = is the reason why I wanted to present this to TCPM. Our goal has been to de= sign DCTCP such that without ECN marks it behaves exactly like New Reno or = whatever congestion control it is built on. In our case we built it as a mo= dification to New Reno, I therefore think it is very much in scope for disc= ussion. Whether it is in TCPM or ICCRG (treating DCTCP as an alternative co= ngestion control algorithm) is for the WG to decide.=20 Remember if you are in a multi-tenant datacenter, algorithms like DCTCP are= most effective especially at the switches only if all the senders are conf= ormant to DCTCP, in that vein it is worth discussing at IETF.=20 If the WG and the chairs agree I intend to submit an ID explaining the chan= ges. I propose two alternatives. One way to think of this is as a modificat= ion to the ECN RFC, to say that instead of halving in response to the *pres= ence* of congestion; react to the *extent* of congestion by averaging the E= CN marks which is what DCTCP does. Personally I believe this is a better ap= proach however the alternative option is to submit DCTCP as a new congestio= n control algorithm. Thoughts? Thanks Murari=20 -----Original Message----- From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com]=20 Sent: Saturday, November 13, 2010 8:46 AM To: Joe Touch; Scheffenegger, Richard Cc: Murari Sridharan; tcpm; Andrew McGregor Subject: RE: [tcpm] dctcp Well, My thoughts here are :- - If someone is using a protocol defined by IETF, then it is desirable to a= bide by the standards, irrespective of the type of network.=20 - interoperability across different devices (may be coming from different v= endors), using the same protocol, is one of the reason you need standards!= =20 - From an implementation perspective you don't want "private TCP" and "pub= lic TCP" in the same stack since the same stack needs to cater to TCP conne= ctions from *both* private and public networks! - The problems and the solutions which are posed by the data center environ= ments may not be unique. The question to ask is : "what is the problem and = whether the problems and solutions would have a generic applicability. =20 - Also how do you draw a boundary as to a what is private network and what = isn't ? Why is data center environment considered a "private network" ? IMO, it is an issue that can be well addressed (if there is a need) by the = IETF, if changes are being planned with TCP protocol, yes TCPM is the righ= t place for such efforts. $0.02, -Anantha -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe= Touch Sent: Friday, November 12, 2010 12:06 PM To: Scheffenegger, Richard Cc: Murari Sridharan; tcpm; Andrew McGregor Subject: Re: [tcpm] dctcp On 11/11/2010 3:51 AM, Scheffenegger, Richard wrote: ... > Reading the TSVAREA material, it was also pointed out (storage teaser - > NFSv4, iSCSI) that TCPM may need to look closer at datacenter=20 > environments rather soon. Tuning TCP for private networks (i.e., not using the Internet, or competing= with Internet flows) seems out of scope for TCPM. It might not even be relevant elsewhere in the IETF, except as an issue of = common interest. Protocols running over private networks don't need to adhe= re to standards. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From muraris@microsoft.com Tue Nov 16 11:08:07 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3983A6DE3 for ; Tue, 16 Nov 2010 11:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6us-H0evATsu for ; Tue, 16 Nov 2010 11:08:05 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 205E13A6DD1 for ; Tue, 16 Nov 2010 11:08:05 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 16 Nov 2010 11:08:49 -0800 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.54]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0255.003; Tue, 16 Nov 2010 11:08:48 -0800 From: Murari Sridharan To: Idris Rai , "tcpm@ietf.org" Thread-Topic: [tcpm] tcpm Digest, Vol 79, Issue 24 Thread-Index: AQHLhbTuCBU4RVfo60qCWQnCC23jPpN0d6GQ Date: Tue, 16 Nov 2010 19:08:47 +0000 Message-ID: References: <0A03BFFA-9C68-44F3-8DAA-0A1DFD36A9BB@gmail.com> In-Reply-To: <0A03BFFA-9C68-44F3-8DAA-0A1DFD36A9BB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] tcpm Digest, Vol 79, Issue 24 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 19:08:07 -0000 The buffers in these low speed modems are in fact quite large as we have se= en in Ledbat. In my home DSL I can build up latencies into the seconds by d= oing sustained uploads. There is a significant amount of buffering much lar= ger than BDP.=20 Thanks Murari=20 -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Idr= is Rai Sent: Tuesday, November 16, 2010 9:19 AM To: tcpm@ietf.org Cc: tcpm@ietf.org Subject: Re: [tcpm] tcpm Digest, Vol 79, Issue 24 The results presented by Jerry in Beijing for IW10 show an improved respons= e time and increase in loss rate at low speed links -- but the buffer use= d was too large (about double the DBP). Can we get the same results at lower, more acceptable buffer sizes??. Not i= ntuitive at all to me. Perhaps this is one experiment we need to do next=20 =20 Idris Sent from my iPhone On 16 Nov 2010, at 19:41, tcpm-request@ietf.org wrote: > If you have received this digest without all the individual message=20 > attachments you will need to update your digest options in your list=20 > subscription. To do so, go to >=20 > https://www.ietf.org/mailman/listinfo/tcpm >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get=20 > MIME or Plain Text Digests?" to MIME. You can set this option=20 > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send tcpm mailing list submissions to > tcpm@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/tcpm > or, via email, send a message with subject or body 'help' to > tcpm-request@ietf.org >=20 > You can reach the person managing the list at > tcpm-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific=20 > than "Re: Contents of tcpm digest..." >=20 >=20 > Today's Topics: >=20 > 1. Re: WG status update (Lars Eggert) > 2. I-D Action:draft-ietf-tcpm-tcp-timestamps-01.txt > (Internet-Drafts@ietf.org) > 3. Re: [Tmrg] Increasing the Initial Window - Notes > ( Ilpo J?rvinen ) > 4. Re: [Tmrg] Increasing the Initial Window - Notes (Fred Baker) > 5. Re: [Tmrg] Increasing the Initial Window - Notes > (Scheffenegger, Richard) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Tue, 16 Nov 2010 13:48:12 +0200 > From: Lars Eggert > Subject: Re: [tcpm] WG status update > To: L.Wood@surrey.ac.uk > Cc: tcpm@ietf.org > Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" >=20 > On 2010-11-15, at 17:39, L.Wood@surrey.ac.uk wrote: >>> But since we are doing MPTCP, I simply don't see the point of=20 >>> specifying a subset of it in a way that is incompatible. >>=20 >> Lars, are you speaking as an individual contributor or as Area director = here? >=20 > Individual. (Thanks for reminding me to make this clear.) >=20 > Lars > -------------- next part -------------- A non-text attachment was=20 > scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 4367 bytes > Desc: not available > Url :=20 > cb/attachment.p7s> >=20 > ------------------------------ >=20 > Message: 2 > Date: Tue, 16 Nov 2010 04:45:01 -0800 > From: Internet-Drafts@ietf.org > Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-timestamps-01.txt > To: i-d-announce@ietf.org > Cc: tcpm@ietf.org > Message-ID: <20101116124501.2400.2831.idtracker@localhost> > Content-Type: text/plain; charset=3D"us-ascii" >=20 >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Tue, 16 Nov 2010 16:01:19 +0200 (EET) > From: " Ilpo J?rvinen " > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > To: Fred Baker > Cc: tcpm , tmrg > Message-ID: > > Content-Type: text/plain; charset=3Dus-ascii >=20 > On Tue, 16 Nov 2010, Fred Baker wrote: >=20 >> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: >>=20 >>> I wonder what factors will argue that the initial quantum can't be chan= ged? >>> Someone has argued in the past IW10 effectively "disable CC algorithm". >>> But haven't we already done that years ago when moving up IW from 1=20 >>> to 3 if one insisted then that the initial quantum must be 1? >>=20 >> Actually, no. I may be the person who said that this effectively=20 >> disables congestion control in the average case; my reason for saying=20 >> that is that per what little data I have, the average TCP transfer is=20 >> on the order of 15K bytes, which is about ten 1460 byte segments. >=20 > It only "disables" it if there was no congestion to control in the=20 > first place. >=20 >> Now, the median is much smaller - on the order of two or three data=20 >> segments each direction, which is where you get your comment. But the=20 >> fact that browsers, Bittorrent, and other applications open multiple=20 >> sessions simultaneously argues that a given endpoint having multiple=20 >> packets in flight simultaneously doesn't hurt, and research done at=20 >> the time by Mark Allman and others showed that IW=3D2..4 wasn't a=20 >> problem and did in fact reduce the median session to a single RTT for=20 >> data. But the median session doesn't create a congestion problem. >>=20 >> The question I have been asking is how IW=3D10 affects parallel=20 >> sessions on relatively low speed links. >=20 > Could you on your behalf answer how does IW=3D3 affect parallel sessions= =20 > on the same kind of environment? ...I've done research on this (and=20 > Jerry has > too) and I know that the answer is not an intuitive one. Then we=20 > changed to IW10 in the same environment and observe no (consistent)=20 > change. The results are driven by problems already with IW3 so IW10=20 > won't make it any worse or the effect is just too small to be measured=20 > among the other troubles that happen. >=20 >> My sense is that the sudden arrival of >> O(15K) bytes at a 56 KBPS line, which is to say the insertion of a=20 >> tad over two seconds delay in all competing sessions plus an increase=20 >> in their probability of loss, is likely to cause them all to be disrupte= d. >=20 > Again, the existing research points to exactly _opposite_ thing to=20 > happen, ie., IW10 hurts mostly itself, not the others! We'll never get=20 > anywhere if these same "fuzzy feelings" (like Mark put it) just get=20 > repeated and the existing _evidence_ overlooked. Jerry has tested a=20 > case that is very close to what you're specifying and his results=20 > don't agree what you think would happen. My results also confirm=20 > Jerry's observations for the low end links though in my case it was a=20 > bit higher bw already (160kbps). >=20 > I personally don't anymore believe we will find a convincing case=20 > against > IW10 from the very lowest end of links, afaict, it doesn't help but=20 > doesn't really hurt significantly either. ...I understand this is=20 > quite non-intuitive claim but it is what the performed studies seem to=20 > point out (and I expect new guys every now and then to jump in with=20 > this same argument if IW10 is to proceed). ...I'm more concerned about=20 > mid-ranged links where it could be possible (at least in theory if AQM=20 > in use) to have both TCP and low-latency requiring audio/video in paralle= l. >=20 >> You told me verbally that in your tests it is net beneficial to the=20 >> parallel sessions, but in thought experiments I'm not sure how that=20 >> can be true; I'd be fascinated to see the data that shows that=20 >> competing voice/video sees no frame loss or induced noise, that=20 >> competing file transfers slow down but do not see redundant retransmissi= ons, and so on. >=20 > In this I somewhat agree with you. The delay increase was confirmed by=20 > my measurements, however, I think you also end up too cleverly mixing > IW3+IW10 and voice/video cases here. It seems that even if delay=20 > IW3+increases > and as a result voice/video could possible experience more losses (I'm=20 > yet to confirm that losses actually happen as I didn't have actual CBR=20 > traffic running), IW3 TCP in mixed case is not affected in a similar=20 > way. Instead, > IW3 TCP might actually get a boost in its performance against IW10=20 > because also IW10 TCP needs to respond to the congestion it caused. >=20 > Also, regardless of IW, TCP is well capable of leaving audio/video in=20 > ruins as it will fill all buffers you give to it, so I find this=20 > exercise quite pointless anyway unless there is some form of AQM in use. >=20 >> So, IW=3D2..4 demonstrably works pretty well everywhere, but IW=3D10=20 >> seems to me only sensible on MPBS and GBPS, not KBPS, scale links. >=20 > IW3 doesn't work that well if you have parallel connections over=20 > 56kbps but since the latencies are high anyway, you just won't notice tha= t. >=20 >=20 > -- > i. >=20 >=20 > ------------------------------ >=20 > Message: 4 > Date: Tue, 16 Nov 2010 22:09:38 +0800 > From: Fred Baker > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > To: "Ilpo J?rvinen" > Cc: tcpm , tmrg > Message-ID: > Content-Type: text/plain; charset=3Diso-8859-1 >=20 >=20 > On Nov 16, 2010, at 10:01 PM, Ilpo J?rvinen wrote: >=20 >> On Tue, 16 Nov 2010, Fred Baker wrote: >>=20 >>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: >>>=20 >>>> I wonder what factors will argue that the initial quantum can't be cha= nged? >>>> Someone has argued in the past IW10 effectively "disable CC algorithm"= . >>>> But haven't we already done that years ago when moving up IW from 1=20 >>>> to 3 if one insisted then that the initial quantum must be 1? >>>=20 >>> Actually, no. I may be the person who said that this effectively=20 >>> disables congestion control in the average case; my reason for=20 >>> saying that is that per what little data I have, the average TCP=20 >>> transfer is on the order of 15K bytes, which is about ten 1460 byte seg= ments. >>=20 >> It only "disables" it if there was no congestion to control in the=20 >> first place. >=20 > How do you turn off something that's not on? >=20 > I refer to this as in the average case turning off congestion control bec= ause the transmission requires ten data packets and they all get sent in a = single burst. There is no congestion control, with IW=3D10, in the case of = the average-sized (which is actually gar above the median-sized) file trans= fer. >=20 >> Could you on your behalf answer how does IW=3D3 affect parallel=20 >> sessions on the same kind of environment? ...I've done research on=20 >> this (and Jerry has >> too) and I know that the answer is not an intuitive one. Then we=20 >> changed to IW10 in the same environment and observe no (consistent)=20 >> change. The results are driven by problems already with IW3 so IW10=20 >> won't make it any worse or the effect is just too small to be=20 >> measured among the other troubles that happen. >=20 > That may be true. I have asked to see data describing the impact. I haven= 't seen the data. Maybe I missed something? >=20 > ------------------------------ >=20 > Message: 5 > Date: Tue, 16 Nov 2010 16:41:50 -0000 > From: "Scheffenegger, Richard" > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > To: "Fred Baker" , "Ilpo J?rvinen" > > Cc: tcpm , tmrg > Message-ID: > <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 >=20 > Group, >=20 > Just one additional data point: Obviously, there are already applications= in the wild, that use persistent connections and disable the slow-start-re= start mechanism on these sessions. The expectations of the programmers maki= ng use of these socket options is to reduce the latency for their appliacti= on... In effect, these Apps seem use IW=3D44 (and hurting themselves more t= han anybody else). >=20 > See "Profiling Network Performance in Multi-Tier Data Center=20 > Applications", Section 6.1, "cwnd failing to prevent sudden bursts",=20 > http://www.cs.princeton.edu/~jrex/papers/snap10.pdf >=20 >=20 > IMHO this is evidence that some action in this space is absolutely needed= (even if it is "only" strong advice to apps programmers), or there will be= even more proliferation of clumsy workarounds that are even less well unde= rstood and investigated than IW10 already is. Keeping IW3 "forever" may be = more problematic than addressing emerging application needs with well-teste= d transport-layer approaches... >=20 >=20 > Richard Scheffenegger >=20 >=20 >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com] >> Sent: Dienstag, 16. November 2010 15:10 >> To: "Ilpo J?rvinen" >> Cc: tcpm; tmrg >> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >>=20 >>=20 >> On Nov 16, 2010, at 10:01 PM, Ilpo J?rvinen wrote: >>=20 >>> On Tue, 16 Nov 2010, Fred Baker wrote: >>>=20 >>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: >>>>=20 >>>>> I wonder what factors will argue that the initial quantum >> can't be changed? >>>>> Someone has argued in the past IW10 effectively "disable >> CC algorithm". >>>>> But haven't we already done that years ago when moving up >> IW from 1 >>>>> to 3 if one insisted then that the initial quantum must be 1? >>>>=20 >>>> Actually, no. I may be the person who said that this effectively=20 >>>> disables congestion control in the average case; my reason >> for saying >>>> that is that per what little data I have, the average TCP >> transfer is >>>> on the order of 15K bytes, which is about ten 1460 byte segments. >>>=20 >>> It only "disables" it if there was no congestion to control in the=20 >>> first place. >>=20 >> How do you turn off something that's not on? >>=20 >> I refer to this as in the average case turning off congestion control=20 >> because the transmission requires ten data packets and they all get=20 >> sent in a single burst. There is no congestion control, with IW=3D10,=20 >> in the case of the average-sized (which is actually gar above the=20 >> median-sized) file transfer. >>=20 >>> Could you on your behalf answer how does IW=3D3 affect >> parallel sessions >>> on the same kind of environment? ...I've done research on this (and=20 >>> Jerry has >>> too) and I know that the answer is not an intuitive one. Then we=20 >>> changed to IW10 in the same environment and observe no (consistent)=20 >>> change. The results are driven by problems already with IW3 so IW10=20 >>> won't make it any worse or the effect is just too small to >> be measured >>> among the other troubles that happen. >>=20 >> That may be true. I have asked to see data describing the impact. I=20 >> haven't seen the data. Maybe I missed something? >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 > End of tcpm Digest, Vol 79, Issue 24 > ************************************ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Tue Nov 16 13:41:29 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E973A67F9 for ; Tue, 16 Nov 2010 13:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.676 X-Spam-Level: X-Spam-Status: No, score=-109.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HimKmEo0FRra for ; Tue, 16 Nov 2010 13:41:26 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D89423A67F7 for ; Tue, 16 Nov 2010 13:41:25 -0800 (PST) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id oAGLg8Dw032621 for ; Tue, 16 Nov 2010 13:42:09 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1289943729; bh=Fdun4Tk7czVuJwNG3A/6xmvP7O4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Kd3FTgK/I/JfcN7dVHsLvFjLV0ny3BTdHtPomYjApW9MPPs3GuWR8J2BLsgFocRcA hl02kkHAgpcYRsZxwLo/A== Received: from qwd7 (qwd7.prod.google.com [10.241.193.199]) by kpbe18.cbf.corp.google.com with ESMTP id oAGLeaIx013957 for ; Tue, 16 Nov 2010 13:42:07 -0800 Received: by qwd7 with SMTP id 7so506100qwd.11 for ; Tue, 16 Nov 2010 13:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=bLV6FLjNIeh9k3OsmWucJq47T0oS/GhuBf06usEjbFk=; b=vs2/uk0reRGXGeuG0IwT+uffYyHGKEcD3nY/Do3cqfhsL5CM7o02LmBasYTiUlP2Ql frKzW7zArpo2buqqpxXg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=WJwY+dXaHw5nh1X9Ko7JeBco9XpuPH5F0Ovk0atQBkwdWeDcR56gZLwjf05tMj37nz 5ChJ9XoPhUYjFmOC3e4w== Received: by 10.224.174.12 with SMTP id r12mr6770152qaz.109.1289943726939; Tue, 16 Nov 2010 13:42:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Tue, 16 Nov 2010 13:41:46 -0800 (PST) In-Reply-To: References: <0A03BFFA-9C68-44F3-8DAA-0A1DFD36A9BB@gmail.com> From: Yuchung Cheng Date: Tue, 16 Nov 2010 13:41:46 -0800 Message-ID: To: Murari Sridharan Content-Type: multipart/alternative; boundary=20cf303343db9fe0080495326db6 X-System-Of-Record: true Cc: Idris Rai , "tcpm@ietf.org" Subject: Re: [tcpm] tcpm Digest, Vol 79, Issue 24 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 21:41:30 -0000 --20cf303343db9fe0080495326db6 Content-Type: text/plain; charset=ISO-8859-1 There is also a paper that studies this topic in details: Characterizing residential broadband networks, IMC 2007 http://portal.acm.org/citation.cfm?id=1298306.1298313 Section 4.4 [...] All ISPs deploy queues that are several times larger than their bandwidth-delay products. Whereas downstream queues can delay packets by more than 100 ms, the upstream queueing delays can exceed several hundreds of milliseconds and, at times, a few seconds. Jerry picked the configuration based on other member's suggestions and also these studies to better emulate today's residential network setup. On Tue, Nov 16, 2010 at 11:08 AM, Murari Sridharan wrote: > The buffers in these low speed modems are in fact quite large as we have > seen in Ledbat. In my home DSL I can build up latencies into the seconds by > doing sustained uploads. There is a significant amount of buffering much > larger than BDP. > > Thanks > Murari > > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Idris Rai > Sent: Tuesday, November 16, 2010 9:19 AM > To: tcpm@ietf.org > Cc: tcpm@ietf.org > Subject: Re: [tcpm] tcpm Digest, Vol 79, Issue 24 > > The results presented by Jerry in Beijing for IW10 show an improved > response time and increase in loss rate at low speed links -- but the > buffer used was too large (about double the DBP). > > Can we get the same results at lower, more acceptable buffer sizes??. Not > intuitive at all to me. Perhaps this is one experiment we need to do next > > Idris > > Sent from my iPhone > > On 16 Nov 2010, at 19:41, tcpm-request@ietf.org wrote: > > > If you have received this digest without all the individual message > > attachments you will need to update your digest options in your list > > subscription. To do so, go to > > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > > MIME or Plain Text Digests?" to MIME. You can set this option > > globally for all the list digests you receive at this point. > > > > > > > > Send tcpm mailing list submissions to > > tcpm@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/tcpm > > or, via email, send a message with subject or body 'help' to > > tcpm-request@ietf.org > > > > You can reach the person managing the list at > > tcpm-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of tcpm digest..." > > > > > > Today's Topics: > > > > 1. Re: WG status update (Lars Eggert) > > 2. I-D Action:draft-ietf-tcpm-tcp-timestamps-01.txt > > (Internet-Drafts@ietf.org) > > 3. Re: [Tmrg] Increasing the Initial Window - Notes > > ( Ilpo J?rvinen ) > > 4. Re: [Tmrg] Increasing the Initial Window - Notes (Fred Baker) > > 5. Re: [Tmrg] Increasing the Initial Window - Notes > > (Scheffenegger, Richard) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 16 Nov 2010 13:48:12 +0200 > > From: Lars Eggert > > Subject: Re: [tcpm] WG status update > > To: L.Wood@surrey.ac.uk > > Cc: tcpm@ietf.org > > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > > > On 2010-11-15, at 17:39, L.Wood@surrey.ac.uk wrote: > >>> But since we are doing MPTCP, I simply don't see the point of > >>> specifying a subset of it in a way that is incompatible. > >> > >> Lars, are you speaking as an individual contributor or as Area director > here? > > > > Individual. (Thanks for reminding me to make this clear.) > > > > Lars > > -------------- next part -------------- A non-text attachment was > > scrubbed... > > Name: smime.p7s > > Type: application/pkcs7-signature > > Size: 4367 bytes > > Desc: not available > > Url : > > > cb/attachment.p7s> > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 16 Nov 2010 04:45:01 -0800 > > From: Internet-Drafts@ietf.org > > Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-timestamps-01.txt > > To: i-d-announce@ietf.org > > Cc: tcpm@ietf.org > > Message-ID: <20101116124501.2400.2831.idtracker@localhost> > > Content-Type: text/plain; charset="us-ascii" > > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Tue, 16 Nov 2010 16:01:19 +0200 (EET) > > From: " Ilpo J?rvinen " > > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > > To: Fred Baker > > Cc: tcpm , tmrg > > Message-ID: > > > > Content-Type: text/plain; charset=us-ascii > > > > On Tue, 16 Nov 2010, Fred Baker wrote: > > > >> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > >> > >>> I wonder what factors will argue that the initial quantum can't be > changed? > >>> Someone has argued in the past IW10 effectively "disable CC algorithm". > >>> But haven't we already done that years ago when moving up IW from 1 > >>> to 3 if one insisted then that the initial quantum must be 1? > >> > >> Actually, no. I may be the person who said that this effectively > >> disables congestion control in the average case; my reason for saying > >> that is that per what little data I have, the average TCP transfer is > >> on the order of 15K bytes, which is about ten 1460 byte segments. > > > > It only "disables" it if there was no congestion to control in the > > first place. > > > >> Now, the median is much smaller - on the order of two or three data > >> segments each direction, which is where you get your comment. But the > >> fact that browsers, Bittorrent, and other applications open multiple > >> sessions simultaneously argues that a given endpoint having multiple > >> packets in flight simultaneously doesn't hurt, and research done at > >> the time by Mark Allman and others showed that IW=2..4 wasn't a > >> problem and did in fact reduce the median session to a single RTT for > >> data. But the median session doesn't create a congestion problem. > >> > >> The question I have been asking is how IW=10 affects parallel > >> sessions on relatively low speed links. > > > > Could you on your behalf answer how does IW=3 affect parallel sessions > > on the same kind of environment? ...I've done research on this (and > > Jerry has > > too) and I know that the answer is not an intuitive one. Then we > > changed to IW10 in the same environment and observe no (consistent) > > change. The results are driven by problems already with IW3 so IW10 > > won't make it any worse or the effect is just too small to be measured > > among the other troubles that happen. > > > >> My sense is that the sudden arrival of > >> O(15K) bytes at a 56 KBPS line, which is to say the insertion of a > >> tad over two seconds delay in all competing sessions plus an increase > >> in their probability of loss, is likely to cause them all to be > disrupted. > > > > Again, the existing research points to exactly _opposite_ thing to > > happen, ie., IW10 hurts mostly itself, not the others! We'll never get > > anywhere if these same "fuzzy feelings" (like Mark put it) just get > > repeated and the existing _evidence_ overlooked. Jerry has tested a > > case that is very close to what you're specifying and his results > > don't agree what you think would happen. My results also confirm > > Jerry's observations for the low end links though in my case it was a > > bit higher bw already (160kbps). > > > > I personally don't anymore believe we will find a convincing case > > against > > IW10 from the very lowest end of links, afaict, it doesn't help but > > doesn't really hurt significantly either. ...I understand this is > > quite non-intuitive claim but it is what the performed studies seem to > > point out (and I expect new guys every now and then to jump in with > > this same argument if IW10 is to proceed). ...I'm more concerned about > > mid-ranged links where it could be possible (at least in theory if AQM > > in use) to have both TCP and low-latency requiring audio/video in > parallel. > > > >> You told me verbally that in your tests it is net beneficial to the > >> parallel sessions, but in thought experiments I'm not sure how that > >> can be true; I'd be fascinated to see the data that shows that > >> competing voice/video sees no frame loss or induced noise, that > >> competing file transfers slow down but do not see redundant > retransmissions, and so on. > > > > In this I somewhat agree with you. The delay increase was confirmed by > > my measurements, however, I think you also end up too cleverly mixing > > IW3+IW10 and voice/video cases here. It seems that even if delay > > IW3+increases > > and as a result voice/video could possible experience more losses (I'm > > yet to confirm that losses actually happen as I didn't have actual CBR > > traffic running), IW3 TCP in mixed case is not affected in a similar > > way. Instead, > > IW3 TCP might actually get a boost in its performance against IW10 > > because also IW10 TCP needs to respond to the congestion it caused. > > > > Also, regardless of IW, TCP is well capable of leaving audio/video in > > ruins as it will fill all buffers you give to it, so I find this > > exercise quite pointless anyway unless there is some form of AQM in use. > > > >> So, IW=2..4 demonstrably works pretty well everywhere, but IW=10 > >> seems to me only sensible on MPBS and GBPS, not KBPS, scale links. > > > > IW3 doesn't work that well if you have parallel connections over > > 56kbps but since the latencies are high anyway, you just won't notice > that. > > > > > > -- > > i. > > > > > > ------------------------------ > > > > Message: 4 > > Date: Tue, 16 Nov 2010 22:09:38 +0800 > > From: Fred Baker > > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > > To: "Ilpo J?rvinen" > > Cc: tcpm , tmrg > > Message-ID: > > Content-Type: text/plain; charset=iso-8859-1 > > > > > > On Nov 16, 2010, at 10:01 PM, Ilpo J?rvinen wrote: > > > >> On Tue, 16 Nov 2010, Fred Baker wrote: > >> > >>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > >>> > >>>> I wonder what factors will argue that the initial quantum can't be > changed? > >>>> Someone has argued in the past IW10 effectively "disable CC > algorithm". > >>>> But haven't we already done that years ago when moving up IW from 1 > >>>> to 3 if one insisted then that the initial quantum must be 1? > >>> > >>> Actually, no. I may be the person who said that this effectively > >>> disables congestion control in the average case; my reason for > >>> saying that is that per what little data I have, the average TCP > >>> transfer is on the order of 15K bytes, which is about ten 1460 byte > segments. > >> > >> It only "disables" it if there was no congestion to control in the > >> first place. > > > > How do you turn off something that's not on? > > > > I refer to this as in the average case turning off congestion control > because the transmission requires ten data packets and they all get sent in > a single burst. There is no congestion control, with IW=10, in the case of > the average-sized (which is actually gar above the median-sized) file > transfer. > > > >> Could you on your behalf answer how does IW=3 affect parallel > >> sessions on the same kind of environment? ...I've done research on > >> this (and Jerry has > >> too) and I know that the answer is not an intuitive one. Then we > >> changed to IW10 in the same environment and observe no (consistent) > >> change. The results are driven by problems already with IW3 so IW10 > >> won't make it any worse or the effect is just too small to be > >> measured among the other troubles that happen. > > > > That may be true. I have asked to see data describing the impact. I > haven't seen the data. Maybe I missed something? > > > > ------------------------------ > > > > Message: 5 > > Date: Tue, 16 Nov 2010 16:41:50 -0000 > > From: "Scheffenegger, Richard" > > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > > To: "Fred Baker" , "Ilpo J?rvinen" > > > > Cc: tcpm , tmrg > > Message-ID: > > <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > Group, > > > > Just one additional data point: Obviously, there are already applications > in the wild, that use persistent connections and disable the > slow-start-restart mechanism on these sessions. The expectations of the > programmers making use of these socket options is to reduce the latency for > their appliaction... In effect, these Apps seem use IW=44 (and hurting > themselves more than anybody else). > > > > See "Profiling Network Performance in Multi-Tier Data Center > > Applications", Section 6.1, "cwnd failing to prevent sudden bursts", > > http://www.cs.princeton.edu/~jrex/papers/snap10.pdf > > > > > > IMHO this is evidence that some action in this space is absolutely needed > (even if it is "only" strong advice to apps programmers), or there will be > even more proliferation of clumsy workarounds that are even less well > understood and investigated than IW10 already is. Keeping IW3 "forever" may > be more problematic than addressing emerging application needs with > well-tested transport-layer approaches... > > > > > > Richard Scheffenegger > > > > > >> -----Original Message----- > >> From: Fred Baker [mailto:fred@cisco.com] > >> Sent: Dienstag, 16. November 2010 15:10 > >> To: "Ilpo J?rvinen" > >> Cc: tcpm; tmrg > >> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > >> > >> > >> On Nov 16, 2010, at 10:01 PM, Ilpo J?rvinen wrote: > >> > >>> On Tue, 16 Nov 2010, Fred Baker wrote: > >>> > >>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > >>>> > >>>>> I wonder what factors will argue that the initial quantum > >> can't be changed? > >>>>> Someone has argued in the past IW10 effectively "disable > >> CC algorithm". > >>>>> But haven't we already done that years ago when moving up > >> IW from 1 > >>>>> to 3 if one insisted then that the initial quantum must be 1? > >>>> > >>>> Actually, no. I may be the person who said that this effectively > >>>> disables congestion control in the average case; my reason > >> for saying > >>>> that is that per what little data I have, the average TCP > >> transfer is > >>>> on the order of 15K bytes, which is about ten 1460 byte segments. > >>> > >>> It only "disables" it if there was no congestion to control in the > >>> first place. > >> > >> How do you turn off something that's not on? > >> > >> I refer to this as in the average case turning off congestion control > >> because the transmission requires ten data packets and they all get > >> sent in a single burst. There is no congestion control, with IW=10, > >> in the case of the average-sized (which is actually gar above the > >> median-sized) file transfer. > >> > >>> Could you on your behalf answer how does IW=3 affect > >> parallel sessions > >>> on the same kind of environment? ...I've done research on this (and > >>> Jerry has > >>> too) and I know that the answer is not an intuitive one. Then we > >>> changed to IW10 in the same environment and observe no (consistent) > >>> change. The results are driven by problems already with IW3 so IW10 > >>> won't make it any worse or the effect is just too small to > >> be measured > >>> among the other troubles that happen. > >> > >> That may be true. I have asked to see data describing the impact. I > >> haven't seen the data. Maybe I missed something? > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > >> > > > > > > ------------------------------ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > End of tcpm Digest, Vol 79, Issue 24 > > ************************************ > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --20cf303343db9fe0080495326db6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is also a paper that studies this topic in details:

Characterizing residential broadband networks, IMC 2007

Section 4.4
[...]
All ISPs dep= loy queues that are several times larger
than their bandwidth-del= ay products. Whereas downstream
queues can delay packets by more = than 100 ms, the upstream
queueing delays can exceed several hundreds of milliseconds
= and, at times, a few seconds.

Jerry picked t= he configuration based on other member's suggestions and also these stu= dies to better emulate today's residential network setup.


On Tue, Nov 16, 2010 at 11:08 AM, Murari= Sridharan <m= uraris@microsoft.com> wrote:
The buffers in these low speed modems are i= n fact quite large as we have seen in Ledbat. In my home DSL I can build up= latencies into the seconds by doing sustained uploads. There is a signific= ant amount of buffering much larger than BDP.

Thanks
Murari

-----Original Message-----
From: tcpm-bounces@ietf.org [m= ailto:tcpm-bounces@ietf.org] O= n Behalf Of Idris Rai
Sent: Tuesday, November 16, 2010 9:19 AM
To: tcpm@ietf.org
Cc: tcpm@ietf.org
Subject: Re: [tcpm] tcpm Digest, Vo= l 79, Issue 24

The results presented by Jerry in Beijing for IW10 show an improved respons= e time and =A0increase in loss rate at low speed links -- =A0but the buffer= used was too large (about double the DBP).

Can we get the same results at lower, more acceptable buffer sizes??. Not i= ntuitive at all to me. Perhaps this is one experiment we need to do next
Idris

Sent from my iPhone

On 16 Nov 2010, at 19:41, tcpm-req= uest@ietf.org wrote:

> If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. =A0To do so, go to
>
> https://www.ietf.org/mailman/listinfo/tcpm
>
> Click the 'Unsubscribe or edit options' button, log in, and se= t "Get
> MIME or Plain Text Digests?" to MIME. =A0You can set this option<= br> > globally for all the list digests you receive at this point.
>
>
>
> Send tcpm mailing list submissions to
> =A0 =A0tcpm@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> =A0 =A0https://www.ietf.org/mailman/listinfo/tcpm
> or, via email, send a message with subject or body 'help' to > =A0 =A0tcpm-request@ietf.org<= /a>
>
> You can reach the person managing the list at
> =A0 =A0tcpm-owner@ietf.org<= br> >
> When replying, please edit your Subject line so it is more specific > than "Re: Contents of tcpm digest..."
>
>
> Today's Topics:
>
> =A0 1. Re: WG status update (Lars Eggert)
> =A0 2. I-D Action:draft-ietf-tcpm-tcp-timestamps-01.txt
> =A0 =A0 =A0(Internet-Draft= s@ietf.org)
> =A0 3. Re: [Tmrg] =A0Increasing the Initial Window - Notes
> =A0 =A0 =A0( Ilpo J?rvinen )
> =A0 4. Re: [Tmrg] =A0Increasing the Initial Window - Notes (Fred Baker= )
> =A0 5. Re: [Tmrg] =A0Increasing the Initial Window - Notes
> =A0 =A0 =A0(Scheffenegger, Richard)
>
>
> ----------------------------------------------------------------------=
>
> Message: 1
> Date: Tue, 16 Nov 2010 13:48:12 +0200
> From: Lars Eggert <lars.eg= gert@nokia.com>
> Subject: Re: [tcpm] WG status update
> To: L.Wood@surrey.ac.uk
> Cc: tcpm@ietf.org
> Message-ID: <E8DE9B17-6C26-4FF4-8C9A-DCFECB62038C@nokia.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> On 2010-11-15, at 17:39, L.Wood= @surrey.ac.uk wrote:
>>> But since we are doing MPTCP, I simply don't see the point= of
>>> specifying a subset of it in a way that is incompatible.
>>
>> Lars, are you speaking as an individual contributor or as Area dir= ector here?
>
> Individual. (Thanks for reminding me to make this clear.)
>
> Lars
> -------------- next part -------------- A non-text attachment was
> scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 4367 bytes
> Desc: not available
> Url :
> <http://www.ietf.org/mail-archive/web/tcpm= /attachments/20101116/43abe0
> cb/attachment.p7s>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 16 Nov 2010 04:45:01 -0800
> From: Internet-Drafts@ietf= .org
> Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-timestamps-01.txt
> To: i-d-announce@ietf.org=
> Cc: tcpm@ietf.org
> Message-ID: <20101116124501.2400.2831.idtracker@localhost>
> Content-Type: text/plain; charset=3D"us-ascii"
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 16 Nov 2010 16:01:19 +0200 (EET)
> From: " Ilpo J?rvinen " <ilpo.jarvinen@helsinki.fi>
> Subject: Re: [tcpm] [Tmrg] =A0Increasing the Initial Window - Notes > To: Fred Baker <fred@cisco.com>
> Cc: tcpm <tcpm@ietf.org>, t= mrg <tmrg-interest@IC= SI.Berkeley.EDU>
> Message-ID:
> =A0 =A0<alpine.DEB.2.00.1011161345170.11898@wel-95.cs.helsinki.fi= >
> Content-Type: text/plain; charset=3Dus-ascii
>
> On Tue, 16 Nov 2010, Fred Baker wrote:
>
>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote:
>>
>>> I wonder what factors will argue that the initial quantum can&= #39;t be changed?
>>> Someone has argued in the past IW10 effectively "disable = CC algorithm".
>>> But haven't we already done that years ago when moving up = IW from 1
>>> to 3 if one insisted then that the initial quantum must be 1?<= br> >>
>> Actually, no. I may be the person who said that this effectively >> disables congestion control in the average case; my reason for say= ing
>> that is that per what little data I have, the average TCP transfer= is
>> on the order of 15K bytes, which is about ten 1460 byte segments.<= br> >
> It only "disables" it if there was no congestion to control = in the
> first place.
>
>> Now, the median is much smaller - on the order of two or three dat= a
>> segments each direction, which is where you get your comment. But = the
>> fact that browsers, Bittorrent, and other applications open multip= le
>> sessions simultaneously argues that a given endpoint having multip= le
>> packets in flight simultaneously doesn't hurt, and research do= ne at
>> the time by Mark Allman and others showed that IW=3D2..4 wasn'= t a
>> problem and did in fact reduce the median session to a single RTT = for
>> data. But the median session doesn't create a congestion probl= em.
>>
>> The question I have been asking is how IW=3D10 affects parallel >> sessions on relatively low speed links.
>
> Could you on your behalf answer how does IW=3D3 affect parallel sessio= ns
> on the same kind of environment? ...I've done research on this (an= d
> Jerry has
> too) and I know that the answer is not an intuitive one. Then we
> changed to IW10 in the same environment and observe no (consistent) > change. The results are driven by problems already with IW3 so IW10 > won't make it any worse or the effect is just too small to be meas= ured
> among the other troubles that happen.
>
>> My sense is that the sudden arrival of
>> O(15K) bytes at a 56 KBPS line, which is to say the insertion of a=
>> tad over two seconds delay in all competing sessions plus an incre= ase
>> in their probability of loss, is likely to cause them all to be di= srupted.
>
> Again, the existing research points to exactly _opposite_ thing to
> happen, ie., IW10 hurts mostly itself, not the others! We'll never= get
> anywhere if these same "fuzzy feelings" (like Mark put it) j= ust get
> repeated and the existing _evidence_ overlooked. Jerry has tested a > case that is very close to what you're specifying and his results<= br> > don't agree what you think would happen. My results also confirm > Jerry's observations for the low end links though in my case it wa= s a
> bit higher bw already (160kbps).
>
> I personally don't anymore believe we will find a convincing case<= br> > against
> IW10 from the very lowest end of links, afaict, it doesn't help bu= t
> doesn't really hurt significantly either. ...I understand this is<= br> > quite non-intuitive claim but it is what the performed studies seem to=
> point out (and I expect new guys every now and then to jump in with > this same argument if IW10 is to proceed). ...I'm more concerned a= bout
> mid-ranged links where it could be possible (at least in theory if AQM=
> in use) to have both TCP and low-latency requiring audio/video in para= llel.
>
>> You told me verbally that in your tests it is net beneficial to th= e
>> parallel sessions, but in thought experiments I'm not sure how= that
>> can be true; I'd be fascinated to see the data that shows that=
>> competing voice/video sees no frame loss or induced noise, that >> competing file transfers slow down but do not see redundant retran= smissions, and so on.
>
> In this I somewhat agree with you. The delay increase was confirmed by=
> my measurements, however, I think you also end up too cleverly mixing<= br> > IW3+IW10 and voice/video cases here. It seems that even if delay
> IW3+increases
> and as a result voice/video could po= ssible experience more losses (I'm
> yet to confirm that losses actually happen as I didn't have actual= CBR
> traffic running), IW3 TCP in mixed case is not affected in a similar > way. Instead,
> IW3 TCP might actually get a boost in its performance against IW10
> because also IW10 TCP needs to respond to the congestion it caused. >
> Also, regardless of IW, TCP is well capable of leaving audio/video in<= br> > ruins as it will fill all buffers you give to it, so I find this
> exercise quite pointless anyway unless there is some form of AQM in us= e.
>
>> So, IW=3D2..4 demonstrably works pretty well everywhere, but IW=3D= 10
>> seems to me only sensible on MPBS and GBPS, not KBPS, scale links.=
>
> IW3 doesn't work that well if you have parallel connections over > 56kbps but since the latencies are high anyway, you just won't not= ice that.
>
>
> --
> i.
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 16 Nov 2010 22:09:38 +0800
> From: Fred Baker <fred@cisco.com<= /a>>
> Subject: Re: [tcpm] [Tmrg] =A0Increasing the Initial Window - Notes > To: "Ilpo J?rvinen" <ilpo.jarvinen@helsinki.fi>
> Cc: tcpm <tcpm@ietf.org>, t= mrg <tmrg-interest@IC= SI.Berkeley.EDU>
> Message-ID: <E798B9A8-29BB-425B-B0C2-2B2735C49948@cisco.com>
> Content-Type: text/plain; charset=3Diso-8859-1
>
>
> On Nov 16, 2010, at 10:01 PM, Ilpo J?rvinen wrote:
>
>> On Tue, 16 Nov 2010, Fred Baker wrote:
>>
>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote:
>>>
>>>> I wonder what factors will argue that the initial quantum = can't be changed?
>>>> Someone has argued in the past IW10 effectively "disa= ble CC algorithm".
>>>> But haven't we already done that years ago when moving= up IW from 1
>>>> to 3 if one insisted then that the initial quantum must be= 1?
>>>
>>> Actually, no. I may be the person who said that this effective= ly
>>> disables congestion control in the average case; my reason for=
>>> saying that is that per what little data I have, the average T= CP
>>> transfer is on the order of 15K bytes, which is about ten 1460= byte segments.
>>
>> It only "disables" it if there was no congestion to cont= rol in the
>> first place.
>
> How do you turn off something that's not on?
>
> I refer to this as in the average case turning off congestion control = because the transmission requires ten data packets and they all get sent in= a single burst. There is no congestion control, with IW=3D10, in the case = of the average-sized (which is actually gar above the median-sized) file tr= ansfer.
>
>> Could you on your behalf answer how does IW=3D3 affect parallel >> sessions on the same kind of environment? ...I've done researc= h on
>> this (and Jerry has
>> too) and I know that the answer is not an intuitive one. Then we >> changed to IW10 in the same environment and observe no (consistent= )
>> change. The results are driven by problems already with IW3 so IW1= 0
>> won't make it any worse or the effect is just too small to be<= br> >> measured among the other troubles that happen.
>
> That may be true. I have asked to see data describing the impact. I ha= ven't seen the data. Maybe I missed something?
>
> ------------------------------
>
> Message: 5
> Date: Tue, 16 Nov 2010 16:41:50 -0000
> From: "Scheffenegger, Richard" <rs@netapp.com>
> Subject: Re: [tcpm] [Tmrg] =A0Increasing the Initial Window - Notes > To: "Fred Baker" <fred@= cisco.com>, "Ilpo J?rvinen"
> =A0 =A0<ilpo.jarvinen@= helsinki.fi>
> Cc: tcpm <tcpm@ietf.org>, t= mrg <tmrg-interest@IC= SI.Berkeley.EDU>
> Message-ID:
> =A0 =A0<5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMV= EXC1-PRD.hq.netapp.com>
> Content-Type: text/plain; =A0 =A0charset=3D"iso-8859-1"
>
>
> Group,
>
> Just one additional data point: Obviously, there are already applicati= ons in the wild, that use persistent connections and disable the slow-start= -restart mechanism on these sessions. The expectations of the programmers m= aking use of these socket options is to reduce the latency for their applia= ction... In effect, these Apps seem use IW=3D44 (and hurting themselves mor= e than anybody else).
>
> See "Profiling Network Performance in Multi-Tier Data Center
> Applications", Section 6.1, "cwnd failing to prevent sudden = bursts",
> http://www.cs.princeton.edu/~jrex/papers/snap10.pdf
>
>
> IMHO this is evidence that some action in this space is absolutely nee= ded (even if it is "only" strong advice to apps programmers), or = there will be even more proliferation of clumsy workarounds that are even l= ess well understood and investigated than IW10 already is. Keeping IW3 &quo= t;forever" may be more problematic than addressing emerging applicatio= n needs with well-tested transport-layer approaches...
>
>
> Richard Scheffenegger
>
>
>> -----Original Message-----
>> From: Fred Baker [mailto:fred@ci= sco.com]
>> Sent: Dienstag, 16. November 2010 15:10
>> To: "Ilpo J?rvinen"
>> Cc: tcpm; tmrg
>> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >>
>>
>> On Nov 16, 2010, at 10:01 PM, Ilpo J?rvinen wrote:
>>
>>> On Tue, 16 Nov 2010, Fred Baker wrote:
>>>
>>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote:
>>>>
>>>>> I wonder what factors will argue that the initial quan= tum
>> can't be changed?
>>>>> Someone has argued in the past IW10 effectively "= disable
>> CC algorithm".
>>>>> But haven't we already done that years ago when mo= ving up
>> IW from 1
>>>>> to 3 if one insisted then that the initial quantum mus= t be 1?
>>>>
>>>> Actually, no. I may be the person who said that this effec= tively
>>>> disables congestion control in the average case; my reason=
>> for saying
>>>> that is that per what little data I have, the average TCP<= br> >> transfer is
>>>> on the order of 15K bytes, which is about ten 1460 byte se= gments.
>>>
>>> It only "disables" it if there was no congestion to = control in the
>>> first place.
>>
>> How do you turn off something that's not on?
>>
>> I refer to this as in the average case turning off congestion cont= rol
>> because the transmission requires ten data packets and they all ge= t
>> sent in a single burst. There is no congestion control, with IW=3D= 10,
>> in the case of the average-sized (which is actually gar above the<= br> >> median-sized) file transfer.
>>
>>> Could you on your behalf answer how does IW=3D3 affect
>> parallel sessions
>>> on the same kind of environment? ...I've done research on = this (and
>>> Jerry has
>>> too) and I know that the answer is not an intuitive one. Then = we
>>> changed to IW10 in the same environment and observe no (consis= tent)
>>> change. The results are driven by problems already with IW3 so= IW10
>>> won't make it any worse or the effect is just too small to=
>> be measured
>>> among the other troubles that happen.
>>
>> That may be true. I have asked to see data describing the impact. = I
>> haven't seen the data. Maybe I missed something?
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>
>
> ------------------------------
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
> End of tcpm Digest, Vol 79, Issue 24
> ************************************
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

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

--20cf303343db9fe0080495326db6-- From touch@isi.edu Tue Nov 16 15:38:53 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6743A6876 for ; Tue, 16 Nov 2010 15:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NspgcxtQFRRu for ; Tue, 16 Nov 2010 15:38:52 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id D91E13A6874 for ; Tue, 16 Nov 2010 15:38:52 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oAGNdLpT012312 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 16 Nov 2010 15:39:21 -0800 (PST) Message-ID: <4CE31628.2000602@isi.edu> Date: Tue, 16 Nov 2010 15:39:20 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Lars Eggert References: <4CDA4FA9.4050006@alcatel-lucent.com> <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com> <4CE10B0C.1040705@alcatel-lucent.com> <9EAEB61A-6E43-4EB2-B89F-32A3957814AB@nokia.com> In-Reply-To: <9EAEB61A-6E43-4EB2-B89F-32A3957814AB@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: oAGNdLpT012312 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 23:38:53 -0000 On 11/15/2010 4:54 AM, Lars Eggert wrote: > Hi, > > On 2010-11-15, at 12:27, Bruno Mongazon-Cazavet wrote: >> Please let me know, if from the design point of view, the WG would consider the opportunity to have a lightweight MPTCP that would look like TCP-Rehash. > > given that the IETF is already working on MPTCP, it's a bit > difficult to see why we should work on another extension to TCP that > does some of what MPTCP does, but not all of it, and in a way that is > not interoperable with it. I had argued that MPTCP was trying to solve two separate issues (perhaps three): 1) use of more than one *path* between two endpoints at the same time 2) use of multiple endpoint IP addresses between two pairs at the same time (3) shifting the addresses in #2 dynamically, i.e., not so much concurrent use as a sequence of uses My concern, FWIW, remains that inferring #1 from #2 is just wrong. Beyond that concern, however, I didn't like the idea of bundling two separately useful features in a single system, since I didn't see the two as necessarily related anyway. TCP-Rehash - good or bad, I don't know (I haven't looked in detail, but see below) - at least admits that there's utility to #3 independent of #1 and #2. So I don't see this as related to MPTCP at all. That said, I have other concerns, e.g., as to TCP-Rehash replicating work that has already been done in HIP, SHIM6, or just over tunnels in general. FWIW, I'm also concerned about the fact that TCP *defines* its connections in terms of endpoint addresses, so the *semantics* needs to be updated if there's a corresponding redefinition of how the connection is now dissociated from those addresses. But, again, this is not at all related to MPTCP to me. Joe From alexander.zimmermann@comsys.rwth-aachen.de Tue Nov 16 23:57:41 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CEE83A68BB for ; Tue, 16 Nov 2010 23:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkKUbRRCgqhf for ; Tue, 16 Nov 2010 23:57:39 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 8FF7B3A68B9 for ; Tue, 16 Nov 2010 23:57:39 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LC0001L9RHBH480@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 17 Nov 2010 08:58:23 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.59,209,1288566000"; d="sig'?scan'208";a="81505695" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 17 Nov 2010 08:58:24 +0100 Received: from [137.226.12.58] ([unknown] [137.226.12.58]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LC000HHJRHBHY70@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 17 Nov 2010 08:58:23 +0100 (CET) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-2-288377491 From: Alexander Zimmermann In-reply-to: <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> Date: Wed, 17 Nov 2010 08:58:26 +0100 Content-transfer-encoding: 7bit Message-id: <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Pgp-Agent: GPGMail 1.3.1 X-Mailer: Apple Mail (2.1082) Cc: tcpm , "david.borman@windriver.com Borman" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 07:57:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-288377491 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Richard, exactly, this is the point! IMO, two things are crystal clear: 1. We have to touch/increase the IW 2. We have to do it now Also, IMO he have a rough consensus on these two points. What I like two see now, or discuss now, is a strategy how we can = progress. Mark proposed something, but what are thoughts from the document author/ other group members/chairs/AD on this point? Alex Am 16.11.2010 um 17:41 schrieb Scheffenegger, Richard: >=20 > Group, >=20 > Just one additional data point: Obviously, there are already = applications in the wild, that use persistent connections and disable = the slow-start-restart mechanism on these sessions. The expectations of = the programmers making use of these socket options is to reduce the = latency for their appliaction... In effect, these Apps seem use IW=3D44 = (and hurting themselves more than anybody else). >=20 > See "Profiling Network Performance in Multi-Tier Data Center = Applications", Section 6.1, "cwnd failing to prevent sudden bursts", = http://www.cs.princeton.edu/~jrex/papers/snap10.pdf >=20 >=20 > IMHO this is evidence that some action in this space is absolutely = needed (even if it is "only" strong advice to apps programmers), or = there will be even more proliferation of clumsy workarounds that are = even less well understood and investigated than IW10 already is. Keeping = IW3 "forever" may be more problematic than addressing emerging = application needs with well-tested transport-layer approaches... >=20 >=20 > Richard Scheffenegger >=20 >=20 >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com]=20 >> Sent: Dienstag, 16. November 2010 15:10 >> To: "Ilpo J=E4rvinen" >> Cc: tcpm; tmrg >> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >>=20 >>=20 >> On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote: >>=20 >>> On Tue, 16 Nov 2010, Fred Baker wrote: >>>=20 >>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: >>>>=20 >>>>> I wonder what factors will argue that the initial quantum=20 >> can't be changed? >>>>> Someone has argued in the past IW10 effectively "disable=20 >> CC algorithm". >>>>> But haven't we already done that years ago when moving up=20 >> IW from 1=20 >>>>> to 3 if one insisted then that the initial quantum must be 1? >>>>=20 >>>> Actually, no. I may be the person who said that this effectively=20 >>>> disables congestion control in the average case; my reason=20 >> for saying=20 >>>> that is that per what little data I have, the average TCP=20 >> transfer is=20 >>>> on the order of 15K bytes, which is about ten 1460 byte segments. >>>=20 >>> It only "disables" it if there was no congestion to control in the=20= >>> first place. >>=20 >> How do you turn off something that's not on? >>=20 >> I refer to this as in the average case turning off congestion=20 >> control because the transmission requires ten data packets=20 >> and they all get sent in a single burst. There is no=20 >> congestion control, with IW=3D10, in the case of the=20 >> average-sized (which is actually gar above the median-sized)=20 >> file transfer. >>=20 >>> Could you on your behalf answer how does IW=3D3 affect=20 >> parallel sessions=20 >>> on the same kind of environment? ...I've done research on this (and=20= >>> Jerry has >>> too) and I know that the answer is not an intuitive one. Then we=20 >>> changed to IW10 in the same environment and observe no (consistent)=20= >>> change. The results are driven by problems already with IW3 so IW10=20= >>> won't make it any worse or the effect is just too small to=20 >> be measured=20 >>> among the other troubles that happen. >>=20 >> That may be true. I have asked to see data describing the=20 >> impact. I haven't seen the data. Maybe I missed something? >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-2-288377491 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEUEARECAAYFAkzjiyIACgkQdyiq39b9uS7RaACgkewlY6c17IYn7aJ9GXYJK0IG H6kAmIN1QTU3jOzDyvz+EVohn7W+5sM= =M+Wo -----END PGP SIGNATURE----- --Apple-Mail-2-288377491-- From bruno.mongazon-cazavet@alcatel-lucent.com Wed Nov 17 00:33:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17AA13A68D9 for ; Wed, 17 Nov 2010 00:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjPp7hBsqEoy for ; Wed, 17 Nov 2010 00:33:37 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id DBECA3A68D3 for ; Wed, 17 Nov 2010 00:33:35 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAH8Y5N1000430 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Nov 2010 09:34:18 +0100 Received: from [172.27.205.223] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 17 Nov 2010 09:34:05 +0100 Message-ID: <4CE39377.9030504@alcatel-lucent.com> Date: Wed, 17 Nov 2010 09:33:59 +0100 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Joe Touch References: <4CDA4FA9.4050006@alcatel-lucent.com> <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com> <4CE10B0C.1040705@alcatel-lucent.com> <9EAEB61A-6E43-4EB2-B89F-32A3957814AB@nokia.com> <4CE31628.2000602@isi.edu> In-Reply-To: <4CE31628.2000602@isi.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 08:33:38 -0000 Hey Joe ;-) Please see inline Le 17/11/2010 00:39, Joe Touch a écrit : > > On 11/15/2010 4:54 AM, Lars Eggert wrote: >> Hi, >> >> On 2010-11-15, at 12:27, Bruno Mongazon-Cazavet wrote: >>> Please let me know, if from the design point of view, the WG would consider the opportunity to have a lightweight MPTCP that would look like TCP-Rehash. >> given that the IETF is already working on MPTCP, it's a bit >> difficult to see why we should work on another extension to TCP that >> does some of what MPTCP does, but not all of it, and in a way that is >> not interoperable with it. > I had argued that MPTCP was trying to solve two separate issues (perhaps > three): > > 1) use of more than one *path* between two endpoints at the same time > > 2) use of multiple endpoint IP addresses between two pairs at the same time > > (3) shifting the addresses in #2 dynamically, i.e., not so much > concurrent use as a sequence of uses > > My concern, FWIW, remains that inferring #1 from #2 is just wrong. > Beyond that concern, however, I didn't like the idea of bundling two > separately useful features in a single system, since I didn't see the > two as necessarily related anyway. > > TCP-Rehash - good or bad, I don't know (I haven't looked in detail, but > see below) - at least admits that there's utility to #3 independent of > #1 and #2. [bm] correct. > So I don't see this as related to MPTCP at all. [bm] In fact, it is not. > That said, I have other concerns, e.g., as to TCP-Rehash replicating > work that has already been done in HIP, SHIM6, or just over tunnels in > general. [bm] i tried to make it different from HIP and SHIM6. It is not like HIP because TCP-Rehash does not deal at all with "Identity" but only end-point addresses. It is not like SHIM6 nor tunnel approaches because TCP-Rehash is not an intermediate or inner layer. It is more like MIT's TCP-Migrate or kind of approaches. > FWIW, I'm also concerned about the fact that TCP *defines* its > connections in terms of endpoint addresses, so the *semantics* needs to > be updated if there's a corresponding redefinition of how the connection > is now dissociated from those addresses. [bm] TCP-Rehash does not introduce new semantics. It is based on endpoint addresses and ports as regular TCP. There is no dissociation and this is a major constraint of its design. > But, again, this is not at all related to MPTCP to me. > > Joe > From hkchu@google.com Wed Nov 17 10:13:01 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2B83A6912 for ; Wed, 17 Nov 2010 10:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.675 X-Spam-Level: X-Spam-Status: No, score=-105.675 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV6WNKIp3FMB for ; Wed, 17 Nov 2010 10:13:00 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 78F4E3A6947 for ; Wed, 17 Nov 2010 10:13:00 -0800 (PST) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id oAHIDjZa031132 for ; Wed, 17 Nov 2010 10:13:45 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290017625; bh=FHm8xP/lR4NHDhVzjre6msb6eMc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=fPNGLT5kEI7yfaE/zl6pxB9XwlXu0sVmPQloTWqPDMGwjK1sWSrXyOvbcQavECzMj Sy4pHDOpGdJp3mIvylnCA== Received: from gxk23 (gxk23.prod.google.com [10.202.11.23]) by kpbe11.cbf.corp.google.com with ESMTP id oAHIDha0019691 for ; Wed, 17 Nov 2010 10:13:44 -0800 Received: by gxk23 with SMTP id 23so1289973gxk.19 for ; Wed, 17 Nov 2010 10:13:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V7yjCLIdIl/uVp8XIPZpN+8xToWMMe/4sxhV5ZKPhNs=; b=gpqld0TrclM4DMwvrWTrluVYjXevvh1fT45vDeeBG+ry0mk2R+J3gZuQ4cS0pp3ugp pNPD5k75adOc1MfhR4Qg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=J2MuF/DKLjO8lkWDwBpuVazTAdxQbGbAac8IWapw9pJLmc8mM070cVHjTpSAulmuO7 XlnW51YWWS9n75dfMXNA== MIME-Version: 1.0 Received: by 10.150.92.7 with SMTP id p7mr9470626ybb.405.1290017623169; Wed, 17 Nov 2010 10:13:43 -0800 (PST) Received: by 10.151.158.13 with HTTP; Wed, 17 Nov 2010 10:13:42 -0800 (PST) In-Reply-To: References: <20101110152857.GA5094@hell> <20101111012453.GB2691@hell> <29E76BE6-32D9-45AD-85A1-791DAADDE520@ifi.uio.no> <824FC88F-4877-45DC-AFD9-E5272ACD7C3E@ifi.uio.no> <4CDBCA4E.8000705@tlc.polito.it> <9C745827-D861-45D0-B096-AFC3E4FE5182@ifi.uio.no> Date: Wed, 17 Nov 2010 10:13:42 -0800 Message-ID: From: Jerry Chu To: John Heffner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm , tmrg Subject: Re: [tcpm] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 18:13:01 -0000 [sorry I'm trying to catchup while on vacation] On Mon, Nov 15, 2010 at 7:45 PM, John Heffner wrot= e: > On Thu, Nov 11, 2010 at 5:56 PM, Jerry Chu wrote: >> On Thu, Nov 11, 2010 at 2:58 AM, Michael Welzl wrot= e: >>> >>> On Nov 11, 2010, at 11:49 AM, Marco Mellia wrote: >>> >>>> >>>> >>>>>> I certainly won't object to this, if that's all it takes for >>>>>> standardization. Unfortunately the >>>>>> point for the non-convinced is they don't want ANY flows to use IW10 >>>>>> for fear of hurting >>>>>> the performance of their flows. >>>>> >>>>> ... but here, your "browsers open tens of flows" argument totally hol= ds. >>>>> How is a web flow with IW10 worse than a browser opening tens of flow= s? If >>>>> people only use it for the web, like Google has been successfully doi= ng, >>>>> this seems to be quite safe, based on experience. >>>>> >>>>> I'm curious what the opposition says to this =A0:) >>>> >>>> If today a brower opens 10 flows with a server using IW=3D1 you gets 1= 0 >>>> packets equivalent IW. >>>> Increasing the IW to 10 leads to an equivalent IW of 100 packets. At t= hat >>>> point, you DSL modem will definitively start dropping most of them... >>> >>> ... which is a good reason to open fewer connections. So that's a matte= r >>> of bringing of bringing out an update of a web client with a different >>> behavior for the case that a web server uses a larger IW. But how does = the >>> web browser know what the web server is doing? I guess they could excha= nge >>> this information with HTTP. Hm. Are we getting somewhere here, or is th= is a >>> dead end? >> >> One solution to safely migrate to IW10 for browsers opening multiple >> connections is to mandate browsers that open X connections, when X is, e= .g., >>> 4 to set the initial receive window to 3 (assuming OSes allow initrwnd = to >> be set on a per connection basis). But I don't know how this can be >> enforced... >> Jerry > > > I'm not a Googler, so you probably have better insight into this than > I do, but my impression is that one big reason (if not the *primary* > reason) browsers open multiple connections is being able to submit > requests in parallel. =A0HTTP pipelining can help some, but (a) most > browsers disable this because of some buggy and widely deployed > servers, and (b) it is still susceptible to head-of-line blocking on > responses. =A0Might limiting the number of simultaneous connections > based on IW hurt more than it helps? > > The solution would seem to be shared congestion state on the server. > Like the "congestion manager" (http://nms.lcs.mit.edu/cm/), or using > multiple channels in SCTP. =A0Of course, this may not be practical with > a lot of load-balancing systems. The various points you raised above have been covered in our earlier slides and/or discussed on the list. The following is a short summary for you: 1. Browsers requires multiple connections to schedule web object downloads in parallel to get the best user experience, much like a multi-threaded application requires a multi-core CPU to run well. TCP's small IW is one important but not the only reason for simultaneous connections. Avoiding HOLB is another. 2. The # of simultaneous connections by all popular browsers have continued to increase in the past few years. By increasing IW we hope to reverse this trend because with a much large IW the browser won't need that many connections to get the best user experience. 3. The solutions you've mentioned above are well understood on paper and not deployed for various reasons. Also they would require an even larger IW to work well. Best, Jerry > > Thanks, > =A0-John > From david.borman@windriver.com Wed Nov 17 11:02:07 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 353353A69AD for ; Wed, 17 Nov 2010 11:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.495 X-Spam-Level: X-Spam-Status: No, score=-103.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGgTCQJU3IOA for ; Wed, 17 Nov 2010 11:02:05 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id E42523A69A4 for ; Wed, 17 Nov 2010 11:02:04 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id oAHJ2iM8002772; Wed, 17 Nov 2010 11:02:45 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Nov 2010 11:02:44 -0800 Received: from [172.25.34.29] ([172.25.34.29]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Nov 2010 11:02:44 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: David Borman In-Reply-To: <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> Date: Wed, 17 Nov 2010 13:02:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> To: Alexander Zimmermann X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 17 Nov 2010 19:02:44.0526 (UTC) FILETIME=[044264E0:01CB868A] Cc: tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 19:02:07 -0000 I've been thinking about the whole IW issue, and trying to step back a = bit from IW itself. So I ask myself, what is the main issue with having = a large IW? If the network has the bandwidth, there isn't any practical = problem. But if the network doesn't have the bandwidth, a bunch of TCP = connections starting up with a larger IW can lead to congestion. So = then I ask myself, what is wrong with congestion? The data is going to = back up somewhere, so does it matter? Of course, the answer is that = yes, it does matter, because we don't have a lossless network. When = there is congestion in routers, if there isn't enough buffering, the way = to deal with that is to drop packets, which in turn leads to = retransmissions. But I don't think it is congestion itself and the dropping of packets = that is the problem, the issue is we don't want that congestion to turn = into congestion collapse. So, it seems to me that the issue about = whether or not it is safe to increase the IW should be focused more on, = if increasing the IW leads to increased congestion, is the network still = able to properly respond to that congestion and avoid congestion = collapse? If the answer is "yes", then I think that greatly reduces the = risks of increasing the IW. But if the answer is "no", then we have a = bigger problem that is lying in wait and can be triggered by other = factors than just increasing the IW. -David Borman On Nov 17, 2010, at 1:58 AM, Alexander Zimmermann wrote: > Hi Richard, >=20 > exactly, this is the point! >=20 > IMO, two things are crystal clear: >=20 > 1. We have to touch/increase the IW > 2. We have to do it now >=20 > Also, IMO he have a rough consensus on these two points. >=20 > What I like two see now, or discuss now, is a strategy how we can = progress. >=20 > Mark proposed something, but what are thoughts from the document = author/ > other group members/chairs/AD on this point? >=20 > Alex >=20 > Am 16.11.2010 um 17:41 schrieb Scheffenegger, Richard: >=20 >>=20 >> Group, >>=20 >> Just one additional data point: Obviously, there are already = applications in the wild, that use persistent connections and disable = the slow-start-restart mechanism on these sessions. The expectations of = the programmers making use of these socket options is to reduce the = latency for their appliaction... In effect, these Apps seem use IW=3D44 = (and hurting themselves more than anybody else). >>=20 >> See "Profiling Network Performance in Multi-Tier Data Center = Applications", Section 6.1, "cwnd failing to prevent sudden bursts", = http://www.cs.princeton.edu/~jrex/papers/snap10.pdf >>=20 >>=20 >> IMHO this is evidence that some action in this space is absolutely = needed (even if it is "only" strong advice to apps programmers), or = there will be even more proliferation of clumsy workarounds that are = even less well understood and investigated than IW10 already is. Keeping = IW3 "forever" may be more problematic than addressing emerging = application needs with well-tested transport-layer approaches... >>=20 >>=20 >> Richard Scheffenegger >>=20 >>=20 >>> -----Original Message----- >>> From: Fred Baker [mailto:fred@cisco.com]=20 >>> Sent: Dienstag, 16. November 2010 15:10 >>> To: "Ilpo J=E4rvinen" >>> Cc: tcpm; tmrg >>> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >>>=20 >>>=20 >>> On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote: >>>=20 >>>> On Tue, 16 Nov 2010, Fred Baker wrote: >>>>=20 >>>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: >>>>>=20 >>>>>> I wonder what factors will argue that the initial quantum=20 >>> can't be changed? >>>>>> Someone has argued in the past IW10 effectively "disable=20 >>> CC algorithm". >>>>>> But haven't we already done that years ago when moving up=20 >>> IW from 1=20 >>>>>> to 3 if one insisted then that the initial quantum must be 1? >>>>>=20 >>>>> Actually, no. I may be the person who said that this effectively=20= >>>>> disables congestion control in the average case; my reason=20 >>> for saying=20 >>>>> that is that per what little data I have, the average TCP=20 >>> transfer is=20 >>>>> on the order of 15K bytes, which is about ten 1460 byte segments. >>>>=20 >>>> It only "disables" it if there was no congestion to control in the=20= >>>> first place. >>>=20 >>> How do you turn off something that's not on? >>>=20 >>> I refer to this as in the average case turning off congestion=20 >>> control because the transmission requires ten data packets=20 >>> and they all get sent in a single burst. There is no=20 >>> congestion control, with IW=3D10, in the case of the=20 >>> average-sized (which is actually gar above the median-sized)=20 >>> file transfer. >>>=20 >>>> Could you on your behalf answer how does IW=3D3 affect=20 >>> parallel sessions=20 >>>> on the same kind of environment? ...I've done research on this (and=20= >>>> Jerry has >>>> too) and I know that the answer is not an intuitive one. Then we=20 >>>> changed to IW10 in the same environment and observe no (consistent)=20= >>>> change. The results are driven by problems already with IW3 so IW10=20= >>>> won't make it any worse or the effect is just too small to=20 >>> be measured=20 >>>> among the other troubles that happen. >>>=20 >>> That may be true. I have asked to see data describing the=20 >>> impact. I haven't seen the data. Maybe I missed something? >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22222 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From hkchu@google.com Wed Nov 17 11:28:34 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B033A6989 for ; Wed, 17 Nov 2010 11:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.725 X-Spam-Level: X-Spam-Status: No, score=-105.725 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLKFO8VRxlU6 for ; Wed, 17 Nov 2010 11:28:11 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CEF653A698E for ; Wed, 17 Nov 2010 11:27:46 -0800 (PST) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id oAHJRpX9030060 for ; Wed, 17 Nov 2010 11:27:51 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290022071; bh=JoA0y03aIIHqbhLmYQ6s19I8EL4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=N6t73liA26+xvKoV8Z3s0KL3BnOIOg2OBNBd+OJg6TnkOh2uJ3d4MR13WJNI0oT/K BEjMwQqChsRb6EPloBuKw== Received: from yxg6 (yxg6.prod.google.com [10.190.2.134]) by kpbe15.cbf.corp.google.com with ESMTP id oAHJP5dm009435 for ; Wed, 17 Nov 2010 11:27:50 -0800 Received: by yxg6 with SMTP id 6so1716566yxg.26 for ; Wed, 17 Nov 2010 11:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GnnRU9Uy8G2Iptza3gUTnuIrxezyf+02As3WBVXrsGc=; b=UQ7VBwHn2tm4bwHotJpgiHp/JIoBu/SiwQHfcx2elpB127p4oJUPWWz51pa4CzeUPU 32lkNo98aFhYP9HrIMww== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uob5nu3rQhIIxud/t3DI5Z1oQ38mLcY0OQiQ/vytQMidv3k/TfIfzE+ElFuWmgOPa8 tFHpcchthHHkSYSA09+Q== MIME-Version: 1.0 Received: by 10.150.228.16 with SMTP id a16mr14606886ybh.177.1290022069555; Wed, 17 Nov 2010 11:27:49 -0800 (PST) Received: by 10.151.158.13 with HTTP; Wed, 17 Nov 2010 11:27:49 -0800 (PST) In-Reply-To: References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> Date: Wed, 17 Nov 2010 11:27:49 -0800 Message-ID: From: Jerry Chu To: Fred Baker Content-Type: multipart/alternative; boundary=000e0cd47d9635575c049544ab65 X-System-Of-Record: true Cc: tcpm , tmrg Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 19:28:36 -0000 --000e0cd47d9635575c049544ab65 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 15, 2010 at 8:07 PM, Fred Baker wrote: > > On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > > > I wonder what factors will argue that the initial quantum can't be > changed? > > Someone has argued in the past IW10 effectively "disable CC algorithm". > > But haven't we already done that years ago when moving up IW from 1 to 3 > if > > one insisted then that the initial quantum must be 1? > > Actually, no. I may be the person who said that this effectively disables > congestion control in the average case; my reason for saying that is that > per what little data I have, the average TCP transfer is on the order of 15K > bytes, which is about ten 1460 byte segments. > > Now, the median is much smaller - on the order of two or three data > segments each direction, which is where you get your comment. But the fact > that browsers, Bittorrent, and other applications open multiple sessions > simultaneously argues that a given endpoint having multiple packets in > flight simultaneously doesn't hurt, and research done at the time by Mark > Allman and others showed that IW=2..4 wasn't a problem and did in fact > reduce the median session to a single RTT for data. But the median session > doesn't create a congestion problem. > > The question I have been asking is how IW=10 affects parallel sessions on > relatively low speed links. My sense is that the sudden arrival of O(15K) > bytes at a 56 KBPS line, which is to say the insertion of a tad over two > seconds delay in all competing sessions plus an increase in their > probability of loss, is likely to cause them all to be disrupted. You told > me verbally that in your tests it is net beneficial to the parallel > sessions, but in thought experiments I'm not sure how that can be true; I'd > be Perhaps you've missed something in your thought process? In addition to some points Ilpo has made in his reply, another plausible explanation that you may not have considered is that for the same amount of data to be transfered, IW10 is simply more "efficient" in average than IW3. It is true that IW10 causes a larger burst to be sent, but it is not like you're going to get the same frequency of 10-pkt bursts as compared to 3-pkt bursts. The comparison is more like a single large burst vs three smaller bursts. It's not clear to me one can actually prove the single large burst will often cause more damage to competing flows than 3 smaller bursts and our testbed sorta confirmed this. Jerry > fascinated to see the data that shows that competing voice/video sees no > frame loss or induced noise, that competing file transfers slow down but do > not see redundant retransmissions, and so on. > > So, IW=2..4 demonstrably works pretty well everywhere, but IW=10 seems to > me only sensible on MPBS and GBPS, not KBPS, scale links. --000e0cd47d9635575c049544ab65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 15, 2010 at 8:07 PM, Fred Baker <fred@cisco.com> wrote:

On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote:

> I wonder what factors will argue that the initial quantum can't be= changed?
> Someone has argued in the past IW10 effectively "disable CC algor= ithm".
> But haven't we already done that years ago when moving up IW from = 1 to 3 if
> one insisted then that the initial quantum must be 1?

Actually, no. I may be the person who said that this effectively disa= bles congestion control in the average case; my reason for saying that is t= hat per what little data I have, the average TCP transfer is on the order o= f 15K bytes, which is about ten 1460 byte segments.

Now, the median is much smaller - on the order of two or three data segment= s each direction, which is where you get your comment. But the fact that br= owsers, Bittorrent, and other applications open multiple sessions simultane= ously argues that a given endpoint having multiple packets in flight simult= aneously doesn't hurt, and research done at the time by Mark Allman and= others showed that IW=3D2..4 wasn't a problem and did in fact reduce t= he median session to a single RTT for data. But the median session doesn= 9;t create a congestion problem.

The question I have been asking is how IW=3D10 affects parallel sessions on= relatively low speed links. My sense is that the sudden arrival of O(15K) = bytes at a 56 KBPS line, which is to say the insertion of a tad over two se= conds delay in all competing sessions plus an increase in their probability= of loss, is likely to cause them all to be disrupted. You told me verbally= that in your tests it is net beneficial to the parallel sessions, but in t= hought experiments I'm not sure how that can be true; I'd be

Perhaps you've missed something in your thought pro= cess? In addition to some points
Ilpo has made in his reply, anot= her plausible explanation that you may not have
considered is tha= t for the same=A0amount of data to be transfered, IW10 is simply more
"efficient" in average than IW3. It is true that IW10 causes= a larger burst to be sent,
but it is not like you're going t= o get the same frequency of 10-pkt bursts as compared
to=A03-pkt = bursts. The comparison is more like a single large burst vs three smaller
bursts. It's not clear to me one can actually prove the single lar= ge burst will often
cause=A0more=A0damage to competing flows than= 3 smaller bursts and our testbed sorta
confirmed this.

Jerry
=A0
fas= cinated to see the data that shows that competing voice/video sees no frame= loss or induced noise, that competing file transfers slow down but do not = see redundant retransmissions, and so on.

So, IW=3D2..4 demonstrably works pretty well everywhere, but IW=3D10 seems = to me only sensible on MPBS and GBPS, not KBPS, scale links.
<= /div>
--000e0cd47d9635575c049544ab65-- From ycheng@google.com Wed Nov 17 11:29:36 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E613A699D for ; Wed, 17 Nov 2010 11:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.826 X-Spam-Level: X-Spam-Status: No, score=-109.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgHilSqqX2kL for ; Wed, 17 Nov 2010 11:29:34 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D219B3A6954 for ; Wed, 17 Nov 2010 11:29:17 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id oAHJU2QW008687 for ; Wed, 17 Nov 2010 11:30:03 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290022203; bh=FhKwI5lysl/IopBYl6BC/LMWGtI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=HMQVZXu/H45nPid8YsbkD25hdyCpGk6hFotnDkHV32y0e1FEjhEY5R+NFyQM6vcdk jc092V8LPDUwtvRb4xLYw== Received: from qwf7 (qwf7.prod.google.com [10.241.194.71]) by wpaz17.hot.corp.google.com with ESMTP id oAHJT4xp002871 for ; Wed, 17 Nov 2010 11:30:01 -0800 Received: by qwf7 with SMTP id 7so1206904qwf.15 for ; Wed, 17 Nov 2010 11:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=SaeR+FEntXLMKt9iPyyHFXvbJQuds7ZdRm43r5cFBYA=; b=qkDmJ9bC7a0gFwGakFi9ftOZtzIH7qwZkacvV/WAIngHOVRDwxDC7hPHqQHCCt7QiA I5X17WUssgWl9lmckEsA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=XjylQcPfS06bF9Y33FDcI3muFiTLFIFlLrVc/fCs4vY0p8ic6KQQx8805h39s/Sffe eWue/dtgksvNVWuYCZcQ== Received: by 10.224.11.77 with SMTP id s13mr7181127qas.9.1290022200800; Wed, 17 Nov 2010 11:30:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Wed, 17 Nov 2010 11:29:38 -0800 (PST) In-Reply-To: References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> From: Yuchung Cheng Date: Wed, 17 Nov 2010 11:29:38 -0800 Message-ID: To: Fred Baker Content-Type: multipart/alternative; boundary=0015175cd62a08180f049544b3cb X-System-Of-Record: true Cc: tmrg , tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 19:29:36 -0000 --0015175cd62a08180f049544b3cb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2010 at 6:09 AM, Fred Baker wrote: > > On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote: > > > On Tue, 16 Nov 2010, Fred Baker wrote: > > > >> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > >> > >>> I wonder what factors will argue that the initial quantum can't be > changed? > >>> Someone has argued in the past IW10 effectively "disable CC algorithm= ". > >>> But haven't we already done that years ago when moving up IW from 1 t= o > 3 if > >>> one insisted then that the initial quantum must be 1? > >> > >> Actually, no. I may be the person who said that this effectively > >> disables congestion control in the average case; my reason for saying > >> that is that per what little data I have, the average TCP transfer is = on > >> the order of 15K bytes, which is about ten 1460 byte segments. > > > > It only "disables" it if there was no congestion to control in the firs= t > > place. > > How do you turn off something that's not on? > > I refer to this as in the average case turning off congestion control > because the transmission requires ten data packets and they all get sent = in > a single burst. There is no congestion control, with IW=3D10, in the case= of > the average-sized (which is actually gar above the median-sized) file > transfer. > There surely is CC involved even if app only sends < 10 packets and some packets got dropped. > > Could you on your behalf answer how does IW=3D3 affect parallel sessio= ns > on > > the same kind of environment? ...I've done research on this (and Jerry > has > > too) and I know that the answer is not an intuitive one. Then we change= d > > to IW10 in the same environment and observe no (consistent) change. The > > results are driven by problems already with IW3 so IW10 won't make it a= ny > > worse or the effect is just too small to be measured among the other > > troubles that happen. > > That may be true. I have asked to see data describing the impact. I haven= 't > seen the data. Maybe I missed something? > The NCSU lab has released the raw test data (result presented in IETF). http://research.csc.ncsu.edu/netsrv/?q=3Dcontent/iw10#data > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0015175cd62a08180f049544b3cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 16, 2010 at 6:09 AM, Fred Baker <fred@cisco.com><= /span> wrote:

On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote:

> On Tue, 16 Nov 2010, Fred Baker wrote:
>
>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote:
>>
>>> I wonder what factors will argue that the initial quantum can&= #39;t be changed?
>>> Someone has argued in the past IW10 effectively "disable = CC algorithm".
>>> But haven't we already done that years ago when moving up = IW from 1 to 3 if
>>> one insisted then that the initial quantum must be 1?
>>
>> Actually, no. I may be the person who said that this effectively >> disables congestion control in the average case; my reason for say= ing
>> that is that per what little data I have, the average TCP transfer= is on
>> the order of 15K bytes, which is about ten 1460 byte segments.
>
> It only "disables" it if there was no congestion to control = in the first
> place.

How do you turn off something that's not on?

I refer to this as in the average case turning off congestion control becau= se the transmission requires ten data packets and they all get sent in a si= ngle burst. There is no congestion control, with IW=3D10, in the case of th= e average-sized (which is actually gar above the median-sized) file transfe= r.
There surely is CC involved even if app only sends < 1= 0 packets and some packets got dropped.

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">
> Could you on your behalf answer how does IW=3D3 affect parallel sessio= ns on
> the same kind of environment? ...I've done research on this (and J= erry has
> too) and I know that the answer is not an intuitive one. Then we chang= ed
> to IW10 in the same environment and observe no (consistent) change. Th= e
> results are driven by problems already with IW3 so IW10 won't make= it any
> worse or the effect is just too small to be measured among the other > troubles that happen.

That may be true. I have asked to see data describing the impact. I h= aven't seen the data. Maybe I missed something?
Th= e NCSU lab has released the raw test data (result presented in IETF).
= =A0
_________________________________________= ______
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--0015175cd62a08180f049544b3cb-- From hkchu@google.com Wed Nov 17 11:38:50 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7AC3A69A2 for ; Wed, 17 Nov 2010 11:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.761 X-Spam-Level: X-Spam-Status: No, score=-105.761 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afYkm0-mEZG2 for ; Wed, 17 Nov 2010 11:38:49 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 80F203A698C for ; Wed, 17 Nov 2010 11:38:49 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id oAHJdZdO018432 for ; Wed, 17 Nov 2010 11:39:35 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290022775; bh=hGUk+bwPNhR9pKXwsOBDO59HJ88=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=AWFeBYtGVFGVeDBk70ALxQ/yoqw3GDFuRH83jINTNUyID8zD16+fc8mrNZ2XITnkF qw71MNb1oeXqfEOwE6VKA== Received: from gyh3 (gyh3.prod.google.com [10.243.50.195]) by wpaz33.hot.corp.google.com with ESMTP id oAHJcsIR001585 for ; Wed, 17 Nov 2010 11:39:34 -0800 Received: by gyh3 with SMTP id 3so1395809gyh.28 for ; Wed, 17 Nov 2010 11:39:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GqOVTM9dH4iPiY7Dpr2erSvWG2psh0RdUcuj8lIqDrM=; b=WMjIrUkEFg2yVYTRO6xmdJokx+QbMzm4RkHac7NeQeDpi4ZES0xIb+xrE7p0+2IKp6 xLYjn/VsOHhwDWt32ryg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fMtRMnuvNGjIsplLXOs8QO7qnGyIi0UXyspQL477WlZS6DNMuD0c8W84j3Ru8m6MjC DaM8vTSv88fjbYTK8hbg== MIME-Version: 1.0 Received: by 10.150.147.3 with SMTP id u3mr14792920ybd.234.1290022773895; Wed, 17 Nov 2010 11:39:33 -0800 (PST) Received: by 10.151.158.13 with HTTP; Wed, 17 Nov 2010 11:39:33 -0800 (PST) In-Reply-To: References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> Date: Wed, 17 Nov 2010 11:39:33 -0800 Message-ID: From: Jerry Chu To: Fred Baker Content-Type: multipart/alternative; boundary=000e0cdf144030b6b3049544d5b9 X-System-Of-Record: true Cc: tmrg , tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 19:38:51 -0000 --000e0cdf144030b6b3049544d5b9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2010 at 6:09 AM, Fred Baker wrote: > > On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote: > > > On Tue, 16 Nov 2010, Fred Baker wrote: > > > >> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > >> > >>> I wonder what factors will argue that the initial quantum can't be > changed? > >>> Someone has argued in the past IW10 effectively "disable CC algorithm= ". > >>> But haven't we already done that years ago when moving up IW from 1 t= o > 3 if > >>> one insisted then that the initial quantum must be 1? > >> > >> Actually, no. I may be the person who said that this effectively > >> disables congestion control in the average case; my reason for saying > >> that is that per what little data I have, the average TCP transfer is = on > >> the order of 15K bytes, which is about ten 1460 byte segments. > > > > It only "disables" it if there was no congestion to control in the firs= t > > place. > > How do you turn off something that's not on? > > I refer to this as in the average case turning off congestion control > because the transmission requires ten data packets and they all get sent = in > a single burst. There is no congestion control, with IW=3D10, in the case= of > the average-sized (which is actually gar above the median-sized) file > transfer. > > > Could you on your behalf answer how does IW=3D3 affect parallel session= s on > > the same kind of environment? ...I've done research on this (and Jerry > has > > too) and I know that the answer is not an intuitive one. Then we change= d > > to IW10 in the same environment and observe no (consistent) change. The > > results are driven by problems already with IW3 so IW10 won't make it a= ny > > worse or the effect is just too small to be measured among the other > > troubles that happen. > > That may be true. I have asked to see data describing the impact. I haven= 't > seen the data. Maybe I missed something? Have you chosen not to see the data, or you've simply forgot we've done som= e testbed study with results presented at TCPM (which you missed due to prior engagement)? One of the purposes for this round of our testbed study was to investigate the questions you've raised. If you have still issues with the result, e.g., you have a different set of parameters in mind than what were used by our tests, please spell them out and we can hopefully get the results for you quickly (well I'm still in travel so it may take a couple of weeks). Jerry --000e0cdf144030b6b3049544d5b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2010 at 6:09 AM, Fred Baker <fred@cisco.com> wrote:

On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote:

> On Tue, 16 Nov 2010, Fred Baker wrote:
>
>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote:
>>
>>> I wonder what factors will argue that the initial quantum can&= #39;t be changed?
>>> Someone has argued in the past IW10 effectively "disable = CC algorithm".
>>> But haven't we already done that years ago when moving up = IW from 1 to 3 if
>>> one insisted then that the initial quantum must be 1?
>>
>> Actually, no. I may be the person who said that this effectively >> disables congestion control in the average case; my reason for say= ing
>> that is that per what little data I have, the average TCP transfer= is on
>> the order of 15K bytes, which is about ten 1460 byte segments.
>
> It only "disables" it if there was no congestion to control = in the first
> place.

How do you turn off something that's not on?

I refer to this as in the average case turning off congestion control becau= se the transmission requires ten data packets and they all get sent in a si= ngle burst. There is no congestion control, with IW=3D10, in the case of th= e average-sized (which is actually gar above the median-sized) file transfe= r.

> Could you on your behalf answer how does IW=3D3 affect parallel sessio= ns on
> the same kind of environment? ...I've done research on this (and J= erry has
> too) and I know that the answer is not an intuitive one. Then we chang= ed
> to IW10 in the same environment and observe no (consistent) change. Th= e
> results are driven by problems already with IW3 so IW10 won't make= it any
> worse or the effect is just too small to be measured among the other > troubles that happen.

That may be true. I have asked to see data describing the impact. I h= aven't seen the data. Maybe I missed something?

Have you chosen not to see the data, or you've simply forgot w= e've done some testbed
study with results presented at TCPM (which you missed due to prior en= gagement)?

One of the purposes for this round of o= ur testbed study was to investigate the questions
you've rais= ed. If you have still issues with the result, e.g., you have a different se= t of
parameters in mind than what were used by our tests, please spell them= out and we
can hopefully get the results for you quickly (well I= 'm still in travel so it may take a
couple of weeks).

Jerry

--000e0cdf144030b6b3049544d5b9-- From hkchu@google.com Wed Nov 17 12:19:43 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 813463A696C for ; Wed, 17 Nov 2010 12:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.977 X-Spam-Level: X-Spam-Status: No, score=-109.977 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_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5Jq5+GT90Gz for ; Wed, 17 Nov 2010 12:19:41 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 17CD03A695F for ; Wed, 17 Nov 2010 12:19:40 -0800 (PST) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id oAHKKPJ0017766 for ; Wed, 17 Nov 2010 12:20:26 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290025226; bh=iBYOZbRZC7Yf2tBejBU2Ivj5PD0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Zxi9H0ASyB3bTwGM3BUvutXc/ZehYwmkiPIXJjXz414K/5RlF9sB0Uhq9nWqcVkYW IJgnNuPDbDUGoMWMylv2A== Received: from gwb15 (gwb15.prod.google.com [10.200.2.15]) by kpbe19.cbf.corp.google.com with ESMTP id oAHKK3qS029858 for ; Wed, 17 Nov 2010 12:20:24 -0800 Received: by gwb15 with SMTP id 15so1586251gwb.35 for ; Wed, 17 Nov 2010 12:20:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=BKgfLNwsDSrdOgn93SDaNjkfIef3nc3m9UcaaVZmZLw=; b=PQGKuo0JnSglnt48TzbqRG35BahniNh6bnbfD5hNDQG9MQZJRjHC1VLNJXQonq0a4X nSuwn6Fei01uPTVJN4Lg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ilXYaaewLOh53qwEE4foxU4UFx1yvZBY7+QVrZpXMHwsVaDPAMll7+1G0tsq0yRbpi xXbpxthcD5yfhLAI/dvw== MIME-Version: 1.0 Received: by 10.150.53.2 with SMTP id b2mr14589200yba.348.1290025223044; Wed, 17 Nov 2010 12:20:23 -0800 (PST) Received: by 10.151.158.13 with HTTP; Wed, 17 Nov 2010 12:20:22 -0800 (PST) In-Reply-To: <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> Date: Wed, 17 Nov 2010 12:20:22 -0800 Message-ID: From: Jerry Chu To: Alexander Zimmermann Content-Type: multipart/alternative; boundary=000e0cd310742bc0d1049545671d X-System-Of-Record: true Cc: tcpm , "david.borman@windriver.com Borman" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 20:19:43 -0000 --000e0cd310742bc0d1049545671d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2010 at 11:58 PM, Alexander Zimmermann < alexander.zimmermann@comsys.rwth-aachen.de> wrote: > Hi Richard, > > exactly, this is the point! > > IMO, two things are crystal clear: > > 1. We have to touch/increase the IW > 2. We have to do it now > > Also, IMO he have a rough consensus on these two points. > > What I like two see now, or discuss now, is a strategy how we can progres= s. > > Mark proposed something, but what are thoughts from the document author/ > other group members/chairs/AD on this point? > (Sorry for slow in response due to traveling and limited communication with my other colleagues.) I like the idea in that it is consistent with our belief that IW needs to b= e scaled up over time but there are some details/feasibility/execution that need to be thought out. Also 3 years seems a long time. Remember IW10 has been in active experiments for more than a year at Google and some other places. More later, Jerry > Alex > > Am 16.11.2010 um 17:41 schrieb Scheffenegger, Richard: > > > > > Group, > > > > Just one additional data point: Obviously, there are already applicatio= ns > in the wild, that use persistent connections and disable the > slow-start-restart mechanism on these sessions. The expectations of the > programmers making use of these socket options is to reduce the latency f= or > their appliaction... In effect, these Apps seem use IW=3D44 (and hurting > themselves more than anybody else). > > > > See "Profiling Network Performance in Multi-Tier Data Center > Applications", Section 6.1, "cwnd failing to prevent sudden bursts", > http://www.cs.princeton.edu/~jrex/papers/snap10.pdf > > > > > > IMHO this is evidence that some action in this space is absolutely need= ed > (even if it is "only" strong advice to apps programmers), or there will b= e > even more proliferation of clumsy workarounds that are even less well > understood and investigated than IW10 already is. Keeping IW3 "forever" m= ay > be more problematic than addressing emerging application needs with > well-tested transport-layer approaches... > > > > > > Richard Scheffenegger > > > > > >> -----Original Message----- > >> From: Fred Baker [mailto:fred@cisco.com] > >> Sent: Dienstag, 16. November 2010 15:10 > >> To: "Ilpo J=E4rvinen" > >> Cc: tcpm; tmrg > >> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > >> > >> > >> On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote: > >> > >>> On Tue, 16 Nov 2010, Fred Baker wrote: > >>> > >>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > >>>> > >>>>> I wonder what factors will argue that the initial quantum > >> can't be changed? > >>>>> Someone has argued in the past IW10 effectively "disable > >> CC algorithm". > >>>>> But haven't we already done that years ago when moving up > >> IW from 1 > >>>>> to 3 if one insisted then that the initial quantum must be 1? > >>>> > >>>> Actually, no. I may be the person who said that this effectively > >>>> disables congestion control in the average case; my reason > >> for saying > >>>> that is that per what little data I have, the average TCP > >> transfer is > >>>> on the order of 15K bytes, which is about ten 1460 byte segments. > >>> > >>> It only "disables" it if there was no congestion to control in the > >>> first place. > >> > >> How do you turn off something that's not on? > >> > >> I refer to this as in the average case turning off congestion > >> control because the transmission requires ten data packets > >> and they all get sent in a single burst. There is no > >> congestion control, with IW=3D10, in the case of the > >> average-sized (which is actually gar above the median-sized) > >> file transfer. > >> > >>> Could you on your behalf answer how does IW=3D3 affect > >> parallel sessions > >>> on the same kind of environment? ...I've done research on this (and > >>> Jerry has > >>> too) and I know that the answer is not an intuitive one. Then we > >>> changed to IW10 in the same environment and observe no (consistent) > >>> change. The results are driven by problems already with IW3 so IW10 > >>> won't make it any worse or the effect is just too small to > >> be measured > >>> among the other troubles that happen. > >> > >> That may be true. I have asked to see data describing the > >> impact. I haven't seen the data. Maybe I missed something? > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > >> > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science, Informatik 4 > // RWTH Aachen University > // Ahornstr. 55, 52056 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22222 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // > > --000e0cd310742bc0d1049545671d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2010 at 11:58 PM, Alexander Zimmermann &l= t;alexander.z= immermann@comsys.rwth-aachen.de> wrote:
Hi Richard,

exactly, this is the point!

IMO, two things are crystal clear:

1. We have to touch/increase the IW
2. We have to do it now

Also, IMO he have a rough consensus on these two points.

What I like two see now, or discuss now, is a strategy how we can progress.=

Mark proposed something, but what are thoughts from the document author/ other group members/chairs/AD on this point?

(Sorry for slow in response due to traveling and limited communicatio= n with my
other colleagues.)

I like the = idea in that it is consistent with our belief that IW needs to be
scaled up over time but there are some details/feasibility/execution t= hat need
to be=A0thought out.

Also 3 yea= rs seems a long time. Remember IW10 has been in active=A0experiments=A0for = more than a year at Google and some other places.

More later,

Jerry

Alex

Am 16.11.2010 um 17:41 schrieb Scheffenegger, Richard:

>
> Group,
>
> Just one additional data point: Obviously, there are already applicati= ons in the wild, that use persistent connections and disable the slow-start= -restart mechanism on these sessions. The expectations of the programmers m= aking use of these socket options is to reduce the latency for their applia= ction... In effect, these Apps seem use IW=3D44 (and hurting themselves mor= e than anybody else).
>
> See "Profiling Network Performance in Multi-Tier Data Center Appl= ications", Section 6.1, "cwnd failing to prevent sudden bursts&qu= ot;, http://www.cs.princeton.edu/~jrex/papers/snap10.pdf
>
>
> IMHO this is evidence that some action in this space is absolutely nee= ded (even if it is "only" strong advice to apps programmers), or = there will be even more proliferation of clumsy workarounds that are even l= ess well understood and investigated than IW10 already is. Keeping IW3 &quo= t;forever" may be more problematic than addressing emerging applicatio= n needs with well-tested transport-layer approaches...
>
>
> Richard Scheffenegger
>
>
>> -----Original Message-----
>> From: Fred Baker [mailto:fred@ci= sco.com]
>> Sent: Dienstag, 16. November 2010 15:10
>> To: "Ilpo J=E4rvinen"
>> Cc: tcpm; tmrg
>> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >>
>>
>> On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote:
>>
>>> On Tue, 16 Nov 2010, Fred Baker wrote:
>>>
>>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote:
>>>>
>>>>> I wonder what factors will argue that the initial quan= tum
>> can't be changed?
>>>>> Someone has argued in the past IW10 effectively "= disable
>> CC algorithm".
>>>>> But haven't we already done that years ago when mo= ving up
>> IW from 1
>>>>> to 3 if one insisted then that the initial quantum mus= t be 1?
>>>>
>>>> Actually, no. I may be the person who said that this effec= tively
>>>> disables congestion control in the average case; my reason=
>> for saying
>>>> that is that per what little data I have, the average TCP<= br> >> transfer is
>>>> on the order of 15K bytes, which is about ten 1460 byte se= gments.
>>>
>>> It only "disables" it if there was no congestion to = control in the
>>> first place.
>>
>> How do you turn off something that's not on?
>>
>> I refer to this as in the average case turning off congestion
>> control because the transmission requires ten data packets
>> and they all get sent in a single burst. There is no
>> congestion control, with IW=3D10, in the case of the
>> average-sized (which is actually gar above the median-sized)
>> file transfer.
>>
>>> Could you on your behalf answer how does IW=3D3 affect
>> parallel sessions
>>> on the same kind of environment? ...I've done research on = this (and
>>> Jerry has
>>> too) and I know that the answer is not an intuitive one. Then = we
>>> changed to IW10 in the same environment and observe no (consis= tent)
>>> change. The results are driven by problems already with IW3 so= IW10
>>> won't make it any worse or the effect is just too small to=
>> be measured
>>> among the other troubles that happen.
>>
>> That may be true. I have asked to see data describing the
>> impact. I haven't seen the data. Maybe I missed something?
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

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


--000e0cd310742bc0d1049545671d-- From mallman@icir.org Wed Nov 17 12:36:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88FD03A696C for ; Wed, 17 Nov 2010 12:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xDMcle4aiOd for ; Wed, 17 Nov 2010 12:36:40 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id DB1BF3A6965 for ; Wed, 17 Nov 2010 12:36:39 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAHKbMiF026580; Wed, 17 Nov 2010 12:37:22 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1E6112520B30; Wed, 17 Nov 2010 15:37:22 -0500 (EST) To: David Borman From: Mark Allman In-Reply-To: <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Hey Tonight MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma15617-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 17 Nov 2010 15:37:22 -0500 Sender: mallman@icir.org Message-Id: <20101117203722.1E6112520B30@lawyers.icir.org> Cc: tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 20:36:45 -0000 ----------ma15617-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline David- > But I don't think it is congestion itself and the dropping of packets > that is the problem, the issue is we don't want that congestion to > turn into congestion collapse. So, it seems to me that the issue > about whether or not it is safe to increase the IW should be focused > more on, if increasing the IW leads to increased congestion, is the > network still able to properly respond to that congestion and avoid > congestion collapse? If the answer is "yes", then I think that > greatly reduces the risks of increasing the IW. But if the answer is > "no", then we have a bigger problem that is lying in wait and can be > triggered by other factors than just increasing the IW. I think the answer is pretty obviously "no". We are not taking the reaction to congestion away at all and *that* is the important part in preventing collapse. In other words, left alone, TCP will keep reducing the rate at which it tries to recover (via the window and ultimately via RTO backoff). This is what I mean when I have said that changing the initial cwnd does not eliminate congestion control. Second, remember that we know that most of the traffic volume is large flows. And, initial settings in large flows are pretty meaningless. Further, there are plenty of flows that aren't even 15KB. So, there would have to be some scenario whereby some number of medium-sized flows that are not taking a large chunk of the bandwidth would collapse the network. That seems hard to see. The only scenario I can come up with that even starts us down the road towards collapse is the case where a connection uses a 10 segment initial window and takes some loss and the user gets impatient and hits reload to give it another shot. In that case, the packets that made it through in the first connection *wasted* scarce network resources (i.e., made it across the congested link) and yet ultimately accomplished no useful work. However, I don't buy this as a very likely scenario because if you play out sending 10 packets with IW=3 and IW=10 in a network that can only handle 3 packets the transfer times are pretty comparable (I did this last night on the TMRG list) with the IW10 connection longer by roughly one RTO. So, if we're worried about user impatience with IW10 then we should worry about it with IW3, too. allman ----------ma15617-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzkPQEACgkQWyrrWs4yIs6h2QCeIn/4ZyzEmANBh0cghLNE4JYZ fNEAn1nwr4g3anCNWiRuFV2m9pllejsx =uO1j -----END PGP SIGNATURE----- ----------ma15617-1-- From jakob.heitz@ericsson.com Wed Nov 17 12:41:03 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6973A6987 for ; Wed, 17 Nov 2010 12:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufQbzkRqPf+o for ; Wed, 17 Nov 2010 12:41:02 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id E72493A698F for ; Wed, 17 Nov 2010 12:41:01 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oAHL6lRQ023119 for ; Wed, 17 Nov 2010 15:06:48 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.213]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 17 Nov 2010 15:41:41 -0500 From: Jakob Heitz To: tcpm Date: Wed, 17 Nov 2010 15:41:39 -0500 Thread-Topic: [tcpm] [Tmrg] Increasing the Initial Window - Notes Thread-Index: AcuGikCHh9emoSSGSgC8Kw6LLSUUFwADVryA Message-ID: <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> In-Reply-To: <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 20:41:03 -0000 IMHO: If you think a small TCP IW is protecting any network from congestion collapse, you are either living in the past or under delusions of grandeur. Today's networks are under greater threat from many protocols that have no respect for congestion control at all and would collapse immediately without QOS. TCP IW protects the TCP session itself. The problem with TCP is that if it drops too many packets, it grinds to a halt. That is to be avoided at all costs. A small IW helps to avoid that. Of course too small an IW makes it take too long to ramp up. There is no good way to find the optimum. The best seems to be history of previous connections. It probably should not even be standardized. Remove the IW recommendation from the standard and let each implementation figure out its own optimum. -- Jakob Heitz. =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of David Borman > Sent: Wednesday, November 17, 2010 11:03 AM > To: Alexander Zimmermann > Cc: tcpm > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >=20 > I've been thinking about the whole IW issue, and trying to=20 > step back a bit from IW itself. So I ask myself, what is the=20 > main issue with having a large IW? If the network has the=20 > bandwidth, there isn't any practical problem. But if the=20 > network doesn't have the bandwidth, a bunch of TCP=20 > connections starting up with a larger IW can lead to=20 > congestion. So then I ask myself, what is wrong with=20 > congestion? The data is going to back up somewhere, so does=20 > it matter? Of course, the answer is that yes, it does=20 > matter, because we don't have a lossless network. When there=20 > is congestion in routers, if there isn't enough buffering,=20 > the way to deal with that is to drop packets, which in turn=20 > leads to retransmissions. >=20 > But I don't think it is congestion itself and the dropping of=20 > packets that is the problem, the issue is we don't want that=20 > congestion to turn into congestion collapse. So, it seems to=20 > me that the issue about whether or not it is safe to increase=20 > the IW should be focused more on, if increasing the IW leads=20 > to increased congestion, is the network still able to=20 > properly respond to that congestion and avoid congestion=20 > collapse? If the answer is "yes", then I think that greatly=20 > reduces the risks of increasing the IW. But if the answer is=20 > "no", then we have a bigger problem that is lying in wait and=20 > can be triggered by other factors than just increasing the IW. >=20 > -David Borman >=20 >=20 > On Nov 17, 2010, at 1:58 AM, Alexander Zimmermann wrote: >=20 > > Hi Richard, > >=20 > > exactly, this is the point! > >=20 > > IMO, two things are crystal clear: > >=20 > > 1. We have to touch/increase the IW > > 2. We have to do it now > >=20 > > Also, IMO he have a rough consensus on these two points. > >=20 > > What I like two see now, or discuss now, is a strategy how=20 > we can progress. > >=20 > > Mark proposed something, but what are thoughts from the=20 > document author/ > > other group members/chairs/AD on this point? > >=20 > > Alex > >=20 > > Am 16.11.2010 um 17:41 schrieb Scheffenegger, Richard: > >=20 > >>=20 > >> Group, > >>=20 > >> Just one additional data point: Obviously, there are=20 > already applications in the wild, that use persistent=20 > connections and disable the slow-start-restart mechanism on=20 > these sessions. The expectations of the programmers making=20 > use of these socket options is to reduce the latency for=20 > their appliaction... In effect, these Apps seem use IW=3D44=20 > (and hurting themselves more than anybody else). > >>=20 > >> See "Profiling Network Performance in Multi-Tier Data=20 > Center Applications", Section 6.1, "cwnd failing to prevent=20 > sudden bursts", http://www.cs.princeton.edu/~jrex/papers/snap10.pdf > >>=20 > >>=20 > >> IMHO this is evidence that some action in this space is=20 > absolutely needed (even if it is "only" strong advice to apps=20 > programmers), or there will be even more proliferation of=20 > clumsy workarounds that are even less well understood and=20 > investigated than IW10 already is. Keeping IW3 "forever" may=20 > be more problematic than addressing emerging application=20 > needs with well-tested transport-layer approaches... > >>=20 > >>=20 > >> Richard Scheffenegger > >>=20 > >>=20 > >>> -----Original Message----- > >>> From: Fred Baker [mailto:fred@cisco.com]=20 > >>> Sent: Dienstag, 16. November 2010 15:10 > >>> To: "Ilpo J=E4rvinen" > >>> Cc: tcpm; tmrg > >>> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > >>>=20 > >>>=20 > >>> On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote: > >>>=20 > >>>> On Tue, 16 Nov 2010, Fred Baker wrote: > >>>>=20 > >>>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > >>>>>=20 > >>>>>> I wonder what factors will argue that the initial quantum=20 > >>> can't be changed? > >>>>>> Someone has argued in the past IW10 effectively "disable=20 > >>> CC algorithm". > >>>>>> But haven't we already done that years ago when moving up=20 > >>> IW from 1=20 > >>>>>> to 3 if one insisted then that the initial quantum must be 1? > >>>>>=20 > >>>>> Actually, no. I may be the person who said that this=20 > effectively=20 > >>>>> disables congestion control in the average case; my reason=20 > >>> for saying=20 > >>>>> that is that per what little data I have, the average TCP=20 > >>> transfer is=20 > >>>>> on the order of 15K bytes, which is about ten 1460 byte=20 > segments. > >>>>=20 > >>>> It only "disables" it if there was no congestion to=20 > control in the=20 > >>>> first place. > >>>=20 > >>> How do you turn off something that's not on? > >>>=20 > >>> I refer to this as in the average case turning off congestion=20 > >>> control because the transmission requires ten data packets=20 > >>> and they all get sent in a single burst. There is no=20 > >>> congestion control, with IW=3D10, in the case of the=20 > >>> average-sized (which is actually gar above the median-sized)=20 > >>> file transfer. > >>>=20 > >>>> Could you on your behalf answer how does IW=3D3 affect=20 > >>> parallel sessions=20 > >>>> on the same kind of environment? ...I've done research=20 > on this (and=20 > >>>> Jerry has > >>>> too) and I know that the answer is not an intuitive one. Then we=20 > >>>> changed to IW10 in the same environment and observe no=20 > (consistent)=20 > >>>> change. The results are driven by problems already with=20 > IW3 so IW10=20 > >>>> won't make it any worse or the effect is just too small to=20 > >>> be measured=20 > >>>> among the other troubles that happen. > >>>=20 > >>> That may be true. I have asked to see data describing the=20 > >>> impact. I haven't seen the data. Maybe I missed something? > >>> _______________________________________________ > >>> tcpm mailing list > >>> tcpm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tcpm > >>>=20 > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > >=20 > > // > > // Dipl.-Inform. Alexander Zimmermann > > // Department of Computer Science, Informatik 4 > > // RWTH Aachen University > > // Ahornstr. 55, 52056 Aachen, Germany > > // phone: (49-241) 80-21422, fax: (49-241) 80-22222 > > // email: zimmermann@cs.rwth-aachen.de > > // web: http://www.umic-mesh.net > > // > >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From mallman@icir.org Wed Nov 17 12:58:05 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5FC3A6993 for ; Wed, 17 Nov 2010 12:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bTIhlhmpDhu for ; Wed, 17 Nov 2010 12:58:05 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id EFD043A698F for ; Wed, 17 Nov 2010 12:58:04 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAHKwoq2028434; Wed, 17 Nov 2010 12:58:50 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9271325213D8; Wed, 17 Nov 2010 15:58:50 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CE1A632.2070202@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Hey Tonight MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma16906-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 17 Nov 2010 15:58:50 -0500 Sender: mallman@icir.org Message-Id: <20101117205850.9271325213D8@lawyers.icir.org> Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 20:58:05 -0000 ----------ma16906-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > As to the hurdle, I think it ought to be high for this, perhaps higher > than for other changes we've discussed. Some of the TCPM changes don't > affect anyone except those who use them; this one affects congestion > everywhere, potentially. I'm not uncomfortable with a fairly high bar > on such things. I disagree. I have said this before. The initial congestion window is a parameter choice. As long as we pick a reasonable parameter then TCP will puzzle its way out (in the cases where that is even needed; a reasonable number would be a cwnd that the vast majority of connections would be able to attain---given enough data---anyway). I've looked at a lot of evidence that folks have thrown about and it suggests to me that 10 segments is *well* within "reasonable". This is a detail and it need not be sweated so much. allman ----------ma16906-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzkQgoACgkQWyrrWs4yIs7kugCfb9zXjq+7Y5TB1Aa6JLDNghJv DJ8AniJmAr/1sjQ8uLQrfaXflD0wWgp5 =oPjY -----END PGP SIGNATURE----- ----------ma16906-1-- From mallman@icir.org Wed Nov 17 13:14:42 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC44D3A69A2 for ; Wed, 17 Nov 2010 13:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Aj6KSY1rHLJ for ; Wed, 17 Nov 2010 13:14:42 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 176BA3A6985 for ; Wed, 17 Nov 2010 13:14:42 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAHLFPbM029999; Wed, 17 Nov 2010 13:15:25 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3772C2521890; Wed, 17 Nov 2010 16:15:25 -0500 (EST) To: Fred Baker From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Hey Tonight MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma17900-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 17 Nov 2010 16:15:25 -0500 Sender: mallman@icir.org Message-Id: <20101117211525.3772C2521890@lawyers.icir.org> Cc: tcpm , tmrg Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 21:14:42 -0000 ----------ma17900-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Fred! > So, IW=2..4 demonstrably works pretty well everywhere, but IW=10 seems > to me only sensible on MPBS and GBPS, not KBPS, scale links. Question: How much do you think we should be able to expect from hosts / people connected via 56kbps? There is a control they can use---the advertised window---to prevent IW=10 from being used on traffic sent their way. Is it reasonable to expect outliers such as this to utilize such controls and not the defaults? allman ----------ma17900-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzkRewACgkQWyrrWs4yIs4LEgCgkxLeMJnKkEYAUyAUsLL8qbxk QJsAnixBOl8Ytn3BEaxMQu7GGtKB1ZVK =9ONx -----END PGP SIGNATURE----- ----------ma17900-1-- From touch@isi.edu Wed Nov 17 14:51:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333403A680F for ; Wed, 17 Nov 2010 14:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMgqaEUukuE3 for ; Wed, 17 Nov 2010 14:51:39 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6FF763A6807 for ; Wed, 17 Nov 2010 14:51:39 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAHMqC2d027103 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 17 Nov 2010 14:52:12 -0800 (PST) Message-ID: <4CE45C9C.3090202@isi.edu> Date: Wed, 17 Nov 2010 14:52:12 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: mallman@icir.org References: <20101117205850.9271325213D8@lawyers.icir.org> In-Reply-To: <20101117205850.9271325213D8@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 22:51:40 -0000 On 11/17/2010 12:58 PM, Mark Allman wrote: > >> As to the hurdle, I think it ought to be high for this, perhaps higher >> than for other changes we've discussed. Some of the TCPM changes don't >> affect anyone except those who use them; this one affects congestion >> everywhere, potentially. I'm not uncomfortable with a fairly high bar >> on such things. > > I disagree. I have said this before. The initial congestion window is > a parameter choice. As long as we pick a reasonable parameter then TCP > will puzzle its way out (in the cases where that is even needed; a > reasonable number would be a cwnd that the vast majority of connections > would be able to attain---given enough data---anyway). That would be true of TCP learned the IW over time, even across various connections. I.e., if it started with IW=3, and found that this wasn't a problem, then it increased to IW=10 and found no problems. If, however, IW=10 resulted in large amounts of drops, then it should back off and use a smaller IW for a while. However, IW doesn't run in AIMD mode. This "parameter" persistently affects all subsequent connections, which ends up changing the nature of traffic on the network. There have been various discussions of what could happen, and we don't really know much better now what will happen with IW=10 than we knew when we increased it from 1 to 2 (accidentally, due to the bug in the original code), then from 2 to 3 (explicitly). There are a few differences this time around: 1) the proposed increase changes the parameter in use by 233%, rather than by 50% we don't know what the widespread effect of this will be on whether other connections will incur drops, e.g., if this changes how much buffering routers need for a given level of drops, etc. Single-dumbbell experiments are known insufficient to explore this issue. 2) the rationale for the proposal is a particular current use The increased performance rationale for this is sketchy at best, and it's not clear that endorsing this sort of 'millions of individual connections' use is good for the network (or whether it's even necessary, given appropriate use of Nagle and a reasonable number of concurrent connections) 3) we'll end up right back here if we're not careful Your doc is a good step in avoiding that, but lacks precisely the objective metrics we are struggling with now, and without which such changes will clearly continue unfettered. --- I subscribe to the "first do no harm" principle. I have yet to see enough evidence this is necessary, and certainly not enough to convince me that it's worth even the potential risk to make these changes yet. Joe From fred@cisco.com Wed Nov 17 15:04:12 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F073A67FC for ; Wed, 17 Nov 2010 15:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.35 X-Spam-Level: X-Spam-Status: No, score=-110.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b385S58OyeYO for ; Wed, 17 Nov 2010 15:04:11 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id ABB1B3A69AB for ; Wed, 17 Nov 2010 15:04:11 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAC7u40xAaMHG/2dsb2JhbACUUo4BcaRUm0aFSwSEWIYAgww X-IronPort-AV: E=Sophos;i="4.59,213,1288569600"; d="scan'208";a="219294115" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2010 23:04:55 +0000 Received: from Freds-Computer.local (sin-vpn-client-21-45.cisco.com [10.68.21.45]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAHN2u7Z006839; Wed, 17 Nov 2010 23:04:48 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 18 Nov 2010 07:04:49 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 18 Nov 2010 07:04:49 +0900 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <20101117211525.3772C2521890@lawyers.icir.org> Date: Thu, 18 Nov 2010 07:04:47 +0800 Message-Id: <098DFA22-6F71-4E82-8758-677D722449D9@cisco.com> References: <20101117211525.3772C2521890@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tcpm , tmrg Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 23:04:12 -0000 On Nov 18, 2010, at 5:15 AM, Mark Allman wrote: > > Hi Fred! > >> So, IW=2..4 demonstrably works pretty well everywhere, but IW=10 seems >> to me only sensible on MPBS and GBPS, not KBPS, scale links. > > Question: How much do you think we should be able to expect from hosts / > people connected via 56kbps? There is a control they can use---the > advertised window---to prevent IW=10 from being used on traffic sent > their way. Is it reasonable to expect outliers such as this to utilize > such controls and not the defaults? Not in my experience. They generally don't know much about the network. From mallman@icir.org Wed Nov 17 19:20:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68B833A66B4 for ; Wed, 17 Nov 2010 19:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.367 X-Spam-Level: X-Spam-Status: No, score=-106.367 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZR4T3+oy-+K for ; Wed, 17 Nov 2010 19:20:37 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id AEAD03A635F for ; Wed, 17 Nov 2010 19:20:37 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAI3LNP0029637; Wed, 17 Nov 2010 19:21:23 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 091DF2523EF7; Wed, 17 Nov 2010 22:21:23 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CE45C9C.3090202@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Hey Tonight MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma39858-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 17 Nov 2010 22:21:23 -0500 Sender: mallman@icir.org Message-Id: <20101118032123.091DF2523EF7@lawyers.icir.org> Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 03:20:39 -0000 ----------ma39858-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > I disagree. I have said this before. The initial congestion window is > > a parameter choice. As long as we pick a reasonable parameter then TCP > > will puzzle its way out (in the cases where that is even needed; a > > reasonable number would be a cwnd that the vast majority of connections > > would be able to attain---given enough data---anyway). > > That would be true of TCP learned the IW over time, I disagree. Its fine if we see this differently. But, I don't find your argument correct at all. I.e., - TCP will react to problems in the initial window. It will. It will figure itself out of it within a connection. - The cross connection dynamic is presuming you're making the same mistakes over-and-over. That isn't clear. If you make a zillion 10 packet connections to some host then OK. I am willing to call that pathological. - The vast majority of traffic volume is from large flows that converge via the usual AIMD. Therefore, by traffic volume the initial window is a quite small effect---especially if we are roughly in the area of "reasonable" (i.e., if the 10 packet window works the vast majority of the time). > This "parameter" persistently affects all subsequent connections, > which ends up changing the nature of traffic on the network. Absolutely this will change some of the dynamics. There is no doubt. But, there are zillions of things that change the dynamics of the networks in much larger ways and are perfectly consistent with the standards. Add a deep queue. Add a web cache. Run BitTorrent. Shape traffic. Do DNS prefetching of a zillion domains because they are all found on a web page. Install or bypass a CDN. Etc. Etc. We need to show some perspective here. > There have been various discussions of what could happen, and we don't > really know much better now what will happen with IW=10 than we knew > when we increased it from 1 to 2 (accidentally, due to the bug in the > original code), then from 2 to 3 (explicitly). I disagree. The data currently on hand is much better than the data we had [and, I generated a bunch of it] when we moved to 4KB. I don't think its even close. > 1) the proposed increase changes the parameter in use by 233%, > rather than by 50% > > we don't know what the widespread effect of this will be on whether > other connections will incur drops, e.g., if this changes how much > buffering routers need for a given level of drops, etc. We didn't know that last time either. This is *nearly impossible* to understand without just rolling the change out at scale. I'd for sure like to know the answer to this question a priori. But, I don't see how we get it. It may be a little bigger change. The bug that caused the 2 packet window wasn't somehow ubiquitous and so I am not sure the move to 4KB wasn't a tripling of the size of the IW---which is roughly what the proposed change is. That said, the initial step in my progress---which wasn't called out well, but I have added text to my private version today---was to 6 segments for a reason. Slow start by definition tolerates errors of 2x. So, if we are happy enough with 3 packets then an IW of 6 packets bounds the error at 2x. I am not uncomfortable with 3x from what I have seen. But, I understand the point. > 2) the rationale for the proposal is a particular current use > > The increased performance rationale for this is sketchy at best, and > it's not clear that endorsing this sort of 'millions of individual > connections' use is good for the network (or whether it's even > necessary, given appropriate use of Nagle and a reasonable number of > concurrent connections) [I can't parse this at all.] > 3) we'll end up right back here if we're not careful That's not true. Careful or not we'll end up right back where we are---because networks evolve and therefore it is natural to evolve parameters, too. > Your doc is a good step in avoiding that, but lacks precisely the > objective metrics we are struggling with now, and without which such > changes will clearly continue unfettered. Right- we talked about this yesterday. It'd be really nice if we could plop some objective metrics in there. I don't quite see it (and, as I recall, neither do you). So, the quick suggestion I threw out is flipping from a path whereby every so often we think hard about this and ultimately make our best engineering judgment to a path where we make an informed guess [although, that chart did not come out of thin air] at a slow and steady progression and we endeavor to try to understand small changes. allman ----------ma39858-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzkm7IACgkQWyrrWs4yIs7HXgCgmpea5fykpuargD6n7EFvnY7x z2QAnRYx4nZR372yS2fbjrdh4EX9z6fN =dk5z -----END PGP SIGNATURE----- ----------ma39858-1-- From david.borman@windriver.com Thu Nov 18 04:45:31 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130533A6853 for ; Thu, 18 Nov 2010 04:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.504 X-Spam-Level: X-Spam-Status: No, score=-103.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSnrlTq3Ag1I for ; Thu, 18 Nov 2010 04:45:29 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 522CC3A6850 for ; Thu, 18 Nov 2010 04:45:28 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id oAICkDmi011781; Thu, 18 Nov 2010 04:46:13 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Nov 2010 04:46:13 -0800 Received: from [172.25.44.11] ([172.25.44.11]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Nov 2010 04:46:12 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: David Borman In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 18 Nov 2010 06:46:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> To: Jakob Heitz X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 18 Nov 2010 12:46:13.0187 (UTC) FILETIME=[952F6130:01CB871E] Cc: tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 12:45:31 -0000 On Nov 17, 2010, at 2:41 PM, Jakob Heitz wrote: > IMHO: >=20 > If you think a small TCP IW is protecting any network from > congestion collapse, you are either living in the past > or under delusions of grandeur. That is my point, increasing the TCP IW may increase congestion and = packet drops in some scenarios, but it doesn't change how TCP reacts to = congestion so there is no reason to think that increasing the IW will = lead to congestion collapse. Congestion by itself isn't so evil that we = have to do everything we can to avoid it, it is only when it leads to = congestion collapse that it becomes detrimental to the network. In other words, just saying that increasing the IW can lead to = congestion isn't sufficient reason to not allow the IW to be increased. -David Borman >=20 > Today's networks are under greater threat from many protocols > that have no respect for congestion control at all and > would collapse immediately without QOS. >=20 > TCP IW protects the TCP session itself. > The problem with TCP is that if it drops too many packets, it > grinds to a halt. That is to be avoided at all costs. > A small IW helps to avoid that. > Of course too small an IW makes it take too long to ramp up. > There is no good way to find the optimum. The best seems to > be history of previous connections. >=20 > It probably should not even be standardized. > Remove the IW recommendation from the standard and > let each implementation figure out its own optimum. >=20 > -- > Jakob Heitz. >=20 >=20 >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 >> Behalf Of David Borman >> Sent: Wednesday, November 17, 2010 11:03 AM >> To: Alexander Zimmermann >> Cc: tcpm >> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >>=20 >> I've been thinking about the whole IW issue, and trying to=20 >> step back a bit from IW itself. So I ask myself, what is the=20 >> main issue with having a large IW? If the network has the=20 >> bandwidth, there isn't any practical problem. But if the=20 >> network doesn't have the bandwidth, a bunch of TCP=20 >> connections starting up with a larger IW can lead to=20 >> congestion. So then I ask myself, what is wrong with=20 >> congestion? The data is going to back up somewhere, so does=20 >> it matter? Of course, the answer is that yes, it does=20 >> matter, because we don't have a lossless network. When there=20 >> is congestion in routers, if there isn't enough buffering,=20 >> the way to deal with that is to drop packets, which in turn=20 >> leads to retransmissions. >>=20 >> But I don't think it is congestion itself and the dropping of=20 >> packets that is the problem, the issue is we don't want that=20 >> congestion to turn into congestion collapse. So, it seems to=20 >> me that the issue about whether or not it is safe to increase=20 >> the IW should be focused more on, if increasing the IW leads=20 >> to increased congestion, is the network still able to=20 >> properly respond to that congestion and avoid congestion=20 >> collapse? If the answer is "yes", then I think that greatly=20 >> reduces the risks of increasing the IW. But if the answer is=20 >> "no", then we have a bigger problem that is lying in wait and=20 >> can be triggered by other factors than just increasing the IW. >>=20 >> -David Borman >>=20 >>=20 >> On Nov 17, 2010, at 1:58 AM, Alexander Zimmermann wrote: >>=20 >>> Hi Richard, >>>=20 >>> exactly, this is the point! >>>=20 >>> IMO, two things are crystal clear: >>>=20 >>> 1. We have to touch/increase the IW >>> 2. We have to do it now >>>=20 >>> Also, IMO he have a rough consensus on these two points. >>>=20 >>> What I like two see now, or discuss now, is a strategy how=20 >> we can progress. >>>=20 >>> Mark proposed something, but what are thoughts from the=20 >> document author/ >>> other group members/chairs/AD on this point? >>>=20 >>> Alex >>>=20 >>> Am 16.11.2010 um 17:41 schrieb Scheffenegger, Richard: >>>=20 >>>>=20 >>>> Group, >>>>=20 >>>> Just one additional data point: Obviously, there are=20 >> already applications in the wild, that use persistent=20 >> connections and disable the slow-start-restart mechanism on=20 >> these sessions. The expectations of the programmers making=20 >> use of these socket options is to reduce the latency for=20 >> their appliaction... In effect, these Apps seem use IW=3D44=20 >> (and hurting themselves more than anybody else). >>>>=20 >>>> See "Profiling Network Performance in Multi-Tier Data=20 >> Center Applications", Section 6.1, "cwnd failing to prevent=20 >> sudden bursts", http://www.cs.princeton.edu/~jrex/papers/snap10.pdf >>>>=20 >>>>=20 >>>> IMHO this is evidence that some action in this space is=20 >> absolutely needed (even if it is "only" strong advice to apps=20 >> programmers), or there will be even more proliferation of=20 >> clumsy workarounds that are even less well understood and=20 >> investigated than IW10 already is. Keeping IW3 "forever" may=20 >> be more problematic than addressing emerging application=20 >> needs with well-tested transport-layer approaches... >>>>=20 >>>>=20 >>>> Richard Scheffenegger >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Fred Baker [mailto:fred@cisco.com]=20 >>>>> Sent: Dienstag, 16. November 2010 15:10 >>>>> To: "Ilpo J=E4rvinen" >>>>> Cc: tcpm; tmrg >>>>> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >>>>>=20 >>>>>=20 >>>>> On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote: >>>>>=20 >>>>>> On Tue, 16 Nov 2010, Fred Baker wrote: >>>>>>=20 >>>>>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: >>>>>>>=20 >>>>>>>> I wonder what factors will argue that the initial quantum=20 >>>>> can't be changed? >>>>>>>> Someone has argued in the past IW10 effectively "disable=20 >>>>> CC algorithm". >>>>>>>> But haven't we already done that years ago when moving up=20 >>>>> IW from 1=20 >>>>>>>> to 3 if one insisted then that the initial quantum must be 1? >>>>>>>=20 >>>>>>> Actually, no. I may be the person who said that this=20 >> effectively=20 >>>>>>> disables congestion control in the average case; my reason=20 >>>>> for saying=20 >>>>>>> that is that per what little data I have, the average TCP=20 >>>>> transfer is=20 >>>>>>> on the order of 15K bytes, which is about ten 1460 byte=20 >> segments. >>>>>>=20 >>>>>> It only "disables" it if there was no congestion to=20 >> control in the=20 >>>>>> first place. >>>>>=20 >>>>> How do you turn off something that's not on? >>>>>=20 >>>>> I refer to this as in the average case turning off congestion=20 >>>>> control because the transmission requires ten data packets=20 >>>>> and they all get sent in a single burst. There is no=20 >>>>> congestion control, with IW=3D10, in the case of the=20 >>>>> average-sized (which is actually gar above the median-sized)=20 >>>>> file transfer. >>>>>=20 >>>>>> Could you on your behalf answer how does IW=3D3 affect=20 >>>>> parallel sessions=20 >>>>>> on the same kind of environment? ...I've done research=20 >> on this (and=20 >>>>>> Jerry has >>>>>> too) and I know that the answer is not an intuitive one. Then we=20= >>>>>> changed to IW10 in the same environment and observe no=20 >> (consistent)=20 >>>>>> change. The results are driven by problems already with=20 >> IW3 so IW10=20 >>>>>> won't make it any worse or the effect is just too small to=20 >>>>> be measured=20 >>>>>> among the other troubles that happen. >>>>>=20 >>>>> That may be true. I have asked to see data describing the=20 >>>>> impact. I haven't seen the data. Maybe I missed something? >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>=20 >>> // >>> // Dipl.-Inform. Alexander Zimmermann >>> // Department of Computer Science, Informatik 4 >>> // RWTH Aachen University >>> // Ahornstr. 55, 52056 Aachen, Germany >>> // phone: (49-241) 80-21422, fax: (49-241) 80-22222 >>> // email: zimmermann@cs.rwth-aachen.de >>> // web: http://www.umic-mesh.net >>> // >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Thu Nov 18 08:31:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E44E28C0CE for ; Thu, 18 Nov 2010 08:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mGYtmVRDYjf for ; Thu, 18 Nov 2010 08:31:47 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 070D83A6879 for ; Thu, 18 Nov 2010 08:31:46 -0800 (PST) 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 oAIGVvag023257 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 08:31:57 -0800 (PST) Message-ID: <4CE554FD.8040304@isi.edu> Date: Thu, 18 Nov 2010 08:31:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: mallman@icir.org References: <20101118032123.091DF2523EF7@lawyers.icir.org> In-Reply-To: <20101118032123.091DF2523EF7@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 16:31:48 -0000 Hi, Mark, On 11/17/2010 7:21 PM, Mark Allman wrote: > >>> I disagree. I have said this before. The initial congestion window is >>> a parameter choice. As long as we pick a reasonable parameter then TCP >>> will puzzle its way out (in the cases where that is even needed; a >>> reasonable number would be a cwnd that the vast majority of connections >>> would be able to attain---given enough data---anyway). >> >> That would be true of TCP learned the IW over time, > > I disagree. Its fine if we see this differently. But, I don't find > your argument correct at all. I.e., > > - TCP will react to problems in the initial window. It will. It will > figure itself out of it within a connection. TCP does NOT react to problems in the IW. It keeps using the same IW for every connection, banging its head against the wall continually. It COULD. That's what I'm wondering might be useful... e.g.: TCP MAY increase its IW if it monitors the impact of that increase, and uses an AIMD algorithm to adjust the IW values over time. > - The cross connection dynamic is presuming you're making the same > mistakes over-and-over. That isn't clear. If you make a zillion > 10 packet connections to some host then OK. I am willing to call > that pathological. Let me be more clear. The IW isn't a property of the destination, it's a property of the path. Either the path can tolerate new connections with large IWs, or it cannot. Some paths from a given source may exhibit problems only for some destinations. However, there are some sources that have problems ON THEIR END of the network, i.e., that impact most, if not all, of their connections. E.g., a laptop on a low-speed link, or on a disadvantaged net. > - The vast majority of traffic volume is from large flows that > converge via the usual AIMD. Therefore, by traffic volume the > initial window is a quite small effect---especially if we are > roughly in the area of "reasonable" (i.e., if the 10 packet window > works the vast majority of the time). IW traffic is bursty, and bursts tend to synchronize. Further, IW is uses more than just for the connection start - it's also used for restart, e.g., after an idle period. This all means that increasing the IW without feedback could easily lead to problems that we cannot correct once deployed. ... >> 2) the rationale for the proposal is a particular current use >> >> The increased performance rationale for this is sketchy at best, and >> it's not clear that endorsing this sort of 'millions of individual >> connections' use is good for the network (or whether it's even >> necessary, given appropriate use of Nagle and a reasonable number of >> concurrent connections) > > [I can't parse this at all.] Let me rephrase: How much does this help? How much does it reduce latency? Most of the info I've seen summarized suggests the benefit is in the 5-20% range. That's not even noticeable from a user POV. So, back to my original point, how about IW using a long-timescale AIMD? If we do that, we can avoid needing to monitor the problem en-masse, and the system will adapt over time and we won't be back here in another 10 years... Joe From mallman@icir.org Thu Nov 18 10:06:05 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441A83A680D for ; Thu, 18 Nov 2010 10:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.515 X-Spam-Level: X-Spam-Status: No, score=-106.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KXmsTQtYtxa for ; Thu, 18 Nov 2010 10:06:03 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id AFAB03A689A for ; Thu, 18 Nov 2010 10:05:57 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAII6f6o009909; Thu, 18 Nov 2010 10:06:42 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9DD3A2532223; Thu, 18 Nov 2010 13:00:51 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CE554FD.8040304@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Who You Are MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma27091-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 18 Nov 2010 13:00:51 -0500 Sender: mallman@icir.org Message-Id: <20101118180051.9DD3A2532223@lawyers.icir.org> Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 18:06:05 -0000 ----------ma27091-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Mark: > - TCP will react to problems in the initial window. It will. It will > figure itself out of it within a connection. Joe: > TCP does NOT react to problems in the IW. It keeps using the same IW > for every connection, banging its head against the wall continually. Joe, please read what I wrote. Please in particular note the last three words. You are not replying to what I said. My statement is right. Your reaction that "TCP does NOT react to problems in the IW" is wrong. (Yes, sometimes it happens.) (I agree that there is no history across connections, but that is has nothing to do with what I said above.) allman ----------ma27091-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzladMACgkQWyrrWs4yIs6gPACfZI5tRvk34wenekxunb3Smkl2 +OkAoIuDwYUk2kCQSFOUnRoqsbKN8DFN =qjsn -----END PGP SIGNATURE----- ----------ma27091-1-- From mallman@icir.org Thu Nov 18 10:06:14 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56613A68BE for ; Thu, 18 Nov 2010 10:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.223 X-Spam-Level: X-Spam-Status: No, score=-106.223 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh81ygWIQTDZ for ; Thu, 18 Nov 2010 10:06:09 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 96DE93A689A for ; Thu, 18 Nov 2010 10:06:09 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAII6faB009908; Thu, 18 Nov 2010 10:06:42 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6E4072532382; Thu, 18 Nov 2010 13:06:05 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CE554FD.8040304@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Who You Are MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma27405-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 18 Nov 2010 13:06:05 -0500 Sender: mallman@icir.org Message-Id: <20101118180605.6E4072532382@lawyers.icir.org> Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 18:06:14 -0000 ----------ma27405-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > - The cross connection dynamic is presuming you're making the same > > mistakes over-and-over. That isn't clear. If you make a zillion > > 10 packet connections to some host then OK. I am willing to call > > that pathological. > > Let me be more clear. The IW isn't a property of the destination, > it's a property of the path. No it isn't. The IW is a construct of the sender. The path DOES NOT HAVE A WINDOW, LET ALONE AN **INITIAL** WINDOW. Period. Congestion is a property of a particular link. And, congestion of individual links aggregate into the congestion experienced across a path. But, there is no way to, e.g., measure the "IW of a link". That doesn't make any sense. TCP has a system of *inferring* congestion along the network path a connection traverses (putting aside ECN, which isn't much used). And, it has a construct called a "congestion window" to regulate the current sending rate based on its observations of that path. When a connection starts it does not have a history of observations on which to base its congestion window (/ sending rate). Yet, it needs some initial rate. So, we have to have some default here. None of this is new or novel or startling. So, we use some default IW. That default IW is a probabilistic engineering *guess* at its root. We use something that we believe will work well in the vast majority of the cases and when it doesn't the results are not somehow catastrophic. (It *could* have a history as you have noted (and conducted research on). But, the practical efficacy of that has at least not been shown (as far as I know; perhaps I am out of the loop). E.g., how often do two hosts communicate? And, is it meaningful to cache across the timeframe between those communications? E.g., even if you think you're talking to a particular host you may be talking to a farm and your connection gets sprayed to the "best" possible server at some moment in time (for some secret-sauce definition of "best") and that server might not have the state from your last interaction. Etc. So, I agree that this is something we can think further about and it may well be that it is nice for things like repeated image gets from some web server. However, that does not get us away from needing some initial setting. At *best* you have reduced the importance of the setting in some cases.) > > - The vast majority of traffic volume is from large flows that > > converge via the usual AIMD. Therefore, by traffic volume the > > initial window is a quite small effect---especially if we are > > roughly in the area of "reasonable" (i.e., if the 10 packet window > > works the vast majority of the time). > > IW traffic is bursty, and bursts tend to synchronize. Further, IW is > uses more than just for the connection start - it's also used for > restart, e.g., after an idle period. I would be perfectly happy with a rule that said the RW had to be min(IW,max_lossless_cwnd/2). I.e., basing the RW on observations from the connection itself seems absolutely reasonable to me. > How much does this help? How much does it reduce latency? Most of > the info I've seen summarized suggests the benefit is in the 5-20% > range. That's not even noticeable from a user POV. 20% seems like a pretty nice chunk of change to me. That's on the order of what we got by going to 4KB. 20% of a second is perceptible to humans. Add this over a number of objects and it looks like a fine bit of increase to me. Certainly this WG has done things for much less benefit. allman ----------ma27405-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzlaw0ACgkQWyrrWs4yIs7h2ACeKjzokV97AAYqRfHzt1Vn/F6n gTkAoJEtDzp5RAaPPlf6L0CqDmXSSIUm =Q+Il -----END PGP SIGNATURE----- ----------ma27405-1-- From jakob.heitz@ericsson.com Thu Nov 18 10:47:06 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CAD028C0E1 for ; Thu, 18 Nov 2010 10:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC4ooTiFv+Kw for ; Thu, 18 Nov 2010 10:47:04 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 16CE328C0E6 for ; Thu, 18 Nov 2010 10:47:03 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oAIIlpAu028767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Nov 2010 12:47:51 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.213]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 18 Nov 2010 13:47:50 -0500 From: Jakob Heitz To: David Borman Date: Thu, 18 Nov 2010 13:47:49 -0500 Thread-Topic: [tcpm] [Tmrg] Increasing the Initial Window - Notes Thread-Index: AcuHHpgoDyxEdJHVQpiepXPgXwSnigALfa1g Message-ID: <7309FCBCAE981B43ABBE69B31C8D213909B72E044E@EUSAACMS0701.eamcs.ericsson.se> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> In-Reply-To: <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 18:47:06 -0000 You are implying that congestion collapse is something to be avoided. I agree. However, I believe that: It is not TCP's responsibility to avoid congestion collapse. It is not within TCP's power to avoid congestion collapse. No sane network operator would rely on the TCP in end hosts to avoid conges= tion collapse. No sane server operator would rely on the TCP in clients to avoid server co= llapse. Therefore selection of IW should not be influenced by any desire to avoid congestion or protect the network. The network will protect itself. The best IW is the amount that the sender thinks he can push through within the estimated RTO. This will be different in every case. -- Jakob Heitz. =20 > -----Original Message----- > From: David Borman [mailto:david.borman@windriver.com]=20 > Sent: Thursday, November 18, 2010 4:46 AM > To: Jakob Heitz > Cc: tcpm > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >=20 >=20 > On Nov 17, 2010, at 2:41 PM, Jakob Heitz wrote: >=20 > > IMHO: > >=20 > > If you think a small TCP IW is protecting any network from > > congestion collapse, you are either living in the past > > or under delusions of grandeur. >=20 > That is my point, increasing the TCP IW may increase=20 > congestion and packet drops in some scenarios, but it doesn't=20 > change how TCP reacts to congestion so there is no reason to=20 > think that increasing the IW will lead to congestion=20 > collapse. Congestion by itself isn't so evil that we have to=20 > do everything we can to avoid it, it is only when it leads to=20 > congestion collapse that it becomes detrimental to the network. >=20 > In other words, just saying that increasing the IW can lead=20 > to congestion isn't sufficient reason to not allow the IW to=20 > be increased. >=20 > -David Borman > >=20 > > Today's networks are under greater threat from many protocols > > that have no respect for congestion control at all and > > would collapse immediately without QOS. > >=20 > > TCP IW protects the TCP session itself. > > The problem with TCP is that if it drops too many packets, it > > grinds to a halt. That is to be avoided at all costs. > > A small IW helps to avoid that. > > Of course too small an IW makes it take too long to ramp up. > > There is no good way to find the optimum. The best seems to > > be history of previous connections. > >=20 > > It probably should not even be standardized. > > Remove the IW recommendation from the standard and > > let each implementation figure out its own optimum. > >=20 > > -- > > Jakob Heitz. > >=20 > >=20 > >> -----Original Message----- > >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > >> Behalf Of David Borman > >> Sent: Wednesday, November 17, 2010 11:03 AM > >> To: Alexander Zimmermann > >> Cc: tcpm > >> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > >>=20 > >> I've been thinking about the whole IW issue, and trying to=20 > >> step back a bit from IW itself. So I ask myself, what is the=20 > >> main issue with having a large IW? If the network has the=20 > >> bandwidth, there isn't any practical problem. But if the=20 > >> network doesn't have the bandwidth, a bunch of TCP=20 > >> connections starting up with a larger IW can lead to=20 > >> congestion. So then I ask myself, what is wrong with=20 > >> congestion? The data is going to back up somewhere, so does=20 > >> it matter? Of course, the answer is that yes, it does=20 > >> matter, because we don't have a lossless network. When there=20 > >> is congestion in routers, if there isn't enough buffering,=20 > >> the way to deal with that is to drop packets, which in turn=20 > >> leads to retransmissions. > >>=20 > >> But I don't think it is congestion itself and the dropping of=20 > >> packets that is the problem, the issue is we don't want that=20 > >> congestion to turn into congestion collapse. So, it seems to=20 > >> me that the issue about whether or not it is safe to increase=20 > >> the IW should be focused more on, if increasing the IW leads=20 > >> to increased congestion, is the network still able to=20 > >> properly respond to that congestion and avoid congestion=20 > >> collapse? If the answer is "yes", then I think that greatly=20 > >> reduces the risks of increasing the IW. But if the answer is=20 > >> "no", then we have a bigger problem that is lying in wait and=20 > >> can be triggered by other factors than just increasing the IW. > >>=20 > >> -David Borman > >>=20 > >>=20 > >> On Nov 17, 2010, at 1:58 AM, Alexander Zimmermann wrote: > >>=20 > >>> Hi Richard, > >>>=20 > >>> exactly, this is the point! > >>>=20 > >>> IMO, two things are crystal clear: > >>>=20 > >>> 1. We have to touch/increase the IW > >>> 2. We have to do it now > >>>=20 > >>> Also, IMO he have a rough consensus on these two points. > >>>=20 > >>> What I like two see now, or discuss now, is a strategy how=20 > >> we can progress. > >>>=20 > >>> Mark proposed something, but what are thoughts from the=20 > >> document author/ > >>> other group members/chairs/AD on this point? > >>>=20 > >>> Alex > >>>=20 > >>> Am 16.11.2010 um 17:41 schrieb Scheffenegger, Richard: > >>>=20 > >>>>=20 > >>>> Group, > >>>>=20 > >>>> Just one additional data point: Obviously, there are=20 > >> already applications in the wild, that use persistent=20 > >> connections and disable the slow-start-restart mechanism on=20 > >> these sessions. The expectations of the programmers making=20 > >> use of these socket options is to reduce the latency for=20 > >> their appliaction... In effect, these Apps seem use IW=3D44=20 > >> (and hurting themselves more than anybody else). > >>>>=20 > >>>> See "Profiling Network Performance in Multi-Tier Data=20 > >> Center Applications", Section 6.1, "cwnd failing to prevent=20 > >> sudden bursts", http://www.cs.princeton.edu/~jrex/papers/snap10.pdf > >>>>=20 > >>>>=20 > >>>> IMHO this is evidence that some action in this space is=20 > >> absolutely needed (even if it is "only" strong advice to apps=20 > >> programmers), or there will be even more proliferation of=20 > >> clumsy workarounds that are even less well understood and=20 > >> investigated than IW10 already is. Keeping IW3 "forever" may=20 > >> be more problematic than addressing emerging application=20 > >> needs with well-tested transport-layer approaches... > >>>>=20 > >>>>=20 > >>>> Richard Scheffenegger > >>>>=20 > >>>>=20 > >>>>> -----Original Message----- > >>>>> From: Fred Baker [mailto:fred@cisco.com]=20 > >>>>> Sent: Dienstag, 16. November 2010 15:10 > >>>>> To: "Ilpo J=E4rvinen" > >>>>> Cc: tcpm; tmrg > >>>>> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > >>>>>=20 > >>>>>=20 > >>>>> On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote: > >>>>>=20 > >>>>>> On Tue, 16 Nov 2010, Fred Baker wrote: > >>>>>>=20 > >>>>>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > >>>>>>>=20 > >>>>>>>> I wonder what factors will argue that the initial quantum=20 > >>>>> can't be changed? > >>>>>>>> Someone has argued in the past IW10 effectively "disable=20 > >>>>> CC algorithm". > >>>>>>>> But haven't we already done that years ago when moving up=20 > >>>>> IW from 1=20 > >>>>>>>> to 3 if one insisted then that the initial quantum must be 1? > >>>>>>>=20 > >>>>>>> Actually, no. I may be the person who said that this=20 > >> effectively=20 > >>>>>>> disables congestion control in the average case; my reason=20 > >>>>> for saying=20 > >>>>>>> that is that per what little data I have, the average TCP=20 > >>>>> transfer is=20 > >>>>>>> on the order of 15K bytes, which is about ten 1460 byte=20 > >> segments. > >>>>>>=20 > >>>>>> It only "disables" it if there was no congestion to=20 > >> control in the=20 > >>>>>> first place. > >>>>>=20 > >>>>> How do you turn off something that's not on? > >>>>>=20 > >>>>> I refer to this as in the average case turning off congestion=20 > >>>>> control because the transmission requires ten data packets=20 > >>>>> and they all get sent in a single burst. There is no=20 > >>>>> congestion control, with IW=3D10, in the case of the=20 > >>>>> average-sized (which is actually gar above the median-sized)=20 > >>>>> file transfer. > >>>>>=20 > >>>>>> Could you on your behalf answer how does IW=3D3 affect=20 > >>>>> parallel sessions=20 > >>>>>> on the same kind of environment? ...I've done research=20 > >> on this (and=20 > >>>>>> Jerry has > >>>>>> too) and I know that the answer is not an intuitive=20 > one. Then we=20 > >>>>>> changed to IW10 in the same environment and observe no=20 > >> (consistent)=20 > >>>>>> change. The results are driven by problems already with=20 > >> IW3 so IW10=20 > >>>>>> won't make it any worse or the effect is just too small to=20 > >>>>> be measured=20 > >>>>>> among the other troubles that happen. > >>>>>=20 > >>>>> That may be true. I have asked to see data describing the=20 > >>>>> impact. I haven't seen the data. Maybe I missed something? > >>>>> _______________________________________________ > >>>>> tcpm mailing list > >>>>> tcpm@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tcpm > >>>>>=20 > >>>> _______________________________________________ > >>>> tcpm mailing list > >>>> tcpm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcpm > >>>=20 > >>> // > >>> // Dipl.-Inform. Alexander Zimmermann > >>> // Department of Computer Science, Informatik 4 > >>> // RWTH Aachen University > >>> // Ahornstr. 55, 52056 Aachen, Germany > >>> // phone: (49-241) 80-21422, fax: (49-241) 80-22222 > >>> // email: zimmermann@cs.rwth-aachen.de > >>> // web: http://www.umic-mesh.net > >>> // > >>>=20 > >>> _______________________________________________ > >>> tcpm mailing list > >>> tcpm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tcpm > >>=20 > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > >>=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > = From touch@isi.edu Thu Nov 18 11:07:59 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708383A68A4 for ; Thu, 18 Nov 2010 11:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dDegvrCxfB8 for ; Thu, 18 Nov 2010 11:07:58 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 96FF03A6834 for ; Thu, 18 Nov 2010 11:07:58 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAIJ7tuL014999 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 11:07:55 -0800 (PST) Message-ID: <4CE5798B.3010000@isi.edu> Date: Thu, 18 Nov 2010 11:07:55 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: mallman@icir.org References: <20101118180051.9DD3A2532223@lawyers.icir.org> In-Reply-To: <20101118180051.9DD3A2532223@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 19:07:59 -0000 On 11/18/2010 10:00 AM, Mark Allman wrote: > > Mark: >> - TCP will react to problems in the initial window. It will. It will >> figure itself out of it within a connection. > > Joe: >> TCP does NOT react to problems in the IW. It keeps using the same IW >> for every connection, banging its head against the wall continually. > > Joe, please read what I wrote. Please in particular note the last three > words. You are not replying to what I said. My statement is right. "Within a connection" is true. That's not the case I consider important, and not the case I have been arguing. Please re-read what I posted. > Your reaction that "TCP does NOT react to problems in the IW" is wrong. > (Yes, sometimes it happens.) TCP uses the same IW over and over. If it's wrong - if every connection loses 5 of the first 10 packets sent - TCP *does not learn to do anything different for the next **new** connection*. We agree on this, I think. My point, all along, is that it is *this* issue that is of concern. Joe From touch@isi.edu Thu Nov 18 11:15:42 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7571428B23E for ; Thu, 18 Nov 2010 11:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4iFCj3YMGR7 for ; Thu, 18 Nov 2010 11:15:41 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7AD233A6834 for ; Thu, 18 Nov 2010 11:15:41 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAIJFhWD016569 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 11:15:44 -0800 (PST) Message-ID: <4CE57B5F.5000707@isi.edu> Date: Thu, 18 Nov 2010 11:15:43 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: mallman@icir.org References: <20101118180605.6E4072532382@lawyers.icir.org> In-Reply-To: <20101118180605.6E4072532382@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 19:15:42 -0000 On 11/18/2010 10:06 AM, Mark Allman wrote: > >>> - The cross connection dynamic is presuming you're making the same >>> mistakes over-and-over. That isn't clear. If you make a zillion >>> 10 packet connections to some host then OK. I am willing to call >>> that pathological. >> >> Let me be more clear. The IW isn't a property of the destination, >> it's a property of the path. > > No it isn't. The IW is a construct of the sender. The path DOES NOT > HAVE A WINDOW, LET ALONE AN **INITIAL** WINDOW. Period. Granted. The path doesn't have an IW. The path supports a given IW. > Congestion is a property of a particular link. Congestion is a property of a path. It can occur at a link, or across a set of links (e.g., if parallelized, or alternated). It can also occur on a sequence of links, e.g., if you send 1 Gbps through a path that includes links with remaining capacity of 100 Mbps and 10 Mbps, they BOTH experience congestion-based loss. ... > So, we use some default IW. That default IW is a probabilistic > engineering *guess* at its root. We use something that we believe will > work well in the vast majority of the cases and when it doesn't the > results are not somehow catastrophic. > > (It *could* have a history as you have noted (and conducted research > on). But, the practical efficacy of that has at least not been > shown (as far as I know; perhaps I am out of the loop). E.g., how > often do two hosts communicate? You keep assuming that whether an IW works is a property of a single source, or of a pair of endpoints. I am concerned about cases where the IW interacts with a link that affects communication with MANY hosts, and so ends up being a property of a set of receivers, or all receivers. >> How much does this help? How much does it reduce latency? Most of >> the info I've seen summarized suggests the benefit is in the 5-20% >> range. That's not even noticeable from a user POV. > > 20% seems like a pretty nice chunk of change to me. That's on the order > of what we got by going to 4KB. 20% of a second is perceptible to > humans. Really? You can tell the difference between 1 second and 0.8 seconds? or 1.2 seconds? Or 400 vs 500 ms? > Add this over a number of objects and it looks like a fine bit > of increase to me. It doesn't generally add. Separate connections are independent; the only way it adds is when you retrieve something in a subsequent connection based on the first, at which point you could have used persistent connections and avoided the TWHS, which saves an additional 2 RTTs *and* allow you to use your current window (which could be larger than the IW). So basically the only time it adds up is when you should be doing something different for a more significant benefit anyway. Joe Joe From touch@isi.edu Thu Nov 18 12:01:23 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239E428C103 for ; Thu, 18 Nov 2010 12:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxZ3PlBSpqSA for ; Thu, 18 Nov 2010 12:01:22 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id A28D928C112 for ; Thu, 18 Nov 2010 12:01:14 -0800 (PST) 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 oAIK0fjl007655 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 12:00:41 -0800 (PST) Message-ID: <4CE585E9.6060203@isi.edu> Date: Thu, 18 Nov 2010 12:00:41 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: David Borman References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> In-Reply-To: <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 20:01:23 -0000 Hi, all, On 11/18/2010 4:46 AM, David Borman wrote: > > On Nov 17, 2010, at 2:41 PM, Jakob Heitz wrote: > >> IMHO: >> >> If you think a small TCP IW is protecting any network from >> congestion collapse, you are either living in the past >> or under delusions of grandeur. > > That is my point, increasing the TCP IW may increase congestion and > packet drops in some scenarios, but it doesn't change how TCP reacts to > congestion ... Actually, it does. Consider that there are three cases: A) connections so small the IW doesn't matter (they already fit in IW=3) B) connections 4-20 or so segments range C) connections much longer than 20 or so segments (A) isn't affected by this proposed change at all, so we don't need to consider it. (C) adjusts to the IW using AIMD, so even if we guess wrong, TCP will "react to congestion" here. And then there's (B). (B) doesn't react to congestion. Every new connection uses IW=10. Even after repeated attempts - to a given address, or, e.g., to every address - end up dropping, e.g., half of those segments. (B) will sit there and beat its head against the wall. That's the congestion-increasing case. Will this cause collapse? I don't know. But it's definitely NOT reacting to congestion. So can we please get off the long-connection case? That's not the issue here at all*... Joe PS - * even long connections can be affected by the IW, e.g., when they do a restart after idle, if they use IW for the restart value repeatedly; that's worth considering, but should be considered roughly the same as (B) if each busy period is in the 4-20 segments range. I.e., we can just talk about (B), IMO. From david.borman@windriver.com Thu Nov 18 12:17:13 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E203A68E1 for ; Thu, 18 Nov 2010 12:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.512 X-Spam-Level: X-Spam-Status: No, score=-103.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO3gHczpAE54 for ; Thu, 18 Nov 2010 12:17:10 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id B7EC628C0F0 for ; Thu, 18 Nov 2010 12:17:10 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id oAIKHuK4004512; Thu, 18 Nov 2010 12:17:56 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Nov 2010 12:17:55 -0800 Received: from [172.25.44.11] ([172.25.44.11]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Nov 2010 12:17:55 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: David Borman In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213909B72E044E@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 18 Nov 2010 14:17:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72E044E@EUSAACMS0701.eamcs.ericsson.se> To: Jakob Heitz X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 18 Nov 2010 20:17:55.0646 (UTC) FILETIME=[AF826DE0:01CB875D] Cc: tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 20:17:13 -0000 On Nov 18, 2010, at 12:47 PM, Jakob Heitz wrote: > You are implying that congestion collapse is something to be avoided. > I agree. > However, I believe that: > It is not TCP's responsibility to avoid congestion collapse. > It is not within TCP's power to avoid congestion collapse. Wrong. The whole point of slowstart and exponential backoff in TCP is = to keep TCP from causing or contributing to congestion collapse. This = is what happened before TCP had such things, and why we have it now. It = is fully within TCP's power and responsibility to avoid contributing to = congestion collapse by implementing proper congestion control = algorithms. > No sane network operator would rely on the TCP in end hosts to avoid = congestion collapse. > No sane server operator would rely on the TCP in clients to avoid = server collapse. If the TCPs in end hosts (both client and server) did not have = congestion control algorithms, we'd surly fall into congestion collapse = again. The network can't prevent that. Congestion collapse is when no = useful data gets through due to congestion, e.g., the TCPs keep blasting = out bursts of retransmitted data, but do not make forward progress due = to packet loss due to congestion. The network has no control over what = data the end hosts choose to send. >=20 > Therefore selection of IW should not be influenced by any desire to > avoid congestion or protect the network. The network will protect = itself. My point is that because TCPs congestion control algorithms aren't = modified by increasing the IW, if the only concern of a larger IW is = that it may cause congestion, that argument by itself is not sufficient = to defeat increasing the IW. > The best IW is the amount that the sender thinks he can push through > within the estimated RTO. This will be different in every case. Only if it is able to spread out the transmission of those packets over = the RTO. If it blasts out those packets in the first 10% of the RTO, = then if there isn't sufficient buffering in the network, you will still = have packet loss. During the first RTO you don't have any returning = ACKs to clock out the data. -David Borman >=20 > -- > Jakob Heitz. >=20 >=20 >> -----Original Message----- >> From: David Borman [mailto:david.borman@windriver.com]=20 >> Sent: Thursday, November 18, 2010 4:46 AM >> To: Jakob Heitz >> Cc: tcpm >> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >>=20 >>=20 >> On Nov 17, 2010, at 2:41 PM, Jakob Heitz wrote: >>=20 >>> IMHO: >>>=20 >>> If you think a small TCP IW is protecting any network from >>> congestion collapse, you are either living in the past >>> or under delusions of grandeur. >>=20 >> That is my point, increasing the TCP IW may increase=20 >> congestion and packet drops in some scenarios, but it doesn't=20 >> change how TCP reacts to congestion so there is no reason to=20 >> think that increasing the IW will lead to congestion=20 >> collapse. Congestion by itself isn't so evil that we have to=20 >> do everything we can to avoid it, it is only when it leads to=20 >> congestion collapse that it becomes detrimental to the network. >>=20 >> In other words, just saying that increasing the IW can lead=20 >> to congestion isn't sufficient reason to not allow the IW to=20 >> be increased. >>=20 >> -David Borman >>>=20 >>> Today's networks are under greater threat from many protocols >>> that have no respect for congestion control at all and >>> would collapse immediately without QOS. >>>=20 >>> TCP IW protects the TCP session itself. >>> The problem with TCP is that if it drops too many packets, it >>> grinds to a halt. That is to be avoided at all costs. >>> A small IW helps to avoid that. >>> Of course too small an IW makes it take too long to ramp up. >>> There is no good way to find the optimum. The best seems to >>> be history of previous connections. >>>=20 >>> It probably should not even be standardized. >>> Remove the IW recommendation from the standard and >>> let each implementation figure out its own optimum. >>>=20 >>> -- >>> Jakob Heitz. >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 >>>> Behalf Of David Borman >>>> Sent: Wednesday, November 17, 2010 11:03 AM >>>> To: Alexander Zimmermann >>>> Cc: tcpm >>>> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >>>>=20 >>>> I've been thinking about the whole IW issue, and trying to=20 >>>> step back a bit from IW itself. So I ask myself, what is the=20 >>>> main issue with having a large IW? If the network has the=20 >>>> bandwidth, there isn't any practical problem. But if the=20 >>>> network doesn't have the bandwidth, a bunch of TCP=20 >>>> connections starting up with a larger IW can lead to=20 >>>> congestion. So then I ask myself, what is wrong with=20 >>>> congestion? The data is going to back up somewhere, so does=20 >>>> it matter? Of course, the answer is that yes, it does=20 >>>> matter, because we don't have a lossless network. When there=20 >>>> is congestion in routers, if there isn't enough buffering,=20 >>>> the way to deal with that is to drop packets, which in turn=20 >>>> leads to retransmissions. >>>>=20 >>>> But I don't think it is congestion itself and the dropping of=20 >>>> packets that is the problem, the issue is we don't want that=20 >>>> congestion to turn into congestion collapse. So, it seems to=20 >>>> me that the issue about whether or not it is safe to increase=20 >>>> the IW should be focused more on, if increasing the IW leads=20 >>>> to increased congestion, is the network still able to=20 >>>> properly respond to that congestion and avoid congestion=20 >>>> collapse? If the answer is "yes", then I think that greatly=20 >>>> reduces the risks of increasing the IW. But if the answer is=20 >>>> "no", then we have a bigger problem that is lying in wait and=20 >>>> can be triggered by other factors than just increasing the IW. >>>>=20 >>>> -David Borman >>>>=20 >>>>=20 >>>> On Nov 17, 2010, at 1:58 AM, Alexander Zimmermann wrote: >>>>=20 >>>>> Hi Richard, >>>>>=20 >>>>> exactly, this is the point! >>>>>=20 >>>>> IMO, two things are crystal clear: >>>>>=20 >>>>> 1. We have to touch/increase the IW >>>>> 2. We have to do it now >>>>>=20 >>>>> Also, IMO he have a rough consensus on these two points. >>>>>=20 >>>>> What I like two see now, or discuss now, is a strategy how=20 >>>> we can progress. >>>>>=20 >>>>> Mark proposed something, but what are thoughts from the=20 >>>> document author/ >>>>> other group members/chairs/AD on this point? >>>>>=20 >>>>> Alex >>>>>=20 >>>>> Am 16.11.2010 um 17:41 schrieb Scheffenegger, Richard: >>>>>=20 >>>>>>=20 >>>>>> Group, >>>>>>=20 >>>>>> Just one additional data point: Obviously, there are=20 >>>> already applications in the wild, that use persistent=20 >>>> connections and disable the slow-start-restart mechanism on=20 >>>> these sessions. The expectations of the programmers making=20 >>>> use of these socket options is to reduce the latency for=20 >>>> their appliaction... In effect, these Apps seem use IW=3D44=20 >>>> (and hurting themselves more than anybody else). >>>>>>=20 >>>>>> See "Profiling Network Performance in Multi-Tier Data=20 >>>> Center Applications", Section 6.1, "cwnd failing to prevent=20 >>>> sudden bursts", http://www.cs.princeton.edu/~jrex/papers/snap10.pdf >>>>>>=20 >>>>>>=20 >>>>>> IMHO this is evidence that some action in this space is=20 >>>> absolutely needed (even if it is "only" strong advice to apps=20 >>>> programmers), or there will be even more proliferation of=20 >>>> clumsy workarounds that are even less well understood and=20 >>>> investigated than IW10 already is. Keeping IW3 "forever" may=20 >>>> be more problematic than addressing emerging application=20 >>>> needs with well-tested transport-layer approaches... >>>>>>=20 >>>>>>=20 >>>>>> Richard Scheffenegger >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Fred Baker [mailto:fred@cisco.com]=20 >>>>>>> Sent: Dienstag, 16. November 2010 15:10 >>>>>>> To: "Ilpo J=E4rvinen" >>>>>>> Cc: tcpm; tmrg >>>>>>> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >>>>>>>=20 >>>>>>>=20 >>>>>>> On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote: >>>>>>>=20 >>>>>>>> On Tue, 16 Nov 2010, Fred Baker wrote: >>>>>>>>=20 >>>>>>>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: >>>>>>>>>=20 >>>>>>>>>> I wonder what factors will argue that the initial quantum=20 >>>>>>> can't be changed? >>>>>>>>>> Someone has argued in the past IW10 effectively "disable=20 >>>>>>> CC algorithm". >>>>>>>>>> But haven't we already done that years ago when moving up=20 >>>>>>> IW from 1=20 >>>>>>>>>> to 3 if one insisted then that the initial quantum must be 1? >>>>>>>>>=20 >>>>>>>>> Actually, no. I may be the person who said that this=20 >>>> effectively=20 >>>>>>>>> disables congestion control in the average case; my reason=20 >>>>>>> for saying=20 >>>>>>>>> that is that per what little data I have, the average TCP=20 >>>>>>> transfer is=20 >>>>>>>>> on the order of 15K bytes, which is about ten 1460 byte=20 >>>> segments. >>>>>>>>=20 >>>>>>>> It only "disables" it if there was no congestion to=20 >>>> control in the=20 >>>>>>>> first place. >>>>>>>=20 >>>>>>> How do you turn off something that's not on? >>>>>>>=20 >>>>>>> I refer to this as in the average case turning off congestion=20 >>>>>>> control because the transmission requires ten data packets=20 >>>>>>> and they all get sent in a single burst. There is no=20 >>>>>>> congestion control, with IW=3D10, in the case of the=20 >>>>>>> average-sized (which is actually gar above the median-sized)=20 >>>>>>> file transfer. >>>>>>>=20 >>>>>>>> Could you on your behalf answer how does IW=3D3 affect=20 >>>>>>> parallel sessions=20 >>>>>>>> on the same kind of environment? ...I've done research=20 >>>> on this (and=20 >>>>>>>> Jerry has >>>>>>>> too) and I know that the answer is not an intuitive=20 >> one. Then we=20 >>>>>>>> changed to IW10 in the same environment and observe no=20 >>>> (consistent)=20 >>>>>>>> change. The results are driven by problems already with=20 >>>> IW3 so IW10=20 >>>>>>>> won't make it any worse or the effect is just too small to=20 >>>>>>> be measured=20 >>>>>>>> among the other troubles that happen. >>>>>>>=20 >>>>>>> That may be true. I have asked to see data describing the=20 >>>>>>> impact. I haven't seen the data. Maybe I missed something? >>>>>>> _______________________________________________ >>>>>>> tcpm mailing list >>>>>>> tcpm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> tcpm mailing list >>>>>> tcpm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>>=20 >>>>> // >>>>> // Dipl.-Inform. Alexander Zimmermann >>>>> // Department of Computer Science, Informatik 4 >>>>> // RWTH Aachen University >>>>> // Ahornstr. 55, 52056 Aachen, Germany >>>>> // phone: (49-241) 80-21422, fax: (49-241) 80-22222 >>>>> // email: zimmermann@cs.rwth-aachen.de >>>>> // web: http://www.umic-mesh.net >>>>> // >>>>>=20 >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >>=20 From mallman@icir.org Thu Nov 18 12:28:03 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B007A28C0D7 for ; Thu, 18 Nov 2010 12:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBebZDmPt-cw for ; Thu, 18 Nov 2010 12:28:02 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 96CEC3A6834 for ; Thu, 18 Nov 2010 12:28:02 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAIKSiCi007603; Thu, 18 Nov 2010 12:28:45 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C3C7B2539D2E; Thu, 18 Nov 2010 15:28:44 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CE57B5F.5000707@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Who You Are MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma35964-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 18 Nov 2010 15:28:44 -0500 Sender: mallman@icir.org Message-Id: <20101118202844.C3C7B2539D2E@lawyers.icir.org> Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 20:28:03 -0000 ----------ma35964-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > (It *could* have a history as you have noted (and conducted research > > on). But, the practical efficacy of that has at least not been > > shown (as far as I know; perhaps I am out of the loop). E.g., how > > often do two hosts communicate? > > You keep assuming that whether an IW works is a property of a single > source, or of a pair of endpoints. I ain't so good with the English and only passable at American, but over here "e.g." means "for example". Yes, certainly one can think of cases where the congested point is close to the sender and therefore a cache would want to consider many (or all) recipients as equivalent for IW treatment. If you're thinking of caching this sort of state then that seems like a case to work out, for sure. > I am concerned about cases where the IW interacts with a link that > affects communication with MANY hosts, and so ends up being a property > of a set of receivers, or all receivers. This doesn't concern me all that much ... - If the congestion point is pretty local then we're very much only hurting (if we are hurting) ourselves or those within our institution because we don't traverse the shared Internet. - If the initial window is problematic across all connections then it seems clear that its a bogus IW setting. If that is the case for a whole lot of edges then whatever the IW setting is happens to be a really poor choice. If this edge is somehow an outlier then they can manually configure down IW settings. Or, deal with the small amount of fallout this will cause. As I have said before, a good choice for an IW has to be fine for the vast majority of situations. But, regardless, my high order bits on this between connection business are two-fold: (1) It does not divorce us from needing a default initial window when there is no previous history to suggest what the IW should be. (2) We have no idea how it would or could work. There have been forays into congestion information sharing, but we don't (as far as I know) have any understanding of often it'd be useful in reality. Nor do we have any sort of scheme to figure out what connections should be considered together when caching (i.e., caching information obtained from connections between two IPs seems simple enough, but how do we go beyond that?). This seems like a research project to me---not a viable alternative to thinking about the IW. Of course, we could decide the current IW proposals are not viable and then go off and do the research and if it turns out to look viable then come back and revisit this sharing notion. All I am saying is that this is so under-specified and under-investigated at present that it isn't like we can consider IW10 vs. IW3-with-shared-IW-information at this time. > > 20% seems like a pretty nice chunk of change to me. That's on the order > > of what we got by going to 4KB. 20% of a second is perceptible to > > humans. > > Really? You can tell the difference between 1 second and 0.8 > seconds? or 1.2 seconds? Yep. That's what they tell me. I haven't run the tests, but yeah that's the right order for human perception to start. > > Add this over a number of objects and it looks like a fine bit of > > increase to me. > > It doesn't generally add. Separate connections are independent; the > only way it adds is when you retrieve something in a subsequent > connection based on the first, at which point you could have used > persistent connections and avoided the TWHS, which saves an > additional 2 RTTs *and* allow you to use your current window (which > could be larger than the IW). I'll grant you that it might not add. But, it might. If I want to use 4 parallel connections to download "a web page" and grabbing components sprayed across a bunch of servers then it seems pretty clear that connections finishing sooner cause subsequent connections to start sooner and if those also end sooner then you get additive benefit. allman ----------ma35964-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzljHwACgkQWyrrWs4yIs6i7gCcC+6PXWmN19iFBBOMHT8zVzqu O3gAnjEEpsQBaBfB9tVLY4fcYEJFIfs7 =7ojA -----END PGP SIGNATURE----- ----------ma35964-1-- From david.borman@windriver.com Thu Nov 18 12:32:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4BA3A6811 for ; Thu, 18 Nov 2010 12:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.519 X-Spam-Level: X-Spam-Status: No, score=-103.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CagEya3Nll8f for ; Thu, 18 Nov 2010 12:32:02 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 17ACB3A6834 for ; Thu, 18 Nov 2010 12:32:02 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id oAIKWm2v006745; Thu, 18 Nov 2010 12:32:48 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Nov 2010 12:32:47 -0800 Received: from [172.25.44.11] ([172.25.44.11]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Nov 2010 12:32:47 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <4CE585E9.6060203@isi.edu> Date: Thu, 18 Nov 2010 14:32:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 18 Nov 2010 20:32:47.0773 (UTC) FILETIME=[C34234D0:01CB875F] Cc: tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 20:32:03 -0000 On Nov 18, 2010, at 2:00 PM, Joe Touch wrote: > Hi, all, >=20 > On 11/18/2010 4:46 AM, David Borman wrote: >>=20 >> On Nov 17, 2010, at 2:41 PM, Jakob Heitz wrote: >>=20 >>> IMHO: >>>=20 >>> If you think a small TCP IW is protecting any network from >>> congestion collapse, you are either living in the past >>> or under delusions of grandeur. >>=20 >> That is my point, increasing the TCP IW may increase congestion and >> packet drops in some scenarios, but it doesn't change how TCP reacts = to >> congestion ... >=20 > Actually, it does. >=20 > Consider that there are three cases: >=20 > A) connections so small the IW doesn't matter (they already fit in = IW=3D3) >=20 > B) connections 4-20 or so segments range >=20 > C) connections much longer than 20 or so segments >=20 > (A) isn't affected by this proposed change at all, so we don't need to = consider it. >=20 > (C) adjusts to the IW using AIMD, so even if we guess wrong, TCP will = "react to congestion" here. >=20 > And then there's (B). (B) doesn't react to congestion. Every new = connection uses IW=3D10. Even after repeated attempts - to a given = address, or, e.g., to every address - end up dropping, e.g., half of = those segments. (B) will sit there and beat its head against the wall. >=20 > That's the congestion-increasing case. Will this cause collapse? I = don't know. But it's definitely NOT reacting to congestion. No, (B) will also react to congestion, if the congestion causes packet = loss. For any given flow, if all the packets get through the first = time, from it's viewpoint there is no congestion. If they don't all get = through, that connection does normal TCP backoff and retransmits. It's = not really any different than if the connection had started with IW=3D3, = worked it's way up to IW=3D10, and *then* the network became congested. = If there is congestion and packet loss, those TCP streams affected by = the packet loss will all be backing off. The flows that don't have = dropped packets complete and go away. -David Borman >=20 >=20 > So can we please get off the long-connection case? That's not the = issue here at all*... >=20 > Joe >=20 > PS - * even long connections can be affected by the IW, e.g., when = they do a restart after idle, if they use IW for the restart value = repeatedly; that's worth considering, but should be considered roughly = the same as (B) if each busy period is in the 4-20 segments range. I.e., = we can just talk about (B), IMO. >=20 From touch@isi.edu Thu Nov 18 12:40:00 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D72028C10F for ; Thu, 18 Nov 2010 12:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.573 X-Spam-Level: X-Spam-Status: No, score=-103.573 tagged_above=-999 required=5 tests=[AWL=1.026, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmRK44EBA+ct for ; Thu, 18 Nov 2010 12:39:59 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id A582B28C10A for ; Thu, 18 Nov 2010 12:39:59 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oAIKeNAc002782 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 12:40:23 -0800 (PST) Message-ID: <4CE58F37.7000407@isi.edu> Date: Thu, 18 Nov 2010 12:40:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: mallman@icir.org References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> In-Reply-To: <20101118202844.C3C7B2539D2E@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: oAIKeNAc002782 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 20:40:00 -0000 On 11/18/2010 12:28 PM, Mark Allman wrote: > >>> (It *could* have a history as you have noted (and conducted research >>> on). But, the practical efficacy of that has at least not been >>> shown (as far as I know; perhaps I am out of the loop). E.g., how >>> often do two hosts communicate? >> >> You keep assuming that whether an IW works is a property of a single >> source, or of a pair of endpoints. > > I ain't so good with the English and only passable at American, but over > here "e.g." means "for example". > > Yes, certainly one can think of cases where the congested point is close > to the sender and therefore a cache would want to consider many (or all) > recipients as equivalent for IW treatment. If you're thinking of > caching this sort of state then that seems like a case to work out, for > sure. > >> I am concerned about cases where the IW interacts with a link that >> affects communication with MANY hosts, and so ends up being a property >> of a set of receivers, or all receivers. > > This doesn't concern me all that much ... > > - If the congestion point is pretty local then we're very much only > hurting (if we are hurting) ourselves or those within our > institution because we don't traverse the shared Internet. > > - If the initial window is problematic across all connections then it > seems clear that its a bogus IW setting. Or - we're sharing an access point at a coffee shop, or one of those card-deck sized mobile hotspots (wifi-cell modem) - we all live in an apartment building or on the same cable Internet segment, or some similar enclave (a cruise ship comes to mind) - we're all behind some firewall somewhere, such as at a big company, or even a country Ultimately, either the IW setting mostly works or it doesn't. If it works, we can keep using it or make it larger. If it doesn't, we should back off. That's an invitation for an automatic system, IMO, not a schedule of updates in an RFC. > But, regardless, my high order bits on this between connection business > are two-fold: > > (1) It does not divorce us from needing a default initial window when > there is no previous history to suggest what the IW should be. We always need a starting point. If a system *automatically* converges over a reasonable time, it doesn't matter much what that is. If however that's a fixed value, it matters. > (2) We have no idea how it would or could work. There have been > forays into congestion information sharing, but we don't (as far > as I know) have any understanding of often it'd be useful in > reality. Nor do we have any sort of scheme to figure out what > connections should be considered together when caching (i.e., > caching information obtained from connections between two IPs > seems simple enough, but how do we go beyond that?). This seems > like a research project to me---not a viable alternative to > thinking about the IW. I'm thinking very coarsely; if it hurts most of the time when I do this, then stop doing it. It can be based on 80% - if 80% of the connections lose packets using IW=10, then backoff. If not, then don't. If 80% of the connections don't lose packets, then try a larger IW. You don't need much more than a counter of whether packets are lost during an IW and how many connections you have. Yes, this is an experiment -- BUT SO IS PICKING IW=10, or SETTING A SCHEDULE OF IW INCREASES OVER TIME. The point is that it's an adaptive solution that should end up doing the right thing without constant oversight. ... >> Really? You can tell the difference between 1 second and 0.8 >> seconds? or 1.2 seconds? > > Yep. That's what they tell me. I haven't run the tests, but yeah > that's the right order for human perception to start. People can notice things down to about 200ms. That does NOT mean they know 1 vs 1.2 seconds, though - and definitely not 400 vs 500ms. We looked at this issue in the mid 90s when looking at web push systems. Joe From touch@isi.edu Thu Nov 18 12:43:10 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E55028C10C for ; Thu, 18 Nov 2010 12:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kclyUC9c48FT for ; Thu, 18 Nov 2010 12:43:09 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id BBB2828C10A for ; Thu, 18 Nov 2010 12:43:09 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oAIKhPGG003126 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 12:43:25 -0800 (PST) Message-ID: <4CE58FED.608@isi.edu> Date: Thu, 18 Nov 2010 12:43:25 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: David Borman References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> In-Reply-To: <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: oAIKhPGG003126 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 20:43:10 -0000 On 11/18/2010 12:32 PM, David Borman wrote: ... >> Consider that there are three cases: >> >> A) connections so small the IW doesn't matter (they already fit in IW=3) >> >> B) connections 4-20 or so segments range >> >> C) connections much longer than 20 or so segments >> >> (A) isn't affected by this proposed change at all, so we don't need to consider it. >> >> (C) adjusts to the IW using AIMD, so even if we guess wrong, TCP will "react to congestion" here. >> >> And then there's (B). (B) doesn't react to congestion. Every new connection uses IW=10. Even after repeated attempts - to a given address, or, e.g., to every address - end up dropping, e.g., half of those segments. (B) will sit there and beat its head against the wall. > >> >> That's the congestion-increasing case. Will this cause collapse? I don't know. But it's definitely NOT reacting to congestion. > > No, (B) will also react to congestion, if the congestion causes > packet loss. For any given flow, if all the packets get through the > first time, from it's viewpoint there is no congestion. If they don't > all get through, that connection does normal TCP backoff and > retransmits. To be more clear, here's the case: start 1000 connections in a row. during the first connection, lose some packets and do normal TCP backoff so what do the other 999 connections start with? ans: 10 packets The point is that subsequent connections don't do anything different. If you have 1000 connections, you're sending a certain amount of data into the network without reacting. We're tripling that. That can easily cause congestion. At which point the *existing* connections will backoff, but new connections keep making problems. Joe From ananth@cisco.com Thu Nov 18 13:04:17 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 734A528C113 for ; Thu, 18 Nov 2010 13:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.97 X-Spam-Level: X-Spam-Status: No, score=-9.97 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_00=-2.599, FB_YOU_CAN_BECOME=1.258, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNEKHWIK7nVa for ; Thu, 18 Nov 2010 13:04:15 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C4BDC28C10A for ; Thu, 18 Nov 2010 13:04:14 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI4j5UyrRN+K/2dsb2JhbACiV3GkKpsthUsEhFqJEogG X-IronPort-AV: E=Sophos;i="4.59,218,1288569600"; d="scan'208";a="382541420" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 18 Nov 2010 21:05:03 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id oAIL53io014095; Thu, 18 Nov 2010 21:05:03 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Nov 2010 13:05:02 -0800 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, 18 Nov 2010 13:05:01 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4CE58FED.608@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] [Tmrg] Increasing the Initial Window - Notes Thread-Index: AcuHYVdExa9rm3nRTqqb7XBw9N2rBAAAc6yg References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se><36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com><4CE585E9.6060203@isi.edu><6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "David Borman" X-OriginalArrivalTime: 18 Nov 2010 21:05:02.0953 (UTC) FILETIME=[44B73D90:01CB8764] Cc: tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 21:04:18 -0000 Why can't you do something like this : - If any one of the TCP connections egressing out of that interface (this can determined in TCP layer) is in the TCP retransmit state (or has experienced congestion in the past xxx secs/mins), then go back to a lower IW for new TCP connections which are using the same output interface..=20 - When you want to start a connection, use the connection history (Joe's RFC) Well, there may be some gotchas of this scheme, but you can become conservative when there is some concrete information. Thanks, -Anantha >=20 > To be more clear, here's the case: >=20 > start 1000 connections in a row. >=20 > during the first connection, lose some packets and do > normal TCP backoff >=20 > so what do the other 999 connections start with? > ans: 10 packets >=20 > The point is that subsequent connections don't do anything different. > If > you have 1000 connections, you're sending a certain amount of data into > the network without reacting. We're tripling that. >=20 > That can easily cause congestion. At which point the *existing* > connections will backoff, but new connections keep making problems. >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Thu Nov 18 13:09:06 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684A13A68ED for ; Thu, 18 Nov 2010 13:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.985 X-Spam-Level: X-Spam-Status: No, score=-101.985 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, FB_YOU_CAN_BECOME=1.258, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jdf+7RiBRBva for ; Thu, 18 Nov 2010 13:09:04 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id E16903A68EE for ; Thu, 18 Nov 2010 13:09:02 -0800 (PST) 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 oAIL8pVj021191 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 13:08:51 -0800 (PST) Message-ID: <4CE595E3.3010109@isi.edu> Date: Thu, 18 Nov 2010 13:08:51 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se><36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com><4CE585E9.6060203@isi.edu><6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm , David Borman Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 21:09:06 -0000 That's basically what I'm suggesting; it can easily be per subnet, per interface, or per the entire machine as desired. The ultimate point is: - put something in the end node that notices if/when it fails objectively, and fixes it - that same thing can allow the IW to increase over time if there are no problems I'll be glad to write this up if people need a more concrete proposal. Joe On 11/18/2010 1:05 PM, Anantha Ramaiah (ananth) wrote: > Why can't you do something like this : > > - If any one of the TCP connections egressing out of that interface > (this can determined in TCP layer) is in the TCP retransmit state (or > has experienced congestion in the past xxx secs/mins), then go back to a > lower IW for new TCP connections which are using the same output > interface.. > > - When you want to start a connection, use the connection history (Joe's > RFC) > > Well, there may be some gotchas of this scheme, but you can become > conservative when there is some concrete information. > > Thanks, > -Anantha >> >> To be more clear, here's the case: >> >> start 1000 connections in a row. >> >> during the first connection, lose some packets and do >> normal TCP backoff >> >> so what do the other 999 connections start with? >> ans: 10 packets >> >> The point is that subsequent connections don't do anything different. >> If >> you have 1000 connections, you're sending a certain amount of data > into >> the network without reacting. We're tripling that. >> >> That can easily cause congestion. At which point the *existing* >> connections will backoff, but new connections keep making problems. >> >> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From david.borman@windriver.com Thu Nov 18 13:09:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610F228C113 for ; Thu, 18 Nov 2010 13:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Bnbp9MCAVnC for ; Thu, 18 Nov 2010 13:09:41 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id A7FE33A68F0 for ; Thu, 18 Nov 2010 13:09:41 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id oAILATQY012462; Thu, 18 Nov 2010 13:10:29 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Nov 2010 13:10:28 -0800 Received: from [172.25.44.11] ([172.25.44.11]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Nov 2010 13:10:28 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <4CE58FED.608@isi.edu> Date: Thu, 18 Nov 2010 15:10:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <752D4660-5063-4050-B7C5-A30164ADAB09@windriver.com> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 18 Nov 2010 21:10:29.0050 (UTC) FILETIME=[0715B1A0:01CB8765] Cc: tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 21:09:44 -0000 On Nov 18, 2010, at 2:43 PM, Joe Touch wrote: >=20 >=20 > On 11/18/2010 12:32 PM, David Borman wrote: > ... >>> Consider that there are three cases: >>>=20 >>> A) connections so small the IW doesn't matter (they already fit in = IW=3D3) >>>=20 >>> B) connections 4-20 or so segments range >>>=20 >>> C) connections much longer than 20 or so segments >>>=20 >>> (A) isn't affected by this proposed change at all, so we don't need = to consider it. >>>=20 >>> (C) adjusts to the IW using AIMD, so even if we guess wrong, TCP = will "react to congestion" here. >>>=20 >>> And then there's (B). (B) doesn't react to congestion. Every new = connection uses IW=3D10. Even after repeated attempts - to a given = address, or, e.g., to every address - end up dropping, e.g., half of = those segments. (B) will sit there and beat its head against the wall. >>=20 >>>=20 >>> That's the congestion-increasing case. Will this cause collapse? I = don't know. But it's definitely NOT reacting to congestion. >>=20 >> No, (B) will also react to congestion, if the congestion causes >> packet loss. For any given flow, if all the packets get through the >> first time, from it's viewpoint there is no congestion. If they don't >> all get through, that connection does normal TCP backoff and >> retransmits. >=20 > To be more clear, here's the case: >=20 > start 1000 connections in a row. >=20 > during the first connection, lose some packets and do > normal TCP backoff >=20 > so what do the other 999 connections start with? > ans: 10 packets >=20 > The point is that subsequent connections don't do anything different. = If you have 1000 connections, you're sending a certain amount of data = into the network without reacting. We're tripling that. >=20 > That can easily cause congestion. At which point the *existing* = connections will backoff, but new connections keep making problems. If you are doing the 1000 connections serially, then any connection that = experiences packet loss will slow down that connection, and delay the = creation of all the successive connections, and hence delay the next IW = burst. Seems to me that that is reacting to congestion across = connections. If you are doing 1000 connections in parallel, well, you are now = spitting out 3,000 packets with IW=3D3 and 10,000 packets with IW=3D10, = both of which are probably going to cause congestion. Remember, from the end-point of a TCP connection, it is not aware of = congestion unless there is packet loss or an ECN indication. There may = be congestion on the path, but if the packets gets through, TCP is = unaware of the congestion, other than the RTO going up due to delayed = packets, and will continue to open up its idea of the congestion window. But here's a thought: Any TCP connection with a large IW that has to = retransmit or gets an ECN notification during the initial 3-way = handshake must clamp down its IW to a small value. That won't catch = every case, but it'll catch some. -David >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From johnwheffner@gmail.com Thu Nov 18 13:10:46 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726323A68F2 for ; Thu, 18 Nov 2010 13:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, FB_YOU_CAN_BECOME=1.258] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35tPhbn1fAT9 for ; Thu, 18 Nov 2010 13:10:34 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id ADDB43A68EC for ; Thu, 18 Nov 2010 13:10:33 -0800 (PST) Received: by bwz12 with SMTP id 12so3344778bwz.31 for ; Thu, 18 Nov 2010 13:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iPNumvauzS3YrBoViKXr/9ya7NexExalMXrqgF4/QeI=; b=Vq0nTnxkivMEpdAZsIHs7Gtlr9TT3cG2FDJbTva2DTwURzdQUw0XjiztYuy9bqnWho rvBz2wIQPllJn1WbWzHmkCbBQl338ar5/gGTDNTheaVlreXlHKnR0QSR+pejERYUG2jx PsPm+n7rqFJwxuiAMGeMmJ/EDy9u/F1NlhJrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JXeSHJeTxM1zL4dERa/ZwAD8KNfbxcIgIogwEkrIQYI1a1Nfwvrn2y3VNNOjkL2Ofx hWQBfwDTVo87hddFT2c/+hWGk45z5Rak5nNQLcQZJ8ZeLgw3JXwgdaWcSVJkjIY/n7MB qEKaZwoAtZcZ3FJ8fis6DoHzcfRJJNzohT3BU= MIME-Version: 1.0 Received: by 10.204.64.139 with SMTP id e11mr1124213bki.212.1290114680552; Thu, 18 Nov 2010 13:11:20 -0800 (PST) Received: by 10.204.118.67 with HTTP; Thu, 18 Nov 2010 13:11:20 -0800 (PST) In-Reply-To: <4CE595E3.3010109@isi.edu> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> Date: Thu, 18 Nov 2010 16:11:20 -0500 Message-ID: From: John Heffner To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: David Borman , tcpm , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 21:10:46 -0000 Why is this mechanism required for IW=3D10 but not for IW=3D3? -John On Thu, Nov 18, 2010 at 4:08 PM, Joe Touch wrote: > That's basically what I'm suggesting; it can easily be per subnet, per > interface, or per the entire machine as desired. > > The ultimate point is: > > =A0 =A0 =A0 =A0- put something in the end node that notices if/when > =A0 =A0 =A0 =A0it fails objectively, and fixes it > > =A0 =A0 =A0 =A0- that same thing can allow the IW to increase > =A0 =A0 =A0 =A0over time if there are no problems > > I'll be glad to write this up if people need a more concrete proposal. > > Joe > > On 11/18/2010 1:05 PM, Anantha Ramaiah (ananth) wrote: >> >> Why can't you do something like this : >> >> - If any one of the TCP connections egressing out of that interface >> (this can determined in TCP layer) is in the TCP retransmit state (or >> has experienced congestion in the past xxx secs/mins), then go back to a >> lower IW for new TCP connections which are using the same output >> interface.. >> >> - When you want to start a connection, use the connection history (Joe's >> RFC) >> >> Well, there may be some gotchas of this scheme, but you can become >> conservative when there is some concrete information. >> >> Thanks, >> -Anantha >>> >>> To be more clear, here's the case: >>> >>> =A0 =A0 =A0 =A0start 1000 connections in a row. >>> >>> =A0 =A0 =A0 =A0during the first connection, lose some packets and do >>> =A0 =A0 =A0 =A0normal TCP backoff >>> >>> =A0 =A0 =A0 =A0so what do the other 999 connections start with? >>> =A0 =A0 =A0 =A0ans: 10 packets >>> >>> The point is that subsequent connections don't do anything different. >>> If >>> you have 1000 connections, you're sending a certain amount of data >> >> into >>> >>> the network without reacting. We're tripling that. >>> >>> That can easily cause congestion. At which point the *existing* >>> connections will backoff, but new connections keep making problems. >>> >>> Joe >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From jakob.heitz@ericsson.com Wed Nov 17 12:08:51 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5B93A6982 for ; Wed, 17 Nov 2010 12:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6FYxRsTh3VR for ; Wed, 17 Nov 2010 12:08:49 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id D0A2E3A6975 for ; Wed, 17 Nov 2010 12:08:49 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oAHKXZ6O017107; Wed, 17 Nov 2010 14:34:33 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.213]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 17 Nov 2010 15:09:27 -0500 From: Jakob Heitz To: David Borman , Alexander Zimmermann Date: Wed, 17 Nov 2010 15:09:25 -0500 Thread-Topic: [tcpm] [Tmrg] Increasing the Initial Window - Notes Thread-Index: AcuGikCHh9emoSSGSgC8Kw6LLSUUFwAByVCw Message-ID: <7309FCBCAE981B43ABBE69B31C8D213909B72A7ACB@EUSAACMS0701.eamcs.ericsson.se> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> In-Reply-To: <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 18 Nov 2010 13:13:19 -0800 Cc: tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 20:08:51 -0000 If you think a small TCP IW is protecting any network from congestion collapse, you are either living in the past or under delusions of grandeur. Today's networks are under greater threat from many protocols that have no respect for congestion control at all and would collapse immediately without QOS. TCP IW protects the TCP session itself. The problem with TCP is that if it drops too many packets, it grinds to a halt. That is to be avoided at all costs. A small IW helps to avoid that. Of course too small an IW makes it take too long to ramp up. There is no good way to find the optimum. The best seems to be history of previous connections. It probably should not even be standardized. Let each implementation figure out its own optimum. -- Jakob Heitz. =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of David Borman > Sent: Wednesday, November 17, 2010 11:03 AM > To: Alexander Zimmermann > Cc: tcpm > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >=20 > I've been thinking about the whole IW issue, and trying to=20 > step back a bit from IW itself. So I ask myself, what is the=20 > main issue with having a large IW? If the network has the=20 > bandwidth, there isn't any practical problem. But if the=20 > network doesn't have the bandwidth, a bunch of TCP=20 > connections starting up with a larger IW can lead to=20 > congestion. So then I ask myself, what is wrong with=20 > congestion? The data is going to back up somewhere, so does=20 > it matter? Of course, the answer is that yes, it does=20 > matter, because we don't have a lossless network. When there=20 > is congestion in routers, if there isn't enough buffering,=20 > the way to deal with that is to drop packets, which in turn=20 > leads to retransmissions. >=20 > But I don't think it is congestion itself and the dropping of=20 > packets that is the problem, the issue is we don't want that=20 > congestion to turn into congestion collapse. So, it seems to=20 > me that the issue about whether or not it is safe to increase=20 > the IW should be focused more on, if increasing the IW leads=20 > to increased congestion, is the network still able to=20 > properly respond to that congestion and avoid congestion=20 > collapse? If the answer is "yes", then I think that greatly=20 > reduces the risks of increasing the IW. But if the answer is=20 > "no", then we have a bigger problem that is lying in wait and=20 > can be triggered by other factors than just increasing the IW. >=20 > -David Borman >=20 >=20 > On Nov 17, 2010, at 1:58 AM, Alexander Zimmermann wrote: >=20 > > Hi Richard, > >=20 > > exactly, this is the point! > >=20 > > IMO, two things are crystal clear: > >=20 > > 1. We have to touch/increase the IW > > 2. We have to do it now > >=20 > > Also, IMO he have a rough consensus on these two points. > >=20 > > What I like two see now, or discuss now, is a strategy how=20 > we can progress. > >=20 > > Mark proposed something, but what are thoughts from the=20 > document author/ > > other group members/chairs/AD on this point? > >=20 > > Alex > >=20 > > Am 16.11.2010 um 17:41 schrieb Scheffenegger, Richard: > >=20 > >>=20 > >> Group, > >>=20 > >> Just one additional data point: Obviously, there are=20 > already applications in the wild, that use persistent=20 > connections and disable the slow-start-restart mechanism on=20 > these sessions. The expectations of the programmers making=20 > use of these socket options is to reduce the latency for=20 > their appliaction... In effect, these Apps seem use IW=3D44=20 > (and hurting themselves more than anybody else). > >>=20 > >> See "Profiling Network Performance in Multi-Tier Data=20 > Center Applications", Section 6.1, "cwnd failing to prevent=20 > sudden bursts", http://www.cs.princeton.edu/~jrex/papers/snap10.pdf > >>=20 > >>=20 > >> IMHO this is evidence that some action in this space is=20 > absolutely needed (even if it is "only" strong advice to apps=20 > programmers), or there will be even more proliferation of=20 > clumsy workarounds that are even less well understood and=20 > investigated than IW10 already is. Keeping IW3 "forever" may=20 > be more problematic than addressing emerging application=20 > needs with well-tested transport-layer approaches... > >>=20 > >>=20 > >> Richard Scheffenegger > >>=20 > >>=20 > >>> -----Original Message----- > >>> From: Fred Baker [mailto:fred@cisco.com]=20 > >>> Sent: Dienstag, 16. November 2010 15:10 > >>> To: "Ilpo J=E4rvinen" > >>> Cc: tcpm; tmrg > >>> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes > >>>=20 > >>>=20 > >>> On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote: > >>>=20 > >>>> On Tue, 16 Nov 2010, Fred Baker wrote: > >>>>=20 > >>>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote: > >>>>>=20 > >>>>>> I wonder what factors will argue that the initial quantum=20 > >>> can't be changed? > >>>>>> Someone has argued in the past IW10 effectively "disable=20 > >>> CC algorithm". > >>>>>> But haven't we already done that years ago when moving up=20 > >>> IW from 1=20 > >>>>>> to 3 if one insisted then that the initial quantum must be 1? > >>>>>=20 > >>>>> Actually, no. I may be the person who said that this=20 > effectively=20 > >>>>> disables congestion control in the average case; my reason=20 > >>> for saying=20 > >>>>> that is that per what little data I have, the average TCP=20 > >>> transfer is=20 > >>>>> on the order of 15K bytes, which is about ten 1460 byte=20 > segments. > >>>>=20 > >>>> It only "disables" it if there was no congestion to=20 > control in the=20 > >>>> first place. > >>>=20 > >>> How do you turn off something that's not on? > >>>=20 > >>> I refer to this as in the average case turning off congestion=20 > >>> control because the transmission requires ten data packets=20 > >>> and they all get sent in a single burst. There is no=20 > >>> congestion control, with IW=3D10, in the case of the=20 > >>> average-sized (which is actually gar above the median-sized)=20 > >>> file transfer. > >>>=20 > >>>> Could you on your behalf answer how does IW=3D3 affect=20 > >>> parallel sessions=20 > >>>> on the same kind of environment? ...I've done research=20 > on this (and=20 > >>>> Jerry has > >>>> too) and I know that the answer is not an intuitive one. Then we=20 > >>>> changed to IW10 in the same environment and observe no=20 > (consistent)=20 > >>>> change. The results are driven by problems already with=20 > IW3 so IW10=20 > >>>> won't make it any worse or the effect is just too small to=20 > >>> be measured=20 > >>>> among the other troubles that happen. > >>>=20 > >>> That may be true. I have asked to see data describing the=20 > >>> impact. I haven't seen the data. Maybe I missed something? > >>> _______________________________________________ > >>> tcpm mailing list > >>> tcpm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tcpm > >>>=20 > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > >=20 > > // > > // Dipl.-Inform. Alexander Zimmermann > > // Department of Computer Science, Informatik 4 > > // RWTH Aachen University > > // Ahornstr. 55, 52056 Aachen, Germany > > // phone: (49-241) 80-21422, fax: (49-241) 80-22222 > > // email: zimmermann@cs.rwth-aachen.de > > // web: http://www.umic-mesh.net > > // > >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From touch@isi.edu Thu Nov 18 13:16:29 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36F9828C117 for ; Thu, 18 Nov 2010 13:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.961 X-Spam-Level: X-Spam-Status: No, score=-101.961 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FB_YOU_CAN_BECOME=1.258, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhxJagKablAy for ; Thu, 18 Nov 2010 13:16:28 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 6411B3A68E6 for ; Thu, 18 Nov 2010 13:16:28 -0800 (PST) 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 oAILGRg2022851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 13:16:27 -0800 (PST) Message-ID: <4CE597AB.1020306@isi.edu> Date: Thu, 18 Nov 2010 13:16:27 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: John Heffner References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@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: David Borman , tcpm , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 21:16:29 -0000 Maybe it should have been for IW=3 too, but it didn't occur to me at the time. The benefit is that had we used this mechanism then, we wouldn't be asking for a new IW now, though. Joe On 11/18/2010 1:11 PM, John Heffner wrote: > Why is this mechanism required for IW=10 but not for IW=3? > > -John > > > On Thu, Nov 18, 2010 at 4:08 PM, Joe Touch wrote: >> That's basically what I'm suggesting; it can easily be per subnet, per >> interface, or per the entire machine as desired. >> >> The ultimate point is: >> >> - put something in the end node that notices if/when >> it fails objectively, and fixes it >> >> - that same thing can allow the IW to increase >> over time if there are no problems >> >> I'll be glad to write this up if people need a more concrete proposal. >> >> Joe >> >> On 11/18/2010 1:05 PM, Anantha Ramaiah (ananth) wrote: >>> >>> Why can't you do something like this : >>> >>> - If any one of the TCP connections egressing out of that interface >>> (this can determined in TCP layer) is in the TCP retransmit state (or >>> has experienced congestion in the past xxx secs/mins), then go back to a >>> lower IW for new TCP connections which are using the same output >>> interface.. >>> >>> - When you want to start a connection, use the connection history (Joe's >>> RFC) >>> >>> Well, there may be some gotchas of this scheme, but you can become >>> conservative when there is some concrete information. >>> >>> Thanks, >>> -Anantha >>>> >>>> To be more clear, here's the case: >>>> >>>> start 1000 connections in a row. >>>> >>>> during the first connection, lose some packets and do >>>> normal TCP backoff >>>> >>>> so what do the other 999 connections start with? >>>> ans: 10 packets >>>> >>>> The point is that subsequent connections don't do anything different. >>>> If >>>> you have 1000 connections, you're sending a certain amount of data >>> >>> into >>>> >>>> the network without reacting. We're tripling that. >>>> >>>> That can easily cause congestion. At which point the *existing* >>>> connections will backoff, but new connections keep making problems. >>>> >>>> Joe >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From touch@isi.edu Thu Nov 18 13:21:21 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3451228C114 for ; Thu, 18 Nov 2010 13:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T5JlGexxVi3 for ; Thu, 18 Nov 2010 13:21:20 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 00C523A68CF for ; Thu, 18 Nov 2010 13:21:19 -0800 (PST) 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 oAILLOjm023909 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 13:21:24 -0800 (PST) Message-ID: <4CE598D4.50606@isi.edu> Date: Thu, 18 Nov 2010 13:21:24 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: David Borman References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <752D4660-5063-4050-B7C5-A30164ADAB09@windriver.com> In-Reply-To: <752D4660-5063-4050-B7C5-A30164ADAB09@windriver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 21:21:21 -0000 On 11/18/2010 1:10 PM, David Borman wrote: ... >> To be more clear, here's the case: >> >> start 1000 connections in a row. >> >> during the first connection, lose some packets and do >> normal TCP backoff >> >> so what do the other 999 connections start with? >> ans: 10 packets >> >> The point is that subsequent connections don't do anything different. If you have 1000 connections, you're sending a certain amount of data into the network without reacting. We're tripling that. >> >> That can easily cause congestion. At which point the *existing* connections will backoff, but new connections keep making problems. > > If you are doing the 1000 connections serially, then any connection > that experiences packet loss will slow down that connection, and delay > the creation of all the successive connections, and hence delay the next > IW burst. Seems to me that that is reacting to congestion across > connections. That's true if the connections are serial, but I didn't say that. I said try to start 1000 connections. They'll start in a sequence, but they don't get delayed based on what other connections are doing necessarily. > If you are doing 1000 connections in parallel, well, you are now > spitting out 3,000 packets with IW=3 and 10,000 packets with IW=10, both > of which are probably going to cause congestion. The 10,000 packets cause more congestion, or causes congestion more of the time - depending on the network parameters. I.e., it *increases* the congestion, regardless. > Remember, from the end-point of a TCP connection, it is not aware of > congestion unless there is packet loss or an ECN indication. There may > be congestion on the path, but if the packets gets through, TCP is > unaware of the congestion, other than the RTO going up due to delayed > packets, and will continue to open up its idea of the congestion window. Agreed. > But here's a thought: Any TCP connection with a large IW that has to > retransmit or gets an ECN notification during the initial 3-way > handshake must clamp down its IW to a small value. That won't catch > every case, but it'll catch some. Sure - that's basically what I'm suggesting. We can refine the feedback mechanism (packet loss detected via SACK or ACK gaps vs. ECN notification vs retransmit). I'm also suggesting that the IW should increase over time, too - so that we don't need to revisit this issue explicitly. Joe From jakob.heitz@ericsson.com Thu Nov 18 14:17:09 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E3928C0EC for ; Thu, 18 Nov 2010 14:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, FB_YOU_CAN_BECOME=1.258] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ft3VSqeYcAa for ; Thu, 18 Nov 2010 14:17:08 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 622E43A68C2 for ; Thu, 18 Nov 2010 14:17:08 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oAIMh9Vh014611; Thu, 18 Nov 2010 16:43:10 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.213]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 18 Nov 2010 17:17:49 -0500 From: Jakob Heitz To: Joe Touch , "Anantha Ramaiah (ananth)" Date: Thu, 18 Nov 2010 17:17:48 -0500 Thread-Topic: [tcpm] [Tmrg] Increasing the Initial Window - Notes Thread-Index: AcuHZQWbs2DHewicSCK9QcVqWpogvgACOzCw Message-ID: <7309FCBCAE981B43ABBE69B31C8D213909B72E0675@EUSAACMS0701.eamcs.ericsson.se> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se><36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com><4CE585E9.6060203@isi.edu><6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> In-Reply-To: <4CE595E3.3010109@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm , David Borman Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 22:17:09 -0000 That's good. I would replace the word "increase" with "increase or decrease". This would also require an initial value. Let's call it IIW. I'll propose IIW=3D10. -- Jakob Heitz. =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Joe Touch > Sent: Thursday, November 18, 2010 1:09 PM > To: Anantha Ramaiah (ananth) > Cc: tcpm; David Borman > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >=20 > That's basically what I'm suggesting; it can easily be per=20 > subnet, per=20 > interface, or per the entire machine as desired. >=20 > The ultimate point is: >=20 > - put something in the end node that notices if/when > it fails objectively, and fixes it >=20 > - that same thing can allow the IW to increase > over time if there are no problems >=20 > I'll be glad to write this up if people need a more concrete proposal. >=20 > Joe >=20 > On 11/18/2010 1:05 PM, Anantha Ramaiah (ananth) wrote: > > Why can't you do something like this : > > > > - If any one of the TCP connections egressing out of that interface > > (this can determined in TCP layer) is in the TCP retransmit=20 > state (or > > has experienced congestion in the past xxx secs/mins), then=20 > go back to a > > lower IW for new TCP connections which are using the same output > > interface.. > > > > - When you want to start a connection, use the connection=20 > history (Joe's > > RFC) > > > > Well, there may be some gotchas of this scheme, but you can become > > conservative when there is some concrete information. > > > > Thanks, > > -Anantha > >> > >> To be more clear, here's the case: > >> > >> start 1000 connections in a row. > >> > >> during the first connection, lose some packets and do > >> normal TCP backoff > >> > >> so what do the other 999 connections start with? > >> ans: 10 packets > >> > >> The point is that subsequent connections don't do anything=20 > different. > >> If > >> you have 1000 connections, you're sending a certain amount of data > > into > >> the network without reacting. We're tripling that. > >> > >> That can easily cause congestion. At which point the *existing* > >> connections will backoff, but new connections keep making problems. > >> > >> Joe > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From ayourtch@cisco.com Thu Nov 18 16:50:45 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3C13A63EC for ; Thu, 18 Nov 2010 16:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.324 X-Spam-Level: ** X-Spam-Status: No, score=2.324 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_YOU_CAN_BECOME=1.258, FRT_LOLITA1=1.865, J_CHICKENPOX_24=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWPzrrYS7vTQ for ; Thu, 18 Nov 2010 16:50:43 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 70F683A63CB for ; Thu, 18 Nov 2010 16:50:43 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAJ0lkuC022105; Fri, 19 Nov 2010 01:47:46 +0100 (CET) Received: from sweet-brew-4.cisco.com (sweet-brew-4.cisco.com [144.254.10.205]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAJ0lfo2026070; Fri, 19 Nov 2010 01:47:41 +0100 (CET) Date: Fri, 19 Nov 2010 01:47:41 +0100 (CET) From: Andrew Yourtchenko To: Joe Touch In-Reply-To: <4CE595E3.3010109@isi.edu> Message-ID: References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se><36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com><4CE585E9.6060203@isi.edu><6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-869749773-1290127661=:27897" Cc: David Borman , tcpm , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 00:50:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-869749773-1290127661=:27897 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Thu, 18 Nov 2010, Joe Touch wrote: > That's basically what I'm suggesting; it can easily be per subnet, per > interface, or per the entire machine as desired. > > The ultimate point is: > > - put something in the end node that notices if/when > it fails objectively, and fixes it > > - that same thing can allow the IW to increase > over time if there are no problems I think this is a very viable idea. However, I think there is a catch due to which it would need tweaking - there should be a signaling mechanism whereby a node on the "conservative" side of the connection would be able to signal the node on the "eager" side of the connection not to be too aggressive, in case the data flow is mostly from from "eager" to "conservative" side. One might consider the following model for a path: [peer A] --- [access A] ----- [ backbone ] ---- [access B] --- [peer B] Where the "access A" and "access B" are the access networks for the peers, and the "backbone" is the "big Internet" inbetween. I am speculating based on experience (please correct me if I am wrong) that the congestion would typically be either in [access A] or [access B] cloud. So in case peer B is a server then storing the losses about the connections on a per-something basis would not be productive - because a connection from peer A may experience the congestion at access A, whereas connection from peer C would not traverse the same access network - so there would not be a congestion. OTOH if the congestion is in [access B] for both cases then storing the data in peer B would indeed make sense. If the above logic is right, then the peers during the 3whs should communicate their memorized values and pick up the minimum of theirs and the communicated by the peer. Therefore both parties know by the end of 3whs the IW value they are going to use - and can monitor the initial loss within the connection. If there happen to be a packet loss during the IW burst - both parties will be aware of it. the result: whether there was a loss or not - will affect the party that had the smaller value to begin with - if there was no loss, it means that party can use larger value for subsequent connections *if* it had LOSS_THRESH previous connections happen without the losses. If there was loss - that party will use smaller value for subsequent connections. I've done a poor man's simulation program (attached) to experiment with this idea - it seems more viable in terms of controlling the loss. It assumes a full mesh between 10 nodes with nodeX-nodeY backbone capacities potentially unique. What's more entertaining with this approach is that with sufficiently large value of LOSS_THRESH, it relatively converges *regardless* of the initial setting for IW. You can run this code in the following way: 1) Assume access and backbone links can uniformly support IW=10, nonadaptive: ./a.out 10 0 1000 10 11 10 11 | grep round ... Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 .... 2) Assume access and backbone links can uniformly support only IW=5, nonadaptive: ./a.out 10 0 1000 5 6 5 6 | grep round Results from the round: loss: 500, headroom: 0, avg IW size: 10.000000 Results from the round: loss: 500, headroom: 0, avg IW size: 10.000000 Results from the round: loss: 500, headroom: 0, avg IW size: 10.000000 3) same as (1), adaptive with the LOSS_THRESH=1000 and IW of 4: ./a.out 4 1 1000 10 11 10 11 | grep round Results from the round: loss: 2, headroom: 0, avg IW size: 10.020000 Results from the round: loss: 1, headroom: 0, avg IW size: 10.010000 Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 (loss fluctuates betweeen 0 and 2) 4) same as (2), same adaptive parameters as (3): ./a.out 4 1 1000 5 6 5 6 | grep round Results from the round: loss: 0, headroom: 0, avg IW size: 5.000000 Results from the round: loss: 1, headroom: 0, avg IW size: 5.010000 Results from the round: loss: 0, headroom: 0, avg IW size: 5.000000 Results from the round: loss: 0, headroom: 0, avg IW size: 5.000000 On to fun stuff with nonuniform distributions: Assume access links can support 5..8, and backbone 8..15 5) non-adaptive with IW=10: ./a.out 10 0 1000 5 8 8 15 | grep round Results from the round: loss: 434, headroom: 0, avg IW size: 10.000000 Results from the round: loss: 423, headroom: 0, avg IW size: 10.000000 Results from the round: loss: 415, headroom: 0, avg IW size: 10.000000 6) non-adaptive with IW = 5: ./a.out 5 0 1000 5 8 8 15 | grep round Results from the round: loss: 0, headroom: 71, avg IW size: 5.000000 Results from the round: loss: 0, headroom: 84, avg IW size: 5.000000 Results from the round: loss: 0, headroom: 66, avg IW size: 5.000000 7) adaptive with IW=10: ./a.out 10 1 1000 5 8 8 15 | grep round Results from the round: loss: 0, headroom: 12, avg IW size: 5.660000 Results from the round: loss: 0, headroom: 11, avg IW size: 5.670000 Results from the round: loss: 2, headroom: 13, avg IW size: 5.610000 Results from the round: loss: 0, headroom: 26, avg IW size: 5.47000 8) adaptive with IW=5: ./a.out 5 1 1000 5 8 8 15 | grep round Results from the round: loss: 0, headroom: 11, avg IW size: 5.550000 Results from the round: loss: 0, headroom: 10, avg IW size: 5.670000 Results from the round: loss: 1, headroom: 10, avg IW size: 5.750000 Results from the round: loss: 0, headroom: 3, avg IW size: 5.810000 Results from the round: loss: 2, headroom: 6, avg IW size: 5.800000 Results from the round: loss: 2, headroom: 0, avg IW size: 5.670000 9) (extreme:) - adaptive with IW=100: ./a.out 100 1 1000 5 8 8 15 | grep round Results from the round: loss: 0, headroom: 8, avg IW size: 5.550000 Results from the round: loss: 0, headroom: 3, avg IW size: 5.600000 Results from the round: loss: 0, headroom: 5, avg IW size: 5.68000 10) "conservative futuristic" - adaptive with IW=5, and access cap between 10 and 20 and backbone cap between 15 and 35: ./a.out 5 1 1000 10 20 15 35 | grep round Results from the round: loss: 0, headroom: 54, avg IW size: 14.200000 Results from the round: loss: 0, headroom: 58, avg IW size: 13.750000 Results from the round: loss: 0, headroom: 31, avg IW size: 13.470000 Results from the round: loss: 0, headroom: 53, avg IW size: 13.860000 Results from the round: loss: 0, headroom: 32, avg IW size: 13.590000 Results from the round: loss: 0, headroom: 41, avg IW size: 13.790000 Results from the round: loss: 0, headroom: 62, avg IW size: 14.290000 11) same as (10), "badly converging" - the THRESH being 5: ./a.out 5 1 5 10 20 15 35 | grep round Results from the round: loss: 20, headroom: 13, avg IW size: 14.140000 Results from the round: loss: 18, headroom: 9, avg IW size: 14.760000 Results from the round: loss: 21, headroom: 4, avg IW size: 14.470000 Results from the round: loss: 18, headroom: 6, avg IW size: 14.420000 Results from the round: loss: 19, headroom: 11, avg IW size: 14.370000 Results from the round: loss: 22, headroom: 11, avg IW size: 14.42000 12) same as (10) with the fixed IW of 10, non-adaptive: ./a.out 10 0 5 10 20 15 35 | grep round Results from the round: loss: 0, headroom: 398, avg IW size: 10.000000 Results from the round: loss: 0, headroom: 435, avg IW size: 10.000000 Results from the round: loss: 0, headroom: 418, avg IW size: 10.000000 Results from the round: loss: 0, headroom: 422, avg IW size: 10.000000 How to do the signaling during the 3whs is another story - might be either an option or some tricks with the TCP window size in 3whs, so far I am not talking about it. Critiques very welcome - as I said, it is a rather non-scientific simulation done in half an hour just to test the concept - you'll see some "non-working" logic commented out in the code, maybe there is a better approach. cheers, andrew (also, the security side of things on this approach would need to be given a thought. There are some interesting attacks lurking with all of the "adaptive" logic.) > > I'll be glad to write this up if people need a more concrete proposal. > > Joe > > On 11/18/2010 1:05 PM, Anantha Ramaiah (ananth) wrote: >> Why can't you do something like this : >> >> - If any one of the TCP connections egressing out of that interface >> (this can determined in TCP layer) is in the TCP retransmit state (or >> has experienced congestion in the past xxx secs/mins), then go back to a >> lower IW for new TCP connections which are using the same output >> interface.. >> >> - When you want to start a connection, use the connection history (Joe's >> RFC) >> >> Well, there may be some gotchas of this scheme, but you can become >> conservative when there is some concrete information. >> >> Thanks, >> -Anantha >>> >>> To be more clear, here's the case: >>> >>> start 1000 connections in a row. >>> >>> during the first connection, lose some packets and do >>> normal TCP backoff >>> >>> so what do the other 999 connections start with? >>> ans: 10 packets >>> >>> The point is that subsequent connections don't do anything different. >>> If >>> you have 1000 connections, you're sending a certain amount of data >> into >>> the network without reacting. We're tripling that. >>> >>> That can easily cause congestion. At which point the *existing* >>> connections will backoff, but new connections keep making problems. >>> >>> Joe >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > ---559023410-869749773-1290127661=:27897 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=congest.c Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=congest.c I2luY2x1ZGUgPHN0ZGlvLmg+DQoNCiNkZWZpbmUgQ09VTlQgMTANCg0KaW50 IGFjY2Vzc19jYXBhY2l0eVtDT1VOVF07DQppbnQgYmFja2JvbmVfY2FwYWNp dHlbQ09VTlRdW0NPVU5UXTsNCmludCBub2RlX2l3W0NPVU5UXTsNCmludCBu b2RlX25vbG9zc1tDT1VOVF07DQoNCnZvaWQgZmlsbF9pbml0aWFsKGludCBp dywgaW50IGxhYywgaW50IGhhYywgaW50IGxiYywgaW50IGhiYykgew0KICBp bnQgaSwgajsNCiAgZm9yKGk9MDsgaTxDT1VOVDsgaSsrKSB7DQogICAgbm9k ZV9pd1tpXSA9IGl3Ow0KICAgIG5vZGVfbm9sb3NzW2ldID0gMDsNCiAgICBh Y2Nlc3NfY2FwYWNpdHlbaV0gPSByYW5kKCkgJSAoaGFjLWxhYykgKyBsYWM7 DQogICAgZm9yKGo9MDtqPENPVU5UO2orKykgew0KICAgICAgYmFja2JvbmVf Y2FwYWNpdHlbaV1bal0gPSByYW5kKCkgJSAoaGJjLWxiYykgKyBsYmM7DQog ICAgfQ0KICB9DQp9DQoNCnZvaWQgaXRlcmF0ZShpbnQgYWRqdXN0LCBpbnQg bG9zc190aHJlc2gsIGludCAqcmxvc3MsIGludCAqcmhlYWRyb29tLCBpbnQg KnJpdykgew0KICAvLyByZXR1cm4gdGhlIGxvc3Mgb24gdGhlIGNvbm5lY3Rp b24NCiAgaW50IGksajsNCiAgaW50IGl3Ow0KICBpbnQgbWluY2FwOw0KICBp bnQgbG9zczsNCiAgaW50IGhlYWRyb29tOw0KDQogIGkgPSByYW5kKCkgJSBD T1VOVDsNCiAgaiA9IHJhbmQoKSAlIENPVU5UOw0KDQogIGl3ID0gbm9kZV9p d1tqXSA8IG5vZGVfaXdbaV0gPyBub2RlX2l3W2pdIDogbm9kZV9pd1tpXTsN Cg0KICAqcml3ID0gaXc7DQogIHByaW50ZigiQ29ubmVjdGlvbiBmcm9tIGJl dHdlZW4gJWRbaXcgJWQsIGNhcCAlZF0gYW5kICVkW2l3ICVkLCBjYXAgJWRd LCByZXN1bHRpbmcgaXcgPSAlZCwgYmFja2JvbmUgY2FwOiAlZFxuIiwNCiAg ICAgICBpLCBub2RlX2l3W2ldLCBhY2Nlc3NfY2FwYWNpdHlbaV0sDQogICAg ICAgaiwgbm9kZV9pd1tqXSwgYWNjZXNzX2NhcGFjaXR5W2pdLA0KICAgICAg IGl3LCBiYWNrYm9uZV9jYXBhY2l0eVtpXVtqXSApOw0KDQogIC8vIGNhbGN1 bGF0ZSB0aGUgbWluIGNhcGFjaXR5ID0gbWluIG9mIHR3byBhY2Nlc3MgYW5k IGJhY2tib25lDQoNCiAgbWluY2FwID0gYmFja2JvbmVfY2FwYWNpdHlbaV1b al07DQogIGlmIChtaW5jYXAgPiBhY2Nlc3NfY2FwYWNpdHlbaV0pIHsgbWlu Y2FwID0gYWNjZXNzX2NhcGFjaXR5W2ldOyB9DQogIGlmIChtaW5jYXAgPiBh Y2Nlc3NfY2FwYWNpdHlbal0pIHsgbWluY2FwID0gYWNjZXNzX2NhcGFjaXR5 W2pdOyB9DQoNCiAgLy8gbG9zcyBvY2N1cnMgaWYgaXcgaXMgYmlnZ2VyIHRo YW4gYSBtaW5pbXVtIGNhcGFjaXR5Lg0KICBsb3NzID0gaXcgPiBtaW5jYXAg PyBpdyAtIG1pbmNhcCA6IDA7DQogIC8vIGhlYWRyb29tIGlzIGEgbWVhc3Vy ZSBvZiBpbmVmZmljaWVuY3kgLSBob3cgbXVjaCBkaWQgd2UgdW5kZXJzaG9v dCB0aGUgY2FwYWNpdHkgb2YgdGhlIHBhdGgNCiAgaGVhZHJvb20gPSBpdyA8 IG1pbmNhcCA/IG1pbmNhcCAtIGl3IDogMDsNCg0KICBpZiAoYWRqdXN0KSB7 DQogICAgaWYgKGxvc3MpIHsNCiAgICAgIG5vZGVfbm9sb3NzW2ldID0gbm9k ZV9ub2xvc3Nbal0gPSAwOyANCiAgIA0KICAgICAgaWYgKG5vZGVfaXdbaV0g PCBub2RlX2l3W2pdKSB7DQoJLy8gbm9kZV9pd1tpXSAvPSAyOw0KCS8vIGlm KG5vZGVfaXdbal0gPiAyKSB7IG5vZGVfaXdbal0gLT0gMTsgfQ0KCWlmKG5v ZGVfaXdbaV0gPiAyKSB7IG5vZGVfaXdbaV0gLT0gMTsgfQ0KICAgICAgfSBl bHNlIHsNCgkvLyBub2RlX2l3W2pdIC89IDI7DQoJLy8gaWYobm9kZV9pd1tp XSA+IDIpIHsgbm9kZV9pd1tpXSAtPSAxOyB9DQoJaWYobm9kZV9pd1tqXSA+ IDIpIHsgbm9kZV9pd1tqXSAtPSAxOyB9DQogICAgICB9DQogICAgfSBlbHNl IHsNCiAgICAgIG5vZGVfbm9sb3NzW2ldKys7DQogICAgICBub2RlX25vbG9z c1tqXSsrOw0KDQogICAgICAvLyBubyBsb3NzLCBjYW4gdHJ5IGluY3JlbWVu dGluZyB0aGUgc21hbGxlciBzaWRlDQogICAgICBpZiAobm9kZV9pd1tpXSA8 IG5vZGVfaXdbal0pIHsNCglpZihub2RlX25vbG9zc1tpXSA+IGxvc3NfdGhy ZXNoKSB7IG5vZGVfaXdbaV0gKz0gMTsgfQ0KICAgICAgfSBlbHNlIHsNCglp Zihub2RlX25vbG9zc1tqXSA+IGxvc3NfdGhyZXNoKSB7IG5vZGVfaXdbal0g Kz0gMTsgfQ0KICAgICAgfQ0KICAgIH0NCiAgfQ0KDQogIHByaW50ZigiICAg cmVzdWx0IGhlYWRyb29tOiAlZCwgbG9zczogJWQsIG5ldyBpdyAlZCA9ICVk LCBuZXcgaXcgJWQgPSAlZFxuIiwgDQoJaGVhZHJvb20sIGxvc3MsIA0KCWks IG5vZGVfaXdbaV0sDQoJaiwgbm9kZV9pd1tqXSk7DQoNCiAgKnJsb3NzID0g bG9zczsNCiAgKnJoZWFkcm9vbSA9IGhlYWRyb29tOw0KfQ0KDQoNCmludCBt YWluKGludCBhcmdjLCBjaGFyICoqYXJndikgew0KICBpbnQgaSA9IDA7DQog IGludCBsb3NzLCBoZWFkcm9vbTsNCiAgaW50IGl3czsNCiAgaW50IGNsb3Nz LCBjaGVhZHJvb207DQogIGludCBjaXc7DQogIGludCBjb3VudCA9IDEwMDsN CiAgaWYoYXJnYyA8IDgpIHsNCiAgICBwcmludGYoInVzYWdlOiAlZCA8aW5p dGlhbCB3aW5kb3c+IDxhZGp1c3Q6IDEvMD4gPElXIGluY3JlbWVudCBzdWNj ZXNzIHRocmVzaG9sZD4gPGxvd2VyIGFjY2VzcyBjYXA+IDxoaWdoZXIgYWNj ZXNzIGNhcD4gPGxvd2VyIGJiIGNhcD4gPGhpZ2hlciBiYiBjYXA+XG4iKTsN CiAgICBleGl0KDApOw0KICB9DQogIGZpbGxfaW5pdGlhbChhdG9pKGFyZ3Zb MV0pLCBhdG9pKGFyZ3ZbNF0pLCBhdG9pKGFyZ3ZbNV0pLCBhdG9pKGFyZ3Zb Nl0pLCBhdG9pKGFyZ3ZbN10pKTsNCiAgd2hpbGUoMSkgew0KICAgIGl3cyA9 IGxvc3MgPSBoZWFkcm9vbSA9IDA7DQogICAgZm9yKGk9MDtpPGNvdW50O2kr Kykgew0KICAgICAgaXRlcmF0ZShhdG9pKGFyZ3ZbMl0pLCBhdG9pKGFyZ3Zb M10pLCAmY2xvc3MsICZjaGVhZHJvb20sICZjaXcpOw0KICAgICAgbG9zcyAr PSBjbG9zczsNCiAgICAgIGhlYWRyb29tICs9IGNoZWFkcm9vbTsNCiAgICAg IGl3cyArPSBjaXc7DQogICAgfQ0KICAgIHByaW50ZigiUmVzdWx0cyBmcm9t IHRoZSByb3VuZDogbG9zczogJWQsIGhlYWRyb29tOiAlZCwgYXZnIElXIHNp emU6ICVmXG4iLCBsb3NzLCBoZWFkcm9vbSwgKChmbG9hdClpd3MpLygoZmxv YXQpY291bnQpKTsNCiAgICANCiAgfQ0KDQp9DQo= ---559023410-869749773-1290127661=:27897-- From nanditad@google.com Thu Nov 18 16:54:52 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E3D3A6407 for ; Thu, 18 Nov 2010 16:54:52 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p669qOe2EHn6 for ; Thu, 18 Nov 2010 16:54:51 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 143A23A63CB for ; Thu, 18 Nov 2010 16:54:51 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id oAJ0tchR020458 for ; Thu, 18 Nov 2010 16:55:38 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290128139; bh=kkpFvV0x+AE5V15pRu1aum0hovg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=QtHur2GgoWJG5Htll4VynzSx8eTSpXBBZxnOjmtBjKUqUhqEYcDYa0KXeDgt8ktv2 z1duVPpM4m8tEpdCE8laA== Received: from gxk4 (gxk4.prod.google.com [10.202.11.4]) by wpaz24.hot.corp.google.com with ESMTP id oAJ0sx9Z004785 for ; Thu, 18 Nov 2010 16:55:37 -0800 Received: by gxk4 with SMTP id 4so2512665gxk.21 for ; Thu, 18 Nov 2010 16:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5FdXwk6y6elfko2nmJVgbGgOLQGIMfVNFsUNgGHEdYE=; b=p1IfpkCguzIk/l1wBkZjgTtbAwNTsil6S2NyC5frY8BlMoY39srzyaWt6h0qsmbJpR oD+p+ZtldbNT5pX6GXDA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CWjI+h+eTyhDTslGbfZjuoYaMosXMgU8lcNGkbofug+4166iDt/JOARFbM4OZtIG53 V/Ifpf+KzaBMNTYTrfqw== MIME-Version: 1.0 Received: by 10.91.45.16 with SMTP id x16mr1718781agj.15.1290128136964; Thu, 18 Nov 2010 16:55:36 -0800 (PST) Received: by 10.90.55.19 with HTTP; Thu, 18 Nov 2010 16:55:36 -0800 (PST) In-Reply-To: <4CE58F37.7000407@isi.edu> References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> Date: Thu, 18 Nov 2010 16:55:36 -0800 Message-ID: From: Nandita Dukkipati To: Joe Touch Content-Type: multipart/alternative; boundary=0016363b823a51894204955d5dd5 X-System-Of-Record: true Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 00:54:52 -0000 --0016363b823a51894204955d5dd5 Content-Type: text/plain; charset=ISO-8859-1 ... > > Really? You can tell the difference between 1 second and 0.8 >>> seconds? or 1.2 seconds? >>> >> >> Yep. That's what they tell me. I haven't run the tests, but yeah >> that's the right order for human perception to start. >> > > People can notice things down to about 200ms. That does NOT mean they know > 1 vs 1.2 seconds, though - and definitely not 400 vs 500ms. We looked at > this issue in the mid 90s when looking at web push systems. Fortunately, we don't have to speculate on the impact of delay on user behaviors. There are more recent (2009, 2010) studies that show that even small latency increases, such as 100ms, have measurable impacts (obviously negative) on user experience and perception. These studies describe experiments and go on to quantify the impact of delays ranging from 50-2000ms on user behavior, number of clicks, and such other metrics. * http://velocityconf.com/velocity2009/public/schedule/detail/8523 * http://googleresearch.blogspot.com/2009/06/speed-matters.html Other work along similar lines: http://velocityconf.com/velocity2010/public/schedule/detail/13031 http://velocityconf.com/velocity2009/public/schedule/detail/7709 http://www.gomez.com/pdfs/wp_why_web_performance_matters.pdf I think we can safely put to rest the question on whether IW10 benefits are significant enough to warrant it to be standardized. -Nandita > > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0016363b823a51894204955d5dd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

...

Really? You can tell the difference between 1 second and 0.8
seconds? or 1.2 seconds?

Yep. =A0That's what they tell me. =A0I haven't run the tests, but y= eah
that's the right order for human perception to start.

People can notice things down to about 200ms. That does NOT mean they know = 1 vs 1.2 seconds, though - and definitely not 400 vs 500ms. We looked at th= is issue in the mid 90s when looking at web push systems.

Fortunately, we don't have = to speculate on the impact of delay on user behaviors. There are more recen= t (2009, 2010) studies that show that even small latency increases, such as= 100ms, have measurable impacts (obviously negative) on user experience and= perception.=A0

These studies describe experiments and go on to quantify the= impact of delays ranging from 50-2000ms on user behavior, number of clicks= , and such other metrics.=A0

Other work along similar lines:

I think we can safely put to rest the question on wheth= er IW10 benefits are significant enough to warrant it to be standardized.

-Nandita
=A0


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

--0016363b823a51894204955d5dd5-- From touch@isi.edu Thu Nov 18 17:21:25 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939663A68AC for ; Thu, 18 Nov 2010 17:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Sr-uKJ3Dx2T for ; Thu, 18 Nov 2010 17:21:24 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E27493A63CB for ; Thu, 18 Nov 2010 17:21:23 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAJ1LvTH024795 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 17:22:00 -0800 (PST) Message-ID: <4CE5D135.4060109@isi.edu> Date: Thu, 18 Nov 2010 17:21:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Nandita Dukkipati References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@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, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 01:21:25 -0000 On 11/18/2010 4:55 PM, Nandita Dukkipati wrote: ... > Fortunately, we don't have to speculate on the impact of delay on user > behaviors. There are more recent (2009, 2010) studies that show that > even small latency increases, such as 100ms, have measurable impacts > (obviously negative) on user experience and perception. > > These studies describe experiments and go on to quantify the impact of > delays ranging from 50-2000ms on user behavior, number of clicks, and > such other metrics. > * http://velocityconf.com/velocity2009/public/schedule/detail/8523 > * http://googleresearch.blogspot.com/2009/06/speed-matters.html > > Other work along similar lines: > http://velocityconf.com/velocity2010/public/schedule/detail/13031 > http://velocityconf.com/velocity2009/public/schedule/detail/7709 > http://www.gomez.com/pdfs/wp_why_web_performance_matters.pdf If you care that much about latency, keep connections open and reuse them. Reusing connections saves 1 RTT - the same amount you will save with IW=10. Further, your IW won't matter, so you'll save that too. Second, you're saving 1 RTT. In most cases on reasonable nets, that's well under 100ms. The cases where that's not true are where you probably don't want to swamp the buffers (cell nets, bloated home DSL router buffers, bloated OS buffers). Third, the reduction in latency is 1 RTT out of 3 *best case*. For very short transfers. For anything longer, it's deep in the noise. Finally, I claim that this cannot possibly matter to the web. If it did, people wouldn't design web pages using bloated images and flash; they'd use simple HTML that would load and render faster. If I have to wait 10-20 seconds after a page shows up just to see the first content, can you really argue that 100ms is going to make or break anything? Joe From touch@isi.edu Thu Nov 18 17:29:47 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064933A68AC for ; Thu, 18 Nov 2010 17:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu963y1jwgG3 for ; Thu, 18 Nov 2010 17:29:46 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 27B753A63CB for ; Thu, 18 Nov 2010 17:29:46 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oAJ1UChY025220 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 17:30:12 -0800 (PST) Message-ID: <4CE5D324.1050609@isi.edu> Date: Thu, 18 Nov 2010 17:30:12 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Andrew Yourtchenko References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se><36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com><4CE585E9.6060203@isi.edu><6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: oAJ1UChY025220 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: David Borman , tcpm , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 01:29:47 -0000 Hi, Andrew, On 11/18/2010 4:47 PM, Andrew Yourtchenko wrote: > > > On Thu, 18 Nov 2010, Joe Touch wrote: > >> That's basically what I'm suggesting; it can easily be per subnet, per >> interface, or per the entire machine as desired. >> >> The ultimate point is: >> >> - put something in the end node that notices if/when >> it fails objectively, and fixes it >> >> - that same thing can allow the IW to increase >> over time if there are no problems > > I think this is a very viable idea. > > However, I think there is a catch due to which it would need tweaking - > there should be a signaling mechanism whereby a node on the > "conservative" side of the connection would be able to signal the node > on the "eager" side of the connection not to be too aggressive, in case > the data flow is mostly from from "eager" to "conservative" side. I think the rest of your argument boils down to how the client decides to aggregate it's idea of the best IW. That's up to the client to decide what it is willing to support - coarse or fine-grained. An IW=10 as a static proposal is the coarsest possible; anything else we could do can't be any worse. ... > If the above logic is right, then the peers during the 3whs should > communicate their memorized values and pick up the minimum of theirs and > the communicated by the peer. Congestion isn't often bidirectional, so it's unlikely IMO that a peer would know what to suggest to its counterpart (if I understand your proposal). However, your suggestion is that there could be additional input if someone - anyone - knew 'better' what to do. That's fine - that's just an out-of-band hint to the algorithm. Joe From nanditad@google.com Thu Nov 18 18:04:19 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE9428C0D7 for ; Thu, 18 Nov 2010 18:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.976 X-Spam-Level: X-Spam-Status: No, score=-109.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66TZQqE6v1TC for ; Thu, 18 Nov 2010 18:04:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id F385928C0D6 for ; Thu, 18 Nov 2010 18:04:15 -0800 (PST) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id oAJ252PR010068 for ; Thu, 18 Nov 2010 18:05:03 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290132304; bh=j3jPQOYs41iakKKIrwAasGgKKMg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=bw+IN/XnXR5eoXyruJwvay8nIEPZBhRX6lNw+QZqKBOPNpK8VPiFRT6RHUshgDMCA PjhQpQ3S+phVnz7nhAZ/Q== Received: from yxf34 (yxf34.prod.google.com [10.190.2.98]) by kpbe18.cbf.corp.google.com with ESMTP id oAJ251rP002528 for ; Thu, 18 Nov 2010 18:05:01 -0800 Received: by yxf34 with SMTP id 34so2227849yxf.18 for ; Thu, 18 Nov 2010 18:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jIa9/LJLxEYm5auPmPGjRYVm6D8/7HFj26ebXKIeo54=; b=jqrMBHrObamsa+wVUVa43KUTcZpP6ZvHiQL2Xt/kOx4lFnd9jlg8vzjdVrlmoaR8tk DVTe84imY/ulg6tZaDKA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HWNMccVaddi1KOl8HXmeoaTpF2cblY/r64YzTkjS80/PLmtOfrUSdTRE0N0hJPOQns BpIKUHzI2bCNJmn6jZ3Q== MIME-Version: 1.0 Received: by 10.91.159.5 with SMTP id l5mr303625ago.42.1290132299433; Thu, 18 Nov 2010 18:04:59 -0800 (PST) Received: by 10.90.55.19 with HTTP; Thu, 18 Nov 2010 18:04:58 -0800 (PST) In-Reply-To: <4CE5D135.4060109@isi.edu> References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <4CE5D135.4060109@isi.edu> Date: Thu, 18 Nov 2010 18:04:58 -0800 Message-ID: From: Nandita Dukkipati To: Joe Touch Content-Type: multipart/mixed; boundary=0016e65095c46bd31304955e5579 X-System-Of-Record: true Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 02:04:20 -0000 --0016e65095c46bd31304955e5579 Content-Type: multipart/alternative; boundary=0016e65095c46bd2fe04955e5577 --0016e65095c46bd2fe04955e5577 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 18, 2010 at 5:21 PM, Joe Touch wrote: > > > On 11/18/2010 4:55 PM, Nandita Dukkipati wrote: > ... > > Fortunately, we don't have to speculate on the impact of delay on user >> behaviors. There are more recent (2009, 2010) studies that show that >> even small latency increases, such as 100ms, have measurable impacts >> (obviously negative) on user experience and perception. >> >> These studies describe experiments and go on to quantify the impact of >> delays ranging from 50-2000ms on user behavior, number of clicks, and >> such other metrics. >> * http://velocityconf.com/velocity2009/public/schedule/detail/8523 >> * http://googleresearch.blogspot.com/2009/06/speed-matters.html >> >> Other work along similar lines: >> http://velocityconf.com/velocity2010/public/schedule/detail/13031 >> http://velocityconf.com/velocity2009/public/schedule/detail/7709 >> http://www.gomez.com/pdfs/wp_why_web_performance_matters.pdf >> > > If you care that much about latency, keep connections open and reuse them. > Reusing connections saves 1 RTT - the same amount you will save with IW=10. > Further, your IW won't matter, so you'll save that too. > > Second, you're saving 1 RTT. In most cases on reasonable nets, that's well > under 100ms. The cases where that's not true are where you probably don't > want to swamp the buffers (cell nets, bloated home DSL router buffers, > bloated OS buffers). > > Third, the reduction in latency is 1 RTT out of 3 *best case*. For very > short transfers. For anything longer, it's deep in the noise. > > Finally, I claim that this cannot possibly matter to the web. If it did, > people wouldn't design web pages using bloated images and flash; they'd use > simple HTML that would load and render faster. > > If I have to wait 10-20 seconds after a page shows up just to see the first > content, can you really argue that 100ms is going to make or break anything? > > A couple of points: 1) It seems like you are assuming that IW10 saves 1 RTT over IW3? This is incorrect. It can save up to 4 RTTs taking delayed ACKs into consideration, as shown in this attached plot (reposting from Jerry Chu's earlier email in IW10 thread). 2) The idea of keeping connections persistent is definitely an interesting one, and requires solving its own set of issues such as scaling the usage of memory (mainly on servers), as they will now have a large number of mostly idle connections. Even then, it does not entirely solve the issue at hand if one decays cwnd over time. Other practical consideration is of course NAT boxes that auto-timeout connections. > Joe > > --0016e65095c46bd2fe04955e5577 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Nov 18, 2010 at 5:21 PM, Joe Tou= ch <touch@isi.edu= > wrote:


On 11/18/2010 4:55 PM, Nandita Dukkipati wrote:
...

Fortunately, we don't have to speculate on the impact of delay on user<= br> behaviors. There are more recent (2009, 2010) studies that show that
even small latency increases, such as 100ms, have measurable impacts
(obviously negative) on user experience and perception.

These studies describe experiments and go on to quantify the impact of
delays ranging from 50-2000ms on user behavior, number of clicks, and
such other metrics.
* http://velocityconf.com/velocity2009/public/schedule/= detail/8523
* http://googleresearch.blogspot.com/2009/06/speed-matters= .html

Other work along similar lines:
http://velocityconf.com/velocity2010/public/schedule/d= etail/13031
http://velocityconf.com/velocity2009/public/schedule/de= tail/7709
http://www.gomez.com/pdfs/wp_why_web_performance_matters.pd= f

If you care that much about latency, keep connections open and reuse them. = Reusing connections saves 1 RTT - the same amount you will save with IW=3D1= 0. Further, your IW won't matter, so you'll save that too.

Second, you're saving 1 RTT. In most cases on reasonable nets, that'= ;s well under 100ms. The cases where that's not true are where you prob= ably don't want to swamp the buffers (cell nets, bloated home DSL route= r buffers, bloated OS buffers).

Third, the reduction in latency is 1 RTT out of 3 *best case*. For very sho= rt transfers. For anything longer, it's deep in the noise.

Finally, I claim that this cannot possibly matter to the web. If it did, pe= ople wouldn't design web pages using bloated images and flash; they'= ;d use simple HTML that would load and render faster.

If I have to wait 10-20 seconds after a page shows up just to see the first= content, can you really argue that 100ms is going to make or break anythin= g?


A couple of points:
<= br>
1) It seems like you are assuming that IW10 saves 1 RTT over = IW3? This is incorrect. It can save up to 4 RTTs taking delayed ACKs into c= onsideration, as shown in this attached plot (reposting from Jerry Chu'= s earlier email in IW10 thread).

2) The idea of keeping connections persistent is defini= tely an interesting one, and requires solving its own set of issues such as= scaling the usage of memory (mainly on servers), as they will now have a l= arge number of mostly idle connections. Even then, it does not entirely sol= ve the issue at hand if one decays cwnd over time. Other practical consider= ation is of course NAT boxes that auto-timeout connections.
=A0
Joe


--0016e65095c46bd2fe04955e5577-- --0016e65095c46bd31304955e5579 Content-Type: image/png; name="IW-vs-RTT.png" Content-Disposition: attachment; filename="IW-vs-RTT.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggoeln370 iVBORw0KGgoAAAANSUhEUgAAA2wAAAJ9CAYAAABJkfHbAAAgAElEQVR4nOzdeXxU1f3/8feFhKwQ giZICIso8AVRQFQMaom1BhTQYiuLWAhgBVoVZKkFURCLCypuYN0LVCnqz6LUWgSLgARFRZCAyCKg EJYkJoGQPZnz+wOZkpBMZiaZzE3m9fQxD5m5c8/53CWTeeeee69ljDECAAAAANhKTuZRBeVkHvV3 HQAAAACASjTydwEAAAAAgMoR2AAAAADApghsAAAAAGBTBDYAAAAAsCnbBLat32xT0+bn+LsMNFDs XwAAAKiPgtx9478/XKm3310uSZpw51hd2fsKnxXlS5+sXadrE/v6uwyvfLRqtVZ+vE6ff71FP3y/ V207XKgre/XUDb/qq35J19OfD73+t8V6Y+nLSjucqdEjx2j8uPFq3jzKZ/398OOPWr36v/rXv1O0 /8ABZWUdU7Nm0WrXto3Gjv6Nfn3zTQoKcvvHFwAAAPWUlZ1xpMr7sKVu/0Jr17+qqOaZ2rq1mUpK GsnhaKSwsDJdcslx5WTH6JeJ49TtoktrXMjWb7bpmr7XKjfnpxq1k5Z2WHOemK9v9+yXJDVuZGna hDs04Mb+2vjZ5/rNkNt05OC+Gtcb06qNMo4cdPvfNfFTVpbunjJdX23frfMHjFP0BT3U5LwLdfSH vTq6e6tyPn5JCZd00gvzH9U5LVrQXyVqun8dPnxE/W68XoP7Zevo98FKL+2mf/5zhRo18s1B6ti4 9mrceKgKCwdJ+j9JMQoLO6ImTXYrOPglxcZma82q5QoJCfFJ/wAAALAHl4HtuYXj9MCDeZKkpUuD ZYxkjCWHw2jkyBJJ0pxZEZp4z0s1LqSmX6jz8vL00GNP6o1l/09lV/9Bxa0SJYek4hyFrZqma3p1 UcrnnysvK1PZGUdqXG9dBbafsrLUp2+S2lx7q371h0cVGRYqh6S8Eim7SDpWIKXlFOr7v09X46/f 0aZ1q2oUohpqf97sXydPnlRERIQsy5Ik7dmzV31+0Vd5HznU755wXT1ogqZMmepxLe6IadVepaU5 ksokbVWTJifUtOnVahrZWBERZcrKvkP9kyI1/8m5PukfAAAA9uAysP196a266+7K/4LvyCtT6YkS LXypRGPufr/GhdQksDkcDt08fJS+zItV0YV3SoeOSGVxUmg3KTJaapqvJrvuU3GPJOnlm2sU2GJa tZEklZaWOoekVffvZs2a6vtd33rV322jxymzaQf9ZtrTOidUCguSHEY6USylF0qH86RDedIPudIP f7tXVwft01uLvA/Q/ujvWEi8vvvoTTWy/ve6OeP/xkilRgq6coSuCT3kVX/e7F9vLP2Hdu36Vg8/ 9LCkU0dvr+t3tY7+u0BffyANX3yeNn2xxeNa3BHTqr0aNxoi6T21bdtRwU2C9f33e9S2baqimkXI mK06ln6HUrd86pP+AQAAYA8uT4Jp3Pjs1xyFDpUeL1HZ8WKVniiR8q2z31THXnt9kVLWfqKQqFid s3+9ul/SU4czjumH/fvkiPydijpOU/FFz0txNe/Lk6NqNT3C9tGq1fpq+26Ne/MttQyXzguXvv30 P5p550gV5GXqjmeWK7r3r3WiWIoMlsJ+86g2PNRTH61a7dU5X5X1F9VEOnb0qEb2aCWrcSNdecdM tf71g4oMblxr/Y168SXtWvWGDv74g1RYKH3wgdSsmZSU5Hxvq/h2Ch30gDY8ca3X/XlqQ8oqvb9i lYKDm+jii7tr9+49at8+WAov0HkxUnbOSZ/1HRkZoZG3n6PJk75SVFQzSdJvh47Vnr3/VGjobWrS JFap2w/5rH8AAADYg9tXLTAlRqXHi1V6vORUYDtx6v+lJ5v4sj63LHxtsc5r216LXnhaV1x+ufP1 3bv3qM8vfinld5dCR0r17HSflR+vU+dB49Q8IlThVokWPzxD7/19mQoL31Vwk/l6ddLgcu+3QqJk bpqtDz9e51WgOd3fvH4xKj5ZPow0jg1W2eYSfXX7U/ruvhW64I//VEjY+fqpz7ga9xcVHqpGlqXm zZpJ114rnXOOlJYmrVwpvf76zwtnKSQkVNk16M9TR44c0Zw5Dm3a9Df9eKiRQpo4NGJEsRQuRcdI ObkF5Y6o1qbNmzaoRYto5/OfsrK0desWtY7/k8LCHMrP367/+7+La71fAAAA2Ev13zTLjEpPh7Of H7+c1Eh9+/7y1PQQafZfHjtrtnXr1umT1f+p7XrPkrLxM/2i92V67JGHFR4e7nzd4XDo3j8/JBPZ RorcJ+2dLR2teX9nDol099/eDonc9PUWdR57u7LT9uvZScOUcehcFRZukXSuSop/UeHdOTKO9lJ8 D3328d+9WrbT/TmsUilbUvP/TSvTqXMWSz7JU878VH3954vV7NaFtdKfcyjkG29IUVHSxx9LRUVS 27bSDz9I7dpJkiypRv15aurkBzR52kh9+22+goPPmJAhhUVLAy9tot/fMVqvvPq3Wg9tZ4a1rKxs DbhpuCIib1fMuRepSZM8pW6fq3snDq3VPgEAAGA/Lr9lOoqMig4XlAtrpcdL1LfvjXpm7lxpxw4p LExq0eLUUZHQUOe8kyZN8nnxktSx44V67pmnznp9167duubKHrrmyh6S8v43YdqUGvVXl0MiD3y/ Vxc1b6XnR/9SuZmtZRz/UrW3zou9UAf37/W6vx6tLnT9JksyU8pkzstTzu3J0m/n17i/Aoek0lJp 4kRpxYpTE0NCpNtvl157TZozR5JUYlSj5fPU1Vf1Ua9LE5WQsE5Ll+apU6efJ4Sferw9rkC/fTFF d/5+jF559W9qXNkY4hoqKi7WLbeOUn7etbrggvsUElKob3fepSt7X6A77xhd6/0BAADAXlwGttLc EhWlFZcPbCdKpFWrTn2R7tLl1DlHGRlSbq70yCPSPfdIkg7oQF3Ur9iYGD0278lKp908aKC6dPm/ s15Pz8hQbEyMr0ursXYXXKif0o9o6F/X6F9/GqastEEqLlws6dzKZzCS0veqzfnVhC4X/R39Ya+q vArN6T7mN5Y1N1QhYxeqsFm7Gvd3blQPmcaNpb17TwX/0/74R6lPH+nPf5YkFZapRsvnqRM/HdSC pxdq2f97V717P6DCwiKVFBvddHOw3p5RrKDG0jvjCvSbv27Qnb8fo5dfeb3WQ9us2Y/rWHo7der4 oEJDS7Rr90S1ic/TXxc8X6v9AAAAwJ5cHq4pyy1VUVrBWQ8lJEg//aQjX7yvfdvek44ckbZvl955 R5owQTu1U6u1uq6WQY8/8ZQeT4849TgaoSeW/FOffrlVnTt3Kve+/Px83TNpivbs8f4ITUyrNopp 1cY53NGdf1/QuatXffW+tKfSvtuq4ujzNXzRBl36664KCukpab0aB/9apwYJnn5ES40lHdqqhMt6 1qg/yxEkRZdvvlFssHRIanxthML/drFaPZCqwstH1Up/mYWSkVU+rElShw7Sb38rXXmlrLJSnSyp 2fJ5qqy0SAe+26Su7Zrp5fkPaeGTs/TXp2cp42hHDXsgTKVNpOAg6d0JBSpK+1Tj7hyrsrKyWq3h Px/9V+e1/KPCwsp0Mu9TlZWl6q2lryv0jKPZAAAAaLhcBrbi3LLyYe3wz4GtaVPtbfKjev/83zRN k9q3l1avllJStOFvY9VTdfOl2mnUbOn62VJJB1mZB/X03Fnlbmr8xZdf6rK+SVq/6Std1SfB624y jhxUxpGDCgoKcvvf3l7S/4Zf9dWxVS/pYHahDhcGq9v4J9TvLy8rOOw3Kit5X70fXK6r3zPq+A+j iFeN9ORRhW98STf+qm+N+vvFkgwNXW10x1qjP3xqNGr5ETkySqT2jRQXP0VxM77S8WbnSyWFtdLf oZxCGWOUk5Nz9uMvf1HOgw/KIavG/XkqsnmcHMahkpJilTkcKiouVfbJAg0aMEAZJzvpthfDVOY4 Fdr++YcC5R9cr/Hj7qjV0JaZeVjf7Rqk9esv0KZNv9M1V11BWAMAAAggLodE5pbEqijt8M9DIf83 NFJx0st6WcM0TDM0Q71+/m9Y6DDtffsR3XLNTdpy47C6WoZTjko6KCkkSUEX3K3EpFvUrl0HxcW1 1DffbFFecZmKctP1+Nw5dVtXDfRLul5XLv1/2vq36eow9mmFB0nBXW/QL9/JUFGZlFsipedJGYVS XqnUZMV0dT6vqZKu/1Xt9ddIMsHnKfF9o9wSKatIOlrL/X395sMqNZZatWl/1ntO34etzGqsJh89 rC6tm9fJFSIlqUlohNp2ukzFO79SflGZGuWV6viJXJUZo4H9+utfHxqNeGWP3vx9gZoEScv/UKCb F67ThPF36K8vvlorwyO//GxduQAYElrPLnUKAACAGnF54+xtW77Sh6/NV5P0H6SiUunn740nrhys lc+s1FIt1aW6VNu1XdfpOiUpSau0SstfuF5vP/xfzU51/6bCNblxdnRMK2ni+2ryxSoVX/i4dChc 2p8tpW+Xmh6W4lopJP9lXd4qXe+/tbjckTdP1fWNs3/KylLvvkkqu/RWNR/yqJqEhMpIKi47FZqO F0slRYVqsmK6GqW8qsL8kxr3+zv02CMPN7j+Gm98TQV5ubrnrj/ooVkPeNRPTfav08rKSvWvf72n 7w/sV3REiKIiQ7R46T/VutEevXFHgRo3kopKpK4PhuuVxe/q0p49vO7rtAs6X6L8/AI1siwZ41Dz 6Ob6dttXNW4XAAAA9YPL5HJJz8v05wVLNfntFE1+f5Mmf3DqcVInlaEM9dCpL6Td1E1btVXX6Bqt 0ir1+cMbUseOdbIAp0UsGavE6B8UtrK7ZL0ntf5G6lamJjE7Fbb3txqZ2EzLFr1Yo7Am1e2QSEk6 p0ULbVq3SldY+5R+f0/tXf6Mvv9yrX44eEiZ36xVyepnFP5YT/Uq2KKSogJJ0kuvvKon5z/T4Por Kjh1tc/nFryg5xf+1av+aqJx4yANHDRY3bt2UmREE0WEhWryXck6VNpRv3vt1PDItGzpeL5RzLlV XBjGQw6HdGP/9RoxYruGDfuPjMPlJWEAAADQwHh186hd2qV+6qdGZ+S9VmqlO3Xn/9506aU1Ls5d oaFhenvxK+qTcKX+/eFKPbHwKZWVnfpi2/Xi8/XgGx+pdeu4Wu2zWbOmHv27Js5p0UJvLXpJH61a rQ8/XqfPVv9dB/efulpiwmU9deO8GeqXdL3e/Mcy3XXPvZKkvPz8Btff3xYt0eRp90mSjh6thZvq eSGocWNde91Abf1yjfJP/KSIiHA9Mnuy7n9ovq58dJ9+zCjVn6dPV5s28bXWZ2iYQ+FhDpWUOH6+ GR0AAAAChcshkVXpcH1X3dz3ZkUpqsr3eHrj7JoMWftk7Tpdm1g3F6Kwu+cWvCBHWZkmTby7Qfb3 xFNPq6ysTH/+01SP5quNIZFncjjKtP+7L1VSeFIREZGKbtVRX369Xc2bN1fPHt1rpQ9JuvD/LlZ+ fqEaWZYcxqHo5s21gyGRAAAAAcOrwAYAAAAA8L2andAFAAAAAPAZAhsAAAAA2BSBDQAAAABsisAG AAAAADZFYAMAAAAAmwra++1Wf9cAAAAAAKjgwq49ZBljuKw/AAAAANgQQyIBAAAAwKYIbAAAAABg UwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAAmyKwAQAAAIBNEdgAAAAAwKYI bAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAAmyKwAQAAAIBNEdgA AAAAwKYIbAAAAABgUwQ2oJZZluXvErRu3Tq1bdvWFrW4Yqf66mqdVdX+6tWrdd555zmnV3wO2JUn +6g/92df9V3ffkbXrFmjli1b2qJuf9RQ231W154d1jPqPwIb0ABNmzZNCxYskDHG36XUOl/98vPH OjtzWWbMmKE33njD2X/F54GMLzyeYX0FHk+2+YwZM/Tmm286P1vqS+D2l0BcZtgPgQ0NkmVZ6t+/ f6VfdgPhwzc1NVU33HCDv8vwiLvbxVcBxh/r7Mxl2bFjhxITE6t87g/ubBPLspSRkaGWLVuqqKio 3LTBgweXe15YWKjY2FhlZGR4VAeh1TOsr/pr06ZNuuKKKxQSEqKOHTvqjTfecGs+T7b5tm3byn22 eDLvme8NhN+lkmfrJ1DWCeoegQ0NVosWLbRw4UJ/l+EXhYWFCg4O9ncZ9Yq/11lBQYGCgoKqfG5n MTExSkhI0IoVK5yvZWVlacWKFcrMzHS+tnz5cvXp00cxMTH+KBOwvSFDhmj8+PE6fvy4li9frvff f7/W+6hPny0ATiGwocF64YUXtGDBAn333XdVvqeyv4ad+ZplWfrrX/+qDh06KCQkRN26ddOGDRu0 aNEiderUSU2aNFHPnj2Vmpparo158+apZcuWioiI0JgxY8odeSgrK9P06dMVGxur8PBwDRs2TLm5 ueX6fPrpp9WmTRs1alT5j2hhYaF+//vfKyoqSlFRUbrzzjtVWFhYrn7Lsqr8a19lfbhq09119eKL L6p9+/bO9bJ161bn9KKiIo0ePVoRERE677zz9MQTT5zVTsWaK6uz4nRX6/o///mPunXrpiZNmqh9 +/Z69dVXq1wfFft3Z31Ut51cLXPFfs/sv7J6vNlv3Jmnqm3mzn50puTkZC1ZssT5fOPGjXI4HNq4 caPztUWLFik5ObnS+V1tq4rbvOLjtOqW1939oTL79u3TTTfdpKZNmyo0NFQ33HCD0tPT3Wrb3WWr ank9/Qzy5OeyoKBAo0aNcu6j8+bNc7m9q9unq9sG7q7TX/ziF1q2bFm59//444+Ki4vT8ePHq+2n ujo9qUWSSkpKNHnyZMXExCg6OlpPPfVUpe1s3rxZ8fHxevbZZyV5vs8VFBSoT58+Cg0NVbdu3fTO O++4fP9p7m7zyj5rPNlfqvrMOs2T7X+aq8/w6rZLTX7vXHjhhdqxY4fz+eLFi53/3rFjhy688MKz 1q03v8ckuawRcAeBDQ1W8+bN9eKLL+p3v/udSkpKvG7n448/1rp165Sdna3bbrtNN954oz788EP9 97//VU5Ojm699Vbdeeed5eZZv369UlNTtX//fh07dkwPPvigc9ojjzyizZs36+uvv9axY8cUFham ++67r9z8mzZt0tdffy2Hw1FpTTNnztThw4e1Z88e7d69Wz/++KMeeOABSf8bvmGMcTmUo2Ifrtp0 19q1a5WSkqLs7GwNHjy43Hp54IEHlJGRof379+ubb77RmjVrnNNc1VzdunC1rkeOHKmHHnpIubm5 Wr9+vT7//PNK26isf3fWR3W1uVpmV/1XVo83+40781S1zdzdj04bMGCANm/e7PwylZKSoqSkJKWk pEiS0tLStG3bNg0YMKDS+T3ZVqcfL7/8sgYOHOicVt3yuttHZQYNGqRJkyYpPT1dx44dU+fOnTV5 8mS32q5Jv5J3n0Fnqu7n8vjx4zpw4IBSU1O1YcMGl7VUt0+7s8+d5mqd3n///ZozZ065n605c+Zo 4sSJioqKqrYfd3/23KlFkmbPnq0dO3Zoy5Yt2r9/vw4dOnRWGx988IFuuOEGLVy4UBMnTpTk+bbv 16+frr/++rP+COgpd3+uK/vZdrW/nFbV54Mn2/80V5/h1W2X6up1tR/069dP69evlyQdOnRId999 tzNcrlu3Tv379z+rVm9/j7mzTgGXDNAAnblrT5s2zUyfPr3SaZX9CFScnpmZ6Xyel5dX6WtBQUHl 5tmzZ4/z+e7du018fLzzebt27cx3333nfH706FHTsmXLcvOnpaW5XL64uDize/du5/Ndu3aZ1q1b u1yuistYsQ9v2qy4rn766Sfn84rrpXXr1uXWy65du9zaFhXrrDiPq3Xdpk0b8/zzz5uDBw+e1bar ZTHGvfVR3XbyZJkr9l/xuTf7jTvzuNpm7vyKOPM9EydONE8//bQxxphrrrnGbNy40Vx11VXGGGMe eeQRM3HixCrbcbWtKqtj9erVpmfPnubEiRPO16pbXk/2h+rk5eWZmJgYt9r2dNlq4zPozH9X93P5 /fffO5/v2bPH5Xavbp92Z5+rSsV1evnll5s333zTGPO/n+28vDy3+qmuzupUrCU+Pt7s2rWr0vdK MgsWLDBxcXHmiy++KDfNk33u6aefNh07djTPPPOMadWqlfnkk0+c0w4fPmzOPffcKuf1ZJu7+qzx ZN7K1md126Wyul19hldUcbvU5PfO+++/b4YOHWqMMeaxxx4zMTEx5pVXXjHGGDNkyBCzYsWKs5bT 299jrmoE3EFgQ4N05odmUVGR6dWrl/n000/PmubOlyVX06uap7S01Pm8pKSk3IdzUFCQkVTuYVmW y/Yraty4scs+3AlstdGmJ+uqsvZ9va6/+OILM2jQIHPOOeeYDh06OH8BV6ZiXzVdx1W14W1g82a/ 8Wae6raJq/dv2bLF9OjRwxQVFZlu3boZY4zp0qWLKSwsNJ07dzZbtmypsh1X26piHTt27DAdO3Y0 Bw4c8Gh5PdkfKkpJSTFXX321iYiI8LhtT5at4mve/ly4+97q9tGKqnu/J/tcdev0vffeM507dzal paVm+PDh5rnnnnO7H0+Xq7paGjdubEpKSiqdV5Lp0KFDuT8MnubJPhcXF2dSU1ONMcZs3rzZXHDB Bebtt982xhjzwgsvmNtuu63KeWvye83beb35zKmsbVefs9Vtl5rs37m5uaZt27bGGGMuvvhi88EH H5g+ffoYY4xp27atOXnypEftuVOPq9cAV9hj0CBV9gWvS5cu5sSJE2d9uTj9F1tjjMnMzKyVL0tn /gVuz5495Y7MtGnTxhw6dMjt2isTFxd31l/54uLi3G6jsunVtVnTdVXxL5O7d+/2+bo+zeFwmH// +9/mvPPOO2taVX3VdB0b49kyVxfYvNlvvJmnJoHNGGN69OhhXnrpJTN27FhjjDHJycnmySefNN27 d6+2LWMq31Zn9nHs2DHTuXNns2HDhrPmrW55XfVRndatW5tly5aZnJwc43A4zPHjxytdP67armya rz6D3H1vXFxcjY6wVdynPdnnqlunDofDXHzxxWbatGmmffv2pqioyO1+qquzsve7qqW6I2wHDx40 F154oZk3b16l73FnnwsPDy93JO7IkSMmISHBPPfcc+aKK65w+QcPuwQ2d38Gz2zD1Wd4ddulpr93 EhMTzVtvvWWuuOIKY4wxV1xxhXnvvffMtdde61V7BDb4CuewISB07dpV48eP1913313u9e7du+vJ J59Ufn6+0tLSNH78+Frpb/LkycrIyFBGRobuvfde3Xbbbc5p48eP15133qnvv/9epaWlSk1N1bBh wzxqf+jQoc5x/enp6Zo4caLHbXjaZk3X1fDhw53rJT09XZMmTSo3vXnz5tq1a5fHdbta18OHD9e3 336rkpISGWNUWlrqdru1sY6rW2ZPeLPf1HRf82abjBo1SjNmzHBeNjwxMVGzZ8+u8mIjp7m7rW6+ +WZNnz5dV1111VnTqlve6vpwdbGNgoIChYaGKjQ0VPv37z/rHBRXbbua5qvPIHcNGzZMU6ZMUWZm pjIzM886P6ii6vZpT/a56tapZVm6//779cQTT2jmzJlq0qSJ2/14+rNXXS2jRo3S3XffrUOHDikn J0f33ntvuenx8fFat26dXnvtNT366KPl6nD3M+i3v/2thg4dqi1btqisrEwOh0P9+/fXpEmTtGPH Dp177rkul6GuVfb54M1njqvP8Oq2S3Wq2w/69++vyZMn6/bbb5ckjRgxQnfddVel56+50563v8eA avkzLQK+Utmu7XA4TL9+/cpN+/rrr03Pnj1NUFCQadeunXnhhRdq5a/bjz/+uImNjTXh4eFm1KhR pqCgwDm9rKzMPPLII6Zdu3YmODjYdOvWzSxbtsxl+xXl5+ebMWPGmKZNm5qmTZuaMWPGmPz8fLfb qGx6dW3WdF0VFBSYkSNHmrCwMBMbG2vmzZtXbvpf/vIXExkZ6fFfe12t63/84x+mc+fOJigoyFx0 0UVm5cqVbq+Tmq5jd5bZ1bJWfO7NfuPNPNVtE1fvN8aY9PR0Exwc7DxSsH//fhMcHGzS09OrbMMY 19uq4nqq+HB3eV31sWHDBuf5dpVZvny56dChg2ncuLFp27atee6558r17aptV9N89Rnk7nvz8vLM 7bff7txH586da4KDg6tcD9Xt057sc9WtU2OMeeedd0zHjh3PGo5YXT/V1VlRdbUUFxebiRMnmhYt Wpjo6Ggzf/78SpfpyJEjpkuXLmbOnDnGGM8+g/Ly8sy9995r2rRpY4KCgkyrVq3MhAkTzHfffWde fPFFc8stt1Q5r6efm7Uxb2WfD9Vtl8radvUZXt12qenvnS1btpigoCDn59OxY8dMUFCQ2bp1q1ft efN7DHCHZYwxNYt8AOAflmWJjzDUhl/+8pd64IEHdO211/q7FL/67rvvdOONN2rfvn3+LkXSqSOq w4YN0/Dhw/1dCgD4DUMiAQABb82aNQEb1u69915lZ2fr6NGjmjJlin7961/7uyQ5HA698sor2rt3 r4YOHervcgDAr7jVPQAAAax9+/bq1KmTCgsLddNNN2nOnDn+LkmNGzdW+/bt9dZbb1V5Y3oACBQM iQQAAAAAm+LPVgAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAAmyKw AQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZV7wKb ZVnOR1UyMzPVtm1bl+8BAAAAALurd4HNGCNjjMv3zJo1SxMmTKijigAAAADANyxTXfqxKcuyKg1u O3fu1KBBg7R9+3aFhYVVG+4AAAAAwK7q3RG26kydOlVz5sxRaGiov0sBAAAA0JClp0snT/q0iyCf tl7HVq9erczMTA0fPtyj+TjXDQAAAIC3THCtQXAAACAASURBVFKSNHDgqcf559dq2w1qSOQll1yi F154QVdffXWV73G3LQAAAACQJFmWVEVe8HWWaFCBraojZdUtIoENAAAAQJX8GNga1JDIygIcQQwA AABAfVXvAtuZR9FO/5tQBgAAAKAhqneBzZNwRpADAAAAUJ81uMv6AwAAAEBDQWADAAAAAJsisAEA AACATRHYAAAAAMCmCGwAAAAAYFMENh+wLEsZGRlq2bKlioqKyk0bPHhwueeFhYWKjY1VRkaGPvzw Q/Xt21ehoaE655xzNGzYMKWlpdVl6QAAAABshMDmIzExMUpISNCKFSucr2VlZWnFihXKzMx0vrZ8 +XL16dNHMTExevLJJzVp0iQdPXpUBw4c0MUXX6xbb73VH+UDAAAAsAECmw8lJydryZIlzucbN26U w+HQxo0bna8tWrRIycnJkqQ1a9Zo8ODBat68uZo2barJkydry5YtdV02AAAAAJsgsPnQgAEDtHnz ZqWnp0uSUlJSlJSUpJSUFElSWlqatm3bpgEDBpw1b15enp599lldd911dVozAAAAAPsI8ncBDVlw cLCGDBmipUuXatKkSUpJSdHjjz+uadOmSZKWLFmioUOHKjg4uNx8lmVJkmJjY53hzqWf329bxvi7 AgAAAKBe4gibjyUnJ2vx4sUqLi5Wdna2EhISlJWVpaKiIi1evNg5HPJMxhgdP35cd911l8aMGVN9 J8bY+wEAAADAKwQ2H+vRo4ekU+eq9e7dW5LUu3dvLViwQKGhoc7pFTVr1kxTp07VF198UWe1AgAA ALAXAlsdGDVqlGbMmKHExERJUmJiombPnn3W0bWRI0dq586dKi0t1dGjRzVz5kwlJCTUfcEAAAAA bIHAVgdGjBihEydOOANb3759VVRUpBEjRpR736BBgzRs2DCFhYWpe/fu+umnn/TWW2/5oWIAAAAA dmAZw0lGlmWJ1QAAAACgUpZV5bUZfJ0lOMIGAAAAADZFYAMAAAAAmyKwAQAAAIBNEdgAAAAAwKYI bAAAAABgUwQ2AAAAALApAhsAAAAA2BSBzQcsy1JGRoZatmypoqKictMGDx5c7nlhYaFiY2OVkZEh Sfrmm2/Ur18/RUZGqnXr1nr99dfrrG4AAAAA9kJg85GYmBglJCRoxYoVzteysrK0YsUKZWZmOl9b vny5+vTpo5iYGO3evVs33XSTxo0bp/T0dH322WfasGGDP8oHAAAAYAMENh9KTk7WkiVLnM83btwo h8OhjRs3Ol9btGiRkpOTJUmzZ8/WrFmzdMsttyg8PFxt27blCBsAAAAQwAhsPjRgwABt3rxZ6enp kqSUlBQlJSUpJSVFkpSWlqZt27ZpwIABkqQ1a9bo6NGjiouLU0REhIYMGaLs7Gy/1Q8AAADAvwhs PhQcHKwhQ4Zo6dKlkk4FttmzZzsD25IlSzR06FAFBwdLkjIzM7Vv3z5t375dBw8eVHh4uCZMmFBt P5bN/wMAAADgHcsYY/xdhL9ZlqXaXA1ntrd161aNHj1amzZtUq9evZSamqquXbtqy5Yt6t69u5Yt W6YePXpIkqKionTgwAFFR0dLOnXOW7t27ZSbm1trtQEAAADwkGVJVeSF2s4SFQX5rGVIkjOMLVq0 SL1795Yk9e7dWwsWLFBoaKhzuiRdcsklZ81vWRyhAgAAQAPA91qvMCSyDowaNUozZsxQYmKiJCkx MVGzZ892XmzktNGjR2vq1KnKzs5Wdna2Jk+erIEDB9Z9wQAAAIAvGFN/H35CYKsDI0aM0IkTJ5yB rW/fvioqKtKIESPKvW/MmDGKj49Xp06dFB8fr7y8PC1cuNAPFQMAAACwA85hk+/HnQIAAAABz8V5 YPWZr7MER9gAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMA AAAAmyKwecGyLGVkZKhly5YqKioqN23w4MHlnhcWFio2NlYZGRnOeU8/KjLG6L777lN0dLRatGih 6dOnc384AAAAIIAR2LwUExOjhIQErVixwvlaVlaWVqxYoczMTOdry5cvV58+fRQTEyPpVCirKoS9 /PLLWr9+vXbs2KHt27dr7dq1eu2113y7IAAAAABsi8BWA8nJyVqyZInz+caNG+VwOLRx40bna4sW LVJycrJb7S1evFhz585VXFyc4uLiNHfuXC1atKiWqwYAAABQXxDYamDAgAHavHmz0tPTJUkpKSlK SkpSSkqKJCktLU3btm3TgAED3Gpvx44duuyyy5zPe/XqpR07dtR+4QAAAADqBQJbDQQHB2vIkCFa unSppFOBbfbs2c7AtmTJEg0dOlTBwcFutXfy5ElFRkY6nzdt2lS5ubnVzmdZ9n4AAAAA8A6BrYaS k5O1ePFiFRcXKzs7WwkJCcrKylJRUZEWL17s9nBISYqMjNTJkyedz3Nzc9W0adNq5zPG3g8AAAAA 3iGw1VCPHj0knTpXrXfv3pKk3r17a8GCBQoNDXVOd8dFF12kr776yvl88+bNuuiii2q3YAAAAAD1 BoGtFowaNUozZsxQYmKiJCkxMVGzZ8/26OiaJI0cOVIzZ87U4cOHdfjwYc2cOdPjNgAAAAA0HJbh Rl+yLMuj+51VfH9GRoZat26tffv2KT4+XgcOHFCnTp2UlpbmvJz/mfNWdLqt0/dhe+WVVyRJ48aN 06OPPlrpPAAAAEC9YlkN8nwZT7OEx+0T2Hy/kgEAAICAR2DzCkMiAQAAAMCmCGwAAAAAYFMENgAA AACwKQIbAAAAANgUgQ0AAAAAbIrABgAAAAA2RWADAAAAAJsisHnBsixlZGSoZcuWKioqKjdt8ODB 5Z4XFhYqNjZWGRkZznlPPyrzzTffqF+/foqMjFTr1q31+uuv+2YhAAAAANgegc1LMTExSkhI0IoV K5yvZWVlacWKFcrMzHS+tnz5cvXp00cxMTGSJGNMlTfW2717t2666SaNGzdO6enp+uyzz7Rhwwbf LggAAAAA26p3gc3VEaqVK1fquuuuU1hYmM455xzdfvvtSk9P91ktycnJWrJkifP5xo0b5XA4tHHj RudrixYtUnJyslvtzZ49W7NmzdItt9yi8PBwtW3bliNsAAAAQACrd4HN1RGq+fPna+rUqcrIyNDO nTsVFRWl4cOH+6yWAQMGaPPmzc5QmJKSoqSkJKWkpEiS0tLStG3bNg0YMMCt9tasWaOjR48qLi5O ERERGjJkiLKzs31WPwAAAAB7q3eBzZVVq1bphhtuUGRkpGJjY/XEE084w5MvBAcHa8iQIVq6dKmk U4Ft9uzZzj6XLFmioUOHKjg42K32MjMztW/fPm3fvl0HDx5UeHi4JkyYUP2Mls0fAAAAALximaoO V9mcZVlVHmk77f3339czzzyjTz75pMZtVfX+rVu3avTo0dq0aZN69eql1NRUde3aVVu2bFH37t21 bNky9ejRw60+o6KidODAAUVHR0s6dU5cu3btlJub63ZtAAAAgC1ZllQ/o4dLnmYJTwX5rGU/27p1 q+69916tXLnSrfdXddVGSS43wOkwtmjRIvXu3VuS1Lt3by1YsEChoaGVhrWqXHLJJR7VBQAAgADE 98M6ZbkxZOxDfagbdaNP+m9QQyJPW7t2rW6++WYtW7ZMnTp1cmue0+fGVfaozqhRozRjxgwlJiZK khITEzV79my3LzZy2ujRozV16lRlZ2crOztbkydP1sCBAz1qAwAAAAHAmPr5qKdMFf99rs8lyWdh TWqAge2tt97SiBEj9O677+qKK66okz5HjBihEydOOANb3759VVRUpBEjRpz13jOvcFnxapdjxoxR fHy8OnXqpPj4eOXl5WnhwoV1sgwAAAAAPNNbvX3eR4M6h23+/Pl69tlntXLlSnXp0qVGbQEAAAC2 1EDPBbMrS5aMql7fvs4S9S6wVXZO1+lFqOp8r9zcXEVGRrpss56tBgAAAAQqAlud8ndgq3cXHXG1 MghdAAAAABqSBncOGwAAAAA0FAQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAA myKwAQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZF YAMAAAAAmyKwAQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAG AAAAADZFYAMAAAAAmyKwAQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAA AABsisAGAAAAADYV5O8CAAAAgDpnWf6uIKBYYn17i8AGAACAwGSMvysIKEasb28wJBIAAAAAbIrA BgAAAAA2RWADAAAAAJsisAEAAACATRHYAAAAAMCmCGwAAAAAYFMENgAAAACwKQIbAAAAANgUgQ0A AAAAbIrABgAAAAA2RWADAAAAAJsisAEAAACATRHYAAAAAMCmCGwAAAAAYFMENgAAAACwKQIbAAAA ANgUgQ0AAAAAbIrABgAAAAA2RWADAAAAAJsisAEAAACATRHYAAAAAMCmCGwAAAAAYFMENgAAAACw KQIbAAAAANgUgQ0AAAAAbIrABgAAAAA2RWADAAAAAJsisAEAAACATdW7wGZZlvNRkTFG9913n6Kj o9WiRQtNnz5dxhg/VAkAAAAANVfvApsxpsoQ9vLLL2v9+vXasWOHtm/frrVr1+q1116r4woBAAAA oHbUu8DmyuLFizV37lzFxcUpLi5Oc+fO1aJFi/xdFgAAAAB4xTL1dMygZVlnHWmLiorSwYMH1axZ M0nS8ePH1b59e2VnZ3vcFgAAABowy5L4/ldnLFkyapjr29dZokEFtsaNG6ukpESNGp06cOhwONSk SROVlpZW25Yr9XQVAQAA+FY136Fsr559x7NUv9d3TQKbvXc1Sz17Gl1+udSrl3TZZdLFF0vBwbXT elDtNGMPkZGROnnypPMIW25urpo2berWvIQyAAAAL/Adqk411KNU7rDjrpaTI0VHS19/7bs+GtQ5 bBdddJG++uor5/PNmzfroosu8mNFAAAAABqq5s1930eDCmwjR47UzJkzdfjwYR0+fFgzZ85UcnKy v8sCAAAAAK/UuyGRZ55vdvrfp4czjhs3Tvv27XMeVRs3bpzGjh1b90UCAAAAQC2otxcdqU1cJRIA AMALXGmxTjXkKy1Wx867mq+zRIMaEgkAAAAADQmBDQAAAABsisAGAAAAADZFYAMAAAAAmyKwAQAA AIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAA myKwAQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZF YAMAAAAAmyKwAQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAG AAAAADZFYAMAAAAAmwrydwEAAAABy7L8XUFAsRS46ztgdjV/LecyScN807RljDG+abr+sCxLrAYA AFDnLEviO0idsWTJKDDXd8DsapZUp5t4q2T19G2WILCJwAYAAPwkYL5F2wOBzd9V1IG6DmzyfZbg HDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANkVgAwAAAACbIrABAAAAgE0R2AAAAADApghs AAAAAGBTBDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANkVgAwAAAACbIrABAAAAgE0R2AAA AADApghsAAAAAGBTBDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANkVgAwAAAACbIrABAAAA gE0R2AAAAADApghsAAAAAGBTBDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANtWgAtvu3buV lJSkiIgIRUREKCkpSbt37/Z3WQAAAADglQYV2IYOHao+ffooLS1NaWlp6t27t4YNG+bvsgAAAADA K5Yxxvi7iNoSFhamnJwchYSESJIKCwvVokUL5efnu5zPsiw1oNUAAADqC8uS+A5SZyxZMgrM9R0w u5ol1fUm9nWW8PoI2yuvvKI77rhDkvSvf/1LrVq1UkxMjD766KNaK85TAwcO1OOPP67jx48rJydH jz32mAYMGOC3egAAAACgJrw+wta+fXutX79ebdu2VYcOHbRw4UKVlJTo/vvvV2pqam3X6Za0tDRd ddVV+uGHHyRJ7dq108aNGxUXF+dyPsuyXE7n6BsAADZUze/veqMefc+wVP/XubdH2BrC7ubWrtYA lrOhHWHzOrAFBwfr5MmTSk9P16WXXqqMjAwVFRWpadOmKi4uru063XL99dcrISFBkydPliQ99dRT +vzzz7V69WqX8zEkEgCAeihgxnjZB0MK/V1FHfDDkML6ztdZIsjbGTt27KgPPvhAaWlp6tOnjyTp +++/1wUXXFBrxXnq008/1QcffOA8h+3+++9X8+bN/VYPAAAAANSE14Ft3rx5Sk5OVnh4uN59911J 0sMPP6xZs2bVWnGe6tq1qx599FFNmjRJkjR//nx169bNb/UAAAAAQE00qKtE7ty5U3/84x/1+eef S5ISEhL0wgsvqHPnzi7nY0gkAAD1UMCMUbMPhkT6u4o6wJBIj9n2HLaGhMAGAEA9FDDfoO2DwObv KuoAgc1jtr2sf2Fhof70pz8pPj5ewcHBatOmje677z4VFRXVZn0AAAAAELC8Dmzjx4/Xzp07tXbt WhUUFGjNmjXavn27JkyYUJv1AQAAAEDA8npIZEREhA4cOKCYmBjna+np6Tr//POVl5dXawXWBYZE AgBQDwXMGDX7YEikv6uoAwyJ9Jhth0RGRkZ69DoAAAAAwDNeB7YpU6Zo7Nix2rt3r8rKyrR3716N GTNGU6ZMqc36AAAAACBgeT0k0rIst95XH4YaMiQSAIB6KGDGqNkHQyL9XUUdYEikx3ydJby+cTYB BwAAAAB8y+shkQAAAAAA3/LoCNuZh/tcDYnk6BsAAAAA1JxHge3MIEYoAwAAAADf8npIZKNGjKYE AAAAAF/yOnXFxcUpMzOzNmsBAAAAAJyhRvdhu+eee3TkyJHarAcAAAAA8DOf3Ietvp3fxn3YAACo hwLmxlj2wX3Y/F1FHeA+bB6z3X3YThdEwAEAAAAA3+LKIQAAAABgUwQ2AAAAALApj4dESq7PX5Pq 3zlsAAAAAGBHXgU2AhkAAAAA+B5DIgEAAADApghsAAAAAGBTHgc2hkMCAAAAQN3gCBsAAAAA2BSB DQAAAABsisAGAAAAADZFYAMAAAAAm3L7PmzV3Sz7TFyYBAAAAABqzu0jbMaYco958+bpxhtv1O7d u1VSUqJdu3apf//+mjdvni/rBQAAAICAYRkvD4e1bNlSqampio2Ndb527Ngxde/eXUePHq21AuuC ZVkcFQQABB4PRs/YVj35/W2pAazrnxl5vs4bwq4mubG7NZDl9GITBzRfZwm3h0RWlJube9YwScuy lJubW+OiAABAHakngach8CboNCQBs6sFynKiznh90ZFbb71VY8eO1d69e1VWVqa9e/dqzJgxGjJk SG3WBwAAAAABy+vA9tJLL6lz585KTExUSEiIEhMT1bVrV7344ou1WR8AAAAABCyvz2FrSDiHDQAQ kCwrgMap+ZclK6CHRAbMrmaJIZEByNdZgvuwAQAAAIBNeR3YtmzZossvv1zBwcGyLKvcAwAAAABQ c14HtjFjxmjQoEE6fvz4WfdoAwAAAADUnNfnsAUHB+v48eMKDw+v7ZrqHOewAQACUsCcWOR/nMMW ILsa57AFJNuew9a6dWvl5OTUZi0AAAAAgDN4Hdjuu+8+TZ48WVlZWbVZDwAAAADgZ14PiXR1cZH6 NryQIZEAgIAUMOPU/I8hkQGyqzEkMiD5OksEeTsjAQcAAAAAfIv7sAEAAACATXl9hK0hDYkEAAAA ADuqtSGRP/30k8aPH6/rrruuxkUBAAAAAGpw0ZHKHDp0SFdffbUOHDhQW03WCS46AgAISAFzJQj/ 46IjAbKrcdGRgOTrLFGrgS0/P1/NmzdXcXFxbTVZJwhsAICAFDDfov2PwBYguxqBLSDZ9sbZFeXn 5+vJJ59Ut27daqtJAAAAAAhotXbRkaCgIHXv3l2vvfZajYsCAAAAAHAfNgAAAACwLe7DBgAAAAA2 5XVgKygo0JQpU9S6dWsFBwcrPj5e06ZNU2FhYW3WBwAAAAABy+vAdtddd+nbb7/VJ598ooKCAq1Z s0apqam65557arM+AAAAAAhYXl/Wv1mzZtq7d69iY2Odrx07dkydOnXS8ePHa63AusBl/QEAASlg rrXuf1zWP0B2NS7rH5DqzWX9pbOvHAkAAAAA8J7Xge3WW2/VmDFjtHfvXpWVlWnPnj0aPXq0hgwZ Upv1AQAAAEDA8jqwLViwQJ06dVLfvn0VEhKixMREdenSRc8//3xt1gcAAAAAAcvrc9gaEs5hAwAE pIA5scj/OIctQHY1zmELSPXmHLbc3Fy99NJL6tWrV201CQAAAAABzePAtn37dvXs2VMhISG68sor 9cMPP2j58uXq1KmTPv74Yz366KO+qNNt33zzjfr166fIyEi1bt1ar7/+ul/rAQAAAABveRzY7rnn Hv3mN7/RiRMn1L9/fyUkJOjZZ5/Vl19+qXfeeUdJSUm+qNMtu3fv1k033aRx48YpPT1dn332mTZs 2OC3egAAAACgJjw+hy0iIkKHDx9WVFSUcnJyFB0drb179+qCCy7wVY1uu+222/SrX/1KY8aM8Wg+ zmEDAASkgDmxyP84hy1AdjXOYQtItjuHLT8/X1FRUZKk5s2bS5I6dOhQu1V5ac2aNTp69Kji4uIU ERGhIUOGKDs7299lAQAAAIBXauWiI3a5YXZmZqb27dun7du36+DBgwoPD9eECRPcmteyrCofAACU Y1kN42FjVgP7z6t1YINdxOe7mtXAHoAPeDwk0p0A46/hhVFRUTpw4ICio6MlSVlZWWrXrp1yc3Nd zseQSACARwJmfJf/BPoQQilAdjNLDCFEvefrLBHk6Qx2DjaXXHLJWa9xhAwAAABAfVVr92Gzg9Gj R2vq1KnKzs5Wdna2Jk+erIEDB/q7LAAAAADwSoMKbGPGjFF8fLw6deqk+Ph45eXlaeHChf4uCwAA AAC84vE5bA0R57ABADwSECcX+RfnsAXIbsY5bGgAbHdZfwAAAABA3SCwAQAAAIBNEdgAAAAAwKYI bAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAAmyKwAQAAAIBNEdgA AAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAAmyKwAQAA AIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALApAhsAAAAA2BSBDQAAAABsisAGAAAAADZFYAMAAAAA myKwAQAAAIBNEdgAAAAAwKYIbAAAAABgUwQ2AAAAALCpIH8XAAAIEJbl7woaLEuBvW4b/K7V0JcP gEsENgBA3THG3xU0WEaBvW4b/K7V0JcPQJUYEgkAAAAANkVgAwAAAACbIrABAAAAgE0R2AAAAADA pghsAAAAAGBTBDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANkVgAwAAAACbIrABAAAAgE0R 2AAAAADApghsAAAAAGBTBDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANkVgAwAAAACbIrAB AAAAgE0R2AAAAADApghsAAAAAGBTBDYAAAAAsCkCGwAAAADYFIENAAAAAGyKwAYAAAAANkVgAwAA AACbIrABAAAAgE0R2AAAAADAphpkYMvMzFTbtm1lWZa/SwEAAAAArzXIwDZr1ixNmDDB32UAAAAA QI1Yxhjj7yJq086dOzVo0CBt375dYWFhcmfxLMty630AgBqwLInPWp+wZMkocNdtg9+1LCmANy9g e77OEg3uCNv/b+/eg6yu6z6Af87DLrCCXFMLCMQZdAp1aiY10y4EmRkkTigXHUidgZpnpkApdQaz MG8zSVlm89DY5a9I62nm+YOYEFMxyUzJIG6GOUPocnNBYoFh5fv8YazLsnvO2cPlfPfs6zWzM5zL 73c+5/P7nu+e9/6+5zB//vxYuHBh9O3bt9qlAAAAHJe6ahdwIi1fvjx27twZ06dP7/K2xT7v5uwb cEL4XO0pVYie1++eMMQ6+o2cIqIHHm6gh6ipJZEXXnhhPPLII3H55ZdHRPmnJy2JBE6Jml+3lZee uEywRwwxywOBzJzsLFFTga2zs2SlnqLABpwSPeLddD4EtholsAGZOdlZoqaWRLZvlCAGAAB0ZzX3 pSMAAAC1oqYDm7NrAABAd1bTgQ0AAKA7E9gAAAAyJbABAABkSmADAADIlMAGAACQKYENAAAgUwIb AABApgQ2AACATAlsAAAAmRLYAAAAMiWwAQAAZEpgAwAAyJTABgAAkCmBDQAAIFMCGwAAQKYENgAA gEwJbAAAAJkS2AAAADIlsAEAAGRKYAMAAMiUwAYAAJApgQ0AACBTAhsAAECmBDYAAIBMCWwAAACZ EtgAAAAyJbABAABkSmADAADIVF21CwC6mUKh2hVQQiF6yDEqpBJ3SN2uE6WeUVnbd7cnDUBRAhvQ del431ZysqXjfuufv0LU4FAsxPGnNgBqiiWRAAAAmRLYAAAAMiWwAQAAZEpgAwAAyJTABgAAkCmB DQAAIFMCGwAAQKYENgAAgEwJbAAAAJkS2AAAADIlsAEAAGRKYAMAAMiUwAYAAJApgQ0AACBTAhsA AECmBDYAAIBMCWwAAACZEtgAAAAy0pVPBQAAErpJREFUJbABAABkSmADAADIlMAGAACQKYENAAAg UwIbAABApgQ2AACATAlsAAAAmRLYAAAAMiWwAQAAZEpgAwAAyJTABgAAkKmaCmzLli2L8ePHR0ND QwwdOjRuuOGG2L59e7XLAgAAqEhNBbZFixbF/PnzY8eOHbF+/foYOHBgTJ8+vdplAQAAVKSQUkrV LuJkaW5ujiFDhsSBAweK3q9QKEQNtwFOrEIhwusla4UoRIraP0Y1ORQLET3g0AHUlJOdJWrqDFt7 y5cvj0svvbTaZQAAAFSkrtoFnCx//etfY968ebFs2bKy7l8oFDq9zdm3GlTkeFNcIUW8cxqgxhW6 8+s+dXqEuvOzaq+nDEUAeraaDGxPPfVUzJo1Kx5//PE499xzy9pGKOuBHPMK9ZDldlGjQ8SSOwDo VmpuSeSvfvWruP766+M3v/lNXHzxxdUuBwAAoGI1dYZt0aJF8dBDD8UTTzwRH/jAB6pdDgAAwHGp qW+J7OxzaHv37o3+/fsX3a6G2kA5avLr5U4N30DYzVkSCQAn1MnOEjV1hk3oAgAAaknNfYYNAACg VghsAAAAmRLYAAAAMiWwAQAAZEpgAwAAyJTABgAAkCmBDQAAIFMCGwAAQKYENgAAgEwJbAAAAJkS 2AAAADIlsAEAAGRKYAMAAMiUwAYAAJApgQ0AACBTAhsAAECmBDYAAIBMCWwAAACZEtgAAAAyJbAB AABkSmADAADIlMAGAACQKYENAAAgUwIbAABApgQ2AACATAlsAAAAmRLYAAAAMiWwAQAAZKqu2gVk o1DtAji1kmNeoRSp2iWcEinCGAEAqk5gO6JnvAcFAAC6EUsiAQAAMiWwAQAAZEpgAwAAyJTABgAA kCmBDQAAIFMCGwAAQKYENgAAgEwJbAAAAJkS2AAAADIlsAEAAGRKYAMAAMiUwAYAAJApgQ0AACBT AhsAAECmBDYAAIBMCWwAAACZEtgAAAAyJbABAABkSmADAADIlMAGAACQKYENAAAgUwIbAABApgQ2 AACATAlsAAAAmRLYAAAAMiWwcVwKhUK1S+i29K5yelc5vauc3lVO7yqnd5XRt8rpXX4ENgAAgEwJ bAAAAJmqqcCWUorbbrstBg8eHEOGDIk77rgjUkrVLgsAAKAiNRXYFi9eHM8880z8/e9/j7Vr18ZT Tz0Vjz76aLXLAgAAqEhNBbZf/OIXcc8998SwYcNi2LBhcc8998TPf/7zapcFAABQkUKqoTWDAwcO jC1btsSAAQMiImLPnj1x9tlnR1NTU9HtCoWCpZMV0rvK6V3l9K5yelc5vauc3lVO7yqjb5XTu647 2T2rqcDWq1evOHToUPzXf71z4vDw4cPRu3fvaGlpKbqdry8FAAAqdTIjVd1J23MV9O/fP/7973+3 nmHbu3dvnH766SW3q6HMCgAA1JCa+gzb2LFj4y9/+Uvr5RdffDHGjh1bxYoAAAAqV1OBbebMmbFg wYJ4/fXX4/XXX48FCxbEl770pWqXBQAAUJGaWhI5Z86cePXVV1vPqs2ZMyduvvnmKlcFAABQmZr6 0hEAAIBaUlNLIgEAAGqJwAYAAJApgQ0AACBTAhsAAECmBDYAAIBMCWwAAACZEtgAAAAyJbD9R6FQ aP2hfMuWLYvx48dHQ0NDDB06NG644YbYvn17tcvqVnbu3BkjR4409rpg06ZNccUVV0S/fv2iX79+ ccUVV8SmTZuqXVaWSs1tL7/8cnz2s5+N/v37x/Dhw+OnP/3pKa4wT0uXLo1PfvKT0bdv3xg6dGhM mzYttm7d2nq7ua+4csaVue8dxV6jpcZZT54LS/WmbV87629Pnf/K6c3xjEtOPIHtP1JK4f8Q77pF ixbF/PnzY8eOHbF+/foYOHBgTJ8+vdpldSt33XVXfOUrX6l2Gd3K1KlT42Mf+1hs3bo1tm7dGpdc cklMmzat2mVlqdjctmnTpvjCF74Qc+bMie3bt8eqVavi2WefPcUV5um73/1uzJ07NxobG+O1116L Cy64IK699trW2819nSt3XJn73lHsNVpqnPXkubCc1+CR3nbU454+/xXrTdvbO2L+O/UKSUo5SqFQ ENyOQ3NzcwwZMiQOHDhQ7VK6hfXr18ekSZNi7dq10dDQYOyVqaGhIXbv3h19+vSJiIgDBw7EkCFD orm5ucqV5aujuW3GjBkxYcKEuOmmm6pUVfexf//+GDJkSOzfv7/D28197ypnXJn7jlXO+4/248xc +K72vSnVz548/3XlvW4l45ITzxk2Tqjly5fHpZdeWu0yuo358+fHwoULo2/fvtUupVuZOHFiPPDA A7Fnz57YvXt33H///fH5z3++2mV1O08++WQ0NjbGsGHDol+/fnHddddFU1NTtcvKzr59++Khhx6K 8ePHd3ofc9+7yhlX5r7KtB9n5sJ3dfQaHDp0aPTu3TvOO++8uO++++Ltt99uva2nz3/FetNV5r9T IHEULanc6tWr0+jRo9PGjRurXUq38Pvf/z5dfPHF6fDhwyklY68r/vWvf6VRo0aliEgRkUaNGpW2 bt1a7bKy1tH46tWrV7r55pvTrl270q5du9KsWbPS1KlTq1Bdvo6MsTPPPDO98sorHd7H3He0UuPK 3NexUn3oaJyZC99R7DXY0tKSXn755TRu3Lg0d+7c1uvNf533pq1KxiUnnlmyHb84KvOHP/whjRw5 Mj3//PPVLqXbuOCCC9LKlStbLxt75ZswYUK68847U1NTU2pqakoLFixIEyZMqHZZWetofA0YMCC9 +eabrZd37dqV+vfvfyrL6hb27NmTFi5cmD7+8Y8fc5u571ilxpW5r2PF+tDZODMXlv8afOONN9Kg QYNaL5v/3tW+N21VMi458cyS7fjF0XVLlixJw4YNSy+88EK1S+lWjvxFtP0PpfXp0ycdOHCg9fL+ /ftTnz59qlhR/joaW5dffvkxb1hOP/30U1lWt9Hc3HzMGDP3dazUuDL3dayzHhQbZz19LuzKa3Db tm1pwIABrZfNf+9q35u2KhmXnHg+w8ZxWbRoUXzjG9+IJ554Ij7ykY9Uu5xuJXXwDU3JB+/L8sEP fjDuu+++2L17d+zevTvuvffeOP/886tdVrdz4403xvz586OpqSmamprilltuiYkTJ1a7rCzMnDkz 1q9fHy0tLdHY2BgLFiw46jMa5r7OlRpX5r7ylRpnPXkuLNWb6dOnx9q1a6OlpSU2b94cN954Y0yZ MqX19p48/5XqTSnmvyqoVlLMTfhrX0U66ltEpL1791a7tG7HmCvfunXr0rhx41JDQ0NqaGhIn/70 p9OGDRuqXVaWSs1t3/zmN9N73vOedNppp6UpU6Yc9Rfnnuyxxx5LF154Yaqrq0tnnnlmmjVrVtq2 bVvr7ea+4royrnr63FfsNVpqnPXkubBUb9q+hocPH57mzZuXmpubj9pHT53/yunN8YxLTjxf6w8A AJApSyIBAAAyJbABAABkSmADAADIlMAGAACQKYENAAAgUwIbAABApgQ2AACATAlsAAAAmRLYAAAA MiWwAQAAZEpgAwAAyJTABgAAkCmBDQAAIFMCGwCdevrpp2PkyJFRKBSqXQoA9EgCGwCd+vrXvx4P P/xwpJRO6eNWIyAKpQDkSGADyEyhUOj051Rbs2ZNfO5znzuh+9yzZ0/MnTs3Ro8eHfX19TFkyJCY PHlyrFixovU+pzogHs9jlnO8NmzYEF/84hdj6NCh0adPn7jooovi17/+dYf7GDRoUFx33XWxY8eO Th+znB52R0IzwLEENoDMpJRafzq6fCodOHAg6uvrT+g+p06dGocOHYonn3wyDhw4EBs3bowZM2bE 3XfffUIf51QpdbxeeeWVGDduXEyYMCE2bdoUb731Vjz88MOxZMmSDvezadOm6NOnT8yZM6fTx6y1 HgJQRAIgW+2n6YhIixYtSiNGjEiFQiGllNLmzZvTpEmTUv/+/VOfPn3SlVdembZt23bUNj/+8Y/T qFGjUn19ffrQhz6UVq9e3Xr70qVL09ixY1N9fX0aNWpU+slPftK6XduflFJqaWlJt99+ezrjjDNS Q0NDmjp1anrrrbeK1tde79690969e8t+3u3raHtbqXo6e27lPGaxnpWzjyNmzJiRvve973Vpu127 dqV+/fp1ev9yeliqN83NzWnmzJnptNNOS2eddVZ64IEHjunBI488kkaPHp169+6dxo4dm1auXJl+ 9rOfpTFjxrT25W9/+1vZj1msr50d464cQ4Ba5AwbQDfz/PPPx0svvRSHDx+OiIhJkybF3LlzY/v2 7bFt27Y477zz4pZbbjlqm6eeeir++Mc/RlNTU1xzzTUxe/bs1ttmzpwZ3/72t2Pv3r3xzDPPxJ/+ 9KeIiGPOGEVE3HvvvfHiiy/GSy+9FNu2bYuGhoa47bbbitbX3mWXXRazZ8+OVatWxf79+0s+39Tm jNXixYtj4sSJrbeVqqez51aOYj3rihUrVsTUqVO7tE2ppYHl9LBUb+68887Ys2dPvPbaa7FmzZp4 9tlnj9nHE088EU8//XQ0NTXFjBkz4qqrroqlS5fGihUrYvfu3XHttdce1Zdyxkdnfe1ovEUc3zEE qAlVi4oAlNR+mo6ItHXr1qLb7Nu3L51xxhlHbbNr166jbq+rq2u9/P73vz/98Ic/TFu2bCn5+KNG jUobNmxovdzY2JjOOuusLtXX1NSUbr/99jR27NjUt2/fNHLkyPS1r30tvfnmm50+bkopLV++PH34 wx8+6oxNqXqKPbdiz7VUz8rZxxF1dXXp0KFDZW+3ffv2NGvWrHT11Vd3ev9yeliqN8OHD0+bN29u vfzKK68c04OdO3e2Xt63b1+H17XtSznjo1hfO+pfV44hQC0qpFSFD0UAUJZCoXDU2Yb2lyMinnvu ubjtttti9erVsW/fvtb7HTnD1dE2ba974YUX4u67747nnnsuBg4cGN///vdj0qRJHW5bX18fLS0t x+yr2GMVk1KKjRs3xoMPPhivvfZaLF++vMP9rFu3LiZPnhzLly+PUaNGlV1PsefWXtvHLNWzznR0 n/e+972xevXqeN/73ld0uyMGDBgQn/nMZ+JHP/pRnHXWWUUfL6LzHpbqTV1dXRw8eDB69eoVEREt LS1RX1/f5R60va6S8VGq7105hgC1SGADyFg5gW3EiBHx4IMPxpVXXhkDBgyIvXv3xsCBA7v8xjul FL/73e/i5ptvjjfeeKPD+40cOTJWrVoVw4cPL6vecjU3N8fgwYPj4MGDx+xn+/bt8YlPfCIeffTR uOyyy47arlQ9xZ5bsdpPZGC7/vrr45JLLomvfvWrXdquq9r3sFRvhg8fHitXroxzzjknIiL+8Y9/ xJgxY44rsFUyPkr1/YhyjiFALfIZNoBubv/+/dG3b9/o27dv/POf/+zyZ62mT58e69ati0OHDkVK 6ZgzJG19+ctfjtmzZ8fmzZujpaUl1qxZE9OmTevS433qU5+Kxx57LLZt2xZvv/12bNmyJW6//fb4 6Ec/2uH9r7766rjjjjuOCWvl1NOV53ayfOtb34r7778/Fi9eHG+++WYcPHgw/vznP8eUKVMq3mc5 PSzVm2nTpsWtt94aO3fujJ07dx7zucdKHO/4GDRoUGzcuPGo63I4hgBVdaLXWAJw4rSfpjuatn/7 29+mc845J/Xq1SuNHDky/eAHPzjms0jF9vvLX/4ynXfeeamuri6NHTs2LVu2rNNt33777XTvvfe2 fsvf+eefn5YsWVL0sdpbsWJFuuaaa9LgwYNTr1690ogRI9JNN92UGhsbO9xPFPmWyFL1FHtuxXpS qmfl7KOtdevWpWuuuSYNGjQo9e7dO1100UXp8ccf79K+2yqnh6V6s2/fvnTDDTekhoaGdOaZZ6Z7 7rkn1dfXF62p1HWVjI+2133nO99J/fv3L3t8AvQElkQCALFhw4a46qqr4tVXX612KQC0YUkkAPRQ 8+bNi6ampmhsbIxbb701Jk+eXO2SAGhHYAOAHurss8+Oc889N8aMGRODBg2KhQsXVrskANqxJBIA ACBTdbt3Nla7BgAAADpgSSQAAECm6o7846Ef/U816wAAAOA/7rrrrti9s/HdwBYR8bX/nlOtegAA AGjHkkgAAIBMCWwAAACZEtgAAAAyJbABAABkSmADAADIlMAGAACQKYENAAAgUwIbAABApgQ2AACA DDz2v/8Xg97z3qOuE9gAAAAyMHv27GOuq6tCHQAAALSze2fjMdc5wwYAAFAlbZdBWhIJAACQkbbL IC2JBAAAyEjbZZCWRAIAAFRZZ8sgLYkEAACoss6WQVoSCQAAUGWdLYO0JBIAAKAKylkGaUkkAABA FZSzDLLkksj2aQ4AAIATp23mKuffhaYdb6RTUxoAAABd8f/NT+6Q0+o4gwAAAABJRU5ErkJggg== --0016e65095c46bd31304955e5579-- From touch@isi.edu Thu Nov 18 19:22:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB9E23A6887 for ; Thu, 18 Nov 2010 19:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIQ47TPRpn6u for ; Thu, 18 Nov 2010 19:22:00 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 44A243A6768 for ; Thu, 18 Nov 2010 19:22:00 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAJ3LrHS012565 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Nov 2010 19:22:06 -0800 (PST) Message-ID: <4CE5ED4D.20103@isi.edu> Date: Thu, 18 Nov 2010 19:21:49 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Andrew Yourtchenko References: <20101110152857.GA5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se><36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com><4CE585E9.6060203@isi.edu><6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <4CE5D324.1050609@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: "Anantha Ramaiah \(ananth\)" , tcpm , David Borman Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 03:22:02 -0000 On 11/18/2010 6:26 PM, Andrew Yourtchenko wrote: > Hi Joe, ... >>> However, I think there is a catch due to which it would need tweaking - >>> there should be a signaling mechanism whereby a node on the >>> "conservative" side of the connection would be able to signal the node >>> on the "eager" side of the connection not to be too aggressive, in case >>> the data flow is mostly from from "eager" to "conservative" side. >> >> I think the rest of your argument boils down to how the client decides >> to aggregate it's idea of the best IW. That's up to the client to >> decide what it is willing to support - coarse or fine-grained. > > No. IW of the client does not really matter - it sends the short GET > request. The server side is the one that may generate congestion by > having large IW. It doesn't matter what side you call client or server; they each get an IW. > So it needs either to remember all the clients somehow, or take a hint. Right now you assume all remote ends are the same -- IW=3. The proposal is to assume they're the same and IW=10. Even if you presume they're the same, you can treat them as a group, and if 'most of the time in the past' IW=10 caused losses, you can backoff and use IW=5 for future connections for a while. Yes, it's possible to 'learn' this for subsets of remote ends, but that's an optimization that can be implemented in whatever granularity desired. > "Average temperature in the hospital" approach (aggregating on the > server) will not be useful. Well, that's exactly what we're doing now when we pick a fixed IW anyway. So if that's bad, then let's not do it now either ;-) >> An IW=10 as a static proposal is the coarsest possible; anything else >> we could do can't be any worse. >> >> ... >>> If the above logic is right, then the peers during the 3whs should >>> communicate their memorized values and pick up the minimum of theirs and >>> the communicated by the peer. >> >> Congestion isn't often bidirectional, so it's unlikely IMO that a peer >> would know what to suggest to its counterpart (if I understand your >> proposal). > > If I connect to http://foo.example/ which sends me an IW=10 and I lose 5 > packets out of that, and I connect to http://bar.example/ which sends me > an IW=10 and I lose 5 packets out of that, my assumption that if I > connect to http://baz.example, most chances are that I will also be able > to get up to 5 packets - so I better give it a hint based on my previous > knowledge. If they tell you their IW, you still need to know they actually sent 5. You don't know they're lost - they may have never been sent. So IW knowledge isn't enough to do anything per se. Joe From ayourtch@cisco.com Thu Nov 18 19:30:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87F23A6887 for ; Thu, 18 Nov 2010 19:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=1.381, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WsBtjChE2la for ; Thu, 18 Nov 2010 19:30:37 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 4179B3A6768 for ; Thu, 18 Nov 2010 19:30:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAJ2dgtk006808; Fri, 19 Nov 2010 03:39:42 +0100 (CET) Received: from sweet-brew-4.cisco.com (sweet-brew-4.cisco.com [144.254.10.205]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAJ2dc3D013233; Fri, 19 Nov 2010 03:39:38 +0100 (CET) Date: Fri, 19 Nov 2010 03:39:38 +0100 (CET) From: Andrew Yourtchenko To: Joe Touch In-Reply-To: <4CE5D135.4060109@isi.edu> Message-ID: References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <4CE5D135.4060109@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 03:30:39 -0000 On Thu, 18 Nov 2010, Joe Touch wrote: > > > On 11/18/2010 4:55 PM, Nandita Dukkipati wrote: > ... >> Fortunately, we don't have to speculate on the impact of delay on user >> behaviors. There are more recent (2009, 2010) studies that show that >> even small latency increases, such as 100ms, have measurable impacts >> (obviously negative) on user experience and perception. >> >> These studies describe experiments and go on to quantify the impact of >> delays ranging from 50-2000ms on user behavior, number of clicks, and >> such other metrics. >> * http://velocityconf.com/velocity2009/public/schedule/detail/8523 >> * http://googleresearch.blogspot.com/2009/06/speed-matters.html >> >> Other work along similar lines: >> http://velocityconf.com/velocity2010/public/schedule/detail/13031 >> http://velocityconf.com/velocity2009/public/schedule/detail/7709 >> http://www.gomez.com/pdfs/wp_why_web_performance_matters.pdf > > If you care that much about latency, keep connections open and reuse them. > Reusing connections saves 1 RTT - the same amount you will save with IW=10. > Further, your IW won't matter, so you'll save that too. > > Second, you're saving 1 RTT. In most cases on reasonable nets, that's well > under 100ms. The cases where that's not true are where you probably don't > want to swamp the buffers (cell nets, bloated home DSL router buffers, > bloated OS buffers). > > Third, the reduction in latency is 1 RTT out of 3 *best case*. For very short > transfers. For anything longer, it's deep in the noise. > > Finally, I claim that this cannot possibly matter to the web. If it did, Which scientific evidence backs up this claim ? > people wouldn't design web pages using bloated images and flash; they'd use > simple HTML that would load and render faster. By the same logic, smoking is not harmful for people - because if it were, noone would be smoking. > > If I have to wait 10-20 seconds after a page shows up just to see the first > content, can you really argue that 100ms is going to make or break anything? This is not about the sites that take 20 seconds to load. This is about the sites that try to squeeze every millisecond for the better user experience. We should not put everything into the same basket. thanks, andrew > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From ayourtch@cisco.com Thu Nov 18 19:30:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022123A68BA for ; Thu, 18 Nov 2010 19:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVTeo9NqkQo6 for ; Thu, 18 Nov 2010 19:30:38 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 270D43A676A for ; Thu, 18 Nov 2010 19:30:38 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAJ2QtDk005320; Fri, 19 Nov 2010 03:26:56 +0100 (CET) Received: from sweet-brew-4.cisco.com (sweet-brew-4.cisco.com [144.254.10.205]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAJ2QrDk005448; Fri, 19 Nov 2010 03:26:53 +0100 (CET) Date: Fri, 19 Nov 2010 03:26:53 +0100 (CET) From: Andrew Yourtchenko To: Joe Touch In-Reply-To: <4CE5D324.1050609@isi.edu> Message-ID: References: <20101110152857.GA5094@hell> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se><36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com><4CE585E9.6060203@isi.edu><6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <4CE5D324.1050609@isi.edu> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-3036460-1290133613=:27897" Cc: "Anantha Ramaiah \(ananth\)" , tcpm , David Borman Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 03:30:40 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-3036460-1290133613=:27897 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi Joe, On Thu, 18 Nov 2010, Joe Touch wrote: > Hi, Andrew, > > On 11/18/2010 4:47 PM, Andrew Yourtchenko wrote: >> >> >> On Thu, 18 Nov 2010, Joe Touch wrote: >> >>> That's basically what I'm suggesting; it can easily be per subnet, per >>> interface, or per the entire machine as desired. >>> >>> The ultimate point is: >>> >>> - put something in the end node that notices if/when >>> it fails objectively, and fixes it >>> >>> - that same thing can allow the IW to increase >>> over time if there are no problems >> >> I think this is a very viable idea. >> >> However, I think there is a catch due to which it would need tweaking - >> there should be a signaling mechanism whereby a node on the >> "conservative" side of the connection would be able to signal the node >> on the "eager" side of the connection not to be too aggressive, in case >> the data flow is mostly from from "eager" to "conservative" side. > > I think the rest of your argument boils down to how the client decides to > aggregate it's idea of the best IW. That's up to the client to decide what it > is willing to support - coarse or fine-grained. No. IW of the client does not really matter - it sends the short GET request. The server side is the one that may generate congestion by having large IW. So it needs either to remember all the clients somehow, or take a hint. "Average temperature in the hospital" approach (aggregating on the server) will not be useful. > > An IW=10 as a static proposal is the coarsest possible; anything else we > could do can't be any worse. > > ... >> If the above logic is right, then the peers during the 3whs should >> communicate their memorized values and pick up the minimum of theirs and >> the communicated by the peer. > > Congestion isn't often bidirectional, so it's unlikely IMO that a peer would > know what to suggest to its counterpart (if I understand your proposal). If I connect to http://foo.example/ which sends me an IW=10 and I lose 5 packets out of that, and I connect to http://bar.example/ which sends me an IW=10 and I lose 5 packets out of that, my assumption that if I connect to http://baz.example, most chances are that I will also be able to get up to 5 packets - so I better give it a hint based on my previous knowledge. > However, your suggestion is that there could be additional input if someone - > anyone - knew 'better' what to do. That's fine - that's just an out-of-band > hint to the algorithm. well, I've added the proposal you had about adjusting only one side, added an extra parameter to the code, and am attaching it. To save you a compile, just three runs: 1) Static IW=10, access capacity 5..8, backbone capacity 8..15 ./a.out 10 0 1000 5 8 8 15 1 | grep round Results from the round: loss: 423, headroom: 0, avg IW size: 10.000000 Results from the round: loss: 436, headroom: 0, avg IW size: 10.000000 Results from the round: loss: 423, headroom: 0, avg IW size: 10.000000 Results from the round: loss: 426, headroom: 0, avg IW size: 10.000000 2) One-side-adjustment (what I understand is your proposal): ./a.out 10 1 1000 5 8 8 15 1 | grep round Results from the round: loss: 66, headroom: 10, avg IW size: 6.380000 Results from the round: loss: 52, headroom: 14, avg IW size: 6.180000 Results from the round: loss: 62, headroom: 10, avg IW size: 6.350000 Results from the round: loss: 63, headroom: 9, avg IW size: 6.210000 3) With the hint: ./a.out 10 1 1000 5 8 8 15 0 | grep round Results from the round: loss: 1, headroom: 32, avg IW size: 5.420000 Results from the round: loss: 0, headroom: 37, avg IW size: 5.350000 Results from the round: loss: 1, headroom: 29, avg IW size: 5.350000 Results from the round: loss: 1, headroom: 41, avg IW size: 5.350000 Results from the round: loss: 0, headroom: 50, avg IW size: 5.290000 So, the "hint" has roughly the same effect on the new proposal as the new proposal on the original proposal - of course at the expense of being a bit more conservative. Whether this effect is significant enough and whether the simulation is a good enough approximation - I'd be very curious to hear. cheers, andrew > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > ---559023410-3036460-1290133613=:27897 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=congest2.c Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=congest2.c I2luY2x1ZGUgPHN0ZGlvLmg+DQoNCiNkZWZpbmUgQ09VTlQgMTANCg0KaW50 IGFjY2Vzc19jYXBhY2l0eVtDT1VOVF07DQppbnQgYmFja2JvbmVfY2FwYWNp dHlbQ09VTlRdW0NPVU5UXTsNCmludCBub2RlX2l3W0NPVU5UXTsNCmludCBu b2RlX25vbG9zc1tDT1VOVF07DQoNCnZvaWQgZmlsbF9pbml0aWFsKGludCBp dywgaW50IGxhYywgaW50IGhhYywgaW50IGxiYywgaW50IGhiYykgew0KICBp bnQgaSwgajsNCiAgZm9yKGk9MDsgaTxDT1VOVDsgaSsrKSB7DQogICAgbm9k ZV9pd1tpXSA9IGl3Ow0KICAgIG5vZGVfbm9sb3NzW2ldID0gMDsNCiAgICBh Y2Nlc3NfY2FwYWNpdHlbaV0gPSByYW5kKCkgJSAoaGFjLWxhYykgKyBsYWM7 DQogICAgZm9yKGo9MDtqPENPVU5UO2orKykgew0KICAgICAgYmFja2JvbmVf Y2FwYWNpdHlbaV1bal0gPSByYW5kKCkgJSAoaGJjLWxiYykgKyBsYmM7DQog ICAgfQ0KICB9DQp9DQoNCnZvaWQgaXRlcmF0ZShpbnQgbm9faGludCwgaW50 IGFkanVzdCwgaW50IGxvc3NfdGhyZXNoLCBpbnQgKnJsb3NzLCBpbnQgKnJo ZWFkcm9vbSwgaW50ICpyaXcpIHsNCiAgLy8gcmV0dXJuIHRoZSBsb3NzIG9u IHRoZSBjb25uZWN0aW9uDQogIGludCBpLGo7DQogIGludCBpdzsNCiAgaW50 IG1pbmNhcDsNCiAgaW50IGxvc3M7DQogIGludCBoZWFkcm9vbTsNCg0KICBp ID0gcmFuZCgpICUgQ09VTlQ7DQogIGogPSByYW5kKCkgJSBDT1VOVDsNCg0K ICBpZihub19oaW50KSB7DQogICAgIGl3ID0gbm9kZV9pd1tpXTsNCiAgfSBl bHNlIHsNCiAgICAgaXcgPSBub2RlX2l3W2pdIDwgbm9kZV9pd1tpXSA/IG5v ZGVfaXdbal0gOiBub2RlX2l3W2ldOw0KICB9DQoNCiAgKnJpdyA9IGl3Ow0K ICBwcmludGYoIkNvbm5lY3Rpb24gZnJvbSBiZXR3ZWVuICVkW2l3ICVkLCBj YXAgJWRdIGFuZCAlZFtpdyAlZCwgY2FwICVkXSwgcmVzdWx0aW5nIGl3ID0g JWQsIGJhY2tib25lIGNhcDogJWRcbiIsDQogICAgICAgaSwgbm9kZV9pd1tp XSwgYWNjZXNzX2NhcGFjaXR5W2ldLA0KICAgICAgIGosIG5vZGVfaXdbal0s IGFjY2Vzc19jYXBhY2l0eVtqXSwNCiAgICAgICBpdywgYmFja2JvbmVfY2Fw YWNpdHlbaV1bal0gKTsNCg0KICAvLyBjYWxjdWxhdGUgdGhlIG1pbiBjYXBh Y2l0eSA9IG1pbiBvZiB0d28gYWNjZXNzIGFuZCBiYWNrYm9uZQ0KDQogIG1p bmNhcCA9IGJhY2tib25lX2NhcGFjaXR5W2ldW2pdOw0KICBpZiAobWluY2Fw ID4gYWNjZXNzX2NhcGFjaXR5W2ldKSB7IG1pbmNhcCA9IGFjY2Vzc19jYXBh Y2l0eVtpXTsgfQ0KICBpZiAobWluY2FwID4gYWNjZXNzX2NhcGFjaXR5W2pd KSB7IG1pbmNhcCA9IGFjY2Vzc19jYXBhY2l0eVtqXTsgfQ0KDQogIC8vIGxv c3Mgb2NjdXJzIGlmIGl3IGlzIGJpZ2dlciB0aGFuIGEgbWluaW11bSBjYXBh Y2l0eS4NCiAgbG9zcyA9IGl3ID4gbWluY2FwID8gaXcgLSBtaW5jYXAgOiAw Ow0KICAvLyBoZWFkcm9vbSBpcyBhIG1lYXN1cmUgb2YgaW5lZmZpY2llbmN5 IC0gaG93IG11Y2ggZGlkIHdlIHVuZGVyc2hvb3QgdGhlIGNhcGFjaXR5IG9m IHRoZSBwYXRoDQogIGhlYWRyb29tID0gaXcgPCBtaW5jYXAgPyBtaW5jYXAg LSBpdyA6IDA7DQoNCiAgaWYgKGFkanVzdCkgew0KDQogICAgaWYgKG5vX2hp bnQpIHsNCiAgICAgIGlmIChsb3NzKSB7DQogICAgICAgIGlmKG5vZGVfaXdb aV0gPiAyKSB7IG5vZGVfaXdbaV0tLTsgfQ0KICAgICAgfSBlbHNlIHsNCglu b2RlX25vbG9zc1tpXSsrOw0KCWlmKG5vZGVfbm9sb3NzW2ldID4gbG9zc190 aHJlc2gpIHsgbm9kZV9pd1tpXSArPSAxOyB9DQogICAgICB9DQogICAgfSBl bHNlIHsNCg0KICAgICAgaWYgKGxvc3MpIHsNCglub2RlX25vbG9zc1tpXSA9 IG5vZGVfbm9sb3NzW2pdID0gMDsgDQogICAgIA0KCWlmIChub2RlX2l3W2ld IDwgbm9kZV9pd1tqXSkgew0KCSAgLy8gbm9kZV9pd1tpXSAvPSAyOw0KCSAg Ly8gaWYobm9kZV9pd1tqXSA+IDIpIHsgbm9kZV9pd1tqXSAtPSAxOyB9DQoJ ICBpZihub2RlX2l3W2ldID4gMikgeyBub2RlX2l3W2ldIC09IDE7IH0NCgl9 IGVsc2Ugew0KCSAgLy8gbm9kZV9pd1tqXSAvPSAyOw0KCSAgLy8gaWYobm9k ZV9pd1tpXSA+IDIpIHsgbm9kZV9pd1tpXSAtPSAxOyB9DQoJICBpZihub2Rl X2l3W2pdID4gMikgeyBub2RlX2l3W2pdIC09IDE7IH0NCgl9DQogICAgICB9 IGVsc2Ugew0KCW5vZGVfbm9sb3NzW2ldKys7DQoJbm9kZV9ub2xvc3Nbal0r KzsNCg0KCS8vIG5vIGxvc3MsIGNhbiB0cnkgaW5jcmVtZW50aW5nIHRoZSBz bWFsbGVyIHNpZGUNCglpZiAobm9kZV9pd1tpXSA8IG5vZGVfaXdbal0pIHsN CgkgIGlmKG5vZGVfbm9sb3NzW2ldID4gbG9zc190aHJlc2gpIHsgbm9kZV9p d1tpXSArPSAxOyB9DQoJfSBlbHNlIHsNCgkgIGlmKG5vZGVfbm9sb3NzW2pd ID4gbG9zc190aHJlc2gpIHsgbm9kZV9pd1tqXSArPSAxOyB9DQoJfQ0KICAg ICAgfQ0KICAgIH0gDQogIH0NCg0KICBwcmludGYoIiAgIHJlc3VsdCBoZWFk cm9vbTogJWQsIGxvc3M6ICVkLCBuZXcgaXcgJWQgPSAlZCwgbmV3IGl3ICVk ID0gJWRcbiIsIA0KCWhlYWRyb29tLCBsb3NzLCANCglpLCBub2RlX2l3W2ld LA0KCWosIG5vZGVfaXdbal0pOw0KDQogICpybG9zcyA9IGxvc3M7DQogICpy aGVhZHJvb20gPSBoZWFkcm9vbTsNCn0NCg0KDQppbnQgbWFpbihpbnQgYXJn YywgY2hhciAqKmFyZ3YpIHsNCiAgaW50IGkgPSAwOw0KICBpbnQgbG9zcywg aGVhZHJvb207DQogIGludCBpd3M7DQogIGludCBjbG9zcywgY2hlYWRyb29t Ow0KICBpbnQgY2l3Ow0KICBpbnQgY291bnQgPSAxMDA7DQogIGlmKGFyZ2Mg PCA5KSB7DQogICAgcHJpbnRmKCJ1c2FnZTogJWQgPGluaXRpYWwgd2luZG93 PiA8YWRqdXN0OiAxLzA+IDxJVyBpbmNyZW1lbnQgc3VjY2VzcyB0aHJlc2hv bGQ+IDxsb3dlciBhY2Nlc3MgY2FwPiA8aGlnaGVyIGFjY2VzcyBjYXA+IDxs b3dlciBiYiBjYXA+IDxoaWdoZXIgYmIgY2FwPiA8b25lLXNpZGUtb25seS1k ZWNpc2lvbj5cbiIpOw0KICAgIGV4aXQoMCk7DQogIH0NCiAgZmlsbF9pbml0 aWFsKGF0b2koYXJndlsxXSksIGF0b2koYXJndls0XSksIGF0b2koYXJndls1 XSksIGF0b2koYXJndls2XSksIGF0b2koYXJndls3XSkpOw0KICB3aGlsZSgx KSB7DQogICAgaXdzID0gbG9zcyA9IGhlYWRyb29tID0gMDsNCiAgICBmb3Io aT0wO2k8Y291bnQ7aSsrKSB7DQogICAgICBpdGVyYXRlKGF0b2koYXJndls4 XSksIGF0b2koYXJndlsyXSksIGF0b2koYXJndlszXSksICZjbG9zcywgJmNo ZWFkcm9vbSwgJmNpdyk7DQogICAgICBsb3NzICs9IGNsb3NzOw0KICAgICAg aGVhZHJvb20gKz0gY2hlYWRyb29tOw0KICAgICAgaXdzICs9IGNpdzsNCiAg ICB9DQogICAgcHJpbnRmKCJSZXN1bHRzIGZyb20gdGhlIHJvdW5kOiBsb3Nz OiAlZCwgaGVhZHJvb206ICVkLCBhdmcgSVcgc2l6ZTogJWZcbiIsIGxvc3Ms IGhlYWRyb29tLCAoKGZsb2F0KWl3cykvKChmbG9hdCljb3VudCkpOw0KICAg IA0KICB9DQoNCn0NCg== ---559023410-3036460-1290133613=:27897-- From mallman@icir.org Thu Nov 18 19:53:29 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3A03A6887 for ; Thu, 18 Nov 2010 19:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kir9uVGd6a8R for ; Thu, 18 Nov 2010 19:53:28 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id DC1873A672F for ; Thu, 18 Nov 2010 19:53:28 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAJ3sEmS027836; Thu, 18 Nov 2010 19:54:15 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AD85B25599E6; Thu, 18 Nov 2010 22:54:14 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CE5D135.4060109@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Who You Are MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma62694-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 18 Nov 2010 22:54:14 -0500 Sender: mallman@icir.org Message-Id: <20101119035414.AD85B25599E6@lawyers.icir.org> Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 03:53:29 -0000 ----------ma62694-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Two quick things ... > If you care that much about latency, keep connections open and reuse > them. This takes a cooperative effort between two hosts and so is not always possible from the perspective of one host. > Finally, I claim that this cannot possibly matter to the web. If it > did, people wouldn't design web pages using bloated images and flash; > they'd use simple HTML that would load and render faster. More likely its that people value the design of their web pages over the performance benefits of stripping to bare bones. That is a preference on their part. But, it doesn't mean they wouldn't also like to see performance gains, as well. OK, three things... IW10 can save more than 1RTT. allman ----------ma62694-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzl9OYACgkQWyrrWs4yIs7CqgCgiqy9sWmDtw+PGmFT3X4EK6fu nWIAoIGAIgg7tPVS5kBbhfaGJaUIIp04 =mXsP -----END PGP SIGNATURE----- ----------ma62694-1-- From mallman@icir.org Thu Nov 18 20:11:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067EC3A635F for ; Thu, 18 Nov 2010 20:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc6I-smn7TgI for ; Thu, 18 Nov 2010 20:11:27 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 825033A67B5 for ; Thu, 18 Nov 2010 20:11:25 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAJ4CDxk000783; Thu, 18 Nov 2010 20:12:14 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id CC8D0255A013; Thu, 18 Nov 2010 23:12:13 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CE595E3.3010109@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Who You Are MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma63773-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 18 Nov 2010 23:12:13 -0500 Sender: mallman@icir.org Message-Id: <20101119041213.CC8D0255A013@lawyers.icir.org> Cc: David Borman , tcpm , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 04:11:39 -0000 ----------ma63773-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > That's basically what I'm suggesting; it can easily be per subnet, per > interface, or per the entire machine as desired. > > The ultimate point is: > > - put something in the end node that notices if/when > it fails objectively, and fixes it > > - that same thing can allow the IW to increase > over time if there are no problems > > I'll be glad to write this up if people need a more concrete > proposal. The problem here is that we still need a default initial window. Something to use in the absence of this cross connection history. And, we don't really know how to develop this history in any sort of concrete way. You can write a "concrete proposal", but without some empirical understanding it'll be more hand wave than concrete. E.g., what timescales does the state work at? What granularity of "recipient"? What thresholds for increasing the IW? Decreasing it? Etc. All this bears on the prevalence of the opportunity to leverage previous history in subsequent connections. It is not hard for me to envision that all this is going to boil down to being isomorphic with whatever we choose for the default initial cwnd because we just don't have all that many opportunities to share the state and/or build up to a appreciably bigger IW value. I'd love to see something like this worked out and rigorously investigated. But, without some effort it is not a viable alternative (today). allman ----------ma63773-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzl+R0ACgkQWyrrWs4yIs5tDwCeJZpvBlbIkoq4cKiGBU0GwV/w MLIAoJUA1RZRiK2srQRShoxg8BaS7NM9 =xo2X -----END PGP SIGNATURE----- ----------ma63773-1-- From mallman@icir.org Thu Nov 18 20:23:46 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03BAA3A672F for ; Thu, 18 Nov 2010 20:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3bgmSOVdVR1 for ; Thu, 18 Nov 2010 20:23:45 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 41BD93A635F for ; Thu, 18 Nov 2010 20:23:45 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAJ4OXSM002600; Thu, 18 Nov 2010 20:24:34 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id BB2EE255A476; Thu, 18 Nov 2010 23:24:33 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CE58FED.608@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Who You Are MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma64513-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 18 Nov 2010 23:24:33 -0500 Sender: mallman@icir.org Message-Id: <20101119042433.BB2EE255A476@lawyers.icir.org> Cc: tcpm , David Borman Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 04:23:46 -0000 ----------ma64513-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > To be more clear, here's the case: > > start 1000 connections in a row. > > during the first connection, lose some packets and do > normal TCP backoff > > so what do the other 999 connections start with? > ans: 10 packets > > The point is that subsequent connections don't do anything > different. That is absolutely correct---the subsequent connections do not do anything differently with a static IW. But, that may well be perfectly fine. E.g., the other 999 connections may be going to 999 different destinations and the shared portion of the path may not be the problem and those 999 connections may work perfectly. E.g., the loss in the first connection may have been transient and even if the connections are going to the same recipient the same process may not repeat 999 more times. And, of course, you're right that the first connection might be telling of things to come. Your presumption is that there is much opportunity to share state across connections and that is useful in preventing issues. But, thus far this has all been done with cooked up scenarios. What is the real opportunity here? I'd love an adaptive scheme that got us out of the business of doing our best to make informed guesses about what the IW should be every so often. But, before I buy it I'd have to see some evidence that such a scheme existed that could really in fact get us out of that business. allman ----------ma64513-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzl/AEACgkQWyrrWs4yIs6CcgCfcjJQ3CntYP6iEyEclNPQOOj4 UUAAnigtc5d06KaeKrRVTd6jtMyUkEzu =MxqQ -----END PGP SIGNATURE----- ----------ma64513-1-- From ycheng@google.com Thu Nov 18 23:11:24 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149343A68B9 for ; Thu, 18 Nov 2010 23:11:24 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej6gMgaEVbgB for ; Thu, 18 Nov 2010 23:11:19 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C17683A67AD for ; Thu, 18 Nov 2010 23:11:18 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id oAJ7C70a001744 for ; Thu, 18 Nov 2010 23:12:07 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290150727; bh=LsQt+sPmPBW2UU0LCDd204pAYc4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=e4PeOIgYP7Lv74EmE2xlq4awbl68h8BGlK9+7fsxfgotC2Uor3PZVVEbg6R13yQgr A9NAWc9y9oeW/NzUEauAg== Received: from qwk3 (qwk3.prod.google.com [10.241.195.131]) by wpaz24.hot.corp.google.com with ESMTP id oAJ7BuJG024031 for ; Thu, 18 Nov 2010 23:12:06 -0800 Received: by qwk3 with SMTP id 3so4435491qwk.2 for ; Thu, 18 Nov 2010 23:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=Y4MIv3Hnfs8dSmDriJwJDnCVpSgcLIu08Hb3ug3SZ3Q=; b=NmhuTpcb1EFzoG6bFI/y9PjHuP4dfNAzD0JXNbQ1tUH+sSiStxG6ZIr/diyqRczHUt d3RKdz3GEtIqMXo/ADCg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=adg5WdThF4PMitjUZ2m3qP2TcflPelqFfJF1781OhQZlCxVy3wlKMBrHwpel4idDIC fLWcgwfoUYN2tbUOfRUw== Received: by 10.224.174.12 with SMTP id r12mr594240qaz.109.1290150725985; Thu, 18 Nov 2010 23:12:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Thu, 18 Nov 2010 23:11:45 -0800 (PST) In-Reply-To: <4CE5D135.4060109@isi.edu> References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <4CE5D135.4060109@isi.edu> From: Yuchung Cheng Date: Thu, 18 Nov 2010 23:11:45 -0800 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 07:11:24 -0000 On Thu, Nov 18, 2010 at 5:21 PM, Joe Touch wrote: > > > On 11/18/2010 4:55 PM, Nandita Dukkipati wrote: > ... >> >> Fortunately, we don't have to speculate on the impact of delay on user >> behaviors. There are more recent (2009, 2010) studies that show that >> even small latency increases, such as 100ms, have measurable impacts >> (obviously negative) on user experience and perception. >> >> These studies describe experiments and go on to quantify the impact of >> delays ranging from 50-2000ms on user behavior, number of clicks, and >> such other metrics. >> * http://velocityconf.com/velocity2009/public/schedule/detail/8523 >> * http://googleresearch.blogspot.com/2009/06/speed-matters.html >> >> Other work along similar lines: >> http://velocityconf.com/velocity2010/public/schedule/detail/13031 >> http://velocityconf.com/velocity2009/public/schedule/detail/7709 >> http://www.gomez.com/pdfs/wp_why_web_performance_matters.pdf > > If you care that much about latency, keep connections open and reuse them. > Reusing connections saves 1 RTT - the same amount you will save with IW=10. > Further, your IW won't matter, so you'll save that too. Connection reuse is a great idea but there is many practical limits unfortunately. server scale: Servers try to keep connections forever (at least Google) but idle connections take up memory. Not to mention certain load-balancer setup requires per-connection state client scale: Browsers close connections after couple minutes, b/c themselves are opening too many. NAT boxes: Even servers and browsers both keep connections, NAT boxes drop them. It's worse on large carrier-grade NAT. Even servers do keep connections, they disable slow-start-after-idle, so after the nice idle period, we can burst response with cwnd likely larger than 10. It's a commonly known trick to operators in datacenters/server farms. > > Second, you're saving 1 RTT. In most cases on reasonable nets, that's well > under 100ms. The cases where that's not true are where you probably don't > want to swamp the buffers (cell nets, bloated home DSL router buffers, > bloated OS buffers). We save 1RTT for TCP handshake. We save more than 1RTT using IW10 > Third, the reduction in latency is 1 RTT out of 3 *best case*. For very > short transfers. For anything longer, it's deep in the noise. > > Finally, I claim that this cannot possibly matter to the web. If it did, > people wouldn't design web pages using bloated images and flash; they'd use > simple HTML that would load and render faster. So why do CDN spend billions to deploy proxies/servers near the users to cut the RTTs? From ycheng@google.com Thu Nov 18 23:53:43 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E4B28C0E7 for ; Thu, 18 Nov 2010 23:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.877 X-Spam-Level: X-Spam-Status: No, score=-109.877 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfRU2vGI5eG4 for ; Thu, 18 Nov 2010 23:53:42 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1CE0A28C0E4 for ; Thu, 18 Nov 2010 23:53:41 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id oAJ7sTAW032496 for ; Thu, 18 Nov 2010 23:54:30 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290153270; bh=ff9B+XD1lMa4WHbWGgtgk0Xn5wc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=TQ7pTvzGGvTVWPxqHHrx6Hyeay+0cABWJLKKFxqLolE32cuC2WKLRLSMthayoFv9l WkxynQABDe3V9VyS8vndA== Received: from qyk38 (qyk38.prod.google.com [10.241.83.166]) by wpaz9.hot.corp.google.com with ESMTP id oAJ7rluL024846 for ; Thu, 18 Nov 2010 23:54:28 -0800 Received: by qyk38 with SMTP id 38so8319225qyk.9 for ; Thu, 18 Nov 2010 23:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=6GF40xtV7X0pi5VwmXBJo+GzuRIDUr0/t20/ElDga/Q=; b=GjA3GPbD+emBUo0BmMsbP9SEgXfZE6SWQ8sa9wXrImIjmFjTqCX5IfCarHQ3j84PbF +/Ego4z4yH0tOvPTSeSg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=x0jq3y1xPtp+zy3i3wRZ3flMP2C9lBFjY1xhjdTstRMAUQtpRO1O4soaGVkliB+780 Zikprucuj0ua4pf1RArw== Received: by 10.229.87.13 with SMTP id u13mr1503856qcl.202.1290153268282; Thu, 18 Nov 2010 23:54:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Thu, 18 Nov 2010 23:54:07 -0800 (PST) In-Reply-To: <20101119042433.BB2EE255A476@lawyers.icir.org> References: <4CE58FED.608@isi.edu> <20101119042433.BB2EE255A476@lawyers.icir.org> From: Yuchung Cheng Date: Thu, 18 Nov 2010 23:54:07 -0800 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 07:53:43 -0000 We, authors on IW10, take changing TCP seriously so we proceed with scientific methods. We did these in live servers and lab tests to achieve the best possible reality. We took feedbacks from IETF members to refine our methods after two meetings. In the mean time, Ilpo from U of Helsinki, and Michael Scharf from Lucent-Alcatel have each done _independent_ experiments for IW10. None of us find any alarming fairness issues between IW10/IW3. For people who are concerned about possible problems of IW10 in various network scenarios, can they kindly volunteer to help verify these issues by similar testbed/live experiments? If IW10 turns out to be a bad idea, we (tcpm/tmrg members) can all learn from these studies/insights and figure a better solution. From ayourtch@cisco.com Fri Nov 19 02:42:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF703A686A for ; Fri, 19 Nov 2010 02:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzZ9zelEAJgH for ; Fri, 19 Nov 2010 02:42:37 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 545A03A6881 for ; Fri, 19 Nov 2010 02:42:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAJAdfho008943; Fri, 19 Nov 2010 11:39:41 +0100 (CET) Received: from sweet-brew-4.cisco.com (sweet-brew-4.cisco.com [144.254.10.205]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAJAdeSN007320; Fri, 19 Nov 2010 11:39:40 +0100 (CET) Date: Fri, 19 Nov 2010 11:39:40 +0100 (CET) From: Andrew Yourtchenko To: Joe Touch In-Reply-To: <4CE5ED4D.20103@isi.edu> Message-ID: References: <20101110152857.GA5094@hell> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se><36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com><4CE585E9.6060203@isi.edu><6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <4CE5D324.1050609@isi.edu> <4CE5ED4D.20103@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: David Borman , tcpm , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 10:42:38 -0000 On Thu, 18 Nov 2010, Joe Touch wrote: > > > On 11/18/2010 6:26 PM, Andrew Yourtchenko wrote: >> Hi Joe, > ... >>>> However, I think there is a catch due to which it would need tweaking - >>>> there should be a signaling mechanism whereby a node on the >>>> "conservative" side of the connection would be able to signal the node >>>> on the "eager" side of the connection not to be too aggressive, in case >>>> the data flow is mostly from from "eager" to "conservative" side. >>> >>> I think the rest of your argument boils down to how the client decides >>> to aggregate it's idea of the best IW. That's up to the client to >>> decide what it is willing to support - coarse or fine-grained. >> >> No. IW of the client does not really matter - it sends the short GET >> request. The server side is the one that may generate congestion by >> having large IW. > > It doesn't matter what side you call client or server; they each get an IW. > hm seems like either I still did not describe well enough or I did not understand you. Anyway, not a big deal. >> So it needs either to remember all the clients somehow, or take a hint. > > Right now you assume all remote ends are the same -- IW=3. The proposal is to > assume they're the same and IW=10. Even if you presume they're the same, you > can treat them as a group, and if 'most of the time in the past' IW=10 caused > losses, you can backoff and use IW=5 for future connections for a while. > > Yes, it's possible to 'learn' this for subsets of remote ends, but that's an > optimization that can be implemented in whatever granularity desired. There can be other options, yes. However, at least on the surface this one seems to be simple for the impact it has. I guess I'll need to write it up in an I-D + do more tests. > >> "Average temperature in the hospital" approach (aggregating on the >> server) will not be useful. > > Well, that's exactly what we're doing now when we pick a fixed IW anyway. So > if that's bad, then let's not do it now either ;-) On this you and me are in agreement. This moment is an opportunity to try and find something more adaptive. > >>> An IW=10 as a static proposal is the coarsest possible; anything else >>> we could do can't be any worse. >>> >>> ... >>>> If the above logic is right, then the peers during the 3whs should >>>> communicate their memorized values and pick up the minimum of theirs and >>>> the communicated by the peer. >>> >>> Congestion isn't often bidirectional, so it's unlikely IMO that a peer >>> would know what to suggest to its counterpart (if I understand your >>> proposal). >> >> If I connect to http://foo.example/ which sends me an IW=10 and I lose 5 >> packets out of that, and I connect to http://bar.example/ which sends me >> an IW=10 and I lose 5 packets out of that, my assumption that if I >> connect to http://baz.example, most chances are that I will also be able >> to get up to 5 packets - so I better give it a hint based on my previous >> knowledge. > > If they tell you their IW, you still need to know they actually sent 5. You > don't know they're lost - they may have never been sent. So IW knowledge > isn't enough to do anything per se. There will be situations where you can tell, there will be situations where you can't. If you can't tell whether there was no packet loss - do no changes to IW, or do them at a fraction of the pace. cheers, andrew > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From ilpo.jarvinen@helsinki.fi Fri Nov 19 03:48:00 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77983A68A7 for ; Fri, 19 Nov 2010 03:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spO9MDJHwIc4 for ; Fri, 19 Nov 2010 03:47:59 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 945C43A6822 for ; Fri, 19 Nov 2010 03:47:58 -0800 (PST) Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 19 Nov 2010 13:48:46 +0200 id 00093ECF.4CE6641E.00004E7F Date: Fri, 19 Nov 2010 13:48:46 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi To: Yuchung Cheng In-Reply-To: Message-ID: References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <4CE5D135.4060109@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, "Anantha Ramaiah \\\\\(ananth\\\\\)" , mallman@icir.org, Joe Touch Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 11:48:00 -0000 On Thu, 18 Nov 2010, Yuchung Cheng wrote: > On Thu, Nov 18, 2010 at 5:21 PM, Joe Touch wrote: > > > > > > On 11/18/2010 4:55 PM, Nandita Dukkipati wrote: > > ... > >> > >> Fortunately, we don't have to speculate on the impact of delay on user > >> behaviors. There are more recent (2009, 2010) studies that show that > >> even small latency increases, such as 100ms, have measurable impacts > >> (obviously negative) on user experience and perception. > >> > >> These studies describe experiments and go on to quantify the impact of > >> delays ranging from 50-2000ms on user behavior, number of clicks, and > >> such other metrics. > >> * http://velocityconf.com/velocity2009/public/schedule/detail/8523 > >> * http://googleresearch.blogspot.com/2009/06/speed-matters.html > >> > >> Other work along similar lines: > >> http://velocityconf.com/velocity2010/public/schedule/detail/13031 > >> http://velocityconf.com/velocity2009/public/schedule/detail/7709 > >> http://www.gomez.com/pdfs/wp_why_web_performance_matters.pdf > > > > If you care that much about latency, keep connections open and reuse them. > > Reusing connections saves 1 RTT - the same amount you will save with IW=10. > > Further, your IW won't matter, so you'll save that too. > > Connection reuse is a great idea but there is many practical limits > unfortunately. > > server scale: > Servers try to keep connections forever (at least Google) but idle > connections take up memory. Not to mention certain load-balancer setup > requires per-connection state > > client scale: > Browsers close connections after couple minutes, b/c themselves are > opening too many. > > NAT boxes: > Even servers and browsers both keep connections, NAT boxes drop them. ...This is again just one way to case "congestion collapse" if the bottleneck is prior to such a NAT box! Though in the most convincing case it happens for the direction of small requests and not the replies. -- i. From hkchu@google.com Fri Nov 19 09:12:28 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6813A67E9 for ; Fri, 19 Nov 2010 09:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.19 X-Spam-Level: X-Spam-Status: No, score=-109.19 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, FB_YOU_CAN_BECOME=1.258, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyB-F-xLwmev for ; Fri, 19 Nov 2010 09:12:27 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 971183A67E1 for ; Fri, 19 Nov 2010 09:12:26 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id oAJHDEUN008097 for ; Fri, 19 Nov 2010 09:13:15 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290186795; bh=eb5aV4aQn4c6zEIeu7/L89zyfoA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=GkyuiDOeHnYtEwPOAPjs929dA1gg5k3brV0Z3muEuZ4jVwdoKTLuNnFhgIsAIx7GC fQlfDqidD3IwOnjMczfGg== Received: from gxk8 (gxk8.prod.google.com [10.202.11.8]) by wpaz9.hot.corp.google.com with ESMTP id oAJHCRlP000599 for ; Fri, 19 Nov 2010 09:13:13 -0800 Received: by gxk8 with SMTP id 8so2913022gxk.39 for ; Fri, 19 Nov 2010 09:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aQS0r1YJQXohBiA7DCuGoH9eo3B+3Co/ZabgS7llT5k=; b=j8Gg+FuWaiMcKfVb7Tk9S6XjsTHM5WcWuoV8G4g3egy5Vwf4Ui/rmhxhI1jfKIGZ0X V6cLe7k1R/AcIkGXJPGQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=W8rIqqNpkUzX+I+KR6XEr+IOKrJMv3sxtlv8UpEKwe0LBAimgovR+euiVeSfN5TV61 +S3GSUHgyuNv0SiM3SOg== MIME-Version: 1.0 Received: by 10.150.91.13 with SMTP id o13mr4022149ybb.6.1290186792664; Fri, 19 Nov 2010 09:13:12 -0800 (PST) Received: by 10.151.158.13 with HTTP; Fri, 19 Nov 2010 09:13:12 -0800 (PST) In-Reply-To: <4CE597AB.1020306@isi.edu> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <4CE597AB.1020306@isi.edu> Date: Fri, 19 Nov 2010 09:13:12 -0800 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: "Anantha Ramaiah \(ananth\)" , tcpm , David Borman Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 17:12:28 -0000 On Thu, Nov 18, 2010 at 1:16 PM, Joe Touch wrote: > Maybe it should have been for IW=3D3 too, but it didn't occur to me at th= e > time. > > The benefit is that had we used this mechanism then, we wouldn't be askin= g > for a new IW now, though. The problem is that had we used this mechanism we would've quickly found ou= t it just doesn't work well. It's always easy to hand wave and point to somet= hing never well tested and claim that would've worked better. Linux has a "dst cache" feature on a per destination IP basis for years. The problem is that the effectiveness of the dst cache is determined by the cache hit rate, which is highly dependent on client-server access pattern. An ftp server serving RFC documents to a handful of clients (e.g., TCP researchers) may enjoy high cache hit ratio. But consider > 1B users accessing millions of servers, what kind of cache hit ratio would you expec= t? Frustrated by very low cache hits from Linux's dst cache, we went on to modify dst cache from per dst IP to per dst /24 subnet basis, but it only showed limited improvement. Then we discovered out of the small % of cache hits many still suffered low cached cwnd. We quickly realized simple cwnd cache is not sufficient - the prior connection must also have sufficient data to grow its cwnd for the later connection to enjoy a larger IW. Adding on top of all the above were transient congestions on well provisioned users causing cwnd to be clamped down, and later connections to suffer a small IW even though the congestions were long gone (presumably= ). BTW, we've covered this topic in our 1st presentation (see http://www.ietf.org/proceedings/77/slides/tcpm-4.pdf) and list discussions many times. I really hope we don't have to repeat the same topic over and over again. Best, Jerry > > Joe > > On 11/18/2010 1:11 PM, John Heffner wrote: >> >> Why is this mechanism required for IW=3D10 but not for IW=3D3? >> >> =A0 -John >> >> >> On Thu, Nov 18, 2010 at 4:08 PM, Joe Touch =A0wrote: >>> >>> That's basically what I'm suggesting; it can easily be per subnet, per >>> interface, or per the entire machine as desired. >>> >>> The ultimate point is: >>> >>> =A0 =A0 =A0 =A0- put something in the end node that notices if/when >>> =A0 =A0 =A0 =A0it fails objectively, and fixes it >>> >>> =A0 =A0 =A0 =A0- that same thing can allow the IW to increase >>> =A0 =A0 =A0 =A0over time if there are no problems >>> >>> I'll be glad to write this up if people need a more concrete proposal. >>> >>> Joe >>> >>> On 11/18/2010 1:05 PM, Anantha Ramaiah (ananth) wrote: >>>> >>>> Why can't you do something like this : >>>> >>>> - If any one of the TCP connections egressing out of that interface >>>> (this can determined in TCP layer) is in the TCP retransmit state (or >>>> has experienced congestion in the past xxx secs/mins), then go back to= a >>>> lower IW for new TCP connections which are using the same output >>>> interface.. >>>> >>>> - When you want to start a connection, use the connection history (Joe= 's >>>> RFC) >>>> >>>> Well, there may be some gotchas of this scheme, but you can become >>>> conservative when there is some concrete information. >>>> >>>> Thanks, >>>> -Anantha >>>>> >>>>> To be more clear, here's the case: >>>>> >>>>> =A0 =A0 =A0 =A0start 1000 connections in a row. >>>>> >>>>> =A0 =A0 =A0 =A0during the first connection, lose some packets and do >>>>> =A0 =A0 =A0 =A0normal TCP backoff >>>>> >>>>> =A0 =A0 =A0 =A0so what do the other 999 connections start with? >>>>> =A0 =A0 =A0 =A0ans: 10 packets >>>>> >>>>> The point is that subsequent connections don't do anything different. >>>>> If >>>>> you have 1000 connections, you're sending a certain amount of data >>>> >>>> into >>>>> >>>>> the network without reacting. We're tripling that. >>>>> >>>>> That can easily cause congestion. At which point the *existing* >>>>> connections will backoff, but new connections keep making problems. >>>>> >>>>> Joe >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From touch@isi.edu Fri Nov 19 09:23:03 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6218C3A6860 for ; Fri, 19 Nov 2010 09:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMUGhJgIwi81 for ; Fri, 19 Nov 2010 09:23:02 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 9D2583A67E1 for ; Fri, 19 Nov 2010 09:23:02 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oAJHN2SO028539 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 19 Nov 2010 09:23:11 -0800 (PST) Message-ID: <4CE6B276.6040602@isi.edu> Date: Fri, 19 Nov 2010 09:23:02 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jerry Chu References: <20101110152857.GA5094@hell> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <4CE597AB.1020306@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: "Anantha Ramaiah \(ananth\)" , tcpm , David Borman Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 17:23:03 -0000 Hi, Jerry (et al.), The logic here is astounding. We can't use a reactive system because it would make the wrong decision, and potentially treat all endpoints the wrong way. So let's make a static decision that is, essentially, the same as the automatic one with particular parameters (A=0, M=1, timescale=infinite, aggregation=all). Alternately, for Mark's proposal, that would be (A=+k, M=1, timescale=every few years, aggregation=all). I conclude that: - if there is no objective metric for the safety of this change, it MUST NOT be deployed - if there is an objective metric for its safety, it's surely more safe to incorporate that as a test Even if all the 'auto' system does is backoff to IW=3 if IW=10 causes persistent problems, that's MUCH SAFER than anything else. If, as Mark concludes, an auto system isn't ready for prime time because we don't know the impact, then surely we don't have enough info for a static configuration of that auto system either. Joe From hkchu@google.com Fri Nov 19 09:24:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E7B3A688A for ; Fri, 19 Nov 2010 09:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.788 X-Spam-Level: X-Spam-Status: No, score=-105.788 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU-no4A9c56r for ; Fri, 19 Nov 2010 09:24:01 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D2A253A6882 for ; Fri, 19 Nov 2010 09:24:00 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id oAJHOo4x023706 for ; Fri, 19 Nov 2010 09:24:50 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290187490; bh=Ry98aAV47DzxThxu5HXvEdXMuTI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Y8UeBkBBTwrgYXv6ssKaNMwSf3nBCOaE+bkPTskCXDfOq/x7STYdiHag32czqDcFh tAEoBmyVQX/cVdV+QMb9w== Received: from gwaa11 (gwaa11.prod.google.com [10.200.27.11]) by wpaz9.hot.corp.google.com with ESMTP id oAJHNx5Q019015 for ; Fri, 19 Nov 2010 09:24:49 -0800 Received: by gwaa11 with SMTP id a11so2934584gwa.34 for ; Fri, 19 Nov 2010 09:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ij+yadRKwf/EVUJO83wmG4Zfp8GkIGnPRKiUJrO4fFg=; b=cbVrex7XIEHT78ushOqry1iGtK139Ua5fvGLfsIvVWexaFfDYjTiyyyx6GZ2rplLLi 24hl45IZQcVAXbiI+xSQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rXx2h82ojIxkubQEV+nxQ0UMKOsMYEUAr7eyCCA3Yg9hXMFGH4iEsKBuWurIGmCqpc cPBojYya/E2PheGV2udw== MIME-Version: 1.0 Received: by 10.150.147.3 with SMTP id u3mr3831614ybd.234.1290187488146; Fri, 19 Nov 2010 09:24:48 -0800 (PST) Received: by 10.151.158.13 with HTTP; Fri, 19 Nov 2010 09:24:48 -0800 (PST) In-Reply-To: <752D4660-5063-4050-B7C5-A30164ADAB09@windriver.com> References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <752D4660-5063-4050-B7C5-A30164ADAB09@windriver.com> Date: Fri, 19 Nov 2010 09:24:48 -0800 Message-ID: From: Jerry Chu To: David Borman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm , Joe Touch Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 17:24:02 -0000 On Thu, Nov 18, 2010 at 1:10 PM, David Borman wrote: > > On Nov 18, 2010, at 2:43 PM, Joe Touch wrote: > >> >> >> On 11/18/2010 12:32 PM, David Borman wrote: >> ... >>>> Consider that there are three cases: >>>> >>>> A) connections so small the IW doesn't matter (they already fit in IW= =3D3) >>>> >>>> B) connections 4-20 or so segments range >>>> >>>> C) connections much longer than 20 or so segments >>>> >>>> (A) isn't affected by this proposed change at all, so we don't need to= consider it. >>>> >>>> (C) adjusts to the IW using AIMD, so even if we guess wrong, TCP will = "react to congestion" here. >>>> >>>> And then there's (B). (B) doesn't react to congestion. Every new conne= ction uses IW=3D10. Even after repeated attempts - to a given address, or, = e.g., to every address - end up dropping, e.g., half of those segments. (B)= will sit there and beat its head against the wall. >>> >>>> >>>> That's the congestion-increasing case. Will this cause collapse? I don= 't know. But it's definitely NOT reacting to congestion. >>> >>> No, (B) will also react to congestion, if the congestion causes >>> packet loss. For any given flow, if all the packets get through the >>> first time, from it's viewpoint there is no congestion. If they don't >>> all get through, that connection does normal TCP backoff and >>> retransmits. >> >> To be more clear, here's the case: >> >> =A0 =A0 =A0 start 1000 connections in a row. >> >> =A0 =A0 =A0 during the first connection, lose some packets and do >> =A0 =A0 =A0 normal TCP backoff >> >> =A0 =A0 =A0 so what do the other 999 connections start with? >> =A0 =A0 =A0 ans: 10 packets >> >> The point is that subsequent connections don't do anything different. If= you have 1000 connections, you're sending a certain amount of data into th= e network without reacting. We're tripling that. >> >> That can easily cause congestion. At which point the *existing* connecti= ons will backoff, but new connections keep making problems. > > If you are doing the 1000 connections serially, then any connection that = experiences packet loss will slow down that connection, and delay the creat= ion of all the successive connections, and hence delay the next IW burst. = =A0Seems to me that that is reacting to congestion across connections. > > If you are doing 1000 connections in parallel, well, you are now spitting= out 3,000 packets with IW=3D3 and 10,000 packets with IW=3D10, both of whi= ch are probably going to cause congestion. > > Remember, from the end-point of a TCP connection, it is not aware of cong= estion unless there is packet loss or an ECN indication. =A0There may be co= ngestion on the path, but if the packets gets through, TCP is unaware of th= e congestion, other than the RTO going up due to delayed packets, and will = continue to open up its idea of the congestion window. > > > But here's a thought: =A0Any TCP connection with a large IW that has to r= etransmit or gets an ECN notification during the initial 3-way handshake mu= st clamp down its IW to a small value. =A0That won't catch every case, but = it'll catch some. Agreed. In fact, RFC3390 already contains a similar clause: "If the SYN or SYN/ACK is lost, the initial window used by a sender after a correctly transmitted SYN MUST be one segment consisting of MSS bytes." We welcome any contingency that may ease concerns as long as the condition can be detected during 3WHS. (We have a self-imposed KISS design principle. See slides 9 of http://www.ietf.org/proceedings/77/slides/tcpm-4.pdf) Jerry > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-David > >> >> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From hkchu@google.com Fri Nov 19 09:58:07 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691BC3A6860 for ; Fri, 19 Nov 2010 09:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.879 X-Spam-Level: X-Spam-Status: No, score=-109.879 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFLu-HWRmWa3 for ; Fri, 19 Nov 2010 09:58:06 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 57CA23A6850 for ; Fri, 19 Nov 2010 09:58:05 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id oAJHwsbF009179 for ; Fri, 19 Nov 2010 09:58:55 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290189535; bh=W834oHJp2AKBUd+trd2sJwS/o1c=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=JHTohPfzwVQDVoPWRQsI4n6WzOUUspcczvehCxZIPnSaQRi+QBvsLJfcUzOJcLra5 TiI+Bs6jBlLMDz/o7BXAg== Received: from gyh3 (gyh3.prod.google.com [10.243.50.195]) by wpaz5.hot.corp.google.com with ESMTP id oAJHwrCn011556 for ; Fri, 19 Nov 2010 09:58:53 -0800 Received: by gyh3 with SMTP id 3so3473095gyh.0 for ; Fri, 19 Nov 2010 09:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zf87C40DcnWQ94V9g2A2ccl5hGZFRTepWYMESKj3K6o=; b=F9cwTNn0btt2kV4ifFlc/mtu9h8z36kkYflRGsdq6jEHSiHYZsjdTUaTuAEJxesVH8 clFm2lWaLLgRj7exQKTw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uY3pJcSzESzYK2/dFVkCT2yMVN6IF/TzLMYCDLp0qyEwLRl/3w8jAyU9EPwaLsO6dG C32Ctbyx1b8irpUNjP5g== MIME-Version: 1.0 Received: by 10.150.228.16 with SMTP id a16mr3963411ybh.177.1290189532886; Fri, 19 Nov 2010 09:58:52 -0800 (PST) Received: by 10.151.158.13 with HTTP; Fri, 19 Nov 2010 09:58:52 -0800 (PST) In-Reply-To: <4CE6B276.6040602@isi.edu> References: <20101110152857.GA5094@hell> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <4CE597AB.1020306@isi.edu> <4CE6B276.6040602@isi.edu> Date: Fri, 19 Nov 2010 09:58:52 -0800 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: "Anantha Ramaiah \(ananth\)" , tcpm , David Borman Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 17:58:07 -0000 Hi Joe, On Fri, Nov 19, 2010 at 9:23 AM, Joe Touch wrote: > Hi, Jerry (et al.), > > The logic here is astounding. > > We can't use a reactive system because it would make the wrong decision, = and > potentially treat all endpoints the wrong way. We can't use a reactive system like the one you suggested because it just doesn't work (except in a few limited cases). We are debating on an enginee= ring issue here and this is IETF so we'll need running code and real deployment experience. If you can demonstrate your idea in a large server farm environ= ment without requiring a large amount memory and complexity and actually showing reasonable performance latency I'll jump on it tomorrow! I think being conservative to the extreme is like saying "TCP is not to be touched". This will likely force application developers frustrated with TCP performance into ways that circumvent TCP and cause a lot of more damage dwarfing the one you've been worried about. Jerry > > So let's make a static decision that is, essentially, the same as the > automatic one with particular parameters (A=3D0, M=3D1, timescale=3Dinfin= ite, > aggregation=3Dall). Alternately, for Mark's proposal, that would be (A=3D= +k, > M=3D1, timescale=3Devery few years, aggregation=3Dall). > > I conclude that: > > =A0 =A0 =A0 =A0- if there is no objective metric for the safety of this > =A0 =A0 =A0 =A0change, it MUST NOT be deployed > > =A0 =A0 =A0 =A0- if there is an objective metric for its safety, it's sur= ely > =A0 =A0 =A0 =A0more safe to incorporate that as a test > > Even if all the 'auto' system does is backoff to IW=3D3 if IW=3D10 causes > persistent problems, that's MUCH SAFER than anything else. > > If, as Mark concludes, an auto system isn't ready for prime time because = we > don't know the impact, then surely we don't have enough info for a static > configuration of that auto system either. > > Joe > > From touch@isi.edu Fri Nov 19 10:21:16 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFF03A6809 for ; Fri, 19 Nov 2010 10:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcV9lTCODXeY for ; Fri, 19 Nov 2010 10:21:08 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 8EF903A67FF for ; Fri, 19 Nov 2010 10:21:08 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oAJILLwL010478 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 19 Nov 2010 10:21:31 -0800 (PST) Message-ID: <4CE6C01B.7050601@isi.edu> Date: Fri, 19 Nov 2010 10:21:15 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jerry Chu References: <20101110152857.GA5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <4CE597AB.1020306@isi.edu> <4CE6B276.6040602@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: "Anantha Ramaiah \(ananth\)" , tcpm , David Borman Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 18:21:16 -0000 On 11/19/2010 9:58 AM, Jerry Chu wrote: > Hi Joe, > > On Fri, Nov 19, 2010 at 9:23 AM, Joe Touch wrote: >> Hi, Jerry (et al.), >> >> The logic here is astounding. >> >> We can't use a reactive system because it would make the wrong decision, and >> potentially treat all endpoints the wrong way. > > We can't use a reactive system like the one you suggested because it just > doesn't work (except in a few limited cases). We are debating on an engineering > issue here and this is IETF so we'll need running code and real deployment > experience. If you can demonstrate your idea in a large server farm environment > without requiring a large amount memory and complexity and actually showing > reasonable performance latency I'll jump on it tomorrow! It's simpler than you're thinking, and doesn't require code in the data path: 1) pick an IW s 2) keep stats on whether the IW works this can be within every single connection, or done out of band using tracers as separate machines 3) lower the IW if it tends to result in retransmits (possibly even increase it over longer timescales if it doesn't result in retransmits) This can happen on the timescale of days. Weeks even. I'm not talking about something that needs to happen in realtime. The point is to automate the feedback mechanism that Mark and I discussed as necessary. Joe From mallman@icir.org Fri Nov 19 10:22:23 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4543A67FF for ; Fri, 19 Nov 2010 10:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuBnJ-I7D9Sx for ; Fri, 19 Nov 2010 10:22:22 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 6E43F3A67D7 for ; Fri, 19 Nov 2010 10:22:22 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAJIN997007815; Fri, 19 Nov 2010 10:23:09 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3E334256762F; Fri, 19 Nov 2010 13:23:09 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CE6B276.6040602@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: TV Dinner MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma49292-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 19 Nov 2010 13:23:09 -0500 Sender: mallman@icir.org Message-Id: <20101119182309.3E334256762F@lawyers.icir.org> Cc: David Borman , tcpm , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 18:22:23 -0000 ----------ma49292-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Joe- You are suggesting a mechanism that does two things and trying to argue that it is strictly more conservative. One of these aspects seems fine and the other seems speculative to the point I can't believe you either don't see it or won't acknowledge it. Let's take these in turn: (1) Increasing the IW requires a backstop. The concern here is that we could get into a situation where there is continual use of a bad initial parameter and that will cause some bogosity. First, you're not showing this in any sort of concrete way, just presuming that it could happen and if it does then its bad enough to warrant some mitigation. We can all dream of pathologies. But, lets just put this aside for the moment and decide that given that we cannot fully understand the dynamics of IW10 before quite large scale deployment this conservativeness might be a fine design principle. So, the lets design a backstop. To flesh out what you said in your last email a little, do something like this ... - set the default IW to 10 packets - if one-third of the connections (regardless of the other endpoint) that are able to use IW > 3 lose a packet in the initial cwnd then use IW=3 for the next 5min - if we use an IW > 3 packets and we lose at least one packet from the initial cwnd to some destination X then use IW=3 for destination X for the next minute The percentage (one-third) and times (1 & 5 minutes) are pulled from thin air, maybe they should be something else. What we can say about that scheme is: (a) if we're right about IW=10 then this is a no-op on performance, (b) this is a minor bit of complexity and state, (c) if you're right that we see persistent issues then this will mitigate those issues, (d) this is strictly more conservative than a static IW=10 (not "better" necessarily, but more conservative) and (e) this arguably errors in the right direction when there is an error (i.e., it errors on the side of being less aggressive). (2) We can get out of the business of setting the IW. This is the part where your scheme really looks like a solution in search of a problem. You are positing that we can increase the IW adaptively by using experience from previous connections. But, you are offering no evidence that we can effectively build that history. Jerry offered that they have tried this and found the cache hit rate to be quite low. If this is the case---and his is one data point; at least he has that---then we're going to be dependent on the default IW and not on the history. You're conflating two issues that are not intrinsicly coupled. If you want a backstop then call for a backstop. If you want a way to remove ourselves from the IW decision truck over to the lab and start working. But, please be clear. allman ----------ma49292-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzmwIwACgkQWyrrWs4yIs7FnQCeNPH6TEdkm3AINJdYOFj1qwer 4OoAnR8kSFmt+VyfzNd8DZfLlw/jpKSO =4phA -----END PGP SIGNATURE----- ----------ma49292-1-- From touch@isi.edu Fri Nov 19 10:34:30 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0CD28C114 for ; Fri, 19 Nov 2010 10:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8H+9cpcHEoc for ; Fri, 19 Nov 2010 10:34:29 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 5396A28C101 for ; Fri, 19 Nov 2010 10:34:29 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oAJIXofX013249 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 19 Nov 2010 10:33:59 -0800 (PST) Message-ID: <4CE6C30E.7040307@isi.edu> Date: Fri, 19 Nov 2010 10:33:50 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: mallman@icir.org References: <20101119182309.3E334256762F@lawyers.icir.org> In-Reply-To: <20101119182309.3E334256762F@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: David Borman , tcpm , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 18:34:30 -0000 On 11/19/2010 10:23 AM, Mark Allman wrote: > > Joe- > > You are suggesting a mechanism that does two things and trying to argue > that it is strictly more conservative. One of these aspects seems fine > and the other seems speculative to the point I can't believe you either > don't see it or won't acknowledge it. Let's take these in turn: > > (1) Increasing the IW requires a backstop. ... > (2) We can get out of the business of setting the IW. ... > You're conflating two issues that are not intrinsicly coupled. If you > want a backstop then call for a backstop. If you want a way to remove > ourselves from the IW decision truck over to the lab and start working. > But, please be clear. The two are the same argument, as follows: - either there's an objective metric for 'no harm' or not if there is and there's harm, backoff (moderately slowly, i.e., over weeks, not minutes) if there is and there's no harm, increase over long timescales (slowly, in small amounts, over months or years - not minutes, fwiw) if there's no such metric, then we should not be changing anything. However, if I'm pressed to call the second step "experimental" (which, FWIW, is exactly what changing IW=3 to IW=10 in the wild will be - an experiment), then fine, I'll be glad if we at least have just the backoff part. Joe From hkchu@google.com Fri Nov 19 10:44:45 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3956628C128 for ; Fri, 19 Nov 2010 10:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.809 X-Spam-Level: X-Spam-Status: No, score=-105.809 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nY1MpJp4bX7Q for ; Fri, 19 Nov 2010 10:44:43 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1E7FB28C0ED for ; Fri, 19 Nov 2010 10:44:42 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id oAJIjWfT027957 for ; Fri, 19 Nov 2010 10:45:32 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290192332; bh=C9BmWiQNKXMTnlkEnPBwtKczpYE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=jK9aQwCYJCBPQ3Vx6H3NX8fVi2LQ323SBq7I1efhMEI1ZouXhIuMv+p6PQdXcBnsU iIm7KF4+8b9lY7FJEr4rw== Received: from gxk8 (gxk8.prod.google.com [10.202.11.8]) by wpaz33.hot.corp.google.com with ESMTP id oAJIi2r7024984 for ; Fri, 19 Nov 2010 10:45:31 -0800 Received: by gxk8 with SMTP id 8so3486998gxk.25 for ; Fri, 19 Nov 2010 10:45:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LhVl99vayGSzewYyljKYH5nEDBdI09WotJFHbw/eSus=; b=pZBjKDu+pZdUnTbYe12lLKDlBHvv6iZmXmTMiCTCk2w1ch6LlHjNNkU6ozhhd/f7uv Bn6KUoGyBnLHhiwtepRw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PRU/z3+XP9JAzoy36jKr8C2JohzZM5ew4OwcgVuGT8xCrKAiJWshNexxdnGN2LQkl+ +gANi0J0ICdkuP6IzhhA== MIME-Version: 1.0 Received: by 10.151.13.13 with SMTP id q13mr4035717ybi.291.1290192331032; Fri, 19 Nov 2010 10:45:31 -0800 (PST) Received: by 10.151.158.13 with HTTP; Fri, 19 Nov 2010 10:45:30 -0800 (PST) In-Reply-To: <4CE6C01B.7050601@isi.edu> References: <20101110152857.GA5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <4CE597AB.1020306@isi.edu> <4CE6B276.6040602@isi.edu> <4CE6C01B.7050601@isi.edu> Date: Fri, 19 Nov 2010 10:45:30 -0800 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: "Anantha Ramaiah \(ananth\)" , tcpm , David Borman Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 18:44:45 -0000 On Fri, Nov 19, 2010 at 10:21 AM, Joe Touch wrote: > > > On 11/19/2010 9:58 AM, Jerry Chu wrote: >> >> Hi Joe, >> >> On Fri, Nov 19, 2010 at 9:23 AM, Joe Touch =A0wrote: >>> >>> Hi, Jerry (et al.), >>> >>> The logic here is astounding. >>> >>> We can't use a reactive system because it would make the wrong decision= , >>> and >>> potentially treat all endpoints the wrong way. >> >> We can't use a reactive system like the one you suggested because it jus= t >> doesn't work (except in a few limited cases). We are debating on an >> engineering >> issue here and this is IETF so we'll need running code and real deployme= nt >> experience. If you can demonstrate your idea in a large server farm >> environment >> without requiring a large amount memory and complexity and actually >> showing >> reasonable performance latency I'll jump on it tomorrow! > > It's simpler than you're thinking, and doesn't require code in the data > path: Well, it's not as simple as you think because the devil is in the details, and we had to deal with all the details in order to perform real experiment= s before giving up. (See my slides mentioned in previous email.) > > 1) pick an IW s > > 2) keep stats on whether the IW works > =A0 =A0 =A0 =A0this can be within every single connection, or done out of > =A0 =A0 =A0 =A0band using tracers as separate machines > > 3) lower the IW if it tends to result in retransmits > (possibly even increase it over longer timescales if it doesn't result in > retransmits) > > This can happen on the timescale of days. Weeks even. I'm not talking abo= ut > something that needs to happen in realtime. We've tried both the realtime and the offline schemes (again see my slides)= . I've mentioned the problem with the realtime one in my previous email. For the offline scheme, do you realize how many subnets are their even in just = a region, how much memory it requires, and how much work it takes to try to import the data into the kernel and make it work efficiently? Again please show me your "simple" implementation and success experience. Jerry > > The point is to automate the feedback mechanism that Mark and I discussed= as > necessary. > > Joe > From touch@isi.edu Fri Nov 19 10:49:04 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2DF3A6863 for ; Fri, 19 Nov 2010 10:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmPucb3aEQcN for ; Fri, 19 Nov 2010 10:48:56 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 5B8353A690A for ; Fri, 19 Nov 2010 10:48:54 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oAJImota016290 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 19 Nov 2010 10:48:59 -0800 (PST) Message-ID: <4CE6C693.4070007@isi.edu> Date: Fri, 19 Nov 2010 10:48:51 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jerry Chu References: <20101110152857.GA5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <4CE597AB.1020306@isi.edu> <4CE6B276.6040602@isi.edu> <4CE6C01B.7050601@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: "Anantha Ramaiah \(ananth\)" , tcpm , David Borman Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 18:49:04 -0000 Hi, Jerry, The reasons you give for this all being too complex to deploy are great reasons we cannot afford to take a risk on IW=10. If you can't monitor it and tell us whether it works, you're seriously asking us to just do it anyway, blindly? Joe On 11/19/2010 10:45 AM, Jerry Chu wrote: > On Fri, Nov 19, 2010 at 10:21 AM, Joe Touch wrote: >> >> >> On 11/19/2010 9:58 AM, Jerry Chu wrote: >>> >>> Hi Joe, >>> >>> On Fri, Nov 19, 2010 at 9:23 AM, Joe Touch wrote: >>>> >>>> Hi, Jerry (et al.), >>>> >>>> The logic here is astounding. >>>> >>>> We can't use a reactive system because it would make the wrong decision, >>>> and >>>> potentially treat all endpoints the wrong way. >>> >>> We can't use a reactive system like the one you suggested because it just >>> doesn't work (except in a few limited cases). We are debating on an >>> engineering >>> issue here and this is IETF so we'll need running code and real deployment >>> experience. If you can demonstrate your idea in a large server farm >>> environment >>> without requiring a large amount memory and complexity and actually >>> showing >>> reasonable performance latency I'll jump on it tomorrow! >> >> It's simpler than you're thinking, and doesn't require code in the data >> path: > > Well, it's not as simple as you think because the devil is in the details, > and we had to deal with all the details in order to perform real experiments > before giving up. (See my slides mentioned in previous email.) > >> >> 1) pick an IW s >> >> 2) keep stats on whether the IW works >> this can be within every single connection, or done out of >> band using tracers as separate machines >> >> 3) lower the IW if it tends to result in retransmits >> (possibly even increase it over longer timescales if it doesn't result in >> retransmits) >> >> This can happen on the timescale of days. Weeks even. I'm not talking about >> something that needs to happen in realtime. > > We've tried both the realtime and the offline schemes (again see my slides). > I've mentioned the problem with the realtime one in my previous email. For > the offline scheme, do you realize how many subnets are their even in just a > region, how much memory it requires, and how much work it takes to try to > import the data into the kernel and make it work efficiently? > > Again please show me your "simple" implementation and success experience. > > Jerry > >> >> The point is to automate the feedback mechanism that Mark and I discussed as >> necessary. >> >> Joe >> From mallman@icir.org Fri Nov 19 11:30:20 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18733A690B for ; Fri, 19 Nov 2010 11:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.533 X-Spam-Level: X-Spam-Status: No, score=-106.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u57d3Fd2ubnf for ; Fri, 19 Nov 2010 11:30:19 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 2073B28C128 for ; Fri, 19 Nov 2010 11:30:19 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAJJUxBv020188; Fri, 19 Nov 2010 11:30:59 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6C1BF2568C62; Fri, 19 Nov 2010 14:30:59 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CE6C30E.7040307@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: TV Dinner MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma53360-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 19 Nov 2010 14:30:59 -0500 Sender: mallman@icir.org Message-Id: <20101119193059.6C1BF2568C62@lawyers.icir.org> Cc: David Borman , tcpm , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 19:30:20 -0000 ----------ma53360-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Joe, I think we can basically agree on the high order bit of a backstop. But, ... > - either there's an objective metric for 'no harm' or not > > if there is and there's harm, backoff (moderately slowly, > i.e., over weeks, not minutes) I can't reconcile this with your example of 1000 connections opened in a row and if one bumps its head then the rest will and OH MY! Seemingly now you're willing to let things bump their head for weeks? I (a) can't follow this seemingly moving target you present and (b) think if you're willing to let 'problems' persist for weeks then it seems you can't really be all that worried about IW10. allman ----------ma53360-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkzm0HMACgkQWyrrWs4yIs47YgCgi8rZjYgapK3Db26JpebV6dAR eM8An3mBWtkeqi+hzt6vTtbaUJtwHx+Q =ymRY -----END PGP SIGNATURE----- ----------ma53360-1-- From anyrhine@cs.helsinki.fi Fri Nov 19 12:39:55 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A238728C10B for ; Fri, 19 Nov 2010 12:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX6JBI2ygXnL for ; Fri, 19 Nov 2010 12:39:53 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 876503A6862 for ; Fri, 19 Nov 2010 12:39:53 -0800 (PST) Received: from [192.168.10.3] (cs109108001124.pp.htv.fi [109.108.1.124]) (AUTH: PLAIN anyrhine, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 19 Nov 2010 22:40:42 +0200 id 00093E71.4CE6E0CA.00006BB8 From: Aki Nyrhinen To: Joe Touch In-Reply-To: <4CE6C693.4070007@isi.edu> References: <20101110152857.GA5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <4CE597AB.1020306@isi.edu> <4CE6B276.6040602@isi.edu> <4CE6C01B.7050601@isi.edu> <4CE6C693.4070007@isi.edu> Date: Fri, 19 Nov 2010 22:40:41 +0200 Message-Id: <1290199242.20298.26.camel@papana.nyrhi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution 2.22.3.1 Cc: David Borman , tcpm , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 20:39:55 -0000 All of this makes me wonder. If we are going to set one initial window for all, we make the assumption that it works reasonably well for ALL. If we make it dynamic, why does it suddenly have to be per destination? Why can't it be just a single variable (or per actual routing table entry, just to ignore connections to localhost, distinguish local lan etc) that starts at some value, is incremented once a month and is decremented if more than whatever number of clients the server owner is happy to induce IW losses for, experiences them. The state required to track this is simple enough that it can be saved/restored at shutdown/boot. Tracking i imagine takes two integers per possible IW: the number of connection attempts with that particular IW and another for the experienced losses with that IW. i'm sure clever people can come up with more compact representations. I like Joe's proposal and while I agree we don't have any evidence on how well such a thing would work in practice, I definitely don't think it is automatically worse than just saying "IW is 10 until the next time we start fighting over it". Aki On Fri, 2010-11-19 at 10:48 -0800, Joe Touch wrote: > Hi, Jerry, > > The reasons you give for this all being too complex to deploy are great > reasons we cannot afford to take a risk on IW=10. > > If you can't monitor it and tell us whether it works, you're seriously > asking us to just do it anyway, blindly? > > Joe > > On 11/19/2010 10:45 AM, Jerry Chu wrote: > > On Fri, Nov 19, 2010 at 10:21 AM, Joe Touch wrote: > >> > >> > >> On 11/19/2010 9:58 AM, Jerry Chu wrote: > >>> > >>> Hi Joe, > >>> > >>> On Fri, Nov 19, 2010 at 9:23 AM, Joe Touch wrote: > >>>> > >>>> Hi, Jerry (et al.), > >>>> > >>>> The logic here is astounding. > >>>> > >>>> We can't use a reactive system because it would make the wrong decision, > >>>> and > >>>> potentially treat all endpoints the wrong way. > >>> > >>> We can't use a reactive system like the one you suggested because it just > >>> doesn't work (except in a few limited cases). We are debating on an > >>> engineering > >>> issue here and this is IETF so we'll need running code and real deployment > >>> experience. If you can demonstrate your idea in a large server farm > >>> environment > >>> without requiring a large amount memory and complexity and actually > >>> showing > >>> reasonable performance latency I'll jump on it tomorrow! > >> > >> It's simpler than you're thinking, and doesn't require code in the data > >> path: > > > > Well, it's not as simple as you think because the devil is in the details, > > and we had to deal with all the details in order to perform real experiments > > before giving up. (See my slides mentioned in previous email.) > > > >> > >> 1) pick an IW s > >> > >> 2) keep stats on whether the IW works > >> this can be within every single connection, or done out of > >> band using tracers as separate machines > >> > >> 3) lower the IW if it tends to result in retransmits > >> (possibly even increase it over longer timescales if it doesn't result in > >> retransmits) > >> > >> This can happen on the timescale of days. Weeks even. I'm not talking about > >> something that needs to happen in realtime. > > > > We've tried both the realtime and the offline schemes (again see my slides). > > I've mentioned the problem with the realtime one in my previous email. For > > the offline scheme, do you realize how many subnets are their even in just a > > region, how much memory it requires, and how much work it takes to try to > > import the data into the kernel and make it work efficiently? > > > > Again please show me your "simple" implementation and success experience. > > > > Jerry > > > >> > >> The point is to automate the feedback mechanism that Mark and I discussed as > >> necessary. > >> > >> Joe > >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From hkchu@google.com Fri Nov 19 17:37:24 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D1228C0F5 for ; Fri, 19 Nov 2010 17:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.89 X-Spam-Level: X-Spam-Status: No, score=-109.89 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5xS9yRczKER for ; Fri, 19 Nov 2010 17:37:21 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 76B783A68C5 for ; Fri, 19 Nov 2010 17:37:16 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id oAK1c56K023266 for ; Fri, 19 Nov 2010 17:38:06 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290217086; bh=hgU8q5PqbZoudEeFpLekwfXelEU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=AsJQmYorvJktdDaf3PQvfHN4+0acH5frjrfVD1oEkDSXADJHREz6OCfUEvNW8rovp Ds8VCh27jL2cG4ZSfAAtg== Received: from gyb11 (gyb11.prod.google.com [10.243.49.75]) by wpaz29.hot.corp.google.com with ESMTP id oAK1c47h003186 for ; Fri, 19 Nov 2010 17:38:04 -0800 Received: by gyb11 with SMTP id 11so343181gyb.19 for ; Fri, 19 Nov 2010 17:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0s5p0kB5w1MOGIVBC/FlWzOonS8dUwh9q1KaV/7BWhA=; b=PHwTKuLRzNwojZlZ3CBXxSwFUNqB4KKYRHZbZJ3mufHmfpHwdfXztn99Ybxk0FgUnV NvpQqUuR6k1EOiKwCm1Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JjSqUgGIWi78d0DAiTmKg16pZaH/miqBPmhM9uXeeLYhzS2+qmPd4n29oIcTNQOHU9 zOSNQzpWnbfzGMxJRMUQ== MIME-Version: 1.0 Received: by 10.151.13.13 with SMTP id q13mr4656435ybi.291.1290217084160; Fri, 19 Nov 2010 17:38:04 -0800 (PST) Received: by 10.151.158.13 with HTTP; Fri, 19 Nov 2010 17:38:04 -0800 (PST) In-Reply-To: <4CE6C693.4070007@isi.edu> References: <20101110152857.GA5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <4CE597AB.1020306@isi.edu> <4CE6B276.6040602@isi.edu> <4CE6C01B.7050601@isi.edu> <4CE6C693.4070007@isi.edu> Date: Fri, 19 Nov 2010 17:38:04 -0800 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: "Anantha Ramaiah \(ananth\)" , tcpm , David Borman Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 01:37:25 -0000 Hi Joe, On Fri, Nov 19, 2010 at 10:48 AM, Joe Touch wrote: > Hi, Jerry, > > The reasons you give for this all being too complex to deploy are great > reasons we cannot afford to take a risk on IW=3D10. > > If you can't monitor it and tell us whether it works, you're seriously I'm confused - isn't it what we've been trying to do for the past three IETF meetings, backed with lots of data from both large scale real experiments and testbed emulation, to tell the world IW10 works? Or we've just been too subtle? :) Jerry > asking us to just do it anyway, blindly? > > Joe > > On 11/19/2010 10:45 AM, Jerry Chu wrote: >> >> On Fri, Nov 19, 2010 at 10:21 AM, Joe Touch =A0wrote: >>> >>> >>> On 11/19/2010 9:58 AM, Jerry Chu wrote: >>>> >>>> Hi Joe, >>>> >>>> On Fri, Nov 19, 2010 at 9:23 AM, Joe Touch =A0 =A0wrote= : >>>>> >>>>> Hi, Jerry (et al.), >>>>> >>>>> The logic here is astounding. >>>>> >>>>> We can't use a reactive system because it would make the wrong >>>>> decision, >>>>> and >>>>> potentially treat all endpoints the wrong way. >>>> >>>> We can't use a reactive system like the one you suggested because it >>>> just >>>> doesn't work (except in a few limited cases). We are debating on an >>>> engineering >>>> issue here and this is IETF so we'll need running code and real >>>> deployment >>>> experience. If you can demonstrate your idea in a large server farm >>>> environment >>>> without requiring a large amount memory and complexity and actually >>>> showing >>>> reasonable performance latency I'll jump on it tomorrow! >>> >>> It's simpler than you're thinking, and doesn't require code in the data >>> path: >> >> Well, it's not as simple as you think because the devil is in the detail= s, >> and we had to deal with all the details in order to perform real >> experiments >> before giving up. (See my slides mentioned in previous email.) >> >>> >>> 1) pick an IW s >>> >>> 2) keep stats on whether the IW works >>> =A0 =A0 =A0 =A0this can be within every single connection, or done out = of >>> =A0 =A0 =A0 =A0band using tracers as separate machines >>> >>> 3) lower the IW if it tends to result in retransmits >>> (possibly even increase it over longer timescales if it doesn't result = in >>> retransmits) >>> >>> This can happen on the timescale of days. Weeks even. I'm not talking >>> about >>> something that needs to happen in realtime. >> >> We've tried both the realtime and the offline schemes (again see my >> slides). >> I've mentioned the problem with the realtime one in my previous email. F= or >> the offline scheme, do you realize how many subnets are their even in ju= st >> a >> region, how much memory it requires, and how much work it takes to try t= o >> import the data into the kernel and make it work efficiently? >> >> Again please show me your "simple" implementation and success experience= . >> >> Jerry >> >>> >>> The point is to automate the feedback mechanism that Mark and I discuss= ed >>> as >>> necessary. >>> >>> Joe >>> > From wes@mti-systems.com Sun Nov 21 20:32:52 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D69C3A6936 for ; Sun, 21 Nov 2010 20:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlUNaA7jXk-9 for ; Sun, 21 Nov 2010 20:32:51 -0800 (PST) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by core3.amsl.com (Postfix) with ESMTP id F09933A6A00 for ; Sun, 21 Nov 2010 20:32:50 -0800 (PST) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id oAM4XhRA007131 for ; Sun, 21 Nov 2010 23:33:45 -0500 Authentication-Results: cm-omr1 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.127.11] ([174.130.127.11:57631] helo=[192.168.1.104]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 70/79-02317-7A2F9EC4; Sun, 21 Nov 2010 23:33:43 -0500 Message-ID: <4CE9F2A6.3000100@mti-systems.com> Date: Sun, 21 Nov 2010 23:33:42 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: ietfdbh@comcast.net, iesg-secretary@ietf.org Content-Type: multipart/mixed; boundary="------------070008040400080909040606" Cc: tcpm@ietf.org Subject: [tcpm] requesting publication from TCPM of draft-eggert-tcpm-historicize X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 04:32:52 -0000 This is a multi-part message in MIME format. --------------070008040400080909040606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, attached is the PROTO statement for the TCPM working group document draft-eggert-tcpm-historicize, which we would like to request publication as an Informational RFC. Wesley Eddy (TCPM co-chair) is the document shepherd. Note that this is a TCPM working group item, and marked as such in the tracker, despite the filename prefix. --------------070008040400080909040606 Content-Type: text/plain; name="HISTORICIZE-PROTO.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="HISTORICIZE-PROTO.txt" draft-eggert-tcpm-historicize (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. He has personally reviewed this version and believes it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had review in the TCPM working group, and the content of the document is largely based on RFC 4614 which had been through several reviews in the TCPM working group and in the broader IETF. The reviews on this document were brief and the working group last call concluded with very light feedback, but the level of support (and lack of resistance) is appropriate for the scope of this document, which simply provides formal movement of several RFCs to Historic status that had already been mentioned as such in RFC 4614, but never formally altered with the RFC Editor. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There has been no resistance to this document and reasonable support for it at its inception. This formalizes document status on several historic TCP extensions that have ceased to be relevant. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? IDNits finds obsolete references, but these are spurious as the documents referenced are mentioned here specifically (and purposefully) so that they can be moved to Historic. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are properly split. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA Considerations are present and clearly instruct IANA on the marking of several options as "obsolete" on publication of this document as an RFC. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not Applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. >From abstract: This document recommends that several TCP extensions that have never seen widespread use be moved to Historic status. The affected RFCs are RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and RFC1693. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing exceptional occurred during the working group process for this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The document does not define a protocol, it formalizes the moving of several outdated TCP documents to Historic status. --------------070008040400080909040606-- From wes@mti-systems.com Sun Nov 21 20:36:31 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33F83A69FA for ; Sun, 21 Nov 2010 20:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qIXJcrszYh7 for ; Sun, 21 Nov 2010 20:36:30 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by core3.amsl.com (Postfix) with ESMTP id 7949A3A6888 for ; Sun, 21 Nov 2010 20:36:30 -0800 (PST) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id oAM4bPGQ001465 for ; Sun, 21 Nov 2010 23:37:25 -0500 Authentication-Results: cm-omr8 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.127.11] ([174.130.127.11:25577] helo=[192.168.1.104]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 11/00-24350-483F9EC4; Sun, 21 Nov 2010 23:37:25 -0500 Message-ID: <4CE9F384.8020406@mti-systems.com> Date: Sun, 21 Nov 2010 23:37:24 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: lars.eggert@nokia.com, iesg-secretary@ietf.org Content-Type: multipart/mixed; boundary="------------020309020708050801000400" Cc: tcpm@ietf.org, fernando@gont.com.ar Subject: [tcpm] requesting publication from TCPM of draft-ietf-tcpm-tcp-timestamps X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 04:36:32 -0000 This is a multi-part message in MIME format. --------------020309020708050801000400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, attached is the PROTO statement for the TCPM working group document draft-ietf-tcpm-tcp-timestamps, which we would like to request for publication as a BCP. Wesley Eddy (TCPM co-chair) is the document shepherd. --------------020309020708050801000400 Content-Type: text/plain; name="TIMESTAMPS-PROTO.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="TIMESTAMPS-PROTO.txt" draft-ietf-tcpm-tcp-timestamps (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. He has personally reviewed this version and believes it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had review in the TCPM working group, and underwent several revisions based on mailing list discussion prior to becoming a working group draft. Some comments were received during working group last call which were sufficiently addressed. The depth and breadth of reviews has been appropriate for the scope of the draft. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There has been a reasonable amount of support from several individuals for this document. There has not been recent resistance to any of the document's current content, which was reduced when it was clear that some additional content (when it was still an individual submission) did not have consensus. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? There are a few IDNITS errors which appear to be a mix of spurious and non-worrisome. One such case is the reported down-ref to RFC 1337, which is used as Normative here because it should be read and understood in understanding this BCP, even though 1337 it is marked Informational in the RFC Editor database. This shepherd thinks this is consistent with the spirit of RFC 3967 which allows downrefs in BCPs to Informational documents. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are properly split. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA Considerations are present and specify no actions for IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not Applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. >From abstract: This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing exceptional occurred during the working group process for this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Implementations of the technique described in this document have been implemented for some time. The document specifically cites the Linux kernel's TCP implementation, though there are others as well. One reason for completing this document is to bring this practice to the RFC series so that it can be captured for other implementations. --------------020309020708050801000400-- From Xiangsong.Cui@huawei.com Mon Nov 22 20:03:07 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0D73A6AD2 for ; Mon, 22 Nov 2010 20:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=2.329, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4yXgen9DYBR for ; Mon, 22 Nov 2010 20:03:06 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2405C3A6A0D for ; Mon, 22 Nov 2010 20:03:06 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCB0069TKMGU9@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 23 Nov 2010 12:03:52 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCB00I9BKMFA6@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 23 Nov 2010 12:03:52 +0800 (CST) Date: Tue, 23 Nov 2010 12:03:51 +0800 From: Xiangsong Cui In-reply-to: To: 'Jerry Chu' , 'Joe Touch' Message-id: <009801cb8ac3$7089dc90$519d95b0$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcuIU5+C7CbV8UCCTxi2Gfhy1OIFWgCbTnOQ iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <20101110152857.GA5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> <4CE597AB.1020306@isi.edu> <4CE6B276.6040602@isi.edu> <4CE6C01B.7050601@isi.edu> <07@isi.edu> Cc: 'David Borman' , 'tcpm' , "'Anantha Ramaiah \(ananth\)'" Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 04:03:07 -0000 Hi, Firstly I would like to say I like this idea (i.e., increasing initial window), although I am not sure that is right. My concern here is, how to evaluate the right IW number? (perhaps, 3 is good, 10 is better, however, 20 is the right) I notice that in RFC3390 Increasing TCP's Initial Window,=20 there is a statement (in section 7) of=20 "Larger TCP initial windows would not dramatically increase the burstiness of TCP traffic in the Internet today, because such traffic is already fairly bursty. " I just wonder, when we increased the IW to 3, how did we get the = judgment that the increase is right? When RFC3390 is implemented, what experience (positive and negative) do we get? PS, is a survey on network box (along the path) queue capacity needed? Thanks and regards, Xiangsong > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of > Jerry Chu > Sent: Saturday, November 20, 2010 9:38 AM > To: Joe Touch > Cc: Anantha Ramaiah (ananth); tcpm; David Borman > Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes >=20 > Hi Joe, >=20 > On Fri, Nov 19, 2010 at 10:48 AM, Joe Touch wrote: > > Hi, Jerry, > > > > The reasons you give for this all being too complex to deploy are = great > > reasons we cannot afford to take a risk on IW=3D10. > > > > If you can't monitor it and tell us whether it works, you're = seriously >=20 > I'm confused - isn't it what we've been trying to do for the past = three > IETF meetings, backed with lots of data from both large scale real > experiments and testbed emulation, to tell the world IW10 works? > Or we've just been too subtle? :) >=20 > Jerry >=20 > > asking us to just do it anyway, blindly? > > > > Joe > > > > On 11/19/2010 10:45 AM, Jerry Chu wrote: > >> > >> On Fri, Nov 19, 2010 at 10:21 AM, Joe Touch = =A0wrote: > >>> > >>> > >>> On 11/19/2010 9:58 AM, Jerry Chu wrote: > >>>> > >>>> Hi Joe, > >>>> > >>>> On Fri, Nov 19, 2010 at 9:23 AM, Joe Touch =A0 = =A0wrote: > >>>>> > >>>>> Hi, Jerry (et al.), > >>>>> > >>>>> The logic here is astounding. > >>>>> > >>>>> We can't use a reactive system because it would make the wrong > >>>>> decision, > >>>>> and > >>>>> potentially treat all endpoints the wrong way. > >>>> > >>>> We can't use a reactive system like the one you suggested because = it > >>>> just > >>>> doesn't work (except in a few limited cases). We are debating on = an > >>>> engineering > >>>> issue here and this is IETF so we'll need running code and real > >>>> deployment > >>>> experience. If you can demonstrate your idea in a large server = farm > >>>> environment > >>>> without requiring a large amount memory and complexity and = actually > >>>> showing > >>>> reasonable performance latency I'll jump on it tomorrow! > >>> > >>> It's simpler than you're thinking, and doesn't require code in the data > >>> path: > >> > >> Well, it's not as simple as you think because the devil is in the details, > >> and we had to deal with all the details in order to perform real > >> experiments > >> before giving up. (See my slides mentioned in previous email.) > >> > >>> > >>> 1) pick an IW s > >>> > >>> 2) keep stats on whether the IW works > >>> =A0 =A0 =A0 =A0this can be within every single connection, or done = out of > >>> =A0 =A0 =A0 =A0band using tracers as separate machines > >>> > >>> 3) lower the IW if it tends to result in retransmits > >>> (possibly even increase it over longer timescales if it doesn't = result in > >>> retransmits) > >>> > >>> This can happen on the timescale of days. Weeks even. I'm not = talking > >>> about > >>> something that needs to happen in realtime. > >> > >> We've tried both the realtime and the offline schemes (again see my > >> slides). > >> I've mentioned the problem with the realtime one in my previous = email. For > >> the offline scheme, do you realize how many subnets are their even = in just > >> a > >> region, how much memory it requires, and how much work it takes to = try to > >> import the data into the kernel and make it work efficiently? > >> > >> Again please show me your "simple" implementation and success > experience. > >> > >> Jerry > >> > >>> > >>> The point is to automate the feedback mechanism that Mark and I > discussed > >>> as > >>> necessary. > >>> > >>> Joe > >>> > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From lars.eggert@nokia.com Tue Nov 23 03:43:27 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C63A3A6920 for ; Tue, 23 Nov 2010 03:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cTj3SXC7gGC for ; Tue, 23 Nov 2010 03:43:26 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id E26723A691B for ; Tue, 23 Nov 2010 03:43:25 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oANBiMBq005541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Nov 2010 13:44:22 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-41-820247463; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 23 Nov 2010 13:42:56 +0200 Message-Id: <4431B1B2-A769-43F9-AB60-91C751159C16@nokia.com> To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 23 Nov 2010 13:44:19 +0200 (EET) X-Nokia-AV: Clean Subject: [tcpm] AD review: draft-ietf-tcpm-tcp-timestamps-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 11:43:27 -0000 --Apple-Mail-41-820247463 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Summary: No show-stoppers, will initiate IETF last call. (Take the = comments below as last call comments.) Section 1., paragraph 4: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this > document are to be interpreted as described in RFC 2119 [RFC2119]. The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. The boilerplate text and reference can hence be removed. Section 250000, paragraph 2: > The upcoming revision of RFC 1323, [I-D.ietf-tcpm-1323bis], > recommends the selection of timestamps such that they are > monotonically-increasing across connections. Specific > implementation details for such a Timestamps generation scheme = can > be found in [I-D.gont-timestamps-generation]. I'm a bit uncomfortable with a BCP pointing to an individual ID for implementation details of a purely informative reference. Is there really a need for this reference? Section 4., paragraph 1: > [RFC0793] suggests that the ISNs of TCP conections be generated = from Nit: s/conections/connections/ Section 5., paragraph 1: > require monotonically-increasing timestamps across conenctions. Nit: s/conenctions./connections./ Section 8.1., paragraph 4: > [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", > RFC 1337, May 1992. This is a DOWNREF to an Informational document. I will call this out during the IETF last call. Appendix A., paragraph 2: > The question was raised on the tcpm mailing-list as to how this > algorithm would operate in case a computer reboots, keeps the same = IP > address, looses memory of the previous time stamps, and then tries = to > reestablish a previous connection. It doesn't matter where this question was raised - suggest to rephrase. --Apple-Mail-41-820247463 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag 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 aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyMzExNDI1NlowIwYJKoZIhvcNAQkE MRYEFF0lRHWulZY/MRcRP7aqyrcn4ZkUMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AH7oGRXb0w45GagLUbFvsvoRUX/5/P20+UWQYD3vPGyZVQJlIrb/bcpoYAuf7posv8fKQzLhpCsd edrE+zU69yM3aEMBkNA3BKYMOuxwdxVkrQR6pL80NRkmruAFnFrbrs0OgZWA618fGMV5kO2Bw8h9 GefHJwo0mwYBy/zpnYLqQeVsHPGvJvzFa6M1P8g6KKMCi8e5m1rEiEIljIsU9zR1otGTvSrp4/2V TkfD4Rma0WO+uxXkDDHZk+xlyA5dgLbgf6tTCSG6B5In/bt7iPPzBk4zbdU0GMSq1JceTCEjogE9 qSgzXIwIOWt3MhiGE5oTjdY9gIy3u0dbjfFAScQAAAAAAAA= --Apple-Mail-41-820247463-- From iesg-secretary@ietf.org Tue Nov 23 05:16:30 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8D03A6949; Tue, 23 Nov 2010 05:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVzZYWYcIcEc; Tue, 23 Nov 2010 05:16:29 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11D93A694C; Tue, 23 Nov 2010 05:16:29 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101123131629.31485.56958.idtracker@localhost> Date: Tue, 23 Nov 2010 05:16:29 -0800 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (Reducing the TIME-WAIT state using TCP timestamps) to BCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 13:16:30 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Reducing the TIME-WAIT state using TCP timestamps' as a BCP 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 2010-12-07. 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. *** Note: *** This document has a downward reference to RFC 1337. Please comment during the last call on the appropriateness of this downref. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-timestamps/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-timestamps/ No IPR declarations have been submitted directly on this I-D. From touch@isi.edu Tue Nov 23 09:10:28 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFA433A68A0 for ; Tue, 23 Nov 2010 09:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPL6n+ur+R1E for ; Tue, 23 Nov 2010 09:10:27 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id BDF2E3A6881 for ; Tue, 23 Nov 2010 09:10:27 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oANHAvG0010635 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 23 Nov 2010 09:10:57 -0800 (PST) Message-ID: <4CEBF5A1.3090601@isi.edu> Date: Tue, 23 Nov 2010 09:10:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Lars Eggert References: <4431B1B2-A769-43F9-AB60-91C751159C16@nokia.com> In-Reply-To: <4431B1B2-A769-43F9-AB60-91C751159C16@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: oANHAvG0010635 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-timestamps-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 17:10:28 -0000 Lars, et al., How can this be a BCP if it makes no 2119 recommendations? There appears to already be some language to this effect, just not capitalized. It seems worth doing a quick revision to see if this point can be corrected by changing the caps judiciously. Joe On 11/23/2010 3:42 AM, Lars Eggert wrote: > Summary: No show-stoppers, will initiate IETF last call. (Take the comments below as last call comments.) > > > Section 1., paragraph 4: > >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [RFC2119]. > > The document doesn't use any RFC 2119 keywords, yet seems to have RFC > 2119 boilerplate text. The boilerplate text and reference can hence be > removed. > > > Section 250000, paragraph 2: >> The upcoming revision of RFC 1323, [I-D.ietf-tcpm-1323bis], >> recommends the selection of timestamps such that they are >> monotonically-increasing across connections. Specific >> implementation details for such a Timestamps generation scheme can >> be found in [I-D.gont-timestamps-generation]. > > I'm a bit uncomfortable with a BCP pointing to an individual ID for > implementation details of a purely informative reference. Is there > really a need for this reference? > > > Section 4., paragraph 1: >> [RFC0793] suggests that the ISNs of TCP conections be generated from > > Nit: s/conections/connections/ > > > Section 5., paragraph 1: >> require monotonically-increasing timestamps across conenctions. > > Nit: s/conenctions./connections./ > > > Section 8.1., paragraph 4: >> [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", >> RFC 1337, May 1992. > > This is a DOWNREF to an Informational document. I will call this out > during the IETF last call. > > > Appendix A., paragraph 2: >> The question was raised on the tcpm mailing-list as to how this >> algorithm would operate in case a computer reboots, keeps the same IP >> address, looses memory of the previous time stamps, and then tries to >> reestablish a previous connection. > > It doesn't matter where this question was raised - suggest to > rephrase. > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fernando.gont.netbook.win@gmail.com Tue Nov 23 13:28:46 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E863A69C8 for ; Tue, 23 Nov 2010 13:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3beAw-OtJyE for ; Tue, 23 Nov 2010 13:28:45 -0800 (PST) Received: from mail-bw0-f66.google.com (mail-bw0-f66.google.com [209.85.214.66]) by core3.amsl.com (Postfix) with ESMTP id 641AB3A69C7 for ; Tue, 23 Nov 2010 13:28:45 -0800 (PST) Received: by bwz7 with SMTP id 7so3276162bwz.1 for ; Tue, 23 Nov 2010 13:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=2/8o5M+6LZzb+zgX2trnLqKPV3q/JIExKnFd0l9mH2Q=; b=g/V0X+Pyzy2cXxrptsmm+07qFw09SB7wJjEey2NQoOWMDXJ9/bgmzHgRDzPvPkFc82 ZorOb8vEEAIxklvsEfob7KAQdB+ETd12nIgbt4fME0IZql2BfqZi0g0KxikkcTJ5wwqJ 3qN355eCFwW0P8lvM30mgFx+YOZ3FMh2B/oNY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Hoe0prGMNhUptak1613YljkoXBkcv4silrUfFxNiRVfWJrbLnWs16xPPvdjZ32zxJR +814DhJZPA5xaWdQMWpq7WCfKcJcpcqXRaOCSycQl4nOdzVTVokIieme6UbV5lIWj11B vY803aNJo3NRhEHGlIfC9p8NAHtQHrAg+TVuY= MIME-Version: 1.0 Received: by 10.204.53.130 with SMTP id m2mr7744636bkg.111.1290547781842; Tue, 23 Nov 2010 13:29:41 -0800 (PST) Sender: fernando.gont.netbook.win@gmail.com Received: by 10.204.189.74 with HTTP; Tue, 23 Nov 2010 13:29:41 -0800 (PST) In-Reply-To: <4431B1B2-A769-43F9-AB60-91C751159C16@nokia.com> References: <4431B1B2-A769-43F9-AB60-91C751159C16@nokia.com> Date: Tue, 23 Nov 2010 18:29:41 -0300 X-Google-Sender-Auth: YpkvU3q8G6zH39nB_WKpS46LwmU Message-ID: From: Fernando Gont To: Lars Eggert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-timestamps-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 21:28:46 -0000 Hi, Lars, > Section 1., paragraph 4: > >> =A0 =A0The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT= ", >> =A0 =A0"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in t= his >> =A0 =A0document are to be interpreted as described in RFC 2119 [RFC2119]= . > > =A0The document doesn't use any RFC 2119 keywords, yet seems to have RFC > =A02119 boilerplate text. The boilerplate text and reference can hence be > =A0removed. As pointed out by Joe, I should probably CAPitalize the specific requirements contained in the document, instead. > Section 250000, paragraph 2: >> =A0 =A0 =A0 The upcoming revision of RFC 1323, [I-D.ietf-tcpm-1323bis], >> =A0 =A0 =A0 recommends the selection of timestamps such that they are >> =A0 =A0 =A0 monotonically-increasing across connections. =A0Specific >> =A0 =A0 =A0 implementation details for such a Timestamps generation sche= me can >> =A0 =A0 =A0 be found in [I-D.gont-timestamps-generation]. > > =A0I'm a bit uncomfortable with a BCP pointing to an individual ID for > =A0implementation details of a purely informative reference. Is there > =A0really a need for this reference? Maybe changing the text to "An example of such a Timestamps...." looks bett= er? I think the reference is useful -- some had even proposed to include a sample algorithm in an Appendix. --- if there's no pointer, the read is left alone to figure out a possible algorithm. > Section 8.1., paragraph 4: >> =A0 =A0[RFC1337] =A0Braden, B., "TIME-WAIT Assassination Hazards in TCP"= , >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 RFC 1337, May 1992. > > =A0This is a DOWNREF to an Informational document. I will call this out > =A0during the IETF last call. Should I move this one to the "Informative" references? > Appendix A., paragraph 2: >> =A0 =A0The question was raised on the tcpm mailing-list as to how this >> =A0 =A0algorithm would operate in case a computer reboots, keeps the sam= e IP >> =A0 =A0address, looses memory of the previous time stamps, and then trie= s to >> =A0 =A0reestablish a previous connection. > > =A0It doesn't matter where this question was raised - suggest to > =A0rephrase. How about either: option 1: "This section clarifies how this algorithm...." option 2: "While producing this document, the question was raised as to how= ..." Pick one, or propose an alternative ;-) P.S.: Thanks for the reported nits, too! -- I'll fix them. Thanks! Kind regards, --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Tue Nov 23 13:33:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E34328C15C for ; Tue, 23 Nov 2010 13:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEoDm04g0y41 for ; Tue, 23 Nov 2010 13:33:01 -0800 (PST) Received: from mail-bw0-f66.google.com (mail-bw0-f66.google.com [209.85.214.66]) by core3.amsl.com (Postfix) with ESMTP id 278B13A69CA for ; Tue, 23 Nov 2010 13:33:00 -0800 (PST) Received: by bwz7 with SMTP id 7so3277925bwz.1 for ; Tue, 23 Nov 2010 13:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=Xum7iI2pEjExScVuE6ELlFLWWZ2w7JlssAKasyFz4JY=; b=u4JnJLx9NRjS6EqrVhWg8zKfVx+3otk8/4ajTkQ0TuNkF3P5MRH2uGc3oeGZ2+7bZj QpETZuTqmPpO7iIa1ly6s3EbH8lHg+KuMw7MxMv/LuMe9Y3bctMkN5xn3h7R4a0LjfjJ TkwU2yMsg56dKpjpAsMVGpxYFPWshnG19jBOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=RlNBG+UVGRgdX2UsVw0BZ681oc8RSbK5FilWib1+bUklxphtdh6rIV8BSgf5oL1IFv SVtitGnyu45M8HFfPxilsOdIUi1B76yY7VykAbDAyClblyWQOLDpgXsvK2MUE90p8a4A JJCmKaGclHB6e8zMZFjAO73aKsmqrxZAiGRVM= MIME-Version: 1.0 Received: by 10.204.152.144 with SMTP id g16mr1500714bkw.57.1290548038399; Tue, 23 Nov 2010 13:33:58 -0800 (PST) Sender: fernando.gont.netbook.win@gmail.com Received: by 10.204.189.74 with HTTP; Tue, 23 Nov 2010 13:33:58 -0800 (PST) In-Reply-To: <4CEBF5A1.3090601@isi.edu> References: <4431B1B2-A769-43F9-AB60-91C751159C16@nokia.com> <4CEBF5A1.3090601@isi.edu> Date: Tue, 23 Nov 2010 18:33:58 -0300 X-Google-Sender-Auth: SGQuI3gWwT6yyFeCid41mU3F7Iw Message-ID: From: Fernando Gont To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-timestamps-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 21:33:02 -0000 On Tue, Nov 23, 2010 at 2:10 PM, Joe Touch wrote: > How can this be a BCP if it makes no 2119 recommendations? > > There appears to already be some language to this effect, just not > capitalized. It seems worth doing a quick revision to see if this point can > be corrected by changing the caps judiciously. How about changing the text in Section 2 (right above the bulleted list) to: " Processing of SYN segments received for connections in the TIME-WAIT state SHOULD occur as follows:" Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Tue Nov 23 13:36:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB13F28C1BC for ; Tue, 23 Nov 2010 13:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZSIGcQoOHOe for ; Tue, 23 Nov 2010 13:36:57 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id EE2353A69CA for ; Tue, 23 Nov 2010 13:36:56 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oANLbLEb029925 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 23 Nov 2010 13:37:21 -0800 (PST) Message-ID: <4CEC3411.1030300@isi.edu> Date: Tue, 23 Nov 2010 13:37:21 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Fernando Gont References: <4431B1B2-A769-43F9-AB60-91C751159C16@nokia.com> <4CEBF5A1.3090601@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: oANLbLEb029925 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-timestamps-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 21:36:58 -0000 On 11/23/2010 1:33 PM, Fernando Gont wrote: > How about changing the text in Section 2 (right above the bulleted list) to: > > " Processing of SYN segments received for connections in the TIME-WAIT > state SHOULD occur as follows:" There has to be more to it than just one 2119 sentence. Joe From fernando.gont.netbook.win@gmail.com Tue Nov 23 13:45:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3C93A69A0 for ; Tue, 23 Nov 2010 13:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knSV0eOVdrSh for ; Tue, 23 Nov 2010 13:45:37 -0800 (PST) Received: from mail-bw0-f66.google.com (mail-bw0-f66.google.com [209.85.214.66]) by core3.amsl.com (Postfix) with ESMTP id 5C8683A696E for ; Tue, 23 Nov 2010 13:45:37 -0800 (PST) Received: by bwz7 with SMTP id 7so3282328bwz.1 for ; Tue, 23 Nov 2010 13:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=rApP6fmnz9q9U8MxsBki6jHrQxnh9OWZi6SIafgMG1k=; b=s/Rx3bp/zCZOqT7sk89umpnK5WG6DTCFwO6Q8JRrtBm38S8RysWvX3XIBSkrXhnF7E aeGEOsdgVcEqc7F2U8xei8TYPzH/tSg133t+3EpdWH4k/X89Hd7Y0XO4LzxXNXp6fjt7 XXHjpRLT9iZuQvDlyFgqvg7HNQ9cbi+47sr3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=XFAyUPH/e8sOPErxXWEsAMqoUHod8mgRuMkyadfREfpmF7GCWYpJeBophdjG1VUy5R ZHXjypLjs4mAQ3ssFd3fS3N+mU1mJA+mnppCZpFVq6GfImnvK98wU4u/YHLIsaO/S8lU wQM+y+Swok0WGwIllYD46GTEjnbQfwqVTRX7k= MIME-Version: 1.0 Received: by 10.204.102.78 with SMTP id f14mr7778894bko.30.1290548793963; Tue, 23 Nov 2010 13:46:33 -0800 (PST) Sender: fernando.gont.netbook.win@gmail.com Received: by 10.204.189.74 with HTTP; Tue, 23 Nov 2010 13:46:33 -0800 (PST) In-Reply-To: <4CEC3411.1030300@isi.edu> References: <4431B1B2-A769-43F9-AB60-91C751159C16@nokia.com> <4CEBF5A1.3090601@isi.edu> <4CEC3411.1030300@isi.edu> Date: Tue, 23 Nov 2010 18:46:33 -0300 X-Google-Sender-Auth: 3EeDHQFORDHorZ8rqFysts6eFP0 Message-ID: From: Fernando Gont To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-timestamps-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 21:45:38 -0000 On Tue, Nov 23, 2010 at 6:37 PM, Joe Touch wrote: >> How about changing the text in Section 2 (right above the bulleted list) >> to: >> >> " =A0Processing of SYN segments received for connections in the TIME-WAI= T >> =A0 =A0state SHOULD occur as follows:" > > There has to be more to it than just one 2119 sentence. Do you mean that I should include RFC2119-speak in each of the bullets, or what? -- a proposed way forward would be appreciated. Thanks! Kind regards, --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Tue Nov 23 14:14:35 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12DC428C11B for ; Tue, 23 Nov 2010 14:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olrJltWF1Yfv for ; Tue, 23 Nov 2010 14:14:34 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 23A6328C152 for ; Tue, 23 Nov 2010 14:14:34 -0800 (PST) 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 oANMED1A026019 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 23 Nov 2010 14:14:13 -0800 (PST) Message-ID: <4CEC3CB5.5030205@isi.edu> Date: Tue, 23 Nov 2010 14:14:13 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Fernando Gont References: <4431B1B2-A769-43F9-AB60-91C751159C16@nokia.com> <4CEBF5A1.3090601@isi.edu> <4CEC3411.1030300@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-timestamps-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 22:14:35 -0000 On 11/23/2010 1:46 PM, Fernando Gont wrote: > On Tue, Nov 23, 2010 at 6:37 PM, Joe Touch wrote: > >>> How about changing the text in Section 2 (right above the bulleted list) >>> to: >>> >>> " Processing of SYN segments received for connections in the TIME-WAIT >>> state SHOULD occur as follows:" >> >> There has to be more to it than just one 2119 sentence. > > Do you mean that I should include RFC2119-speak in each of the > bullets, or what? -- a proposed way forward would be appreciated. Take a look at other BCPs. They don't express their suggestions in a single 2119 sentence. Joe From fernando.gont.netbook.win@gmail.com Tue Nov 23 14:34:32 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0B13A6997 for ; Tue, 23 Nov 2010 14:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns6de2ZZcs-S for ; Tue, 23 Nov 2010 14:34:31 -0800 (PST) Received: from mail-ww0-f66.google.com (mail-ww0-f66.google.com [74.125.82.66]) by core3.amsl.com (Postfix) with ESMTP id 3E20A3A696E for ; Tue, 23 Nov 2010 14:34:30 -0800 (PST) Received: by wwb13 with SMTP id 13so1441893wwb.1 for ; Tue, 23 Nov 2010 14:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=shWbZ02UqT+RRobY39uFrxO7Qr4+Qf3HJ82MiO/jKh4=; b=bNievvncyq1ievQ292vcFOqVuxbspkJJEnD/A/cht/z8Kx+V5K/nmseErgZR3bApPU 3ud7jWCVcMb87LengJTAJ3cCbfMlZDEaweru5XUD39kWi8fAuyIO+aSnOSSnJTxq78C1 UVkfMquDmlaypyhHPeNae9j+tAK8WRupSzwAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=e17zTou6/IA5qTOng78c8v+6hxtSvJwd2bUEMkmMXzgtFKqxoKE/ehGix4/TgBQu2H GjbgSIoC1xm+i64sYD4hj4ANbZtEMi/xbwTNsVYGoiQJUatn3M/wQr76s1RTeofkQNDU Rxc7ce3SI+CyulbUpjv/MmNmbUThTQpMHOCPY= MIME-Version: 1.0 Received: by 10.216.59.199 with SMTP id s49mr1835102wec.111.1290551727736; Tue, 23 Nov 2010 14:35:27 -0800 (PST) Sender: fernando.gont.netbook.win@gmail.com Received: by 10.216.163.134 with HTTP; Tue, 23 Nov 2010 14:35:27 -0800 (PST) In-Reply-To: <4CEC3CB5.5030205@isi.edu> References: <4431B1B2-A769-43F9-AB60-91C751159C16@nokia.com> <4CEBF5A1.3090601@isi.edu> <4CEC3411.1030300@isi.edu> <4CEC3CB5.5030205@isi.edu> Date: Tue, 23 Nov 2010 19:35:27 -0300 X-Google-Sender-Auth: 2FqTVSEpDoRJNkkEAg8GXOhTiKs Message-ID: From: Fernando Gont To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] AD review: draft-ietf-tcpm-tcp-timestamps-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 22:34:32 -0000 On Tue, Nov 23, 2010 at 7:14 PM, Joe Touch wrote: >>>> How about changing the text in Section 2 (right above the bulleted lis= t) >>>> to: >>>> >>>> " =A0Processing of SYN segments received for connections in the TIME-W= AIT >>>> =A0 =A0state SHOULD occur as follows:" >>> >>> There has to be more to it than just one 2119 sentence. >> >> Do you mean that I should include RFC2119-speak in each of the >> bullets, or what? -- a proposed way forward would be appreciated. > > Take a look at other BCPs. They don't express their suggestions in a sing= le > 2119 sentence. They may have multiple suggestions. Many BCPs have only a few RFC2119 terms= . So far, I will apply the change I mentioned above. If you have any specific proposal to improve this aspect, please do let me know. Thanks! Kind regards, --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From wes@mti-systems.com Tue Nov 23 21:06:59 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E084428C1DF for ; Tue, 23 Nov 2010 21:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5RPtgdZUgM0 for ; Tue, 23 Nov 2010 21:06:59 -0800 (PST) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by core3.amsl.com (Postfix) with ESMTP id C9EC828C1E1 for ; Tue, 23 Nov 2010 21:06:58 -0800 (PST) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id oAO57sSM026196 for ; Wed, 24 Nov 2010 00:07:57 -0500 Authentication-Results: cm-omr10 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.73.245] ([174.130.73.245:15818] helo=[192.168.1.104]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id ED/35-04819-AAD9CEC4; Wed, 24 Nov 2010 00:07:54 -0500 Message-ID: <4CEC9DAB.3090502@mti-systems.com> Date: Wed, 24 Nov 2010 00:07:55 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] NewReno revision (RFC3782bis) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 05:07:00 -0000 We had previously polled the working group on revising RFC3782 (NewReno) in order to account for the reported errata and Yoshifumi's modification. Since TCPM's charter already includes maintaining existing pieces of TCP (like NewReno), and given that there was a small amount of support on the list, no resistance, and all of the authors of RFC 3782 plus Yoshifumi have expressed interest and energy, we asked the authors to submit the next revision of their 3782bis document as a WG draft. The prior revision is: http://datatracker.ietf.org/doc/draft-henderson-tcpm-rfc3782-bis/ which will be replaced by the working group document. Since the known updates are fairly simple, we set a charter milestone only a few months away (April 2011) for submission to the IESG (still as a Proposed Standard). From ycheng@google.com Tue Nov 23 22:39:15 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8F703A68A2 for ; Tue, 23 Nov 2010 22:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWajoHXIbneR for ; Tue, 23 Nov 2010 22:39:15 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 532C43A69CB for ; Tue, 23 Nov 2010 22:39:14 -0800 (PST) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id oAO6eCBF029720 for ; Tue, 23 Nov 2010 22:40:13 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290580813; bh=RdqL1kqlP0Vfhfv5jXjx5cTTJi0=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=LRn3ysfwQeEMJPMISpPDL0xzrNlCa+EaEOzqjqPzG2H8hxpoHaxo/C9HcXicO9kJI UuBM+peWjuLDh689tM0GQ== Received: from qwb8 (qwb8.prod.google.com [10.241.193.72]) by kpbe16.cbf.corp.google.com with ESMTP id oAO6eANS017499 for ; Tue, 23 Nov 2010 22:40:11 -0800 Received: by qwb8 with SMTP id 8so2293032qwb.11 for ; Tue, 23 Nov 2010 22:40:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:cc:content-type; bh=bekgQOeBMqk2mTt5JyfPWne/M1JNL9w0Venqn54Xwnw=; b=ZFmh5V2GQlXP8eg+JdRqcGqSmCwTQ8RBxMpIVD0ZJu4SAqdgaUHmlMLl3KN6mKK5UL 0/F7rsoal0zz96qrBlQA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:cc:content-type; b=eY/HKM70bGt6YczS7Fp1A63MblHDg0dGGG4jKLYu2fs4vZUBV5CTl9JK1ZC7zNKVXb vBM9qY5oCT7pqTuwOhxA== Received: by 10.224.174.12 with SMTP id r12mr6531929qaz.109.1290580810231; Tue, 23 Nov 2010 22:40:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.159.66 with HTTP; Tue, 23 Nov 2010 22:39:50 -0800 (PST) From: Yuchung Cheng Date: Tue, 23 Nov 2010 22:39:50 -0800 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary=20cf303343dbbf6e170495c6c26b X-System-Of-Record: true Cc: tmrg@irtf.org Subject: [tcpm] References page of IW10 proposals X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 06:39:15 -0000 --20cf303343dbbf6e170495c6c26b Content-Type: text/plain; charset=ISO-8859-1 To make future references easier, I've created a page of the IW10 proposal(s) including previous IETF presenatations, papers, etc at http://code.google.com/speed/protocols/tcpm-IW10.html If you know other good references, please let me know. Cheers, Yuchung --20cf303343dbbf6e170495c6c26b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
To make future references easier, I've created a page of the IW10 = proposal(s) including previous IETF presenatations, papers, etc at
= http://co= de.google.com/speed/protocols/tcpm-IW10.html

If you know other good references, please let me know.<= /div>

Cheers,

Yuchung
--20cf303343dbbf6e170495c6c26b-- From hkchu@google.com Wed Nov 24 17:34:35 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8151C3A69DD for ; Wed, 24 Nov 2010 17:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.337 X-Spam-Level: X-Spam-Status: No, score=-108.337 tagged_above=-999 required=5 tests=[AWL=-1.483, BAYES_00=-2.599, FB_YOU_CAN_BECOME=1.258, FM_FORGED_GMAIL=0.622, FRT_LOLITA1=1.865, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSRV162-GNfw for ; Wed, 24 Nov 2010 17:34:20 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C48A43A69E2 for ; Wed, 24 Nov 2010 17:34:18 -0800 (PST) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id oAP1ZH8r018607 for ; Wed, 24 Nov 2010 17:35:17 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290648918; bh=2xz3gd7knTjqZtDqPCM/wlj8P5g=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=FvsXaqDOGfvD9t8JRdNofkzjgDTxFxrBlOqwisNoALE6WQVmN4foQQkvOblkT3dmQ jImhU0GiTkhjourXAuwQg== Received: from gyb11 (gyb11.prod.google.com [10.243.49.75]) by kpbe11.cbf.corp.google.com with ESMTP id oAP1ZF4S003626 for ; Wed, 24 Nov 2010 17:35:16 -0800 Received: by gyb11 with SMTP id 11so212070gyb.19 for ; Wed, 24 Nov 2010 17:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d032uAOAfQ2oZek/chZyPmLgBztMfumZajPd72cP2PU=; b=J/ZHvS1irFt/nN0KRC8UllazjmXjf1CCxxy0bZADdDRWvwYxYXI2LkHt3ndq7typJX 74eJe/QTTNzA3GRDe5Gg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kXYM5IizStOtotuBMlyAvhpJgln+EK4ysOpNpK8+AuofT6P1OvtI2aIKWjuXBsgx9K EVHSF2aAUzsXTIgLqCHQ== MIME-Version: 1.0 Received: by 10.151.158.7 with SMTP id k7mr2025612ybo.405.1290648914669; Wed, 24 Nov 2010 17:35:14 -0800 (PST) Received: by 10.151.158.13 with HTTP; Wed, 24 Nov 2010 17:35:14 -0800 (PST) In-Reply-To: References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> Date: Wed, 24 Nov 2010 17:35:14 -0800 Message-ID: From: Jerry Chu To: Andrew Yourtchenko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "Anantha Ramaiah \(ananth\)" , tcpm , David Borman , Joe Touch Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 01:34:36 -0000 On Thu, Nov 18, 2010 at 4:47 PM, Andrew Yourtchenko wr= ote: > > > On Thu, 18 Nov 2010, Joe Touch wrote: > >> That's basically what I'm suggesting; it can easily be per subnet, per >> interface, or per the entire machine as desired. >> >> The ultimate point is: >> >> =A0 =A0 =A0 =A0- put something in the end node that notices if/when >> =A0 =A0 =A0 =A0it fails objectively, and fixes it >> >> =A0 =A0 =A0 =A0- that same thing can allow the IW to increase >> =A0 =A0 =A0 =A0over time if there are no problems > > I think this is a very viable idea. > > However, I think there is a catch due to which it would need tweaking - > there should be a signaling mechanism whereby a node on the "conservative= " > side of the connection would be able to signal the node on the "eager" si= de > of the connection not to be too aggressive, in case the data flow is most= ly > from from "eager" to "conservative" side. > > One might consider the following model for a path: > > [peer A] --- [access A] ----- [ backbone ] ---- [access B] --- [peer B] > > Where the "access A" and "access B" are the access networks for the peers= , > and the "backbone" is the "big Internet" inbetween. > > I am speculating based on experience (please correct me if I am wrong) th= at > the congestion would typically be either in [access A] or [access B] clou= d. > > So in case peer B is a server then storing the losses about the connectio= ns > on a per-something basis would not be productive - because a connection f= rom > peer A may experience the congestion at access A, whereas connection from > peer C would not traverse the same access network - so there would not be= a > congestion. But cwnd in the long run would converge to the fair share bottleneck b/w regardless of whether the bottleneck is at the near end or the far end. (Guess I don't quite understand your use case.) > > OTOH if the congestion is in [access B] for both cases then storing the d= ata > in peer B would indeed make sense. > > If the above logic is right, then the peers during the 3whs should > communicate their memorized values and pick up the minimum of theirs and = the > communicated by the peer. There is already a mechanism through which a receiving peer can influence h= ow much data the send side can burst out. It's called the "advertised receive window". > > Therefore both parties know by the end of 3whs the IW value they are goin= g > to use - and can monitor the initial loss within the connection. > > If there happen to be a packet loss during the IW burst - both parties wi= ll > be aware of it. > > the result: whether there was a loss or not - will affect the party that = had > the smaller value to begin with - if there was no loss, it means that par= ty > can use larger value for subsequent connections *if* it had LOSS_THRESH > previous connections happen without the losses. If there was loss - that > party will use smaller value for subsequent connections. > > I've done a poor man's simulation program (attached) to experiment with t= his > idea - it seems more viable in terms of controlling the loss. It assumes = a > full mesh between 10 nodes with nodeX-nodeY backbone capacities potential= ly > unique. > > What's more entertaining with this approach is that with sufficiently lar= ge > value of LOSS_THRESH, it relatively converges *regardless* of the initial > setting for IW. > > You can run this code in the following way: > > 1) Assume access and backbone links can uniformly support IW=3D10, > nonadaptive: > > ./a.out 10 0 1000 10 11 10 11 | grep round > > ... > Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 > Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 > Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 > .... > > 2) Assume access and backbone links can uniformly support only IW=3D5, > nonadaptive: > > ./a.out 10 0 1000 5 6 5 6 | grep round > > Results from the round: loss: 500, headroom: 0, avg IW size: 10.000000 > Results from the round: loss: 500, headroom: 0, avg IW size: 10.000000 > Results from the round: loss: 500, headroom: 0, avg IW size: 10.000000 > > 3) same as (1), adaptive with the LOSS_THRESH=3D1000 and IW of 4: > > ./a.out 4 1 1000 10 11 10 11 | grep round > > Results from the round: loss: 2, headroom: 0, avg IW size: 10.020000 > Results from the round: loss: 1, headroom: 0, avg IW size: 10.010000 > Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 > Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 > > (loss fluctuates betweeen 0 and 2) > > 4) same as (2), same adaptive parameters as (3): > > ./a.out 4 1 1000 5 6 5 6 | grep round > > Results from the round: loss: 0, headroom: 0, avg IW size: 5.000000 > Results from the round: loss: 1, headroom: 0, avg IW size: 5.010000 > Results from the round: loss: 0, headroom: 0, avg IW size: 5.000000 > Results from the round: loss: 0, headroom: 0, avg IW size: 5.000000 > > On to fun stuff with nonuniform distributions: > > Assume access links can support 5..8, and backbone 8..15 > > 5) non-adaptive with IW=3D10: > > ./a.out 10 0 1000 5 8 8 15 | grep round > > Results from the round: loss: 434, headroom: 0, avg IW size: 10.000000 > Results from the round: loss: 423, headroom: 0, avg IW size: 10.000000 > Results from the round: loss: 415, headroom: 0, avg IW size: 10.000000 > > 6) non-adaptive with IW =3D 5: > > ./a.out 5 0 1000 5 8 8 15 | grep round > > Results from the round: loss: 0, headroom: 71, avg IW size: 5.000000 > Results from the round: loss: 0, headroom: 84, avg IW size: 5.000000 > Results from the round: loss: 0, headroom: 66, avg IW size: 5.000000 > > 7) adaptive with IW=3D10: > > ./a.out 10 1 1000 5 8 8 15 | grep round > > Results from the round: loss: 0, headroom: 12, avg IW size: 5.660000 > Results from the round: loss: 0, headroom: 11, avg IW size: 5.670000 > Results from the round: loss: 2, headroom: 13, avg IW size: 5.610000 > Results from the round: loss: 0, headroom: 26, avg IW size: 5.47000 > > 8) adaptive with IW=3D5: > > ./a.out 5 1 1000 5 8 8 15 | grep round > > Results from the round: loss: 0, headroom: 11, avg IW size: 5.550000 > Results from the round: loss: 0, headroom: 10, avg IW size: 5.670000 > Results from the round: loss: 1, headroom: 10, avg IW size: 5.750000 > Results from the round: loss: 0, headroom: 3, avg IW size: 5.810000 > Results from the round: loss: 2, headroom: 6, avg IW size: 5.800000 > Results from the round: loss: 2, headroom: 0, avg IW size: 5.670000 > > 9) (extreme:) - adaptive with IW=3D100: > > ./a.out 100 1 1000 5 8 8 15 | grep round > > Results from the round: loss: 0, headroom: 8, avg IW size: 5.550000 > Results from the round: loss: 0, headroom: 3, avg IW size: 5.600000 > Results from the round: loss: 0, headroom: 5, avg IW size: 5.68000 > > > 10) "conservative futuristic" - adaptive with IW=3D5, and access cap betw= een > 10 and 20 and backbone cap between 15 and 35: > > ./a.out 5 1 1000 10 20 15 35 | grep round > > Results from the round: loss: 0, headroom: 54, avg IW size: 14.200000 > Results from the round: loss: 0, headroom: 58, avg IW size: 13.750000 > Results from the round: loss: 0, headroom: 31, avg IW size: 13.470000 > Results from the round: loss: 0, headroom: 53, avg IW size: 13.860000 > Results from the round: loss: 0, headroom: 32, avg IW size: 13.590000 > Results from the round: loss: 0, headroom: 41, avg IW size: 13.790000 > Results from the round: loss: 0, headroom: 62, avg IW size: 14.290000 > > 11) same as (10), "badly converging" - the THRESH being 5: > > ./a.out 5 1 5 10 20 15 35 | grep round > > Results from the round: loss: 20, headroom: 13, avg IW size: 14.140000 > Results from the round: loss: 18, headroom: 9, avg IW size: 14.760000 > Results from the round: loss: 21, headroom: 4, avg IW size: 14.470000 > Results from the round: loss: 18, headroom: 6, avg IW size: 14.420000 > Results from the round: loss: 19, headroom: 11, avg IW size: 14.370000 > Results from the round: loss: 22, headroom: 11, avg IW size: 14.42000 > > 12) same as (10) with the fixed IW of 10, non-adaptive: > > ./a.out 10 0 5 10 20 15 35 | grep round > > Results from the round: loss: 0, headroom: 398, avg IW size: 10.000000 > Results from the round: loss: 0, headroom: 435, avg IW size: 10.000000 > Results from the round: loss: 0, headroom: 418, avg IW size: 10.000000 > Results from the round: loss: 0, headroom: 422, avg IW size: 10.000000 > > How to do the signaling during the 3whs is another story - might be eithe= r > an option or some tricks with the TCP window size in 3whs, so far I am no= t > talking about it. The additional signal, either explicitly through the previous TCP option space, or implicit through some window encoding (as you mentioned to me privately), seems to be adding unnecessary complexity hence violates our KISS principle IMHO. Just use the advertised receive window described above should achieve what you want, no? Jerry > > Critiques very welcome - as I said, it is a rather non-scientific simulat= ion > done in half an hour just to test the concept - you'll see some > "non-working" logic commented out in the code, maybe there is a better > approach. > > cheers, > andrew > > (also, the security side of things on this approach would need to be give= n a > thought. There are some interesting attacks lurking with all of the > "adaptive" logic.) > >> >> I'll be glad to write this up if people need a more concrete proposal. >> >> Joe >> >> On 11/18/2010 1:05 PM, Anantha Ramaiah (ananth) wrote: >>> >>> Why can't you do something like this : >>> >>> - If any one of the TCP connections egressing out of that interface >>> (this can determined in TCP layer) is in the TCP retransmit state (or >>> has experienced congestion in the past xxx secs/mins), then go back to = a >>> lower IW for new TCP connections which are using the same output >>> interface.. >>> >>> - When you want to start a connection, use the connection history (Joe'= s >>> RFC) >>> >>> Well, there may be some gotchas of this scheme, but you can become >>> conservative when there is some concrete information. >>> >>> Thanks, >>> -Anantha >>>> >>>> To be more clear, here's the case: >>>> >>>> =A0 =A0 =A0 =A0start 1000 connections in a row. >>>> >>>> =A0 =A0 =A0 =A0during the first connection, lose some packets and do >>>> =A0 =A0 =A0 =A0normal TCP backoff >>>> >>>> =A0 =A0 =A0 =A0so what do the other 999 connections start with? >>>> =A0 =A0 =A0 =A0ans: 10 packets >>>> >>>> The point is that subsequent connections don't do anything different. >>>> If >>>> you have 1000 connections, you're sending a certain amount of data >>> >>> into >>>> >>>> the network without reacting. We're tripling that. >>>> >>>> That can easily cause congestion. At which point the *existing* >>>> connections will backoff, but new connections keep making problems. >>>> >>>> Joe >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From ayourtch@cisco.com Wed Nov 24 18:35:10 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335EB28C222 for ; Wed, 24 Nov 2010 18:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_00=-2.599, FB_YOU_CAN_BECOME=1.258, FRT_LOLITA1=1.865] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh5SKNlWrW61 for ; Wed, 24 Nov 2010 18:35:08 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 1C34728C0ED for ; Wed, 24 Nov 2010 18:35:07 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAP2a3WN000584; Thu, 25 Nov 2010 03:36:03 +0100 (CET) Received: from sweet-brew-3.cisco.com (sweet-brew-3.cisco.com [144.254.10.204]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oAP2a3Vc028043; Thu, 25 Nov 2010 03:36:03 +0100 (CET) Date: Thu, 25 Nov 2010 03:36:03 +0100 (CET) From: Andrew Yourtchenko To: Jerry Chu In-Reply-To: Message-ID: References: <20101110152857.GA5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com> <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de> <931FAE2C-F66E-43B2-8EE1-CFEB17DABD5E@windriver.com> <7309FCBCAE981B43ABBE69B31C8D213909B72A7B1F@EUSAACMS0701.eamcs.ericsson.se> <36F89B79-EABA-4C38-A59E-023D9A630832@windriver.com> <4CE585E9.6060203@isi.edu> <6B25AF56-AFED-4085-AF42-F8AD47CB9F41@windriver.com> <4CE58FED.608@isi.edu> <0C53DCFB700D144284A584F54711EC580B36940A@xmb-sjc-21c.amer.cisco.com> <4CE595E3.3010109@isi.edu> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-758783491-1290652563=:2064" Cc: "Anantha Ramaiah \(ananth\)" , tcpm , David Borman , Joe Touch Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 02:35:10 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-758783491-1290652563=:2064 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Jerry, On Wed, 24 Nov 2010, Jerry Chu wrote: > On Thu, Nov 18, 2010 at 4:47 PM, Andrew Yourtchenko = wrote: >> >> >> On Thu, 18 Nov 2010, Joe Touch wrote: >> >>> That's basically what I'm suggesting; it can easily be per subnet, per >>> interface, or per the entire machine as desired. >>> >>> The ultimate point is: >>> >>> =A0 =A0 =A0 =A0- put something in the end node that notices if/when >>> =A0 =A0 =A0 =A0it fails objectively, and fixes it >>> >>> =A0 =A0 =A0 =A0- that same thing can allow the IW to increase >>> =A0 =A0 =A0 =A0over time if there are no problems >> >> I think this is a very viable idea. >> >> However, I think there is a catch due to which it would need tweaking - >> there should be a signaling mechanism whereby a node on the "conservativ= e" >> side of the connection would be able to signal the node on the "eager" s= ide >> of the connection not to be too aggressive, in case the data flow is mos= tly >> from from "eager" to "conservative" side. >> >> One might consider the following model for a path: >> >> [peer A] --- [access A] ----- [ backbone ] ---- [access B] --- [peer B] >> >> Where the "access A" and "access B" are the access networks for the peer= s, >> and the "backbone" is the "big Internet" inbetween. >> >> I am speculating based on experience (please correct me if I am wrong) t= hat >> the congestion would typically be either in [access A] or [access B] clo= ud. >> >> So in case peer B is a server then storing the losses about the connecti= ons >> on a per-something basis would not be productive - because a connection = from >> peer A may experience the congestion at access A, whereas connection fro= m >> peer C would not traverse the same access network - so there would not b= e a >> congestion. > > But cwnd in the long run would converge to the fair share bottleneck > b/w regardless > of whether the bottleneck is at the near end or the far end. (Guess I > don't quite > understand your use case.) yes. It's just that at least according to my experimentation that I=20 posted, picking the minimum between the two endpoints seems to provide a be= tter=20 approximation vs. picking just based on the knowledge of one endpoint vs. j= ust a constant. Of course it was only a rough sketch FWIW - I just wrote the code to test t= he=20 idea in principle. > >> >> OTOH if the congestion is in [access B] for both cases then storing the = data >> in peer B would indeed make sense. >> >> If the above logic is right, then the peers during the 3whs should >> communicate their memorized values and pick up the minimum of theirs and= the >> communicated by the peer. > > There is already a mechanism through which a receiving peer can influence= how > much data the send side can burst out. It's called the "advertised > receive window". Yeah - so in this case seems like we should just abandon the IW entirely an= d=20 just use the "advertised receive window" to begin with ? That seems fine to me except one would need to signal about their ability t= o=20 support new semantic. Of course, if we use it just as a clamping mechanism then no extra=20 signaling needed - but would be cool to not have to revisit this later with= the=20 new constant for IW. > >> >> Therefore both parties know by the end of 3whs the IW value they are goi= ng >> to use - and can monitor the initial loss within the connection. >> >> If there happen to be a packet loss during the IW burst - both parties w= ill >> be aware of it. >> >> the result: whether there was a loss or not - will affect the party that= had >> the smaller value to begin with - if there was no loss, it means that pa= rty >> can use larger value for subsequent connections *if* it had LOSS_THRESH >> previous connections happen without the losses. If there was loss - that >> party will use smaller value for subsequent connections. >> >> I've done a poor man's simulation program (attached) to experiment with = this >> idea - it seems more viable in terms of controlling the loss. It assumes= a >> full mesh between 10 nodes with nodeX-nodeY backbone capacities potentia= lly >> unique. >> >> What's more entertaining with this approach is that with sufficiently la= rge >> value of LOSS_THRESH, it relatively converges *regardless* of the initia= l >> setting for IW. >> >> You can run this code in the following way: >> >> 1) Assume access and backbone links can uniformly support IW=3D10, >> nonadaptive: >> >> ./a.out 10 0 1000 10 11 10 11 | grep round >> >> ... >> Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 >> Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 >> Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 >> .... >> >> 2) Assume access and backbone links can uniformly support only IW=3D5, >> nonadaptive: >> >> ./a.out 10 0 1000 5 6 5 6 | grep round >> >> Results from the round: loss: 500, headroom: 0, avg IW size: 10.000000 >> Results from the round: loss: 500, headroom: 0, avg IW size: 10.000000 >> Results from the round: loss: 500, headroom: 0, avg IW size: 10.000000 >> >> 3) same as (1), adaptive with the LOSS_THRESH=3D1000 and IW of 4: >> >> ./a.out 4 1 1000 10 11 10 11 | grep round >> >> Results from the round: loss: 2, headroom: 0, avg IW size: 10.020000 >> Results from the round: loss: 1, headroom: 0, avg IW size: 10.010000 >> Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 >> Results from the round: loss: 0, headroom: 0, avg IW size: 10.000000 >> >> (loss fluctuates betweeen 0 and 2) >> >> 4) same as (2), same adaptive parameters as (3): >> >> ./a.out 4 1 1000 5 6 5 6 | grep round >> >> Results from the round: loss: 0, headroom: 0, avg IW size: 5.000000 >> Results from the round: loss: 1, headroom: 0, avg IW size: 5.010000 >> Results from the round: loss: 0, headroom: 0, avg IW size: 5.000000 >> Results from the round: loss: 0, headroom: 0, avg IW size: 5.000000 >> >> On to fun stuff with nonuniform distributions: >> >> Assume access links can support 5..8, and backbone 8..15 >> >> 5) non-adaptive with IW=3D10: >> >> ./a.out 10 0 1000 5 8 8 15 | grep round >> >> Results from the round: loss: 434, headroom: 0, avg IW size: 10.000000 >> Results from the round: loss: 423, headroom: 0, avg IW size: 10.000000 >> Results from the round: loss: 415, headroom: 0, avg IW size: 10.000000 >> >> 6) non-adaptive with IW =3D 5: >> >> ./a.out 5 0 1000 5 8 8 15 | grep round >> >> Results from the round: loss: 0, headroom: 71, avg IW size: 5.000000 >> Results from the round: loss: 0, headroom: 84, avg IW size: 5.000000 >> Results from the round: loss: 0, headroom: 66, avg IW size: 5.000000 >> >> 7) adaptive with IW=3D10: >> >> ./a.out 10 1 1000 5 8 8 15 | grep round >> >> Results from the round: loss: 0, headroom: 12, avg IW size: 5.660000 >> Results from the round: loss: 0, headroom: 11, avg IW size: 5.670000 >> Results from the round: loss: 2, headroom: 13, avg IW size: 5.610000 >> Results from the round: loss: 0, headroom: 26, avg IW size: 5.47000 >> >> 8) adaptive with IW=3D5: >> >> ./a.out 5 1 1000 5 8 8 15 | grep round >> >> Results from the round: loss: 0, headroom: 11, avg IW size: 5.550000 >> Results from the round: loss: 0, headroom: 10, avg IW size: 5.670000 >> Results from the round: loss: 1, headroom: 10, avg IW size: 5.750000 >> Results from the round: loss: 0, headroom: 3, avg IW size: 5.810000 >> Results from the round: loss: 2, headroom: 6, avg IW size: 5.800000 >> Results from the round: loss: 2, headroom: 0, avg IW size: 5.670000 >> >> 9) (extreme:) - adaptive with IW=3D100: >> >> ./a.out 100 1 1000 5 8 8 15 | grep round >> >> Results from the round: loss: 0, headroom: 8, avg IW size: 5.550000 >> Results from the round: loss: 0, headroom: 3, avg IW size: 5.600000 >> Results from the round: loss: 0, headroom: 5, avg IW size: 5.68000 >> >> >> 10) "conservative futuristic" - adaptive with IW=3D5, and access cap bet= ween >> 10 and 20 and backbone cap between 15 and 35: >> >> ./a.out 5 1 1000 10 20 15 35 | grep round >> >> Results from the round: loss: 0, headroom: 54, avg IW size: 14.200000 >> Results from the round: loss: 0, headroom: 58, avg IW size: 13.750000 >> Results from the round: loss: 0, headroom: 31, avg IW size: 13.470000 >> Results from the round: loss: 0, headroom: 53, avg IW size: 13.860000 >> Results from the round: loss: 0, headroom: 32, avg IW size: 13.590000 >> Results from the round: loss: 0, headroom: 41, avg IW size: 13.790000 >> Results from the round: loss: 0, headroom: 62, avg IW size: 14.290000 >> >> 11) same as (10), "badly converging" - the THRESH being 5: >> >> ./a.out 5 1 5 10 20 15 35 | grep round >> >> Results from the round: loss: 20, headroom: 13, avg IW size: 14.140000 >> Results from the round: loss: 18, headroom: 9, avg IW size: 14.760000 >> Results from the round: loss: 21, headroom: 4, avg IW size: 14.470000 >> Results from the round: loss: 18, headroom: 6, avg IW size: 14.420000 >> Results from the round: loss: 19, headroom: 11, avg IW size: 14.370000 >> Results from the round: loss: 22, headroom: 11, avg IW size: 14.42000 >> >> 12) same as (10) with the fixed IW of 10, non-adaptive: >> >> ./a.out 10 0 5 10 20 15 35 | grep round >> >> Results from the round: loss: 0, headroom: 398, avg IW size: 10.000000 >> Results from the round: loss: 0, headroom: 435, avg IW size: 10.000000 >> Results from the round: loss: 0, headroom: 418, avg IW size: 10.000000 >> Results from the round: loss: 0, headroom: 422, avg IW size: 10.000000 >> >> How to do the signaling during the 3whs is another story - might be eith= er >> an option or some tricks with the TCP window size in 3whs, so far I am n= ot >> talking about it. > > The additional signal, either explicitly through the previous TCP option > space, or implicit through some window encoding (as you mentioned to me > privately), seems to be adding unnecessary complexity hence violates our > KISS principle IMHO. Just use the advertised receive window described > above should achieve what you want, no? It could. The code I played with did not include any specifics on how it is= =20 communicated. The main idea was to see what happens if two parties can agre= e on=20 an IW during the 3WHS. This can certainly be derived from the advertised wi= ndow=20 size within SYN segments, except one would need a way to figure out which= =20 semantic to use. Which implies to me *some* way of signaling. One can set the window value i= n the=20 segments to be an odd number, for example. (again this goes about the case = of=20 'no upper limit' negotiation. If we talk merely about clamping, the above= =20 argument is null). cheers, andrew > > Jerry > >> >> Critiques very welcome - as I said, it is a rather non-scientific simula= tion >> done in half an hour just to test the concept - you'll see some >> "non-working" logic commented out in the code, maybe there is a better >> approach. >> >> cheers, >> andrew >> >> (also, the security side of things on this approach would need to be giv= en a >> thought. There are some interesting attacks lurking with all of the >> "adaptive" logic.) >> >>> >>> I'll be glad to write this up if people need a more concrete proposal. >>> >>> Joe >>> >>> On 11/18/2010 1:05 PM, Anantha Ramaiah (ananth) wrote: >>>> >>>> Why can't you do something like this : >>>> >>>> - If any one of the TCP connections egressing out of that interface >>>> (this can determined in TCP layer) is in the TCP retransmit state (or >>>> has experienced congestion in the past xxx secs/mins), then go back to= a >>>> lower IW for new TCP connections which are using the same output >>>> interface.. >>>> >>>> - When you want to start a connection, use the connection history (Joe= 's >>>> RFC) >>>> >>>> Well, there may be some gotchas of this scheme, but you can become >>>> conservative when there is some concrete information. >>>> >>>> Thanks, >>>> -Anantha >>>>> >>>>> To be more clear, here's the case: >>>>> >>>>> =A0 =A0 =A0 =A0start 1000 connections in a row. >>>>> >>>>> =A0 =A0 =A0 =A0during the first connection, lose some packets and do >>>>> =A0 =A0 =A0 =A0normal TCP backoff >>>>> >>>>> =A0 =A0 =A0 =A0so what do the other 999 connections start with? >>>>> =A0 =A0 =A0 =A0ans: 10 packets >>>>> >>>>> The point is that subsequent connections don't do anything different. >>>>> If >>>>> you have 1000 connections, you're sending a certain amount of data >>>> >>>> into >>>>> >>>>> the network without reacting. We're tripling that. >>>>> >>>>> That can easily cause congestion. At which point the *existing* >>>>> connections will backoff, but new connections keep making problems. >>>>> >>>>> Joe >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> > ---559023410-758783491-1290652563=:2064-- From hkchu@google.com Thu Nov 25 13:26:05 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1455B3A68DC for ; Thu, 25 Nov 2010 13:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.764 X-Spam-Level: X-Spam-Status: No, score=-109.764 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJDn4j8qTXtl for ; Thu, 25 Nov 2010 13:26:04 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A739A3A6A6D for ; Thu, 25 Nov 2010 13:26:03 -0800 (PST) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id oAPLR4qv010728 for ; Thu, 25 Nov 2010 13:27:04 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290720425; bh=qUlkwgMeRTQiV2hdh10TfLTEldY=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=W3CqMq9ULL3NIKWvQud5RlTaoKrSDXShurkW9MrmfKnkDNgA05KI89h0pO6yIuyq1 Ju0OjeYiPdipgvRf35kxg== Received: from yxl31 (yxl31.prod.google.com [10.190.3.223]) by kpbe12.cbf.corp.google.com with ESMTP id oAPLR3jP001146 for ; Thu, 25 Nov 2010 13:27:03 -0800 Received: by yxl31 with SMTP id 31so717468yxl.14 for ; Thu, 25 Nov 2010 13:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=pWezWCISZpW+DpqUb+Yq8mgU1CBP7MOOcAS5QmtjK80=; b=B8bYoNjgCDRGgx2Jx9zeiDIHcxf8E/jf+IFDxx0LL8S4Ys9+KpKQyF9aFi8Dqhs7d2 3HGH8qF9fJKn5NYHrpFA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ps4LSgKH85ZKLMqsUi26oquRdYI7UtbzQn0eWlGJOu+gKc8I5KP7OflD9CYNgnE1ZM t589Kf2oa4EqEGRfstPQ== MIME-Version: 1.0 Received: by 10.150.217.6 with SMTP id p6mr3892309ybg.63.1290720420856; Thu, 25 Nov 2010 13:27:00 -0800 (PST) Received: by 10.151.158.13 with HTTP; Thu, 25 Nov 2010 13:27:00 -0800 (PST) Date: Thu, 25 Nov 2010 13:27:00 -0800 Message-ID: From: Jerry Chu To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [tcpm] response to questions raised at Beijing's meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 21:26:05 -0000 I have not seen the meeting minutes but two questions were raised during the just passed IETF meeting, one from Lars on whether the User Completion Time (UCT) as reported from our testbed includes time spent on 3WHS, the other on whether raw test data from our testbed can be made available. The answer to the 1st question is No, our UCT does not include 3WHS. If this is believed to be important we can certainly rerun tests to include 3WHS. The answer to the 2nd question is Yes, and we have made the raw data available for download from http://research.csc.ncsu.edu/netsrv/?q=content/iw10 Unfortunately the set of raw data does NOT include tcpdump traces due to the sheer sizes. If you really want the packet traces we can certainly rerun tests to collect them. But we'll probably need to find a way to host the possibly voluminous data more efficiently. BTW, the above mentioned web page contains all the info about the testbed hosted by NCSU and parameters used in our tests. If you'd like to see a different set of parameters being used just let us know. But please apply good judgement as we can only accommodate a limited number of test requests due to time constraint. (Dr. Idris Rai has questioned the use of 40 pkt buffer being too large. But as others pointed out that size is not unreasonable. Also we've found out a buffer pool smaller than 40 can cause severe performance (response time) degradation even for IW3. Thanks, Jerry From rs@netapp.com Thu Nov 25 17:26:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226D43A6AEC for ; Thu, 25 Nov 2010 17:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.938 X-Spam-Level: X-Spam-Status: No, score=-8.938 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_50=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv-ya51GZJbN for ; Thu, 25 Nov 2010 17:26:44 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id D13B63A6A9E for ; Thu, 25 Nov 2010 17:26:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,258,1288594800"; d="scan'208";a="227965676" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 25 Nov 2010 17:27:43 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oAQ1ReLb000756; Thu, 25 Nov 2010 17:27:41 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Nov 2010 01:27:40 +0000 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: Fri, 26 Nov 2010 01:27:38 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0B9AD5FE@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <201003221915.UAA02621@TR-Sys.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-ietf-tcpm-1323bis Thread-Index: AcrJ9D82AnH7H+TmTqCH5lJNlBbjGjDEf+Ww References: <201003221915.UAA02621@TR-Sys.de> From: "Scheffenegger, Richard" To: "David Borman" , , X-OriginalArrivalTime: 26 Nov 2010 01:27:40.0875 (UTC) FILETIME=[1E0F91B0:01CB8D09] Cc: =?utf-8?B?QWxmcmVkIEjDjm5lcw==?= , tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] draft-ietf-tcpm-1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 01:26:48 -0000 DQogQm9iLCBEYXZlLCBWYW4sIEdyb3VwLA0KDQpJcyB0aGlzIFdHIEl0ZW0gc3RpbGwgYWxpdmU/ DQoNCkkgd291bGQgYmUgaW50ZXJlc3RlZCBpbiB5b3VyIG9waW5pb24gb2YgaG93IHRvIGFkZHJl c3Mgc29tZSBwb3RlbnRpYWwgb3B0aW1pemF0aW9ucyBpbiB0aGUgVGltZXN0YW1wIGFsZ29yaXRo bSBhbmQgUlRUIE1lYXN1cmVtZW50LCB3aGVuIG9uZSB0YWtlcyBTQUNLIGludGVyYWN0aW9ucyBp bnRvIGFjY291bnQuDQoNCg0KTW9yZSBzcGVjaWZpY2FsbHksIEkgZmluYWxseSBmb3VuZCB0aGUg b3JpZ2luYWwgZGlzY3Vzc2lvbiB3aGljaCBleHBsYWlucyB3aHkgUkZDMTMyMyhiaXMpIGhhcyB0 aGUgcmVxdWlyZW1lbnQgb24gYm90aCBTZW5kZXIgYW5kIFJlY2VpdmVyIHRvIGEpIHJlZmxlY3Qg b25seSB2ZXJ5IHNwZWNpZmljIHRpbWVzdGFtcHMsIGFuZCBiKSBvbmx5IG1ha2UgdXNlIG9mIHRo ZXNlIHVuZGVyIHZlcnkgY2VydGFpbiBjaXJjdW1zdGFuY2VzLg0KDQpIb3dldmVyLCBpZiB0aGUg c2VuZGVyIGFsc28gdGFrZXMgYXZhaWxhYmxlIFNBQ0sgaW5mb3JtYXRpb24gaW50byBhY2NvdW50 LCBzb21lIG9mIHRoZXNlIHJlc3RyaWN0aW9ucyBhcmUgbGlmdGVkLCBhbmQgdGhhdCBtYXkgaW4g dHVybiBhbGxvdyBpbXByb3ZlZCBSVFRNIChlc3BlY2lhbGx5IGR1cmluZyBhIHdpbmRvdyBjb250 YWluaW5nIGxvc3MgLSB2ZXJ5IGxpa2VseSBzaG93aW5nIGhpZ2hlciBsYXRlbmNpZXMgdGhhbiBk dXJpbmcgaW4tc2VxdWVuY2UgZGVsaXZlcnkpLCBhbmQgYWxzbyBpbXByb3ZlZCBTQUNLIHJlY292 ZXJ5IHdoaWxlIHN0cmljdGx5IGFkaGVyaW5nIHRvIHBhY2tldCBjb25zZXJ2YXRpb24uDQoNCg0K DQpCZXN0IHJlZ2FyZHMsDQoNClJpY2hhcmQgU2NoZWZmZW5lZ2dlcg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQpGcm9tIGJyYWRlbiAgTW9uIEF1ZyAxOSAxNzoyMjo0NSAxOTkxDQpS ZWNlaXZlZDogZnJvbSBicmFkZW4uaXNpLmVkdSBieSB2ZW5lcmEuaXNpLmVkdSAoNS42MS81LjYx K2xvY2FsLTMpDQoJaWQgPEFBMTgzMjI+OyBNb24sIDE5IEF1ZyA5MSAxNzoyMjo0NSAtMDcwMA0K RGF0ZTogTW9uLCAxOSBBdWcgOTEgMTc6MjE6MzggUERUDQpGcm9tOiBicmFkZW4NClBvc3RlZC1E YXRlOiBNb24sIDE5IEF1ZyA5MSAxNzoyMTozOCBQRFQNCk1lc3NhZ2UtSWQ6IDw5MTA4MjAwMDIx LkFBMTEzMzJAYnJhZGVuLmlzaS5lZHU+DQpSZWNlaXZlZDogYnkgYnJhZGVuLmlzaS5lZHUgKDQu MC80LjAuMy00KQ0KCWlkIDxBQTExMzMyPjsgTW9uLCAxOSBBdWcgOTEgMTc6MjE6MzggUERUDQpU bzogZW5kMmVuZC1pbnRlcmVzdA0KU3ViamVjdDogUkZDLTEwNzINCg0KRm9sa3MsDQoNClJlY2Vu dGx5IHdlIChWYW4sIERhdmUgQm9ybWFuLCBhbmQgSSkgaGF2ZSBiZWVuIGRpc2N1c3Npbmcgc29t ZSBkZXRhaWxzDQpvZiB0aGUgdGltZXN0YW1wIGVjaG8gbWVjaGFuaXNtIG9mIFJGQy0xMDcyLiAN Cg0KVGhlcmUgaXMgY29uc2lkZXJhYmxlIHByZXNzdXJlIHRvIGVudGVyIFJGQy0xMDcyIGFuZCBS RkMtMTE4NSBpbnRvIHRoZQ0KSW50ZXJuZXQgc3RhbmRhcmRzIHRyYWNrLCBidXQgSSByZWNlbnRs eSBub3RpY2VkIHNvbWUgYW1iaWd1aXRpZXMgYW5kDQpvbWlzc2lvbnMuICBVcG9uIGZ1cnRoZXIg ZGlzY3Vzc2lvbiB3aXRoIFZhbiwgSSBkaXNjb3ZlcmVkIHRoYXQgaGlzDQppbXBsZW1lbnRhdGlv biB2aW9sYXRlcyBteSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgUkZDLTEwNzIgbWVhbnQuDQoNCkkg dGhvdWdodCB0aGlzIHRvcGljIG91Z2h0IG1pZ2h0IGJlIG9mIHdpZGVyIGludGVyZXN0LCBzbyBJ IGFtIGZvcndhcmRpbmcNCnRoZSBzdHJpbmcgb2YgcmVsZXZhbnQgbWVzc2FnZXMuICBXZSBtaWdo dCB0YWxrIGFib3V0IGl0IGluIFN0b2NraG9sbS4NCg0KDQpCb2INCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpbW0kgaGF2ZSByZWNlbnRseSBub3RpY2VkIHRoYXQgUkZDLTEwNzIgZGlkIG5vdCBl eHBsYWluIGhvdyB0byBwcmV2ZW50IG9sZA0KZHVwbGljYXRlIEFDS3MgZnJvbSBmYWxsaW5nIGlu dG8gdGhlIGN1cnJlbnQgd2luZG93IGFmdGVyIHNlcXVlbmNlIG51bWJlcg0Kd3JhcC1hcm91bmQu ICBJIGRpc2N1c3NlZCB0aGlzIHdpdGggVmFuIGF0IHRoZSBHaWdhYml0cyBtZWV0aW5nLCBhbmQg aGUNCnNhaWQgaGUgd2FudHMgdG8gc2VuZCB0aW1lc3RhbXBzIG9uIEFDS3MgYXMgd2VsbCBhcyBk YXRhIHNlZ21lbnRzLg0KVGhlbiBJIHdyb3RlOl1dDQoNCkZyb20gYnJhZGVuQElTSS5FRFUgRnJp IEF1ZyAgOSAxNDo0ODoxOSAxOTkxDQpEYXRlOiBGcmksIDkgQXVnIDkxIDE0OjQ3OjUyIFBEVA0K RnJvbTogYnJhZGVuQElTSS5FRFUNClRvOiBkYWJAY3JheS5jb20sIHZhbkBoZWxpb3MuZWUubGJs Lmdvdg0KU3ViamVjdDogUkZDLTEwNzIgJiBSRkMtMTE4NQ0KQ2M6IGJyYWRlbkBJU0kuRURVLCBw b3N0ZWxASVNJLkVEVQ0KDQpGcmllbmRzLA0KDQpUaGUgaXNzdWUgb2Ygd2hldGhlciBvciBub3Qg dG8gaW5jbHVkZSBUQ1AgRWNobyBvcHRpb25zIG9uIEFDSyBzZWdtZW50cw0KcGVyIFJGQy0xMTg1 IG1hZGUgbWUgYXdhcmUgdGhhdCB0aGVyZSBhcmUgb3RoZXIgYW1iaWd1aXRpZXMgaW4gdGhlc2UN ClJGQ3MuICBTaW5jZSB0aGUgSUVTRyBub3cgd2FudHMgdG8gbWFrZSB0aGVtIEludGVybmV0IHN0 YW5kYXJkcywgd2UNCm91Z2h0IHRvIHJlbW92ZSBhbWJpZ3VpdGllcy4NCg0KVG8gdGhpcyBlbmQs IEkgaGF2ZSB3cml0dGVuIGRvd24gdHdvIGRlc2NyaXB0aW9ucyBvZiB0aGUgYWxnb3JpdGhtcy4N ClRoZSBmaXJzdCBpbiBpbiBwc3VlZG8tY29kZTsgdGhlIHNlY29uZCBpcyBhcyBhIGRlbHRhIG9u IFJGQy03OTMNCnNlY3Rpb24gMy45IEV2ZW50IFByb2Nlc3NpbmcuICBJIHdvdWxkIGFwcHJlY2lh dGUgeW91ciBsb29raW5nIHRoaXMNCm92ZXIgY2FyZWZ1bGx5LCB0byBzZWUgd2hldGhlciBpdCBh Z3JlZXMgd2l0aCB5b3VyIHVuZGVyc3RhbmRpbmcuDQoNCk9uZSBuZXcgaXNzdWUgdGhhdCBjYW1l IHVwOiBXaGVuIFRDUCByZWNlaXZlcyBhIGRhdGEgc2VnbWVudCBvdXRzaWRlDQp0aGUgd2luZG93 LCBpdCBzZW5kcyBhbiBBQ0sgZm9yIHRoZSBjdXJyZW50IHdpbmRvdyBpbiByZXBseS4gIFF1ZXN0 aW9uOg0Kc2hvdWxkIHRoaXMgdGltZXN0YW1wIGVjaG8gdGhlIHRpbWVzdGFtcCBmcm9tIHRoZSAo b2xkIGR1cGxpY2F0ZSkNCmRhdGEgc2VnbWVudD8gIChUaGUgY29kZSBhcyB3cml0dGVuIGhlcmUg ZG9lcyBzZW5kIGl0KS4NCg0KQm9iDQoNCltbdGV4dCBkZWxldGVkIGFzIGltbWF0ZXJpYWwgdG8g dGhpcyB0aHJlYWQuICBEYXZlIEJvcm1hbiBhY3R1YWxseSByZWFkDQpteSBwc2V1ZG8tY29kZSBh bmQgcG9pbnRlZCBvdXQgc29tZSBidWdzLl1dDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KW1tW YW4gY2FsbGVkIG1lIGFuZCB3ZSBkaXNjdXNzZWQgaGlzIGltcGxlbWVudGF0aW9uIG9mIFJGQy0x MDcyIGluDQp0aGUgREFSVG5ldCBUQ1AsIHdoaWNoIGRpZCBub3Qgc2VlbSB0byBtZSB0byBtYXRj aCBSRkMtMTA3Mi4gIFZhbg0Kd2FzIHRyeWluZyB0byBwZXJzdWFkZSBtZSB0aGF0IGl0IHdhcyBs b2dpY2FsbHkgZXF1aXZhbGVudCwganVzdA0KaW1wbGVtZW50ZWQgZGlmZmVyZW50bHldXQ0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbSB2YW5AZWUubGJsLmdvdiBNb24gQXVnIDEyIDE1OjU3 OjE4IDE5OTENClRvOiBicmFkZW5ASVNJLkVEVQ0KU3ViamVjdDogUmU6IFJGQy0xMDcyOiB0aW1l c3RhbXBzIGFuZCBhIGJpdCBmbGFnIA0KSW4tUmVwbHktVG86IFlvdXIgbWVzc2FnZSBvZiBTdW4s IDExIEF1ZyA5MSAxNjozMDo0MyBQRFQuDQpEYXRlOiBNb24sIDEyIEF1ZyA5MSAxNTo1NzozMSBQ RFQNCkZyb206IFZhbiBKYWNvYnNvbiA8dmFuQGVlLmxibC5nb3Y+DQoNCkJvYiwNCg0KSSB3YXMg YW1iaWd1b3VzIG9uIHRoZSBwaG9uZS4gIERlcGVuZGluZyBvbiB3aGVyZSBpbiB0aGUgcGF0aA0K eW91IHNpdCwgdGhlcmUgYXJlIGRpZmZlcmVudCBsZWZ0IGVkZ2VzIG9mIHRoZSB3aW5kb3cuICBC U0QNCnRyYWNrcyBib3RoIHRoZSAncmVjZWl2ZXInIGxlZnQgZWRnZSAocmVsYXRpdmUgdG8gcmN2 X254dCkgYW5kDQp0aGUgJ2xlZnQgZWRnZSBrbm93biB0byBwZWVyJyAocmVsYXRpdmUgdG8gdGhl IGFjayBudW1iZXIgaW4gdGhlDQpsYXN0IHBhY2tldCB5b3Ugc2VudCkuICBUaGUgbGF0dGVyIHZp ZXcgaXMgdXNlZCBhcyBwYXJ0IG9mIHRoZQ0KcmN2ciBzaWxseS13aW5kb3cgYXZvaWRhbmNlIHRv IHByZXZlbnQgd2luZG93IGFkdmVydGlzbWVudHMgdGhhdA0KcmV0cmFjdCB0aGUgd2luZG93LiAg V2UgaGF2ZSBhIHJlY2VpdmVyIHN0YXRlIHZhcmlhYmxlLCByY3ZfYWNrZWQsDQp0aGF0IHRyYWNr cyB0aGUgbGFzdCBzZXF1ZW5jZSBudW1iZXIgYWNrZWQuICAoRS5nLiwgd2hlbiBhDQpwYWNrZXQg aXMgc2VudCByY3ZfYWNrZWQgaXMgdXBkYXRlZCBmcm9tIHNlZ19hY2suICBJbiBlYXJsaWVyDQp2 ZXJzaW9ucyBvZiBCU0QgYW4gZXF1aXZhbGVudCB2YXJpYWJsZSwgcmN2X2FkdiwgdHJhY2tlZCB0 aGUgZW5kDQpvZiB0aGUgd2luZG93LiAgSW4gNC40LCBJIHJlYWxpemVkIHRoYXQgdGhlIGNvZGUg Z290IHNpbXBsZXIgaWYNCnlvdSB0cmFja2VkIHRoZSBiZWdpbm5pbmcuKSAgU28sIHRoZSB0aW1l c3RhbXAgdGVzdCB3ZSBkbyBpbg0KdGNwX2lucHV0IGlzDQoNCglpZiAodGktPnRpX3NlcSA9PSB0 cC0+cmN2X2Fja2VkKQ0KCQkvKg0KCQkgKiB0aGlzIHNlZ21lbnQgYXQgbGVmdCBlZGdlIG9mIHdp bmRvdyBrbm93IHRvIHBlZXIuDQoJCSAqIHJlY29yZCBpdHMgdGltZXN0YW1wIGZvciBlY2hvIHJl cGx5IGFuZA0KCQkgKiBpbmNvbWluZyB2YWxpZGl0eSBjaGVja2luZyAocGVyIHJmYzEwNzIgJiAx MTg1KS4NCgkJICovDQoJCXRwLT5yY3ZfdHN0YW1wID0gdHN0YW1wOw0KDQooVGhlcmUgYXJlIGVh cmxpZXIgdmFsaWRpdHkgY2hlY2tzLCBpbmNsdWRpbmcgdGVzdGluZyB0aGUNCmluY29taW5nIHRp bWVzdGFtcCBhZ2FpbnN0IHRwLT5yY3ZfdHN0YW1wIHNvIHdlJ3JlIHN1cmUgYXQgdGhpcw0KcG9p bnQgdGhhdCB0aGUgaW5jb21pbmcgc2VnbWVudCBpcyBsZWdhbCAmICdyZWNlbnQnLikgIFRoaXMN CmhhbmRsZXMgYm90aCBkZWxheWVkIGFja3MgJiByZXRyYW5zbWl0cy4gIEkgYmVsaWV2ZSBpdCBk b2VzIGp1c3QNCndoYXQgMTA3MiB3YW50cy4NCg0KIC0gVmFuDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJv bSBicmFkZW5ASVNJLkVEVSBNb24gQXVnIDEyIDE2OjQ1OjMwIDE5OTENCkRhdGU6IE1vbiwgMTIg QXVnIDkxIDE2OjQ1OjE1IFBEVA0KRnJvbTogYnJhZGVuQElTSS5FRFUNClRvOiB2YW5AZWUubGJs Lmdvdg0KU3ViamVjdDogUmU6IFJGQy0xMDcyOiB0aW1lc3RhbXBzIGFuZCBhIGJpdCBmbGFnDQpD YzogYnJhZGVuQElTSS5FRFUNCg0KSSBkb24ndCB0aGluayB5b3VyIHRyaWNrIHdpbGwgd29yayBm b3IgY2FzZSAoQikgb24gcGFnZSAxMyBvZiBSRkMtMTA3MjoNCiJBIGhvbGUgaW4gdGhlIHNlcXVl bmNlIHNwYWNlIi4gIEl0IGdvZXMgb24gYWJvdXQgaG93IHZhbHVhYmxlIGl0IGlzDQp0byBoYXZl IFJUVCdzIGZvciBBQ0tzIHJlc3VsdGluZyBmcm9tIG91dC1vZi1vcmRlciBzZWdtZW50cy4gIElm IEkNCnVuZGVyc3RhbmQgeW91ciBtZXNzYWdlLCBub25lIG9mIHRoZSBvdXQtb2Ytb3JkZXIgc2Vn bWVudHMgd2lsbA0KdXBkYXRlIHJjdl90c3RhbXAsIHNvIHRoZSByZXN1bHRpbmcgQUNLcyB3aWxs IGFsbCBlY2hvIHRoZSBzYW1lDQp0aW1lc3RhbXAgdmFsdWUuICBJcyB0aGlzIHJlYWxseSB3aGF0 IHlvdSB3YW50Pz8NCg0KQS4xIC0tLT4gKHNldHMgdHN0YW1wKTsgQiBpcyBsb3N0DQpDLjMgLS0t Pg0KIDwtLSBBQ0sgQS4xDQpELjQgLS0tPg0KICA8LS0gQUNLIEEuMQ0KRS41IC0tLT4NCiAgPC0t IEFDSyBBLjENCkIuNiAtLS0+DQogIDwtLSBBQ0sgRS42DQogIA0KUmlnaHQ/DQoNCiAgIEJvYg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb20gYnJhZGVuQElTSS5FRFUgVHVlIEF1ZyAxMyAxNzowMDo1 OCAxOTkxDQpEYXRlOiBUdWUsIDEzIEF1ZyA5MSAxNzowMDoyMyBQRFQNCkZyb206IGJyYWRlbkBJ U0kuRURVDQpUbzogdmFuQGhlbGlvcy5lZS5sYmwuZ292DQpTdWJqZWN0OiBGb3IgZGlzY3Vzc2lv bi4uLg0KQ2M6IGJyYWRlbkBJU0kuRURVLCBkYWJAY3JheS5jb20NCg0KSGVyZSBpcyB3aGF0IEkg dGhpbmsgUkZDLTEwNzIgYW5kIFJGQy0xMTg1IGltcGx5IHNob3VsZCBoYXBwZW46DQoNCiBBc3N1 bWUgc2VxdWVuY2Ugb2YgZGF0YSBzZWdtZW50cyBBLCBCLCBDLCAuLi4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBS ZWNlaXZlciBkb2VzIFJGQy0xMTg1IFRpbWVzdGFtcA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgY29tcGFyaXNvbiBhZ2FpbnN0IHZhbHVlOg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBWDQogICAgPEEsRUNvcHQ9MT4gLS0tLS0tLS0tLS0tLS0tLS0tLS0+ ICAgIDAgKHNheSkgICAgDQogICAgPEIsRUNvcHQ9Mj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0+ICAg IDEgICAgDQogICAgICAgICAgICAgICAgIDwtLS0tIDxBQ0soQiksRUNSb3B0PTE+ICAgIA0KICAg IDxDLEVDb3B0PTM+IC0tLS0tLT4gKGxvc3QpICAgIA0KICAgIDxELEVDb3B0PTQ+IC0tLS0tLS0t LS0tLS0tLS0tLS0tPiAgICAxICAgDQogICAgICAgICAgICAgICAgPC0tLS0tIDxBQ0soQiksRUNS b3B0PTQ+DQogICAocmV0cmFuc21pdCBDKQ0KICAgIDxDLEVDb3B0PTU+IC0tLS0tLS0tLS0tLS0t LS0tLS0+ICAgICAxICAgDQogICAgICAgICAgICAgICAgPC0tLS0tLSA8QUNLKEQpLEVDUm9wdD01 DQogICAgICAgICAgICAgICANCk5vdywgSSBiZWxpZXZlIHlvdXIgY29kZSB3b3VsZCBkbyB0aGUg Zm9sbG93aW5nIHdpdGggdGhlIHNhbWUgc2VxdWVuY2U6DQoNCiAgICA8QSxFQ29wdD0xPiAtLS0t LS0tLS0tLS0tLS0tLS0tLT4gICAgMCAoc2F5KSAgICANCiAgICA8QixFQ29wdD0yPiAtLS0tLS0t LS0tLS0tLS0tLS0tLT4gICAgMSAgIA0KICAgICAgICAgICAgICAgICA8LS0tLSA8QUNLKEIpLEVD Um9wdD0xPiAgICAgDQogICAgPEMsRUNvcHQ9Mz4gLS0tLS0tLS0tLT4gKGxvc3QpICAgIA0KICAg IDxELEVDb3B0PTQ+IC0tLS0tLS0tLS0tLS0tLS0tLS0tPiAgICAxICAgIA0KICAgICAgICAgICAg ICAgIDwtLS0tLSA8QUNLKEIpLEVDUm9wdD0xPg0KICAgKHJldHJhbnNtaXQpDQogICAgPEMsRUNv cHQ9NT4gLS0tLS0tLS0tLS0tLS0tLS0tLT4gICAgIDENCiAgICAgICAgICAgICAgICAgIDwtLS0t LS0gPEFDSyhEKSxFQ1JvcHQ9NQ0KDQpEYXZlLCBJIHdvdWxkIGJlIGludGVyZXN0ZWQgdG8ga25v dyBob3cgeW91ciBpbXBsZW1lbnRhdGlvbiB3b3VsZA0KYmVoYXZlLi4uDQoNCkJvYg0KICAgICAg ICAgICAgICAgICAgDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tIHZhbkBlZS5sYmwuZ292IFdlZCBB dWcgMTQgMDY6MTg6MTUgMTk5MQ0KVG86IGJyYWRlbkBJU0kuRURVDQpDYzogZGFiQGNyYXkuY29t DQpTdWJqZWN0OiBSZTogRm9yIGRpc2N1c3Npb24uLi4gDQpJbi1SZXBseS1UbzogWW91ciBtZXNz YWdlIG9mIFR1ZSwgMTMgQXVnIDkxIDE3OjAwOjIzIFBEVC4NCkRhdGU6IFdlZCwgMTQgQXVnIDkx IDA2OjE4OjE4IFBEVA0KRnJvbTogVmFuIEphY29ic29uIDx2YW5AZWUubGJsLmdvdj4NCg0KQm9i LA0KDQpPdWNoLiAgWW91J3JlIHRvbyBnb29kIGEgcHJvdG9jb2wgbGF3eWVyICYgeW91IGNhdWdo dCBtZS4gIFllcywNCjEwNzIgc3VnZ2VzdHMgdGhlIGZpcnN0IHNlcXVlbmNlIGFuZCBJIHdvdWxk IGdlbmVyYXRlIHRoZQ0Kc2Vjb25kLiAgTm90ZSB0aGF0IHRoZSByZXN1bHRzIGZvciBhbGwgb2Yg MTE4NSBhbmQgY2FzZSAoYSkgJg0KKGMpIG9mIDEwNzIgcC4xMyBhcmUgdGhlIHNhbWUgZm9yIGJv dGggc2NoZW1lcyBhbmQgd2hhdCBJIGRvIGlzDQptb3JlIGNvbnNlcnZhdGl2ZSBmb3IgY2FzZSAo YikuICh0aGUgc2VuZGVyIHdpbGwgb3ZlcmVzdGltYXRlDQp0aGUgcnR0IGJ5IHNvbWUgYW1vdW50 IHRoYXQgc2hvdWxkIGJlIDw9IHR3aWNlIHdoYXQgdGhlDQphbGdvcml0aG0gaW4gMTA3MiB3b3Vs ZCBlc3RpbWF0ZS4pICBTbyBJJ2xsIHN0aWxsIGFyZ3VlIGZvciBteQ0Kc2NoZW1lIGFzIGFuIGFs dGVybmF0aXZlLCBzYWZlIGFuZCBzbGlnaHRseSBzaW1wbGVyIHdheSB0bw0KaW1wbGVtZW50IGEg MTA3MiByZWNlaXZlci4NCg0KIC0gVmFuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJvbSBicmFkZW5A SVNJLkVEVSBXZWQgQXVnIDE0IDA5OjQ0OjIxIDE5OTENCkRhdGU6IFdlZCwgMTQgQXVnIDkxIDA5 OjQzOjQ5IFBEVA0KRnJvbTogYnJhZGVuQElTSS5FRFUNClRvOiB2YW5AZWUubGJsLmdvdg0KU3Vi amVjdDogUmU6IEZvciBkaXNjdXNzaW9uLi4uDQpDYzogYnJhZGVuQElTSS5FRFUsIGRhYkBjcmF5 LmNvbQ0KDQp2YW4sDQoNCldoYXQgbWF5IGFwcGVhciB0byBiZSBwcm90b2NvbCBsYXd5ZXJpbmcg aXMganVzdCBzaW1wbGUtbWluZGVkbmVzcyAtLSB3aGljaCwNCmxpa2UgZ3VpbHQsIGNhbiBzb21l dGltZXMgYmUgcHV0IHRvIHBvc2l0aXZlIHVzZS4NCg0KSG1tbW1tLiAgV2hlbiB3ZSBwdXQgdG9n ZXRoZXIgUkZDLTEwNzIsIHdlIHdlcmUgdHJ5aW5nIHRvIGRvIHRoZSBiZXN0DQpkYW1uIGpvYiB3 ZSBjb3VsZCBpbiBtZWFzdXJpbmcgdGhlIHRydWUgUlRULCBhcyBmcmVlIGZyb20gYmlhc2VzIGFz DQpwb3NzaWJsZS4uLi4gdGhhdCB3YXMgdGhlIHdob2xlIHJhdGlvbmFsZSBmb3IgdGhlIHRpbWVz dGFtcCBlY2hvIGluDQpSRkMtMTA3Mi4gIEkgd2FzIGRlYWxpbmcgd2l0aCB0aGUgY29udHJvbCB0 aGVvcmlzdCBWYW4gSmFjb2Jzb24uICBOb3cgSQ0KaGF2ZSBhIGZlZWxpbmcgSSBhbSBkZWFsaW5n IHdpdGggdGhlIGltcGxlbWVudG9yIFZhbiBKYWNvYnNvbiwgYW5kDQpoZWFyaW5nIHNvbWV0aGlu ZyBkaWZmZXJlbnQuICBJdCBzZWVtcyB0aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIHJlZHVjZQ0KdGhl IGFtb3VudCBvZiBzdGF0ZSAob25lIDMyLWJpdCB0aW1lc3RhbXAgaW5zdGVhZCBvZiB0d28sIGFu ZCBvbmUgZmV3ZXINCmNvbnRyb2wgYml0cykgaW4gdGhlIHRjYmNiLiAgSXMgdGhlIGNvbnRyb2wg dGhlb3Jpc3QgZG9ybWFudD8NCkFyZSB5b3UgcmVhbGx5IHN1cmUgdGhpcyBpcyBtb3ZpbmcgaW4g YSBjb25zdHJ1Y3RpdmUgZGlyZWN0aW9uPz8NCg0KQm9iDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbSBicmFkZW5ASVNJLkVEVSBUaHUgQXVnICA4IDEyOjU5OjE3IDE5OTENCkRhdGU6IFRodSwg OCBBdWcgOTEgMTI6NTg6NDkgUERUDQpGcm9tOiBicmFkZW5ASVNJLkVEVQ0KVG86IHZhbkBoZWxp b3MuZWUubGJsLmdvdg0KU3ViamVjdDogbW9yZSBCcmFkZW4gYm90aGVyLi4uDQpDYzogYnJhZGVu QElTSS5FRFUNCg0KdmFuLA0KDQpXZWxsLCBJIGRpZG4ndCBnZXQgYSBMT1Qgb2Ygam95IG91dCBv ZiB0aGUgRGFydG5ldCBuZXRpbmV0LyBtb2R1bGVzLg0KSXQgc2VlbXMgcHV6emxpbmdseSBwYXJ0 aWFsLi4uIGVnIGl0IGRvZXMgbm90IHNlZW0gdG8gVVNFIHRoZSByZXR1cm5lZCBFY2hvDQpyZXBs eSB2YWx1ZXMgdG8gY29tcHV0ZSB0aGUgUlRUIChpcyB0aGVyZSBzb21ldGhpbmcgc3VidGxlIGdv aW5nIG9uIGhlcmUNCkkgZG9uJ3QgdW5kZXJzdGFuZD8pOyBhbmQsIGl0IGRvZXMgbm90IHNlZW0g dG8gaW1wbGVtZW50IHRoZSAibmV3ZXN0IHNlZ21lbnQNCmZyb20gdGhlIG9sZGVzdCBzZXF1ZW5j ZSBudW1iZXIiIGFsZ29yaXRobSBvZiBSRkMtMTA3Mi4gDQoNCkhtbW0uICBNeSBbZGVsYXllZF0g Ym9nb3NpdHkgbWV0ZXIgaXMgZ29pbmcgb2ZmLCBjb25jZXJuaW5nIHlvdXIgaWRlYQ0Kb2YgdGhl IHN5bW1ldHJ5IGJldHdlZW4gZGF0YSBhbmQgQUNLcy4gIE9LLCBzbyB3ZSBjYW4gc2VuZCBFQ29w dHMgaW4NCmJvdGggZGF0YSBhbmQgQUNLIHNlZ21lbnRzLiAgQnV0IGVjaG9pbmcgQUNLIHNlZ21l bnQgdGltZXN0YW1wcyBpbiBkYXRhDQpzZWdtZW50cyBzZWVtcyBicm9rZW4uLi4gICB0aGUgdGlt aW5nIGRlcGVuZHMgdXBvbiBob3cgc29vbiB0aGUNCmFwcGxpY2F0aW9uIGRlY2lkZXMgdG8gc2Vu ZCBhIHJlc3BvbnNlLCB3aGljaCB3b3VsZCBhcnRpZmljaWFsbHkNCmluZmxhdGUgdGhlIFJUVCBt ZWFzdXJlbWVudC4gIFBlcmhhcHMgSSBtaXN1bmRlcnN0b29kIHlvdXIgcmVhc29uaW5nOw0KSWYg eW91ciBhcmd1bWVudCBpcyBqdXN0IHRoYXQgaXQgaXMgc2ltcGxlciB0byBjb2RlIGFuZC9vciBm YXN0ZXIgdG8NCmV4ZWN1dGUgdG8gYWx3YXlzIHN0dWZmIHNvbWUgRUNSb3B0IHZhbHVlIGludG8g ZXZlcnkgcGFja2V0LCBidXQgaWdub3JlDQpFQ1JvcHQgdmFsdWVzIHJlY2VpdmVkIG9uIGRhdGEg c2VnbWVudHMsIHRoZW4gSSBhdCBsZWFzdCB1bmRlcnN0YW5kLi4uDQoNCkJvYg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KRnJvbSBkYWJAYmVyc2Vya2x5LmNyYXkuY29tIFRodSBBdWcgMTUgMDg6MzI6 NDYgMTk5MQ0KRGF0ZTogVGh1LCAxNSBBdWcgOTEgMTA6MzE6MDcgLTA1MDANCkZyb206IGRhYkBi ZXJzZXJrbHkuY3JheS5jb20gKERhdmlkIEJvcm1hbikNClRvOiBicmFkZW5ASVNJLkVEVSwgdmFu QGhlbGlvcy5lZS5sYmwuZ292DQpTdWJqZWN0OiBSZTogRm9yIGRpc2N1c3Npb24uLi4NCg0KDQpX ZWxsLCB1c2luZyBCb2JzIGV4YW1wbGUsIG15IGNvZGUgd291bGQgZG8gdGhlIGZvbGxvd2luZzoN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVjZWl2ZXIgZG9lcyBSRkMtMTE4NSBU aW1lc3RhbXANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbXBhcmlzb24gYWdhaW5z dCB2YWx1ZToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVg0KICAg IDxBLEVDb3B0PTE+IC0tLS0tLS0tLS0tLS0tLS0tLS0tPiAgICAwIChzYXkpDQogICAgPEIsRUNv cHQ9Mj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0+ICAgIDENCiAgICAgICAgICAgICAgICAgPC0tLS0g PEFDSyhCKSxFQ1JvcHQ9Mj4NCiAgICA8QyxFQ29wdD0zPiAtLS0tLS0+IChsb3N0KQ0KICAgIDxE LEVDb3B0PTQ+IC0tLS0tLS0tLS0tLS0tLS0tLS0tPiAgICAyCShjb21wYXJlIGFnYWluc3QgMiwg bm90IDEhKQ0KICAgICAgICAgICAgICAgIDwtLS0tLSA8QUNLKEIpLEVDUm9wdD00PgkNCiAgIChy ZXRyYW5zbWl0IEMpDQogICAgPEMsRUNvcHQ9NT4gLS0tLS0tLS0tLS0tLS0tLS0tLT4gICAgIDIN CiAgICAgICAgICAgICAgICA8LS0tLS0tIDxBQ0soRCksRUNSb3B0PTUNCiAgICA8RSxFQ29wdD02 PiAtLS0tLS0tLS0tLS0tLS0tLS0tPiAgICAgNQ0KICAgICAgICAgICAgICAgIDwtLS0tLS0gPEFD SyhEKSxFQ1JvcHQ9Ng0KDQpVZmYgZGEuICBJbiBteSBjb2RlLCB0aGUgaW5kaWNhdGVkIGFjayAo Kikgd2lsbCBoYXZlIGFuIEVDUm9wdCBvZiA0LA0Kbm90IDEsIGJ1dCBub3QgYmVjYXVzZSBvZiB3 aGF0J3Mgd3JpdHRlbiBpbiAxMDcyIG9yIDExODUuLi4gIEFzIHdyaXR0ZW4sDQp3aWxsIHJlc3Bv bmQgd2l0aCB0aGUgRUNSb3B0IHZhbHVlIG9mIHdoYXRldmVyIHdhcyBtb3N0IHJlY2VudGx5DQpy ZWNlaXZlZCBpbiBhbiBFQ29wdC4gIE15IGNvZGUgbW9yZSBvciBsZXNzIGxvb2tzIGxpa2U6DQoN Cgl0cC0+ZWNob192YWx1ZQkJTW9zdCByZWNlbnRseSByZWNlaXZlZCBFQ29wdA0KCXRwLT5lY2hv X3RpbWVzdGFtcAlFQ29wdCB2YWx1ZSBmcm9tIGxhc3QgcGFja2V0IHJlY2VpdmVkDQoJCQkJYXQg dGhlIGxlZnQgZWRnZSBvZiB0aGUgd2luZG93Lg0KCUVDSE9fTkVFREVECQlGbGFnIHRvIGluZGlj YXRlIHRoYXQgdHAtPmVjaG9fdmFsdWUNCgkJCQluZWVkZXMgdG8gYmUgc2VudCBiYWNrIGluIEVD Um9wdC4NCglFQ0hPX1JDVkQJCUZsYWcgdG8gaW5kaWNhdGUgdGhhdCBFQ29wdCB3YXMgZm91bmQN CgkJCQl3aGlsZSBwcm9jZXNzaW5nIHRoZSBvcHRpb25zLg0KDQogICAgT24gcmVjaWV2ZToNCg0K CVByb2Nlc3MgVENQIG9wdGlvbnM6DQoJCUlmIGVjaG8gb3B0aW9uIGlzIHJlY2VpdmVkLCBpdHMg dmFsdWUgaXMgc2F2ZWQgaW4NCgkJdHAtPmVjaG9fdmFsdWUsIGFuZCBFQ0hPX05FRURFRCBhbmQg RUNIT19SQ1ZEIGZsYWdzIGFyZSBzZXQuDQoNCglJZiB0aGUgcGFja2V0IGlzIHRoZW4gZGV0ZXJt aW5lZCB0byBiZSBhdCB0aGUgbGVmdCBlZGdlIG9mIHRoZQ0KCQl3aW5kb3csIGFuZCB0aGUgRUNI T19SQ1ZEIGJpdCBpcyBzZXQsIHRwLT5lY2hvX3ZhbHVlIGlzDQoJCWNvcGllZCBpbnRvIHRwLT5l Y2hvX3RpbWVzdGFtcC4NCglPdGhlcndpc2UsIGlmIHRoZSB0cC0+ZWNob192YWx1ZSBpcyBsZXNz IHRoYW4gdHAtPmVjaG9fdGltZXN0YW1wLA0KCQl0aGUgcGFja2V0IGlzIHRvc3NlZC4NCg0KICAg IE9uIHRyYW5zbWl0Og0KCUlmIEVDSE9fTkVFREVEIGlzIHNldCwgY29weSB0cC0+ZWNob192YWx1 ZSBpbnRvIEVDUm9wdCwgYW5kDQoJY2xlYXIgRUNIT19ORUVERUQuDQoNCk15IGNvZGUgaXMgb2J2 aW91c2x5IHdyb25nLiAgQW4gb2xkIHBhY2tldCB3YW5kZXJpbmcgaW4gY291bGQgbXVjaw0KdGhp bmdzIHVwLCBhbmQgSSBjbGVhcmx5IHZpb2xhdGUgY2FzZSBBIG9uIHBhZ2UgMTMgb2YgMTA3Mi4N Cg0KU28sIGxldCB0b3NzIG91dCBzb21lIGNhc2VzIGZvciBkaXNjdXNzaW9uOg0KDQoxKSBQYWNr ZXRzIGFycml2ZSBpbiBzZXF1ZW5jZSwgYW5kIGV2ZXJ5IHBhY2tldCBpcyBhY2tlZC4gIFRoaXMN CiAgIGlzIG5vdCBhbiBpc3N1ZSwgd2UgYWxsIHVuZGVyc3RhbmQgd2hhdCBzaG91bGQgaGFwcGVu IGhlcmUuDQoJPEEsIEVDb3B0PTE+IC0tLS0tLS0tLS0tLS0tLS0tLS0+ICAgMA0KCQk8LS0tLSA8 QUNLKEEpLCBFQ1JvcHQ9MT4NCgk8QiwgRUNvcHQ9Mj4gLS0tLS0tLS0tLS0tLS0tLS0tLT4gICAx DQoJCTwtLS0tIDxBQ0soQiksIEVDUm9wdD0yPg0KCTxDLCBFQ29wdD0zPiAtLS0tLS0tLS0tLS0t LS0tLS0tPiAgIDINCgkJPC0tLS0gPEFDSyhDKSwgRUNSb3B0PTM+DQoJPEQsIEVDb3B0PTQ+IC0t LS0tLS0tLS0tLS0tLS0tLS0+ICAgMw0KCQk8LS0tLSA8QUNLKEQpLCBFQ1JvcHQ9ND4NCg0KMikg UGFja2V0cyBhcnJpdmUgaW4gc2VxdWVuY2UsIGFuZCBzb21lIG9mIHRoZSBhY2tzIGFyZSBkZWxh eWVkLg0KICAgV2hhdCBlY2hvIHZhbHVlIGRvIHlvdSB1c2U/ICBSRkMgMTA3MiwgcGcuIDEzLCBD YXNlIChBKSBzYXlzDQogICB5b3UgdXNlIHRoZSBvbGRlc3QgZWNobyB2YWx1ZSByZWNlaXZlZC4g IEkgZG9uJ3QgdGhpbmsgdGhhdA0KICAgdGhlcmUgaXMgYW4gaXNzdWUgaGVyZSBlaXRoZXIuDQoJ PEEsIEVDb3B0PTE+IC0tLS0tLS0tLS0tLS0tLS0tLS0+ICAgMA0KCTxCLCBFQ29wdD0yPiAtLS0t LS0tLS0tLS0tLS0tLS0tPiAgIDENCgk8QywgRUNvcHQ9Mz4gLS0tLS0tLS0tLS0tLS0tLS0tLT4g ICAyDQoJCTwtLS0tIDxBQ0soQyksIEVDUm9wdD0xPg0KCTxELCBFQ29wdD00PiAtLS0tLS0tLS0t LS0tLS0tLS0tPiAgIDMNCgk8RSwgRUNvcHQ9NT4gLS0tLS0tLS0tLS0tLS0tLS0tLT4gICA0DQoJ PEYsIEVDb3B0PTY+IC0tLS0tLS0tLS0tLS0tLS0tLS0+ICAgNQ0KCQk8LS0tLSA8QUNLKEYpLCBF Q1JvcHQ9Nj4NCg0KMykgUGFja2V0cyBhcnJpdmUgb3V0IG9mIG9yZGVyLCBhbmQgd2UgYXJlIGFj a2luZyBldmVyeSBwYWNrZXQuDQoJPEEsIEVDb3B0PTE+IC0tLS0tLS0tLS0tLS0tLS0tLS0+ICAg MA0KCQk8LS0tLSA8QUNLKEEpLCBFQ1JvcHQ9MT4NCgk8QywgRUNvcHQ9Mz4gLS0tLS0tLS0tLS0t LS0tLS0tLT4gICAxDQoJCTwtLS0tIDxBQ0soQSksIEVDUm9wdD0zPgkzLCAxLCBvciBubyBFQ1Ig YXQgYWxsPw0KCTxCLCBFQ29wdD0yPiAtLS0tLS0tLS0tLS0tLS0tLS0tPiAgIDENCgkJPC0tLS0g PEFDSyhDKSwgRUNSb3B0PTI+DQoJPEUsIEVDb3B0PTU+IC0tLS0tLS0tLS0tLS0tLS0tLS0+ICAg Mg0KCQk8LS0tLSA8QUNLKEMpLCBFQ1JvcHQ9NT4JNSwgMiwgb3Igbm8gRUNSIGF0IGFsbD8NCgk8 RCwgRUNvcHQ9ND4gLS0tLS0tLS0tLS0tLS0tLS0tLT4gICAyDQoJCTwtLS0tIDxBQ0soRCksIEVD Um9wdD00Pg0KCTxGLCBFQ29wdD02PiAtLS0tLS0tLS0tLS0tLS0tLS0tPiAgIDQNCgkJPC0tLS0g PEFDSyhGKSwgRUNSb3B0PTY+DQoNCjQpIFBhY2tldHMgYXJyaXZlIG91dCBvZiBvcmRlciwgYW5k IHdlIGFyZSBOT1QgYWNraW5nIGV2ZXJ5IHBhY2tldC4NCgk8QSwgRUNvcHQ9MT4gLS0tLS0tLS0t LS0tLS0tLS0tLT4gICAwDQoJPEMsIEVDb3B0PTM+IC0tLS0tLS0tLS0tLS0tLS0tLS0+ICAgMQ0K CQk8LS0tLSA8QUNLKEEpLCBFQ1JvcHQ9MT4NCgk8RCwgRUNvcHQ9ND4gLS0tLS0tLS0tLS0tLS0t LS0tLT4gICAxDQoJCTwtLS0tIDxBQ0soQSksIEVDUm9wdD00Pgk0LCAxLCBvciBubyBFQ1IgYXQg YWxsPw0KCTxCLCBFQ29wdD0yPiAtLS0tLS0tLS0tLS0tLS0tLS0tPiAgIDENCgkJPC0tLS0gPEFD SyhDKSwgRUNSb3B0PTI+DQoJPEUsIEVDb3B0PTU+IC0tLS0tLS0tLS0tLS0tLS0tLS0+ICAgMg0K CQk8LS0tLSA8QUNLKEUpLCBFQ1JvcHQ9ND4JNSwgMiwgb3Igbm8gRUNSIGF0IGFsbD8NCgk8Riwg RUNvcHQ9Nj4gLS0tLS0tLS0tLS0tLS0tLS0tLT4gICA1DQoJCTwtLS0tIDxBQ0soRiksIEVDUm9w dD02Pg0KDQpJIHdvdWxkIGFyZ3VlIHRoYXQgd2hlbiBzZW5kaW5nIGFuIEFDSyBkdWUgdG8gb3V0 LW9mLW9yZGVyIChsb3N0KSBwYWNrZXRzLA0KeW91IGVpdGhlciAxKSBzZW5kIHRoZSBFQ1Igd2l0 aCB0aGUgcHJlLWV4aXN0aW5nIHZhbHVlIHRoYXQgaGFzbid0IGJlZW4gc2VudA0KeWV0IChkZWxh eWVkIGFja3MpLCAyKSBpZiBubyBFQ1Igd2FzIGFscmVhZHkgcXVldWVkIHVwLCBzZW5kIHRoZSBF Q1Igd2l0aA0KdGhlIHZhbHVlIGluIHRoZSBwYWNrZXQsIG9yIDMpIGRvbid0IHNlbmQgYW4gRUNS IGluIHRoZSBhY2suICBTZW5kaW5nIGFuDQpFQ1IgaW4gdGhlIGFjayB3aXRoIHRoZSBsYXN0IGxl ZnQtd2luZG93LWVkZ2UgdmFsdWUgaW5zdGVhZCBvZiB0aGUgRUMgdmFsdWUNCmp1c3QgcmVjZWl2 ZWQgY291bGQgcmVhbGx5IHNjcmV3IHRoaW5ncyB1cC4NCg0KSW1hZ2luZToNCiAgICAgICAgPEEs IEVDb3B0PTE+ICAgLS0tLS0tLS0tLS0tLS0tLS0tLT4gICAwDQogICAgICAgICAgICAgICAgPC0t LS0gPEFDSyhBKSwgRUNSb3B0PTE+DQoJICAgIChjb25uZWN0aW9uIGlzIGlkbGUgZm9yIGEgd2hp bGUuLi4pDQogICAgICAgIDxDLCBFQ29wdD0xMDM+IC0tLS0tLS0tLS0tLS0tLS0tLS0+ICAgMQ0K ICAgICAgICAgICAgICAgIDwtLS0tIDxBQ0soQSksIEVDUm9wdD0xMDM+ICAgICAgICAxMDMsIDEs IG9yIG5vIEVDUiBhdCBhbGw/DQogICAgICAgIDxCLCBFQ29wdD0xMDI+IC0tLS0tLS0tLS0tLS0t LS0tLS0+ICAgMQ0KICAgICAgICAgICAgICAgIDwtLS0tIDxBQ0soQyksIEVDUm9wdD0xMDI+DQoN CklmIHRoZSBtaWRkbGUgYWNrIHdhcyAxLCBub3QgMTAzLCB0aGVuIHdoZW4gdGhlIEFDSyBpcyBy ZWNlaXZlZCwgdGhlIFJUVA0KdmFsdWUgdGhhdCBpcyBjb21wdXRlZCBpcyBnb2luZyB0byBiZSBk cmFzdGljYWxseSBvdXQgb2Ygd2Fjay4gIEVpdGhlciB1c2UNCnRoZSB2YWx1ZSB0aGF0IHdhcyBy ZWNlaXZlZCBpbiB0aGUgb3V0LW9mLXNlcXVlbmNlIHBhY2tldCwgb3IgZG9uJ3Qgc2VuZA0KYW5k IEVDUiBpbiB0aGUgYWNrLg0KDQpDb21tZW50cz8gIEknbGwgYmUgZml4aW5nIG15IGNvZGUsIGJ1 dCBJJ2xsIHdhaXQgdW50aWwgd2UgYWxsIGFncmVlIG9uDQp3aGF0IHNob3VsZCByZWFsbHkgYmUg aGFwcGVuaW5nLg0KDQoJCQktRGF2ZSBCb3JtYW4sIGRhYkBjcmF5LmNvbQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KRnJvbSBicmFkZW5ASVNJLkVEVSBGcmkgQXVnIDE2IDE0OjQyOjE1IDE5OTEN CkRhdGU6IEZyaSwgMTYgQXVnIDkxIDE0OjQxOjQ0IFBEVA0KRnJvbTogYnJhZGVuQElTSS5FRFUN ClRvOiBkYWJAY3JheS5jb20sIHZhbkBoZWxpb3MuZWUubGJsLmdvdg0KU3ViamVjdDogUkZDLTEw NzIvMTE4NSBpc3N1ZXMNCkNjOiBicmFkZW5ASVNJLkVEVQ0KDQpEYXZlLA0KDQpZZXMsIHlvdXIg Y29ycmVjdGlvbnMgdG8gbXkgcHNldWRvLWNvZGUgYXJlIGNlcnRhaW5seSByaWdodC4gIEkgd2ls bA0KaW5jb3Jwb3JhdGUgdGhlbS4uLg0KDQpWYW4sDQoNCkFyZSB0aGVyZSBhbnkgY2lyY3Vtc3Rh bmNlcyBpbiB3aGljaCBhIFRDUCByZWNlaXZpbmcgZGF0YSBjb250YWluaW5nDQpFQ29wdHMgd291 bGQgc2VuZCBiYWNrIGFuIEFDSyB0aGF0IERJRCBOT1QgY29udGFpbiBhbiBFQ1JvcHQ/ICBEYXZl DQphcmd1ZWQgaW4gaGlzIG1lc3NhZ2UgeWVzdGVyZGF5IHRoYXQgdGhlIGFuc3dlciBpcyAieWVz Iiwgd2hlbiB0aGUgb25seQ0KdGltZXN0YW1wIGF2YWlsYWJsZSB0byBiZSBlY2hvZWQgaXMga25v d24gdG8gYmUgc2VyaW91c2x5IG91dCBvZiBkYXRlLg0KSGVyZSBpcyB0aGUgc2FtZSBhcmd1bWVu dDoNCg0KICAgV2hlbiBhIGhvc3QgcmVjZWl2ZXMgYW4gRUNSb3B0LCBpdCBoYXMgdG8gYmVsaWV2 ZSBpdCBhbmQgdXBkYXRlDQogICBpdHMgUlRUIGVzdGltYXRlIChJIGRvbid0IHNlZSBhIHNpbXBs ZSBhbHRlcm5hdGl2ZSkuICBUaGVyZSBhcmUNCiAgIHRpbWVzIHdoZW4gaXQgU0hPVUxEIE5PVCBi ZWxpZXZlIGl0IChhbiBFQ1JvcHQgaW4gYSBkYXRhIHNlZ21lbnQNCiAgIGNvbWluZyBzb21lIGxv bmcgaWRsZSBwZXJpb2QgYnV0IGNhcnJ5aW5nIGEgdGltZXN0YW1wIGVjaG9lZCBmcm9tDQogICBh biBBQ0suKSAgICANCiAgICAgICAgICAgICAgICAgICAtLS0tLS0+IDxBQ0ssRUNvcHQ9MTc+IC0t LS0tLT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoaWRsZSkNCiAgICAgICg9 PmJhZCBSVFQhKSAgPC0tLS0gPGRhdGEsRUNSb3B0PTE3PiA8LS0tLS0NCiAgIA0KICAgVGhlIG9u bHkgd2F5IHRvIGhlYWwgdGhpcyBpcyBmb3IgdGhlIEVDb3B0IHJlY2VpdmVkIGluDQogICBhbiBB Q0sgc2VnbWVudCB0byBOT1QgYmUgZWNob2VkIGluIHRoZSBuZXh0IGRhdGEgc2VnbWVudCB0aGF0 IGlzDQogICBzZW50Lg0KICAgICAgICAgICAgICAgICAtLS0tLS0+IDxBQ0ssRUNvcHQ9MTc+IC0t LS0tLT4gKGlnbm9yZSBFQ29wdCBpbiBBQ0spDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKGlkbGUpDQogICAgICAgICAgICAgICAgICA8LS0tLS0tIDxkYXRhPiA8LS0tLS0tLS0t LQ0KICAgDQpIZXJlIGlzIGFub3RoZXIgYXJndW1lbnQ6DQoNCiAgIENvbnNpZGVyIGEgc2ltcGxl eCBkYXRhIHRyYW5zZmVyLiAgQXNzdW1pbmcgdGhlIEFDS3MgY2FycnkgRUNvcHRzLA0KICAgaWYg d2UgZWNobyB0aGUgQUNLIHRpbWVzdGFtcHMgaW4gdGhlIGRhdGEgc2VnbWVudHMsIHRoZW4gdGhl IGRhdGENCiAgIHJlY2VpdmVyIG11c3QgY2FsY3VsYXRlIGFuIFJUVCB0aGF0IGl0IHdpbGwgbmV2 ZXIgdXNlLCBldmVyeSB0aW1lIGl0DQogICByZWNlaXZlcyBhIGRhdGEgc2VnbWVudC4gIFRoYXQg d2FzdGVkIHByb2Nlc3NpbmcgaXMgbXVjaCBncmVhdGVyDQogICB0aGFuIHRoZSBwcm9jZXNzaW5n IHRvIGluY2x1ZGUgb3IgZXhjbHVkZSBhbiBFQ1JvcHQgb3B0aW9uLg0KDQpBbSBJIGNvbnZpbmNp bmcgeW91Pw0KDQpCb2INCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyANCg0KRnJvbSB2YW5AZWUubGJsLmdv diBNb24gQXVnIDE5IDA2OjUxOjIyIDE5OTENClRvOiBicmFkZW5ASVNJLkVEVQ0KQ2M6IGRhYkBj cmF5LmNvbQ0KU3ViamVjdDogUmU6IFJGQy0xMDcyLzExODUgaXNzdWVzIA0KSW4tUmVwbHktVG86 IFlvdXIgbWVzc2FnZSBvZiBGcmksIDE2IEF1ZyA5MSAxNDo0MTo0NCBQRFQuDQpEYXRlOiBNb24s IDE5IEF1ZyA5MSAwNjo1MTozNiBQRFQNCkZyb206IFZhbiBKYWNvYnNvbiA8dmFuQGVlLmxibC5n b3Y+DQoNCj4gV2hlbiB3ZSBwdXQgdG9nZXRoZXIgUkZDLTEwNzIsIHdlIHdlcmUgdHJ5aW5nIHRv IGRvIHRoZSBiZXN0DQo+IGRhbW4gam9iIHdlIGNvdWxkIGluIG1lYXN1cmluZyB0aGUgdHJ1ZSBS VFQsIGFzIGZyZWUgZnJvbSBiaWFzZXMNCj4gYXMgcG9zc2libGUuLi4uIHRoYXQgd2FzIHRoZSB3 aG9sZSByYXRpb25hbGUgZm9yIHRoZSB0aW1lc3RhbXANCj4gZWNobyBpbiBSRkMtMTA3Mi4NCg0K V3JvbmcuICBZb3UndmUgbWFkZSB0aGUgY2xhc3NpYyBtaXN0YWtlIG9mIGNvbmZ1c2luZyBhIG1l YW5zDQp3aXRoIGFuIGVuZC4gIEEgVENQIHNlbmRlciBpcyB0cnlpbmcgdG8gYSBjb21wdXRlIGEg ZnVuY3Rpb24gTCgpDQpiZXN0IGRlc2NyaWJlZCBhcyAidGhlIGVhcmxpZXN0IHRpbWUgYXQgd2hp Y2ggSSB3aWxsIGtub3cgc29tZQ0KcGFja2V0IGhhcyAoYWxtb3N0IGNlcnRhaW5seSkgYmVlbiBs b3N0IGluIHRyYW5zaXQiLiAgVGhlDQp2YWx1ZSBvZiB0aGlzIGZ1bmN0aW9uIGlzIGNydWNpYWwg dG8gdGhlIHN0YWJpbGl0eSBvZiB0aGUNCm5ldHdvcmsgKGlmIEwoKSBpcyBvcHRpbWlzdGljLCBz cHVyaW91cyByZXRyYW5zbWl0cyB3aWxsIGZpbGwgdXANCnRoZSBuZXR3b3JrIGFuZCBpdCB3aWxs IGNvbmdlc3Rpb24gY29sbGFwc2UpLiAgRnJvbSBhIG1peCBvZg0KdGhlb3J5IGFuZCBleHBlcmll bmNlLCB3ZSd2ZSBkZXZlbG9wZWQgYSB1c2VmdWwgYXBwcm94aW1hdGlvbg0KZm9yIEwoKSBiYXNl ZCBvbiB0aGUgY3VycmVudCB0aW1lLCBhbiBlc3RpbWF0ZSBvZiB0aGUgZmlyc3QgJg0Kc2Vjb25k IG9yZGVyIHN0YXRpc3RpY3Mgb2YgdGhlIHJ0dCBhbmQgc29tZSBsb2NhbCBzdGF0ZSAoZS5nLiwN Ckthcm4ncyBhbGdvcml0aG0gb24gdGhlIHJlY2VudCByZXRyYW5zbWlzc2lvbiBoaXN0b3J5KS4N Ck5vdGUgdGhhdCB0aGUgcnR0IGVzdGltYXRlIGlzIHZhbHVhYmxlIG9ubHkgaW4gdGhhdCB3ZSB1 c2UgaXQNCnRvIGNvbXB1dGUgTCgpLiAgV2UgZG9uJ3QgbmVlZCBhICJ0cnVlIFJUVCIsIHdlIG5l ZWQgYQ0KY29uc2VydmF0aXZlIEwoKS4NCg0KVGhlIHJhdGlvbmFsZSBmb3IgdGhlIDEwNzIgdGlt ZXN0YW1wIHdhcyB0aGF0DQoNCiBhKSBldmVyeSBUQ1AgaW1wbGVtZW50YXRpb24gSSBrbm93IG9m IChhdCBsZWFzdCA1IGluZGVwZW5kZW50DQogICAgaW1wbGVtZW50YXRpb25zKSBtZWFzdXJlcyB0 aGUgcnR0IG9uICphdCBtb3N0KiBvbmUgcGFja2V0DQogICAgcGVyIHdpbmRvdyBvZiBkYXRhIHNl bnQgKHVzdWFsbHkgdGhlIHBhY2tldHMgaXNzKzEsIGlzcytXKzEsDQogICAgaXNzKzJXKzEsIC4u LikuICBbVGhpcyBmZWF0dXJlIG9mIHRoZSBpbXBsZW1lbnRhdGlvbnMgaXMgbm90DQogICAgaW50 ZW50aW9uYWwgYW5kIG5vdCBvYnZpb3VzIC0tIG9uZSBpbmRpdmlkdWFsIHJlYWxseSBiZWxpZXZl ZA0KICAgIGhpcyBpbXBsZW1lbnRhdGlvbiB0aW1lZCBhbG1vc3QgZXZlcnkgcGFja2V0IHVudGls IEkgZm9yY2VkDQogICAgaGltIHRvIHB1dCBpbiBhIHRyYWNlIGJ1ZmZlciB0byBsb29rIGF0IHdo aWNoIHBhY2tldHMgdXBkYXRlZA0KICAgIHRoZSBydHQgZXN0aW1hdGUuXQ0KDQogYikgQW55b25l IHdobyBsb29rcyBhdCBob3cgcnR0IHZhcmllcyBvdmVyIHRoZSBsaWZlIG9mIGENCiAgICBjb252 ZXJzYXRpb24gbm90aWNlcyB0aGF0IHRoZXJlIGlzIGEgZ3JlYXQgZGVhbCBvZiBzdHJ1Y3R1cmUu DQogICAgSW4gcGFydGljdWxhciwgdGhlcmUgaXMgYWxtb3N0IGFsd2F5cyBhIHBlcmlvZGljIHZh cmlhdGlvbg0KICAgIHdpdGggbWluaW1hIGF0IGludGVnZXIgbXVsdGlwbGVzIG9mIHRoZSB3aW5k b3cgc2l6ZTogKHRoZQ0KICAgIHJlYXNvbiBmb3IgdGhpcyBpcyBvYnZpb3VzIGlmIHlvdSBjb25z aWRlciBob3cgYSB3aW5kb3cNCiAgICBwcm90b2NvbCBsb2FkcyB0aGUgcGlwZS4pDQoNCiAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgIHwgICAgICAgICoqKioqKioqKiAgICAgICoqKioqKioqKiAgICAgICoqKioq ICAgICAgICAgICAgICAgDQogICAgUiAgfCAgICAgICAqICAgICAgICAgICAgICAqICAgICAgICAg ICAgICAqICAgICAgICAgICAgICAgICAgICANCiAgICBUICB8ICAgICAgKiAgICAgICAgICAgICAg KiAgICAgICAgICAgICAgKiAgICAgICAgICAgICAgICAgICAgDQogICAgVCAgfCAgICAgKiAgICAg ICAgICAgICAgKiAgICAgICAgICAgICAgKiAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICB8 ICAgICogICAgICAgICAgICAgICogICAgICAgICAgICAgICogICAgICAgICAgICAgICAgICAgICAg IA0KICAgICAgIHwgICAqICAgICAgICAgICAgICAqICAgICAgICAgICAgICAqICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgICAgfCAgKiAgICAgICAgICAgICAgKiAgICAgICAgICAgICAgKiAg ICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICB8DQogICAgICAgfA0KICAgICAgIC0tLSst LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LQ0KICAgICAgICBpc3MrMSAgICAgICAgIFcraXNzKzEgICAgICAgIDJXK2lzcysxICAgICAgIDNX K2lzcysxICAgICAgICAgDQoJCQkgICAgU2VxdWVuY2UgTnVtYmVyDQoNCg0KVGhlIGNvbnNlcXVl bmNlIG9mIChhKSBjb21iaW5lZCB3aXRoIChiKSBpcyB0aGF0IHNhbXBsaW5nIGFydGlmYWN0cw0K KHRlY2huaWNhbGx5IGtub3duIGFzIE55cXVpc3QgYWxpYXNpbmcpIHdpbGwgcmVzdWx0IGluIGEg cG9zc2libHkNCnN1YnN0YW50aWFsIHVuZGVyZXN0aW1hdGUgb2YgdGhlIHJ0dC4gIEEgc2ltaWxh ciBlZmZlY3QgYWxzbyBhcHBlYXJzDQppbiB0aGUgMm5kIG9yZGVyIHN0YXRpc3RpY3MgKHRoZSB2 YXJpYW5jZSBpcyBtdWNoIGxvd2VyIGZvciB0aGUNCmZpcnN0IHBhY2tldCBvZiBhIHdpbmRvdyku ICBUaGUgbWFnbml0dWRlIG9mIHRoZSB0b3RhbCBlZmZlY3QgaXMNCm9idmlvdXNseSBhIGZ1bmN0 aW9uIG9mIHdpbmRvdyBzaXplOiAgZm9yIHNtYWxsIFcgaXQncyBvZnRlbg0KbmVnbGlnaWJsZSBi dXQgZm9yIGxhcmdlIFcgaXQgY2FuIGNhdXNlIHZlcnkgcG9vciBlc3RpbWF0ZXMgb2YgTCgpDQoo aS5lLiwgc3B1cmlvdXMgcmV0cmFuc21pdHMpLiAgMTA3MiB3YXMgaW50ZW5kZWQgdG8gY29ycmVj dCB0aGlzDQpwcm9ibGVtIGJ5IG9mZmVyaW5nIGEgc2ltcGxlIHdheSBmb3IgaW1wbGVtZW50YXRp b25zIHRvIHRpbWUgZXZlcnkNCnBhY2tldCBhbmQsIHRodXMsIHVzZSB0aGUgdmFyaWFuY2UgaW4g dGhlIHJ0dCBvdmVyIGEgd2luZG93IHRvDQpoZWxwIGluZmxhdGUgTCgpIHRvIGFwcHJvcHJpYXRl bHkgY29uc2VydmF0aXZlIHZhbHVlcy4NCg0KSW4gMTA3Miwgd2UgZ2F2ZSAzIHNjZW5hcmlvcyB3 aGVyZSB0aGUgdGltZXN0YW1wIHdvdWxkIGJlIHVzZWZ1bA0KKGNhc2VzIGEsIGIgJiBjIG9uIHAu MTMpLiAgU3Vic2VxdWVudCBleHBlcmllbmNlIHNob3dlZCB3ZSBnb3QNCnR3byBvdXQgb2YgdGhy ZWUgcmlnaHQgYnV0IChiKSBpcyBib2d1czogIFdoZW4gY29uZ2VzdGlvbiBvY2N1cnMNCihpLmUu LCBhdCBhIHBhY2tldCBsb3NzKSB0aGUgc2VuZGVyIHNob3VsZCBnZXQgY2F1dGlvdXMgKCJsZXQn cw0Kbm90IG1ha2UgdGhlIHByb2JsZW0gd29yc2UiKS4gIFRoaXMgaW1wbGllcyB0aGF0IHdlIHdh bnQgTCgpIHRvDQppbmNyZWFzZS4gIENsZWFybHksIHRoZSB0aW1lc3RhbXAgYXZhaWxhYmxlIHRv IHRoZSByZWNlaXZlciB0aGF0DQp3aWxsIGNhdXNlIHRoZSBiaWdnZXN0IGluY3JlYXNlIGluIEwo KSBhdCB0aGUgc2VuZGVyIGlzIHRoZQ0KdGltZXN0YW1wIG9mIHRoZSBsZWZ0IGVkZ2Ugb2YgdGhl IHdpbmRvdyAodGhlIHRpbWVzdGFtcCBvZiB0aGUNCm1vc3QgcmVjZW50IGluLXNlcXVlbmNlIHBh Y2tldCkuICBUaGlzIGlzIHdoYXQgbXkgaW1wbGVtZW50YXRpb24NCnNlbmRzLiAgSSBiZWxpZXZl IGl0IGlzIGNvcnJlY3Qgb24gYm90aCB0aGVvcmV0aWNhbCAmIHByYWN0aWNhbA0KZ3JvdW5kcy4N Cg0KQWN0dWFsbHksIG9uIHByYWN0aWNhbCBncm91bmRzLCAoYikgb24gcC4xMyBpcyBhbG1vc3Qg Y2VydGFpbmx5DQppcnJlbGV2YW50LiAgMTA3MiB3YXNuJ3QgaW50ZW5kZWQgdG8gY2hhbmdlIHRo ZSBzZW1hbnRpY3Mgb2YNCnJ0dCAoaS5lLiwgd2hlbiB0aGUgc2VuZGVyIGNvbXB1dGVzIHJ0dCkg W3Rob3VnaCB5b3Ugc2VlbSB0bw0KaGF2ZSBtaXNzZWQgb3IgZGlzYWdyZWUgd2l0aCB0aGlzIHBv aW50IC0tIHNlZSB0aGUgbm90ZSBsYXRlcl0uDQpXaXRoIHRoZSBleGlzdGluZyBzZW1hbnRpY3Ms IHRoZSBzZW5kZXIgY2FuIHVwZGF0ZSBydHQgb25seQ0Kd2hlbiBzbmQudW5hIG1vdmVzLiAgVGh1 cyB0aGUgZWNobyByZXBseSByZXN1bHRpbmcgZnJvbSB0aGUNCm91dC1vZi1zZXF1ZW5jZSBwYWNr ZXRzIHdpbGwgYmUgaWdub3JlZCAoc2luY2UgdGhleSBjYW5ub3QNCm1vdmUgc25kLnVuYSkgKmV4 Y2VwdCB3aGVuKiB0aGUgYWNrIGZvciB0aGUgcGFja2V0IGF0IHRoZQ0KbGVmdCBlZGdlIG9mIHRo ZSB3aW5kb3cgZ2V0cyBsb3N0LiAgSW4gdGhpcyBjYXNlLCBpdCBpcyBiZXN0DQpvbiBib3RoIGlu Zm9ybWF0aW9uIHRoZW9yZXRpYyAmIHN5c3RlbSBzdGFiaWxpdHkgZ3JvdW5kcyBpZg0KdGhlICdk dXBsaWNhdGUnIGFja3MgZ2VuZXJhdGVkIGJ5IG91dC1vZi1zZXF1ZW5jZSBwYWNrZXRzIGFyZQ0K aW5kZWVkIGR1cGxpY2F0ZXMuICBJLmUuLCBpZiB0aGV5IGhhdmUgdGhlIHNhbWUgZWNobyByZXBs eQ0KdmFsdWUgYXMgdGhlIGFjayBmb3IgdGhlIHBhY2tldCBhdCB0aGUgbGVmdCBlZGdlIG9mIHRo ZSB3aW5kb3cuDQoNCg0KTW92aW5nIG9uIHRvIERhdmUncyBzY2VuYXJpb3M6DQoNCj4gMykgUGFj a2V0cyBhcnJpdmUgb3V0IG9mIG9yZGVyLCBhbmQgd2UgYXJlIGFja2luZyBldmVyeSBwYWNrZXQu DQo+ICAgICA8QSwgRUNvcHQ9MT4gLS0tLS0tLS0tLS0tLS0tLS0tLT4gICAwDQo+ICAgICAgICAg ICAgIDwtLS0tIDxBQ0soQSksIEVDUm9wdD0xPg0KPiAgICAgPEMsIEVDb3B0PTM+IC0tLS0tLS0t LS0tLS0tLS0tLS0+ICAgMQ0KPiAgICAgICAgICAgICA8LS0tLSA8QUNLKEEpLCBFQ1JvcHQ9Mz4J MywgMSwgb3Igbm8gRUNSIGF0IGFsbD8NCj4gICAgIDxCLCBFQ29wdD0yPiAtLS0tLS0tLS0tLS0t LS0tLS0tPiAgIDENCj4gICAgICAgICAgICAgPC0tLS0gPEFDSyhDKSwgRUNSb3B0PTI+DQoNClRo ZSBhY2sgdGhhdCByZXN1bHRzIGZyb20gQyBtdXN0IGhhdmUgRUNSb3B0PTEsIG5vdCAzLiAgVGhl cmUNCmFyZSB0d28gc2VwYXJhdGUgd2F5cyBvZiBhcnJpdmluZyBhdCB0aGlzOg0KDQoxKSBJZiB3 ZSBjb25zaWRlciB3aGF0IGhhcHBlbnMgaWYgdGhlIGFjayByZXN1bHRpbmcgZnJvbSBBIGdldHMN CiAgIGxvc3QsIGFuIEVDUm9wdD0zIGluIHRoZSBhY2sgZnJvbSBDIHdpbGwgcmVzdWx0IGluIGFu DQogICAqdW5kZXJlc3RpbWF0ZSogb2YgdGhlIHJ0dCBmb3IgQS4gIFRoaXMgaXMgdGhlIGxhc3Qg dGhpbmcgeW91DQogICB3YW50IHRvIGhhcHBlbi4gIElmIHRoZSBhY2sgZnJvbSBBIGRvZXMgYXJy aXZlLCB0aGUgYWNrIGZyb20NCiAgIEMgZG9lc24ndCBtb3ZlIHNuZC51bmEgc28gdGhlIHJ0dCBp c24ndCB1cGRhdGVkICYgaXQgZG9lc24ndA0KICAgbWF0dGVyIHdoYXQgeW91IHB1dCBpbiB0aGUg RUNSb3B0LiAgU2luY2UgdGhlIHJlY2VpdmVyIGRvZXNuJ3QNCiAgIGtub3cgd2hpY2ggYWNrcyB3 aWxsIGdldCBkcm9wcGVkLCB0aGUgb25seSBzYWZlIGNob2ljZSBpcw0KICAgRUNSb3B0PTEgaW4g dGhlIGFjayBmcm9tIEMuDQoNCjIpIFVsdGltYXRlbHkgdGhlIHJ0dCB3aWxsIGluY2x1ZGUgdGhl IHRpbWUgaXQgdGFrZXMgdGhlIHJlY2VpdmluZw0KICAgYXBwbGljYXRpb24gdG8gY29uc3VtZSB0 aGF0IGRhdGEgKGZvciBtb3N0IGltcGxlbWVudGF0aW9ucywgdGhpcw0KICAgaGFwcGVucyBpbmRp cmVjdGx5IHZpYSBkZWxheWVkIGFja3MgJiBjbG9zZWQgd2luZG93IHByb2JlcyBidXQNCiAgIGV2 ZXJ5dGhpbmcgd29ya3MgYmV0dGVyIGlmIGFuIGltcGxlbWVudGF0aW9uIGlzIHN0cnVjdHVyZWQg c28NCiAgIHRoZSBhcHBsaWNhdGlvbiBpcyBpbiB0aGUgcmVjZWl2ZSBsb29wLiAgSS5lLiwgaWYg YWNrcyBhcmUNCiAgICh1c3VhbGx5KSBnZW5lcmF0ZWQgd2hlbiB0aGUgcmVjZWl2aW5nIGFwcGxp Y2F0aW9uIGNvbnN1bWVzIHRoZQ0KICAgZGF0YSwgbm90IHdoZW4gdGhlIGRhdGEgYXJyaXZlcyBh dCB0aGUgcmVjZWl2ZXIpLiAgU2luY2UgZGF0YQ0KICAgY2Fubm90IGJlIGRlbGl2ZXJlZCBvdXQg b2Ygc2VxdWVuY2UsIHRoZSBydHQgZm9yIEMgaXMgY29udHJvbGxlZA0KICAgYnkgQiAodGhpcyBp cyB3aHkgdGhlIEFDSyhDKSByZXN1bHRpbmcgZnJvbSBCJ3MgYXJyaXZhbCBoYXMNCiAgIEVDUm9w dD0yKS4gIFNpbmNlIEIgaGFzbid0IGFycml2ZWQgeWV0LCBhbGwgdGhlIHJlY2VpdmVyIGtub3dz DQogICBpcyB0aGUgYm91bmRzIG9uIGl0cyB0aW1lc3RhbXA6IEVDKEEpIDw9IEVDKEIpIDw9IEVD KEMpLiAgVGhlIG1vc3QNCiAgIGNvbnNlcnZhdGl2ZSBkZWNpc2lvbiAoaW4gdGVybXMgb2YgdGhl IGVmZmVjdCBvbiBMKCkgYXQgdGhlIHNlbmRlcikNCiAgIGlzIGZvciB0aGUgcmVjZWl2ZXIgdG8g dXNlIHRoZSBsb3dlciBib3VuZCwgRUMoQSkuICBbSSB3aWxsIGNsYWltLA0KICAgd2l0aG91dCBw cm9vZiwgdGhhdCBpdCdzIGEgZ29vZCBpZGVhIHRvIGJlIGNvbnNlcnZhdGl2ZSBhYm91dA0KICAg cmV0cmFuc21pdHMgaW4gdGhlIGZhY2Ugb2YgcGFja2V0IHJlLW9yZGVyaW5nLl0NCg0KDQo+IDQp IFBhY2tldHMgYXJyaXZlIG91dCBvZiBvcmRlciwgYW5kIHdlIGFyZSBOT1QgYWNraW5nIGV2ZXJ5 IHBhY2tldC4NCj4gCTxBLCBFQ29wdD0xPiAtLS0tLS0tLS0tLS0tLS0tLS0tPiAgIDANCj4gCTxD LCBFQ29wdD0zPiAtLS0tLS0tLS0tLS0tLS0tLS0tPiAgIDENCj4gCQk8LS0tLSA8QUNLKEEpLCBF Q1JvcHQ9MT4NCj4gCTxELCBFQ29wdD00PiAtLS0tLS0tLS0tLS0tLS0tLS0tPiAgIDENCj4gCQk8 LS0tLSA8QUNLKEEpLCBFQ1JvcHQ9ND4JNCwgMSwgb3Igbm8gRUNSIGF0IGFsbD8NCj4gCTxCLCBF Q29wdD0yPiAtLS0tLS0tLS0tLS0tLS0tLS0tPiAgIDENCj4gCQk8LS0tLSA8QUNLKEMpLCBFQ1Jv cHQ9Mj4NCg0KRm9yIHRoZSBzYW1lIHJlYXNvbnMgYXMgYWJvdmUsIHRoZSBhY2sgdGhhdCByZXN1 bHRzIGZyb20gRCBtdXN0IGhhdmUNCkVDUm9wdD0xLCBub3QgNC4NCg0KPiBJbWFnaW5lOg0KPiAg ICAgICAgIDxBLCBFQ29wdD0xPiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0+ICAgMA0KPiAgICAgICAg ICAgICAgICAgPC0tLS0gPEFDSyhBKSwgRUNSb3B0PTE+DQo+IAkgICAgKGNvbm5lY3Rpb24gaXMg aWRsZSBmb3IgYSB3aGlsZS4uLikNCj4gICAgICAgICA8QywgRUNvcHQ9MTAzPiAtLS0tLS0tLS0t LS0tLS0tLS0tPiAgIDENCj4gICAgICAgICAgICAgICAgIDwtLS0tIDxBQ0soQSksIEVDUm9wdD0x MDM+ICAgICAgICAxMDMsIDEsIG9yIG5vIEVDUiBhdCBhbGw/DQo+ICAgICAgICAgPEIsIEVDb3B0 PTEwMj4gLS0tLS0tLS0tLS0tLS0tLS0tLT4gICAxDQo+ICAgICAgICAgICAgICAgICA8LS0tLSA8 QUNLKEMpLCBFQ1JvcHQ9MTAyPg0KPiANCj4gSWYgdGhlIG1pZGRsZSBhY2sgd2FzIDEsIG5vdCAx MDMsIHRoZW4gd2hlbiB0aGUgQUNLIGlzIHJlY2VpdmVkLA0KPiB0aGUgUlRUIHZhbHVlIHRoYXQg aXMgY29tcHV0ZWQgaXMgZ29pbmcgdG8gYmUgZHJhc3RpY2FsbHkgb3V0IG9mIHdhY2suIA0KDQpS ZW1lbWJlciwgMTA3MiBjaGFuZ2VkIHRoZSBpbmZvcm1hdGlvbiBhdmFpbGFibGUgdG8gY29tcHV0 ZSB0aGUNCnJ0dC4gIEl0IGRpZCAqbm90KiBjaGFuZ2UgKndoZW4qIHRoZSBydHQgaXMgY29tcHV0 ZWQgKGkuZS4sIG9ubHkNCndoZW4gbmV3IGRhdGEgaXMgYWNrZWQpLiAgVGhlICpvbmx5KiB3YXkg dGhlIEVDUm9wdCBpbiB0aGUgYWNrDQpyZXN1bHRpbmcgZnJvbSBDIGNhbiBiZSB1c2VkIGlzIHdo ZW4gdGhlIGFjayBmcm9tIEEgaXMgZHJvcHBlZA0KKGFuZCwgb2YgY291cnNlLCBDIG11c3QgYmUg c2VudCBiZWZvcmUgdGhlIHNlbmRlciB0aW1lcyBvdXQgJg0KcmV0cmFuc21pdHMgQSkuICBJbiB0 aGlzIGNhc2UsIHRoZSBzZW5kZXIgc2hvdWxkIGdldCBFQ1JvcHQ9MSBpbg0KdGhlIGFjayBmcm9t IEMgc28gaXQgd2lsbCBjb21wdXRlIGEgcmVhc29uYWJsZSBydHQgZm9yIEEuICBUaGlzDQp3aWxs IGluZmxhdGUgTCBidXQgdGhhdCdzIHBlcmZlY3RseSBsZWdpdGltYXRlIC0tIHBhY2tldCBsb3Nz IGluDQp0aGUgcmV2ZXJzZSBwYXRoIGluY3JlYXNlcyB1bmNlcnRhaW50eSBhdCB0aGUgc2VuZGVy IHNvIGl0DQp3YW50cyB0byBiZSBtb3JlIGNvbnNlcnZhdGl2ZSBhYm91dCByZXRyYW5zbWl0aW5n Lg0KDQpHb2luZyBiYWNrIHRvIEJvYidzIGxhc3Qgbm90ZSwNCg0KPiBXaGVuIGEgaG9zdCByZWNl aXZlcyBhbiBFQ1JvcHQsIGl0IGhhcyB0byBiZWxpZXZlIGl0IGFuZCB1cGRhdGUNCj4gaXRzIFJU VCBlc3RpbWF0ZSAoSSBkb24ndCBzZWUgYSBzaW1wbGUgYWx0ZXJuYXRpdmUpLiAgVGhlcmUgYXJl DQo+IHRpbWVzIHdoZW4gaXQgU0hPVUxEIE5PVCBiZWxpZXZlIGl0IChhbiBFQ1JvcHQgaW4gYSBk YXRhIHNlZ21lbnQNCj4gY29taW5nIHNvbWUgbG9uZyBpZGxlIHBlcmlvZCBidXQgY2Fycnlpbmcg YSB0aW1lc3RhbXAgZWNob2VkDQo+IGZyb20gYW4gQUNLLikNCg0KVGhlICJiZWxpZXZlIGl0IiBw YXJ0IG9mIHlvdXIgc3RhdGVtZW50IGlzIGNvcnJlY3QgYnV0IHRoZSAiYW5kDQp1cGRhdGUgdGhl IHJ0dCBlc3RpbWF0ZSIgZG9lc24ndCBmb2xsb3cuICBOb3doZXJlIGluIHJmYzEwNzINCmRpZCB3 ZSBzcGVjaWZ5IHRoZSBzZW5kZXIncyBydHQgZXN0aW1hdGlvbiBhbGdvcml0aG0uICBJdCBuZXZl cg0Kb2NjdXJyZWQgdG8gbWUgdGhhdCBhbnlvbmUgd291bGQgY29uY2VpdmUgb2YgY2hhbmdpbmcg d2hhdA0KY3VycmVudGx5IGhhcHBlbnMgd2l0aG91dCBlY2hvL2VjaG8tcmVwbHkgLS0tIHRoZSBy dHQgZXN0aW1hdGUNCmlzIHVwZGF0ZWQgb25seSBvbiAnbmV3JyBhY2tzIChvbmVzIHRoYXQgbW92 ZSBzbmQudW5hKS4gIEFzc3VtaW5nDQp0aGF0IHBlb3BsZSBkb24ndCBtYWtlIGdyYXR1aXRvdXMg Y2hhbmdlcyB0byB0aGUgcnR0IGVzdGltYXRlDQpzZW1hbnRpY3Mgd2hpbGUgaW1wbGVtZW50aW5n IDEwNzIsIHRoZSBzY2VuYXJpbyB5b3UncmUgd29ycmllZA0KYWJvdXQgY2FuJ3QgYXJpc2UgYW5k IGV2ZXJ5IHBhY2tldCBzaG91bGQgY29udGFpbiBhbiBFQ1JvcHQuDQoNCj4gQ29uc2lkZXIgYSBz aW1wbGV4IGRhdGEgdHJhbnNmZXIuICBBc3N1bWluZyB0aGUgQUNLcyBjYXJyeQ0KPiBFQ29wdHMs IGlmIHdlIGVjaG8gdGhlIEFDSyB0aW1lc3RhbXBzIGluIHRoZSBkYXRhIHNlZ21lbnRzLCB0aGVu DQo+IHRoZSBkYXRhIHJlY2VpdmVyIG11c3QgY2FsY3VsYXRlIGFuIFJUVCB0aGF0IGl0IHdpbGwg bmV2ZXIgdXNlLA0KPiBldmVyeSB0aW1lIGl0IHJlY2VpdmVzIGEgZGF0YSBzZWdtZW50LiAgVGhh dCB3YXN0ZWQgcHJvY2Vzc2luZw0KPiBpcyBtdWNoIGdyZWF0ZXIgdGhhbiB0aGUgcHJvY2Vzc2lu ZyB0byBpbmNsdWRlIG9yIGV4Y2x1ZGUgYW4NCj4gRUNSb3B0IG9wdGlvbi4NCg0KU2FtZSBtaXN0 YWtlIGFzIGFib3ZlOiAgMTA3MiBkaWQgbm90IHN1Z2dlc3QgdGhhdCB0aGUgcnR0DQplc3RpbWF0 aW9uIHNlbWFudGljcyBiZSBjaGFuZ2VkLiAgSS5lLiwgdGhlIGludGVudCB3YXMgdGhhdA0KYW4g aW1wbGVtZW50YXRpb24gdXNlIGV4YWN0bHkgdGhlIGNvZGUgaXQgZG9lcyBub3cgYnV0IHRoZQ0K c3RlcCB0aGF0IGxvb2tzIGxpa2UgKGluIEJTRCk6DQoJDQoJLyoNCgkgKiBJZiB0cmFuc21pdCB0 aW1lciBpcyBydW5uaW5nIGFuZCB0aW1lZCBzZXF1ZW5jZQ0KCSAqIG51bWJlciB3YXMgYWNrZWQs IHVwZGF0ZSBzbW9vdGhlZCByb3VuZCB0cmlwIHRpbWUuDQoJICovDQoJaWYgKHRwLT50X3J0dCAm JiBTRVFfR1QodGktPnRpX2FjaywgdHAtPnRfcnRzZXEpKSB7DQoJCXRjcF94bWl0X3RpbWVyKHRw LCB0cC0+dF9ydHQpOw0KCQl0cC0+dF9ydHQgPSAwOw0KCX0NCg0KY291bGQgYmUgYXVnbWVudGVk IHRvIHRpbWUgZXZlcnkgcGFja2V0IGlmIGVjaG8gd2FzIG5lZ290aWF0ZWQ6DQooaW4gNC40LCAi ZWNob19yZXBseSIgcG9pbnRzIHRvIHRoZSBFQ1JPUFQgaW4gYW4gaW5jb21pbmcgcGFja2V0DQoo aWYgdGhlcmUgaXMgb25lKSAmIEVYVFJBQ1RfRUNST1BUIGlzIGEgbWFjaGluZSBkZXBlbmRlbnQg KGUuZy4sDQphbGlnbm1lbnQgY29uc3RyYWludHMpIG1hY3JvIHRvIG1hcnNoYWxsIHRoZSB0aW1l c3RhbXAgaW4gdGhlIG9wdGlvbi4pDQoNCglpZiAoZWNob19yZXBseSkNCgkJdGNwX3htaXRfdGlt ZXIodHAsIG5vdyAtIEVYVFJBQ1RfRUNST1BUKGVjaG9fcmVwbHkpKTsNCgllbHNlIGlmICh0cC0+ dF9ydHQgJiYgU0VRX0dUKHRpLT50aV9hY2ssIHRwLT50X3J0c2VxKSkgew0KCQl0Y3BfeG1pdF90 aW1lcih0cCwgdHAtPnRfcnR0KTsNCgkJdHAtPnRfcnR0ID0gMDsNCgl9DQoNCkJ1dCB0aGlzIHJ0 dCBlc3RpbWF0ZSB1cGRhdGUgY29kZSBpcyBleGVjdXRlZCAqb25seSogd2hlbiBuZXcNCmRhdGEg aXMgYWNrZWQgKHNuZF91bmEgbW92ZXMgZm9yd2FyZCkgYW5kIG5vIG9uZSBwcm9wb3NlZA0KY2hh bmdpbmcgdGhhdC4gIFRodXMgdGhlcmUgaXMgbm8gd2FzdGVkIGVmZm9ydCB1cGRhdGluZyBydHQN CmZvciB0aGUgcmVjZWl2ZXIgc2lkZSBvZiBhIHNpbXBsZXggY29ubmVjdGlvbiAoc2luY2Ugc25k X3VuYQ0Kd2lsbCBuZXZlciBtb3ZlKS4gIFRoZSBvbmx5IGNvc3Qgb2YgdGhlIEVDUm9wdCB3aGVu IGl0J3Mgbm90DQp1c2VkIGlzIHRoZSBjb3N0IG9mIHNldHRpbmcgdXAgdGhlIGVjaG9fcmVwbHkg cG9pbnRlciAoaWYgd2UNCnNwZWNpZnkgYSAnc3VnZ2VzdGVkIG9yZGVyJyBmb3IgdGhlIEVDL0VD UiBvcHRzLCB0aGlzIGNhbg0KYmUgZG9uZSBpbiB0d28gaW5zdHJ1Y3Rpb25zKS4NCg0KPiBBbSBJ IGNvbnZpbmNpbmcgeW91Pw0KDQpCeSBub3csIHlvdSd2ZSBwcm9iYWJseSBndWVzc2VkIHRoZSBh bnN3ZXIgdG8gdGhpcyBvbmUgOikuDQoNCiAtIFZhbg0KIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IEFsZnJlZCBIw45uZXMgW21haWx0bzphaEBUUi1TeXMuZGVdIA0K PiBTZW50OiBNb250YWcsIDIyLiBNw6RyeiAyMDEwIDIwOjE2DQo+IFRvOiB0Y3BtQGlldGYub3Jn OyBtYWxsbWFuQGljaXIub3JnDQo+IFN1YmplY3Q6IFJlOiBbdGNwbV0gcG9sbCBmb3IgYWRvcHRp b24gb2YgDQo+IGRyYWZ0LWdvbnQtdGNwbS10Y3AtdGltZXN0YW1wcy0wMw0KPiANCj4gTWFyayBB bGxtYW4gd3JvdGU6DQo+ID4gLi4uDQo+ID4NCj4gPiAgIC0gQnV0LCB0byBtZSwgdGhlIHJpZ2h0 IHRoaW5nIHRvIGRvIGhlcmUgaXMgdG8gcm9sbCB0aGVzZSBjaGFuZ2VzDQo+ID4gICAgIGludG8g dGhlIHdvcmsgaXRlbSB0aGlzIFdHIGFscmVhZHkgaGFzIGdvaW5nOiAxMzIzYmlzLiAgWy4uLl0N Cj4gDQo+IEdvaW5nPyAgR29uZSA/Pw0KPiBJdCdzIGxpc3RlZCBvbiA8aHR0cDovL3Rvb2xzLklF VEYuT1JHL3dnL3RjcG0vPjoNCj4gDQo+ICAgIEV4cGlyZWQ6DQo+ICAgIGRyYWZ0LWlldGYtdGNw bS0xMzIzYmlzICAgICAgICAgICAgICAgIC0wMSAgICAyMDA5LTAzLTA0ICBFeHBpcmVkDQo+IA0K PiBbIEFuZCwgYnR3LCAgIC0wMCAgd2FzIHB1Ymxpc2hlZCAgMjAwOC0wMS0yOSwNCj4gICBzbyBl eHRyYXBvbGF0aW5nIGxpbmVhcmx5LCBJIHN0aWxsIGhvcGUgZm9yIGEgLTAyIHNvb24uDQo+ICAg QnV0IHRoZSBjb25maWRlbmNlIGxldmVsIG9mIHN0YXRpc3RpY3MgYmFzZWQgb24gYSBzYW1wbGUg b2Ygc2l6ZSAyDQo+ICAgaXMgcmF0aGVyIHNtYWxsLiAgOi0pIF0NCj4gDQo+IEEgc2lnbmlmaWNh bnQgcGFydCBvZiBteSByZXZpZXcgY29tbWVudHMgZnJvbSBlYXJseSBpbiAyMDA5IA0KPiBoYXZl IGJlZW4gYWRkcmVzc2VkIGluIHRoZSAtMDEgZHJhZnQgdmVyc2lvbiwgYnV0IG90aGVyLCANCj4g bm9uLXRyaXZpYWwsIHBhcnRzIGhhdmUgYmVlbiBkZWZlcnJlZCB0byB0aGUgbmV4dCB1cGRhdGUu ICBJIA0KPiBjYW5ub3QgcmVjYWxsIGRpc2N1c3Npb24gb2YgdGhpcyBkcmFmdCBvbiB0aGUgbGlz dCBzaW5jZSBhIA0KPiB2ZXJ5IGxvbmcgdGltZS4NCj4gDQo+IA0KPiBTbyBpdCBsb29rcyBsaWtl IHRoZSBjaG9pY2UgZm9yIHRoZSBXRyBtaWdodCBiZSBoYXZpbmcgYSANCj4gc2hvcnQgZG9jdW1l bnQgdGhhdCBjYW4gYmUgc2hpcHBlZCBieSB0aGUgZW5kIG9mIHRoaXMgeWVhciANCj4gKG9yIGV2 ZW4gbXVjaCBmYXN0ZXIpLCBvciB3aXRoIGEgLTEzMjNiaXMgaW4gNSB5ZWFycyBvciBzby4NCj4g DQo+IChPciB3b3VsZCB5b3UgcHJlZmVyIGRvaW5nIGJvdGg/KQ0KPiANCj4gSUlSQywgRmVybmFu ZG8ncyB0aW1lc3RhbXAgZHJhZnQgaGFzIGJlZW4gcGhyYXNlZCBhcyBhIEJDUCANCj4gYmVjYXVz ZSBmZWVkYmFjayBmcm9tIHRoZSBXRyAoTVBMUyBJRVRGPykgaW5kaWNhdGVkIGl0IHdvdWxkIA0K PiBub3QgYmUgYWNjZXB0YWJsZSB0byB0aGUgV0cgd2l0aCBub3JtYXRpdmUgbGFuZ3VhZ2UsIG9u IHRoZSANCj4gU3RhbmRhcmRzIFRyYWNrLg0KPiANCj4gSSBwZXJzb25hbGx5IHdvdWxkIG5vdCBv cHBvc2UgdG8gU3RhbmRhcmRzIFRyYWNrLCBidXQgSSdtIG5vdCB0aGUgV0cuDQo+IA0KPiANCj4g S2luZCByZWdhcmRzLA0KPiAgIEFsZnJlZC4NCj4gDQo+IC0tIA0KPiANCj4gKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0t LS0tLS0rDQo+IHwgVFItU3lzIEFsZnJlZCBIb2VuZXMgICB8ICBBbGZyZWQgSG9lbmVzICAgRGlw bC4tTWF0aC4sIA0KPiBEaXBsLi1QaHlzLiAgfA0KPiB8IEdlcmxpbmdlciBTdHJhc3NlIDEyICAg fCAgUGhvbmU6ICgrNDkpNzE1Ni85NjM1LTAsIEZheDogLTE4IA0KPiAgICAgICAgIHwNCj4gfCBE LTcxMjU0ICBEaXR6aW5nZW4gICAgIHwgIEUtTWFpbDogIGFoQFRSLVN5cy5kZSAgICAgICAgICAg ICANCj4gICAgICAgICB8DQo+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tKw0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdGNwbSBtYWlsaW5nIGxpc3QN Cj4gdGNwbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RjcG0NCj4gDQo= From wes@mti-systems.com Thu Nov 25 23:12:08 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D623A6A5A for ; Thu, 25 Nov 2010 23:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3hGw2SVeGlE for ; Thu, 25 Nov 2010 23:12:06 -0800 (PST) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by core3.amsl.com (Postfix) with ESMTP id 68A233A698D for ; Thu, 25 Nov 2010 23:12:06 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id oAQ7D8fv005728 for ; Fri, 26 Nov 2010 02:13:09 -0500 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.73.245] ([174.130.73.245:9199] helo=[192.168.1.104]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 03/BC-20706-40E5FEC4; Fri, 26 Nov 2010 02:13:08 -0500 Message-ID: <4CEF5E06.9070202@mti-systems.com> Date: Fri, 26 Nov 2010 02:13:10 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] draft Beijing minutes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 07:12:08 -0000 Draft minutes from the IETF79 / Beijing meeting are online at: http://www.ietf.org/proceedings/79/minutes/tcpm.txt Please send me any corrections. The cutoff day for submitting the corrections is January 5, 2011, so I'll need any proposed changes within a couple of days prior to that. From lars.eggert@nokia.com Thu Nov 25 23:40:56 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E0D3A6A0C for ; Thu, 25 Nov 2010 23:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVAejjL0EvCk for ; Thu, 25 Nov 2010 23:40:55 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id B880D3A69CC for ; Thu, 25 Nov 2010 23:40:55 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oAQ7fp1K030698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Nov 2010 09:41:52 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-8-1064979525; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Fri, 26 Nov 2010 09:41:48 +0200 Message-Id: <8D115556-6013-45ED-B3E6-D30E02644A0A@nokia.com> References: To: Jerry Chu X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Fri, 26 Nov 2010 09:41:49 +0200 (EET) X-Nokia-AV: Clean Cc: tcpm@ietf.org Subject: Re: [tcpm] response to questions raised at Beijing's meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 07:40:56 -0000 --Apple-Mail-8-1064979525 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-11-25, at 23:27, Jerry Chu wrote: > I have not seen the meeting minutes but two questions were raised > during the just passed IETF meeting, one from Lars on whether the > User Completion Time (UCT) as reported from our testbed includes > time spent on 3WHS, the other on whether raw test data from our > testbed can be made available. >=20 > The answer to the 1st question is No, our UCT does not include 3WHS. > If this is believed to be important we can certainly rerun tests to > include 3WHS. thanks for checking this. I believe that it would be good to see results where UTC is the time = from when the SYN is sent until the connection closes. There are two = reasons: (1) If SYNs or SYN-ACKs are lost, your current metric doesn't capture = the impact of the resulting 3-second retransmit timer. Since packet loss = rates are sometimes somewhat higher with IW10 compared to IW3, I'd = expect at least some SYNs and SYN-ACKs to be lost. (2) Not including the SYN exchange in UTC overestimates the actual delay = improvement with IW10, because the current UTC times are at least 1.5RTT = lower than what a user would actually see (click-wait-read). Lars= --Apple-Mail-8-1064979525 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag 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 aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEyNjA3NDE0OFowIwYJKoZIhvcNAQkE MRYEFOVDYHGL/ssvB7wsGdTKeakBTj4nMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AKdrdjKbqALm/93TtvX8/nRrqKGul3HWuFExLnSzi7a+EOSarbfPCMHUJLHfnEkv3gk2WG5otNE1 zlBFnqZwMJvByfqpCGWdDCfanNV1Wt4+9nwu/nRGzqC8tisRDAeba9lSmCz7JAuC/OjzQYdweJVB yFVC4N374t3lQ7Un9iesiAy0xp7Z7xKP/I2Da4eVbiqUWdk6EyUgk0MJt1Jhk2/6baOLG3HE0Qyp dk4B2/peiLa6eO2O2l7XEE4Q6EwEHLzgxY0NKvGqRWmgWaWkMjMFIZAqPlrA4hby0obeoD6a1Crn 9FN9/Jq55GnGKnkvDvD3sGMkj8R4p0B9gjNfo4EAAAAAAAA= --Apple-Mail-8-1064979525-- From L.Wood@surrey.ac.uk Fri Nov 26 01:20:16 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672723A6A7C for ; Fri, 26 Nov 2010 01:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atMIatvJnsmU for ; Fri, 26 Nov 2010 01:20:14 -0800 (PST) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 6EEE73A6A7A for ; Fri, 26 Nov 2010 01:20:09 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-8.tower-72.messagelabs.com!1290763269!25986723!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 20098 invoked from network); 26 Nov 2010 09:21:09 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-8.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 26 Nov 2010 09:21:09 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Fri, 26 Nov 2010 09:21:09 +0000 From: To: Date: Fri, 26 Nov 2010 09:21:09 +0000 Thread-Topic: [tcpm] response to questions raised at Beijing's meeting Thread-Index: AcuNS0Lr+mj4P08aRiS6vo1RfGE9Qg== Message-ID: References: <8D115556-6013-45ED-B3E6-D30E02644A0A@nokia.com> In-Reply-To: <8D115556-6013-45ED-B3E6-D30E02644A0A@nokia.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [tcpm] response to questions raised at Beijing's meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 09:20:16 -0000 On 26 Nov 2010, at 07:41, Lars Eggert wrote: > (1) If SYNs or SYN-ACKs are lost, your current metric doesn't capture the= impact of the resulting 3-second retransmit timer. Worth noting that the SYN timer is usually 3 seconds with further exponenti= al backoff, but varies somewhat between implementations in value and how of= ten they repeat before giving up. ( I think Linux quits after 6 attempts, B= SD after 9.) Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From mike@belshe.com Fri Nov 26 10:09:31 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF87528C0ED for ; Fri, 26 Nov 2010 10:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.252 X-Spam-Level: ** X-Spam-Status: No, score=2.252 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DC_PNG_UNO_LARGO=0.558, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=0.001, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8BNZ-UOqmfA for ; Fri, 26 Nov 2010 10:09:29 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 11B1B3A6A62 for ; Fri, 26 Nov 2010 10:09:28 -0800 (PST) Received: by qyk34 with SMTP id 34so6926746qyk.10 for ; Fri, 26 Nov 2010 10:10:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.238.16 with SMTP id kq16mr1995888qcb.134.1290795031974; Fri, 26 Nov 2010 10:10:31 -0800 (PST) Received: by 10.229.235.3 with HTTP; Fri, 26 Nov 2010 10:10:31 -0800 (PST) Date: Fri, 26 Nov 2010 10:10:31 -0800 Message-ID: From: Mike Belshe To: tcpm@ietf.org Content-Type: multipart/mixed; boundary=0016e64cbf6c5bd4eb0495f8a3ca Subject: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 18:09:31 -0000 --0016e64cbf6c5bd4eb0495f8a3ca Content-Type: multipart/alternative; boundary=0016e64cbf6c5bd4e50495f8a3c8 --0016e64cbf6c5bd4e50495f8a3c8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I thought I'd add a slightly different perspective to the discussion about initial cwnd. I'm a developer on Chrome & SPDY. With SPDY, we want to build an application protocol which is efficient on the transport, good for the network, and faster than HTTP. But right now, TCP is holding us back because we're trying to accomplish with one connection what HTTP does with 10+ connections. Note: I don't want to make this thread about SPDY. I hope the members of this list agree that the goals of SPDY are good and will help make TCP a friendly transport for an application protocol like SPDY. *Background* Unrelated to TCP, HTTP is not very efficient. This has been widely documented and observed for some time. We can easily demonstrate a more efficient protocol, which transfers 25-35% fewer packets than HTTP and reduces bytes transferred by 10-15%. Hopefully everyone agrees those are good things for the network. Unfortunately, any TCP-based protocol which uses a single connection is at = a latency-handicap compared to any protocol that uses multiple connections. This is due to IW. Further, because bandwidth increases have outpaced RTT decreases, bandwidth is relatively cheap. So, being efficient on your bandwidth is less critical than being efficient on your round-trips. To visualize the effects, please see the attached graph. (Or click here) In these tests, I loaded a replica of the facebook landing page through tw= o protocols - one using a single connection in a semi-efficient manner (an early version of spdy) and another using 6 connections (http). I used a high-bandwidth network with either 100ms or 200ms of RTT, and then I varied IW from 2pkts all the way to 128pkts. I chose this network configuration t= o specifically isolate the effects of high-RTT and IW. As you can see, at lo= w IW, the single-connection protocol fares poorly compared to the multi-connection protocol. For another writeup on the problem, see http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf Today, the fastest way to deliver content is to simply side-step cwnd by us= e of multiple connections. *The Problem* With SPDY (or whatever protocol comes next), we can definitely reduce the number of connections out of the browser by *at least* a factor of 6. With unfolding of the subdomain tricks that websites have been doing, we can reduce it by a factor of 10. This has nothing to do with TCP, except I hop= e that folks on this list appreciate that this goodness: fewer connections - fewer packets - and fewer bytes. The only trouble is that *if we abide to the RFCs, fewer connections + fewe= r packets + fewer bytes *equates to* slower web pages. * But I'm not asking that we increase IW by a factor of 10; because it grows exponentially, if we can increase it to somewhere in the ~16 range, it's good enough.** *The Conundrum* More perplexing is that whenever we talk about increasing IW, we tend to think of the static throttle that we have today. If we increase a static throttle, it affects everything. So protocols that are already bursting 20-30x more packets than they should (by way of many connections) will burs= t even more. This makes some people want to do nothing... At the same time, we also know that cwnd has already been increased on the net at large. This started with use of multiple connections, multiplied with the use of multiple subdomains, and is now changing by major sites simply increasing or ignoring cwnd altogther. With so many sites systematically working around cwnd, we know that the current limits can be increased. We just don't know how much. *The Solution?* Is the obvious solution to stop using a static value? It doesn't seem like we're in a one-size-fits-all for IW. The IW could either be defined to be protocol-specific, or dynamic based on number of TCP flows between the same two endpoints. Both of these approaches would offer the benefit of a controlled, increased cwnd to reflect the changes in the net over the last 2 decades but also not completely unthrottle protocols that are already living on the edge of not having throttles. Finally, if a dynamic throttle is too much to decide upon, at least updatin= g the static value seems appropriate. Jerrry and Nandita have provided good data for a general-purpose increase to 10. If inefficient protocols are allowed to go that high, maybe more efficient protocols could be allowed to go higher (with data, of course). *Reality Check* Finally, regardless of this debate in the IETF, what is actually going to happen? a) IETF does not increase the limit (or continues to wait): As time goes on, more and more evidence emerges to demonstrate that the current cwnd limits are unnecessarily conservative. More evidence also emerges that increasing cwnd makes your site faster. More sites start experimenting with their own values of cwnd. Without a blessed recommendation from the IETF, sites choose whatever values they want. Ben Strong offered a writeup today which demonstrates this is already happening . b) IETF increases the limit: With data and a specific recommendation, TCP vendors can quickly move to th= e new recommendations, making their products more competitive in the marketplace, and better for users. Pressure is alleviated from existing sites to go renegade, and instead they can rest on the specific findings from this group. With a modern recommendation in hand, all of us can credibly go after any sites which do choose to use dangerously high cwnd values. Finally, having an officially increased IW is an enabler for a future of more efficient application level protocols, which are currently a= t a disadvantage to their less-efficient counterparts. Now, which of these two options carries more risk of internet collapse? Vendors implementing whatever-the-heck-their-rookie-system-administrator decided to configure? Or an official, controlled and intelligent recommendation from this group? Thanks to everyone on this list for their hard work over the years - although my email is somewhat critical, be aware that I have immense gratitude and respect for the veterans of this list that have been keeping the net flowing for so long with such great success. Mike --0016e64cbf6c5bd4e50495f8a3c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
I thought I'd add a slightly different persp= ective to the discussion about initial cwnd. =A0I'm a developer on Chro= me & SPDY.=A0

With SPDY, we want to build an = application protocol which is efficient on the transport, good for the netw= ork, and faster than HTTP. =A0But right now, TCP is holding us back because= we're trying to accomplish with one connection what HTTP does with 10+= connections.

Note: =A0I don't want to ma= ke this thread about SPDY. =A0I hope the members of this list agree that th= e goals of SPDY are good and will help make TCP a friendly transport for an= application protocol like SPDY.

Background
Unrelated to TCP, HTTP is not very efficient. =A0This has been widely docum= ented and observed for some time. =A0We can easily demonstrate a more effic= ient protocol, which transfers 25-35% fewer packets than HTTP and reduces b= ytes transferred by 10-15%. =A0Hopefully everyone agrees those are good thi= ngs for the network.

Unfortunately, any TCP-based pr= otocol which uses a single connection is at a latency-handicap compared to = any protocol that uses multiple connections. =A0This is due to IW. =A0Furth= er, because bandwidth increases have outpaced RTT decreases, bandwidth is r= elatively cheap. =A0So, being efficient on your bandwidth is less critical = than being efficient on your round-trips. =A0

To visualize the effects, = please see the attached graph. =A0(Or click here) =A0In these tests, I loaded a replica of the f= acebook landing page through two protocols - one using a single connection = in a semi-efficient manner (an early version of spdy) and another using 6 c= onnections (http). =A0I used a high-bandwidth network with either 100ms or = 200ms of RTT, and then I varied IW from 2pkts all the way to 128pkts. =A0I = chose this network configuration to specifically isolate the effects of hig= h-RTT and IW. =A0As you can see, at low IW, the single-connection protocol = fares poorly compared to the multi-connection protocol. =A0 For another wri= teup on the problem, see=A0=A0http://dev.chromium.org/spdy/An_Argument_For_Changing_TC= P_Slow_Start.pdf

Today, the fastest way to= deliver content is to simply side-step cwnd by use of multiple connections= .


The Problem
With SPDY (or whatever protocol co= mes next), we can definitely reduce the number of connections out of the br= owser by *at least* a factor of 6. =A0With unfolding of the subdomain trick= s that websites have been doing, we can reduce it by a factor of 10. =A0Thi= s has nothing to do with TCP, except I hope that folks on this list appreci= ate that this goodness: =A0fewer connections - fewer packets - and fewer by= tes.

The only trouble is that if = we abide to the RFCs, fewer connections + fewer packets + fewer bytes e= quates to=A0slower web pages.=A0

But I'm not asking that we = increase IW by a factor of 10; because it grows exponentially, if we can in= crease it to somewhere in the ~16 range, it's good enough.


The Conundrum
More perplexing is that whenever= we talk about increasing IW, we tend to think of the static throttle that = we have today. =A0If we increase a static throttle, it affects everything. = =A0So protocols that are already bursting 20-30x more packets than they sho= uld (by way of many connections) will burst even more. =A0

This makes some people want to = do nothing...

At the same time, we also know = that cwnd has already been increased on the net at large. =A0 This started = with use of multiple connections, multiplied with the use of multiple subdo= mains, and is now changing by major sites simply increasing or ignoring cwn= d altogther. =A0With so many sites systematically working around cwnd, we k= now that the current limits can be increased. =A0We just don't know how= much.


The Solution?
Is the obvious solution to stop = using a static value? =A0It doesn't seem like we're in a one-size-f= its-all for IW. =A0

The IW could either be defined = to be protocol-specific, or dynamic based on number of TCP flows between th= e same two endpoints. =A0Both of these approaches would offer the benefit o= f a controlled, increased cwnd to reflect the changes in the net over the l= ast 2 decades but also not completely unthrottle protocols that are already= living on the edge of not having throttles.

Finally, if a dynamic throttle = is too much to decide upon, at least updating the static value seems approp= riate. =A0Jerrry and Nandita have provided good data for a general-purpose = increase to 10. =A0If inefficient protocols are allowed to go that high, ma= ybe more efficient protocols could be allowed to go higher (with data, of c= ourse).


Reality Check
Finally, regardless of this deba= te in the IETF, what is actually going to happen?

a) IETF does not increase the limit (or continue= s to wait):
As time goes on, more and more evidence emerges to demonstrate that th= e current cwnd limits are unnecessarily conservative. =A0More evidence also= emerges that increasing cwnd makes your site faster. =A0More sites start e= xperimenting with their own values of cwnd. =A0Without a blessed recommenda= tion from the IETF, sites choose whatever values they want. Ben = Strong offered a writeup today which demonstrates this is already happening= .

b) IETF increases the limit:
With data and a specific recom= mendation, TCP vendors can quickly move to the new recommendations, making = their products more=A0competitive=A0in the marketplace, and better for user= s. =A0Pressure is alleviated from existing sites to go renegade, and instea= d they can rest on the specific findings from this group. =A0With a modern = recommendation in hand, all of us can credibly go after any sites which do = choose to use dangerously high cwnd values. =A0Finally, having an officially increased IW is an enabler for = a future of more efficient application level protocols, which are currently= at a disadvantage to their less-efficient counterparts.


Now, which o= f these two options carries more risk of internet collapse? =A0Vendors impl= ementing whatever-the-heck-their-rookie-system-administrator decided to con= figure? =A0Or an official, controlled and intelligent recommendation from t= his group?


Thanks to everyone on this list for their hard work over the years - althou= gh my email is somewhat critical, be aware that I have immense gratitude an= d respect for the veterans of this list that have been keeping the net flow= ing for so long with such great success.
Mike
--0016e64cbf6c5bd4e50495f8a3c8-- --0016e64cbf6c5bd4eb0495f8a3ca Content-Type: image/png; name="effect_of_initial_cwnd_on_plt (1).png" Content-Disposition: attachment; filename="effect_of_initial_cwnd_on_plt (1).png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggzbzoet0 iVBORw0KGgoAAAANSUhEUgAAAoYAAAJJCAYAAAA3NPYYAABpyElEQVR42uydC3hUxfm4ERCIAkVA BSuKIsTWG4ooCpXECwgFr2CxWn8gaLFqCS0qRVsRKAVEC4IFBQGNCiJSghAid5WigHJVUG6BhKsB kpCEEEj4/n6T/znZJLubTbLXnPd9nnmy2TM7uzt7Oe9+M/NNNQEAAAAA+JlqdAEAAAAAIIYAAAAA gBgCAAAAAGIIAAAAAIghAAAAACCGAAAAAIAYAgAAAABiCAAAAACIIQAAAAAghgAAAACAGAIAAAAA YggAAAAAiCEAAAAAIIYAAAAAgBgCAAAAAGIIAAAAAIghAAAAACCGAAAAAIAYAgAAAABiCAAAAACI IQAAAAAghgAAAACAGELoOXnypIwfP146duwojRs3lpo1a0q1atXsUtn6ELjXwusH3uV2wXhtAnV/ wXwewe4zx52E6F8AxBCC8+XqS3FHRkaGXH/99T7frrz1wXf83beIIeKCGEbe93f16tXlvPPOk+uu u07++Mc/yqpVqwLWpxU9l/A6IoZQhcXwueeeK9ftylufk5Hv+Ltvw1EMK/KYEEPE0Onf3w8++KAc P34cMQTEEAIvhldccUWpem+++abk5eX5pT4nI9/xd98ihogLn8Wq8/0dGxsrBQUFiCEghhDYL9da tWqVasubiJS3PiejwL0WiAHiwutf9frg6NGj8p///Efq1KlTqt57770XtD7ltUIMwaFfruVtKxK/ LCLlMTvhixgx5LsLMfStD8aOHVuqXqdOnRBDQAwhMB/Y8g4RVGZIQVfazpgxQ+6//35p3ry51K5d W2rUqGFW3d5+++0ybtw4j/NnXMnPz5e5c+fK//3f/8mvfvUrM0FbV+02aNBAbrrpJjNHb/369RV6 jpX50svMzDQrifVLu2nTpuYxaWnSpIncdddd8u9//1vS09P99lr4833iqc6ZM2fk7bffljZt2pjX q169enLzzTebSIa74ayy7q8yr4Uvz2PXrl0yZcoUefLJJ6V9+/byy1/+Us455xwzkV//6jB9jx49 5P3335dTp04F7WRY3vesop+Rko8hMTGxWJ3+/fsXO/7UU08VO671S7Zx2WWXBey1t5g5c6bcdttt UrduXRMBv+aaa+S1116T06dPB6R/K/vZC1Q/+OP7e//+/aXqnX/++YghIIYQ2WK4fPlyueSSS8q8 zYUXXiiLFy/2+HjXrl0r0dHR5br/YIjhf//7XyO4ZbXdsGFDmTNnTkSIoYp89+7dPT4GFaxwE8Py tP3rX/9adu7cGfCTYUXes8rjjz9e6vigQYOK1dHn4Hr8qquuKnb8r3/9a6k2+vbtG7DXXgW4V69e Hm8XExMjOTk5fu1ff3z2/N0P/vz+VpkuWe/ss89GDAExhMgVw4ULF5ovMl9vp7/0k5KSSj1WFUZ3 8+9CLYYfffSRiUj52v5ZZ51lIirhLoYa3SrrcXz44YcRK4ZaWrVqJbm5uQE7GVb0PatoVLPk8Rtu uME+npaWZt5LJd9bR44cseu4S3v0wQcfBOy1Hzx4cJm3+/3vf++3/vXXZ8/f/eDP7+99+/YRMQTE EPwvdWV9oAM1x1BPUvpLveSX8yuvvCKHDh0yJ+V58+ZJo0aNSn3xuQ796ERsd1EBPVEuWrTIDEHr Ag2NAE2bNs0MIwbjC+7gwYNmaKnk8xs1apQcO3bMPIcxY8aUOoHrEJveNhhfxJURqn/+858mr2JK SopJtu2vuU6BWpV87bXXyvDhw02EWk+oJ06cMFGsn376ST7++GNp0aJFqTYmT54ckNegsu/ZAwcO uM1tp+8rK1Lm7nHq58m6f3fSVPJ956/Xfvv27WZqSMnPwujRo81j1vKvf/2r1Gehov3r78+ePz8D /hSuV199lTmGgBhC1RHDESNGlKqnw1slmTVrVql6+qVuoV/OJY/rvCUdlgrlF9w//vGPUm1qMtqS 6HUl6+ltw1kMe/fuXazOunXr/Ba5CFW6mm+//bZUG3fffXdA7ssf79krr7yyVBuffPKJOTZw4ED7 OteVq3/5y1/McR02LXlbnd8YqNfeXf5Nd5+Ffv36+aV//f3Z8+dnwB+fS5XbSZMmsSoZEEOoWmKo k7RL1tu2bVupeho9KVmvQ4cO9vF27dqVOj579uyQf8G1bdu2VJurV68uVe9///tfqXp623AWwy+/ /LJYHZ3gX7KORogiSQx1sUDJNi666KKA3Jc/3rN/+tOfSrXx9NNPm2O6GML1OuvyjTfeWOZtA/Ha 6/368lnQHTz80b/+/uz58zMQqO/vQOUxRAyBV7UKi2Gw2vK1fv369Sv8BagrNy1+8YtflDquw4Oh /oIrOZSlRU8eJdGhqJL19DmFsxiWfB46JOsv6QukGOrJ/NlnnzU/SnQxU1lz/AI1kd8f71lPUT/9 IWUN2+pw8d69e+1hY70+KyvLa7QxEK+9rrD25bOgQ7z+6F9/f/b8+RkIlBjqzifuniNiCIghRIwY eppP5EvRE52Fu7lSVuqLUH7BuXt+7n7NuzuhuD6/cBRDTdMRKOkLhBhq+hlPCxvKG0n3x2vgj/es p3mC06dPty/rAhOldevWbo+7m58YiNe+5PzC8nwWKtK//v7s+fMz4A8x1Meosq3zZjX9UiD3SkYM gVcVMQyaGLr7VV+RE3ZVjBhqNDWcxTCQbQVCDIcNG+a3bbzCJWKouFtZ7LqIZsCAAaben//8Z7fH 3a1oDsRrH0kRQ3efPX9+BkLxfYQYAmIIESGG7uYB6WrR8uJurmI4zDH0dV5VJM4xjDQxdCdDzzzz jOzZs8dEjRR3OeECJYb+eM8q7nIRuhYrN5+uuvZWr2QORH+/9q5zHoMxx9Dfnz3EEDFEDAExDIIY Dh06tFS9F198sdyPz93qZl3hqelIfMXdXDNNYFsZ3K2M1N0oShKJq5ID2VZFXouy2nXXZskchZof M1hi6I/3rKJ5QL0JnxWFPHz4sNd6JXdN8fdrr+Lpy2chkKuSK/PZQwwRQ8QQEMMgiKGerEoOqenc IE218d1335k8bjo3TJP1fvPNN2bLPN3WS6M/ruhcq5K5DkvmhNN2NDqkCXx1h4WSuNti7K233vK6 NVpZaK45zYvmLnebDpnpMJbmIXOXS01v61QxrMhrUVa7uv2dOwHQ947KmEbWNLVIsMTQH+9ZRReS aNJ3d49JF5i44mmHFV1go+0EUgx//PHHUvMh9X2vaaf0s6BFcwz6K4+hvz97iCFiiBhClRTDiqas CZQYKrpHrLuJ6eV9nJ999lmFd5FQ3G0x5o8vPN35oDyLbLSu7moRTieMYIthRV6Lsupo/r6y2nzo oYeCJob+eM9a3HLLLW7rP/HEEz5F42699dZKv998qecul2HJ8vDDD4flZ68qiqE/dlFCDBFDQAz9 LobKihUrfNoruaz21qxZY7Yxq8jtdYcJTYHjbzFU5s+f7zY65G6/Vt2xItwiCcEWw4q8FmXV0Qic uzmtVtG8gu7yZQZSDCv7nrXQ6Rfu6sfHxxerp4mP3dV76aWXgiKGOoezZ8+eHp/fb37zG8nOzg7L zx5iiBgihoAYBlEMFR021l/rv/vd78xQsa4q1KGnc845R5o1a2a2BNO0DFOmTJFdu3Z5bEcXEmgU 8g9/+IMZOtOhao1I6qrIm266ycx10h0u3KHDdprkV3PBnXvuuX79wtOhuokTJ8pvf/tbM6ypOxZo 0QTKXbp0kfHjxxsxCYcTRqjFsCKvhS/t6jxFHUrU1C1RUVEmWnfVVVfJyJEj7TmMwRbDyr5nFd3i z91j0vyFJfvUXT29fTCFSD/nmqBeX1cdxtbXQF8Xa6qAv/vXH589xBAxRAwBAAAAADGkCwAAAAAA MQQAAAAAxBAAAAAAEEMAAAAAQAwBAAAAADEEAAAAAMQQAAAAABBDAAAAAEAMAQAAAAAxBAAAAADE EAAAAAAQQwAAAABADAEAAAAAMQQAAAAAxBAAAAAAEEMAAAAAQAwBAAAAADEEAAAAAMQQAAAAABBD AAAAAEAMAQAAAAAxBAAAAADEEAAAAAAQQwAAAABADAEAAAAAMQQAAAAAxBAAAAAAEMOw4dSpU3L9 9ddLtWrV7OIvUlJSJC4uTqKjo6V27dqm6OWBAwdKampqRLUBAAAAiGGV56WXXiomhf4Sw8TERKlX r16ptq1Sv359WbRoUUS0AQAAAIhhlWfNmjVSo0YNOffcc/0qhlu2bJGoqCjTlkrZtGnT5Pjx46bo ZUvUtI7WDec2AAAAADGs8pw4ccIMp6oYTZw40a9iGBMTY7eVkJBQ6rheZx2PjY0N6zYAAAAAMazy /PnPfzZCdPvtt8uZM2f8JoYbN26022nbtq3HenrMqrd58+awbAMAAAAQwyrP8uXL5ayzzjJDqXv2 7CnsDD+J4bBhw+x2Ro0a5bGeHrPqDR8+PCzbAAAAAMSwSpOZmSmXXnqpEaG33367qDP8JIZdunSx 21EB9cSyZcvsel27dg3LNjyhcxQPHDhgl+3bt8vWrVvlxx9/pFAolCpTfvrpJ0wBEMOqTu/evY0E de7cuXhn+EkMW7RoYbezd+9ej/U0UmnVa9myZVi24asY6sIVHbrmREKhUKpK0e81b9+dAIhhFcBa bPGLX/xC9u3bFxAxrFu3rt1OTk6Ox3rZ2dnFUsaEYxu+Yn2RAgBUFawfvgCIYRUlLS1NLrzwQiNA M2bMKN0ZfhLD6tWr2+0UFBR4rKfHrHqaMicc20AMAQAxBEAMqyQPPvigkZ/u3bu77wzEEDEEAEAM ATGs+sTHxxvxadiwoccPOkPJDCUDACCGgBg6gAYNGhjx+eCDDzx3BotPfF58ghgCAGIIgBhG7hP1 sE+wL6W8OCFdDWIIAIghAGKIGPqAExNcI4YAgBgCIIZVVh4rgxO3xEMMAQAxBEAMEUMPxMTE2G1p 7sSSWPkUtcTGxoZ1G4ghACCGAIghYliJepoxPyoqytTR/ZinT59udgvRopf1Oj2mdbRuOLeBGAIA YgiAGCKGlay3cOFCW7zcFT2WmJgYEW0ghgCAGAIghohhCXQbPV/m7VmkpKTIgAEDpFWrVlKrVi1T oqOjJS4uTlJTU316XOHSBmIIAIghAGIILliJsrUkJSXRIYghACCGAIihU+nTp4+Rwvbt29MZiCEA IIYAiKGTad68eZkJoxFDAADEEAAxBMQQAAAxBEAMATFEDAEAMQRADAEQQwBADAEQQwDEEAAQQwDE EAAxBADEEAAxBEAMAQAxBEAMARBDAEAMARBDAMQQABBDAMQQADEEAMQQADEEQAwBADEEQAwBEEMA QAwBEEMAxBAAEEPEEBBDAMQQAAAxBMQQADEEAEAMATEEQAwBABBDQAwBEEMAAMQQADEExBAAADEE QAwBMQQAQAwBEEMIqRjmF4gcyiig0wAAMQRADMHJYphyJF9+/0aGPDUlk04DAMQQADEEJ4th3ukz 8rtxGdJpxDHZknKajgMAxBAAMQSniqEyY+UJI4bDP8mm4wAAMQRADMHJYngsq0C6jDxmSlomcw0B ADEEQAzBsWKojJybbaKGGj0EAEAMARBDcLAY6vxCFUOdb6jzDgEAEEMAxBAcKoaKrkxWOVy2JY8O BADEEAAxBCeL4aINJ40YPvMOqWsAADEEQAzB0WKoQ8g9X083crh1H6lrAAAxBEAMwbFiqLyzvDB1 jS5GAQBADAEQQ3CwGGq6Gk1b021UukljAwCAGAIghuBQMVQ00bVGDT9clUtHAgBiCIAYgpPFcH1y UeqafIKGAIAYAiCG4FwxVJ58qzB1zcrvSV0DAIghAGIIjhbDBd8Wpq4ZMP04nQkAiCEAYghOFkNN XfPA2MLUNT8eyKdDAQAxBEAMwaliqLy9tDB1zdj5pK4BAMQQADEER4vhoYyi1DUZOeyfDACIIQBi CI4VQ+XvH2WZqOFHq0ldAwCIIQBiGGC2bt0qo0aNki5dukizZs2kVq1aUqdOHWnRooU89thj8tVX X/mnY6tV87mURUpKisTFxUl0dLTUrl3bFL08cOBASU1N9enx+KONYIjhul2njBj+/g1S1wAAYgiA GAb6CZchaWeddZb87W9/CxsxTExMlHr16nm8bf369WXRokUBbyNYYqj0nVSYuubLbaSuAQDEEAAx DCCtW7eW0aNHyzfffCNZWVly6tQpIzR///vf5eyzz7ZlacaMGX4Tw4qyZcsWiYqKMm2o2E2bNk2O Hz9uil62ZE/raN1AtRFsMUxYV5i65i/vkroGABBDAMQwREycONGWuTZt2oRcDGNiYuw2EhISSgvU z9dZx2NjYwPWRrDF8EReUeqanYdIXQMAiCEAYhgC0tPTbUnSCFooxXDjxo327du2beuxnh6z6m3e vNnvbYRCDJVJi3OMGI5PzOGNCQCIIQBiGHx0aNkSpEaNGoVUDIcNG2bfXhfLeEKPWfWGDx/u9zZC JYb7jxUYMdTUNVm5pK4BAMQQADEMMjqv0BKkvn37hlQMddW0dfvly5d7rLds2TK7XteuXf3ehid0 jqL1palF5ydqcb2usuWvM44YOZy2+LBf26VQKBRfiv7Y3bt3LydHQAydRH5+viQnJ8urr74q55xz jpGja6+9Vo4ePeo3Mbz11lulbt26JjXORRddJPfee6/Mnj1bCgo852PR9DnW7b19Me3Zs8eu17Jl S7+3EUoxXLTmUGHqmnFHJXUfJykKhYIYAiCGgXribtK2/PrXvzaCmJubG5D2S5aOHTtKWlqa29ur SFr1cnI8z7PLzs4ulnbG3234ir+Hki16v5lh5HD1j6f4tAJAUGEoGRBDh4uhRgzvuece+fzzzyvd /o033ijjx4+XTZs2GSnLy8uT7du3y5gxY6RBgwbFookatSxJ9erV7TreIot6zKpXo0YNv7cRajGc u6Ywdc0LH2TxaQUAxBAAMQwsKmw6lDxlyhS5/PLLbUF66aWXAnafKlCNGze272v69OmIoQd04cm9 YwpT1yT/ROoaAEAMARDDIJGZmWkSYFuSNGvWrIDd15tvvmnfT6dOnUodZyi5iIlJhalr9C8AAGII gBgGjSVLlviU+6+y6P7E1v2cf/75pY6H++KTYIphypF8I4YaOSR1DQAghgCIYdDQyJolSXXq1AnY /ehWfNb91KxZs9TxcE9XE0wxVHSOocqhzjkEAEAMARDDoKBpWFwXowSKlJQU+34aNmxY6rjTE1yX RFclqxjqKmUAAMQQADEMComJiX7bL9kbEyZMsO/nzjvvLHXc6VvilSS/QOQPEwpT16zZQeoaAEAM ARDDAKOLTzS5tSVJmtMwEPzwww9myz3rfuLj493Wi4mJseskJCSUOq7XWcdjY2MD1kY4iKEy5+tc I4ZDZpK6BgAQQwDEsJJcf/31Zth01apVcujQIZOqRsvu3btLpavR1cmeEl2Xtd3dddddZ4ZkV65c KQcPHjT3cfLkSSOEI0eONCt/rdt37txZzpxxv6BCdxKJiooy9erVq2fS2uhQtxa9rNfpMa2jdQPV RriIoS480b2TVQ51QQoAAGIIgBhW/Mn6sBuJlu7du3vckcQXMfT1fnr37u01jYyycOFCW97cFT2m w9+BbiMcxFAZn1iYumbSYlLXAABiCIAYVoJt27aZnUdU/DQ6qFEyXRGsO5FohLB///7yxRdfeG1j 3759Zc7b83Q/ushEd0QZMGCArF+/3ufHrQtV9DatWrUy+y1riY6Olri4OJP2JlhthIMYapJrFcMH xqbLiTxS1wAAYgiAGIYQnQ9oiWFSUhIdEmQxVP7y7nEjhwnrSF0DAIghAGIYQvr06WOksH379nRG iMTwy215Rgz7Tsqk4wEAMQRADENH8+bNy0wYjRgGFk1d8/s3ClPXrNtF6hoAQAwBEENwrBgqH60u TF3z949IXQMAiCEAYgiOFsOMnKLUNYcyCngBAAAxBEAMwaliqPx7QWHqmreXnuAFAADEEAAxBCeL 4Y8HilLX5J0mdQ0AIIYAiCE4VgyVAdMLU9cs+JbUNQCAGAIghuBoMVz5fWHqmiffInUNACCGAIgh OFoMNXXN78YVpq5Zn3yaFwIAEEMAxBCcKobKh6sKU9cM/ZjUNQCAGAIghuBoMTyWVWBS13QZeUzS MkldAwCIIQBiCI4VQ2X0vGwTNXxnOalrAAAxBEAMwdFiuHXfaSOGPV8ndQ0AIIYAiCE4WgyVZ97J NHK4aAOpawAAMQRADMHRYrhsS2HqmqemkLoGABBDAMQQHC2GOoRspa5Z/eMpXhQAQAwBEENwqhgq c9ecJGoIAIghAGIIiGFh1PD3bxA1BADEEAAxBMeLobJ4U+Fcw95vZpidUQAAEEMAxBAcKoYqgyqF KocqiQAAiCEAYggOFUOFqCEAIIYAiCEghgaihgCAGAIghoAY2hA1BADEEAAxBMTQoDLYd1ImUUMA QAwBEENwuhgqmrJGxVATX7OHMgAghgCIIThYDBVNdq1yqMmvAQAQQwDEEBwshkQNAQAxBEAMATG0 IWoIAIghAGIIiKGBqCEAIIYAiCEghjYDph83cjjn61xeMABADAEQQ3CyGG7ac9qI4QNj0yUrl6gh ACCGAIghOFYMlUHxhVHD+C+IGgIAYgiAGIKjxZCoIQAghgCIISCGNkQNAQAxBEAMATE0EDUEAMQQ ADEExNBmyMwsI4czVp7gxQMAxBAAMQQni+HOQ/lGDLuNSpdjWQW8gACAGAIghuBUMVSGflwYNZy0 OIcXEAAQQwDEEJwshkQNAQAxBEAMATG0IWoIAIghgIPFcOvWrTJq1Cjp0qWLNGvWTGrVqiV16tSR Fi1ayGOPPSZfffWVX+8vJSVF4uLiJDo6WmrXrm2KXh44cKCkpqZGVBtVUQyJGgIAYgjgYDGsVq2a 13LWWWfJ3/72N7/cV2JiotSrV8/jfdWvX18WLVoUEW1UVTFURs/LNnI4MYmoIQAghoAYOorWrVvL 6NGj5ZtvvpGsrCw5deqUEZq///3vcvbZZ9uyNGPGjErdz5YtWyQqKsq0pVI2bdo0OX78uCl62RI1 raN1w7mNqi6G+48VSJeRx0zRywAAiCEghiATJ060xbBNmzaVaismJsZuKyEhodRxvc46HhsbG9Zt VHUxVMbOL4wa6l8AAMQQEEOQ9PR0W5I0glZRNm7caLfTtm1bj/X0mFVv8+bNYdmGU8SQqCEAIIYA iGExdGjZEqRGjRpVuJ1hw4bZ7ehCF0/oMave8OHDw7INp4ihQtQQABBDQAzBRucVWoLUt2/fCrej K56tdpYvX+6x3rJly+x6Xbt2Dcs2PKFzFK0vTS06P1GL63WRVjb+eMiOGurlSH4uFAql8kV/7O7d u5eTIyCGTiI/P1+Sk5Pl1VdflXPOOcfI0bXXXitHjx6tcJua+sYSLW9fKnv27LHrtWzZMizbcJIY ahn9yU8majh0ZhonRgoFMUQMATF0zBN3k7bl17/+tRHE3NzcSrVdt25du82cHM8pULKzs4uljAnH NnylKgwlK5rLUHMaqhxqjkMAcC4MJQNi6HAx1IjhPffcI59//nml2q5evbrdZkGB54UMesyqV6NG jbBsw2liqOguKCZq+HEW3xAAiCEdAYihk8jLyzNDyVOmTJHLL7/cFqSXXnoJMXSoGBI1BADEEBBD kMzMTJMA25KkWbNmVagdhpIjH6KGAIAYAmIIsmTJEp9y/3nDCYtPqroYEjUEAMQQEEMwkTVLkurU qVOhNpyQrqaqi6ES/0WuEcMhM4kaAiCGAIihI9E0LK6LUSoCCa6rBlm5Z+SBsYVRw017TvPhAEAM ARBDp5GYmFjp/ZLZEq/qYEUNB8Uf58MBgBgCIIZOQhefaHJrS5I0p2FFiYmJsdtJSEgodVyvs47H xsaGdRtOFkOihgCIIQBiWEW5/vrrzbDpqlWr5NChQyZVjZbdu3eXSlejq5M9Jbp2zX3oCd0FJCoq ytSpV6+eTJ8+3QxTa9HLep0e0zpaN5zbcLIYKkQNARBDAMSwKj5ZN0mt3ZXu3btLWlqaT+14Y+HC hbZ4uSt6TIeuI6ENJ4shUUMAxBAAMayCbNu2TcaMGWPET6ODGiWrWbOmNGjQwEQI+/fvL1988YXX Nvbt21eudDYpKSkyYMAAadWqldSqVcuU6OhoiYuLk9TUVJ8ed7i04VQxVOauOWnEcMB0ooYAiCEA Ygj/n/j4eFsMk5KS6BCHiGHe6TPyu3EZRg5X/3iKFxwAMQRADEGkT58+Rgrbt29PZzhIDBUratj7 zQyTABsAEEMAxNDhNG/evMyE0Yhh1USjhn0nZRo51OjhjwfYEQUAMQRADAEcKYZKRs4ZszpZ5fDe Memy8vs8XnwAxBAAMQRwohgq+QUi/16QY+RQi6azAQDEEAAxBHCgGFronMMuIwvlcOTcbDmRd4Y3 AgBiCIAYAjhRDJV1u06ZIWWVw2feyWRRCgBiCIAYAjhVDJWUI/lmpTKLUgAQQwDEEMDhYqiwKAUA MQRADAEQQxsWpQAghgCIIQBiWAwWpQAghgCIISCGiKENi1IAEEMAxBAQQ7BhUQoAYgiAGAJiCDYs SgFADAEQQ0AMwYZFKQCIIQBiCIghFINFKQCIIQBiCIgh2LAoBQAxBEAMATEEGxalACCGAIghIIZg w6IUAMQQADEExBBsWJQCgBgCIIaAGEIxWJQCgBgCIIaAGIKN66KUB8amy1NTMmXox1kyaXGOEcfV P56SnYfyJSsXaQRADAEQQ0AMqzyui1K8FcQRADEEQAwBMXQIujBFVyp/uS1P5nydKxOTcuTvH2XJ k29l2lFFxBEAMQRADAExhEqLo+ZPBADEEAAxBMTQ4eLYbVShOK7ZcYqOAkAMARBDCL0Ynsk/LacP 7KXTQoAOK6sYag5FAEAMARBDCKkY5u3aKnvuvVpSH+tIp4WAvNNnzBxElcNNe07TIQCIIQBiCKET wzN5JyW525Wy85aGcmLd53RcCNBE2iqGL3yQRWcAIIYAiCGETgyVY9NfM2J4YNDDdFwI0JXJVtRQ VyoDAGIIgBhCyMSwICtDdnVsauRQh5Yh+Lyz/IQRQ01pAwCIIQBiCCETQyXtteeNGP70rwF0Xgg4 llVgr1AmagiAGAIghhBSMTyVult2dbjARA7zjxymA0OAJr9WMRw7P5vOAEAMARBDCJ0YKgdfeNRE DY++9U86MARo1LDLyGOm7D9WQIcAIIYAiCGETgxzN35lxDC5S0uzWhmCj0YLiRoCIIYAiCGEXAyV ff06GTnMmDOVTgwBGinUiKHON9QIIgAghoAYAoRMDLO/SDRiuLdnG7MjCgSf0fMKo4Y65xAAEENA DAFCJoYqgyqFKocqiRB8dFWyiiFRQwDEEAAxhJCKoZLx0WQjhvv6d6UjQ4TmM1Q5nLHyBJ0BgBgC YggQOjHUhSe777rMyGHud+vozBBgRQ11RxTdGQUAEENADAFCIobKkf8MM2J4aEhvOjNEDIo/buRQ 91IGAMQQEMMqz44dO2TixIny8MMPy1VXXSX16tWTmjVrSqNGjeS2226TsWPHSmZmpn86tlo1n0tZ pKSkSFxcnERHR0vt2rVN0csDBw6U1NRUnx6PP9oIpBhqkmtNdq1JrzX5NQSfTXtOGzHs+Xq65J0m agiAGAJiWNWfrA+SdvHFF8vatWvDRgwTExONwHq6bf369WXRokUBbyPQYqgcHvG0iRqmjRvCJzNE WFHDuWvIKwmAGAJi6AAxrFWrlvTu3VsWL14s6enpkpeXJxs3bpSePXvaotSwYUPZv3+/38SwomzZ skWioqJMGyp206ZNk+PHj5uily3Z0zpaN1BtBEsM83ZtNWKokcOCrAw+nSFg9Y+njBj+blwGUUNA DBFDQAyrNvfff78kJyd7PP7QQw/ZMvf000+HXAxjYmLsNhISEkod1+us47GxsQFrI1hiaL6IB/Y0 cpgeP45PZ4h4akqmkcMF3xI1BMQQMQTE0MFoxMySpMsuuyykYqhRTOv2bdu29VhPj1n1Nm/e7Pc2 gi2GJ9Z9XrhNXrcr2SYvRFhRw95vZkg+aQ0BMaQjADF0KjqsbAnS2WefHVIxHDZsmH37UaNGeayn x6x6w4cP93sbwRZDJfWxjkYOjy+cyZsyRKgUqhwu3pRHZwBiCIAYOhNduesqdCdPVjxiVVkx7NKl i3375cuXe6y3bNkyu17Xrl393oYndI6i9aWpRaOtWlyvq2hJ+WCSEcPdD9/ql/Yo5S+zPz9sxPD/ JhylPyiOLfpjd+/evZwcATF0KprKxlXoKpPGxbWdW2+9VerWrWsWvlx00UVy7733yuzZs6WgwPM4 XYsWLezbe/ti2rNnj12vZcuWfm8jFGK4PzVFdnVtZeQwNfFjTlAhKKn7Dsij448YOVz49WH6hIIY AiCG/iE7O1vmzJkjTz31lNx8881y/vnnm2FaLRdccIG0a9dO/vSnP8knn3wiOTk5IeuIrKwsadas WTGh27p1q1/E0FPp2LGjpKWlub29iqRVz1u/aP+6pp3xdxu+4s+hZCX9w4lGDPf/+X4+pSEiYd1J I4a6GAXAiTCUDIihH9HoUd++feXcc8/1OZ+fiozepjJpUyqKprApmc/w9OnTFW7vxhtvlPHjx8um TZuMlOn8xe3bt8uYMWOkQYMGxaKJ+fn5pW5fvXp1u463yKIes+rVqFHD722ESgw1Xc3u25sZOTy5 fTOf1BCg6Wo0bY3K4Zodp+gQQAzDAP08lqcAhFwMd+/ebdK+nHXWWUY0mjRpIo8//rjMmDFD1q9f L0eOHDHCderUKRMt+/bbb2X69OnSp08fufDCC81t9LaaV1DbCgaTJk0qJoV6/3Pnzg3Y/alANW7c 2L4/ff6IYWk00bWKoSa+htCgia715KKJrwEQQ8QQEMNyo1utqVjpPDpNIu1NSNwJymeffSb33HOP aUPbCjR6f7otniVGevm9994L+P2++eab9n126tSp1HGnDyUrpw/sNVvkadEt8yD4aNTwgbHp5gSj W+YBIIaIob95+eWXTUAJ3KOBsldeeSVyxbBz585m+LSyaBvaViDZsGFDsa3i6tSpI/PmzQtKx+vC Fut+dd5lScJ98UkwxFA5NKS3iRoe+c8wvh1CRPwXueYE88IHWXQGIIYRLob79u2THj16mClNGnz5 zW9+I59++mmRFJSY3qXnYdfvdtcgii6mVKHTc6nF7bffXmozBf3/jjvucPt8dBRRz4Gu/axbtGo7 ek7WncgeeeQROXy4KDhw5swZef75581zOO+882Tw4MHmOl+PB0yoSvSdPufvv/++1LHybpmrr5mO MupubREphpGCilLTpk3tzte5kEuXLg3a/etQuusHrCThnq4mWGJ4ctuGwtQ1d10mBSeyOVOFgKzc oqjhzkP5dAgghhEshh06dJAXXnhBDh06ZFKyrVy5stj3vmuKNZ3uNWTIEGnTpk2p4zrCp1vHvvHG G0a+vvnmG3P9119/LTfddFOx+9T/16xZ4/b5vP7669K/f/9i1911112SmJhoFoWqEOoCVRVFi8mT J5uFq3r/WvTylClTfD4eSDG0yMjIMHmBW7du7bWer8f69esnEyZMQAwDxbFjx+RXv/qVLUPnnHOO +XAEE9ecifqLqCROTnBdkv1PdzdymPHRZM5UIeKd5SfMSWbox0QNATGMZDHUjCAnTpzwWUxyc3OL bfjgTlxUWHT6mIVOB9NpWkpSUlKxYyXRqJpGCL2hU6Fcp5bdcsstJqDhGtxo3769z8etc51GFHUd hEY0R44cac7F+v+SJUvsuiqoV111lemDSy+91KtgluwbFW9NU+cPMdT+dDftrMqJ4TvvvCOXX365 iZhdccUVJq1NoNE3uf5iskRIXzR94wYb/SBZj+HOO+8sddypW+K5I/uLRCOGex5oLWfymecWkh9T WQXSbRRRQ0AMI10MNXo2YMAA2bVrV5liohHDF1980W3EsGQ/6VCnhWYW0XRsym233eY104gOI7sO E7tDp3jFxMTY/+tc+MzMojRaGp1TyfP1uD6HZ5991syvnzp1qhkx1D6x/r/mmmvsuvq81E1U8nSk UTOn+CJ1ep8anCkZPa2oGOqQu6b4qzJiqPZdcpGFDtuWHEtXQVy3bl3AHoeGvh988EH7/nTVriaa DjY//PCDNGrUyH4c8fHxbuvpB8GqU3LOhqLXWcdjY2MD1kaoxVDZ27ONkcPsFfM5W4WISYtzzIlm 7HyG9AExjFQx1KFVlRudH6hz7HVhg45guYqJ6xQrHdbdtm2bV3HRTCMlp0TpvEBdVPLoo496fT56 O2+p4XT+4mWXXVbs/KLnbteFrXrZNaNGWcf1ORw9etRcVuEr+b/rc9H8xhrI8WXDi5JOo9PVkpOT /SKGmtauslv1hpUYPvDAA+bJuk5wtea/6aRQDRPrG1X/79WrV8AeR1xcXLEXTfMMVqjTytju7rrr rjNhah2ePnjwoMlhqG82FUINV+uvGev2OrHX06RY/ZUVFRVl6ukHWNPa6I4jWvSytXBG63j6ReaP NsJBDDP/O71wJ5Q+t3O2ChEaNewy8pgp+48V0CGAGEagGLqiEcFBgwaZoVdfpMXTce2jkosoNSKp dT1FJi30dhoNc8eKFSvkkksuKTU/0R8RQ2/PyfX/tWvXSvfu3U0wR0c458+fX2bf6Dl9586dJmrq LvUdEcOf0TH7kkauq43U4HW+n6LJn7WO2nnAnmw5VwN5+oVQlhj62r4m1S5rt5eFCxcWWzldsugx nQMR6DZCLYZn8k5KcpeWRg5zN37FGStEaLSQqCEghlVDDBU9B5U1h7AscdGI2v33318uAbLQOYaa 2q4ks2bNMlFNd6OI/phj6KsY2uegn2VPz6XqM772jTqE1tdATGXFUPuoSs0xtPIEWjt8rF692vyv kTULDSXrdYEMlfpDDHXZeFnz9jTsrjuc6K8M/YWh0TjtA53Yqjui6FwGTfbtKxrm19u0atXKzInU Eh0dbSKgvu7n7I82QimGJmI1dbQRw4MvPMoZK0RopFAjhjrfUCOIAIhhZInhb3/7WzOapfPtrTmE rucyX8VQh2e1b1QKNZrm7pzmixjqquQnn3yy2HWvvfaaiRR62pZWN6VQ+bNWHetl10UhZR0vjxjq KKamnNGRvwULFhSbS+nL89XUQLpKurJiqH2kK8CrjBhaQ6dWLj1rFewTTzxR7FeLNachnNH5gJYY hmLRSrgSDDHUJNe7OjY1cngqdTedHiJGzyuMGuqcQwDEMLLEUOVGcxfqKl89N3fr1s0Me5ZHDK1d snQOneYx9JS72Bcx1JFEHU5WgSsriKPpaxSN3j333HNmeFiLpt8pmcfQ2/HyiOHMmTNNEEWDO7o6 2dt5393z1dXEN9xwQ6XEUPtG+8gaYa0SYqirkvTJPvXUUyZB49VXX23+11Cxhb6x9Dp3OX/CCd26 Tx+na1gagiOGyk9j/mrEUP9CaNBVyXrCIWoIiCH4g6FDh7LziRe0byJ65xN36MrfkuZ/8cUXm1C2 xbhx48z1f/nLX8L6BWrevHmZCaMRw8Bxas92I4YaOcxPP0LHh+qL/OMsI4czVp6gMwAxBKhCBC2P oe4NrMkhdQ6hzrMrOR9Br1Ph+vbbb3lVEEOv6BxDlUOdcwihwYoa6o4oujMKAGIIgBgChEQMT3y7 yohhcrcrzWplCA2D4o8bOdS9lAEQQwDEECAkYqikPtbRyGHm/Hg6P0Rs2nPaiGHP19Ml7zRRQ0AM ARDDcrBjxw55/PHHzXCypkrxliYGEMOyyFoy14jh3l430/kh5C/vFkYN564hcguIIQBi6CM6n9Bb gmXEEDEsL7pnsu6dbLbJ+yKRFyBErP7xlBHD343LIGoIiCEAYugbuteildD6f//7n9n5BBDDypLx 0WQjhvuf7s4LEEKempJp5HDBt3yuATEEQAx9QJNWqxhu3LiRHkcM/UZBVobsvusyI4cnt2/mRQgR VtSw95sZkk9aQ0AMARDDstAM6yqGuu0dIIb+5MiEfxgxPPT3frwIIUSlUOVw8aY8OgMQQwDE0Du6 HYyKoe4zDIihPzl9eL/s6nCBKXoZQoMKoYph30mZdAYghgCIoXd082oVw2HDhtHjiKHfOTy0v4ka po0bwgsRInQI2Yoa6tAyAGIIgBh6RDevfuKJJ8wm1CNHjpSDBw/S84ih39D5hSqGOt9Q5x1CaEhY d9KI4ZNvZbIbCiCGAIihdzZt2iS//OUvSVeDGAYEXZmscpj+4URejBCh6Wp0KNkaUj6WxUoUQAwB EEM3rF27VqKioshjiBgGjJz/fWbEcM+9V5schxAaVAaRQ0AMARBDr9xxxx1G+K6//npZvXo1eQwR w4CQ8kh7I4dZSbN5QcJIDg9lIIeAGAIghi6cc8455DFEDAOO7ptsbZOXf+QwL0oIOZF3xt4uT3dF STmST6cAYgiAGBZiJbgmjyFiGEjO5J00UmjJIelrkEMAxBAgDMWwbdu25DFEDIOCRgqtIeXkblfK qT3beXFCLIeD4ovk8McDyCEghpVBv9vKUwDCUgzffvtt8hgihkGj4ES27OvftVAOu7SU3I1f8QKF UtYLRIZ/km3k8N4x6bIlhZEDQAwRQ3C0GGoew/79+5PHEDEMqhweGtK7ML/h7c0k5+tlvEjIIQBi GGa8/PLL8tBDD/Fm80DPnj3llVdeqXpi6GuaGtLVIIZ+/UGSf1oOj3jafDnqlnnZK+bzQoVYDkfP K5LDNTvYIQUQw2CLoadzrHV9ec/Xrudt1//r1q0rnTt39npeOHLkiJx//vnF+njRokVy++23S506 daRhw4byyCOPyOHDRYsJNdD0/PPPS4MGDeS8886TwYMHm+t8PR4Mz9HnrtlYvv/++0r3qU7Ba9y4 saSnpyOGgBj6C90qz/qSzPhoMi9WiJm0OMfIYZeRx+TLbXl0CCCGYSSGvtT1pX5aWpoMGTJE2rRp 47GN119/3YwmunLXXXdJYmKiZGVlGSH805/+ZETRYvLkydKuXTvZv3+/KXpZt9319XggPcciIyND hg8fLq1bt650nyr9+vWTCRMmVC0xBMQw1KgQWl+UR9/6Jy8YcgiAGAZQDJXc3Fw5++yzPbahUTWN EHojJydHateubf9/yy23yLJlRVOD9HL79u19Pq6PUaVNI4pNmjSRhIQEM8VNo5P6/5IlS+y6KqhX XXWVeQ6XXnqpV8Es+dw1X3OtWrX8IoafffaZdOrUCTEExNDfHF840wwp65dl2mvPs0NKiJmx8oQt hwu+Jek9IIZVSQw1Yvjiiy96jRjqMLLrMLE75s2bJzExMfb/9evXl8zMzKIf/RkZRvJ8Pa6P8dln n5Xs7GyZOnWqSac3YMAA+/9rrrnGrqtDuHPmzDGSt3fvXunbt69P/aH3qYttb7rpJr+IoQ65X3DB BYghIIaBQOcZ6mIU/cLUxSnIYWiZu+akkUMtehkAMQy8GPo6jasiYmgVFS4dFt62bZvHNnRBqrf8 xhs2bJDLLrus2LmlevXqUlBQtJuSXq5Ro4bPx/WxHT161FxW4Sv5vz4mi2bNmpkh3NTU1LJlqkRf Nm3aVJKTk/0ihvn5+V4jr2Evhnfffbds3ry50u1oG9oWIIb+RtPXWHK4/+nuZgUzIIcAThHD8ohe ecWwPGjEUKNh7lixYoVccsklsmbNmmLX+yNi6O0xu/6/du1a6d69uzRq1Eguv/xymT9/fpn9oQtd du7cKR07dpS5c+f6RQwjPmKocwHOOussue+++8zYfnlWA2ndpUuXmttqG67zCgAx9Cd5u7aaBNj6 xbmvXye20AsxizacNEPKKofvLD9BhwBi6AAx1DmGixcvLnX9rFmz5KKLLpJ169aVOuaPOYa+iqGr myxcuNDMQfS1PzTKqPWPHz9eaTHUPoroOYa7du2SBx980IidPslf/vKX8sc//lHi4+PNXsnHjh0z YVENH2v4VkPF7733njzxxBPmjaC30dv26NHDtAWIYaDQXVHYQi980EUolhzq4hQAxLBqi6GuSn7y ySeLXffaa6+ZSOHWrVvd3mbSpElG/qxVx3rZdVFIWcfLI4a9evUyKWfy8vJkwYIFZs5hefpDPUZX SVdWDLWP3njjjcgVQwuVwMcee0yioqJ8TlOjcxIef/xxvwxFA2LoC2yhhxwCIIahEUMNDulwsgqc axvuiqavUTR699xzz5nhYS0vvPBCqTyG3o6XRwxnzpwp0dHRZt6hrk5OSkoqV3/oauIbbrihUn2q faN9pEG1iBdDCw2jalhYjVf3TFbj1k7Wok/25ptvlqeeeko++eQTsyoIEMNgwxZ64cW6XadMAmyV w5Fzs01ibADEsGoydOhQdj7xgvZNldz5BBDDSJBDttALH3TLPEsOdSs95BAQQwDEEBDDoMIWesgh AGIIiCEAYlgMttALo/fVgXz53bgMI4d/efe4nMg7Q6cAYgiAGAJiGFzYQi98SDmCHAJiCIAYAmIY YthCLzzlcFD8cToEEEMAxBAQw+DDFnrhw6GMAlsOV/94ig4BxBAgUsTQ076LgBhGImyhFz5Y2+c9 NSWTzgDEEAAxBMQwNLCFXpi8DqfPEDUExBAAMQTEMPSwhV54QNQQEEMAxNAv7NixQyZOnCgPP/yw 2d6mXr16ZgeWRo0ayW233SZjx46VzEz/nmxSUlIkLi7ObKtTu3ZtU/TywIEDzSbbkdSG08VQYQu9 0EPUEBBDAMTQr4/LW7n44otl7dq1frm/xMREI5+e7qt+/fqyaNGiiGgDMSyCLfRCD1FDQAwBEEO/ PK5atWpJ7969ZfHixZKeni55eXmyceNG6dmzp/24GzZsWGxT74qwZcsWiYqKMu2plE2bNs3sG61F L1uipnW0bji3gRi6l0O20AsdRA0BMQSIQDGsaAkU999/vyQnJ3s8rptVW4/h6aefrtR9xcTE2G0l JCSUOq7XWcdjY2PDug3E0D1soRdaiBoCYgiAGAYUjZhZj+Gyyy6rcDsagbTaadu2rcd6esyqt3nz 5rBsAzEsG7bQCw1EDQExBIgwMYy4E01env3Yzz777Aq3M2zYMLudUaNGeaynx6x6w4cPD8s2EEPf YAu90EDUEBBDAMQwYOjKXdfI5cmTJyvUTpcuXew2li9f7rHesmXL7Hpdu3YNyzY8oXMUrS9NLRpt 1eJ6ndNKygeT7C309gx7Wvanpji6P4JR9qYekJ6vHzNyuPDrw/QJxa9Ff+zu3bsXUwDE0KliqKls XMWwomlcWrRoYbfh7Utlz549dr2WLVuGZRuIYflK6tx3ZVfsxYVy+JdeyGEQyowlPxkx7PefI/QH BTEEQAz9Q1ZWljRr1qyYGG7durVCbdWtW9duIycnx2O97OzsYiljwrENX3H6ULIrbKEXXJhrCIEi LIeS36pWvgKAGFYMTWFTMp/h6dOnK9RW9erV7XYKCgo81tNjVr0aNWqEZRuIYQVlhS30ggpzDQEx RAyhCophqIRy0qRJxaTwrLPOkrlz51a4PcQQFLbQC6KIEzUExDBixfDll1826eLAPZpn+ZVXXols MQy2UFaGzz77zGyLZ923Xn7vvfcq1SZDyWDBFnrBg6ghIIZli+G+ffukR48e0qBBA7M16m9+8xv5 9NNPS52Hteg5pHPnzsW+213PlRdddJERug0bNtjHb7/99lI5c/X/O+64w+3TOXLkiJx//vnF+rms 9HVnzpyR559/3jyH8847TwYPHmyu8/V4oB3G6jt9zt9//32pY+VN36evWePGjc2mHIhhgNE3s+tW cXXq1JF58+ZVul0nLD5BDH2HLfSCA1FDQAzLFsMOHTrICy+8IIcOHTKZN1auXFksG4XrOTgtLU2G DBkibdq0KXVcR5p0h7A33njDyNc333xjrv/666/lpptuKnaf+v+aNWvcPp3XX39d+vfv79EJ3DF5 8mRp166duX8tennKlCk+Hw+kw1hkZGSY9G+tW7f2+Xl5O9avXz+ZMGECYhhIVJSaNm1q3+e5554r S5cu9UvbTkhXUykxzPv5V092qjgJttALDkQNATH0Loaao/fEiRM+i0lubm6xvL7uztEqLPfee6/9 /z333GNG45SkpKRix0qiUbVFixaVS5JuueUWc95yPYe1b9/e5+NWzl6NKDZp0sRENEeOHGm2w9X/ lyxZYtdNTEyUq666yvTBpZde6lUwSz5eFW/dhtcfYqj92alTJ8QwUBw7dkx+9atf2fd3zjnnmF9N /oIE115I3yYy84qfz+A3/mxLp8VJsIVe4CFqCIihdzHU6NmAAQNk165dZYqJRgxffPFFtxHDkv2k Q50WmrqsY8eO5vJtt91m/veEDiMfPny4XJKkU54yM4t+/Gl0TiXP1+Pa7rPPPmumUU2dOtUEhrRP rP+vueYau64+rzlz5hjJ04BS3759fZI6vU89B5eMnlZUDHXI/YILLkAMA4H++tFQunVfavP6i8af sCWetzN3usiHzQu/sFY948iTDVvoBRaihoAYehZDHVpVudH5gTqVShc26OYOJc/D1kjaXXfdJdu2 bfMqLprBQ+ccuvLII4+YRSWPPvqo16ejt/OUAcSTD+jCStcFlXrZdeFkWce13aNHj5rLKnwl/3d9 LprGTiOivuQ1Ljk/UEclk5OT/SKG+fn5ldqRDTH0gL45HnzwQft+9M0ze/bsgNxXTEyMfT8lJ+Iq ep11PDY2Nqzb8KsYKj+tE5lap/BLa+csR55w2EIvcBA1BMTQt1XJGhEcNGiQGXr1RVo8Hdc+0sif KxqR1LqeIpMWejuNhpVHkvwRMfR2P67/r127Vrp37y6NGjWSyy+/XObPn19m3+hCl507d5qoqbsM J0QMw0gM4+Liitn8+PHjK/U4vT1WDZ1HRUWZOvqrbPr06Wa3EC162Vr0onU8hdnDpQ2/i6GydXLh l9a0uiJHt4gTOb5wpr2FXtprz5uhZvAPRA0BMfQtXY1mrChrDmFZ4qIRtfvvv79cAmShcwwXL15c LknyxxxDX8XQQmVv4cKFZg6ir32jUUatr+fbyoqh9lFEzzGs6LLsQItheR+Hp9Cxr49V30Suq55L Fj2mE1sjoQ2/i6GyonfhF9fHV4ucynLkiUfnGVq7pOjiFOTQPxA1BMTQvRj+9re/NXPqdVqVNYfQ daqRr2KoI3DaNyqFGk1bv359hcRQVyU/+eST5ZIkzT2s8metOtbLrotCyjpeHjHs1auXSTmTl5cn CxYsKDaX0pfHq6mBdJV0ZcVQ+0hXgCOGYSiGmk/Il3l7Fjp3Qye1tmrVysxn1BIdHW2il77uxRwu bfhdDFUGVQr1y2v5o449+bCFXmAgagiIYenzqcqN5i7UHIY65NqtWzcz7FkeMbQ2Q9A5dJrHcNOm TeWSHFd0bp8OJ6vAeTtXl4zePffcc2Z4WIum3ymZx9Db8fKI4cyZM825Uucd6upkb2sS3D1fXU18 ww03VEoMtW+0j3ThbMSKYVUmPj7efqP6e9FKJFPhPIa6SlmHk/ULbKtzF2K4bqG3q2NT2fNAa7OV 3oGBPc1K5iP/GSbp8ePM8LOmusn9bp2cPrBXzuSd5M3nqU+JGkJVFMMqyNChQ9n5xAvaN47d+SQS 6NOnj5FC1/kKUMkE17oARcVwSs3ChSkOxXULvfIURNIzRA0BMQQIEzHUfED6K+Dqq682Cxu06GVd vq7HIpXmzZuXmTAaMawAmrpG5VBT2eSlO7ovdShZJU6HmHP+95mRu2PTX5MjE/5hpG//n++X1D63 Gxm0Fq+EU9l912WS+lhHOfjCoyY1j67Azv4iUU5u3ywFWRlB7UuihoAYAoSBGGpWdU2I6Wnunh7z lnkdHCiGmuxak16rHCbeTYdWYZEMtjgSNQTEECDEYvjPf/7TCKBO+tSJm1lZWaboZb1Oj2kdQAyL odvkvdu4UA7Xj6BTI5T89CNyctsGs+I6/cOJJhXPgUEPS8oj7e1FNsEUR6KGgBgChFgMddNolb93 33231LEZM2aYYyVX6QBiaEhNKppvuG8pHYs4lir7+nc1bZQHooaAGAKEUAx1Gx2Vv/T00nPFdLm1 Hqtbty69jxi655uhhXIY30Qk5yCdiziWEkddpJN/5LDPbRI1BMQQIIRiWFY+wmDsiQwRLIY633DB nYVymNCh8H8AlcafZdBauV1eOSRqCIghAGIIkSiGSm6ayPsXF8rhV4PoYPAoh5rmxxeIGgJiCIAY QqSKoXLwy8K5hiqHyfPoZLDRldg611DlUBOD+yqHRA0BMQQIoRiG25Z4EGFiqGwZVyiG0xuIZO6g o6FSckjUEBBDAMQQIlkMlSU9CuVwTmuR/Fw6G4rJoeZpNHLYpaXJ5VgWRA0BMQQIshgCYuhXTmWJ zLyiUA5X9KazoRhn8k/LoSG9C3Mg3t6sTDkkagiIIQBiCJEshsqRDSLT6hbK4Y8z6HColBwSNQTE EAAxhEgWQ3MnMwrFUAVRRRGghBz+9K8BRg516z/Ng+gJooaAGAIghhDpYqh83q9QDnVoWYeYAUqg 2+j5IodEDQExBEAMIdLFUBef6CIUlcPP7qPjoUw5zEqa7bYOUUNADAEQQ4h0MVQ0bY2mr1E51HQ2 AG5Ijx9n76+c8dFkt3WIGgJiCIAYQqSLoaIJr1UMNQG2JsIGcIMKoTc5JGoIkSaG1YZWK1cBQAzB GWKorBlcKIe6dV7OQV4EKFMOj00dXeo4UUNADAEQQ6gKYlhwWiShQ6EcLriz8H8AN+giFJ1vqHKo 8w9dIWoIiGHoePnll+Whhx7izeaBnj17yiuvvIIYAmLoMxopjG9SKIffDOWFgArJoRU17Pl6uoyd ny2LN+XJoYwCOg0xrHJi6Gl3Mev6yuxY5vp/3bp1pXPnzl7PC0eOHJHzzz+/WB+XtQvamTNn5Pnn n5cGDRrIeeedJ4MHDzbX+Xo8YK9Lied+xx13yPfff1/pPt23b580btxY0tPTEUNADH1m39LCuYYq h6lJvBjgVQ41AbbK4eERT5vch4pGDXu/WRg1dC1/mJCBKCKGjhJDX+r6Uj8tLU2GDBkibdq08djG 66+/Lv379/e5fWXy5MnSrl072b9/vyl6ecqUKT4fD6QYWmRkZMjw4cOldevWle5TpV+/fjJhwgTE EBDDcrFhVKEYvttY5HgyLwh4RHdFseRQd0ux5FBJOZIvC749KSPnZtvDy4giYogYVqx+bm6unH32 2R7b0KjaokWLyiVJt9xyiyxbtsz+Xy+3b9/e5+ParkqbRhSbNGkiCQkJMnLkSGnYsKH5f8mSJXbd xMREueqqq8xzuPTSS70KZsnHe/LkSalVq5ZfxPCzzz6TTp06IYaAGJabxLuLkl/vX8GLAhWSQ1cQ RcQQMayYGGrE8MUXX/QaMdRh5MOHD5dLkurXry+ZmUULxTQ6p5Ln63Ft99lnn5Xs7GyZOnWqnHvu uTJgwAD7/2uuucauq0O4c+bMMZK3d+9e6du3r0/9ofc5bNgwuemmm/wihjrkfsEFFyCGgBiWm7x0 kY+uLJRDLUt7ET0Ez3L43TpJ7nalkcP9T3eXghPZZd4GUUQMq4IYepvTVlkxtIoK11133SXbtm3z 2EbNmjXl9OnT5ZKk6tWrS0FB0WdLL9eoUcPn49ru0aNHzWUVvpL/62OyaNasmRnCTU1NLft1KdGX TZs2leTkZL+IYX5+vtfIK2IIiKE3dGeU9SNEptYplEP9q4tS9HqAEpzas92Ww339u/okh4giYhjp Ylge0SuvGJYHjRhqNKw8kuSPiKG3+3H9f+3atdK9e3dp1KiRXH755TJ//vwy+0MXuuzcuVM6duwo c+fO9YsYEjEExNAfZKcWRgyt6OGHzUV2zuKFAq9yqGX3XZfJngdam5L6WEcTTdRy8IVHzYIVLbqq WXMiatE8iccXzjRlz8IFsnzWCpkybqnEDV0tDw/ZbMp9Q/cYURwUf1xO5J2h0xFDxFAK5xguXry4 XJLkjzmGvoqhhcrewoULzRxEX/tDo4xa//jx45UWQ+0j5hgCYugvdFcUa29lLZ/GiBzdwgsGxTh9 YK/s7XWzLYeBKkm/7SR/m7IPOUQMEUMpXJX85JNPlkuSJk2aZOTPWnWsl10XhZR1vDxi2KtXL5Ny Ji8vTxYsWGDmHJanP3r06GFWSVdWDLWP3njjDcQQEEO/oYmvt04uXLFsbaP3Zf/COYkAJchPP2JE UcvJbRvkxLerTNFUN1ZkMP3DiXbEMO215+1I4oFBD9sRxpRH2tuRR2uhi5ZVd90oL03ahRwiho4X Q53bp8PJKnCubXib+6jRu+eee84MD2t54YUXSuUx9Ha8PGI4c+ZMiY6ONvMOdXVyUlJSufpDVxPf cMMNlepT7Rvto2PHjiGGgBj6HRXBVc8U5Tyc3qBQGNkxBYIhnEcOy+6HbkYOEUNwYejQoex84gXt G3Y+AcQw0OhQsm6hZw0vf3w16W0gJHI4dOJW5BAxBAgrEENwnhha7J5TuCiF9DYQRHTl854nuho5 XB/TSoaP34AcIoYAiCEghmEB6W0AOQTEEAAxBMSwGKS3gRDI4d7+3Ww5HDX2f8ghYgiAGAJiGFaQ 3gaCiG7Fl/L8/xk5/L7DxfLqqGXIIWIIgBgCYhhWkN4GkENADAExBEAMi0F6GwiiHKa+9EdbDscP n4ccIoYAiCEghmFJyfQ2OtR8+CtedPA7+179m5HD7bdeIG8O/Qg5RAwBEENADMMW1/Q2GkXUaCLD y4AcIoYAiCGAA8VQ0TQ2awYXDS+/f3GhMAL4kf0TRthy+M4Lk5BDxBAAMQzkB103wx42bJjcd999 cskll3jck7FSHetmv0dPpSxSUlIkLi7O7NlYu3ZtU/TywIEDJTU11afH4482EEMXdHj5v+2KhpcX dSM5Nvj3u+q9Sfb+yjMGjUcOEUMAxDAgT7iSkhZsMUxMTJR69ep5vG39+vVl0aJFAW8DMfSALkbR RSkqh9Pqimway+IUQA4RQwDEMFJo2rSpdOvWTV5++WWZP3++7N+/P+BiWFG2bNkiUVFRpg0Vu2nT psnx48dN0cuW7GkdrRuoNhDDMsg5WDw5NotTwI8c/Pg92XHrBUYOZ//pJeQQMQRADAPeCWEqhjEx MXYbCQkJpY7rddbx2NjYgLWBGPpIahKLUyAgHF6UYMvhJ38chBwihgCIodPEcOPGjfbt27Zt67Ge HrPqbd682e9tIIblhMUpgBwihgCIIWLo7zZ1cYx1+1GjRnmsp8esesOHD/d7G4hhBWFxCgRCDlcs lW2/udjI4aI/9JacE6foFMQQADF0ghh26dLFvv3y5cs91lu2bJldr2vXrn5vwxM6R9H60tSi8xO1 uF5HOSAZX42WgnfqGzk88865kvnlP+TAvhT6hlLh8sPCBbL1/8th0sO/l927eT8FquiP3b1793KS BMQQMfRvm7feeqvUrVtXatWqJRdddJHce++9Mnv2bCkoKPB4+xYtWti39/bFtGfPHrtey5Yt/d4G Ylj5cmj3Rjnx6b129PDUzKsk7ftP6RsKcogYAiCGThRDT6Vjx46Slpbm9vYqkla9nJwcj/eTnZ1d LO2Mv9vwFYaSfYDFKeBHfvr2W9l4e7SRwy8f6CzZGVl0ip9hKBkQQ8TQb23eeOONMn78eNm0aZOR sry8PNm+fbuMGTNGGjRoUCyamJ+fX+r21atXt+t4iyzqMatejRo1/N5GIMTwYNZBUxwJi1PAjxzZ +gNyiBgCIIaRIIZlSVTjxo3t+5w+fbpjxHBb2ja5cuKV0mFaB8nKc/BJjMUpEAA51LL5N81lzR3X mrKyc4ef31pdTPnkvt9J/ENPmPL27/8q4x8basqofq/LP/pPNWXQs7Pl6YGLTHn8+VXy8JDNptw3 dI90GnEsKOWBf+y07/eJ5z63H88Lz8y0H+fox1+1H/87Dw+wn9d/7+1hP98vOrWz++H7DoXD7t/c eS1iCIAYhp8YKm+++aZ9n506dSp1vKoOJWukUMWw2tBqEjMjRk47fZcQdk4Bf8jhzmRZc3dbWw4p ngtiCIAYhqUY6v7E1n2ef/75pY6H++KTioqholHDJmObGDnsMbsHcuhu55T0bXwwoULkpx+R0wf2 mnJy2wY58e0qU7JXzJfjC2eakv7hRDk2dbQpaa89L4dHPG3KgUEPy/6nu5uS8kh72fNAa1N2394s aOK2+67L7PtNfayj/XgOvvCo/TjTxg2xH3/GR5Pt55X9RaL9fE9u32z3Q0FWRoX6EjEExBAxDNp9 njp1yr7PmjVrljoe7ulqKiOGypbDW6TuyLpGDp9JfIY3ofm14LI4RaOH302kTwBCCGIIiCFiGLT7 TElJse+zYcPSwxtOSHD95d4vbTkcvHQwb0TziyFLZEXv4nMPc9PoFwDEEAAxrMpiOGHCBPs+77zz zlLHnbIl3rwf5knNYTWNHI77ehxvRgtdqWzNPYxvIrJ3AX0CgBgCIIZVUQx/+OEHadSokX2f8fHx buvFxMTYdRISEkod1+us47GxsQFrI5BiqLy/+X0jhlpmfTeLN6RFdqrIpzFF0UPNe6jpbgAAMQRA DMNHDMuqf91115kh2ZUrV8rBgwdNDsOTJ08aIRw5cqRZ+WvdvnPnznLmzBm37ehOIlFRUaZevXr1 TFob3XFEi17W6/SY1tG6gWoj0GKoaLRQxVCjhxpFBBd0pbKV9/Djq0WObKBPABBDAMQwECJYVqmI GPradu/evb2mkVEWLlxoy5u7oscSExMD3kagxVDReYYqhzrvUOcfggsqgx9dWbRrisoiACCGAIhh aMVw3759Zc7b27Ztm9nhpHv37nL55ZebaJyuPNZFJrojyoABA2T9+vU+P15dqKK3adWqldlvWUt0 dLTExcWZtDfBaiPQYqj0X9DflkNNawMu6DCyDidbQ8sL7iwcbgYAxBAAMQwNOh/QEsOkpCQ6xM9i qDkNNbehyqHmOkQO3aALUd5tXCiHukCFLfUAEEMAxDA09OnTx0hh+/bt6YwAiKElh7orisqh7pLi 2H2VvaEpbDSVjRU9/LxfYaobAEAMARDD4NG8efMyE0YjhpVH91FuN7WdkcOr/3O1s/dV9oYmwZ5a p1AONTn24a/oEwDEEAAxhKolhorrvsodpnVADj2h2+fpNnrWwpT1I9hvGQAxBEAMoWqJoSWH1r7K 9826j32VPaH98tWgoqHl/7YTOZ5MvwAghgCIIVQdMVR0AYolh4/OfZTO9sb+FSLvX1y03/KO9+kT AMQQADGEqiOGiuu+ynFJcXS4N/LSRZb0KIoe6mW9DgAQQwDEEKqCGCorklfY+yqPXU2C57JflBmF UUOVQ40iajQRABBDAMQQqoIYKnO2zrHlcPI3k+n4stB5hjrf0FqYovMQmacJgBgCIIZQFcRQmbh2 or2vsooilIGK4DdDi++3TPQQADEEQAyhKoihMmrVKFsO2VfZRzTHoeY6tOYeLu3FymUAxBAAMYTI F0NFF6FY+yp/lUpiZ5/Q/ZY1z6GVFFv/ajRRrwcAxBAQQ7oAIlUMlV5zerGvckXITi2MGFrRQ40k 7pxFvwAghoAYAkSuGGrCa018rXJ48esXs69yeTn4ZdGuKVo+jRE5uoV+AUAMATEEiDwxVHSrPN0y T+VQt9BDDsuJLk7ZOlnk3cZFq5e/7E/uQ0AMEUNADAEiTwwtObT2Vb7ijStkxsYZknuaeXPlQkVw 1TNFq5enNygURtLbAGIIgBgCRJIYKhopvPo/Vxs5tOYd6url9FwiX+VCh5IX3Fk0vEx6G0AMARBD gEgTQ0XnHL6/+X1pPbm1LYgNRjUwK5hTM1N5ocrD7jmktwHEEDEExBAgcsXQlaSdSXLne3fagqg5 D3vP6y0bDm7gBfMV0tsAYkhHAGIIUBXE0EJFUNPaWFvpabn7/bvN3svgI6S3AcQQADEEqApiaJGc nmyGlOuMqGMLog45z/pulhmCBh8gvQ0ghgCIIUBVEEMLXYwy4osRZnGKJYi6knnc1+NYyewLpLcB xBAAMQSoKmJooRI4+ZvJRgpdF6oMXTmUXIi+QHobQAwBEEOAqiKGrsz7YZ60m9rOFkQdbu6/oL/s OLqDF7cs3KW3SZ5HvwBiCIAYAmIY2Xy590t7iz1rJbP+/1XqV7zIZaHpbWZeUSSIOhcRQQTEEAAx BMQw0tmWtk36ze9XbKFKzIwYE1kEL+gw8o8zEERADAEQQ0AMf6xyz0vnGg5eOtjMPbQEsfGYxiaK qAtYFmxfwM4qCCIghgCIIYATxNBC92LWVcsXv36xLYiuRRew9Jjdw9TR4WitDwgiIIYAiCEghlUc XZCiuQ81J2KHaR2k7si6bmVRcyTqcPTEtRNNkm1H50pEEAExBEAMATF0Aip8Kn5T1081K5lVCF13 WXFd6Xzj2zcaodT9nLccdmBiaAQREEMAxBAQQ6ehORJ1JbMOLT8691G5cuKVbqOKOndR93MetHiQ WdiSmpmKIAIghgCIISCGVR1dpLJ091IZtWqUWbziab6iRhURRAQREEMAxBAQQ4ehq541UvjS8pfk 7vfvtlc/68pnlUjHgCACYgiAGAJiCMXRqKIKopVce+zqsc7qAAQREEMAxBAQQyhCF7Pofs3W0HKv Ob2cl/4GQQTEEAAxBMQQitDk2VYqnKv/c7Uz9212J4ifxoicIk8kIIYAiCEghg5Dt+ZTKbRWMCft THJmR1iC+GHzIjl0cl5IQAwBEENADJ2JDiPrrirW0LIOMzuW9G0i8U0K5XBJD+QQEEMAxBAQQ2ei ezNbibO7fdjNudvuHd0iMq1uoRyueoY3BiCGAIghIIbORFPYaCoba39mR+6eohz8skgO1wzmjQGI IQBiCIihM0lOTzbb7qkc6uKUOVvnOLQj5olMqVkoh1vG8cYAxBAAMazYB33BggUybNgwue++++SS Sy6RatWq2cXfpKSkSFxcnERHR0vt2rVN0csDBw6U1NTUiGoDMQwfdBhZt9qz5h0OXjrYpLlxHDve L1qtvHMWbwxADAEQw3I+YRcJdFf8SWJiotSrV8/jfdWvX18WLVoUEW0ghuHJxLUT7XmHuudyWk6a 8zpBo4Uqhho9JM8hIIYAiGF5aNq0qXTr1k1efvllmT9/vuzfvz8gYrhlyxaJiooybaqUTZs2TY4f P26KXrZETeto3XBuAzEMb1Ykr5AmY5sYOWw+rrlsOLjBeZ2g8wxVDnXeoc4/BEAMARDDCndCAMQw JibGbjMhIaHUcb3OOh4bGxvWbSCG4U9qZqq0m9rOyGGdEXVkxsYZzuuEL/sXyaGmtQFADAEQw3AQ w40bN9rttW3b1mM9PWbV27x5c1i2gRhGDjrHsN/8fva8w2cSn3HWvEN9rprbUOVQcx0ih4AYAiCG 4SCGurDFam/UqFEe6+kxq97w4cPDsg3EMPKYun6qiRqqHHaY1kEOZh10lhzqrigqhx9dKZJzkDcE IIYAiGFoxbBLly52e8uXL/dYb9myZXa9rl27hmUbntA5itaXphadn6jF9TpK6MqiTYuk6atNjRxe MOYC+XTDp4557gdTdsip2W2MHJ6eeaX5n/cEpSJFf+zu3buXkyQghohh5WjRooXdnrcvlT179tj1 WrZsGZZtIIaRWzbu3Ci3vn2rkUNduTx62WjHPPdDuzfK6Q+uMHKY9/FNyCEFMQRADEMnhnXr1rXb y8nJ8VgvOzu7WMqYcGzDVxhKDk90juGgxYPseYe95/WW3NO5znjyOoxs7av82X3sqwzlhqFkQAwR Q7+0V716dbu9goICj/X0mFWvRo0aYdkGYlg1eH/z+2aXFEsQI7nori+6NaBP6AIUSw6XP8obARBD AMQQMUQMQdH8hrq/clWQQy3dPuwmO47uKPuJu+6rvDqONwIghgCIYXDFkKFkgMCgw+CjVo2SBqMa 2HMnNS1Pem669xvuX1G0r/KmsXQkIIYAiGHwxNAJi08QQwglmoKn/4L+9naAKorjvh7nPW/j7jlF crh1Mp0IiCEAYhgcMXRCuhrEEMKBLYe3mD2ireFlHSpfsH2B5xt8N7FoX2UVRQDEEAAxDLQYkuAa ILgk7UySKydeaQtizIwYz3tGbxhVJIfsqwyIIQBiGGgxZEs8gOCjw8gT106UxmMa2/MPdYtAtzu/ 6CIUa1/lw1/ReYAYAiCGgRNDJSYmxm4zISGh1HG9zjoeGxsb1m0ghhBJ6EIUzd1ozT/UND0jvhhR On/j0l7sqwyIIQBiWHkx9KW+7gISFRVl6tSrV0+mT59udgvRopf1Oj2mdbRuOLeBGEIkoqlseszu YQ8vNx/X3ORztNGFKpr4WuXw/YvZVxkQQwCniqGr2JVVKiOSCxcutMXLXdFjiYmJEdEGYgiRyork FSYptiWI7aa2k69S///w8akskYQOhXL40ZXIISCGgBgihuUTw3379vk0b88iJSVFBgwYIK1atZJa tWqZEh0dLXFxcZKamurT4w2XNhBDiGRmbJwhTcY2sQWx15xekpyeXCiHKoUqh+82Fvk0RmTVM4Ur mDX/YW4anYcYAiCG4J74+HhbDJOSkugQxBAiiKy8LBm6cqjUGVHHyKH+fWn5S5J+7MciOXRXEEbE EAAxBHf06dPHSGH79u3pDMQQIpTUzFR5dO6jdvRQI4lT10+V01mpPx/8+QfflnEiX/YX+W87kekN EEbEEAAxBPc0b968zITRiCFAZLBu/zrpMK1D0PZ31lyLOqRdaoU0IIYAiCEghgDhwazvZpldU4Il iE3GXmj2fC5zj2dADAEQQ0AMASIcXd1cYkj69PQG8v64atL6n0WC2GDULyQuKc4MbQNiCIAYAmII 4BQ0b+KO90XmtJakN6rJnf8qEkRNxt17Xm/P2/gBYgiAGAJiCFBF0Wjigjtlw8Rq0mv0z2LoMsx8 9/t3m9yLgBgCIIaAGAI4iSMbzNZ8yZNrSNyr1aTOK0WCqEm5de6j7gENiCEAYgiIIYBTOJ4ssjpO 0t+uLSNeqyZNhhUJ4hVvtJBxX49jJTNiCIAYAmII4Cjy0kXWj5Dc9y6Uyf/+WQpHFF+oosm5D2ax bR9iCIAYAmII4Bzyc0W2ThaZeYXMe6OatBtZJIh1RtSW/gv6y46jO+gnxBAAMQTEEMBRJM8z6W6+ nFBN7hvlupK5htw36z75KvUr+ggxBEAMATEEcBQHvxT57D7Z9mY16Tem+EKVmBkxMu+HefQRYgiA GAJiCOAo0reJfN5PDr5VWwaPrSYNhlUL2o4tkV6aj2uOGAIghoAYAlRBdHeVNYMla9ovZNzr1eTi 4YhfmWL4z5qIIQBiCIghQBXmVFbh1nvvXyzyVjWKt/IhEUMAxBAQQwCACoAYAmIIgBgCACCGgBgC IIYAAIghIIYAiCEAAGIIgBgCYggAgBgCIIaAGAIAIIYAiCEghgAAiCEAYgiIIQAAYgiAGAJiCACA GAIghoAYAgAghgCIISCGAACIIQBiCIghAABiCIAYAmIIAIAYAiCGgBgCACCGAIghIIYAAIghAGII iCEAAGIIgBgCYggAgBgCIIaAGAIAIIYAiCEghgAAiCEAYgiIIQAAYgiAGAJiCACAGAIghoAYAgAg hgCIISCGAACIIQBiCIghAABiCIAYAmIIAIAYAiCGkd+x1ar5XMoiJSVF4uLiJDo6WmrXrm2KXh44 cKCkpqb69Hj80QZiCACIIQBi+P/au+8QKc4/juOxxHjqid3oqbGLHY3tYuxigygk/qEGg2AlgmLD hrHEaLBhJ7H+odhCxFM0QU2iMRGxNyyxi2Kv2I0+P77fHzPcebu3e7vPc+fE9wsWd6c8Nz4zu/PZ Z555FtkYDLds2WISExPDrluwYEHzyy+/OC+DYAiAYAgQDGEhGMbq2LFjJiEhQcuQYLds2TLz8OFD fchzL+zJMrKsqzIIhgAIhgDBENkcDFu2bOmXkZKSkm6+TPPmt2rVylkZBEMABEOAYIhsDIaHDx/2 12/YsGHY5WSet9zRo0etl0EwBEAwBAiGyOZgOGnSJH/977//PuxyMs9b7ttvv7VeBsEQAMEQIBgi m4Nhx44d/fV///33sMv99ttv/nKdOnWyXkY40kfR+9CUh7ROHjx4UPspunhI+dKaGeTyXZUt2+2y /CNHjuiD8jl23rVj89ChQ3zhBcEQ9oPhJ598YgoUKGDy5MljSpcubbp06WLWrVtnXr16FXb9SpUq +etfunQp7HIXL170l6tSpYr1MqINhvLhLB+irj6gJXS6PAEcOHDA6cl9//79Tk++sv0ug4nLfSvl uwwPsu0uy3d9bAb52JF6cf2F0fWxeerUKU5oIBjCbjAM92jRooW5detWyPUlSHrLPX78OOzfefTo UZphZ2yX8bZccpFv7RJGXZET5PPnz52VLyd3V2S7Y+0bGo3bt2+bCxcuOCvf9bEj2y7/h6Aem0E+ dqReXLa4Bf3YBAiG75AGDRqYOXPm6DdmCWXyAfzPP/+YadOmmUKFCqVpTfz333/TrZ8zZ05/mYxa FmWet1yuXLmsl5GZE4DLk6OcACIFt7/++ivm8m/cuBFyP9gq3+XJRbZbtt8VOX7v3bvnNDxEc+zE Wv+y7Rl9MYp330ZzbMYbTrL72Im1fqReognlsZb/thybAMEQcbcwFCtWzA9jy5cvD3wwjMamTZtM 165dzdy5c62XLZfDc+TIob/u4sLSpUtNhQoVnLU8/fTTT6ZDhw5m1qxZTsrfvHmzGTNmjLPWJ5f7 1nX9uz52XNeN62OH9xZAMEQWWLBggR/G2rVrl25+0C4lR7J7925TpkwZM2PGDFOnTh0NKja9fv3a VK5cWYfesX0Ck1YPqcsTJ044qZs//vjDJCUl6ReEunXrmu3bt1stXy4VSt9WuUu9XLlyZsKECYHa t67r3+Wx47puXB87vLcAgiGyiPw+sRfGihcvnm7+237zSWZJKFmzZo0+37lzpxk+fLj1v9GjRw/9 ab/GjRvrCUxaCmz0P3rw4IG2mNy5c0e7BvTp00d/NcZm3fTs2VOfS1eD0aNHm61bt1o9OSYnJ+tz aZWRE/y4ceMCs29d17/LY8d13bg+dnhvAQRDZJEXL174YSx37tzp5r/tw9Vkltzhd/78eX1+9epV 06tXL30u/YMyusydGdIqMGTIEHP//n1TrVo1kzdvXmsd69u0aaMn9aZNm5qxY8dq68/s2bOtlC31 UrZsWb1bvWjRon7506dPt1K+9COT8n788Ud9LSfh8uXLa2tWUPaty/p3eey4qJvU/fFcHDuh+vvx 3gIIhnDs8uXLfhgrUqRIyG+6QRrgOjPu3r2rLRA3b940tWvXNhs2bLBS7pUrV/RS6YoVK8yHH35o Pv74Y/Prr79aKfvs2bOmZMmS5osvvtDX69ev1xOaLc+ePdMWE69MKb9JkyYxlbVo0SKzZ8+eNNOk X6vUyeLFi/W1XNqM9bJgqPJt7ttQ5duq/3D9/WwdOxs3btRtDNWf0EbdhOrvZ/PYCdffz1b9yDrS lUGGsHHx3gq1f23WD0AwhDPz5s3zw1jbtm3TzQ/aT+JlhvR3lM7gcnIcP3681bJr1aplSpQoof8P OSHYJOOZyTb369dPL7n/8MMPVst/+vSp9kfzyl+4cGGmy5DLZNJCIifaN8OVbH/NmjX1N7ErVqyo J3mb5dvYt5G2P576j9TfL95j5++//9Ztnz9/vpb/Zn82G8d9uP5+No6dSP394q0fuZTu9ferV69e mr6uNt5bGe1fG/UDEAzhjHwIymUNL4yFO0G3bNnSXyYlJSXdfJnmzZeTvasybJOTm/SrtB0KhZy0 XIbbly9fal8rW5dh33Tu3DkzcuRI8/PPP8e0vlw2vnbtmm5jqHAl279lyxaza9cuJ+XHu2+j2f5Y 6z9Sf794j52JEydq3zvvb8ld4LKtto/7cP394j12IvX3i7d+Zs6c6ff3k0u58uVk8uTJ1t5bkfZv vPUDEAwRM7n7TS7J7tixQ09y8k1cvmFLIJwyZYre+euFsfbt2+sJIxTpn5SQkKDLJSYm6jdtb1wt eS7TZJ4sI8u6KsMFl+Pu4f9ShysXY7GFK9/WvrW9/a77Qkr5EtDkfS7DUUlok1Y2Gc/UZt0Etb+f 3HBXqlQp89lnn2nLo+xX+dyR6TZkRV9XgGCI2Co1il89kYd8cEUaeFcuh3jhLdRD5kkLkOsyEOxw WL16dWv9Lf8L5bvq5yqk1dPrQyd9Ojt37my1ToLcl1a23Rv4X8ivP61du9b6ceNy/wIEQ2TayZMn dWgE+WYsl0vkW7HceSw3mcgvogwePDhN5+tI5EYVWadq1ar6e8vykJYCaZGI9tu2jTIQPHKClD5V Li7bB7l8l/1chbRwSiuevN9WrVplvfwg96X1SGiTYCu/dRyrcDdCud6/AMEQQCBJ65XLPlVBLd9l P1chge3rr782q1evdlZ+kPvSitatW2u/wFhldKOS6/0LEAwB4D+Gfq7Brv9INyqxfwGCIQDgHeT6 RiuAYAgAQADDoasboQCCIQAAAeH6RiiAYAgAQEC4vhEKIBgCAACAYAgAAACCIQAAAAiGAAAAIBgC AACAYEgVAAAAgGAIAAAAgiEAAAAIhgAAACAYAgAAgGAIAAAAgiEAAAAIhgAAACAYAgAAgGAIAAAA giEAAAAIhgAAACAYAgAAgGAIAAAAgiEAAAAIhgAAACAYAgAAgGAIAAAAgiEAAAAIhoD9A/+99/Tx tpZHvQMACIYAwZB6BwAQDIH/YjAkCFEfAEAwBEAQoj4AgGAIgCBEfQAAwRAIfEBJPX3x4sWmbt26 5v333zcFCxY0HTt2NIcOHYq6PG9aqEdm3L5920yaNMk0atTIFCpUyOTOnduUKVPGdO/e3ezYscNf rnz58lr2wYMH06z/1Vdf+X9Xnqd24MABnV6hQgUr9SC2bt1qWrdurcvmyZNH1124cKF5/fo1wRAA CIZA8ILhwIEDQwa6AgUKmNOnT2dZMNy9e7cpWbJkVGX17t1bX8+YMSNNGUlJSf6y8jy1adOm6fQ+ ffpYqQcJgDly5Ai5Tt++fQmGAEAwBIIXDKVV7rvvvjNXr141L168MPv27TM1atTQeb169cp0ebG4 du2aKVq0qK4vrYWbNm0yd+7c0e25fPmyWbFihWnWrJm//KpVq3RZadHznDp1SqdJuCxRooQ+l2me 9u3b6zRZN956OH78uLYqyrz+/fubs2fP6jpnzpzR4BlriykAgGAIZGswnDp1arp5f/75p8776KOP siQYDhs2TNf99NNPNWBFcv36dV0+f/78/vILFizQaXLZuVu3bvpcponnz5+bfPny6TRZN9566Nev n07v2bNnyO3r0aMHwRAACIZA8IKhtNa96dmzZzpP+s1lRTCsXr26rpu6H2EkNWvW1HV27dqlrz// /HN9vWTJEu0rKM9lmti5c6e+rlWrlpV6qFy5sk7fv39/yG3bu3cvwRAACIZA8IKhrfXiCUIJCQm6 7uPHj6NeZ9CgQbrOhAkTzKtXr0yRIkX09YULF8z58+f1eeHChXXeN998o69lHRv1kDdvXp329OnT kOvIdIIhABAMAYJhFgXDDRs26DrNmzf37ziuVKmSP79ixYp+q17Tpk31eUpKCsEQAEAwBMHwbQ6G sVxKvn//vsmVK5de5h0/fryuL33/PN6dwePGjdMbRWRZWcdGPXApGQAIhgDBMIPpH3zwgU5/8uRJ prdxxIgRfuvfy5cvo15P7mCW9WTMQ/l37dq1/rw1a9boNBlj0LvbOTP/z4zmc/MJABAMAYJhBtOr VKmi02V8v3CXWMNJPVxNcnKy2bx5s7l3756GRBmuZuXKlWmGq/GMGjXK3x4ZU/DmzZv+PHmeepzB 0aNHWwuGx44d84erGTBgQJrhalKPYUgwBACCIfBOBkMJXvEOcO2NPxjtYNnbtm3z58mvjrypTp06 /vzt27dbC4bCGx4n1CP1WIYAAIIh8M4FQxnaRVrwpP+d9PuLJRjdunVL+wTWq1fPJCYmaqtcuXLl zJdffqlDzrxJLlt7l7CHDh2abv6QIUN0niwTrhUz1noQ3k/iya+jyDiJ9evXN/Pnz+cn8QCAYAgA AACCIQAAAAiGAAAAIBgCAACAYAgAAACCIQAAAAiGAAAAIBgCAACAYAgAAACCIQAAAAiGAAAAIBgC AACAYAgAAACCIQAAAAiGAAAAIBgCAACAYAgAAACCIQAAAAiGAAAAwP8A3X7CZ3J0cIIAAAAASUVO RK5CYII= --0016e64cbf6c5bd4eb0495f8a3ca-- From abegen@cisco.com Sat Nov 27 12:33:59 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D670728C0DF for ; Sat, 27 Nov 2010 12:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.577 X-Spam-Level: X-Spam-Status: No, score=-8.577 tagged_above=-999 required=5 tests=[AWL=-2.018, BAYES_20=-0.74, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O83Tdsn1amzf for ; Sat, 27 Nov 2010 12:33:55 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 351F328C0EC for ; Sat, 27 Nov 2010 12:33:54 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8EAMz58EyrR7H+/2dsb2JhbACUTY5AcaUginKPOIVHBIRciRo X-IronPort-AV: E=Sophos;i="4.59,267,1288569600"; d="scan'208";a="626811736" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 27 Nov 2010 20:35:00 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oARKZ0DA002359; Sat, 27 Nov 2010 20:35:00 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 27 Nov 2010 12:35:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sat, 27 Nov 2010 12:34:26 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] A Challenge to TCPM Thread-Index: AcuNlUG/mOB0699nQE6fHFKA+8QeOgA3CztA References: From: "Ali C. Begen (abegen)" To: "Mike Belshe" , X-OriginalArrivalTime: 27 Nov 2010 20:35:00.0284 (UTC) FILETIME=[8FF587C0:01CB8E72] Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Nov 2010 20:34:00 -0000 I agree with some of the claims you are making below, and I don't agree = with some. I just wanna point out one thing, though. You are largely = dismissing the #1 reason why applications are often using more than 1 = TCP connection. It is not often about the tput. It is often (more than = often actually) about the delay (among a few other reasons), which is = critical for short-lived transactions. You can increase the IW to 100 for all I care but TCP will still have to = leave with the HOL blocking issue. IETF can make a recommendation on IW = but I have serious doubts about TCP vendors quickly adopting as you = suggest. As for the number of TCP connections in parallel, that is not = easy to place a policy anyway. Maybe, trying to fix TCP to make HTTP is not the best strategy here. -acbegen > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of Mike Belshe > Sent: Friday, November 26, 2010 1:11 PM > To: tcpm@ietf.org > Subject: [tcpm] A Challenge to TCPM >=20 > Hi, >=20 > I thought I'd add a slightly different perspective to the discussion = about initial cwnd. I'm a developer on Chrome & SPDY. >=20 > With SPDY, we want to build an application protocol which is efficient = on the transport, good for the network, and faster than > HTTP. But right now, TCP is holding us back because we're trying to = accomplish with one connection what HTTP does with > 10+ connections. >=20 > Note: I don't want to make this thread about SPDY. I hope the = members of this list agree that the goals of SPDY are good > and will help make TCP a friendly transport for an application = protocol like SPDY. >=20 > Background > Unrelated to TCP, HTTP is not very efficient. This has been widely = documented and observed for some time. We can easily > demonstrate a more efficient protocol, which transfers 25-35% fewer = packets than HTTP and reduces bytes transferred by > 10-15%. Hopefully everyone agrees those are good things for the = network. >=20 > Unfortunately, any TCP-based protocol which uses a single connection = is at a latency-handicap compared to any protocol that > uses multiple connections. This is due to IW. Further, because = bandwidth increases have outpaced RTT decreases, > bandwidth is relatively cheap. So, being efficient on your bandwidth = is less critical than being efficient on your round-trips. >=20 > To visualize the effects, please see the attached graph. (Or click = here = sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initial_cwnd_on_= plt(1).png?attachauth=3DANoY7cpm-y5NA- > zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9- > = QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3CzKbz= sxnGKlQaectqG8a7cjg5vgU1Gj4c > = FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFPQkA= mEI2FvRbq6IBg1aI%3D&attredirect > s=3D0> ) In these tests, I loaded a replica of the facebook landing = page through two protocols - one using a single connection in > a semi-efficient manner (an early version of spdy) and another using 6 = connections (http). I used a high-bandwidth network > with either 100ms or 200ms of RTT, and then I varied IW from 2pkts all = the way to 128pkts. I chose this network > configuration to specifically isolate the effects of high-RTT and IW. = As you can see, at low IW, the single-connection protocol > fares poorly compared to the multi-connection protocol. For another = writeup on the problem, see > = http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf >=20 > Today, the fastest way to deliver content is to simply side-step cwnd = by use of multiple connections. >=20 >=20 > The Problem > With SPDY (or whatever protocol comes next), we can definitely reduce = the number of connections out of the browser by *at > least* a factor of 6. With unfolding of the subdomain tricks that = websites have been doing, we can reduce it by a factor of > 10. This has nothing to do with TCP, except I hope that folks on this = list appreciate that this goodness: fewer connections - > fewer packets - and fewer bytes. >=20 > The only trouble is that if we abide to the RFCs, fewer connections + = fewer packets + fewer bytes equates to slower web > pages. >=20 > But I'm not asking that we increase IW by a factor of 10; because it = grows exponentially, if we can increase it to somewhere > in the ~16 range, it's good enough. >=20 >=20 > The Conundrum > More perplexing is that whenever we talk about increasing IW, we tend = to think of the static throttle that we have today. If > we increase a static throttle, it affects everything. So protocols = that are already bursting 20-30x more packets than they > should (by way of many connections) will burst even more. >=20 > This makes some people want to do nothing... >=20 > At the same time, we also know that cwnd has already been increased on = the net at large. This started with use of multiple > connections, multiplied with the use of multiple subdomains, and is = now changing by major sites simply increasing or > ignoring cwnd altogther. With so many sites systematically working = around cwnd, we know that the current limits can be > increased. We just don't know how much. >=20 >=20 > The Solution? > Is the obvious solution to stop using a static value? It doesn't seem = like we're in a one-size-fits-all for IW. >=20 > The IW could either be defined to be protocol-specific, or dynamic = based on number of TCP flows between the same two > endpoints. Both of these approaches would offer the benefit of a = controlled, increased cwnd to reflect the changes in the net > over the last 2 decades but also not completely unthrottle protocols = that are already living on the edge of not having > throttles. >=20 > Finally, if a dynamic throttle is too much to decide upon, at least = updating the static value seems appropriate. Jerrry and > Nandita have provided good data for a general-purpose increase to 10. = If inefficient protocols are allowed to go that high, > maybe more efficient protocols could be allowed to go higher (with = data, of course). >=20 >=20 > Reality Check > Finally, regardless of this debate in the IETF, what is actually going = to happen? >=20 > a) IETF does not increase the limit (or continues to wait): > As time goes on, more and more evidence emerges to demonstrate that = the current cwnd limits are unnecessarily > conservative. More evidence also emerges that increasing cwnd makes = your site faster. More sites start experimenting with > their own values of cwnd. Without a blessed recommendation from the = IETF, sites choose whatever values they want. Ben > Strong offered a writeup today which demonstrates this is already = happening and-microsoft-cheat-on-slow.html> . >=20 > b) IETF increases the limit: > With data and a specific recommendation, TCP vendors can quickly move = to the new recommendations, making their > products more competitive in the marketplace, and better for users. = Pressure is alleviated from existing sites to go > renegade, and instead they can rest on the specific findings from this = group. With a modern recommendation in hand, all of > us can credibly go after any sites which do choose to use dangerously = high cwnd values. Finally, having an officially > increased IW is an enabler for a future of more efficient application = level protocols, which are currently at a disadvantage to > their less-efficient counterparts. >=20 >=20 >=20 >=20 > Now, which of these two options carries more risk of internet = collapse? Vendors implementing whatever-the-heck-their- > rookie-system-administrator decided to configure? Or an official, = controlled and intelligent recommendation from this > group? >=20 >=20 > Thanks to everyone on this list for their hard work over the years - = although my email is somewhat critical, be aware that I > have immense gratitude and respect for the veterans of this list that = have been keeping the net flowing for so long with such > great success. > Mike From hkchu@google.com Sat Nov 27 20:46:14 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BF773A69C5 for ; Sat, 27 Nov 2010 20:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.781 X-Spam-Level: X-Spam-Status: No, score=-110.781 tagged_above=-999 required=5 tests=[AWL=1.195, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLNDL48Ynx1A for ; Sat, 27 Nov 2010 20:46:11 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C49A33A6927 for ; Sat, 27 Nov 2010 20:46:10 -0800 (PST) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id oAS4lGOB022793 for ; Sat, 27 Nov 2010 20:47:16 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290919636; bh=V++7XZ2YS0htfiqWkP0amA8iGB8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=yiLWTT3P5NM98ezdp0WKwyaX+UUtJySrbmWMzLDLM1WETJxlXhUumXVnecEwygcHg AKsy70eYwX/CmX1QW5lEA== Received: from ywa6 (ywa6.prod.google.com [10.192.1.6]) by hpaq7.eem.corp.google.com with ESMTP id oAS4lEgq031285 for ; Sat, 27 Nov 2010 20:47:15 -0800 Received: by ywa6 with SMTP id 6so16115086ywa.40 for ; Sat, 27 Nov 2010 20:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9DPGHgzjw6KW/9TTgfc0F1XRB1zcYOXoGzJhpw13XJs=; b=Ww5Ixol5mp5Rmye6m6qvEeeVGR+MqSJIQOP8d5cjbMWDgRAGJxliIt9qrlQuW4LFyh PVMb5Txrxp/lSbThEwFA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hwTixBGokRL3tXiZs9DQpUISJhGmcSddZ3uwb7aBLMKKVG/pW9gzFH8QnrBip0/yR7 OgfUuw0xiH4u6xjwi9zw== MIME-Version: 1.0 Received: by 10.151.158.7 with SMTP id k7mr7798513ybo.405.1290919633048; Sat, 27 Nov 2010 20:47:13 -0800 (PST) Received: by 10.151.158.13 with HTTP; Sat, 27 Nov 2010 20:47:12 -0800 (PST) In-Reply-To: <4CE58F37.7000407@isi.edu> References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> Date: Sat, 27 Nov 2010 20:47:12 -0800 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: multipart/alternative; boundary=0015174ff4fa295556049615a678 X-System-Of-Record: true Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 04:46:14 -0000 --0015174ff4fa295556049615a678 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 18, 2010 at 12:40 PM, Joe Touch wrote: > > > On 11/18/2010 12:28 PM, Mark Allman wrote: > >> >> (It *could* have a history as you have noted (and conducted research >>>> on). But, the practical efficacy of that has at least not been >>>> shown (as far as I know; perhaps I am out of the loop). E.g., how >>>> often do two hosts communicate? >>>> >>> >>> You keep assuming that whether an IW works is a property of a single >>> source, or of a pair of endpoints. >>> >> >> I ain't so good with the English and only passable at American, but over >> here "e.g." means "for example". >> >> Yes, certainly one can think of cases where the congested point is close >> to the sender and therefore a cache would want to consider many (or all) >> recipients as equivalent for IW treatment. If you're thinking of >> caching this sort of state then that seems like a case to work out, for >> sure. >> >> I am concerned about cases where the IW interacts with a link that >>> affects communication with MANY hosts, and so ends up being a property >>> of a set of receivers, or all receivers. >>> >> >> This doesn't concern me all that much ... >> >> - If the congestion point is pretty local then we're very much only >> hurting (if we are hurting) ourselves or those within our >> institution because we don't traverse the shared Internet. >> >> - If the initial window is problematic across all connections then it >> seems clear that its a bogus IW setting. >> > > Or > > - we're sharing an access point at a coffee shop, or one of > those card-deck sized mobile hotspots (wifi-cell modem) > > - we all live in an apartment building or on the same cable > Internet segment, or some similar enclave (a cruise ship comes > to mind) > > - we're all behind some firewall somewhere, such as at a > big company, or even a country > > Ultimately, either the IW setting mostly works or it doesn't. If it works, > we can keep using it or make it larger. If it doesn't, we should back off. > I'm not sure if it's that simple and I don't know the "IW setting" your referred to above is on a per-host, per-dest-IP, or per-whatever basis. From all your objections so far you seem to be pushing the choice of IW toward the direction that is reserved for TCP's dynamic CC algorithm, to figure out an optimal cwnd to use for a given path right from the start for a connection. But this is not the job of IW, as Mark Allman pointed out repeatedly. So what qualifies as a good IW? It needs not be optimal because it'd require too much work to get to the "optimal" value from the beginning (cache from the past history, offline database...), and it can not be optimal because the cwnd (together with RTT) as a measure of the fair-shared bottleneck b/w includes a temporal component as well, that can only be captured dynamically through TCP's CC algorithm. A good choice of IW IMO can't be too conservative nor too aggressive. It needs to work well for the vast majority of connections/paths on the Internet. For the few cases it may not work well, TCP will puzzle its way out (as Mark put it). In our opinion IW3 is too conservative. IW10 will be a good choice and its benefit far outweighs its penalty. > That's an invitation for an automatic system, IMO, not a schedule of > updates in an RFC. > > > But, regardless, my high order bits on this between connection business >> are two-fold: >> >> (1) It does not divorce us from needing a default initial window when >> there is no previous history to suggest what the IW should be. >> > > We always need a starting point. If a system *automatically* converges over > a reasonable time, it doesn't matter much what that is. > > If however that's a fixed value, it matters. > > > (2) We have no idea how it would or could work. There have been >> forays into congestion information sharing, but we don't (as far >> as I know) have any understanding of often it'd be useful in >> reality. Nor do we have any sort of scheme to figure out what >> connections should be considered together when caching (i.e., >> caching information obtained from connections between two IPs >> seems simple enough, but how do we go beyond that?). This seems >> like a research project to me---not a viable alternative to >> thinking about the IW. >> > > I'm thinking very coarsely; if it hurts most of the time when I do this, > then stop doing it. It can be based on 80% - if 80% of the connections lose > packets using IW=10, then backoff. If not, then don't. If 80% of the > connections don't lose packets, then try a larger IW. > > You don't need much more than a counter of whether packets are lost during > an IW and how many connections you have. > I'm all for simplicity and if the very coarse scheme above actually serves some purpose, i.e., works to protect some cases that may suffer from a larger IW that I'm all for it. But does it work? It may work for some very limited cases where a router with very small buffer space is near the sender hosts. But I can't even think of such a case right from the top of my head as the common case of users behind slow 56Kbps links is on the receiving, not sending end, where a different measure like advertising a small init receive window as mentioned in our draft will work well. Will the above coarse measurement works for a web server in general? If our proposed IW has been completely out of line (e.g., IW64) it may have worked, but then we'd have found out long ago from our large scale experiments. > Yes, this is an experiment -- BUT SO IS PICKING IW=10, or SETTING A > SCHEDULE OF IW INCREASES OVER TIME. The point is that it's an adaptive > solution that should end up doing the right thing without constant > oversight. > I'd love for someone to show me a simple adaptive solution actually works so we can incorporate it into our proposal, get it approved by the community, and move on to tons of other work. But I doubt it will be that simple. Jerry > ... > > Really? You can tell the difference between 1 second and 0.8 >>> seconds? or 1.2 seconds? >>> >> >> Yep. That's what they tell me. I haven't run the tests, but yeah >> that's the right order for human perception to start. >> > > People can notice things down to about 200ms. That does NOT mean they know > 1 vs 1.2 seconds, though - and definitely not 400 vs 500ms. We looked at > this issue in the mid 90s when looking at web push systems. > > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0015174ff4fa295556049615a678 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Nov 18, 2010 at 12:40 PM, Joe Touch <touch@isi.edu> wrote:


On 11/18/2010 12:28 PM, Mark Allman wrote:

=A0 =A0 =A0(It *could* have a history as you have noted (and conducted res= earch
=A0 =A0 =A0on). =A0But, the practical efficacy of that has at least not be= en
=A0 =A0 =A0shown (as far as I know; perhaps I am out of the loop). =A0E.g.= , how
=A0 =A0 =A0often do two hosts communicate?

You keep assuming that whether an IW works is a property of a single
source, or of a pair of endpoints.

I ain't so good with the English and only passable at American, but ove= r
here "e.g." means "for example".

Yes, certainly one can think of cases where the congested point is close to the sender and therefore a cache would want to consider many (or all) recipients as equivalent for IW treatment. =A0If you're thinking of
caching this sort of state then that seems like a case to work out, for
sure.

I am concerned about cases where the IW interacts with a link that
affects communication with MANY hosts, and so ends up being a property
of a set of receivers, or all receivers.

This doesn't concern me all that much ...

=A0 - If the congestion point is pretty local then we're very much onl= y
=A0 =A0 hurting (if we are hurting) ourselves or those within our
=A0 =A0 institution because we don't traverse the shared Internet.

=A0 - If the initial window is problematic across all connections then it<= br> =A0 =A0 seems clear that its a bogus IW setting.

Or

=A0 =A0 =A0 =A0- we're sharing an access point at a coffee shop, or on= e of
=A0 =A0 =A0 =A0those card-deck sized mobile hotspots (wifi-cell modem)

=A0 =A0 =A0 =A0- we all live in an apartment building or on the same cable=
=A0 =A0 =A0 =A0Internet segment, or some similar enclave (a cruise ship co= mes
=A0 =A0 =A0 =A0to mind)

=A0 =A0 =A0 =A0- we're all behind some firewall somewhere, such as at = a
=A0 =A0 =A0 =A0big company, or even a country

Ultimately, either the IW setting mostly works or it doesn't. If it wor= ks, we can keep using it or make it larger. If it doesn't, we should ba= ck off.

I'm not sure if it's th= at simple and I don't know the "IW setting" your referred to = above is on a per-host,
per-dest-IP, or per-whatever basis. From all your objections so far yo= u seem to be pushing the choice
of IW toward the direction that i= s reserved for TCP's dynamic CC algorithm, to figure out an optimal
cwnd=A0to use for a given path right from the start for a connection.= =A0But this is not the job of IW, as
Mark Allman pointed out repe= atedly.

So what qualifies as a good IW? It needs n= ot be optimal because=A0it'd=A0require too much work to get to
the "optimal" value from the beginning (cache from the past = history,=A0offline=A0database...), and it can not
be optimal=A0be= cause the cwnd (together with RTT) as a measure of=A0the fair-shared=A0bott= leneck=A0b/w
includes a temporal component as well, that can only be captured=A0dyn= amically through TCP's CC
algorithm.

A good choice of IW IMO can't be too conservative nor too aggressive. = It needs to work well for
the vast majority of connections/paths on the Internet. For the few ca= ses it may not work well,
TCP will=A0puzzle its way out (as Mark = put it). In our opinion IW3 is too conservative. IW10 will
be a g= ood choice and its benefit far outweighs its penalty.


That's an invitation for an automatic system, IMO, not a schedule of up= dates in an RFC.


But, regardless, my high order bits on this between connection business
are two-fold:

=A0 (1) It does not divorce us from needing a default initial window when<= br> =A0 =A0 =A0 there is no previous history to suggest what the IW should be.=

We always need a starting point. If a system *automatically* converges over= a reasonable time, it doesn't matter much what that is.

If however that's a fixed value, it matters.


=A0 (2) We have no idea how it would or could work. =A0There have been
=A0 =A0 =A0 forays into congestion information sharing, but we don't (= as far
=A0 =A0 =A0 as I know) have any understanding of often it'd be useful = in
=A0 =A0 =A0 reality. =A0Nor do we have any sort of scheme to figure out wh= at
=A0 =A0 =A0 connections should be considered together when caching (i.e.,<= br> =A0 =A0 =A0 caching information obtained from connections between two IPs<= br> =A0 =A0 =A0 seems simple enough, but how do we go beyond that?). =A0This s= eems
=A0 =A0 =A0 like a research project to me---not a viable alternative to =A0 =A0 =A0 thinking about the IW.

I'm thinking very coarsely; if it hurts most of the time when I do this= , then stop doing it. It can be based on 80% - if 80% of the connections lo= se packets using IW=3D10, then backoff. If not, then don't. If 80% of t= he connections don't lose packets, then try a larger IW.

You don't need much more than a counter of whether packets are lost dur= ing an IW and how many connections you have.

I'm all for simplicity and if the very coarse scheme above actual= ly serves some purpose, i.e., works to
protect some cases that=A0may suffer from a larger IW that I'm all= for it. But does it work?

It may work for some ve= ry limited cases where a router with very small buffer space is near the se= nder
hosts. But I can't even think of such a case right from the top of= my head as the common case
of users behind slow 56Kbps links is = on the receiving, not sending end, where a different measure like
advertising a small init receive window as mentioned in our draft will= work well. Will the above coarse
measurement works for a web ser= ver in general? If our proposed IW has been completely out of line
(e.g., IW64) it may have worked, but then we'd have found out long= ago from our large scale
experiments.


Yes, this is an experiment -- BUT SO IS PICKING IW=3D10, or SETTING A SCHED= ULE OF IW INCREASES OVER TIME. The point is that it's an adaptive solut= ion that should end up doing the right thing without constant oversight.

I'd love for someone to show me a simp= le adaptive solution actually works so we can incorporate it into
our=A0proposal, get it approved by the community, and move on to tons of o= ther work. But I doubt it will
be that simple.

Jerry


...

Really? You can tell the difference between 1 second and 0.8
seconds? or 1.2 seconds?

Yep. =A0That's what they tell me. =A0I haven't run the tests, but y= eah
that's the right order for human perception to start.

People can notice things down to about 200ms. That does NOT mean they know = 1 vs 1.2 seconds, though - and definitely not 400 vs 500ms. We looked at th= is issue in the mid 90s when looking at web push systems.


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

--0015174ff4fa295556049615a678-- From jakob.heitz@ericsson.com Sat Nov 27 21:00:19 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9CE3A6A68 for ; Sat, 27 Nov 2010 21:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0Xq2GllOJCm for ; Sat, 27 Nov 2010 21:00:18 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id A98CE3A6927 for ; Sat, 27 Nov 2010 21:00:18 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oAS51OL8015367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 27 Nov 2010 23:01:25 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.213]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 28 Nov 2010 00:01:24 -0500 From: Jakob Heitz To: "tcpm@ietf.org" Date: Sun, 28 Nov 2010 00:01:20 -0500 Thread-Topic: [tcpm] alternate IW proposal Thread-Index: AcuOt1sJP4U4yqp/Qq+AS4lvduUK6gAAP1cQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D213909B736A327@EUSAACMS0701.eamcs.ericsson.se> References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7309FCBCAE981B43ABBE69B31C8D213909B736A327EUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 05:00:19 -0000 --_000_7309FCBCAE981B43ABBE69B31C8D213909B736A327EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why does IW need to be standardized? How will any host/router on the internet change its behaviour based on the = standardized value? That is, any host/router other than the TCP sender. Has anyone tried an IW based on advertized receive window rather than on MS= S? -- Jakob Heitz. --_000_7309FCBCAE981B43ABBE69B31C8D213909B736A327EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Why does IW need to be=20 standardized?
How will any host/router on the internet change = its=20 behaviour based on the standardized value? That is, any host/router other t= han=20 the TCP sender.
 
Has anyone tried an IW based on advertized recei= ve=20 window rather than on MSS?

--
Jakob Heitz.

--_000_7309FCBCAE981B43ABBE69B31C8D213909B736A327EUSAACMS0701e_-- From hkchu@google.com Sat Nov 27 22:12:30 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4CE73A69CD for ; Sat, 27 Nov 2010 22:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.715 X-Spam-Level: X-Spam-Status: No, score=-109.715 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjDa9isvUA+A for ; Sat, 27 Nov 2010 22:12:28 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 181C13A6816 for ; Sat, 27 Nov 2010 22:12:27 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id oAS6DXTf027785 for ; Sat, 27 Nov 2010 22:13:33 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1290924814; bh=J1JfJwQIiAKWo3ebREsIGCN4VSA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=emmT7ad+2315JunvV5Zb8N5lP8BIo5/gLmd/txo0Z4kD1y4SNfYausmU7iYGmQTpR A85bkmVxcA8drBcyHvVEg== Received: from yxd5 (yxd5.prod.google.com [10.190.1.197]) by wpaz33.hot.corp.google.com with ESMTP id oAS6DWhA021006 for ; Sat, 27 Nov 2010 22:13:32 -0800 Received: by yxd5 with SMTP id 5so1563098yxd.6 for ; Sat, 27 Nov 2010 22:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xw7qgaH5xhbaHOEzZjc4eVIdQicxL+x4JbJoUKRS9ok=; b=LZGrKt0f66ztHceD6BbKT6ot4rREscdpChNO6gbHqusdIj7FRM+czrnNg7L9XMQFqt FiBj8BV546X/pZWeI9ew== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=drhJF6bEPSv12lb2uGinEsV6+vYnzO08teAEIbnBetbl28oP3Ic9nrLA0XOPTVG2WL u57ros/hrxbnupER87Sg== MIME-Version: 1.0 Received: by 10.150.218.21 with SMTP id q21mr7637934ybg.177.1290924810673; Sat, 27 Nov 2010 22:13:30 -0800 (PST) Received: by 10.151.158.13 with HTTP; Sat, 27 Nov 2010 22:13:30 -0800 (PST) In-Reply-To: <4CE554FD.8040304@isi.edu> References: <20101118032123.091DF2523EF7@lawyers.icir.org> <4CE554FD.8040304@isi.edu> Date: Sat, 27 Nov 2010 22:13:30 -0800 Message-ID: From: Jerry Chu To: Joe Touch Content-Type: multipart/alternative; boundary=000e0cd40650c5a14f049616da0c X-System-Of-Record: true Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 06:12:30 -0000 --000e0cd40650c5a14f049616da0c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 18, 2010 at 8:31 AM, Joe Touch wrote: > Hi, Mark, > > > On 11/17/2010 7:21 PM, Mark Allman wrote: > >> >> I disagree. I have said this before. The initial congestion window is >>>> a parameter choice. As long as we pick a reasonable parameter then TCP >>>> will puzzle its way out (in the cases where that is even needed; a >>>> reasonable number would be a cwnd that the vast majority of connections >>>> would be able to attain---given enough data---anyway). >>>> >>> >>> That would be true of TCP learned the IW over time, >>> >> >> I disagree. Its fine if we see this differently. But, I don't find >> your argument correct at all. I.e., >> >> - TCP will react to problems in the initial window. It will. It will >> figure itself out of it within a connection. >> > > TCP does NOT react to problems in the IW. It keeps using the same IW for > every connection, banging its head against the wall continually. > > It COULD. That's what I'm wondering might be useful... > > e.g.: > TCP MAY increase its IW if it monitors the impact of that > increase, and uses an AIMD algorithm to adjust the IW values > over time. > > > - The cross connection dynamic is presuming you're making the same >> mistakes over-and-over. That isn't clear. If you make a zillion >> 10 packet connections to some host then OK. I am willing to call >> that pathological. >> > > Let me be more clear. The IW isn't a property of the destination, it's a > property of the path. Either the path can tolerate new connections with > large IWs, or it cannot. > > Some paths from a given source may exhibit problems only for some > destinations. However, there are some sources that have problems ON THEIR > END of the network, i.e., that impact most, if not all, of their > connections. > > E.g., a laptop on a low-speed link, or on a disadvantaged net. > > > - The vast majority of traffic volume is from large flows that >> converge via the usual AIMD. Therefore, by traffic volume the >> initial window is a quite small effect---especially if we are >> roughly in the area of "reasonable" (i.e., if the 10 packet window >> works the vast majority of the time). >> > > IW traffic is bursty, and bursts tend to synchronize. Further, IW is uses > more than just for the connection Not true. IW and RW in recent RFCs have been treated as two separate variables. Moreover, we actually propose to reset RW according to RFC3390 if there had been loss during IW10 as follows: [draft-ietf-tcpm-initcwnd-00.txt] Furthermore, to limit any negative effect that a larger initial window may have on links with limited bandwidth or buffer space, implementations SHOULD fall back to RFC 3390 for the restart window (RW), if any packet loss is detected during either the initial window, or a restart window, when more than 4KB of data is sent. The above is a great example of our design principle - anything that is simple to implement to limit the potential damage when retaining the bulk of the benefit, we'd love to adopt. But any caching scheme from the past history that requires lots of memory, and/or slowly growing the IW, and/or high cache hit rate in order to work is just a non-starter IMO. (We even attempted at some point a "negative" cache scheme to work around the low cache hit problem but decided to give up.) Jerry start - it's also used for restart, e.g., after an idle period. This all > means that increasing the IW without feedback could easily lead to problems > that we cannot correct once deployed. > > ... > > 2) the rationale for the proposal is a particular current use >>> >>> The increased performance rationale for this is sketchy at best, and >>> it's not clear that endorsing this sort of 'millions of individual >>> connections' use is good for the network (or whether it's even >>> necessary, given appropriate use of Nagle and a reasonable number of >>> concurrent connections) >>> >> >> [I can't parse this at all.] >> > > Let me rephrase: > > How much does this help? How much does it reduce latency? Most of the info > I've seen summarized suggests the benefit is in the 5-20% range. That's not > even noticeable from a user POV. > > So, back to my original point, how about IW using a long-timescale AIMD? If > we do that, we can avoid needing to monitor the problem en-masse, and the > system will adapt over time and we won't be back here in another 10 years... > > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000e0cd40650c5a14f049616da0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Nov 18, 2010 at 8:31 AM, Joe Tou= ch <touch@isi.edu= > wrote:
Hi, Mark,


On 11/17/2010 7:21 PM, Mark Allman wrote:

I disagree. =A0I have said this before. =A0The initial congestion window is=
a parameter choice. =A0As long as we pick a reasonable parameter then TCP will puzzle its way out (in the cases where that is even needed; a
reasonable number would be a cwnd that the vast majority of connections
would be able to attain---given enough data---anyway).

That would be true of TCP learned the IW over time,

I disagree. =A0Its fine if we see this differently. =A0But, I don't fin= d
your argument correct at all. =A0I.e.,

=A0 - TCP will react to problems in the initial window. =A0It will. =A0It = will
=A0 =A0 figure itself out of it within a connection.

TCP does NOT react to problems in the IW. It keeps using the same IW for ev= ery connection, banging its head against the wall continually.

It COULD. That's what I'm wondering might be useful...

e.g.:
=A0 =A0 =A0 =A0TCP MAY increase its IW if it monitors the impact of that =A0 =A0 =A0 =A0increase, and uses an AIMD algorithm to adjust the IW value= s
=A0 =A0 =A0 =A0over time.


=A0 - The cross connection dynamic is presuming you're making the same=
=A0 =A0 mistakes over-and-over. =A0That isn't clear. =A0If you make a = zillion
=A0 =A0 10 packet connections to some host then OK. =A0I am willing to cal= l
=A0 =A0 that pathological.

Let me be more clear. The IW isn't a property of the destination, it= 9;s a property of the path. Either the path can tolerate new connections wi= th large IWs, or it cannot.

Some paths from a given source may exhibit problems only for some destinati= ons. However, there are some sources that have problems ON THEIR END of the= network, i.e., that impact most, if not all, of their connections.

E.g., a laptop on a low-speed link, or on a disadvantaged net.


=A0 - The vast majority of traffic volume is from large flows that
=A0 =A0 converge via the usual AIMD. =A0Therefore, by traffic volume the =A0 =A0 initial window is a quite small effect---especially if we are
=A0 =A0 roughly in the area of "reasonable" (i.e., if the 10 pac= ket window
=A0 =A0 works the vast majority of the time).

IW traffic is bursty, and bursts tend to synchronize. Further, IW is uses m= ore than just for the connection

Not true.= IW and RW in recent RFCs have been treated as two separate variables. More= over, we actually
propose to reset RW according to RFC3390 if there had been loss during= IW10 as follows:
[draft-ietf-tcpm-initcwnd-00.txt]
=A0=A0 Furthermore, to limit any negative effect that a la= rger initial
=A0=A0 window may have on links with limited bandwidth or buffer space= ,
=A0=A0 implementations SHOULD fall back to RFC 3390 for the res= tart window
=A0=A0 (RW), if any packet loss is detected during ei= ther the initial
=A0=A0 window, or a restart window, when more than 4KB of data is sent= .

The above is a great example of our design= principle - anything that is simple to implement to limit the
po= tential damage when retaining the bulk of the benefit, we'd love to ado= pt.

But any caching scheme from the past history that requi= res lots of memory, and/or slowly growing
the IW, and/or high cac= he hit rate in order to work is just a=A0non-starter IMO. (We even attempte= d
at some point a=A0"negative" cache scheme to work around the= low cache hit problem but decided
to give up.)

Jerry

start - it's also used for restart, e.g., after an idle period. This al= l means that increasing the IW without feedback could easily lead to proble= ms that we cannot correct once deployed.

...

2) the rationale for the proposal is a particular current use

The increased performance rationale for this is sketchy at best, and
it's not clear that endorsing this sort of 'millions of individual<= br> connections' use is good for the network (or whether it's even
necessary, given appropriate use of Nagle and a reasonable number of
concurrent connections)

[I can't parse this at all.]

Let me rephrase:

How much does this help? How much does it reduce latency? Most of the info = I've seen summarized suggests the benefit is in the 5-20% range. That&#= 39;s not even noticeable from a user POV.

So, back to my original point, how about IW using a long-timescale AIMD? If= we do that, we can avoid needing to monitor the problem en-masse, and the = system will adapt over time and we won't be back here in another 10 yea= rs...


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

--000e0cd40650c5a14f049616da0c-- From rs@netapp.com Sun Nov 28 03:38:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC2428C0CF for ; Sun, 28 Nov 2010 03:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.352 X-Spam-Level: X-Spam-Status: No, score=-9.352 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_00=-2.599, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mstd0gGm0ltS for ; Sun, 28 Nov 2010 03:38:43 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 8432E3A6AB5 for ; Sun, 28 Nov 2010 03:38:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,269,1288594800"; d="scan'208";a="228450070" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 28 Nov 2010 03:39:48 -0800 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 oASBdlmD004150; Sun, 28 Nov 2010 03:39:47 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Nov 2010 12:39:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 28 Nov 2010 11:39:45 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0BA9624C@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] A Challenge to TCPM Thread-Index: AcuNlUG/mOB0699nQE6fHFKA+8QeOgA3CztAAB9I3tA= References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> From: "Scheffenegger, Richard" To: "Ali C. Begen (abegen)" , "Mike Belshe" , X-OriginalArrivalTime: 28 Nov 2010 11:39:47.0099 (UTC) FILETIME=[F56C1EB0:01CB8EF0] Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 11:38:45 -0000 Hi, I'm also very interested in fixing head-of-line blocking. However, that is IMHO orthogonal to reducing small flow completion times. More to the point, if numerous applications were really concerned about HOL blocking, you'd expect that they run (idempotent) IO calls over more than a single TCP session, and go with the earlier response. However, I'm not aware that such a behavior is widely deployed in the public internet. Do you have pointers to show how common such protocols are? (Online Gaming with their proprietary protocols comes to mind. But I believe many games use UDP). Also, there already exists another protocol, that can deliver objects to the receiver, even if some earlier in-sequence data is missing (and blocks the delivery of an earlier object): SCTP. Anyway, TCP still has a little bit of room to improve error recovery latency. Ie. using commonly used extensions in a more synergistic way can allow loss recovery in ~1RTT under many more circumstances than today. Improving dupthresh and RTTM algorithms would also reduce the fraction of RTO loss recovery. See also: S. Rewaskar, J. Kaur, and F.D. Smith, "A Performance Study of Loss Detection/Recovery in Real-world TCP Implementations"=20 , in Proceedings of the IEEE International Conference on Network Protocols (ICNP'07), Beijing, China, Oct 2007. Richard Scheffenegger =20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 > Sent: Samstag, 27. November 2010 21:34 > To: Mike Belshe; tcpm@ietf.org > Subject: Re: [tcpm] A Challenge to TCPM >=20 > I agree with some of the claims you are making below, and I=20 > don't agree with some. I just wanna point out one thing,=20 > though. You are largely dismissing the #1 reason why=20 > applications are often using more than 1 TCP connection. It=20 > is not often about the tput. It is often (more than often=20 > actually) about the delay (among a few other reasons), which=20 > is critical for short-lived transactions. >=20 > You can increase the IW to 100 for all I care but TCP will=20 > still have to leave with the HOL blocking issue. IETF can=20 > make a recommendation on IW but I have serious doubts about=20 > TCP vendors quickly adopting as you suggest. As for the=20 > number of TCP connections in parallel, that is not easy to=20 > place a policy anyway. >=20 > Maybe, trying to fix TCP to make HTTP is not the best strategy here. >=20 > -acbegen >=20 > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org]=20 > On Behalf=20 > > Of Mike Belshe > > Sent: Friday, November 26, 2010 1:11 PM > > To: tcpm@ietf.org > > Subject: [tcpm] A Challenge to TCPM > >=20 > > Hi, > >=20 > > I thought I'd add a slightly different perspective to the=20 > discussion about initial cwnd. I'm a developer on Chrome & SPDY. > >=20 > > With SPDY, we want to build an application protocol which=20 > is efficient=20 > > on the transport, good for the network, and faster than HTTP. But=20 > > right now, TCP is holding us back because we're trying to=20 > accomplish=20 > > with one connection what HTTP does with > > 10+ connections. > >=20 > > Note: I don't want to make this thread about SPDY. I hope the=20 > > members of this list agree that the goals of SPDY are good=20 > and will help make TCP a friendly transport for an=20 > application protocol like SPDY. > >=20 > > Background > > Unrelated to TCP, HTTP is not very efficient. This has been widely=20 > > documented and observed for some time. We can easily demonstrate a=20 > > more efficient protocol, which transfers 25-35% fewer=20 > packets than HTTP and reduces bytes transferred by 10-15%. =20 > Hopefully everyone agrees those are good things for the network. > >=20 > > Unfortunately, any TCP-based protocol which uses a single=20 > connection=20 > > is at a latency-handicap compared to any protocol that uses=20 > multiple=20 > > connections. This is due to IW. Further, because=20 > bandwidth increases have outpaced RTT decreases, bandwidth is=20 > relatively cheap. So, being efficient on your bandwidth is=20 > less critical than being efficient on your round-trips. > >=20 > > To visualize the effects, please see the attached graph. (Or click=20 > > here >=20 > sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initial_cwnd_ > > on_plt(1).png?attachauth=3DANoY7cpm-y5NA- > > zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9- > >=20 > QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3Cz > > KbzsxnGKlQaectqG8a7cjg5vgU1Gj4c=20 > >=20 > FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFP > > QkAmEI2FvRbq6IBg1aI%3D&attredirect > > s=3D0> ) In these tests, I loaded a replica of the facebook landing = > > page through two protocols - one using a single connection in a=20 > > semi-efficient manner (an early version of spdy) and=20 > another using 6=20 > > connections (http). I used a high-bandwidth network with=20 > either 100ms or 200ms of RTT, and then I varied IW from 2pkts=20 > all the way to 128pkts. I chose this network configuration=20 > to specifically isolate the effects of high-RTT and IW. As=20 > you can see, at low IW, the single-connection protocol > > fares poorly compared to the multi-connection protocol. =20 > For another writeup on the problem, see > >=20 > http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.p > > df > >=20 > > Today, the fastest way to deliver content is to simply=20 > side-step cwnd by use of multiple connections. > >=20 > >=20 > > The Problem > > With SPDY (or whatever protocol comes next), we can=20 > definitely reduce=20 > > the number of connections out of the browser by *at > > least* a factor of 6. With unfolding of the subdomain tricks that=20 > > websites have been doing, we can reduce it by a factor of 10. This=20 > > has nothing to do with TCP, except I hope that folks on=20 > this list appreciate that this goodness: fewer connections -=20 > fewer packets - and fewer bytes. > >=20 > > The only trouble is that if we abide to the RFCs, fewer=20 > connections +=20 > > fewer packets + fewer bytes equates to slower web pages. > >=20 > > But I'm not asking that we increase IW by a factor of 10;=20 > because it=20 > > grows exponentially, if we can increase it to somewhere in=20 > the ~16 range, it's good enough. > >=20 > >=20 > > The Conundrum > > More perplexing is that whenever we talk about increasing=20 > IW, we tend=20 > > to think of the static throttle that we have today. If we=20 > increase a=20 > > static throttle, it affects everything. So protocols that=20 > are already bursting 20-30x more packets than they should (by=20 > way of many connections) will burst even more. > >=20 > > This makes some people want to do nothing... > >=20 > > At the same time, we also know that cwnd has already been=20 > increased on the net at large. This started with use of multiple > > connections, multiplied with the use of multiple subdomains, and is=20 > > now changing by major sites simply increasing or ignoring cwnd=20 > > altogther. With so many sites systematically working=20 > around cwnd, we know that the current limits can be=20 > increased. We just don't know how much. > >=20 > >=20 > > The Solution? > > Is the obvious solution to stop using a static value? It=20 > doesn't seem like we're in a one-size-fits-all for IW. > >=20 > > The IW could either be defined to be protocol-specific, or dynamic=20 > > based on number of TCP flows between the same two=20 > endpoints. Both of=20 > > these approaches would offer the benefit of a controlled, increased=20 > > cwnd to reflect the changes in the net over the last 2=20 > decades but also not completely unthrottle protocols that are=20 > already living on the edge of not having throttles. > >=20 > > Finally, if a dynamic throttle is too much to decide upon, at least=20 > > updating the static value seems appropriate. Jerrry and=20 > Nandita have=20 > > provided good data for a general-purpose increase to 10. =20 > If inefficient protocols are allowed to go that high, maybe=20 > more efficient protocols could be allowed to go higher (with=20 > data, of course). > >=20 > >=20 > > Reality Check > > Finally, regardless of this debate in the IETF, what is=20 > actually going to happen? > >=20 > > a) IETF does not increase the limit (or continues to wait): > > As time goes on, more and more evidence emerges to demonstrate that=20 > > the current cwnd limits are unnecessarily conservative. =20 > More evidence=20 > > also emerges that increasing cwnd makes your site faster. =20 > More sites=20 > > start experimenting with their own values of cwnd. Without=20 > a blessed=20 > > recommendation from the IETF, sites choose whatever values=20 > they want.=20 > > Ben Strong offered a writeup today which demonstrates this=20 > is already=20 > > happening > and-microsoft-cheat-on-slow.html> . > >=20 > > b) IETF increases the limit: > > With data and a specific recommendation, TCP vendors can=20 > quickly move=20 > > to the new recommendations, making their products more=20 > competitive in=20 > > the marketplace, and better for users. Pressure is alleviated from=20 > > existing sites to go renegade, and instead they can rest on the=20 > > specific findings from this group. With a modern recommendation in=20 > > hand, all of us can credibly go after any sites which do=20 > choose to use dangerously high cwnd values. Finally, having=20 > an officially increased IW is an enabler for a future of more=20 > efficient application level protocols, which are currently at=20 > a disadvantage to their less-efficient counterparts. > >=20 > >=20 > >=20 > >=20 > > Now, which of these two options carries more risk of internet=20 > > collapse? Vendors implementing whatever-the-heck-their-=20 > > rookie-system-administrator decided to configure? Or an=20 > official, controlled and intelligent recommendation from this group? > >=20 > >=20 > > Thanks to everyone on this list for their hard work over=20 > the years -=20 > > although my email is somewhat critical, be aware that I=20 > have immense=20 > > gratitude and respect for the veterans of this list that=20 > have been keeping the net flowing for so long with such great success. > > Mike > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From abegen@cisco.com Sun Nov 28 05:07:27 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4965E3A6B85 for ; Sun, 28 Nov 2010 05:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.429 X-Spam-Level: X-Spam-Status: No, score=-9.429 tagged_above=-999 required=5 tests=[AWL=-1.011, BAYES_00=-2.599, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RbH3ExeH5ug for ; Sun, 28 Nov 2010 05:07:25 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AAF3B3A6B78 for ; Sun, 28 Nov 2010 05:07:25 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigDAP/i8UyrR7H+/2dsb2JhbACUSI5AcaZyinKPHoVHBIRciRo X-IronPort-AV: E=Sophos;i="4.59,270,1288569600"; d="scan'208";a="627058442" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 28 Nov 2010 13:08:33 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oASD8XM2019170; Sun, 28 Nov 2010 13:08:33 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 28 Nov 2010 05:08:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sun, 28 Nov 2010 05:07:58 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DC92F71@xmb-sjc-215.amer.cisco.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0BA9624C@LDCMVEXC1-PRD.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] A Challenge to TCPM Thread-Index: AcuNlUG/mOB0699nQE6fHFKA+8QeOgA3CztAAB9I3tAAAwxuUA== References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0BA9624C@LDCMVEXC1-PRD.hq.netapp.com> From: "Ali C. Begen (abegen)" To: "Scheffenegger, Richard" , "Mike Belshe" , X-OriginalArrivalTime: 28 Nov 2010 13:08:32.0931 (UTC) FILETIME=[5BDD9730:01CB8EFD] Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 13:07:27 -0000 > -----Original Message----- > From: Scheffenegger, Richard [mailto:rs@netapp.com] > Sent: Sunday, November 28, 2010 6:40 AM > To: Ali C. Begen (abegen); Mike Belshe; tcpm@ietf.org > Subject: RE: [tcpm] A Challenge to TCPM >=20 >=20 >=20 > Hi, >=20 > I'm also very interested in fixing head-of-line blocking. However, = that > is IMHO orthogonal to reducing small flow completion times. More to = the > point, if numerous applications were really concerned about HOL > blocking, you'd expect that they run (idempotent) IO calls over more > than a single TCP session, and go with the earlier response. However, Let me clarify this a bit. If your app is not very concerned about the delay but rather tput in = general and that is why it is opening multiple connections, then we may = call it unfriendly. And probably no matter what we do, they won't change = their behavior much (they could use iw of 10, 20 or whatever but they = are likely to continue using multiple connections since in general this = will favor them or they will "feel" so). My point was that in the apps where the user is worried about the delay, = HOL blocking is a big problem and opening an alternative TCP is usually = the temp solution for this. Giving this guy the flexibility of using iw = of 10 or 20 does not help. > I'm not aware that such a behavior is widely deployed in the public > internet. Do you have pointers to show how common such protocols are? One major example is the streaming video (over http). It is already = using most of the consumer IP traffic today and it will suck even more = next year. And yes, the clients are smart enough to go around the TCP = related problems. Some run idempotent connections to different = representations of the content and/or from different source while some = do even trickier things with multiple TCPs (but I don=92t wanna go into = the details here). In these apps, IW is a secondary issue. I am not saying it would not = help but there are bigger problems than a conservative IW here. > (Online Gaming with their proprietary protocols comes to mind. But I > believe many games use UDP). Indeed. =20 > Also, there already exists another protocol, that can deliver objects = to > the receiver, even if some earlier in-sequence data is missing (and > blocks the delivery of an earlier object): SCTP. Sure but HTTP is not using SCTP today. Should we look into it? =20 > Anyway, TCP still has a little bit of room to improve error recovery > latency. Ie. using commonly used extensions in a more synergistic way > can allow loss recovery in ~1RTT under many more circumstances than > today. Improving dupthresh and RTTM algorithms would also reduce the > fraction of RTO loss recovery. Could not agree more but there are already a lot of these things in the = newer TCP stacks (like win 7) that have improved a lot over earlier = versions.=20 BTW, I think you probably got my question below wrong. I suggested maybe = HTTP itself needs fixing or maybe using something besides TCP for HTTP = will provide better benefits. =20 > See also: > S. Rewaskar, J. Kaur, and F.D. Smith, "A Performance Study of Loss > Detection/Recovery in Real-world TCP Implementations" > , in Proceedings = of > the IEEE International Conference on Network Protocols (ICNP'07), > Beijing, China, Oct 2007. Thanks for the pointer. -acbegen =20 > Richard Scheffenegger >=20 >=20 >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Samstag, 27. November 2010 21:34 > > To: Mike Belshe; tcpm@ietf.org > > Subject: Re: [tcpm] A Challenge to TCPM > > > > I agree with some of the claims you are making below, and I > > don't agree with some. I just wanna point out one thing, > > though. You are largely dismissing the #1 reason why > > applications are often using more than 1 TCP connection. It > > is not often about the tput. It is often (more than often > > actually) about the delay (among a few other reasons), which > > is critical for short-lived transactions. > > > > You can increase the IW to 100 for all I care but TCP will > > still have to leave with the HOL blocking issue. IETF can > > make a recommendation on IW but I have serious doubts about > > TCP vendors quickly adopting as you suggest. As for the > > number of TCP connections in parallel, that is not easy to > > place a policy anyway. > > > > Maybe, trying to fix TCP to make HTTP is not the best strategy here. > > > > -acbegen > > > > > -----Original Message----- > > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] > > On Behalf > > > Of Mike Belshe > > > Sent: Friday, November 26, 2010 1:11 PM > > > To: tcpm@ietf.org > > > Subject: [tcpm] A Challenge to TCPM > > > > > > Hi, > > > > > > I thought I'd add a slightly different perspective to the > > discussion about initial cwnd. I'm a developer on Chrome & SPDY. > > > > > > With SPDY, we want to build an application protocol which > > is efficient > > > on the transport, good for the network, and faster than HTTP. But > > > right now, TCP is holding us back because we're trying to > > accomplish > > > with one connection what HTTP does with > > > 10+ connections. > > > > > > Note: I don't want to make this thread about SPDY. I hope the > > > members of this list agree that the goals of SPDY are good > > and will help make TCP a friendly transport for an > > application protocol like SPDY. > > > > > > Background > > > Unrelated to TCP, HTTP is not very efficient. This has been = widely > > > documented and observed for some time. We can easily demonstrate = a > > > more efficient protocol, which transfers 25-35% fewer > > packets than HTTP and reduces bytes transferred by 10-15%. > > Hopefully everyone agrees those are good things for the network. > > > > > > Unfortunately, any TCP-based protocol which uses a single > > connection > > > is at a latency-handicap compared to any protocol that uses > > multiple > > > connections. This is due to IW. Further, because > > bandwidth increases have outpaced RTT decreases, bandwidth is > > relatively cheap. So, being efficient on your bandwidth is > > less critical than being efficient on your round-trips. > > > > > > To visualize the effects, please see the attached graph. (Or = click > > > here > > > > = sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initial_cwnd_ > > > on_plt(1).png?attachauth=3DANoY7cpm-y5NA- > > > zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9- > > > > > = QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3Cz > > > KbzsxnGKlQaectqG8a7cjg5vgU1Gj4c > > > > > = FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFP > > > QkAmEI2FvRbq6IBg1aI%3D&attredirect > > > s=3D0> ) In these tests, I loaded a replica of the facebook = landing > > > page through two protocols - one using a single connection in a > > > semi-efficient manner (an early version of spdy) and > > another using 6 > > > connections (http). I used a high-bandwidth network with > > either 100ms or 200ms of RTT, and then I varied IW from 2pkts > > all the way to 128pkts. I chose this network configuration > > to specifically isolate the effects of high-RTT and IW. As > > you can see, at low IW, the single-connection protocol > > > fares poorly compared to the multi-connection protocol. > > For another writeup on the problem, see > > > > > = http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.p > > > df > > > > > > Today, the fastest way to deliver content is to simply > > side-step cwnd by use of multiple connections. > > > > > > > > > The Problem > > > With SPDY (or whatever protocol comes next), we can > > definitely reduce > > > the number of connections out of the browser by *at > > > least* a factor of 6. With unfolding of the subdomain tricks that > > > websites have been doing, we can reduce it by a factor of 10. = This > > > has nothing to do with TCP, except I hope that folks on > > this list appreciate that this goodness: fewer connections - > > fewer packets - and fewer bytes. > > > > > > The only trouble is that if we abide to the RFCs, fewer > > connections + > > > fewer packets + fewer bytes equates to slower web pages. > > > > > > But I'm not asking that we increase IW by a factor of 10; > > because it > > > grows exponentially, if we can increase it to somewhere in > > the ~16 range, it's good enough. > > > > > > > > > The Conundrum > > > More perplexing is that whenever we talk about increasing > > IW, we tend > > > to think of the static throttle that we have today. If we > > increase a > > > static throttle, it affects everything. So protocols that > > are already bursting 20-30x more packets than they should (by > > way of many connections) will burst even more. > > > > > > This makes some people want to do nothing... > > > > > > At the same time, we also know that cwnd has already been > > increased on the net at large. This started with use of multiple > > > connections, multiplied with the use of multiple subdomains, and = is > > > now changing by major sites simply increasing or ignoring cwnd > > > altogther. With so many sites systematically working > > around cwnd, we know that the current limits can be > > increased. We just don't know how much. > > > > > > > > > The Solution? > > > Is the obvious solution to stop using a static value? It > > doesn't seem like we're in a one-size-fits-all for IW. > > > > > > The IW could either be defined to be protocol-specific, or dynamic > > > based on number of TCP flows between the same two > > endpoints. Both of > > > these approaches would offer the benefit of a controlled, = increased > > > cwnd to reflect the changes in the net over the last 2 > > decades but also not completely unthrottle protocols that are > > already living on the edge of not having throttles. > > > > > > Finally, if a dynamic throttle is too much to decide upon, at = least > > > updating the static value seems appropriate. Jerrry and > > Nandita have > > > provided good data for a general-purpose increase to 10. > > If inefficient protocols are allowed to go that high, maybe > > more efficient protocols could be allowed to go higher (with > > data, of course). > > > > > > > > > Reality Check > > > Finally, regardless of this debate in the IETF, what is > > actually going to happen? > > > > > > a) IETF does not increase the limit (or continues to wait): > > > As time goes on, more and more evidence emerges to demonstrate = that > > > the current cwnd limits are unnecessarily conservative. > > More evidence > > > also emerges that increasing cwnd makes your site faster. > > More sites > > > start experimenting with their own values of cwnd. Without > > a blessed > > > recommendation from the IETF, sites choose whatever values > > they want. > > > Ben Strong offered a writeup today which demonstrates this > > is already > > > happening > > and-microsoft-cheat-on-slow.html> . > > > > > > b) IETF increases the limit: > > > With data and a specific recommendation, TCP vendors can > > quickly move > > > to the new recommendations, making their products more > > competitive in > > > the marketplace, and better for users. Pressure is alleviated = from > > > existing sites to go renegade, and instead they can rest on the > > > specific findings from this group. With a modern recommendation = in > > > hand, all of us can credibly go after any sites which do > > choose to use dangerously high cwnd values. Finally, having > > an officially increased IW is an enabler for a future of more > > efficient application level protocols, which are currently at > > a disadvantage to their less-efficient counterparts. > > > > > > > > > > > > > > > Now, which of these two options carries more risk of internet > > > collapse? Vendors implementing whatever-the-heck-their- > > > rookie-system-administrator decided to configure? Or an > > official, controlled and intelligent recommendation from this group? > > > > > > > > > Thanks to everyone on this list for their hard work over > > the years - > > > although my email is somewhat critical, be aware that I > > have immense > > > gratitude and respect for the veterans of this list that > > have been keeping the net flowing for so long with such great = success. > > > Mike > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > From touch@isi.edu Sun Nov 28 06:21:47 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3CA13A6B93 for ; Sun, 28 Nov 2010 06:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCOTnR4dCe8D for ; Sun, 28 Nov 2010 06:21:47 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 179213A6B78 for ; Sun, 28 Nov 2010 06:21:47 -0800 (PST) Received: from [155.68.181.47] ([155.68.181.47]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oASEMFfV019764 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 28 Nov 2010 06:22:24 -0800 (PST) Message-ID: <4CF26596.7010500@isi.edu> Date: Sun, 28 Nov 2010 06:22:14 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jerry Chu References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@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, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 14:21:48 -0000 Jerry, In short: a) the receive window is an indication of the receiver's ability to reorder out-of-order packets; it limits what is sent primarily to avoid useless transmissions that the receiver will drop, not as a congestion control mechanism yes, I find it odd that you are injecting control of the receive window to correct for IW issues in your draft 2) NO AMOUNT of in-connection adjustment of CWND has any effect on the impact of a poor choice of IW consider that if this were not true, then you would not need to propose a new IW value; just as you do not want to wait for the connection to converge, I am concerned about the network impact until that convergence I have made the second point repeatedly. It would be useful to know if your continued misdirection of the issue is because don't agree with it, or some other reason. Joe From jakob.heitz@ericsson.com Sun Nov 28 11:19:52 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628D93A6BDA for ; Sun, 28 Nov 2010 11:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4oMVo7h8bde for ; Sun, 28 Nov 2010 11:19:50 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 827BD3A6BD5 for ; Sun, 28 Nov 2010 11:19:49 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oASJKq3P029763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Nov 2010 13:20:55 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.213]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sun, 28 Nov 2010 14:20:51 -0500 From: Jakob Heitz To: "Scheffenegger, Richard" , "Ali C. Begen (abegen)" , Mike Belshe , "tcpm@ietf.org" Date: Sun, 28 Nov 2010 14:20:44 -0500 Thread-Topic: [tcpm] A Challenge to TCPM Thread-Index: AcuNlUG/mOB0699nQE6fHFKA+8QeOgA3CztAAB9I3tAAEIE0YA== Message-ID: <7309FCBCAE981B43ABBE69B31C8D213909B736A348@EUSAACMS0701.eamcs.ericsson.se> References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0BA9624C@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0BA9624C@LDCMVEXC1-PRD.hq.netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 19:19:53 -0000 AFAIR, all SCTP streams in one connection share the same receive window. If one stream fills the window, it blocks all others. SCTP streams were not designed to avoid HOL blocking. -- Jakob Heitz. =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Scheffenegger, Richard > Sent: Sunday, November 28, 2010 3:40 AM > To: Ali C. Begen (abegen); Mike Belshe; tcpm@ietf.org > Subject: Re: [tcpm] A Challenge to TCPM >=20 > Also, there already exists another protocol, that can deliver=20 > objects to > the receiver, even if some earlier in-sequence data is missing (and > blocks the delivery of an earlier object): SCTP. From Xiangsong.Cui@huawei.com Sun Nov 28 18:32:44 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A64E3A6BA3; Sun, 28 Nov 2010 18:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=2.117, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUMpbUBoohjI; Sun, 28 Nov 2010 18:32:39 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4670B3A6BA6; Sun, 28 Nov 2010 18:32:38 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCM00KKRKG0DA@szxga04-in.huawei.com>; Mon, 29 Nov 2010 10:33:36 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCM002HWKFZRH@szxga04-in.huawei.com>; Mon, 29 Nov 2010 10:33:36 +0800 (CST) Date: Mon, 29 Nov 2010 10:33:36 +0800 From: Xiangsong Cui In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540DC92F71@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , "'Scheffenegger, Richard'" , 'Mike Belshe' , tcpm@ietf.org Message-id: <003801cb8f6d$d351ed00$79f5c700$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcuNlUG/mOB0699nQE6fHFKA+8QeOgA3CztAAB9I3tAAAwxuUAAcQVdw References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0BA9624C@LDCMVEXC1-PRD.hq.netapp.com> <04CAD96D4C5A3D48B1919248A8FE0D540DC92F71@xmb-sjc-215.amer.cisco.com> Cc: tae@ietf.org Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 02:32:44 -0000 > Sure but HTTP is not using SCTP today. Should we look into it? Sorry for digging this topic in tcpm list, but I think the guys interested in this topic also cover tcpm. I think this is an interesting item. In my remember, a Bar-BoF (or BoF) named "Negotiation BoF" was ever mentioned at IETF76 (denied by AD at that time). There is a draft, http://tools.ietf.org/html/draft-wing-http-new-tech-00, and Dan presented this topic at IETF79, http://www.ietf.org/proceedings/79/slides/tsvwg-9.pptx, Who can tell me more information about this? I missed the BoF at IETF76. Thanks and regards, Xiangsong From mike@belshe.com Sun Nov 28 22:45:34 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2CD73A6C08 for ; Sun, 28 Nov 2010 22:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.228 X-Spam-Level: * X-Spam-Status: No, score=1.228 tagged_above=-999 required=5 tests=[AWL=1.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=0.001, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFQz4Sr+8DzY for ; Sun, 28 Nov 2010 22:45:31 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 647363A6C09 for ; Sun, 28 Nov 2010 22:45:31 -0800 (PST) Received: by qwg5 with SMTP id 5so2958573qwg.31 for ; Sun, 28 Nov 2010 22:46:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.238.16 with SMTP id kq16mr4491868qcb.134.1291013199063; Sun, 28 Nov 2010 22:46:39 -0800 (PST) Received: by 10.229.235.3 with HTTP; Sun, 28 Nov 2010 22:46:39 -0800 (PST) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> Date: Sun, 28 Nov 2010 22:46:39 -0800 Message-ID: From: Mike Belshe To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=0016e64cbf6c216b1004962b6f02 Cc: tcpm@ietf.org Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 06:45:34 -0000 --0016e64cbf6c216b1004962b6f02 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 27, 2010 at 12:34 PM, Ali C. Begen (abegen) wrote: > I agree with some of the claims you are making below, and I don't agree > with some. I just wanna point out one thing, though. You are largely > dismissing the #1 reason why applications are often using more than 1 TCP > connection. It is not often about the tput. It is often (more than often > actually) about the delay (among a few other reasons), which is critical for > short-lived transactions. > Actually, that was my whole point. The only way to get the latency down is to avoid cwnd, and multiple connections are an easy trick to accomplish just that. > > You can increase the IW to 100 for all I care but TCP will still have to > leave with the HOL blocking issue. IETF can make a recommendation on IW but > I have serious doubts about TCP vendors quickly adopting as you suggest. As > for the number of TCP connections in parallel, that is not easy to place a > policy anyway. > That is a separate issue and generally less severe than the cwnd issue. I could provide more color about SCTP, HOL and other issues, but I really don't want to derail this thread to be about anything other than TCP's initial cwnd setting. We need to decide if we think an application protocol should be able to be both a low-latency protocol, and based on TCP. If you think that should be possible, then we seriously need to consider changing IW. The reasons not to change it, would be if you thought it would kill the net - but, I there is no evidence of that, especially if we consider which protocols get which limits. > > Maybe, trying to fix TCP to make HTTP is not the best strategy here. > Are you saying HTTP should move to a new transport? That seems like a shame. Mike > > -acbegen > > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Mike Belshe > > Sent: Friday, November 26, 2010 1:11 PM > > To: tcpm@ietf.org > > Subject: [tcpm] A Challenge to TCPM > > > > Hi, > > > > I thought I'd add a slightly different perspective to the discussion > about initial cwnd. I'm a developer on Chrome & SPDY. > > > > With SPDY, we want to build an application protocol which is efficient on > the transport, good for the network, and faster than > > HTTP. But right now, TCP is holding us back because we're trying to > accomplish with one connection what HTTP does with > > 10+ connections. > > > > Note: I don't want to make this thread about SPDY. I hope the members > of this list agree that the goals of SPDY are good > > and will help make TCP a friendly transport for an application protocol > like SPDY. > > > > Background > > Unrelated to TCP, HTTP is not very efficient. This has been widely > documented and observed for some time. We can easily > > demonstrate a more efficient protocol, which transfers 25-35% fewer > packets than HTTP and reduces bytes transferred by > > 10-15%. Hopefully everyone agrees those are good things for the network. > > > > Unfortunately, any TCP-based protocol which uses a single connection is > at a latency-handicap compared to any protocol that > > uses multiple connections. This is due to IW. Further, because > bandwidth increases have outpaced RTT decreases, > > bandwidth is relatively cheap. So, being efficient on your bandwidth is > less critical than being efficient on your round-trips. > > > > To visualize the effects, please see the attached graph. (Or click here > > > sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initial_cwnd_on_plt(1).png?attachauth=ANoY7cpm-y5NA- > > zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9- > > > QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3CzKbzsxnGKlQaectqG8a7cjg5vgU1Gj4c > > > FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFPQkAmEI2FvRbq6IBg1aI%3D&attredirect > > s=0> ) In these tests, I loaded a replica of the facebook landing page > through two protocols - one using a single connection in > > a semi-efficient manner (an early version of spdy) and another using 6 > connections (http). I used a high-bandwidth network > > with either 100ms or 200ms of RTT, and then I varied IW from 2pkts all > the way to 128pkts. I chose this network > > configuration to specifically isolate the effects of high-RTT and IW. As > you can see, at low IW, the single-connection protocol > > fares poorly compared to the multi-connection protocol. For another > writeup on the problem, see > > http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf > > > > Today, the fastest way to deliver content is to simply side-step cwnd by > use of multiple connections. > > > > > > The Problem > > With SPDY (or whatever protocol comes next), we can definitely reduce the > number of connections out of the browser by *at > > least* a factor of 6. With unfolding of the subdomain tricks that > websites have been doing, we can reduce it by a factor of > > 10. This has nothing to do with TCP, except I hope that folks on this > list appreciate that this goodness: fewer connections - > > fewer packets - and fewer bytes. > > > > The only trouble is that if we abide to the RFCs, fewer connections + > fewer packets + fewer bytes equates to slower web > > pages. > > > > But I'm not asking that we increase IW by a factor of 10; because it > grows exponentially, if we can increase it to somewhere > > in the ~16 range, it's good enough. > > > > > > The Conundrum > > More perplexing is that whenever we talk about increasing IW, we tend to > think of the static throttle that we have today. If > > we increase a static throttle, it affects everything. So protocols that > are already bursting 20-30x more packets than they > > should (by way of many connections) will burst even more. > > > > This makes some people want to do nothing... > > > > At the same time, we also know that cwnd has already been increased on > the net at large. This started with use of multiple > > connections, multiplied with the use of multiple subdomains, and is now > changing by major sites simply increasing or > > ignoring cwnd altogther. With so many sites systematically working > around cwnd, we know that the current limits can be > > increased. We just don't know how much. > > > > > > The Solution? > > Is the obvious solution to stop using a static value? It doesn't seem > like we're in a one-size-fits-all for IW. > > > > The IW could either be defined to be protocol-specific, or dynamic based > on number of TCP flows between the same two > > endpoints. Both of these approaches would offer the benefit of a > controlled, increased cwnd to reflect the changes in the net > > over the last 2 decades but also not completely unthrottle protocols that > are already living on the edge of not having > > throttles. > > > > Finally, if a dynamic throttle is too much to decide upon, at least > updating the static value seems appropriate. Jerrry and > > Nandita have provided good data for a general-purpose increase to 10. If > inefficient protocols are allowed to go that high, > > maybe more efficient protocols could be allowed to go higher (with data, > of course). > > > > > > Reality Check > > Finally, regardless of this debate in the IETF, what is actually going to > happen? > > > > a) IETF does not increase the limit (or continues to wait): > > As time goes on, more and more evidence emerges to demonstrate that the > current cwnd limits are unnecessarily > > conservative. More evidence also emerges that increasing cwnd makes your > site faster. More sites start experimenting with > > their own values of cwnd. Without a blessed recommendation from the > IETF, sites choose whatever values they want. Ben > > Strong offered a writeup today which demonstrates this is already > happening > and-microsoft-cheat-on-slow.html> . > > > > b) IETF increases the limit: > > With data and a specific recommendation, TCP vendors can quickly move to > the new recommendations, making their > > products more competitive in the marketplace, and better for users. > Pressure is alleviated from existing sites to go > > renegade, and instead they can rest on the specific findings from this > group. With a modern recommendation in hand, all of > > us can credibly go after any sites which do choose to use dangerously > high cwnd values. Finally, having an officially > > increased IW is an enabler for a future of more efficient application > level protocols, which are currently at a disadvantage to > > their less-efficient counterparts. > > > > > > > > > > Now, which of these two options carries more risk of internet collapse? > Vendors implementing whatever-the-heck-their- > > rookie-system-administrator decided to configure? Or an official, > controlled and intelligent recommendation from this > > group? > > > > > > Thanks to everyone on this list for their hard work over the years - > although my email is somewhat critical, be aware that I > > have immense gratitude and respect for the veterans of this list that > have been keeping the net flowing for so long with such > > great success. > > Mike > --0016e64cbf6c216b1004962b6f02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Nov 27, 2010 at 12:34 PM, Ali C. Begen (= abegen) <abegen@ci= sco.com> wrote:
I agree with some of the claims you are making below, and I don't agree= with some. I just wanna point out one thing, though. You are largely dismi= ssing the #1 reason why applications are often using more than 1 TCP connec= tion. It is not often about the tput. It is often (more than often actually= ) about the delay (among a few other reasons), which is critical for short-= lived transactions.

Actually, that was my whole point. =A0The = only way to get the latency down is to avoid cwnd, and multiple connections= are an easy trick to accomplish just that.
=A0

You can increase the IW to 100 for all I care but TCP will still have to le= ave with the HOL blocking issue. IETF can make a recommendation on IW but I= have serious doubts about TCP vendors quickly adopting as you suggest. As = for the number of TCP connections in parallel, that is not easy to place a = policy anyway.

That is a separate issue and generally les= s severe than the cwnd issue. =A0I could provide more color about SCTP, HOL= and other issues, but=A0I really don't want to derail this thread to b= e about anything other than TCP's initial cwnd setting. =A0

We need to decide if we think an application protocol s= hould be able to be both a low-latency protocol, and based on TCP. =A0If yo= u think that should be possible, then we seriously need to consider changin= g IW. =A0The reasons not to change it, would be if you thought it would kil= l the net - but, I there is no evidence of that, especially if we consider = which protocols get which limits.
=A0

Maybe, trying to fix TCP to make HTTP is not the best strategy here.

Are you saying HTTP should move to a new tran= sport? =A0That seems like a shame.

Mike

=A0

-acbegen

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mike Belshe
> Sent: Friday, November 26, 2010 1:11 PM
> To: tcpm@ietf.org
> Subject: [tcpm] A Challenge to TCPM
>
> Hi,
>
> I thought I'd add a slightly different perspective to the discussi= on about initial cwnd. =A0I'm a developer on Chrome & SPDY.
>
> With SPDY, we want to build an application protocol which is efficient= on the transport, good for the network, and faster than
> HTTP. =A0But right now, TCP is holding us back because we're tryin= g to accomplish with one connection what HTTP does with
> 10+ connections.
>
> Note: =A0I don't want to make this thread about SPDY. =A0I hope th= e members of this list agree that the goals of SPDY are good
> and will help make TCP a friendly transport for an application protoco= l like SPDY.
>
> Background
> Unrelated to TCP, HTTP is not very efficient. =A0This has been widely = documented and observed for some time. =A0We can easily
> demonstrate a more efficient protocol, which transfers 25-35% fewer pa= ckets than HTTP and reduces bytes transferred by
> 10-15%. =A0Hopefully everyone agrees those are good things for the net= work.
>
> Unfortunately, any TCP-based protocol which uses a single connection i= s at a latency-handicap compared to any protocol that
> uses multiple connections. =A0This is due to IW. =A0Further, because b= andwidth increases have outpaced RTT decreases,
> bandwidth is relatively cheap. =A0So, being efficient on your bandwidt= h is less critical than being efficient on your round-trips.
>
> To visualize the effects, please see the attached graph. =A0(Or = click here <http://6541078575799853287-a-chromium-org-s-
> sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initial_cwnd_o= n_plt(1).png?attachauth=3DANoY7cpm-y5NA-
> zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9-
> QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3Cz= KbzsxnGKlQaectqG8a7cjg5vgU1Gj4c
> FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFP= QkAmEI2FvRbq6IBg1aI%3D&attredirect
> s=3D0> ) =A0In these tests, I loaded a replica of the facebook land= ing page through two protocols - one using a single connection in
> a semi-efficient manner (an early ve= rsion of spdy) and another using 6 connections (http). =A0I used a high-ban= dwidth network
> with either 100ms or 200ms of RTT, and then I varied IW from 2pkts all= the way to 128pkts. =A0I chose this network
> configuration to specifically isolate the effects of high-RTT and IW. = =A0As you can see, at low IW, the single-connection protocol
> fares poorly compared to the multi-connection protocol. =A0 For anothe= r writeup on the problem, see
> http://dev.chromium.org/spdy/An_Argument_F= or_Changing_TCP_Slow_Start.pdf
>
> Today, the fastest way to deliver content is to simply side-step cwnd = by use of multiple connections.
>
>
> The Problem
> With SPDY (or whatever protocol comes next), we can definitely reduce = the number of connections out of the browser by *at
> least* a factor of 6. =A0With unfolding of the subdomain tricks that w= ebsites have been doing, we can reduce it by a factor of
> 10. =A0This has nothing to do with TCP, except I hope that folks on th= is list appreciate that this goodness: =A0fewer connections -
> fewer packets - and fewer bytes.
>
> The only trouble is that if we abide to the RFCs, fewer connections + = fewer packets + fewer bytes equates to slower web
> pages.
>
> But I'm not asking that we increase IW by a factor of 10; because = it grows exponentially, if we can increase it to somewhere
> in the ~16 range, it's good enough.
>
>
> The Conundrum
> More perplexing is that whenever we talk about increasing IW, we tend = to think of the static throttle that we have today. =A0If
> we increase a static throttle, it affects everything. =A0So protocols = that are already bursting 20-30x more packets than they
> should (by way of many connections) will burst even more.
>
> This makes some people want to do nothing...
>
> At the same time, we also know that cwnd has already been increased on= the net at large. =A0 This started with use of multiple
> connections, multiplied with the use of multiple subdomains, and is no= w changing by major sites simply increasing or
> ignoring cwnd altogther. =A0With so many sites systematically working = around cwnd, we know that the current limits can be
> increased. =A0We just don't know how much.
>
>
> The Solution?
> Is the obvious solution to stop using a static value? =A0It doesn'= t seem like we're in a one-size-fits-all for IW.
>
> The IW could either be defined to be protocol-specific, or dynamic bas= ed on number of TCP flows between the same two
> endpoints. =A0Both of these approaches would offer the benefit of a co= ntrolled, increased cwnd to reflect the changes in the net
> over the last 2 decades but also not completely unthrottle protocols t= hat are already living on the edge of not having
> throttles.
>
> Finally, if a dynamic throttle is too much to decide upon, at least up= dating the static value seems appropriate. =A0Jerrry and
> Nandita have provided good data for a general-purpose increase to 10. = =A0If inefficient protocols are allowed to go that high,
> maybe more efficient protocols could be allowed to go higher (with dat= a, of course).
>
>
> Reality Check
> Finally, regardless of this debate in the IETF, what is actually going= to happen?
>
> a) IETF does not increase the limit (or continues to wait):
> As time goes on, more and more evidence emerges to demonstrate that th= e current cwnd limits are unnecessarily
> conservative. =A0More evidence also emerges that increasing cwnd makes= your site faster. =A0More sites start experimenting with
> their own values of cwnd. =A0Without a blessed recommendation from the= IETF, sites choose whatever values they want. Ben
> Strong offered a writeup today which demonstrates this is = already happening <http://blog.benstrong.com/2010/11/google-
> and-microsoft-cheat-on-slow.html> .
>
> b) IETF increases the limit:
> With data and a specific recommendation, TCP vendors can quickly move = to the new recommendations, making their
> products more competitive in the marketplace, and better for users. = =A0Pressure is alleviated from existing sites to go
> renegade, and instead they can rest on the specific findings from this= group. =A0With a modern recommendation in hand, all of
> us can credibly go after any sites which do choose to use dangerously = high cwnd values. =A0Finally, having an officially
> increased IW is an enabler for a future of more efficient application = level protocols, which are currently at a disadvantage to
> their less-efficient counterparts.
>
>
>
>
> Now, which of these two options carries more risk of internet collapse= ? =A0Vendors implementing whatever-the-heck-their-
> rookie-system-administrator decided to configure? =A0Or an official, c= ontrolled and intelligent recommendation from this
> group?
>
>
> Thanks to everyone on this list for their hard work over the years - a= lthough my email is somewhat critical, be aware that I
> have immense gratitude and respect for the veterans of this list that = have been keeping the net flowing for so long with such
> great success.
> Mike

--0016e64cbf6c216b1004962b6f02-- From mike@belshe.com Sun Nov 28 22:50:23 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD003A6BF9 for ; Sun, 28 Nov 2010 22:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=1.602, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar8WJiy+yVFk for ; Sun, 28 Nov 2010 22:50:22 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id C93B03A6BFE for ; Sun, 28 Nov 2010 22:50:21 -0800 (PST) Received: by qyk34 with SMTP id 34so8866502qyk.10 for ; Sun, 28 Nov 2010 22:51:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.81.20 with SMTP id v20mr4524871qck.210.1291013490557; Sun, 28 Nov 2010 22:51:30 -0800 (PST) Received: by 10.229.235.3 with HTTP; Sun, 28 Nov 2010 22:51:30 -0800 (PST) In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213909B736A348@EUSAACMS0701.eamcs.ericsson.se> References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0BA9624C@LDCMVEXC1-PRD.hq.netapp.com> <7309FCBCAE981B43ABBE69B31C8D213909B736A348@EUSAACMS0701.eamcs.ericsson.se> Date: Sun, 28 Nov 2010 22:51:30 -0800 Message-ID: From: Mike Belshe To: Jakob Heitz Content-Type: multipart/alternative; boundary=00163646d4fc81453504962b80c1 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 06:50:23 -0000 --00163646d4fc81453504962b80c1 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 28, 2010 at 11:20 AM, Jakob Heitz wrote: > AFAIR, all SCTP streams in one connection share the same > receive window. If one stream fills the window, it blocks > all others. > > SCTP streams were not designed to avoid HOL blocking. > Again - HOL is a whole different set of issues, not directly related to initial cwnd. Let's take that to a different thread. (And yes, SCTP *was* designed to avoid HOL issues - see packet loss recovery). But congestion control, of course, is intentional throttling of the protocol, regardless of what it does with streams. It's intentionally blocking for the safety of the net. SCTP uses the same static limits that TCP uses. So if we can't solve cwnd for TCP, SCTP won't be viable either. Mike > > -- > Jakob Heitz. > > > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > > Behalf Of Scheffenegger, Richard > > Sent: Sunday, November 28, 2010 3:40 AM > > To: Ali C. Begen (abegen); Mike Belshe; tcpm@ietf.org > > Subject: Re: [tcpm] A Challenge to TCPM > > > > Also, there already exists another protocol, that can deliver > > objects to > > the receiver, even if some earlier in-sequence data is missing (and > > blocks the delivery of an earlier object): SCTP. > --00163646d4fc81453504962b80c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Nov 28, 2010 at 11:20 AM, Jakob Heitz <jakob.heitz= @ericsson.com> wrote:
AFAIR, all SCTP streams in one connection share the same
receive window. If one stream fills the window, it blocks
all others.

SCTP streams were not designed to avoid HOL blocking.
=
Again - HOL is a whole different set of issues, not directly= related to initial cwnd. =A0Let's take that to a different thread. =A0= (And yes, SCTP *was* designed to avoid HOL issues - see packet loss recover= y).

But congestion control, of course, is intentional throt= tling of the protocol, regardless of what it does with streams. =A0It's= intentionally blocking for the safety of the net. =A0SCTP uses the same st= atic limits that TCP uses. =A0So if we can't solve cwnd for TCP, SCTP w= on't be viable either.

Mike
=A0

--
Jakob Heitz.


> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On
> Behalf Of Scheffenegger, Richard
> Sent: Sunday, November 28, 2010 3:40 AM
> To: Ali C. Begen (abegen); Mike Belshe; tcpm@ietf.org
> Subject: Re: [tcpm] A Challenge to TCPM
>
> Also, there already exists ano= ther protocol, that can deliver
> objects to
> the receiver, even if some earlier in-sequence data is missing (and > blocks the delivery of an earlier object): SCTP.

--00163646d4fc81453504962b80c1-- From sunseawq@huawei.com Sun Nov 28 23:33:03 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAD83A6806 for ; Sun, 28 Nov 2010 23:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.054 X-Spam-Level: X-Spam-Status: No, score=0.054 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUcGIEvtbJID for ; Sun, 28 Nov 2010 23:33:01 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7E9AA3A69CD for ; Sun, 28 Nov 2010 23:33:00 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCM00JMEY8E71@szxga04-in.huawei.com> for tcpm@ietf.org; Mon, 29 Nov 2010 15:31:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCM007RZY8EYV@szxga04-in.huawei.com> for tcpm@ietf.org; Mon, 29 Nov 2010 15:31:26 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCM00KG4Y8DHP@szxml04-in.huawei.com> for tcpm@ietf.org; Mon, 29 Nov 2010 15:31:26 +0800 (CST) Date: Mon, 29 Nov 2010 15:31:25 +0800 From: Qin Wu To: Mike Belshe , "Ali C. Begen (abegen)" Message-id: <01fb01cb8f97$6e343520$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_FWfcBIrE4VLwOCmZIHXm9g)" X-Priority: 3 X-MSMail-priority: Normal References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 07:33:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_FWfcBIrE4VLwOCmZIHXm9g) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT ----- Original Message ----- From: Mike Belshe To: Ali C. Begen (abegen) Cc: tcpm@ietf.org Sent: Monday, November 29, 2010 2:46 PM Subject: Re: [tcpm] A Challenge to TCPM On Sat, Nov 27, 2010 at 12:34 PM, Ali C. Begen (abegen) wrote: I agree with some of the claims you are making below, and I don't agree with some. I just wanna point out one thing, though. You are largely dismissing the #1 reason why applications are often using more than 1 TCP connection. It is not often about the tput. It is often (more than often actually) about the delay (among a few other reasons), which is critical for short-lived transactions. Actually, that was my whole point. The only way to get the latency down is to avoid cwnd, and multiple connections are an easy trick to accomplish just that. [Qin]: I am suspecting the latency also lies on how TCP detect and recover from the loss or congestion control algorithm. Selecting appropriate design parameters for loss detection like minRTO, D rather than cwnd can effectively reduce potencital latency or connection duration. You can increase the IW to 100 for all I care but TCP will still have to leave with the HOL blocking issue. IETF can make a recommendation on IW but I have serious doubts about TCP vendors quickly adopting as you suggest. As for the number of TCP connections in parallel, that is not easy to place a policy anyway. That is a separate issue and generally less severe than the cwnd issue. I could provide more color about SCTP, HOL and other issues, but I really don't want to derail this thread to be about anything other than TCP's initial cwnd setting. We need to decide if we think an application protocol should be able to be both a low-latency protocol, and based on TCP. If you think that should be possible, then we seriously need to consider changing IW. The reasons not to change it, would be if you thought it would kill the net - but, I there is no evidence of that, especially if we consider which protocols get which limits. [Qin]: I am not sure changing IW can come up with one low-latency protocol which is based on TCP. I will assume IW changing is orthogonal to RTT or connection duration and will only affect throughput as Ali pointed out. Can you give some data on how IW affect RTT like graph you show in the previous email? Maybe, trying to fix TCP to make HTTP is not the best strategy here. Are you saying HTTP should move to a new transport? That seems like a shame. Mike -acbegen > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mike Belshe > Sent: Friday, November 26, 2010 1:11 PM > To: tcpm@ietf.org > Subject: [tcpm] A Challenge to TCPM > > Hi, > > I thought I'd add a slightly different perspective to the discussion about initial cwnd. I'm a developer on Chrome & SPDY. > > With SPDY, we want to build an application protocol which is efficient on the transport, good for the network, and faster than > HTTP. But right now, TCP is holding us back because we're trying to accomplish with one connection what HTTP does with > 10+ connections. > > Note: I don't want to make this thread about SPDY. I hope the members of this list agree that the goals of SPDY are good > and will help make TCP a friendly transport for an application protocol like SPDY. > > Background > Unrelated to TCP, HTTP is not very efficient. This has been widely documented and observed for some time. We can easily > demonstrate a more efficient protocol, which transfers 25-35% fewer packets than HTTP and reduces bytes transferred by > 10-15%. Hopefully everyone agrees those are good things for the network. > > Unfortunately, any TCP-based protocol which uses a single connection is at a latency-handicap compared to any protocol that > uses multiple connections. This is due to IW. Further, because bandwidth increases have outpaced RTT decreases, > bandwidth is relatively cheap. So, being efficient on your bandwidth is less critical than being efficient on your round-trips. > > To visualize the effects, please see the attached graph. (Or click here sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initial_cwnd_on_plt(1).png?attachauth=ANoY7cpm-y5NA- > zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9- > QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3CzKbzsxnGKlQaectqG8a7cjg5vgU1Gj4c > FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFPQkAmEI2FvRbq6IBg1aI%3D&attredirect > s=0> ) In these tests, I loaded a replica of the facebook landing page through two protocols - one using a single connection in > a semi-efficient manner (an early version of spdy) and another using 6 connections (http). I used a high-bandwidth network > with either 100ms or 200ms of RTT, and then I varied IW from 2pkts all the way to 128pkts. I chose this network > configuration to specifically isolate the effects of high-RTT and IW. As you can see, at low IW, the single-connection protocol > fares poorly compared to the multi-connection protocol. For another writeup on the problem, see > http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf > > Today, the fastest way to deliver content is to simply side-step cwnd by use of multiple connections. > > > The Problem > With SPDY (or whatever protocol comes next), we can definitely reduce the number of connections out of the browser by *at > least* a factor of 6. With unfolding of the subdomain tricks that websites have been doing, we can reduce it by a factor of > 10. This has nothing to do with TCP, except I hope that folks on this list appreciate that this goodness: fewer connections - > fewer packets - and fewer bytes. > > The only trouble is that if we abide to the RFCs, fewer connections + fewer packets + fewer bytes equates to slower web > pages. > > But I'm not asking that we increase IW by a factor of 10; because it grows exponentially, if we can increase it to somewhere > in the ~16 range, it's good enough. > > > The Conundrum > More perplexing is that whenever we talk about increasing IW, we tend to think of the static throttle that we have today. If > we increase a static throttle, it affects everything. So protocols that are already bursting 20-30x more packets than they > should (by way of many connections) will burst even more. > > This makes some people want to do nothing... > > At the same time, we also know that cwnd has already been increased on the net at large. This started with use of multiple > connections, multiplied with the use of multiple subdomains, and is now changing by major sites simply increasing or > ignoring cwnd altogther. With so many sites systematically working around cwnd, we know that the current limits can be > increased. We just don't know how much. > > > The Solution? > Is the obvious solution to stop using a static value? It doesn't seem like we're in a one-size-fits-all for IW. > > The IW could either be defined to be protocol-specific, or dynamic based on number of TCP flows between the same two > endpoints. Both of these approaches would offer the benefit of a controlled, increased cwnd to reflect the changes in the net > over the last 2 decades but also not completely unthrottle protocols that are already living on the edge of not having > throttles. > > Finally, if a dynamic throttle is too much to decide upon, at least updating the static value seems appropriate. Jerrry and > Nandita have provided good data for a general-purpose increase to 10. If inefficient protocols are allowed to go that high, > maybe more efficient protocols could be allowed to go higher (with data, of course). > > > Reality Check > Finally, regardless of this debate in the IETF, what is actually going to happen? > > a) IETF does not increase the limit (or continues to wait): > As time goes on, more and more evidence emerges to demonstrate that the current cwnd limits are unnecessarily > conservative. More evidence also emerges that increasing cwnd makes your site faster. More sites start experimenting with > their own values of cwnd. Without a blessed recommendation from the IETF, sites choose whatever values they want. Ben > Strong offered a writeup today which demonstrates this is already happening and-microsoft-cheat-on-slow.html> . > > b) IETF increases the limit: > With data and a specific recommendation, TCP vendors can quickly move to the new recommendations, making their > products more competitive in the marketplace, and better for users. Pressure is alleviated from existing sites to go > renegade, and instead they can rest on the specific findings from this group. With a modern recommendation in hand, all of > us can credibly go after any sites which do choose to use dangerously high cwnd values. Finally, having an officially > increased IW is an enabler for a future of more efficient application level protocols, which are currently at a disadvantage to > their less-efficient counterparts. > > > > > Now, which of these two options carries more risk of internet collapse? Vendors implementing whatever-the-heck-their- > rookie-system-administrator decided to configure? Or an official, controlled and intelligent recommendation from this > group? > > > Thanks to everyone on this list for their hard work over the years - although my email is somewhat critical, be aware that I > have immense gratitude and respect for the veterans of this list that have been keeping the net flowing for so long with such > great success. > Mike ------------------------------------------------------------------------------ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --Boundary_(ID_FWfcBIrE4VLwOCmZIHXm9g) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
----- Original Message -----
Sent: Monday, November 29, 2010 2:46 PM
Subject: Re: [tcpm] A Challenge to TCPM

On Sat, Nov 27, 2010 at 12:34 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:
I agree with some of the claims you are making below, and I don't agree with some. I just wanna point out one thing, though. You are largely dismissing the #1 reason why applications are often using more than 1 TCP connection. It is not often about the tput. It is often (more than often actually) about the delay (among a few other reasons), which is critical for short-lived transactions.

Actually, that was my whole point.  The only way to get the latency down is to avoid cwnd, and multiple connections are an easy trick to accomplish just that.
 
[Qin]: I am suspecting the latency also lies on how TCP detect and recover from the loss or congestion control algorithm. Selecting appropriate design parameters for loss detection like minRTO, D rather than cwnd can effectively
         reduce potencital latency or connection duration.
 

You can increase the IW to 100 for all I care but TCP will still have to leave with the HOL blocking issue. IETF can make a recommendation on IW but I have serious doubts about TCP vendors quickly adopting as you suggest. As for the number of TCP connections in parallel, that is not easy to place a policy anyway.

That is a separate issue and generally less severe than the cwnd issue.  I could provide more color about SCTP, HOL and other issues, but I really don't want to derail this thread to be about anything other than TCP's initial cwnd setting.  

We need to decide if we think an application protocol should be able to be both a low-latency protocol, and based on TCP.  If you think that should be possible, then we seriously need to consider changing IW.  The reasons not to change it, would be if you thought it would kill the net - but, I there is no evidence of that, especially if we consider which protocols get which limits.
 
[Qin]: I am not sure changing IW can come up with one low-latency protocol which is based on TCP. I will assume IW changing is orthogonal to RTT or connection duration and will only affect throughput as Ali pointed out. Can you give some data on how IW affect RTT like graph you show in the previous email?
 

Maybe, trying to fix TCP to make HTTP is not the best strategy here.

Are you saying HTTP should move to a new transport?  That seems like a shame.

Mike

 

-acbegen

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mike Belshe
> Sent: Friday, November 26, 2010 1:11 PM
> To: tcpm@ietf.org
> Subject: [tcpm] A Challenge to TCPM
>
> Hi,
>
> I thought I'd add a slightly different perspective to the discussion about initial cwnd.  I'm a developer on Chrome & SPDY.
>
> With SPDY, we want to build an application protocol which is efficient on the transport, good for the network, and faster than
> HTTP.  But right now, TCP is holding us back because we're trying to accomplish with one connection what HTTP does with
> 10+ connections.
>
> Note:  I don't want to make this thread about SPDY.  I hope the members of this list agree that the goals of SPDY are good
> and will help make TCP a friendly transport for an application protocol like SPDY.
>
> Background
> Unrelated to TCP, HTTP is not very efficient.  This has been widely documented and observed for some time.  We can easily
> demonstrate a more efficient protocol, which transfers 25-35% fewer packets than HTTP and reduces bytes transferred by
> 10-15%.  Hopefully everyone agrees those are good things for the network.
>
> Unfortunately, any TCP-based protocol which uses a single connection is at a latency-handicap compared to any protocol that
> uses multiple connections.  This is due to IW.  Further, because bandwidth increases have outpaced RTT decreases,
> bandwidth is relatively cheap.  So, being efficient on your bandwidth is less critical than being efficient on your round-trips.
>
> To visualize the effects, please see the attached graph.  (Or click here <http://6541078575799853287-a-chromium-org-s-
> sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initial_cwnd_on_plt(1).png?attachauth=ANoY7cpm-y5NA-
> zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9-
> QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3CzKbzsxnGKlQaectqG8a7cjg5vgU1Gj4c
> FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFPQkAmEI2FvRbq6IBg1aI%3D&attredirect
> s=0> )  In these tests, I loaded a replica of the facebook landing page through two protocols - one using a single connection in
> a semi-efficient manner (an early version of spdy) and another using 6 connections (http).  I used a high-bandwidth network
> with either 100ms or 200ms of RTT, and then I varied IW from 2pkts all the way to 128pkts.  I chose this network
> configuration to specifically isolate the effects of high-RTT and IW.  As you can see, at low IW, the single-connection protocol
> fares poorly compared to the multi-connection protocol.   For another writeup on the problem, see
> http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf
>
> Today, the fastest way to deliver content is to simply side-step cwnd by use of multiple connections.
>
>
> The Problem
> With SPDY (or whatever protocol comes next), we can definitely reduce the number of connections out of the browser by *at
> least* a factor of 6.  With unfolding of the subdomain tricks that websites have been doing, we can reduce it by a factor of
> 10.  This has nothing to do with TCP, except I hope that folks on this list appreciate that this goodness:  fewer connections -
> fewer packets - and fewer bytes.
>
> The only trouble is that if we abide to the RFCs, fewer connections + fewer packets + fewer bytes equates to slower web
> pages.
>
> But I'm not asking that we increase IW by a factor of 10; because it grows exponentially, if we can increase it to somewhere
> in the ~16 range, it's good enough.
>
>
> The Conundrum
> More perplexing is that whenever we talk about increasing IW, we tend to think of the static throttle that we have today.  If
> we increase a static throttle, it affects everything.  So protocols that are already bursting 20-30x more packets than they
> should (by way of many connections) will burst even more.
>
> This makes some people want to do nothing...
>
> At the same time, we also know that cwnd has already been increased on the net at large.   This started with use of multiple
> connections, multiplied with the use of multiple subdomains, and is now changing by major sites simply increasing or
> ignoring cwnd altogther.  With so many sites systematically working around cwnd, we know that the current limits can be
> increased.  We just don't know how much.
>
>
> The Solution?
> Is the obvious solution to stop using a static value?  It doesn't seem like we're in a one-size-fits-all for IW.
>
> The IW could either be defined to be protocol-specific, or dynamic based on number of TCP flows between the same two
> endpoints.  Both of these approaches would offer the benefit of a controlled, increased cwnd to reflect the changes in the net
> over the last 2 decades but also not completely unthrottle protocols that are already living on the edge of not having
> throttles.
>
> Finally, if a dynamic throttle is too much to decide upon, at least updating the static value seems appropriate.  Jerrry and
> Nandita have provided good data for a general-purpose increase to 10.  If inefficient protocols are allowed to go that high,
> maybe more efficient protocols could be allowed to go higher (with data, of course).
>
>
> Reality Check
> Finally, regardless of this debate in the IETF, what is actually going to happen?
>
> a) IETF does not increase the limit (or continues to wait):
> As time goes on, more and more evidence emerges to demonstrate that the current cwnd limits are unnecessarily
> conservative.  More evidence also emerges that increasing cwnd makes your site faster.  More sites start experimenting with
> their own values of cwnd.  Without a blessed recommendation from the IETF, sites choose whatever values they want. Ben
> Strong offered a writeup today which demonstrates this is already happening <http://blog.benstrong.com/2010/11/google-
> and-microsoft-cheat-on-slow.html> .
>
> b) IETF increases the limit:
> With data and a specific recommendation, TCP vendors can quickly move to the new recommendations, making their
> products more competitive in the marketplace, and better for users.  Pressure is alleviated from existing sites to go
> renegade, and instead they can rest on the specific findings from this group.  With a modern recommendation in hand, all of
> us can credibly go after any sites which do choose to use dangerously high cwnd values.  Finally, having an officially
> increased IW is an enabler for a future of more efficient application level protocols, which are currently at a disadvantage to
> their less-efficient counterparts.
>
>
>
>
> Now, which of these two options carries more risk of internet collapse?  Vendors implementing whatever-the-heck-their-
> rookie-system-administrator decided to configure?  Or an official, controlled and intelligent recommendation from this
> group?
>
>
> Thanks to everyone on this list for their hard work over the years - although my email is somewhat critical, be aware that I
> have immense gratitude and respect for the veterans of this list that have been keeping the net flowing for so long with such
> great success.
> Mike

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--Boundary_(ID_FWfcBIrE4VLwOCmZIHXm9g)-- From mike@belshe.com Mon Nov 29 01:16:03 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7383A6BA9 for ; Mon, 29 Nov 2010 01:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.674 X-Spam-Level: *** X-Spam-Status: No, score=3.674 tagged_above=-999 required=5 tests=[AWL=-3.514, BAYES_99=3.5, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=0.001, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbAp5QUqNrnp for ; Mon, 29 Nov 2010 01:16:01 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 9E1FA3A6B49 for ; Mon, 29 Nov 2010 01:16:00 -0800 (PST) Received: by qwg5 with SMTP id 5so3080302qwg.31 for ; Mon, 29 Nov 2010 01:17:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.238.16 with SMTP id kq16mr4611097qcb.134.1291022229360; Mon, 29 Nov 2010 01:17:09 -0800 (PST) Received: by 10.229.235.3 with HTTP; Mon, 29 Nov 2010 01:17:09 -0800 (PST) In-Reply-To: <01fb01cb8f97$6e343520$30298a0a@china.huawei.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> <01fb01cb8f97$6e343520$30298a0a@china.huawei.com> Date: Mon, 29 Nov 2010 01:17:09 -0800 Message-ID: From: Mike Belshe To: Qin Wu Content-Type: multipart/alternative; boundary=0016e64cbf6c60d2cd04962d899c Cc: tcpm@ietf.org Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 09:16:04 -0000 --0016e64cbf6c60d2cd04962d899c Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 28, 2010 at 11:31 PM, Qin Wu wrote: > ----- Original Message ----- > > *From:* Mike Belshe > *To:* Ali C. Begen (abegen) > *Cc:* tcpm@ietf.org > *Sent:* Monday, November 29, 2010 2:46 PM > *Subject:* Re: [tcpm] A Challenge to TCPM > > On Sat, Nov 27, 2010 at 12:34 PM, Ali C. Begen (abegen) wrote: > >> I agree with some of the claims you are making below, and I don't agree >> with some. I just wanna point out one thing, though. You are largely >> dismissing the #1 reason why applications are often using more than 1 TCP >> connection. It is not often about the tput. It is often (more than often >> actually) about the delay (among a few other reasons), which is critical for >> short-lived transactions. >> > > Actually, that was my whole point. The only way to get the latency down is > to avoid cwnd, and multiple connections are an easy trick to accomplish just > that. > > [Qin]: I am suspecting the latency also lies on how TCP detect and recover > from the loss or congestion control algorithm. Selecting appropriate design > parameters for loss detection like minRTO, D rather than cwnd can > effectively > reduce potencital latency or connection duration. > > There are many factors. It doesn't all come down to cwnd, of course. If you look at the zero-loss case, which is fairly common, cwnd is a major factor. > > >> >> You can increase the IW to 100 for all I care but TCP will still have to >> leave with the HOL blocking issue. IETF can make a recommendation on IW but >> I have serious doubts about TCP vendors quickly adopting as you suggest. As >> for the number of TCP connections in parallel, that is not easy to place a >> policy anyway. >> > > That is a separate issue and generally less severe than the cwnd issue. I > could provide more color about SCTP, HOL and other issues, but I really > don't want to derail this thread to be about anything other than TCP's > initial cwnd setting. > > We need to decide if we think an application protocol should be able to be > both a low-latency protocol, and based on TCP. If you think that should be > possible, then we seriously need to consider changing IW. The reasons not > to change it, would be if you thought it would kill the net - but, I there > is no evidence of that, especially if we consider which protocols get which > limits. > > [Qin]: I am not sure changing IW can come up with one low-latency protocol > which is based on TCP. I will assume IW changing is orthogonal to RTT or > connection duration and will only affect throughput as Ali pointed out. Can > you give some data on how IW affect RTT like graph you show in the previous > email? > > There is more to it than just cwnd, I never meant to imply otherwise. I've done quite a lot of research and testing here, have isolated cwnd as a bottleneck, and am attempting to convey that here. My point is that, any protocol, attempting to send independent, medium-sized bursts (greater than 4K) but not huge (large enough for TCP to warm up), will be slower with fewer connections than many. Ali is incorrect that changing IW will only change connection duration. Changing IW directly effects the number of round-trips required to download a resource. With a typical 100ms RTT, a 5KB resource can be transferred in 100ms less time if it were not for cwnd. For a 50KB transfer, an increase of initial cwnd from 2 to 10 reduces the overall time more dramatically - from ~8 round trips to ~5 round trips, saving 3 round trips * 100ms == 300ms of total transfer time. Finally, if you apply how web pages load (an average web page discovers resources over time, and makes ~49 independent requests totaling ~320KB), there are additive effects to these cwnd-induced stalls. The first resource was stalled by 1 or 2 RTs, then the second resource is stalled by 2-3 RTs, etc. And that is why, as the chart shows quite clearly, that a single-connection protocol for HTTP with current cwnd values is slower than a multi-connection HTTP - the multi-connection HTTP gets more cwnd. This chart is pretty clear, I hope. I've isolated just the one variable to test- init-cwnd, and demonstrated the effects. This effect can be seen in the real world - just open up tcpdump and load a few web pages. I guarantee you'll see it! :-) Mike > > >> >> Maybe, trying to fix TCP to make HTTP is not the best strategy here. >> > > Are you saying HTTP should move to a new transport? That seems like a > shame. > > Mike > > > >> >> -acbegen >> >> > -----Original Message----- >> > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >> Mike Belshe >> > Sent: Friday, November 26, 2010 1:11 PM >> > To: tcpm@ietf.org >> > Subject: [tcpm] A Challenge to TCPM >> > >> > Hi, >> > >> > I thought I'd add a slightly different perspective to the discussion >> about initial cwnd. I'm a developer on Chrome & SPDY. >> > >> > With SPDY, we want to build an application protocol which is efficient >> on the transport, good for the network, and faster than >> > HTTP. But right now, TCP is holding us back because we're trying to >> accomplish with one connection what HTTP does with >> > 10+ connections. >> > >> > Note: I don't want to make this thread about SPDY. I hope the members >> of this list agree that the goals of SPDY are good >> > and will help make TCP a friendly transport for an application protocol >> like SPDY. >> > >> > Background >> > Unrelated to TCP, HTTP is not very efficient. This has been widely >> documented and observed for some time. We can easily >> > demonstrate a more efficient protocol, which transfers 25-35% fewer >> packets than HTTP and reduces bytes transferred by >> > 10-15%. Hopefully everyone agrees those are good things for the >> network. >> > >> > Unfortunately, any TCP-based protocol which uses a single connection is >> at a latency-handicap compared to any protocol that >> > uses multiple connections. This is due to IW. Further, because >> bandwidth increases have outpaced RTT decreases, >> > bandwidth is relatively cheap. So, being efficient on your bandwidth is >> less critical than being efficient on your round-trips. >> > >> > To visualize the effects, please see the attached graph. (Or click here >> > > >> sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initial_cwnd_on_plt(1).png?attachauth=ANoY7cpm-y5NA- >> > zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9- >> > >> QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3CzKbzsxnGKlQaectqG8a7cjg5vgU1Gj4c >> > >> FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFPQkAmEI2FvRbq6IBg1aI%3D&attredirect >> > s=0> ) In these tests, I loaded a replica of the facebook landing page >> through two protocols - one using a single connection in >> > a semi-efficient manner (an early version of spdy) and another using 6 >> connections (http). I used a high-bandwidth network >> > with either 100ms or 200ms of RTT, and then I varied IW from 2pkts all >> the way to 128pkts. I chose this network >> > configuration to specifically isolate the effects of high-RTT and IW. >> As you can see, at low IW, the single-connection protocol >> > fares poorly compared to the multi-connection protocol. For another >> writeup on the problem, see >> > >> http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf >> > >> > Today, the fastest way to deliver content is to simply side-step cwnd by >> use of multiple connections. >> > >> > >> > The Problem >> > With SPDY (or whatever protocol comes next), we can definitely reduce >> the number of connections out of the browser by *at >> > least* a factor of 6. With unfolding of the subdomain tricks that >> websites have been doing, we can reduce it by a factor of >> > 10. This has nothing to do with TCP, except I hope that folks on this >> list appreciate that this goodness: fewer connections - >> > fewer packets - and fewer bytes. >> > >> > The only trouble is that if we abide to the RFCs, fewer connections + >> fewer packets + fewer bytes equates to slower web >> > pages. >> > >> > But I'm not asking that we increase IW by a factor of 10; because it >> grows exponentially, if we can increase it to somewhere >> > in the ~16 range, it's good enough. >> > >> > >> > The Conundrum >> > More perplexing is that whenever we talk about increasing IW, we tend to >> think of the static throttle that we have today. If >> > we increase a static throttle, it affects everything. So protocols that >> are already bursting 20-30x more packets than they >> > should (by way of many connections) will burst even more. >> > >> > This makes some people want to do nothing... >> > >> > At the same time, we also know that cwnd has already been increased on >> the net at large. This started with use of multiple >> > connections, multiplied with the use of multiple subdomains, and is now >> changing by major sites simply increasing or >> > ignoring cwnd altogther. With so many sites systematically working >> around cwnd, we know that the current limits can be >> > increased. We just don't know how much. >> > >> > >> > The Solution? >> > Is the obvious solution to stop using a static value? It doesn't seem >> like we're in a one-size-fits-all for IW. >> > >> > The IW could either be defined to be protocol-specific, or dynamic based >> on number of TCP flows between the same two >> > endpoints. Both of these approaches would offer the benefit of a >> controlled, increased cwnd to reflect the changes in the net >> > over the last 2 decades but also not completely unthrottle protocols >> that are already living on the edge of not having >> > throttles. >> > >> > Finally, if a dynamic throttle is too much to decide upon, at least >> updating the static value seems appropriate. Jerrry and >> > Nandita have provided good data for a general-purpose increase to 10. >> If inefficient protocols are allowed to go that high, >> > maybe more efficient protocols could be allowed to go higher (with data, >> of course). >> > >> > >> > Reality Check >> > Finally, regardless of this debate in the IETF, what is actually going >> to happen? >> > >> > a) IETF does not increase the limit (or continues to wait): >> > As time goes on, more and more evidence emerges to demonstrate that the >> current cwnd limits are unnecessarily >> > conservative. More evidence also emerges that increasing cwnd makes >> your site faster. More sites start experimenting with >> > their own values of cwnd. Without a blessed recommendation from the >> IETF, sites choose whatever values they want. Ben >> > Strong offered a writeup today which demonstrates this is already >> happening > > and-microsoft-cheat-on-slow.html> . >> > >> > b) IETF increases the limit: >> > With data and a specific recommendation, TCP vendors can quickly move to >> the new recommendations, making their >> > products more competitive in the marketplace, and better for users. >> Pressure is alleviated from existing sites to go >> > renegade, and instead they can rest on the specific findings from this >> group. With a modern recommendation in hand, all of >> > us can credibly go after any sites which do choose to use dangerously >> high cwnd values. Finally, having an officially >> > increased IW is an enabler for a future of more efficient application >> level protocols, which are currently at a disadvantage to >> > their less-efficient counterparts. >> > >> > >> > >> > >> > Now, which of these two options carries more risk of internet collapse? >> Vendors implementing whatever-the-heck-their- >> > rookie-system-administrator decided to configure? Or an official, >> controlled and intelligent recommendation from this >> > group? >> > >> > >> > Thanks to everyone on this list for their hard work over the years - >> although my email is somewhat critical, be aware that I >> > have immense gratitude and respect for the veterans of this list that >> have been keeping the net flowing for so long with such >> > great success. >> > Mike >> > > ------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --0016e64cbf6c60d2cd04962d899c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Nov 28, 2010 at 11:31 PM, Qin Wu= <sunseawq@huaw= ei.com> wrote:
----- Original Message -----
From:=20 Mike Belshe
Sent: Monday, November 29, 2010 2:46 PM
Subject: Re: [tcpm] A Challenge to TCPM

On Sat, Nov 27, 2010 a= t 12:34 PM, Ali C. Begen (abegen)=20 <abegen@cisco.com> wrote:
I agree with some of the claims you= are making below, and=20 I don't agree with some. I just wanna point out one thing, though. = You are=20 largely dismissing the #1 reason why applications are often using more = than=20 1 TCP connection. It is not often about the tput. It is often (more tha= n=20 often actually) about the delay (among a few other reasons), which is= =20 critical for short-lived transactions.

Actually, that was my whole point. =C2=A0The only way to get the lat= ency=20 down is to avoid cwnd, and multiple connections are an easy trick to=20 accomplish just that.
=C2=A0
[Qin]: I am suspecting the latency also lies on how TCP detect= and=20 recover from the loss or congestion control algorithm. Selecting appropri= ate=20 design parameters for loss detection like minRTO, D rather than cwnd can= =20 effectively
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reduce potencital= =20 latency or connection duration.

There are many factors. =C2=A0It doesn't all come= down to cwnd, of course. =C2=A0 If you look at the zero-loss case, which i= s fairly common, cwnd is a major factor.
=C2=A0
<= blockquote style=3D"border-left:#000000 2px solid;padding-left:5px;padding-= right:0px;margin-left:5px;margin-right:0px">
=C2=A0

You can increase the IW to 100 = for all I care but TCP=20 will still have to leave with the HOL blocking issue. IETF can make a= =20 recommendation on IW but I have serious doubts about TCP vendors quickl= y=20 adopting as you suggest. As for the number of TCP connections in parall= el,=20 that is not easy to place a policy anyway.

That is a separate issue and generally less severe than the cwnd iss= ue.=20 =C2=A0I could provide more color about SCTP, HOL and other issues, but=C2= =A0I=20 really don't want to derail this thread to be about anything other th= an TCP's=20 initial cwnd setting. =C2=A0

We need to decide if we think an application protocol should be able= to=20 be both a low-latency protocol, and based on TCP. =C2=A0If you think that= =20 should be possible, then we seriously need to consider changing IW. =C2= =A0The=20 reasons not to change it, would be if you thought it would kill the net -= but,=20 I there is no evidence of that, especially if we consider which protocols= get=20 which limits.
=C2=A0
[Qin]: I am not sure changing IW can come up with one low-late= ncy=20 protocol which is based on TCP. I will assume IW changing is orthogonal t= o RTT=20 or connection duration and will only affect throughput as Ali pointed out= . Can=20 you give some data on how IW affect RTT like graph you show in the previo= us=20 email?
There is more to i= t than just cwnd, I never meant to imply otherwise. =C2=A0I've done qui= te a lot of research and testing here, have isolated cwnd as a bottleneck, = and am attempting to convey that here.=C2=A0

My point is that, any protocol, attempting to send inde= pendent, medium-sized bursts (greater than 4K) but not huge (large enough f= or TCP to warm up), will be slower with fewer connections than many.

Ali is incorrect that changing IW will only change conn= ection duration. =C2=A0 Changing IW directly effects the number of round-tr= ips required to download a resource. =C2=A0With a typical 100ms RTT, a 5KB = resource can be transferred in 100ms less time if it were not for cwnd. =C2= =A0 For a 50KB transfer, an increase of initial cwnd from 2 to 10 reduces t= he overall time more dramatically - from ~8 round trips to ~5 round trips, = saving 3 round trips * 100ms =3D=3D 300ms of total transfer time.

Finally, if you apply how web pages load (an average we= b page discovers resources over time, and makes ~49 independent requests to= taling ~320KB), there are additive effects to these cwnd-induced stalls. = =C2=A0The first resource was stalled by 1 or 2 RTs, then the second resourc= e is stalled by 2-3 RTs, etc. =C2=A0And that is why, as the chart shows qui= te clearly, that a single-connection protocol for HTTP with current cwnd va= lues is slower than a multi-connection HTTP - the multi-connection HTTP get= s more cwnd.

This chart is pretty clear, I hope. =C2=A0I've isol= ated just the one variable to test- init-cwnd, and demonstrated the effects= . =C2=A0This effect can be seen in the real world - just open up tcpdump an= d load a few web pages. =C2=A0I guarantee you'll see it! :-)

Mike


=C2=A0
=C2=A0

Maybe, trying to fix TCP=20 to make HTTP is not the best strategy here.

Are you saying HTTP should move to a new transport? =C2=A0That seems= like=20 a shame.

Mike

=C2=A0

-acbegen

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailt= o:tcpm-bounces@i= etf.org] On Behalf Of=20 Mike Belshe
> Sent: Friday, November 26, 2010 1:11 PM
> To:= tcpm@ietf.org
&g= t; Subject: [tcpm] A=20 Challenge to TCPM
>
> Hi,
>
> I thought I'd= add a=20 slightly different perspective to the discussion about initial cwnd.=20 =C2=A0I'm a developer on Chrome & SPDY.
>
> With SP= DY, we=20 want to build an application protocol which is efficient on the transpo= rt,=20 good for the network, and faster than
> HTTP. =C2=A0But right now= , TCP=20 is holding us back because we're trying to accomplish with one conn= ection=20 what HTTP does with
> 10+ connections.
>
> Note: =C2= =A0I=20 don't want to make this thread about SPDY. =C2=A0I hope the members= of this=20 list agree that the goals of SPDY are good
> and will help make T= CP a=20 friendly transport for an application protocol like SPDY.
>
&g= t;=20 Background
> Unrelated to TCP, HTTP is not very efficient. =C2=A0= This=20 has been widely documented and observed for some time. =C2=A0We can=20 easily
> demonstrate a more efficient protocol, which transfers 2= 5-35%=20 fewer packets than HTTP and reduces bytes transferred by
> 10-15%= .=20 =C2=A0Hopefully everyone agrees those are good things for the=20 network.
>
> Unfortunately, any TCP-based protocol which us= es a=20 single connection is at a latency-handicap compared to any protocol=20 that
> uses multiple connections. =C2=A0This is due to IW.=20 =C2=A0Further, because bandwidth increases have outpaced RTT=20 decreases,
> bandwidth is relatively cheap. =C2=A0So, being effic= ient=20 on your bandwidth is less critical than being efficient on your=20 round-trips.
>
> To visualize the effects, please see= the=20 attached graph. =C2=A0(Or click here <http://6541078575799853287-a-c= hromium-org-s-
> sites.googlegroups.com/a/chromium.org/dev/spdy/ef= fect_of_initial_cwnd_on_plt(1).png?attachauth=3DANoY7cpm-y5NA-
>=20 zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9-
>=20 QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3CzK= bzsxnGKlQaectqG8a7cjg5vgU1Gj4c
>=20 FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFPQ= kAmEI2FvRbq6IBg1aI%3D&attredirect
>=20 s=3D0> ) =C2=A0In these tests, I loaded a replica of the facebook la= nding=20 page through two protocols - one using a single connection in
> a semi-efficient manner (an early version of spdy) and=20 another using 6 connections (http). =C2=A0I used a high-bandwidth=20 network
> with either 100ms or 200ms of RTT, and then I varied IW= from=20 2pkts all the way to 128pkts. =C2=A0I chose this network
>=20 configuration to specifically isolate the effects of high-RTT and IW.= =20 =C2=A0As you can see, at low IW, the single-connection protocol
>= =20 fares poorly compared to the multi-connection protocol. =C2=A0 For anot= her=20 writeup on the problem, see
> http://= dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf
&g= t;
>=20 Today, the fastest way to deliver content is to simply side-step cwnd b= y use=20 of multiple connections.
>
>
> The Problem
> Wi= th=20 SPDY (or whatever protocol comes next), we can definitely reduce the nu= mber=20 of connections out of the browser by *at
> least* a factor of 6.= =20 =C2=A0With unfolding of the subdomain tricks that websites have been do= ing,=20 we can reduce it by a factor of
> 10. =C2=A0This has nothing to d= o=20 with TCP, except I hope that folks on this list appreciate that this=20 goodness: =C2=A0fewer connections -
> fewer packets - and fewer= =20 bytes.
>
> The only trouble is that if we abide to the RFCs= ,=20 fewer connections + fewer packets + fewer bytes equates to slower=20 web
> pages.
>
> But I'm not asking that we incre= ase IW by=20 a factor of 10; because it grows exponentially, if we can increase it t= o=20 somewhere
> in the ~16 range, it's good=20 enough.
>
>
> The Conundrum
> More perplexing i= s=20 that whenever we talk about increasing IW, we tend to think of the stat= ic=20 throttle that we have today. =C2=A0If
> we increase a static thro= ttle,=20 it affects everything. =C2=A0So protocols that are already bursting 20-= 30x=20 more packets than they
> should (by way of many connections) will= =20 burst even more.
>
> This makes some people want to do=20 nothing...
>
> At the same time, we also know that cwnd has= =20 already been increased on the net at large. =C2=A0 This started with us= e of=20 multiple
> connections, multiplied with the use of multiple=20 subdomains, and is now changing by major sites simply increasing or
= >=20 ignoring cwnd altogther. =C2=A0With so many sites systematically workin= g=20 around cwnd, we know that the current limits can be
> increased.= =20 =C2=A0We just don't know how much.
>
>
> The=20 Solution?
> Is the obvious solution to stop using a static value?= =20 =C2=A0It doesn't seem like we're in a one-size-fits-all for=20 IW.
>
> The IW could either be defined to be protocol-speci= fic,=20 or dynamic based on number of TCP flows between the same two
>=20 endpoints. =C2=A0Both of these approaches would offer the benefit of a= =20 controlled, increased cwnd to reflect the changes in the net
> ov= er=20 the last 2 decades but also not completely unthrottle protocols that ar= e=20 already living on the edge of not having
> throttles.
>
= >=20 Finally, if a dynamic throttle is too much to decide upon, at least upd= ating=20 the static value seems appropriate. =C2=A0Jerrry and
> Nandita ha= ve=20 provided good data for a general-purpose increase to 10. =C2=A0If=20 inefficient protocols are allowed to go that high,
> maybe more= =20 efficient protocols could be allowed to go higher (with data, of=20 course).
>
>
> Reality Check
> Finally, regardl= ess=20 of this debate in the IETF, what is actually going to=20 happen?
>
> a) IETF does not increase the limit (or continu= es to=20 wait):
> As time goes on, more and more evidence emerges to=20 demonstrate that the current cwnd limits are unnecessarily
>=20 conservative. =C2=A0More evidence also emerges that increasing cwnd mak= es=20 your site faster. =C2=A0More sites start experimenting with
> the= ir=20 own values of cwnd. =C2=A0Without a blessed recommendation from the IET= F,=20 sites choose whatever values they want. Ben
> Strong= =20 offered a writeup today which demonstrates this is already happening &l= t;h= ttp://blog.benstrong.com/2010/11/google-
>=20 and-microsoft-cheat-on-slow.html> .
>
> b) IETF increases the limit:
> With data=20 and a specific recommendation, TCP vendors can quickly move to the new= =20 recommendations, making their
> products more competitive in the= =20 marketplace, and better for users. =C2=A0Pressure is alleviated from=20 existing sites to go
> renegade, and instead they can rest on the= =20 specific findings from this group. =C2=A0With a modern recommendation i= n=20 hand, all of
> us can credibly go after any sites which do choose= to=20 use dangerously high cwnd values. =C2=A0Finally, having an=20 officially
> increased IW is an enabler for a future of more effi= cient=20 application level protocols, which are currently at a disadvantage=20 to
> their less-efficient=20 counterparts.
>
>
>
>
> Now, which of the= se=20 two options carries more risk of internet collapse? =C2=A0Vendors=20 implementing whatever-the-heck-their-
> rookie-system-administrat= or=20 decided to configure? =C2=A0Or an official, controlled and intelligent= =20 recommendation from this
> group?
>
>
> Thanks = to=20 everyone on this list for their hard work over the years - although my = email=20 is somewhat critical, be aware that I
> have immense gratitude an= d=20 respect for the veterans of this list that have been keeping the net fl= owing=20 for so long with such
> great success.
>=20 Mike

_______________________________________________
tcpm mailing=20 list
tcpm@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/tcpm


--0016e64cbf6c60d2cd04962d899c-- From L.Wood@surrey.ac.uk Mon Nov 29 01:23:13 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183323A6C04; Mon, 29 Nov 2010 01:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoczQPtFkc+h; Mon, 29 Nov 2010 01:23:10 -0800 (PST) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 736F43A6BFD; Mon, 29 Nov 2010 01:23:09 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-15.tower-82.messagelabs.com!1291022657!27893339!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [131.227.200.39] Received: (qmail 30044 invoked from network); 29 Nov 2010 09:24:18 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-15.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 29 Nov 2010 09:24:18 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Mon, 29 Nov 2010 09:24:17 +0000 From: To: , , , , Date: Mon, 29 Nov 2010 09:24:14 +0000 Thread-Topic: [tae] [tcpm] A Challenge to TCPM Thread-Index: AcuNlUG/mOB0699nQE6fHFKA+8QeOgA3CztAAB9I3tAAAwxuUAAcQVdwAA6z90A= Message-ID: References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0BA9624C@LDCMVEXC1-PRD.hq.netapp.com> <04CAD96D4C5A3D48B1919248A8FE0D540DC92F71@xmb-sjc-215.amer.cisco.com> <003801cb8f6d$d351ed00$79f5c700$%cui@huawei.com> In-Reply-To: <003801cb8f6d$d351ed00$79f5c700$%cui@huawei.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tae@ietf.org Subject: Re: [tcpm] [tae] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 09:23:13 -0000 For HTTP over SCTP see discussion in=20 http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports and particularly http://tools.ietf.org/html/draft-natarajan-http-over-sctp This can form part of making HTTP run over more streaming protocols, not ju= st TCP, to adapt it for different/high performane environments: http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-draft= s/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-turning-http-into-a-standal= one-layer-ietf-75-tsvarea-slides.pdf talk given to the TSVAREA meeting, IETF 75, Stockholm, 27 July 2009. -----Original Message----- From: tae-bounces@ietf.org [mailto:tae-bounces@ietf.org] On Behalf Of Xiang= song Cui Sent: 29 November 2010 02:34 To: 'Ali C. Begen (abegen)'; 'Scheffenegger, Richard'; 'Mike Belshe'; tcpm@= ietf.org Cc: tae@ietf.org Subject: Re: [tae] [tcpm] A Challenge to TCPM > Sure but HTTP is not using SCTP today. Should we look into it? Sorry for digging this topic in tcpm list, but I think the guys interested = in this topic also cover tcpm. I think this is an interesting item. In my remember, a Bar-BoF (or BoF) named "Negotiation BoF" was ever mention= ed at IETF76 (denied by AD at that time). There is a draft, http://tools.ietf.org/html/draft-wing-http-new-tech-00, and Dan presented this topic at IETF79, http://www.ietf.org/proceedings/79/slides/tsvwg-9.pptx, Who can tell me more information about this? I missed the BoF at IETF76. Thanks and regards, Xiangsong _______________________________________________ tae mailing list tae@ietf.org https://www.ietf.org/mailman/listinfo/tae From Xiangsong.Cui@huawei.com Mon Nov 29 01:43:49 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA2E3A6C10; Mon, 29 Nov 2010 01:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=1.941, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReWkm5hoIs7c; Mon, 29 Nov 2010 01:43:48 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CA61F3A6C0F; Mon, 29 Nov 2010 01:43:47 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCN00JE34CDTM@szxga04-in.huawei.com>; Mon, 29 Nov 2010 17:43:25 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCN006054CCZ5@szxga04-in.huawei.com>; Mon, 29 Nov 2010 17:43:25 +0800 (CST) Date: Mon, 29 Nov 2010 17:43:27 +0800 From: Xiangsong Cui In-reply-to: To: L.Wood@surrey.ac.uk, abegen@cisco.com, rs@netapp.com, mike@belshe.com, tcpm@ietf.org Message-id: <007f01cb8fa9$dfdd5320$9f97f960$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcuNlUG/mOB0699nQE6fHFKA+8QeOgA3CztAAB9I3tAAAwxuUAAcQVdwAA6z90AAAMtSIA== References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0BA9624C@LDCMVEXC1-PRD.hq.netapp.com> <04CAD96D4C5A3D48B1919248A8FE0D540DC92F71@xmb-sjc-215.amer.cisco.com> <003801cb8f6d$d351ed00$79f5c700$%cui@huawei.com> Cc: tae@ietf.org Subject: Re: [tcpm] [tae] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 09:43:49 -0000 Thanks for the information! Regards, Xiangsong > -----Original Message----- > From: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk] > Sent: Monday, November 29, 2010 5:24 PM > To: Xiangsong.Cui@huawei.com; abegen@cisco.com; rs@netapp.com; > mike@belshe.com; tcpm@ietf.org > Cc: tae@ietf.org > Subject: RE: [tae] [tcpm] A Challenge to TCPM > > For HTTP over SCTP see discussion in > http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports > and particularly > http://tools.ietf.org/html/draft-natarajan-http-over-sctp > > This can form part of making HTTP run over more streaming protocols, not just > TCP, to adapt it for different/high performane environments: > http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts / > draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-turning-http-into-a-standalone -l > ayer-ietf-75-tsvarea-slides.pdf > talk given to the TSVAREA meeting, IETF 75, Stockholm, 27 July 2009. > > -----Original Message----- > From: tae-bounces@ietf.org [mailto:tae-bounces@ietf.org] On Behalf Of > Xiangsong Cui > Sent: 29 November 2010 02:34 > To: 'Ali C. Begen (abegen)'; 'Scheffenegger, Richard'; 'Mike Belshe'; > tcpm@ietf.org > Cc: tae@ietf.org > Subject: Re: [tae] [tcpm] A Challenge to TCPM > > > Sure but HTTP is not using SCTP today. Should we look into it? > > Sorry for digging this topic in tcpm list, but I think the guys interested in this > topic also cover tcpm. > > I think this is an interesting item. > > In my remember, a Bar-BoF (or BoF) named "Negotiation BoF" was ever > mentioned at IETF76 (denied by AD at that time). > > There is a draft, http://tools.ietf.org/html/draft-wing-http-new-tech-00, > and Dan presented this topic at IETF79, > http://www.ietf.org/proceedings/79/slides/tsvwg-9.pptx, > > Who can tell me more information about this? I missed the BoF at IETF76. > > Thanks and regards, > Xiangsong > > > _______________________________________________ > tae mailing list > tae@ietf.org > https://www.ietf.org/mailman/listinfo/tae From abegen@cisco.com Mon Nov 29 05:02:22 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14D53A6C0F for ; Mon, 29 Nov 2010 05:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.091 X-Spam-Level: X-Spam-Status: No, score=-8.091 tagged_above=-999 required=5 tests=[AWL=-2.273, BAYES_50=0.001, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+mgsgnHweaV for ; Mon, 29 Nov 2010 05:02:20 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 37EF93A6BFF for ; Mon, 29 Nov 2010 05:02:20 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsDABcz80yrR7Hu/2dsb2JhbACDUJBtjWVccac6ijs3j3mBIYMzcwSEXIka X-IronPort-AV: E=Sophos;i="4.59,275,1288569600"; d="scan'208";a="385505859" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 29 Nov 2010 13:03:29 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oATD3TVT016472; Mon, 29 Nov 2010 13:03:29 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Nov 2010 05:03:29 -0800 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, 29 Nov 2010 05:03:24 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DC93005@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] A Challenge to TCPM Thread-Index: AcuPpjQU081hmWoxQsaS0FLm5pjARwAHpFtg References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com><01fb01cb8f97$6e343520$30298a0a@china.huawei.com> From: "Ali C. Begen (abegen)" To: "Mike Belshe" , "Qin Wu" X-OriginalArrivalTime: 29 Nov 2010 13:03:29.0462 (UTC) FILETIME=[D165A560:01CB8FC5] Cc: tcpm@ietf.org Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 13:02:22 -0000 Li4uDQo+IAkJV2UgbmVlZCB0byBkZWNpZGUgaWYgd2UgdGhpbmsgYW4gYXBwbGljYXRpb24gcHJv dG9jb2wgc2hvdWxkIGJlIGFibGUgdG8gYmUgYm90aCBhIGxvdy1sYXRlbmN5IHByb3RvY29sLCBh bmQNCj4gYmFzZWQgb24gVENQLiAgSWYgeW91IHRoaW5rIHRoYXQgc2hvdWxkIGJlIHBvc3NpYmxl LCB0aGVuIHdlIHNlcmlvdXNseSBuZWVkIHRvIGNvbnNpZGVyIGNoYW5naW5nIElXLiAgVGhlIHJl YXNvbnMgbm90IHRvDQo+IGNoYW5nZSBpdCwgd291bGQgYmUgaWYgeW91IHRob3VnaHQgaXQgd291 bGQga2lsbCB0aGUgbmV0IC0gYnV0LCBJIHRoZXJlIGlzIG5vIGV2aWRlbmNlIG9mIHRoYXQsIGVz cGVjaWFsbHkgaWYgd2UgY29uc2lkZXIgd2hpY2gNCj4gcHJvdG9jb2xzIGdldCB3aGljaCBsaW1p dHMuDQo+IA0KPiAJCVtRaW5dOiBJIGFtIG5vdCBzdXJlIGNoYW5naW5nIElXIGNhbiBjb21lIHVw IHdpdGggb25lIGxvdy1sYXRlbmN5IHByb3RvY29sIHdoaWNoIGlzIGJhc2VkIG9uIFRDUC4gSSB3 aWxsDQo+IGFzc3VtZSBJVyBjaGFuZ2luZyBpcyBvcnRob2dvbmFsIHRvIFJUVCBvciBjb25uZWN0 aW9uIGR1cmF0aW9uIGFuZCB3aWxsIG9ubHkgYWZmZWN0IHRocm91Z2hwdXQgYXMgQWxpIHBvaW50 ZWQgb3V0LiBDYW4geW91DQo+IGdpdmUgc29tZSBkYXRhIG9uIGhvdyBJVyBhZmZlY3QgUlRUIGxp a2UgZ3JhcGggeW91IHNob3cgaW4gdGhlIHByZXZpb3VzIGVtYWlsPw0KPiANCj4gVGhlcmUgaXMg bW9yZSB0byBpdCB0aGFuIGp1c3QgY3duZCwgSSBuZXZlciBtZWFudCB0byBpbXBseSBvdGhlcndp c2UuICBJJ3ZlIGRvbmUgcXVpdGUgYSBsb3Qgb2YgcmVzZWFyY2ggYW5kIHRlc3RpbmcgaGVyZSwg aGF2ZQ0KPiBpc29sYXRlZCBjd25kIGFzIGEgYm90dGxlbmVjaywgYW5kIGFtIGF0dGVtcHRpbmcg dG8gY29udmV5IHRoYXQgaGVyZS4NCj4gDQo+IE15IHBvaW50IGlzIHRoYXQsIGFueSBwcm90b2Nv bCwgYXR0ZW1wdGluZyB0byBzZW5kIGluZGVwZW5kZW50LCBtZWRpdW0tc2l6ZWQgYnVyc3RzIChn cmVhdGVyIHRoYW4gNEspIGJ1dCBub3QgaHVnZSAobGFyZ2UNCj4gZW5vdWdoIGZvciBUQ1AgdG8g d2FybSB1cCksIHdpbGwgYmUgc2xvd2VyIHdpdGggZmV3ZXIgY29ubmVjdGlvbnMgdGhhbiBtYW55 Lg0KDQpPZiBjb3Vyc2UsIG5vYm9keSBlbHNlIGlzIHNheWluZyBvdy4NCiANCj4gQWxpIGlzIGlu Y29ycmVjdCB0aGF0IGNoYW5naW5nIElXIHdpbGwgb25seSBjaGFuZ2UgY29ubmVjdGlvbiBkdXJh dGlvbi4gICBDaGFuZ2luZyBJVyBkaXJlY3RseSBlZmZlY3RzIHRoZSBudW1iZXIgb2Ygcm91bmQt DQo+IHRyaXBzIHJlcXVpcmVkIHRvIGRvd25sb2FkIGEgcmVzb3VyY2UuICBXaXRoIGEgdHlwaWNh bCAxMDBtcyBSVFQsIGEgNUtCIHJlc291cmNlIGNhbiBiZSB0cmFuc2ZlcnJlZCBpbiAxMDBtcyBs ZXNzIHRpbWUgaWYgaXQNCj4gd2VyZSBub3QgZm9yIGN3bmQuICAgRm9yIGEgNTBLQiB0cmFuc2Zl ciwgYW4gaW5jcmVhc2Ugb2YgaW5pdGlhbCBjd25kIGZyb20gMiB0byAxMCByZWR1Y2VzIHRoZSBv dmVyYWxsIHRpbWUgbW9yZSBkcmFtYXRpY2FsbHkNCj4gLSBmcm9tIH44IHJvdW5kIHRyaXBzIHRv IH41IHJvdW5kIHRyaXBzLCBzYXZpbmcgMyByb3VuZCB0cmlwcyAqIDEwMG1zID09IDMwMG1zIG9m IHRvdGFsIHRyYW5zZmVyIHRpbWUuDQoNCkkgc2FpZCAiY2hhbmdpbmcgSVcgd291bGQgb25seSBj aGFuZ2UgdGhlIGNvbm4gZHVyYXRpb24iPyBJIGRvbid0IHJlY2FsbCB0aGF0IGJ1dCBhbnl3YXku DQoNCllvdXIgZXhhbXBsZXMgYXJlIGNvcnJlY3QgYnV0IGFzIEkgc2FpZCB0aGVzZSBhcmUgYWxs IHNob3J0LWxpdmVkIHRyYW5zYWN0aW9ucy4gSXQgaXMgbm8gYnJhaW5lciB0aGF0IHRoZWlyIHRy YW5zZmVycyBhcmUgbGltaXRlZCBieSBJVy4gQ2hhbmdpbmcgaXQgZnJvbSAyIHRvIDEwLCBzYXZl cyB5b3UgMyBSVFRzIHNpbmNlIHlvdSBhcmUgc3R1Y2sgd2l0aCBTUyBmb3IgdGhlIGVudGlyZSBj b25uZWN0aW9uLg0KDQpUaGVyZSBhcmUgbWFueSBvdGhlciBhcHBsaWNhdGlvbnMgd2hpY2ggZG9u J3QgbmVjZXNzYXJpbHkgc3BlbmQgdGhlaXIgbGlmZXRpbWUgZW50aXJlbHkgaW4gU1MgcGVyaW9k cywgdGhvdWdoLiANCg0KLWFjYmVnZW4NCiANCj4gRmluYWxseSwgaWYgeW91IGFwcGx5IGhvdyB3 ZWIgcGFnZXMgbG9hZCAoYW4gYXZlcmFnZSB3ZWIgcGFnZSBkaXNjb3ZlcnMgcmVzb3VyY2VzIG92 ZXIgdGltZSwgYW5kIG1ha2VzIH40OSBpbmRlcGVuZGVudA0KPiByZXF1ZXN0cyB0b3RhbGluZyB+ MzIwS0IpLCB0aGVyZSBhcmUgYWRkaXRpdmUgZWZmZWN0cyB0byB0aGVzZSBjd25kLWluZHVjZWQg c3RhbGxzLiAgVGhlIGZpcnN0IHJlc291cmNlIHdhcyBzdGFsbGVkIGJ5IDEgb3IgMg0KPiBSVHMs IHRoZW4gdGhlIHNlY29uZCByZXNvdXJjZSBpcyBzdGFsbGVkIGJ5IDItMyBSVHMsIGV0Yy4gIEFu ZCB0aGF0IGlzIHdoeSwgYXMgdGhlIGNoYXJ0IHNob3dzIHF1aXRlIGNsZWFybHksIHRoYXQgYSBz aW5nbGUtDQo+IGNvbm5lY3Rpb24gcHJvdG9jb2wgZm9yIEhUVFAgd2l0aCBjdXJyZW50IGN3bmQg dmFsdWVzIGlzIHNsb3dlciB0aGFuIGEgbXVsdGktY29ubmVjdGlvbiBIVFRQIC0gdGhlIG11bHRp LWNvbm5lY3Rpb24gSFRUUA0KPiBnZXRzIG1vcmUgY3duZC4NCj4gDQo+IFRoaXMgY2hhcnQgaXMg cHJldHR5IGNsZWFyLCBJIGhvcGUuICBJJ3ZlIGlzb2xhdGVkIGp1c3QgdGhlIG9uZSB2YXJpYWJs ZSB0byB0ZXN0LSBpbml0LWN3bmQsIGFuZCBkZW1vbnN0cmF0ZWQgdGhlIGVmZmVjdHMuICBUaGlz DQo+IGVmZmVjdCBjYW4gYmUgc2VlbiBpbiB0aGUgcmVhbCB3b3JsZCAtIGp1c3Qgb3BlbiB1cCB0 Y3BkdW1wIGFuZCBsb2FkIGEgZmV3IHdlYiBwYWdlcy4gIEkgZ3VhcmFudGVlIHlvdSdsbCBzZWUg aXQhIDotKQ0KPiANCj4gTWlrZQ0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gCQkJTWF5 YmUsIHRyeWluZyB0byBmaXggVENQIHRvIG1ha2UgSFRUUCBpcyBub3QgdGhlIGJlc3Qgc3RyYXRl Z3kgaGVyZS4NCj4gDQo+IA0KPiANCj4gCQlBcmUgeW91IHNheWluZyBIVFRQIHNob3VsZCBtb3Zl IHRvIGEgbmV3IHRyYW5zcG9ydD8gIFRoYXQgc2VlbXMgbGlrZSBhIHNoYW1lLg0KPiANCj4gCQlN aWtlDQo+IA0KPiANCj4gDQo+IA0KPiAJCQktYWNiZWdlbg0KPiANCj4gDQo+IAkJCT4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gCQkJPiBGcm9tOiB0Y3BtLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtlIEJlbHNoZQ0K PiAJCQk+IFNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMjYsIDIwMTAgMToxMSBQTQ0KPiAJCQk+IFRv OiB0Y3BtQGlldGYub3JnDQo+IAkJCT4gU3ViamVjdDogW3RjcG1dIEEgQ2hhbGxlbmdlIHRvIFRD UE0NCj4gCQkJPg0KPiAJCQk+IEhpLA0KPiAJCQk+DQo+IAkJCT4gSSB0aG91Z2h0IEknZCBhZGQg YSBzbGlnaHRseSBkaWZmZXJlbnQgcGVyc3BlY3RpdmUgdG8gdGhlIGRpc2N1c3Npb24gYWJvdXQg aW5pdGlhbCBjd25kLiAgSSdtIGEgZGV2ZWxvcGVyDQo+IG9uIENocm9tZSAmIFNQRFkuDQo+IAkJ CT4NCj4gCQkJPiBXaXRoIFNQRFksIHdlIHdhbnQgdG8gYnVpbGQgYW4gYXBwbGljYXRpb24gcHJv dG9jb2wgd2hpY2ggaXMgZWZmaWNpZW50IG9uIHRoZSB0cmFuc3BvcnQsIGdvb2QgZm9yIHRoZQ0K PiBuZXR3b3JrLCBhbmQgZmFzdGVyIHRoYW4NCj4gCQkJPiBIVFRQLiAgQnV0IHJpZ2h0IG5vdywg VENQIGlzIGhvbGRpbmcgdXMgYmFjayBiZWNhdXNlIHdlJ3JlIHRyeWluZyB0byBhY2NvbXBsaXNo IHdpdGggb25lIGNvbm5lY3Rpb24NCj4gd2hhdCBIVFRQIGRvZXMgd2l0aA0KPiAJCQk+IDEwKyBj b25uZWN0aW9ucy4NCj4gCQkJPg0KPiAJCQk+IE5vdGU6ICBJIGRvbid0IHdhbnQgdG8gbWFrZSB0 aGlzIHRocmVhZCBhYm91dCBTUERZLiAgSSBob3BlIHRoZSBtZW1iZXJzIG9mIHRoaXMgbGlzdCBh Z3JlZSB0aGF0IHRoZQ0KPiBnb2FscyBvZiBTUERZIGFyZSBnb29kDQo+IAkJCT4gYW5kIHdpbGwg aGVscCBtYWtlIFRDUCBhIGZyaWVuZGx5IHRyYW5zcG9ydCBmb3IgYW4gYXBwbGljYXRpb24gcHJv dG9jb2wgbGlrZSBTUERZLg0KPiAJCQk+DQo+IAkJCT4gQmFja2dyb3VuZA0KPiAJCQk+IFVucmVs YXRlZCB0byBUQ1AsIEhUVFAgaXMgbm90IHZlcnkgZWZmaWNpZW50LiAgVGhpcyBoYXMgYmVlbiB3 aWRlbHkgZG9jdW1lbnRlZCBhbmQgb2JzZXJ2ZWQgZm9yDQo+IHNvbWUgdGltZS4gIFdlIGNhbiBl YXNpbHkNCj4gCQkJPiBkZW1vbnN0cmF0ZSBhIG1vcmUgZWZmaWNpZW50IHByb3RvY29sLCB3aGlj aCB0cmFuc2ZlcnMgMjUtMzUlIGZld2VyIHBhY2tldHMgdGhhbiBIVFRQIGFuZCByZWR1Y2VzDQo+ IGJ5dGVzIHRyYW5zZmVycmVkIGJ5DQo+IAkJCT4gMTAtMTUlLiAgSG9wZWZ1bGx5IGV2ZXJ5b25l IGFncmVlcyB0aG9zZSBhcmUgZ29vZCB0aGluZ3MgZm9yIHRoZSBuZXR3b3JrLg0KPiAJCQk+DQo+ IAkJCT4gVW5mb3J0dW5hdGVseSwgYW55IFRDUC1iYXNlZCBwcm90b2NvbCB3aGljaCB1c2VzIGEg c2luZ2xlIGNvbm5lY3Rpb24gaXMgYXQgYSBsYXRlbmN5LWhhbmRpY2FwDQo+IGNvbXBhcmVkIHRv IGFueSBwcm90b2NvbCB0aGF0DQo+IAkJCT4gdXNlcyBtdWx0aXBsZSBjb25uZWN0aW9ucy4gIFRo aXMgaXMgZHVlIHRvIElXLiAgRnVydGhlciwgYmVjYXVzZSBiYW5kd2lkdGggaW5jcmVhc2VzIGhh dmUgb3V0cGFjZWQNCj4gUlRUIGRlY3JlYXNlcywNCj4gCQkJPiBiYW5kd2lkdGggaXMgcmVsYXRp dmVseSBjaGVhcC4gIFNvLCBiZWluZyBlZmZpY2llbnQgb24geW91ciBiYW5kd2lkdGggaXMgbGVz cyBjcml0aWNhbCB0aGFuIGJlaW5nDQo+IGVmZmljaWVudCBvbiB5b3VyIHJvdW5kLXRyaXBzLg0K PiAJCQk+DQo+IA0KPiAJCQk+IFRvIHZpc3VhbGl6ZSB0aGUgZWZmZWN0cywgcGxlYXNlIHNlZSB0 aGUgYXR0YWNoZWQgZ3JhcGguICAoT3IgY2xpY2sgaGVyZQ0KPiA8aHR0cDovLzY1NDEwNzg1NzU3 OTk4NTMyODctYS1jaHJvbWl1bS1vcmctcy0NCj4gCQkJPg0KPiBzaXRlcy5nb29nbGVncm91cHMu Y29tL2EvY2hyb21pdW0ub3JnL2Rldi9zcGR5L2VmZmVjdF9vZl9pbml0aWFsX2N3bmRfb25fcGx0 KDEpLnBuZz9hdHRhY2hhdXRoPUFOb1k3Y3BtLXk1TkEtDQo+IAkJCT4gekZ2R3NteGxLODF2VWg1 NldzRmUtMmw1Qk9rWnhFTnVvcGdlVWNTbU85LQ0KPiAJCQk+DQo+IFFUOXNjNzg0eEZaTHcwUWtT QnhtREtnQ0x4V29WSTA2dnkxdTNhN1J1UzgyTmI2WXVUSFBHZXFVX1cxYzFuaUt4NVczQ3pLYnpz eG5HS2xRYWVjdHFHOGE3Y2pnNXZnVTFHajRjDQo+IAkJCT4NCj4gRkx0VGk3cktpS0hGMTJqX1hr QU5Jd1NNMHNhVmRvRjZjNmd0Q0RnMV84Z0tJbjhRUFZTVnA5Q3d0dzF1RlRUV3c5M1hGUFFrQW1F STJGdlJicTZJQmcxYUklM0QmYXR0cmVkaXJlY3QNCj4gCQkJPiBzPTA+ICkgIEluIHRoZXNlIHRl c3RzLCBJIGxvYWRlZCBhIHJlcGxpY2Egb2YgdGhlIGZhY2Vib29rIGxhbmRpbmcgcGFnZSB0aHJv dWdoIHR3byBwcm90b2NvbHMgLSBvbmUNCj4gdXNpbmcgYSBzaW5nbGUgY29ubmVjdGlvbiBpbg0K PiANCj4gCQkJPiBhIHNlbWktZWZmaWNpZW50IG1hbm5lciAoYW4gZWFybHkgdmVyc2lvbiBvZiBz cGR5KSBhbmQgYW5vdGhlciB1c2luZyA2IGNvbm5lY3Rpb25zIChodHRwKS4gIEkgdXNlZCBhDQo+ IGhpZ2gtYmFuZHdpZHRoIG5ldHdvcmsNCj4gCQkJPiB3aXRoIGVpdGhlciAxMDBtcyBvciAyMDBt cyBvZiBSVFQsIGFuZCB0aGVuIEkgdmFyaWVkIElXIGZyb20gMnBrdHMgYWxsIHRoZSB3YXkgdG8g MTI4cGt0cy4gIEkgY2hvc2UNCj4gdGhpcyBuZXR3b3JrDQo+IAkJCT4gY29uZmlndXJhdGlvbiB0 byBzcGVjaWZpY2FsbHkgaXNvbGF0ZSB0aGUgZWZmZWN0cyBvZiBoaWdoLVJUVCBhbmQgSVcuICBB cyB5b3UgY2FuIHNlZSwgYXQgbG93IElXLCB0aGUNCj4gc2luZ2xlLWNvbm5lY3Rpb24gcHJvdG9j b2wNCj4gCQkJPiBmYXJlcyBwb29ybHkgY29tcGFyZWQgdG8gdGhlIG11bHRpLWNvbm5lY3Rpb24g cHJvdG9jb2wuICAgRm9yIGFub3RoZXIgd3JpdGV1cCBvbiB0aGUgcHJvYmxlbSwgc2VlDQo+IAkJ CT4gaHR0cDovL2Rldi5jaHJvbWl1bS5vcmcvc3BkeS9Bbl9Bcmd1bWVudF9Gb3JfQ2hhbmdpbmdf VENQX1Nsb3dfU3RhcnQucGRmDQo+IAkJCT4NCj4gCQkJPiBUb2RheSwgdGhlIGZhc3Rlc3Qgd2F5 IHRvIGRlbGl2ZXIgY29udGVudCBpcyB0byBzaW1wbHkgc2lkZS1zdGVwIGN3bmQgYnkgdXNlIG9m IG11bHRpcGxlIGNvbm5lY3Rpb25zLg0KPiAJCQk+DQo+IAkJCT4NCj4gCQkJPiBUaGUgUHJvYmxl bQ0KPiAJCQk+IFdpdGggU1BEWSAob3Igd2hhdGV2ZXIgcHJvdG9jb2wgY29tZXMgbmV4dCksIHdl IGNhbiBkZWZpbml0ZWx5IHJlZHVjZSB0aGUgbnVtYmVyIG9mIGNvbm5lY3Rpb25zDQo+IG91dCBv ZiB0aGUgYnJvd3NlciBieSAqYXQNCj4gCQkJPiBsZWFzdCogYSBmYWN0b3Igb2YgNi4gIFdpdGgg dW5mb2xkaW5nIG9mIHRoZSBzdWJkb21haW4gdHJpY2tzIHRoYXQgd2Vic2l0ZXMgaGF2ZSBiZWVu IGRvaW5nLCB3ZSBjYW4NCj4gcmVkdWNlIGl0IGJ5IGEgZmFjdG9yIG9mDQo+IAkJCT4gMTAuICBU aGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggVENQLCBleGNlcHQgSSBob3BlIHRoYXQgZm9sa3Mg b24gdGhpcyBsaXN0IGFwcHJlY2lhdGUgdGhhdCB0aGlzIGdvb2RuZXNzOg0KPiBmZXdlciBjb25u ZWN0aW9ucyAtDQo+IAkJCT4gZmV3ZXIgcGFja2V0cyAtIGFuZCBmZXdlciBieXRlcy4NCj4gCQkJ Pg0KPiAJCQk+IFRoZSBvbmx5IHRyb3VibGUgaXMgdGhhdCBpZiB3ZSBhYmlkZSB0byB0aGUgUkZD cywgZmV3ZXIgY29ubmVjdGlvbnMgKyBmZXdlciBwYWNrZXRzICsgZmV3ZXIgYnl0ZXMNCj4gZXF1 YXRlcyB0byBzbG93ZXIgd2ViDQo+IAkJCT4gcGFnZXMuDQo+IAkJCT4NCj4gCQkJPiBCdXQgSSdt IG5vdCBhc2tpbmcgdGhhdCB3ZSBpbmNyZWFzZSBJVyBieSBhIGZhY3RvciBvZiAxMDsgYmVjYXVz ZSBpdCBncm93cyBleHBvbmVudGlhbGx5LCBpZiB3ZSBjYW4NCj4gaW5jcmVhc2UgaXQgdG8gc29t ZXdoZXJlDQo+IAkJCT4gaW4gdGhlIH4xNiByYW5nZSwgaXQncyBnb29kIGVub3VnaC4NCj4gCQkJ Pg0KPiAJCQk+DQo+IAkJCT4gVGhlIENvbnVuZHJ1bQ0KPiAJCQk+IE1vcmUgcGVycGxleGluZyBp cyB0aGF0IHdoZW5ldmVyIHdlIHRhbGsgYWJvdXQgaW5jcmVhc2luZyBJVywgd2UgdGVuZCB0byB0 aGluayBvZiB0aGUgc3RhdGljIHRocm90dGxlDQo+IHRoYXQgd2UgaGF2ZSB0b2RheS4gIElmDQo+ IAkJCT4gd2UgaW5jcmVhc2UgYSBzdGF0aWMgdGhyb3R0bGUsIGl0IGFmZmVjdHMgZXZlcnl0aGlu Zy4gIFNvIHByb3RvY29scyB0aGF0IGFyZSBhbHJlYWR5IGJ1cnN0aW5nIDIwLTMweA0KPiBtb3Jl IHBhY2tldHMgdGhhbiB0aGV5DQo+IAkJCT4gc2hvdWxkIChieSB3YXkgb2YgbWFueSBjb25uZWN0 aW9ucykgd2lsbCBidXJzdCBldmVuIG1vcmUuDQo+IAkJCT4NCj4gCQkJPiBUaGlzIG1ha2VzIHNv bWUgcGVvcGxlIHdhbnQgdG8gZG8gbm90aGluZy4uLg0KPiAJCQk+DQo+IAkJCT4gQXQgdGhlIHNh bWUgdGltZSwgd2UgYWxzbyBrbm93IHRoYXQgY3duZCBoYXMgYWxyZWFkeSBiZWVuIGluY3JlYXNl ZCBvbiB0aGUgbmV0IGF0IGxhcmdlLiAgIFRoaXMNCj4gc3RhcnRlZCB3aXRoIHVzZSBvZiBtdWx0 aXBsZQ0KPiAJCQk+IGNvbm5lY3Rpb25zLCBtdWx0aXBsaWVkIHdpdGggdGhlIHVzZSBvZiBtdWx0 aXBsZSBzdWJkb21haW5zLCBhbmQgaXMgbm93IGNoYW5naW5nIGJ5IG1ham9yIHNpdGVzDQo+IHNp bXBseSBpbmNyZWFzaW5nIG9yDQo+IAkJCT4gaWdub3JpbmcgY3duZCBhbHRvZ3RoZXIuICBXaXRo IHNvIG1hbnkgc2l0ZXMgc3lzdGVtYXRpY2FsbHkgd29ya2luZyBhcm91bmQgY3duZCwgd2Uga25v dyB0aGF0IHRoZQ0KPiBjdXJyZW50IGxpbWl0cyBjYW4gYmUNCj4gCQkJPiBpbmNyZWFzZWQuICBX ZSBqdXN0IGRvbid0IGtub3cgaG93IG11Y2guDQo+IAkJCT4NCj4gCQkJPg0KPiAJCQk+IFRoZSBT b2x1dGlvbj8NCj4gCQkJPiBJcyB0aGUgb2J2aW91cyBzb2x1dGlvbiB0byBzdG9wIHVzaW5nIGEg c3RhdGljIHZhbHVlPyAgSXQgZG9lc24ndCBzZWVtIGxpa2Ugd2UncmUgaW4gYSBvbmUtc2l6ZS1m aXRzLWFsbCBmb3INCj4gSVcuDQo+IAkJCT4NCj4gCQkJPiBUaGUgSVcgY291bGQgZWl0aGVyIGJl IGRlZmluZWQgdG8gYmUgcHJvdG9jb2wtc3BlY2lmaWMsIG9yIGR5bmFtaWMgYmFzZWQgb24gbnVt YmVyIG9mIFRDUCBmbG93cw0KPiBiZXR3ZWVuIHRoZSBzYW1lIHR3bw0KPiAJCQk+IGVuZHBvaW50 cy4gIEJvdGggb2YgdGhlc2UgYXBwcm9hY2hlcyB3b3VsZCBvZmZlciB0aGUgYmVuZWZpdCBvZiBh IGNvbnRyb2xsZWQsIGluY3JlYXNlZCBjd25kIHRvDQo+IHJlZmxlY3QgdGhlIGNoYW5nZXMgaW4g dGhlIG5ldA0KPiAJCQk+IG92ZXIgdGhlIGxhc3QgMiBkZWNhZGVzIGJ1dCBhbHNvIG5vdCBjb21w bGV0ZWx5IHVudGhyb3R0bGUgcHJvdG9jb2xzIHRoYXQgYXJlIGFscmVhZHkgbGl2aW5nIG9uIHRo ZQ0KPiBlZGdlIG9mIG5vdCBoYXZpbmcNCj4gCQkJPiB0aHJvdHRsZXMuDQo+IAkJCT4NCj4gCQkJ PiBGaW5hbGx5LCBpZiBhIGR5bmFtaWMgdGhyb3R0bGUgaXMgdG9vIG11Y2ggdG8gZGVjaWRlIHVw b24sIGF0IGxlYXN0IHVwZGF0aW5nIHRoZSBzdGF0aWMgdmFsdWUgc2VlbXMNCj4gYXBwcm9wcmlh dGUuICBKZXJycnkgYW5kDQo+IAkJCT4gTmFuZGl0YSBoYXZlIHByb3ZpZGVkIGdvb2QgZGF0YSBm b3IgYSBnZW5lcmFsLXB1cnBvc2UgaW5jcmVhc2UgdG8gMTAuICBJZiBpbmVmZmljaWVudCBwcm90 b2NvbHMgYXJlDQo+IGFsbG93ZWQgdG8gZ28gdGhhdCBoaWdoLA0KPiAJCQk+IG1heWJlIG1vcmUg ZWZmaWNpZW50IHByb3RvY29scyBjb3VsZCBiZSBhbGxvd2VkIHRvIGdvIGhpZ2hlciAod2l0aCBk YXRhLCBvZiBjb3Vyc2UpLg0KPiAJCQk+DQo+IAkJCT4NCj4gCQkJPiBSZWFsaXR5IENoZWNrDQo+ IAkJCT4gRmluYWxseSwgcmVnYXJkbGVzcyBvZiB0aGlzIGRlYmF0ZSBpbiB0aGUgSUVURiwgd2hh dCBpcyBhY3R1YWxseSBnb2luZyB0byBoYXBwZW4/DQo+IAkJCT4NCj4gCQkJPiBhKSBJRVRGIGRv ZXMgbm90IGluY3JlYXNlIHRoZSBsaW1pdCAob3IgY29udGludWVzIHRvIHdhaXQpOg0KPiAJCQk+ IEFzIHRpbWUgZ29lcyBvbiwgbW9yZSBhbmQgbW9yZSBldmlkZW5jZSBlbWVyZ2VzIHRvIGRlbW9u c3RyYXRlIHRoYXQgdGhlIGN1cnJlbnQgY3duZCBsaW1pdHMgYXJlDQo+IHVubmVjZXNzYXJpbHkN Cj4gCQkJPiBjb25zZXJ2YXRpdmUuICBNb3JlIGV2aWRlbmNlIGFsc28gZW1lcmdlcyB0aGF0IGlu Y3JlYXNpbmcgY3duZCBtYWtlcyB5b3VyIHNpdGUgZmFzdGVyLiAgTW9yZSBzaXRlcw0KPiBzdGFy dCBleHBlcmltZW50aW5nIHdpdGgNCj4gCQkJPiB0aGVpciBvd24gdmFsdWVzIG9mIGN3bmQuICBX aXRob3V0IGEgYmxlc3NlZCByZWNvbW1lbmRhdGlvbiBmcm9tIHRoZSBJRVRGLCBzaXRlcyBjaG9v c2Ugd2hhdGV2ZXINCj4gdmFsdWVzIHRoZXkgd2FudC4gQmVuDQo+IA0KPiAJCQk+IFN0cm9uZyBv ZmZlcmVkIGEgd3JpdGV1cCB0b2RheSB3aGljaCBkZW1vbnN0cmF0ZXMgdGhpcyBpcyBhbHJlYWR5 IGhhcHBlbmluZw0KPiA8aHR0cDovL2Jsb2cuYmVuc3Ryb25nLmNvbS8yMDEwLzExL2dvb2dsZS0N Cj4gCQkJPiBhbmQtbWljcm9zb2Z0LWNoZWF0LW9uLXNsb3cuaHRtbD4gLg0KPiANCj4gCQkJPg0K PiAJCQk+IGIpIElFVEYgaW5jcmVhc2VzIHRoZSBsaW1pdDoNCj4gCQkJPiBXaXRoIGRhdGEgYW5k IGEgc3BlY2lmaWMgcmVjb21tZW5kYXRpb24sIFRDUCB2ZW5kb3JzIGNhbiBxdWlja2x5IG1vdmUg dG8gdGhlIG5ldw0KPiByZWNvbW1lbmRhdGlvbnMsIG1ha2luZyB0aGVpcg0KPiAJCQk+IHByb2R1 Y3RzIG1vcmUgY29tcGV0aXRpdmUgaW4gdGhlIG1hcmtldHBsYWNlLCBhbmQgYmV0dGVyIGZvciB1 c2Vycy4gIFByZXNzdXJlIGlzIGFsbGV2aWF0ZWQgZnJvbQ0KPiBleGlzdGluZyBzaXRlcyB0byBn bw0KPiAJCQk+IHJlbmVnYWRlLCBhbmQgaW5zdGVhZCB0aGV5IGNhbiByZXN0IG9uIHRoZSBzcGVj aWZpYyBmaW5kaW5ncyBmcm9tIHRoaXMgZ3JvdXAuICBXaXRoIGEgbW9kZXJuDQo+IHJlY29tbWVu ZGF0aW9uIGluIGhhbmQsIGFsbCBvZg0KPiAJCQk+IHVzIGNhbiBjcmVkaWJseSBnbyBhZnRlciBh bnkgc2l0ZXMgd2hpY2ggZG8gY2hvb3NlIHRvIHVzZSBkYW5nZXJvdXNseSBoaWdoIGN3bmQgdmFs dWVzLiAgRmluYWxseSwNCj4gaGF2aW5nIGFuIG9mZmljaWFsbHkNCj4gCQkJPiBpbmNyZWFzZWQg SVcgaXMgYW4gZW5hYmxlciBmb3IgYSBmdXR1cmUgb2YgbW9yZSBlZmZpY2llbnQgYXBwbGljYXRp b24gbGV2ZWwgcHJvdG9jb2xzLCB3aGljaCBhcmUNCj4gY3VycmVudGx5IGF0IGEgZGlzYWR2YW50 YWdlIHRvDQo+IAkJCT4gdGhlaXIgbGVzcy1lZmZpY2llbnQgY291bnRlcnBhcnRzLg0KPiAJCQk+ DQo+IAkJCT4NCj4gCQkJPg0KPiAJCQk+DQo+IAkJCT4gTm93LCB3aGljaCBvZiB0aGVzZSB0d28g b3B0aW9ucyBjYXJyaWVzIG1vcmUgcmlzayBvZiBpbnRlcm5ldCBjb2xsYXBzZT8gIFZlbmRvcnMg aW1wbGVtZW50aW5nDQo+IHdoYXRldmVyLXRoZS1oZWNrLXRoZWlyLQ0KPiAJCQk+IHJvb2tpZS1z eXN0ZW0tYWRtaW5pc3RyYXRvciBkZWNpZGVkIHRvIGNvbmZpZ3VyZT8gIE9yIGFuIG9mZmljaWFs LCBjb250cm9sbGVkIGFuZCBpbnRlbGxpZ2VudA0KPiByZWNvbW1lbmRhdGlvbiBmcm9tIHRoaXMN Cj4gCQkJPiBncm91cD8NCj4gCQkJPg0KPiAJCQk+DQo+IAkJCT4gVGhhbmtzIHRvIGV2ZXJ5b25l IG9uIHRoaXMgbGlzdCBmb3IgdGhlaXIgaGFyZCB3b3JrIG92ZXIgdGhlIHllYXJzIC0gYWx0aG91 Z2ggbXkgZW1haWwgaXMgc29tZXdoYXQNCj4gY3JpdGljYWwsIGJlIGF3YXJlIHRoYXQgSQ0KPiAJ CQk+IGhhdmUgaW1tZW5zZSBncmF0aXR1ZGUgYW5kIHJlc3BlY3QgZm9yIHRoZSB2ZXRlcmFucyBv ZiB0aGlzIGxpc3QgdGhhdCBoYXZlIGJlZW4ga2VlcGluZyB0aGUgbmV0DQo+IGZsb3dpbmcgZm9y IHNvIGxvbmcgd2l0aCBzdWNoDQo+IAkJCT4gZ3JlYXQgc3VjY2Vzcy4NCj4gCQkJPiBNaWtlDQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g DQo+IA0KPiANCj4gCQlfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiAJCXRjcG0gbWFpbGluZyBsaXN0DQo+IAkJdGNwbUBpZXRmLm9yZw0KPiAJCWh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiANCj4gDQo+IA0KPiANCg0K From abegen@cisco.com Mon Nov 29 05:02:22 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7083A6BFF for ; Mon, 29 Nov 2010 05:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.01 X-Spam-Level: X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[AWL=-2.192, BAYES_50=0.001, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggFaA58rw04s for ; Mon, 29 Nov 2010 05:02:21 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 378CB3A6C09 for ; Mon, 29 Nov 2010 05:02:21 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkDABcz80yrR7Ht/2dsb2JhbACUPY5Bcac6inKPeYVHBIRciRo X-IronPort-AV: E=Sophos;i="4.59,275,1288569600"; d="scan'208";a="385505885" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 29 Nov 2010 13:03:30 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oATD3UuP016231; Mon, 29 Nov 2010 13:03:30 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Nov 2010 05:03:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Nov 2010 05:03:27 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DC93006@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] A Challenge to TCPM Thread-Index: AcuPkToMpQANtTwqRfGEf9mT6mRPRQAMn7sQ References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Mike Belshe" X-OriginalArrivalTime: 29 Nov 2010 13:03:30.0555 (UTC) FILETIME=[D20C6CB0:01CB8FC5] Cc: tcpm@ietf.org Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 13:02:22 -0000 > -----Original Message----- > From: Mike Belshe [mailto:mike@belshe.com] > Sent: Monday, November 29, 2010 1:47 AM > To: Ali C. Begen (abegen) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] A Challenge to TCPM >=20 > On Sat, Nov 27, 2010 at 12:34 PM, Ali C. Begen (abegen) = wrote: >=20 >=20 > I agree with some of the claims you are making below, and I don't = agree with some. I just wanna point out one thing, > though. You are largely dismissing the #1 reason why applications are = often using more than 1 TCP connection. It is not often > about the tput. It is often (more than often actually) about the delay = (among a few other reasons), which is critical for short- > lived transactions. >=20 >=20 >=20 > Actually, that was my whole point. The only way to get the latency = down is to avoid cwnd, and multiple connections are an > easy trick to accomplish just that. I don't agree with this. =20 > You can increase the IW to 100 for all I care but TCP will still have = to leave with the HOL blocking issue. IETF can > make a recommendation on IW but I have serious doubts about TCP = vendors quickly adopting as you suggest. As for the > number of TCP connections in parallel, that is not easy to place a = policy anyway. >=20 >=20 >=20 > That is a separate issue and generally less severe than the cwnd = issue. I could provide more color about SCTP, HOL and other > issues, but I really don't want to derail this thread to be about = anything other than TCP's initial cwnd setting. I don't wanna hijack this thread, either but saying that increasing IW = will fix the delay issues is something I don=92t agree with it. I am not objecting to increase IW. As I said you can increase it to 100 = for all I care: if an app still wants low latency in certain conditions, = it will open a new TCP connection. You cannot fix that problem and avoid = that problem with IW. =20 > We need to decide if we think an application protocol should be able = to be both a low-latency protocol, and based on TCP. If > you think that should be possible, then we seriously need to consider = changing IW. The reasons not to change it, would be if > you thought it would kill the net - but, I there is no evidence of = that, especially if we consider which protocols get which > limits. I don't think it would kill the net. Yet, I don=92t think your = motivation is justified at least for the apps and scenarios I am = interested in, which might be of course different from yours. >=20 >=20 > Maybe, trying to fix TCP to make HTTP is not the best strategy here. >=20 >=20 >=20 > Are you saying HTTP should move to a new transport? That seems like a = shame. One could try fixing HTTP or try to find a better transport alternative. = Neither is a shame. Just because it was designed so, it does not mean = that we need to stick with it forever. -acbegen =20 > Mike >=20 >=20 >=20 >=20 > -acbegen >=20 >=20 > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On = Behalf Of Mike Belshe > > Sent: Friday, November 26, 2010 1:11 PM > > To: tcpm@ietf.org > > Subject: [tcpm] A Challenge to TCPM > > > > Hi, > > > > I thought I'd add a slightly different perspective to the = discussion about initial cwnd. I'm a developer on Chrome & > SPDY. > > > > With SPDY, we want to build an application protocol which is = efficient on the transport, good for the network, and > faster than > > HTTP. But right now, TCP is holding us back because we're trying = to accomplish with one connection what HTTP > does with > > 10+ connections. > > > > Note: I don't want to make this thread about SPDY. I hope the = members of this list agree that the goals of SPDY are > good > > and will help make TCP a friendly transport for an application = protocol like SPDY. > > > > Background > > Unrelated to TCP, HTTP is not very efficient. This has been widely = documented and observed for some time. We > can easily > > demonstrate a more efficient protocol, which transfers 25-35% fewer = packets than HTTP and reduces bytes > transferred by > > 10-15%. Hopefully everyone agrees those are good things for the = network. > > > > Unfortunately, any TCP-based protocol which uses a single = connection is at a latency-handicap compared to any > protocol that > > uses multiple connections. This is due to IW. Further, because = bandwidth increases have outpaced RTT decreases, > > bandwidth is relatively cheap. So, being efficient on your = bandwidth is less critical than being efficient on your > round-trips. > > >=20 > > To visualize the effects, please see the attached graph. (Or click = here org-s- > > = sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initial_cwnd_on_= plt(1).png?attachauth=3DANoY7cpm- > y5NA- > > zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9- > > > = QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3CzKbz= sxnGKlQaectqG8a7cjg5vgU1Gj4c > > > = FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFPQkA= mEI2FvRbq6IBg1aI%3D&attredirect > > s=3D0> ) In these tests, I loaded a replica of the facebook = landing page through two protocols - one using a single > connection in >=20 > > a semi-efficient manner (an early version of spdy) and another = using 6 connections (http). I used a high-bandwidth > network > > with either 100ms or 200ms of RTT, and then I varied IW from 2pkts = all the way to 128pkts. I chose this network > > configuration to specifically isolate the effects of high-RTT and = IW. As you can see, at low IW, the single-connection > protocol > > fares poorly compared to the multi-connection protocol. For = another writeup on the problem, see > > = http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf > > > > Today, the fastest way to deliver content is to simply side-step = cwnd by use of multiple connections. > > > > > > The Problem > > With SPDY (or whatever protocol comes next), we can definitely = reduce the number of connections out of the > browser by *at > > least* a factor of 6. With unfolding of the subdomain tricks that = websites have been doing, we can reduce it by a > factor of > > 10. This has nothing to do with TCP, except I hope that folks on = this list appreciate that this goodness: fewer > connections - > > fewer packets - and fewer bytes. > > > > The only trouble is that if we abide to the RFCs, fewer connections = + fewer packets + fewer bytes equates to slower > web > > pages. > > > > But I'm not asking that we increase IW by a factor of 10; because = it grows exponentially, if we can increase it to > somewhere > > in the ~16 range, it's good enough. > > > > > > The Conundrum > > More perplexing is that whenever we talk about increasing IW, we = tend to think of the static throttle that we have > today. If > > we increase a static throttle, it affects everything. So protocols = that are already bursting 20-30x more packets than > they > > should (by way of many connections) will burst even more. > > > > This makes some people want to do nothing... > > > > At the same time, we also know that cwnd has already been increased = on the net at large. This started with use of > multiple > > connections, multiplied with the use of multiple subdomains, and is = now changing by major sites simply increasing > or > > ignoring cwnd altogther. With so many sites systematically working = around cwnd, we know that the current limits > can be > > increased. We just don't know how much. > > > > > > The Solution? > > Is the obvious solution to stop using a static value? It doesn't = seem like we're in a one-size-fits-all for IW. > > > > The IW could either be defined to be protocol-specific, or dynamic = based on number of TCP flows between the same > two > > endpoints. Both of these approaches would offer the benefit of a = controlled, increased cwnd to reflect the changes > in the net > > over the last 2 decades but also not completely unthrottle = protocols that are already living on the edge of not > having > > throttles. > > > > Finally, if a dynamic throttle is too much to decide upon, at least = updating the static value seems appropriate. > Jerrry and > > Nandita have provided good data for a general-purpose increase to = 10. If inefficient protocols are allowed to go > that high, > > maybe more efficient protocols could be allowed to go higher (with = data, of course). > > > > > > Reality Check > > Finally, regardless of this debate in the IETF, what is actually = going to happen? > > > > a) IETF does not increase the limit (or continues to wait): > > As time goes on, more and more evidence emerges to demonstrate that = the current cwnd limits are unnecessarily > > conservative. More evidence also emerges that increasing cwnd = makes your site faster. More sites start > experimenting with > > their own values of cwnd. Without a blessed recommendation from = the IETF, sites choose whatever values they > want. Ben >=20 > > Strong offered a writeup today which demonstrates this is already = happening > > and-microsoft-cheat-on-slow.html> . >=20 > > > > b) IETF increases the limit: > > With data and a specific recommendation, TCP vendors can quickly = move to the new recommendations, making > their > > products more competitive in the marketplace, and better for users. = Pressure is alleviated from existing sites to go > > renegade, and instead they can rest on the specific findings from = this group. With a modern recommendation in > hand, all of > > us can credibly go after any sites which do choose to use = dangerously high cwnd values. Finally, having an officially > > increased IW is an enabler for a future of more efficient = application level protocols, which are currently at a > disadvantage to > > their less-efficient counterparts. > > > > > > > > > > Now, which of these two options carries more risk of internet = collapse? Vendors implementing whatever-the-heck- > their- > > rookie-system-administrator decided to configure? Or an official, = controlled and intelligent recommendation from > this > > group? > > > > > > Thanks to everyone on this list for their hard work over the years = - although my email is somewhat critical, be > aware that I > > have immense gratitude and respect for the veterans of this list = that have been keeping the net flowing for so long > with such > > great success. > > Mike >=20 >=20 From ycheng@google.com Mon Nov 29 21:48:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E253A6C5A for ; Mon, 29 Nov 2010 21:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.901 X-Spam-Level: X-Spam-Status: No, score=-109.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CALeqhRTGW7g for ; Mon, 29 Nov 2010 21:48:37 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A2E0328C152 for ; Mon, 29 Nov 2010 21:48:32 -0800 (PST) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id oAU5nfPT002315 for ; Mon, 29 Nov 2010 21:49:41 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291096181; bh=lDb9UHKE02T7XqsUoCxgZFTYQ8s=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=fohiUka8uwlcDk+AQy8SPoCmYDOuOwpM8ckV2geVxXL2ksSoeyfr3OI26oHcx5HWr odfTP+7ix9doDIAKY7xXA== Received: from qwj8 (qwj8.prod.google.com [10.241.195.72]) by kpbe15.cbf.corp.google.com with ESMTP id oAU5ndp6025078 for ; Mon, 29 Nov 2010 21:49:40 -0800 Received: by qwj8 with SMTP id 8so1115310qwj.15 for ; Mon, 29 Nov 2010 21:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=qVKBT1E4ahhNJWnMX3Su9Dt6SnzOpXJX8rF67zq9vyA=; b=bYLdKm1jwXUOxWVwrOueTUQaXWkSF3v+QpYBWyLxH955zNIwpcXw1Gwt6oOVE+jbyg 6X/fcwh7g0b3uhwolY9A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=fJsMrRleJVbOJ3lO/C5xLrXhGbayOITeuOu6lYwz8i942Y0acDBYpIe57r6R9+JHbz Fza9/hbLzqUUW4zNpQSA== Received: by 10.229.241.194 with SMTP id lf2mr5685799qcb.164.1291096177728; Mon, 29 Nov 2010 21:49:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.159.66 with HTTP; Mon, 29 Nov 2010 21:49:17 -0800 (PST) In-Reply-To: <4CF26596.7010500@isi.edu> References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <4CF26596.7010500@isi.edu> From: Yuchung Cheng Date: Mon, 29 Nov 2010 21:49:17 -0800 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=0016364d2b890b5e9704963ec143 X-System-Of-Record: true Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 05:48:40 -0000 --0016364d2b890b5e9704963ec143 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 28, 2010 at 6:22 AM, Joe Touch wrote: > > Jerry, > > In short: > > a) the receive window is an indication of the receiver's ability to reorder > out-of-order packets; it limits what is sent primarily to avoid useless > transmissions that the receiver will drop, not as a congestion control > mechanism > > yes, I find it odd that you are injecting control of the > receive window to correct for IW issues in your draft > > 2) NO AMOUNT of in-connection adjustment of CWND has any effect on the > impact of a poor choice of IW > > consider that if this were not true, then you would > not need to propose a new IW value; just as you do not > want to wait for the connection to converge, I am > concerned about the network impact until that convergence > same argument holds for caching cwnd on a per-host or per prefix basis. > > I have made the second point repeatedly. It would be useful to know if your > continued misdirection of the issue is because don't agree with it, or some > other reason. > > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0016364d2b890b5e9704963ec143 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Nov 28, 2010 at 6:22 AM, Joe Tou= ch <touch@isi.edu= > wrote:

Jerry,

In short:

a) the receive window is an indication of the receiver's ability to reo= rder out-of-order packets; it limits what is sent primarily to avoid useles= s transmissions that the receiver will drop, not as a congestion control me= chanism

=A0 =A0 =A0 =A0yes, I find it odd that you are injecting control of the =A0 =A0 =A0 =A0receive window to correct for IW issues in your draft

2) NO AMOUNT of in-connection adjustment of CWND has any effect on =A0the i= mpact of a poor choice of IW

=A0 =A0 =A0 =A0consider that if this were not true, then you would
=A0 =A0 =A0 =A0not need to propose a new IW value; just as you do not
=A0 =A0 =A0 =A0want to wait for the connection to converge, I am
=A0 =A0 =A0 =A0concerned about the network impact until that convergence

same argument holds for caching cwnd on = a per-host or per prefix basis.
=A0

I have made the second point repeatedly. It would be useful to know if your= continued misdirection of the issue is because don't agree with it, or= some other reason.


Joe

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

--0016364d2b890b5e9704963ec143-- From ycheng@google.com Mon Nov 29 22:18:49 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14E528C16D for ; Mon, 29 Nov 2010 22:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.886 X-Spam-Level: X-Spam-Status: No, score=-104.886 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaH1R+wE9KJ8 for ; Mon, 29 Nov 2010 22:18:46 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 935E828C135 for ; Mon, 29 Nov 2010 22:18:45 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id oAU6JtNm017238 for ; Mon, 29 Nov 2010 22:19:56 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291097996; bh=wXGsEMvKDXjIg5W3f1mwhwNbnRs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=c/2spA8HJI2NGZq2I8g2A0u3uBUCyfXB3ON8EnVem48r3SFKJZvC1pWr35T0/NiVU 0XQaq/nnvudGNFE5G846A== Received: from qyk10 (qyk10.prod.google.com [10.241.83.138]) by kpbe14.cbf.corp.google.com with ESMTP id oAU6JseR011038 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 29 Nov 2010 22:19:54 -0800 Received: by qyk10 with SMTP id 10so890424qyk.15 for ; Mon, 29 Nov 2010 22:19:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=7yAbZE6KeGer/4AzQ2JDipAjzyyQPpKKm0NtH/AVcTM=; b=vi2yLU8gvHvflHu8mL+cGUD0antcfcsImxqh7dZfEEjM6vyBYpi4la4VI4V1TMOExT aCNgoHxuithS0b7B4OJg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=bo/9V7B6DCHjMESyNjxB1fReEw/GEenwh1zgohSHkM72IU6kVonxVUowq/DDSphzzb 458qaqR2Yg5lwZt6KMKw== Received: by 10.224.11.149 with SMTP id t21mr6342460qat.9.1291097994154; Mon, 29 Nov 2010 22:19:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.159.66 with HTTP; Mon, 29 Nov 2010 22:19:33 -0800 (PST) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DC93006@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540DC93006@xmb-sjc-215.amer.cisco.com> From: Yuchung Cheng Date: Mon, 29 Nov 2010 22:19:33 -0800 Message-ID: To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=0015175cb8204fd3b104963f2d2f X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 06:18:50 -0000 --0015175cb8204fd3b104963f2d2f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think Ali and Mike are both right. Multiple connections are easy app work-around for both TCP single-threaded model and slow-start slowness to improve HTTP performance. Since it's one stone for two birds, sites (by putting objects on subdomains) and browsers work together to open a lot connections. Which problem is more severe for HTTP performance? I don't hav= e any data. But I do know IW10 helps the second problem and maybe a little bi= t on the first, and is a simple change in TCP. Yuchung On Mon, Nov 29, 2010 at 5:03 AM, Ali C. Begen (abegen) wr= ote: > > > > -----Original Message----- > > From: Mike Belshe [mailto:mike@belshe.com] > > Sent: Monday, November 29, 2010 1:47 AM > > To: Ali C. Begen (abegen) > > Cc: tcpm@ietf.org > > Subject: Re: [tcpm] A Challenge to TCPM > > > > On Sat, Nov 27, 2010 at 12:34 PM, Ali C. Begen (abegen) < > abegen@cisco.com> wrote: > > > > > > I agree with some of the claims you are making below, and I don't > agree with some. I just wanna point out one thing, > > though. You are largely dismissing the #1 reason why applications are > often using more than 1 TCP connection. It is not often > > about the tput. It is often (more than often actually) about the delay > (among a few other reasons), which is critical for short- > > lived transactions. > > > > > > > > Actually, that was my whole point. The only way to get the latency dow= n > is to avoid cwnd, and multiple connections are an > > easy trick to accomplish just that. > > I don't agree with this. > > > You can increase the IW to 100 for all I care but TCP will still > have to leave with the HOL blocking issue. IETF can > > make a recommendation on IW but I have serious doubts about TCP vendors > quickly adopting as you suggest. As for the > > number of TCP connections in parallel, that is not easy to place a poli= cy > anyway. > > > > > > > > That is a separate issue and generally less severe than the cwnd issue. > I could provide more color about SCTP, HOL and other > > issues, but I really don't want to derail this thread to be about > anything other than TCP's initial cwnd setting. > > I don't wanna hijack this thread, either but saying that increasing IW wi= ll > fix the delay issues is something I don=92t agree with it. > > I am not objecting to increase IW. As I said you can increase it to 100 f= or > all I care: if an app still wants low latency in certain conditions, it w= ill > open a new TCP connection. You cannot fix that problem and avoid that > problem with IW. > > > We need to decide if we think an application protocol should be able to > be both a low-latency protocol, and based on TCP. If > > you think that should be possible, then we seriously need to consider > changing IW. The reasons not to change it, would be if > > you thought it would kill the net - but, I there is no evidence of that= , > especially if we consider which protocols get which > > limits. > > I don't think it would kill the net. Yet, I don=92t think your motivation= is > justified at least for the apps and scenarios I am interested in, which > might be of course different from yours. > > > > > > > Maybe, trying to fix TCP to make HTTP is not the best strategy > here. > > > > > > > > Are you saying HTTP should move to a new transport? That seems like a > shame. > > One could try fixing HTTP or try to find a better transport alternative. > Neither is a shame. Just because it was designed so, it does not mean tha= t > we need to stick with it forever. > > -acbegen > > > Mike > > > > > > > > > > -acbegen > > > > > > > -----Original Message----- > > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Mike Belshe > > > Sent: Friday, November 26, 2010 1:11 PM > > > To: tcpm@ietf.org > > > Subject: [tcpm] A Challenge to TCPM > > > > > > Hi, > > > > > > I thought I'd add a slightly different perspective to the > discussion about initial cwnd. I'm a developer on Chrome & > > SPDY. > > > > > > With SPDY, we want to build an application protocol which is > efficient on the transport, good for the network, and > > faster than > > > HTTP. But right now, TCP is holding us back because we're tryi= ng > to accomplish with one connection what HTTP > > does with > > > 10+ connections. > > > > > > Note: I don't want to make this thread about SPDY. I hope the > members of this list agree that the goals of SPDY are > > good > > > and will help make TCP a friendly transport for an application > protocol like SPDY. > > > > > > Background > > > Unrelated to TCP, HTTP is not very efficient. This has been > widely documented and observed for some time. We > > can easily > > > demonstrate a more efficient protocol, which transfers 25-35% > fewer packets than HTTP and reduces bytes > > transferred by > > > 10-15%. Hopefully everyone agrees those are good things for th= e > network. > > > > > > Unfortunately, any TCP-based protocol which uses a single > connection is at a latency-handicap compared to any > > protocol that > > > uses multiple connections. This is due to IW. Further, becaus= e > bandwidth increases have outpaced RTT decreases, > > > bandwidth is relatively cheap. So, being efficient on your > bandwidth is less critical than being efficient on your > > round-trips. > > > > > > > > To visualize the effects, please see the attached graph. (Or > click here > org-s- > > > > sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initial_cwnd_on_= plt(1).png?attachauth=3DANoY7cpm- > > y5NA- > > > zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9- > > > > > > QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3CzKbz= sxnGKlQaectqG8a7cjg5vgU1Gj4c > > > > > > FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFPQkA= mEI2FvRbq6IBg1aI%3D&attredirect > > > s=3D0> ) In these tests, I loaded a replica of the facebook > landing page through two protocols - one using a single > > connection in > > > > > a semi-efficient manner (an early version of spdy) and another > using 6 connections (http). I used a high-bandwidth > > network > > > with either 100ms or 200ms of RTT, and then I varied IW from > 2pkts all the way to 128pkts. I chose this network > > > configuration to specifically isolate the effects of high-RTT a= nd > IW. As you can see, at low IW, the single-connection > > protocol > > > fares poorly compared to the multi-connection protocol. For > another writeup on the problem, see > > > > http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf > > > > > > Today, the fastest way to deliver content is to simply side-ste= p > cwnd by use of multiple connections. > > > > > > > > > The Problem > > > With SPDY (or whatever protocol comes next), we can definitely > reduce the number of connections out of the > > browser by *at > > > least* a factor of 6. With unfolding of the subdomain tricks > that websites have been doing, we can reduce it by a > > factor of > > > 10. This has nothing to do with TCP, except I hope that folks = on > this list appreciate that this goodness: fewer > > connections - > > > fewer packets - and fewer bytes. > > > > > > The only trouble is that if we abide to the RFCs, fewer > connections + fewer packets + fewer bytes equates to slower > > web > > > pages. > > > > > > But I'm not asking that we increase IW by a factor of 10; becau= se > it grows exponentially, if we can increase it to > > somewhere > > > in the ~16 range, it's good enough. > > > > > > > > > The Conundrum > > > More perplexing is that whenever we talk about increasing IW, w= e > tend to think of the static throttle that we have > > today. If > > > we increase a static throttle, it affects everything. So > protocols that are already bursting 20-30x more packets than > > they > > > should (by way of many connections) will burst even more. > > > > > > This makes some people want to do nothing... > > > > > > At the same time, we also know that cwnd has already been > increased on the net at large. This started with use of > > multiple > > > connections, multiplied with the use of multiple subdomains, an= d > is now changing by major sites simply increasing > > or > > > ignoring cwnd altogther. With so many sites systematically > working around cwnd, we know that the current limits > > can be > > > increased. We just don't know how much. > > > > > > > > > The Solution? > > > Is the obvious solution to stop using a static value? It doesn= 't > seem like we're in a one-size-fits-all for IW. > > > > > > The IW could either be defined to be protocol-specific, or > dynamic based on number of TCP flows between the same > > two > > > endpoints. Both of these approaches would offer the benefit of= a > controlled, increased cwnd to reflect the changes > > in the net > > > over the last 2 decades but also not completely unthrottle > protocols that are already living on the edge of not > > having > > > throttles. > > > > > > Finally, if a dynamic throttle is too much to decide upon, at > least updating the static value seems appropriate. > > Jerrry and > > > Nandita have provided good data for a general-purpose increase = to > 10. If inefficient protocols are allowed to go > > that high, > > > maybe more efficient protocols could be allowed to go higher > (with data, of course). > > > > > > > > > Reality Check > > > Finally, regardless of this debate in the IETF, what is actuall= y > going to happen? > > > > > > a) IETF does not increase the limit (or continues to wait): > > > As time goes on, more and more evidence emerges to demonstrate > that the current cwnd limits are unnecessarily > > > conservative. More evidence also emerges that increasing cwnd > makes your site faster. More sites start > > experimenting with > > > their own values of cwnd. Without a blessed recommendation fro= m > the IETF, sites choose whatever values they > > want. Ben > > > > > Strong offered a writeup today which demonstrates this is alrea= dy > happening > > > > and-microsoft-cheat-on-slow.html> . > > > > > > > > b) IETF increases the limit: > > > With data and a specific recommendation, TCP vendors can quickl= y > move to the new recommendations, making > > their > > > products more competitive in the marketplace, and better for > users. Pressure is alleviated from existing sites to go > > > renegade, and instead they can rest on the specific findings fr= om > this group. With a modern recommendation in > > hand, all of > > > us can credibly go after any sites which do choose to use > dangerously high cwnd values. Finally, having an officially > > > increased IW is an enabler for a future of more efficient > application level protocols, which are currently at a > > disadvantage to > > > their less-efficient counterparts. > > > > > > > > > > > > > > > Now, which of these two options carries more risk of internet > collapse? Vendors implementing whatever-the-heck- > > their- > > > rookie-system-administrator decided to configure? Or an > official, controlled and intelligent recommendation from > > this > > > group? > > > > > > > > > Thanks to everyone on this list for their hard work over the > years - although my email is somewhat critical, be > > aware that I > > > have immense gratitude and respect for the veterans of this lis= t > that have been keeping the net flowing for so long > > with such > > > great success. > > > Mike > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0015175cb8204fd3b104963f2d2f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think Ali and Mike=A0are both right. Multiple connections are easy app wo= rk-around for both TCP single-threaded model and slow-start slowness to imp= rove HTTP performance. Since it's one stone for two birds, sites (by pu= tting objects on subdomains) and browsers work together to open a lot conne= ctions. Which problem is more severe for HTTP performance? I don't have= any data. But I do know IW10 helps the second problem and maybe a little b= it on the first, and is a simple change in TCP.

Yuchung


On M= on, Nov 29, 2010 at 5:03 AM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:


> -----Original Message-----
> From: Mike Belshe [mailto:mike@bels= he.com]
> Sent: Monday, November 29, 2010 1:47 AM
> To: Ali C. Begen (abegen)
> Cc: tcpm@ietf= .org
> Subject: Re: [tcpm] A Challenge to TCPM
>
> On Sat, Nov 27, 2010 at 12:34 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:
>
>
> =A0 =A0 =A0 I agree with some of the claims you are making below, and = I don't agree with some. I just wanna point out one thing,
> though. You are largely dismissing the #1 reason why applications are = often using more than 1 TCP connection. It is not often
> about the tput. It is often (more than often actually) about the delay= (among a few other reasons), which is critical for short-
> lived transactions.
>
>
>
> Actually, that was my whole point. =A0The only way to get the latency = down is to avoid cwnd, and multiple connections are an
> easy trick to accomplish just that.

I don't agree with this.

> =A0 =A0 =A0 You can increase the IW to 100 for all I care but TCP will= still have to leave with the HOL blocking issue. IETF can
> make a recommendation on IW but I have serious doubts about TCP vendor= s quickly adopting as you suggest. As for the
> number of TCP connections in parallel, that is not easy to place a pol= icy anyway.
>
>
>
> That is a separate issue and generally less severe than the cwnd issue= . =A0I could provide more color about SCTP, HOL and other
> issues, but I really don't want to derail this thread to be about = anything other than TCP's initial cwnd setting.

I don't wanna hijack this thread, either but saying that increasi= ng IW will fix the delay issues is something I don=92t agree with it.

I am not objecting to increase IW. As I said you can increase it to 100 for= all I care: if an app still wants low latency in certain conditions, it wi= ll open a new TCP connection. You cannot fix that problem and avoid that pr= oblem with IW.

> We need to decide if we think an application protocol should be able t= o be both a low-latency protocol, and based on TCP. =A0If
> you think that should be possible, then we seriously need to consider = changing IW. =A0The reasons not to change it, would be if
> you thought it would kill the net - but, I there is no evidence of tha= t, especially if we consider which protocols get which
> limits.

I don't think it would kill the net. Yet, I don=92t think your mo= tivation is justified at least for the apps and scenarios I am interested i= n, which might be of course different from yours.

>
>
> =A0 =A0 =A0 Maybe, trying to fix TCP to make HTTP is not the best stra= tegy here.
>
>
>
> Are you saying HTTP should move to a new transport? =A0That seems like= a shame.

One could try fixing HTTP or try to find a better transport alternati= ve. Neither is a shame. Just because it was designed so, it does not mean t= hat we need to stick with it forever.

-acbegen

> Mike
>
>
>
>
> =A0 =A0 =A0 -acbegen
>
>
> =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > From: tcpm-b= ounces@ietf.org [mailto:tcpm-b= ounces@ietf.org] On Behalf Of Mike Belshe
> =A0 =A0 =A0 > Sent: Friday, November 26, 2010 1:11 PM
> =A0 =A0 =A0 > To: tcpm@ietf.org
> =A0 =A0 =A0 > Subject: [tcpm] A Challenge to TCPM
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Hi,
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > I thought I'd add a slightly different perspectiv= e to the discussion about initial cwnd. =A0I'm a developer on Chrome &a= mp;
> SPDY.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > With SPDY, we want to build an application protocol w= hich is efficient on the transport, good for the network, and
> faster than
> =A0 =A0 =A0 > HTTP. =A0But right now, TCP is holding us back becaus= e we're trying to accomplish with one connection what HTTP
> does with
> =A0 =A0 =A0 > 10+ connections.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Note: =A0I don't want to make this thread about S= PDY. =A0I hope the members of this list agree that the goals of SPDY are > good
> =A0 =A0 =A0 > and will help make TCP a friendly transport for an ap= plication protocol like SPDY.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Background
> =A0 =A0 =A0 > Unrelated to TCP, HTTP is not very efficient. =A0This= has been widely documented and observed for some time. =A0We
> can easily
> =A0 =A0 =A0 > demonstrate a more efficient protocol, which transfer= s 25-35% fewer packets than HTTP and reduces bytes
> transferred by
> =A0 =A0 =A0 > 10-15%. =A0Hopefully everyone agrees those are good t= hings for the network.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Unfortunately, any TCP-based protocol which uses a si= ngle connection is at a latency-handicap compared to any
> protocol that
> =A0 =A0 =A0 > uses multiple connections. =A0This is due to IW. =A0F= urther, because bandwidth increases have outpaced RTT decreases,
> =A0 =A0 =A0 > bandwidth is relatively cheap. =A0So, being efficient= on your bandwidth is less critical than being efficient on your
> round-trips.
> =A0 =A0 =A0 >
>
> =A0 =A0 =A0 > To visualize the effects, please see the attached gra= ph. =A0(Or click here <http://6541078575799853287-a-chromium-
> org-s-
> =A0 =A0 =A0 > sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_in= itial_cwnd_on_plt(1).png?attachauth=3DANoY7cpm-
> y5NA-
> =A0 =A0 =A0 > zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9-
> =A0 =A0 =A0 >
> QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3Cz= KbzsxnGKlQaectqG8a7cjg5vgU1Gj4c
> =A0 =A0 =A0 >
> FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFP= QkAmEI2FvRbq6IBg1aI%3D&attredirect
> =A0 =A0 =A0 > s=3D0> ) =A0In these tests, I loaded a replica of = the facebook landing page through two protocols - one using a single
> connection in
>
> =A0 =A0 =A0 > a semi-efficient manner (an early version of spdy) an= d another using 6 connections (http). =A0I used a high-bandwidth
> network
> =A0 =A0 =A0 > with either 100ms or 200ms of RTT, and then I varied = IW from 2pkts all the way to 128pkts. =A0I chose this network
> =A0 =A0 =A0 > configuration to specifically isolate the effects of = high-RTT and IW. =A0As you can see, at low IW, the single-connection
> protocol
> =A0 =A0 =A0 > fares poorly compared to the multi-connection protoco= l. =A0 For another writeup on the problem, see
> =A0 =A0 =A0 > http://dev.chromium.org/s= pdy/An_Argument_For_Changing_TCP_Slow_Start.pdf
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Today, the fastest way to deliver content is to simpl= y side-step cwnd by use of multiple connections.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > The Problem
> =A0 =A0 =A0 > With SPDY (or whatever protocol comes next), we can d= efinitely reduce the number of connections out of the
> browser by *at
> =A0 =A0 =A0 > least* a factor of 6. =A0With unfolding of the subdom= ain tricks that websites have been doing, we can reduce it by a
> factor of
> =A0 =A0 =A0 > 10. =A0This has nothing to do with TCP, except I hope= that folks on this list appreciate that this goodness: =A0fewer
> connections -
> =A0 =A0 =A0 > fewer packets - and fewer bytes.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > The only trouble is that if we abide to the RFCs, few= er connections + fewer packets + fewer bytes equates to slower
> web
> =A0 =A0 =A0 > pages.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > But I'm not asking that we increase IW by a facto= r of 10; because it grows exponentially, if we can increase it to
> somewhere
> =A0 =A0 =A0 > in the ~16 range, it's good enough.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > The Conundrum
> =A0 =A0 =A0 > More perplexing is that whenever we talk about increa= sing IW, we tend to think of the static throttle that we have
> today. =A0If
> =A0 =A0 =A0 > we increase a static throttle, it affects everything.= =A0So protocols that are already bursting 20-30x more packets than
> they
> =A0 =A0 =A0 > should (by way of many connections) will burst even m= ore.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > This makes some people want to do nothing...
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > At the same time, we also know that cwnd has already = been increased on the net at large. =A0 This started with use of
> multiple
> =A0 =A0 =A0 > connections, multiplied with the use of multiple subd= omains, and is now changing by major sites simply increasing
> or
> =A0 =A0 =A0 > ignoring cwnd altogther. =A0With so many sites system= atically working around cwnd, we know that the current limits
> can be
> =A0 =A0 =A0 > increased. =A0We just don't know how much.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > The Solution?
> =A0 =A0 =A0 > Is the obvious solution to stop using a static value?= =A0It doesn't seem like we're in a one-size-fits-all for IW.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > The IW could either be defined to be protocol-specifi= c, or dynamic based on number of TCP flows between the same
> two
> =A0 =A0 =A0 > endpoints. =A0Both of these approaches would offer th= e benefit of a controlled, increased cwnd to reflect the changes
> in the net
> =A0 =A0 =A0 > over the last 2 decades but also not completely unthr= ottle protocols that are already living on the edge of not
> having
> =A0 =A0 =A0 > throttles.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Finally, if a dynamic throttle is too much to decide = upon, at least updating the static value seems appropriate.
> Jerrry and
> =A0 =A0 =A0 > Nandita have provided good data for a general-purpose= increase to 10. =A0If inefficient protocols are allowed to go
> that high,
> =A0 =A0 =A0 > maybe more efficient protocols could be allowed to go= higher (with data, of course).
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Reality Check
> =A0 =A0 =A0 > Finally, regardless of this debate in the IETF, what = is actually going to happen?
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > a) IETF does not increase the limit (or continues to = wait):
> =A0 =A0 =A0 > As time goes on, more and more evidence emerges to de= monstrate that the current cwnd limits are unnecessarily
> =A0 =A0 =A0 > conservative. =A0More evidence also emerges that incr= easing cwnd makes your site faster. =A0More sites start
> experimenting with
> =A0 =A0 =A0 > their own values of cwnd. =A0Without a blessed recomm= endation from the IETF, sites choose whatever values they
> want. Ben
>
> =A0 =A0 =A0 > Strong offered a writeup today which demonstrates thi= s is already happening
> <http://blog.benstrong.com/2010/11/google-
> =A0 =A0 =A0 > and-microsoft-cheat-on-slow.html> .
>
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > b) IETF increases the limit:
> =A0 =A0 =A0 > With data and a specific recommendation, TCP vendors = can quickly move to the new recommendations, making
> their
> =A0 =A0 =A0 > products more competitive in the marketplace, and bet= ter for users. =A0Pressure is alleviated from existing sites to go
> =A0 =A0 =A0 > renegade, and instead they can rest on the specific f= indings from this group. =A0With a modern recommendation in
> hand, all of
> =A0 =A0 =A0 > us can credibly go after any sites which do choose to= use dangerously high cwnd values. =A0Finally, having an officially
> =A0 =A0 =A0 > increased IW is an enabler for a future of more effic= ient application level protocols, which are currently at a
> disadvantage to
> =A0 =A0 =A0 > their less-efficient counterparts.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Now, which of these two options carries more risk of = internet collapse? =A0Vendors implementing whatever-the-heck-
> their-
> =A0 =A0 =A0 > rookie-system-administrator decided to configure? =A0= Or an official, controlled and intelligent recommendation from
> this
> =A0 =A0 =A0 > group?
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Thanks to everyone on this list for their hard work o= ver the years - although my email is somewhat critical, be
> aware that I
> =A0 =A0 =A0 > have immense gratitude and respect for the veterans o= f this list that have been keeping the net flowing for so long
> with such
> =A0 =A0 =A0 > great success.
> =A0 =A0 =A0 > Mike
>
>

_____________________________= __________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--0015175cb8204fd3b104963f2d2f-- From sunseawq@huawei.com Tue Nov 30 00:52:24 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522C73A6C0C for ; Tue, 30 Nov 2010 00:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=0.670, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZXSXTAf3Hry for ; Tue, 30 Nov 2010 00:52:22 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 87DEE3A6831 for ; Tue, 30 Nov 2010 00:52:22 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCO0008AWOZDZ@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 30 Nov 2010 16:53:23 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCO0009AWOZ1K@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 30 Nov 2010 16:53:23 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCO000O9WOY6M@szxml06-in.huawei.com> for tcpm@ietf.org; Tue, 30 Nov 2010 16:53:23 +0800 (CST) Date: Tue, 30 Nov 2010 16:53:22 +0800 From: Qin Wu To: "Ali C. Begen (abegen)" , Mike Belshe Message-id: <031c01cb906c$0b44d840$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> <01fb01cb8f97$6e343520$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540DC93005@xmb-sjc-215.amer.cisco.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 08:52:24 -0000 +1 Tuning IW used to improve TCP performance will not work for the application that holds persistent connection. ----- Original Message ----- From: "Ali C. Begen (abegen)" To: "Mike Belshe" ; "Qin Wu" Cc: Sent: Monday, November 29, 2010 9:03 PM Subject: RE: [tcpm] A Challenge to TCPM > ... > >> Ali is incorrect that changing IW will only change connection duration. Changing IW directly effects the number of round- >> trips required to download a resource. With a typical 100ms RTT, a 5KB resource can be transferred in 100ms less time if it >> were not for cwnd. For a 50KB transfer, an increase of initial cwnd from 2 to 10 reduces the overall time more dramatically >> - from ~8 round trips to ~5 round trips, saving 3 round trips * 100ms == 300ms of total transfer time. > > I said "changing IW would only change the conn duration"? I don't recall that but anyway. > > Your examples are correct but as I said these are all short-lived transactions. It is no brainer that their transfers are limited by IW. Changing it from 2 to 10, saves you 3 RTTs since you are stuck with SS for the entire connection. > > There are many other applications which don't necessarily spend their lifetime entirely in SS periods, though. > > -acbegen > >> Finally, if you apply how web pages load (an average web page discovers resources over time, and makes ~49 independent >> requests totaling ~320KB), there are additive effects to these cwnd-induced stalls. The first resource was stalled by 1 or 2 >> RTs, then the second resource is stalled by 2-3 RTs, etc. And that is why, as the chart shows quite clearly, that a single- >> connection protocol for HTTP with current cwnd values is slower than a multi-connection HTTP - the multi-connection HTTP >> gets more cwnd. >> >> This chart is pretty clear, I hope. I've isolated just the one variable to test- init-cwnd, and demonstrated the effects. This >> effect can be seen in the real world - just open up tcpdump and load a few web pages. I guarantee you'll see it! :-) >> >> Mike >> >> >> >> >> >> >> >> Maybe, trying to fix TCP to make HTTP is not the best strategy here. >> >> >> >> Are you saying HTTP should move to a new transport? That seems like a shame. >> >> Mike >> >> >> >> >> -acbegen >> >> >> > -----Original Message----- >> > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mike Belshe >> > Sent: Friday, November 26, 2010 1:11 PM >> > To: tcpm@ietf.org >> > Subject: [tcpm] A Challenge to TCPM >> > >> > Hi, >> > >> > I thought I'd add a slightly different perspective to the discussion about initial cwnd. I'm a developer >> on Chrome & SPDY. >> > >> > With SPDY, we want to build an application protocol which is efficient on the transport, good for the >> network, and faster than >> > HTTP. But right now, TCP is holding us back because we're trying to accomplish with one connection >> what HTTP does with >> > 10+ connections. >> > >> > Note: I don't want to make this thread about SPDY. I hope the members of this list agree that the >> goals of SPDY are good >> > and will help make TCP a friendly transport for an application protocol like SPDY. >> > >> > Background >> > Unrelated to TCP, HTTP is not very efficient. This has been widely documented and observed for >> some time. We can easily >> > demonstrate a more efficient protocol, which transfers 25-35% fewer packets than HTTP and reduces >> bytes transferred by >> > 10-15%. Hopefully everyone agrees those are good things for the network. >> > >> > Unfortunately, any TCP-based protocol which uses a single connection is at a latency-handicap >> compared to any protocol that >> > uses multiple connections. This is due to IW. Further, because bandwidth increases have outpaced >> RTT decreases, >> > bandwidth is relatively cheap. So, being efficient on your bandwidth is less critical than being >> efficient on your round-trips. >> > >> >> > To visualize the effects, please see the attached graph. (Or click here >> > > >> sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initial_cwnd_on_plt(1).png?attachauth=ANoY7cpm-y5NA- >> > zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9- >> > >> QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3CzKbzsxnGKlQaectqG8a7cjg5vgU1Gj4c >> > >> FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFPQkAmEI2FvRbq6IBg1aI%3D&attredirect >> > s=0> ) In these tests, I loaded a replica of the facebook landing page through two protocols - one >> using a single connection in >> >> > a semi-efficient manner (an early version of spdy) and another using 6 connections (http). I used a >> high-bandwidth network >> > with either 100ms or 200ms of RTT, and then I varied IW from 2pkts all the way to 128pkts. I chose >> this network >> > configuration to specifically isolate the effects of high-RTT and IW. As you can see, at low IW, the >> single-connection protocol >> > fares poorly compared to the multi-connection protocol. For another writeup on the problem, see >> > http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf >> > >> > Today, the fastest way to deliver content is to simply side-step cwnd by use of multiple connections. >> > >> > >> > The Problem >> > With SPDY (or whatever protocol comes next), we can definitely reduce the number of connections >> out of the browser by *at >> > least* a factor of 6. With unfolding of the subdomain tricks that websites have been doing, we can >> reduce it by a factor of >> > 10. This has nothing to do with TCP, except I hope that folks on this list appreciate that this goodness: >> fewer connections - >> > fewer packets - and fewer bytes. >> > >> > The only trouble is that if we abide to the RFCs, fewer connections + fewer packets + fewer bytes >> equates to slower web >> > pages. >> > >> > But I'm not asking that we increase IW by a factor of 10; because it grows exponentially, if we can >> increase it to somewhere >> > in the ~16 range, it's good enough. >> > >> > >> > The Conundrum >> > More perplexing is that whenever we talk about increasing IW, we tend to think of the static throttle >> that we have today. If >> > we increase a static throttle, it affects everything. So protocols that are already bursting 20-30x >> more packets than they >> > should (by way of many connections) will burst even more. >> > >> > This makes some people want to do nothing... >> > >> > At the same time, we also know that cwnd has already been increased on the net at large. This >> started with use of multiple >> > connections, multiplied with the use of multiple subdomains, and is now changing by major sites >> simply increasing or >> > ignoring cwnd altogther. With so many sites systematically working around cwnd, we know that the >> current limits can be >> > increased. We just don't know how much. >> > >> > >> > The Solution? >> > Is the obvious solution to stop using a static value? It doesn't seem like we're in a one-size-fits-all for >> IW. >> > >> > The IW could either be defined to be protocol-specific, or dynamic based on number of TCP flows >> between the same two >> > endpoints. Both of these approaches would offer the benefit of a controlled, increased cwnd to >> reflect the changes in the net >> > over the last 2 decades but also not completely unthrottle protocols that are already living on the >> edge of not having >> > throttles. >> > >> > Finally, if a dynamic throttle is too much to decide upon, at least updating the static value seems >> appropriate. Jerrry and >> > Nandita have provided good data for a general-purpose increase to 10. If inefficient protocols are >> allowed to go that high, >> > maybe more efficient protocols could be allowed to go higher (with data, of course). >> > >> > >> > Reality Check >> > Finally, regardless of this debate in the IETF, what is actually going to happen? >> > >> > a) IETF does not increase the limit (or continues to wait): >> > As time goes on, more and more evidence emerges to demonstrate that the current cwnd limits are >> unnecessarily >> > conservative. More evidence also emerges that increasing cwnd makes your site faster. More sites >> start experimenting with >> > their own values of cwnd. Without a blessed recommendation from the IETF, sites choose whatever >> values they want. Ben >> >> > Strong offered a writeup today which demonstrates this is already happening >> > > and-microsoft-cheat-on-slow.html> . >> >> > >> > b) IETF increases the limit: >> > With data and a specific recommendation, TCP vendors can quickly move to the new >> recommendations, making their >> > products more competitive in the marketplace, and better for users. Pressure is alleviated from >> existing sites to go >> > renegade, and instead they can rest on the specific findings from this group. With a modern >> recommendation in hand, all of >> > us can credibly go after any sites which do choose to use dangerously high cwnd values. Finally, >> having an officially >> > increased IW is an enabler for a future of more efficient application level protocols, which are >> currently at a disadvantage to >> > their less-efficient counterparts. >> > >> > >> > >> > >> > Now, which of these two options carries more risk of internet collapse? Vendors implementing >> whatever-the-heck-their- >> > rookie-system-administrator decided to configure? Or an official, controlled and intelligent >> recommendation from this >> > group? >> > >> > >> > Thanks to everyone on this list for their hard work over the years - although my email is somewhat >> critical, be aware that I >> > have immense gratitude and respect for the veterans of this list that have been keeping the net >> flowing for so long with such >> > great success. >> > Mike >> >> >> >> >> >> ________________________________ >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> >> > > From rs@netapp.com Tue Nov 30 01:17:03 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695CD3A6AED for ; Tue, 30 Nov 2010 01:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.997 X-Spam-Level: X-Spam-Status: No, score=-7.997 tagged_above=-999 required=5 tests=[AWL=-2.179, BAYES_50=0.001, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJhoXTE78ine for ; Tue, 30 Nov 2010 01:17:01 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id D6BE83A69DA for ; Tue, 30 Nov 2010 01:17:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,279,1288594800"; d="scan'208";a="223262766" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 30 Nov 2010 01:18:11 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oAU9I86M004599; Tue, 30 Nov 2010 01:18:08 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Nov 2010 09:18:09 +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: Tue, 30 Nov 2010 09:18:06 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0BA96A8B@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <031c01cb906c$0b44d840$30298a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] A Challenge to TCPM Thread-Index: AcuQbBkyF+4yvdgaSxi438eOQz6fUQAApMag References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com><01fb01cb8f97$6e343520$30298a0a@china.huawei.com><04CAD96D4C5A3D48B1919248A8FE0D540DC93005@xmb-sjc-215.amer.cisco.com> <031c01cb906c$0b44d840$30298a0a@china.huawei.com> From: "Scheffenegger, Richard" To: "Qin Wu" , "Ali C. Begen (abegen)" , "Mike Belshe" X-OriginalArrivalTime: 30 Nov 2010 09:18:09.0475 (UTC) FILETIME=[81451930:01CB906F] Cc: tcpm@ietf.org Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 09:17:03 -0000 Let's not loose focus... for restart window (persistent connection), many (most?) TCP stacks already use their prior knowledge on the specifics of the tcp session, when deciding which restart window to choose. IMHO, addressing this by dynamic means (much along the lines with Joe is a big supporter) is really not much of an issue. The IW10 proposal addresses some of the issues, when it is simply very hard to obtain any prior knowledge as to how optimally deal with a new session. Even the 2nd session to the same target is already making use of cached information today. Richard Scheffenegger =20 > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com]=20 > Sent: Dienstag, 30. November 2010 09:53 > To: Ali C. Begen (abegen); Mike Belshe > Cc: tcpm@ietf.org > Subject: Re: [tcpm] A Challenge to TCPM >=20 > +1 > Tuning IW used to improve TCP performance will not work for=20 > the application that holds persistent connection. > ----- Original Message ----- > From: "Ali C. Begen (abegen)" > To: "Mike Belshe" ; "Qin Wu" > Cc: > Sent: Monday, November 29, 2010 9:03 PM > Subject: RE: [tcpm] A Challenge to TCPM >=20 >=20 > > ... > >=20 > >> Ali is incorrect that changing IW will only change=20 > connection duration. Changing IW directly effects the=20 > number of round- > >> trips required to download a resource. With a typical=20 > 100ms RTT, a 5KB resource can be transferred in 100ms less time if it > >> were not for cwnd. For a 50KB transfer, an increase of=20 > initial cwnd from 2 to 10 reduces the overall time more dramatically > >> - from ~8 round trips to ~5 round trips, saving 3 round=20 > trips * 100ms =3D=3D 300ms of total transfer time. > >=20 > > I said "changing IW would only change the conn duration"? I=20 > don't recall that but anyway. > >=20 > > Your examples are correct but as I said these are all=20 > short-lived transactions. It is no brainer that their=20 > transfers are limited by IW. Changing it from 2 to 10, saves=20 > you 3 RTTs since you are stuck with SS for the entire connection. > >=20 > > There are many other applications which don't necessarily=20 > spend their lifetime entirely in SS periods, though.=20 > >=20 > > -acbegen > >=20 > >> Finally, if you apply how web pages load (an average web=20 > page discovers resources over time, and makes ~49 independent > >> requests totaling ~320KB), there are additive effects to=20 > these cwnd-induced stalls. The first resource was stalled by 1 or 2 > >> RTs, then the second resource is stalled by 2-3 RTs, etc. =20 > And that is why, as the chart shows quite clearly, that a single- > >> connection protocol for HTTP with current cwnd values is=20 > slower than a multi-connection HTTP - the multi-connection HTTP > >> gets more cwnd. > >>=20 > >> This chart is pretty clear, I hope. I've isolated just=20 > the one variable to test- init-cwnd, and demonstrated the=20 > effects. This > >> effect can be seen in the real world - just open up=20 > tcpdump and load a few web pages. I guarantee you'll see it! :-) > >>=20 > >> Mike > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >> Maybe, trying to fix TCP to make HTTP is not the best=20 > strategy here. > >>=20 > >>=20 > >>=20 > >> Are you saying HTTP should move to a new transport? That=20 > seems like a shame. > >>=20 > >> Mike > >>=20 > >>=20 > >>=20 > >>=20 > >> -acbegen > >>=20 > >>=20 > >> > -----Original Message----- > >> > From: tcpm-bounces@ietf.org=20 > [mailto:tcpm-bounces@ietf.org] On Behalf Of Mike Belshe > >> > Sent: Friday, November 26, 2010 1:11 PM > >> > To: tcpm@ietf.org > >> > Subject: [tcpm] A Challenge to TCPM > >> > > >> > Hi, > >> > > >> > I thought I'd add a slightly different perspective to=20 > the discussion about initial cwnd. I'm a developer > >> on Chrome & SPDY. > >> > > >> > With SPDY, we want to build an application protocol=20 > which is efficient on the transport, good for the > >> network, and faster than > >> > HTTP. But right now, TCP is holding us back because=20 > we're trying to accomplish with one connection > >> what HTTP does with > >> > 10+ connections. > >> > > >> > Note: I don't want to make this thread about SPDY. I=20 > hope the members of this list agree that the > >> goals of SPDY are good > >> > and will help make TCP a friendly transport for an=20 > application protocol like SPDY. > >> > > >> > Background > >> > Unrelated to TCP, HTTP is not very efficient. This has=20 > been widely documented and observed for > >> some time. We can easily > >> > demonstrate a more efficient protocol, which transfers=20 > 25-35% fewer packets than HTTP and reduces > >> bytes transferred by > >> > 10-15%. Hopefully everyone agrees those are good things=20 > for the network. > >> > > >> > Unfortunately, any TCP-based protocol which uses a=20 > single connection is at a latency-handicap > >> compared to any protocol that > >> > uses multiple connections. This is due to IW. Further,=20 > because bandwidth increases have outpaced > >> RTT decreases, > >> > bandwidth is relatively cheap. So, being efficient on=20 > your bandwidth is less critical than being > >> efficient on your round-trips. > >> > > >>=20 > >> > To visualize the effects, please see the attached graph.=20 > (Or click here > >> >> > > >>=20 > sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initi > al_cwnd_on_plt(1).png?attachauth=3DANoY7cpm-y5NA- > >> > zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9- > >> > > >>=20 > QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1n > iKx5W3CzKbzsxnGKlQaectqG8a7cjg5vgU1Gj4c > >> > > >>=20 > FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFT > TWw93XFPQkAmEI2FvRbq6IBg1aI%3D&attredirect > >> > s=3D0> ) In these tests, I loaded a replica of the=20 > facebook landing page through two protocols - one > >> using a single connection in > >>=20 > >> > a semi-efficient manner (an early version of spdy) and=20 > another using 6 connections (http). I used a > >> high-bandwidth network > >> > with either 100ms or 200ms of RTT, and then I varied IW=20 > from 2pkts all the way to 128pkts. I chose > >> this network > >> > configuration to specifically isolate the effects of=20 > high-RTT and IW. As you can see, at low IW, the > >> single-connection protocol > >> > fares poorly compared to the multi-connection protocol. =20 > For another writeup on the problem, see > >> >=20 > http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow > _Start.pdf > >> > > >> > Today, the fastest way to deliver content is to simply=20 > side-step cwnd by use of multiple connections. > >> > > >> > > >> > The Problem > >> > With SPDY (or whatever protocol comes next), we can=20 > definitely reduce the number of connections > >> out of the browser by *at > >> > least* a factor of 6. With unfolding of the subdomain=20 > tricks that websites have been doing, we can > >> reduce it by a factor of > >> > 10. This has nothing to do with TCP, except I hope that=20 > folks on this list appreciate that this goodness: > >> fewer connections - > >> > fewer packets - and fewer bytes. > >> > > >> > The only trouble is that if we abide to the RFCs, fewer=20 > connections + fewer packets + fewer bytes > >> equates to slower web > >> > pages. > >> > > >> > But I'm not asking that we increase IW by a factor of=20 > 10; because it grows exponentially, if we can > >> increase it to somewhere > >> > in the ~16 range, it's good enough. > >> > > >> > > >> > The Conundrum > >> > More perplexing is that whenever we talk about=20 > increasing IW, we tend to think of the static throttle > >> that we have today. If > >> > we increase a static throttle, it affects everything. =20 > So protocols that are already bursting 20-30x > >> more packets than they > >> > should (by way of many connections) will burst even more. > >> > > >> > This makes some people want to do nothing... > >> > > >> > At the same time, we also know that cwnd has already=20 > been increased on the net at large. This > >> started with use of multiple > >> > connections, multiplied with the use of multiple=20 > subdomains, and is now changing by major sites > >> simply increasing or > >> > ignoring cwnd altogther. With so many sites=20 > systematically working around cwnd, we know that the > >> current limits can be > >> > increased. We just don't know how much. > >> > > >> > > >> > The Solution? > >> > Is the obvious solution to stop using a static value? =20 > It doesn't seem like we're in a one-size-fits-all for > >> IW. > >> > > >> > The IW could either be defined to be protocol-specific,=20 > or dynamic based on number of TCP flows > >> between the same two > >> > endpoints. Both of these approaches would offer the=20 > benefit of a controlled, increased cwnd to > >> reflect the changes in the net > >> > over the last 2 decades but also not completely=20 > unthrottle protocols that are already living on the > >> edge of not having > >> > throttles. > >> > > >> > Finally, if a dynamic throttle is too much to decide=20 > upon, at least updating the static value seems > >> appropriate. Jerrry and > >> > Nandita have provided good data for a general-purpose=20 > increase to 10. If inefficient protocols are > >> allowed to go that high, > >> > maybe more efficient protocols could be allowed to go=20 > higher (with data, of course). > >> > > >> > > >> > Reality Check > >> > Finally, regardless of this debate in the IETF, what is=20 > actually going to happen? > >> > > >> > a) IETF does not increase the limit (or continues to wait): > >> > As time goes on, more and more evidence emerges to=20 > demonstrate that the current cwnd limits are > >> unnecessarily > >> > conservative. More evidence also emerges that=20 > increasing cwnd makes your site faster. More sites > >> start experimenting with > >> > their own values of cwnd. Without a blessed=20 > recommendation from the IETF, sites choose whatever > >> values they want. Ben > >>=20 > >> > Strong offered a writeup today which demonstrates this=20 > is already happening > >> >> > and-microsoft-cheat-on-slow.html> . > >>=20 > >> > > >> > b) IETF increases the limit: > >> > With data and a specific recommendation, TCP vendors can=20 > quickly move to the new > >> recommendations, making their > >> > products more competitive in the marketplace, and better=20 > for users. Pressure is alleviated from > >> existing sites to go > >> > renegade, and instead they can rest on the specific=20 > findings from this group. With a modern > >> recommendation in hand, all of > >> > us can credibly go after any sites which do choose to=20 > use dangerously high cwnd values. Finally, > >> having an officially > >> > increased IW is an enabler for a future of more=20 > efficient application level protocols, which are > >> currently at a disadvantage to > >> > their less-efficient counterparts. > >> > > >> > > >> > > >> > > >> > Now, which of these two options carries more risk of=20 > internet collapse? Vendors implementing > >> whatever-the-heck-their- > >> > rookie-system-administrator decided to configure? Or an=20 > official, controlled and intelligent > >> recommendation from this > >> > group? > >> > > >> > > >> > Thanks to everyone on this list for their hard work over=20 > the years - although my email is somewhat > >> critical, be aware that I > >> > have immense gratitude and respect for the veterans of=20 > this list that have been keeping the net > >> flowing for so long with such > >> > great success. > >> > Mike > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >> ________________________________ > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > >>=20 > >>=20 > >>=20 > >>=20 > >=20 > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From sunseawq@huawei.com Tue Nov 30 03:46:19 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAF33A6A7C for ; Tue, 30 Nov 2010 03:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAGF2wPiEl4C for ; Tue, 30 Nov 2010 03:46:17 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 391003A6BED for ; Tue, 30 Nov 2010 03:46:17 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCP000164MYDZ@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 30 Nov 2010 19:44:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCP00A3W4MYN6@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 30 Nov 2010 19:44:58 +0800 (CST) Received: from C863D63E94E7457 ([112.122.138.131]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCP00IBW4MX5J@szxml01-in.huawei.com>; Tue, 30 Nov 2010 19:44:58 +0800 (CST) Date: Tue, 30 Nov 2010 19:46:06 +0800 From: Qin Wu To: "Scheffenegger, Richard" , "Ali C. Begen (abegen)" , Mike Belshe Message-id: <008801cb9084$2cf297d0$ff5afea9@C863D63E94E7457> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> <01fb01cb8f97$6e343520$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540DC93005@xmb-sjc-215.amer.cisco.com> <031c01cb906c$0b44d840$30298a0a@china.huawei.com> <5FDC413D5FA246468C200652D63E627A0BA96A8B@LDCMVEXC1-PRD.hq.netapp.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 11:46:19 -0000 Hi, ----- Original Message ----- From: "Scheffenegger, Richard" To: "Qin Wu" ; "Ali C. Begen (abegen)" ; "Mike Belshe" Cc: Sent: Tuesday, November 30, 2010 5:18 PM Subject: RE: [tcpm] A Challenge to TCPM Let's not loose focus... for restart window (persistent connection), many (most?) TCP stacks already use their prior knowledge on the specifics of the tcp session, when deciding which restart window to choose. IMHO, addressing this by dynamic means (much along the lines with Joe is a big supporter) is really not much of an issue. [Qin]: I am not convincing that chaning IW can reduce latency for persistent connection. I only agree IW10 has its value when Slow start applies in zero-loss case. The IW10 proposal addresses some of the issues, when it is simply very hard to obtain any prior knowledge as to how optimally deal with a new session. Even the 2nd session to the same target is already making use of cached information today. [Qin]: No doubt about this. Richard Scheffenegger > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Dienstag, 30. November 2010 09:53 > To: Ali C. Begen (abegen); Mike Belshe > Cc: tcpm@ietf.org > Subject: Re: [tcpm] A Challenge to TCPM > > +1 > Tuning IW used to improve TCP performance will not work for > the application that holds persistent connection. > ----- Original Message ----- > From: "Ali C. Begen (abegen)" > To: "Mike Belshe" ; "Qin Wu" > Cc: > Sent: Monday, November 29, 2010 9:03 PM > Subject: RE: [tcpm] A Challenge to TCPM > > > > ... > > > >> Ali is incorrect that changing IW will only change > connection duration. Changing IW directly effects the > number of round- > >> trips required to download a resource. With a typical > 100ms RTT, a 5KB resource can be transferred in 100ms less time if it > >> were not for cwnd. For a 50KB transfer, an increase of > initial cwnd from 2 to 10 reduces the overall time more dramatically > >> - from ~8 round trips to ~5 round trips, saving 3 round > trips * 100ms == 300ms of total transfer time. > > > > I said "changing IW would only change the conn duration"? I > don't recall that but anyway. > > > > Your examples are correct but as I said these are all > short-lived transactions. It is no brainer that their > transfers are limited by IW. Changing it from 2 to 10, saves > you 3 RTTs since you are stuck with SS for the entire connection. > > > > There are many other applications which don't necessarily > spend their lifetime entirely in SS periods, though. > > > > -acbegen > > > >> Finally, if you apply how web pages load (an average web > page discovers resources over time, and makes ~49 independent > >> requests totaling ~320KB), there are additive effects to > these cwnd-induced stalls. The first resource was stalled by 1 or 2 > >> RTs, then the second resource is stalled by 2-3 RTs, etc. > And that is why, as the chart shows quite clearly, that a single- > >> connection protocol for HTTP with current cwnd values is > slower than a multi-connection HTTP - the multi-connection HTTP > >> gets more cwnd. > >> > >> This chart is pretty clear, I hope. I've isolated just > the one variable to test- init-cwnd, and demonstrated the > effects. This > >> effect can be seen in the real world - just open up > tcpdump and load a few web pages. I guarantee you'll see it! :-) > >> > >> Mike > >> > >> > >> > >> > >> > >> > >> > >> Maybe, trying to fix TCP to make HTTP is not the best > strategy here. > >> > >> > >> > >> Are you saying HTTP should move to a new transport? That > seems like a shame. > >> > >> Mike > >> > >> > >> > >> > >> -acbegen > >> > >> > >> > -----Original Message----- > >> > From: tcpm-bounces@ietf.org > [mailto:tcpm-bounces@ietf.org] On Behalf Of Mike Belshe > >> > Sent: Friday, November 26, 2010 1:11 PM > >> > To: tcpm@ietf.org > >> > Subject: [tcpm] A Challenge to TCPM > >> > > >> > Hi, > >> > > >> > I thought I'd add a slightly different perspective to > the discussion about initial cwnd. I'm a developer > >> on Chrome & SPDY. > >> > > >> > With SPDY, we want to build an application protocol > which is efficient on the transport, good for the > >> network, and faster than > >> > HTTP. But right now, TCP is holding us back because > we're trying to accomplish with one connection > >> what HTTP does with > >> > 10+ connections. > >> > > >> > Note: I don't want to make this thread about SPDY. I > hope the members of this list agree that the > >> goals of SPDY are good > >> > and will help make TCP a friendly transport for an > application protocol like SPDY. > >> > > >> > Background > >> > Unrelated to TCP, HTTP is not very efficient. This has > been widely documented and observed for > >> some time. We can easily > >> > demonstrate a more efficient protocol, which transfers > 25-35% fewer packets than HTTP and reduces > >> bytes transferred by > >> > 10-15%. Hopefully everyone agrees those are good things > for the network. > >> > > >> > Unfortunately, any TCP-based protocol which uses a > single connection is at a latency-handicap > >> compared to any protocol that > >> > uses multiple connections. This is due to IW. Further, > because bandwidth increases have outpaced > >> RTT decreases, > >> > bandwidth is relatively cheap. So, being efficient on > your bandwidth is less critical than being > >> efficient on your round-trips. > >> > > >> > >> > To visualize the effects, please see the attached graph. > (Or click here > >> >> > > >> > sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initi > al_cwnd_on_plt(1).png?attachauth=ANoY7cpm-y5NA- > >> > zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9- > >> > > >> > QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1n > iKx5W3CzKbzsxnGKlQaectqG8a7cjg5vgU1Gj4c > >> > > >> > FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFT > TWw93XFPQkAmEI2FvRbq6IBg1aI%3D&attredirect > >> > s=0> ) In these tests, I loaded a replica of the > facebook landing page through two protocols - one > >> using a single connection in > >> > >> > a semi-efficient manner (an early version of spdy) and > another using 6 connections (http). I used a > >> high-bandwidth network > >> > with either 100ms or 200ms of RTT, and then I varied IW > from 2pkts all the way to 128pkts. I chose > >> this network > >> > configuration to specifically isolate the effects of > high-RTT and IW. As you can see, at low IW, the > >> single-connection protocol > >> > fares poorly compared to the multi-connection protocol. > For another writeup on the problem, see > >> > > http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow > _Start.pdf > >> > > >> > Today, the fastest way to deliver content is to simply > side-step cwnd by use of multiple connections. > >> > > >> > > >> > The Problem > >> > With SPDY (or whatever protocol comes next), we can > definitely reduce the number of connections > >> out of the browser by *at > >> > least* a factor of 6. With unfolding of the subdomain > tricks that websites have been doing, we can > >> reduce it by a factor of > >> > 10. This has nothing to do with TCP, except I hope that > folks on this list appreciate that this goodness: > >> fewer connections - > >> > fewer packets - and fewer bytes. > >> > > >> > The only trouble is that if we abide to the RFCs, fewer > connections + fewer packets + fewer bytes > >> equates to slower web > >> > pages. > >> > > >> > But I'm not asking that we increase IW by a factor of > 10; because it grows exponentially, if we can > >> increase it to somewhere > >> > in the ~16 range, it's good enough. > >> > > >> > > >> > The Conundrum > >> > More perplexing is that whenever we talk about > increasing IW, we tend to think of the static throttle > >> that we have today. If > >> > we increase a static throttle, it affects everything. > So protocols that are already bursting 20-30x > >> more packets than they > >> > should (by way of many connections) will burst even more. > >> > > >> > This makes some people want to do nothing... > >> > > >> > At the same time, we also know that cwnd has already > been increased on the net at large. This > >> started with use of multiple > >> > connections, multiplied with the use of multiple > subdomains, and is now changing by major sites > >> simply increasing or > >> > ignoring cwnd altogther. With so many sites > systematically working around cwnd, we know that the > >> current limits can be > >> > increased. We just don't know how much. > >> > > >> > > >> > The Solution? > >> > Is the obvious solution to stop using a static value? > It doesn't seem like we're in a one-size-fits-all for > >> IW. > >> > > >> > The IW could either be defined to be protocol-specific, > or dynamic based on number of TCP flows > >> between the same two > >> > endpoints. Both of these approaches would offer the > benefit of a controlled, increased cwnd to > >> reflect the changes in the net > >> > over the last 2 decades but also not completely > unthrottle protocols that are already living on the > >> edge of not having > >> > throttles. > >> > > >> > Finally, if a dynamic throttle is too much to decide > upon, at least updating the static value seems > >> appropriate. Jerrry and > >> > Nandita have provided good data for a general-purpose > increase to 10. If inefficient protocols are > >> allowed to go that high, > >> > maybe more efficient protocols could be allowed to go > higher (with data, of course). > >> > > >> > > >> > Reality Check > >> > Finally, regardless of this debate in the IETF, what is > actually going to happen? > >> > > >> > a) IETF does not increase the limit (or continues to wait): > >> > As time goes on, more and more evidence emerges to > demonstrate that the current cwnd limits are > >> unnecessarily > >> > conservative. More evidence also emerges that > increasing cwnd makes your site faster. More sites > >> start experimenting with > >> > their own values of cwnd. Without a blessed > recommendation from the IETF, sites choose whatever > >> values they want. Ben > >> > >> > Strong offered a writeup today which demonstrates this > is already happening > >> >> > and-microsoft-cheat-on-slow.html> . > >> > >> > > >> > b) IETF increases the limit: > >> > With data and a specific recommendation, TCP vendors can > quickly move to the new > >> recommendations, making their > >> > products more competitive in the marketplace, and better > for users. Pressure is alleviated from > >> existing sites to go > >> > renegade, and instead they can rest on the specific > findings from this group. With a modern > >> recommendation in hand, all of > >> > us can credibly go after any sites which do choose to > use dangerously high cwnd values. Finally, > >> having an officially > >> > increased IW is an enabler for a future of more > efficient application level protocols, which are > >> currently at a disadvantage to > >> > their less-efficient counterparts. > >> > > >> > > >> > > >> > > >> > Now, which of these two options carries more risk of > internet collapse? Vendors implementing > >> whatever-the-heck-their- > >> > rookie-system-administrator decided to configure? Or an > official, controlled and intelligent > >> recommendation from this > >> > group? > >> > > >> > > >> > Thanks to everyone on this list for their hard work over > the years - although my email is somewhat > >> critical, be aware that I > >> > have immense gratitude and respect for the veterans of > this list that have been keeping the net > >> flowing for so long with such > >> > great success. > >> > Mike > >> > >> > >> > >> > >> > >> ________________________________ > >> > >> > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > >> > >> > >> > >> > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From touch@isi.edu Tue Nov 30 06:00:10 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09EE3A6C1B for ; Tue, 30 Nov 2010 06:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu8RdNGds2TK for ; Tue, 30 Nov 2010 06:00:10 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 0ACAC3A6BF1 for ; Tue, 30 Nov 2010 06:00:10 -0800 (PST) Received: from [144.118.103.248] (n2-103-248.guest.drexel.edu [144.118.103.248]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oAUE0VtF006753 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 30 Nov 2010 06:00:41 -0800 (PST) Message-ID: <4CF5037F.4000602@isi.edu> Date: Tue, 30 Nov 2010 06:00:31 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Yuchung Cheng References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <4CF26596.7010500@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, "Anantha Ramaiah \(ananth\)" , mallman@icir.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 14:00:10 -0000 On 11/29/2010 9:49 PM, Yuchung Cheng wrote: ... >> 2) NO AMOUNT of in-connection adjustment of CWND has any effect on >> the impact of a poor choice of IW >> >> consider that if this were not true, then you would >> not need to propose a new IW value; just as you do not >> want to wait for the connection to converge, I am >> concerned about the network impact until that convergence > > same argument holds for caching cwnd on a per-host or per prefix basis. There were two points: 1) that no amount of post-start adjusting of CWND affects poor IW choice auto-adjusting IW corrects for poor IW choice, so that argument is valid 2) auto-adjusting IW can still make mistakes yes, but over time if it does it will correct. fixed IW will not Fixing the IW over time isn't caching the CWND. The point is that CWND and IW are deliberately different. IW should be adjusted only if there were issues *during the IW period*, i.e., losses or retransmissions in that time. Perhaps your point was that we shouldn't reuse CWND. Note, however, that CWND reuse - as already deployed, FWIW - adjusts over time (as per RFC2140). The point I have made is that fixed IW does NOT adjust over time, and that it repeatedly can make mistakes. So if you have a counterargument, please explain. Joe From mallman@icir.org Tue Nov 30 06:31:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703A83A6C66 for ; Tue, 30 Nov 2010 06:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9d+PgGFoboRL for ; Tue, 30 Nov 2010 06:31:54 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 209A63A6C6F for ; Tue, 30 Nov 2010 06:31:54 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAUEX2cH008614; Tue, 30 Nov 2010 06:33:02 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2C6FF2655E90; Tue, 30 Nov 2010 09:33:02 -0500 (EST) To: Jakob Heitz From: Mark Allman In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213909B736A327@EUSAACMS0701.eamcs.ericsson.se> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Dance the Night Away MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma2844-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 30 Nov 2010 09:33:02 -0500 Sender: mallman@icir.org Message-Id: <20101130143302.2C6FF2655E90@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 14:31:57 -0000 ----------ma2844-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Why does IW need to be standardized? > How will any host/router on the internet change its behaviour based on > the standardized value? That is, any host/router other than the TCP > sender. > > Has anyone tried an IW based on advertized receive window rather than > on MSS? Only a little bit ... Dan Liu, Mark Allman, Shudong Jin, Limin Wang. Congestion Control Without a Startup Phase. Protocols for Fast, Long Distance Networks (PFLDnet) Workshop, February 2007. http://www.icir.org/mallman/papers/jumpstart-pfldnet07.pdf allman ----------ma2844-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz1Cx4ACgkQWyrrWs4yIs7qfgCeInfYL/fswEGmpJipO1AmI+lZ UgEAn1OzIwgSFr8EZmIFiMSSbcGz1lM3 =5EOt -----END PGP SIGNATURE----- ----------ma2844-1-- From touch@isi.edu Tue Nov 30 07:01:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7073A6BC1 for ; Tue, 30 Nov 2010 07:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFhrDPfxfWWo for ; Tue, 30 Nov 2010 07:01:39 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 562F93A6C79 for ; Tue, 30 Nov 2010 07:01:39 -0800 (PST) Received: from [144.118.103.248] (n2-103-248.guest.drexel.edu [144.118.103.248]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oAUF2FpC020195 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 30 Nov 2010 07:02:30 -0800 (PST) Message-ID: <4CF511F7.4050907@isi.edu> Date: Tue, 30 Nov 2010 07:02:15 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jakob Heitz References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <7309FCBCAE981B43ABBE69B31C8D213909B736A327@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213909B736A327@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: oAUF2FpC020195 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 15:01:40 -0000 On 11/27/2010 9:01 PM, Jakob Heitz wrote: > Why does IW need to be standardized? > How will any host/router on the internet change its behaviour based on > the standardized value? That is, any host/router other than the TCP sender. > Has anyone tried an IW based on advertized receive window rather than on > MSS? FWIW, advertised receive window is an indication of the receiver's ability to reorder and accommodate gaps in the transmission; it is not related to the congestion window, except that it's not useful to open CWND larger than the receive window. I.e., these values serve completely different purposes. There is no rationale for setting CWND to the receive window (i.e., for thinking that RWIN should be both the upper and lower bound of CWND). Joe From touch@isi.edu Tue Nov 30 07:38:14 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B19028C11F for ; Tue, 30 Nov 2010 07:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.509 X-Spam-Level: X-Spam-Status: No, score=-101.509 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_00=-2.599, NUMERIC_HTTP_ADDR=0.001, SARE_SPEC_REPLICA_OBFU=1.812, URI_HEX=0.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4j3BsLvGk6p for ; Tue, 30 Nov 2010 07:38:12 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 91D0128C11D for ; Tue, 30 Nov 2010 07:38:12 -0800 (PST) Received: from [144.118.103.248] (n2-103-248.guest.drexel.edu [144.118.103.248]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oAUFcUq2026636 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 30 Nov 2010 07:38:41 -0800 (PST) Message-ID: <4CF51A76.7010409@isi.edu> Date: Tue, 30 Nov 2010 07:38:30 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Qin Wu References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAB26@xmb-sjc-215.amer.cisco.com> <01fb01cb8f97$6e343520$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540DC93005@xmb-sjc-215.amer.cisco.com> <031c01cb906c$0b44d840$30298a0a@china.huawei.com> In-Reply-To: <031c01cb906c$0b44d840$30298a0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: oAUFcUq2026636 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] A Challenge to TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 15:38:14 -0000 It helps persistent connections during slow-start restart, since IW MAY also be used as the restart window (see RFC3390). Joe On 11/30/2010 12:53 AM, Qin Wu wrote: > +1 > Tuning IW used to improve TCP performance will not work for the application that holds persistent connection. > ----- Original Message ----- > From: "Ali C. Begen (abegen)" > To: "Mike Belshe"; "Qin Wu" > Cc: > Sent: Monday, November 29, 2010 9:03 PM > Subject: RE: [tcpm] A Challenge to TCPM > > >> ... >> >>> Ali is incorrect that changing IW will only change connection duration. Changing IW directly effects the number of round- >>> trips required to download a resource. With a typical 100ms RTT, a 5KB resource can be transferred in 100ms less time if it >>> were not for cwnd. For a 50KB transfer, an increase of initial cwnd from 2 to 10 reduces the overall time more dramatically >>> - from ~8 round trips to ~5 round trips, saving 3 round trips * 100ms == 300ms of total transfer time. >> >> I said "changing IW would only change the conn duration"? I don't recall that but anyway. >> >> Your examples are correct but as I said these are all short-lived transactions. It is no brainer that their transfers are limited by IW. Changing it from 2 to 10, saves you 3 RTTs since you are stuck with SS for the entire connection. >> >> There are many other applications which don't necessarily spend their lifetime entirely in SS periods, though. >> >> -acbegen >> >>> Finally, if you apply how web pages load (an average web page discovers resources over time, and makes ~49 independent >>> requests totaling ~320KB), there are additive effects to these cwnd-induced stalls. The first resource was stalled by 1 or 2 >>> RTs, then the second resource is stalled by 2-3 RTs, etc. And that is why, as the chart shows quite clearly, that a single- >>> connection protocol for HTTP with current cwnd values is slower than a multi-connection HTTP - the multi-connection HTTP >>> gets more cwnd. >>> >>> This chart is pretty clear, I hope. I've isolated just the one variable to test- init-cwnd, and demonstrated the effects. This >>> effect can be seen in the real world - just open up tcpdump and load a few web pages. I guarantee you'll see it! :-) >>> >>> Mike >>> >>> >>> >>> >>> >>> >>> >>> Maybe, trying to fix TCP to make HTTP is not the best strategy here. >>> >>> >>> >>> Are you saying HTTP should move to a new transport? That seems like a shame. >>> >>> Mike >>> >>> >>> >>> >>> -acbegen >>> >>> >>>> -----Original Message----- >>>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mike Belshe >>>> Sent: Friday, November 26, 2010 1:11 PM >>>> To: tcpm@ietf.org >>>> Subject: [tcpm] A Challenge to TCPM >>>> >>>> Hi, >>>> >>>> I thought I'd add a slightly different perspective to the discussion about initial cwnd. I'm a developer >>> on Chrome& SPDY. >>>> >>>> With SPDY, we want to build an application protocol which is efficient on the transport, good for the >>> network, and faster than >>>> HTTP. But right now, TCP is holding us back because we're trying to accomplish with one connection >>> what HTTP does with >>>> 10+ connections. >>>> >>>> Note: I don't want to make this thread about SPDY. I hope the members of this list agree that the >>> goals of SPDY are good >>>> and will help make TCP a friendly transport for an application protocol like SPDY. >>>> >>>> Background >>>> Unrelated to TCP, HTTP is not very efficient. This has been widely documented and observed for >>> some time. We can easily >>>> demonstrate a more efficient protocol, which transfers 25-35% fewer packets than HTTP and reduces >>> bytes transferred by >>>> 10-15%. Hopefully everyone agrees those are good things for the network. >>>> >>>> Unfortunately, any TCP-based protocol which uses a single connection is at a latency-handicap >>> compared to any protocol that >>>> uses multiple connections. This is due to IW. Further, because bandwidth increases have outpaced >>> RTT decreases, >>>> bandwidth is relatively cheap. So, being efficient on your bandwidth is less critical than being >>> efficient on your round-trips. >>>> >>> >>>> To visualize the effects, please see the attached graph. (Or click here >>> >>> >>> sites.googlegroups.com/a/chromium.org/dev/spdy/effect_of_initial_cwnd_on_plt(1).png?attachauth=ANoY7cpm-y5NA- >>>> zFvGsmxlK81vUh56WsFe-2l5BOkZxENuopgeUcSmO9- >>>> >>> QT9sc784xFZLw0QkSBxmDKgCLxWoVI06vy1u3a7RuS82Nb6YuTHPGeqU_W1c1niKx5W3CzKbzsxnGKlQaectqG8a7cjg5vgU1Gj4c >>>> >>> FLtTi7rKiKHF12j_XkANIwSM0saVdoF6c6gtCDg1_8gKIn8QPVSVp9Cwtw1uFTTWw93XFPQkAmEI2FvRbq6IBg1aI%3D&attredirect >>>> s=0> ) In these tests, I loaded a replica of the facebook landing page through two protocols - one >>> using a single connection in >>> >>>> a semi-efficient manner (an early version of spdy) and another using 6 connections (http). I used a >>> high-bandwidth network >>>> with either 100ms or 200ms of RTT, and then I varied IW from 2pkts all the way to 128pkts. I chose >>> this network >>>> configuration to specifically isolate the effects of high-RTT and IW. As you can see, at low IW, the >>> single-connection protocol >>>> fares poorly compared to the multi-connection protocol. For another writeup on the problem, see >>>> http://dev.chromium.org/spdy/An_Argument_For_Changing_TCP_Slow_Start.pdf >>>> >>>> Today, the fastest way to deliver content is to simply side-step cwnd by use of multiple connections. >>>> >>>> >>>> The Problem >>>> With SPDY (or whatever protocol comes next), we can definitely reduce the number of connections >>> out of the browser by *at >>>> least* a factor of 6. With unfolding of the subdomain tricks that websites have been doing, we can >>> reduce it by a factor of >>>> 10. This has nothing to do with TCP, except I hope that folks on this list appreciate that this goodness: >>> fewer connections - >>>> fewer packets - and fewer bytes. >>>> >>>> The only trouble is that if we abide to the RFCs, fewer connections + fewer packets + fewer bytes >>> equates to slower web >>>> pages. >>>> >>>> But I'm not asking that we increase IW by a factor of 10; because it grows exponentially, if we can >>> increase it to somewhere >>>> in the ~16 range, it's good enough. >>>> >>>> >>>> The Conundrum >>>> More perplexing is that whenever we talk about increasing IW, we tend to think of the static throttle >>> that we have today. If >>>> we increase a static throttle, it affects everything. So protocols that are already bursting 20-30x >>> more packets than they >>>> should (by way of many connections) will burst even more. >>>> >>>> This makes some people want to do nothing... >>>> >>>> At the same time, we also know that cwnd has already been increased on the net at large. This >>> started with use of multiple >>>> connections, multiplied with the use of multiple subdomains, and is now changing by major sites >>> simply increasing or >>>> ignoring cwnd altogther. With so many sites systematically working around cwnd, we know that the >>> current limits can be >>>> increased. We just don't know how much. >>>> >>>> >>>> The Solution? >>>> Is the obvious solution to stop using a static value? It doesn't seem like we're in a one-size-fits-all for >>> IW. >>>> >>>> The IW could either be defined to be protocol-specific, or dynamic based on number of TCP flows >>> between the same two >>>> endpoints. Both of these approaches would offer the benefit of a controlled, increased cwnd to >>> reflect the changes in the net >>>> over the last 2 decades but also not completely unthrottle protocols that are already living on the >>> edge of not having >>>> throttles. >>>> >>>> Finally, if a dynamic throttle is too much to decide upon, at least updating the static value seems >>> appropriate. Jerrry and >>>> Nandita have provided good data for a general-purpose increase to 10. If inefficient protocols are >>> allowed to go that high, >>>> maybe more efficient protocols could be allowed to go higher (with data, of course). >>>> >>>> >>>> Reality Check >>>> Finally, regardless of this debate in the IETF, what is actually going to happen? >>>> >>>> a) IETF does not increase the limit (or continues to wait): >>>> As time goes on, more and more evidence emerges to demonstrate that the current cwnd limits are >>> unnecessarily >>>> conservative. More evidence also emerges that increasing cwnd makes your site faster. More sites >>> start experimenting with >>>> their own values of cwnd. Without a blessed recommendation from the IETF, sites choose whatever >>> values they want. Ben >>> >>>> Strong offered a writeup today which demonstrates this is already happening >>> >>> and-microsoft-cheat-on-slow.html> . >>> >>>> >>>> b) IETF increases the limit: >>>> With data and a specific recommendation, TCP vendors can quickly move to the new >>> recommendations, making their >>>> products more competitive in the marketplace, and better for users. Pressure is alleviated from >>> existing sites to go >>>> renegade, and instead they can rest on the specific findings from this group. With a modern >>> recommendation in hand, all of >>>> us can credibly go after any sites which do choose to use dangerously high cwnd values. Finally, >>> having an officially >>>> increased IW is an enabler for a future of more efficient application level protocols, which are >>> currently at a disadvantage to >>>> their less-efficient counterparts. >>>> >>>> >>>> >>>> >>>> Now, which of these two options carries more risk of internet collapse? Vendors implementing >>> whatever-the-heck-their- >>>> rookie-system-administrator decided to configure? Or an official, controlled and intelligent >>> recommendation from this >>>> group? >>>> >>>> >>>> Thanks to everyone on this list for their hard work over the years - although my email is somewhat >>> critical, be aware that I >>>> have immense gratitude and respect for the veterans of this list that have been keeping the net >>> flowing for so long with such >>>> great success. >>>> Mike >>> >>> >>> >>> >>> >>> ________________________________ >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >>> >>> >> >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Tue Nov 30 08:59:15 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B1B28C0D9 for ; Tue, 30 Nov 2010 08:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.266 X-Spam-Level: X-Spam-Status: No, score=-10.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEt4x2y9h9QO for ; Tue, 30 Nov 2010 08:59:14 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 21A1C3A6C87 for ; Tue, 30 Nov 2010 08:59:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,280,1288594800"; d="scan'208";a="223403135" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 30 Nov 2010 09:00:25 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oAUH0Nvs008399; Tue, 30 Nov 2010 09:00:24 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Nov 2010 17:00:24 +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: Tue, 30 Nov 2010 17:00:20 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0BB766AD@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4CF511F7.4050907@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] alternate IW proposal Thread-Index: AcuQn7in0HDGzMbVRuqr7Aze3VrH2gADqVOg References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <7309FCBCAE981B43ABBE69B31C8D213909B736A327@EUSAACMS0701.eamcs.ericsson.se> <4CF511F7.4050907@isi.edu> From: "Scheffenegger, Richard" To: "Joe Touch" , "Jakob Heitz" X-OriginalArrivalTime: 30 Nov 2010 17:00:24.0380 (UTC) FILETIME=[148FBFC0:01CB90B0] Cc: tcpm@ietf.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 16:59:15 -0000 But "knowledgeable" clients (which have some - hopefully better than the server has - understanding of their side of the network can use the rwin signalled in the 3WHS to cap any excessive IW the server might want to use... Ie. if a client "knows" that the first hope interface is a PPP / SLIP interface (not PPPoE/PPPoA), it might signal a small RWin for the first few segments received. Or grow signalled RWin by one MSS for each data segment received and ACKed. I think such a cooperative signalling would actually help a dynamic/opportunistic IW adjustment scheme, as "known slow" hosts would not impact the IW upward adjustments on the sender side (with small initial RWin, the IW will also be small (smaller than what the sender might use otherwise), thus it will not observe loss while doing the IW. Which would not negatively affet the upwards adjustement for "usual" clients. Such a dynamic IW adjustment scheme could be a system-wide variable, but I believe it was Mark that pointed out, that this will only shift the selection of an initial value one step further out (the kernels boot init value). Also, the exact dyamics aren't all that clear yet. Ie. increase IW by 1 seg, if the balance between total sessions (previous 24hrs) vs. sessions with loss during IW (previous 24hrs) is towards the no-loss-during-IW? Reduce by 1 seg otherwise? Should the metric be absolute time based, or relative to the number of session setups? (systems with mostly persistent connections won't adjust IW (Restart window) all that quick, but may not care either... For the kernel boot time initial value, I would vote for IW10 :) Richard Scheffenegger =20 > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu]=20 > Sent: Dienstag, 30. November 2010 16:02 > To: Jakob Heitz > Cc: tcpm@ietf.org > Subject: Re: [tcpm] alternate IW proposal >=20 >=20 >=20 > On 11/27/2010 9:01 PM, Jakob Heitz wrote: > > Why does IW need to be standardized? > > How will any host/router on the internet change its=20 > behaviour based on=20 > > the standardized value? That is, any host/router other than=20 > the TCP sender. > > Has anyone tried an IW based on advertized receive window=20 > rather than=20 > > on MSS? >=20 > FWIW, advertised receive window is an indication of the=20 > receiver's ability to reorder and accommodate gaps in the=20 > transmission; it is not related to the congestion window,=20 > except that it's not useful to open CWND larger than the=20 > receive window. >=20 > I.e., these values serve completely different purposes. There=20 > is no rationale for setting CWND to the receive window (i.e.,=20 > for thinking that RWIN should be both the upper and lower=20 > bound of CWND). >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From touch@isi.edu Tue Nov 30 09:03:38 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE1028C0F6 for ; Tue, 30 Nov 2010 09:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.381 X-Spam-Level: X-Spam-Status: No, score=-102.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm4wTBtv0PpL for ; Tue, 30 Nov 2010 09:03:37 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id BEA303A6C86 for ; Tue, 30 Nov 2010 09:03:37 -0800 (PST) Received: from [144.118.103.248] (n2-103-248.guest.drexel.edu [144.118.103.248]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oAUH46mc013834 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 30 Nov 2010 09:04:16 -0800 (PST) Message-ID: <4CF52E82.5060908@isi.edu> Date: Tue, 30 Nov 2010 09:04:02 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Scheffenegger, Richard" References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <7309FCBCAE981B43ABBE69B31C8D213909B736A327@EUSAACMS0701.eamcs.ericsson.se> <4CF511F7.4050907@isi.edu> <5FDC413D5FA246468C200652D63E627A0BB766AD@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0BB766AD@LDCMVEXC1-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 17:03:38 -0000 Hi, Richard, FWIW, there have been several attempts to have TCP "know" what its first-hop link is, and tune to that. The biggest problem is that this is most often incorrect - e.g., at home, my first hop is a 54 Mbps WiFi link, but I'm limited by my DSL modem. The same is true for anyone on a satellite link (e.g., DirectPC), or anyone using a cellphone as a 'tethered' modem (via Bluetooth or WiFi). The RWIN is supposed to indicate the receiver's ability to: a) buffer b) reorder (related to (a) RWIN has no relation to CWND, nor should it. CWND is a path property; RWIN is an endpoint property. Joe On 11/30/2010 9:00 AM, Scheffenegger, Richard wrote: > > But "knowledgeable" clients (which have some - hopefully better than the > server has - understanding of their side of the network can use the rwin > signalled in the 3WHS to cap any excessive IW the server might want to > use... > > Ie. if a client "knows" that the first hope interface is a PPP / SLIP > interface (not PPPoE/PPPoA), it might signal a small RWin for the first > few segments received. Or grow signalled RWin by one MSS for each data > segment received and ACKed. > > > I think such a cooperative signalling would actually help a > dynamic/opportunistic IW adjustment scheme, as "known slow" hosts would > not impact the IW upward adjustments on the sender side (with small > initial RWin, the IW will also be small (smaller than what the sender > might use otherwise), thus it will not observe loss while doing the IW. > Which would not negatively affet the upwards adjustement for "usual" > clients. > > Such a dynamic IW adjustment scheme could be a system-wide variable, but > I believe it was Mark that pointed out, that this will only shift the > selection of an initial value one step further out (the kernels boot > init value). > > Also, the exact dyamics aren't all that clear yet. > > Ie. increase IW by 1 seg, if the balance between total sessions > (previous 24hrs) vs. sessions with loss during IW (previous 24hrs) is > towards the no-loss-during-IW? Reduce by 1 seg otherwise? > > Should the metric be absolute time based, or relative to the number of > session setups? (systems with mostly persistent connections won't adjust > IW (Restart window) all that quick, but may not care either... > > > For the kernel boot time initial value, I would vote for IW10 :) > > > Richard Scheffenegger > > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Dienstag, 30. November 2010 16:02 >> To: Jakob Heitz >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] alternate IW proposal >> >> >> >> On 11/27/2010 9:01 PM, Jakob Heitz wrote: >>> Why does IW need to be standardized? >>> How will any host/router on the internet change its >> behaviour based on >>> the standardized value? That is, any host/router other than >> the TCP sender. >>> Has anyone tried an IW based on advertized receive window >> rather than >>> on MSS? >> >> FWIW, advertised receive window is an indication of the >> receiver's ability to reorder and accommodate gaps in the >> transmission; it is not related to the congestion window, >> except that it's not useful to open CWND larger than the >> receive window. >> >> I.e., these values serve completely different purposes. There >> is no rationale for setting CWND to the receive window (i.e., >> for thinking that RWIN should be both the upper and lower >> bound of CWND). >> >> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From mallman@icir.org Tue Nov 30 09:03:50 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D547428C10E for ; Tue, 30 Nov 2010 09:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.545 X-Spam-Level: X-Spam-Status: No, score=-105.545 tagged_above=-999 required=5 tests=[AWL=-0.936, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKwDAuFW46wL for ; Tue, 30 Nov 2010 09:03:49 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 879D928C107 for ; Tue, 30 Nov 2010 09:03:49 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAUH506F023989 for ; Tue, 30 Nov 2010 09:05:01 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id ED5732657E7F for ; Tue, 30 Nov 2010 12:05:00 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Dance the Night Away MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma11962-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 30 Nov 2010 12:05:00 -0500 Sender: mallman@icir.org Message-Id: <20101130170500.ED5732657E7F@lawyers.icir.org> Subject: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 17:03:50 -0000 ----------ma11962-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- I *think* this might be a reasonable summary of the recent IW threads. o Everyone understands that *within* a TCP connection TCP will find the "right" cwnd as it always has. So, regardless of IW setting (1, 3, 10, 1000, ...) mistaken initial assumptions will be detected and normal congestion control actions taken to address these problems in the initial parameters within the given flow. o Mistakes (and in particular, systemic mistakes) in the initial parameter choices across connections from some host are not mitigated in any fashion with any static IW. (Certainly a stack *can* cache CC state and leverage it in the future, but it is not currently *compelled* to do so.) o There is not likely a one-size-fits-all set of initial parameters for TCP. o We have traditionally addressed this heterogeneity by picking initial parameters that are "safe" in the overwhelming majority of the cases. o And, some folks think we have seen enough evidence that IW=10 is likely to be safe initial parameter choice for general use in the overwhelming majority of the cases in the Internet. o However, choosing initial parameters is difficult because its hard to understand the implications of such choices both at scale and across a broad range of situations. o And, so, some folks are uneasy because there are for sure pathologies and even more there is a dynamic that is unknown. o So, in some sense this leaves us stuck between two sets of opinions and without any good way to bring enough data to bear on the question without deciding to just let IW=10 happen and then observing things to see if we were right or wrong. o In an ideal world we'd not be trying to puzzle through tuning initial settings every once in a while, but rather there would be some more automated way to go about setting them. o Another thought that seems to have been accepted to some degree is "go slow". I.e., not jump from 3 to 10, but take smaller steps (which I tried to codify in a static fashion in my rockheaded I-D). This lets us learn as we go without as much possibility of over-shoot. Joe and I argued too much. On and off the list (yeah- we spared you some of it!). But, I think we converged (although I am not sure my esteemed colleague would frame it as such!). I think the question comes down to how much error can we tolerate in the IW and for how long. So, off-list I framed this to Joe and Aki. Its basically Joe's idea, but with a few more details. As such, Joe will no doubt correct it. :) So, do something like this: o On Jul/1 set IW=3 [i.e., RFC5681]. Also, start two counters for each possible IW, 1--3: total number of connections using the given IW and number of connections using that IW that experienced loss in the initial window. (Remember, just because a connection can use an IW of X doesn't mean it will have enough data to do so or that the advertised window will allow, hence, counters for all possible values.) This costs IW*2 system-wide counters---which seems like a minor state burden (e.g., using 8 byte counters would cost 160 whole bytes of memory for IW=10). Plus, its easy enough to retain across boots. o Update the counters for every connection. Tracking the initial window size and any retransmits from that window is a bit of added complexity, but not onerous and especially not when compared with the possible benefits of being able to use a larger initial cwnd. o On Aug/1 (one month later) consider the counters. If each IW setting shows > 95% success (no loss in the initial window) then decide we can tolerate the fallout of IW=3 and bump IW to 4, clear the counters and move on. If not all IW settings show > 95% success then set the IW to the maximum IW that both (1) shows 95% success and (2) all lower values of IW have 95% success. Again, clear the counters. o Perhaps the mechanism can be augmented with some minimum number of connection attempts---either per IW or in the aggregate. And, if we don't meet the min then we don't adjust the IW and we don't clear the counters, but we wait until the first of the next month to re-consider after gathering more evidence. o You could always notice a IW of X is not working well before the first of the month and reduce the IW. That would be strictly more conservative and so just fine. o This scheme *does not* try to achieve congestion control across connections. If IW=X fails now because of something systemic (say talking to some badly connected machine on the other side of the world) then it will fail in now+5sec, too. And, in fact, for days or weeks to come. And, if that is only a small fraction of the activity then it might continue to fail across all of time. So, we should think of this as empirically arriving at an initial parameter we can live with over the long haul and not somehow part of short-term congestion control. o This scheme bounds the badness. For some IW=X we can say that: - IWs of 1..X-1 worked in over 95% of the cases during the previous month and so while we cannot say for sure that all these IWs will work this month we have some direct evidence in the relevant context that they likely will. - IW=X could fail 100% of the time for up to one month. However, since X is at most one more segment than what worked in the previous month the imposed loss is likely minor. And, further, it'd happen in the second RTT anyway given the usual cwnd increase. (So, this is well within the bounds of the usual slow start overshoot error.) o So, we can use the time period (one month in this sketch) and the success rate (95% in this sketch) to tune our tolerance of badness. (I picked these numbers out of thin air, basically. But, to my eye they look pretty OK.) o (Everyone doesn't have to decide on the first of the month. It was just easier to type that way. It could be "one month since last considered".) o One can always be more conservative. E.g., factor out some particular host with a known issue and use the RFC5681 IW (or lower) with that host and use the automatically adjusted IW for the remainder of the hosts. E.g., not increase IW per the above unless N successive time periods suggest the current IW is OK. E.g., use a threshold more than 95%. Etc. o And, if one doesn't want to maintain the state then the IW in RFC5681 stands. I am hopeful Joe will write it up as I think that perhaps it addresses much of what we have been talking about and perhaps we can then converge. allman ----------ma11962-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz1LrwACgkQWyrrWs4yIs5D2wCeMLkn8nZNpXwIcebKsGuo2niM 7AAAmQH2g7BX6KDfeA+mp52ClriPP8Tx =4RDD -----END PGP SIGNATURE----- ----------ma11962-1-- From touch@isi.edu Tue Nov 30 09:11:48 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0107328C129 for ; Tue, 30 Nov 2010 09:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.448 X-Spam-Level: X-Spam-Status: No, score=-101.448 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBevkRABNc19 for ; Tue, 30 Nov 2010 09:11:46 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D1D7B28C10E for ; Tue, 30 Nov 2010 09:11:45 -0800 (PST) Received: from [144.118.103.248] (n2-103-248.guest.drexel.edu [144.118.103.248]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAUHCSQQ019092 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 30 Nov 2010 09:12:38 -0800 (PST) Message-ID: <4CF5307B.9030101@isi.edu> Date: Tue, 30 Nov 2010 09:12:27 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: mallman@icir.org References: <20101130170500.ED5732657E7F@lawyers.icir.org> In-Reply-To: <20101130170500.ED5732657E7F@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 17:11:48 -0000 Hi, all, Some additional info. I am in the process of writing this up, but also trying to participate in a conference today ;-) Joe On 11/30/2010 9:05 AM, Mark Allman wrote: > > Folks- > ... > So, off-list I framed this to Joe and Aki. Its basically Joe's > idea, but with a few more details. As such, Joe will no doubt > correct it. :) So, do something like this: > > o On Jul/1 set IW=3 [i.e., RFC5681]. Also, start two counters for > each possible IW, 1--3: total number of connections using the > given IW and number of connections using that IW that > experienced loss in the initial window. > > (Remember, just because a connection can use an IW of X doesn't > mean it will have enough data to do so or that the advertised > window will allow, hence, counters for all possible values.) > > This costs IW*2 system-wide counters---which seems like a minor > state burden (e.g., using 8 byte counters would cost 160 whole > bytes of memory for IW=10). Plus, its easy enough to retain across > boots. > > o Update the counters for every connection. > > Tracking the initial window size and any retransmits from that > window is a bit of added complexity, but not onerous and > especially not when compared with the possible benefits of being > able to use a larger initial cwnd. Note - these are simple +1 counters per connection, and deciding if the IW fails happens ONLY if there is a retransmission. In the fast-path case, there's only ONE additional opcode required. > o On Aug/1 (one month later) consider the counters. > > If each IW setting shows> 95% success (no loss in the initial > window) then decide we can tolerate the fallout of IW=3 and bump > IW to 4, clear the counters and move on. > > If not all IW settings show> 95% success then set the IW to the > maximum IW that both (1) shows 95% success and (2) all lower > values of IW have 95% success. Again, clear the counters. > > o Perhaps the mechanism can be augmented with some minimum number > of connection attempts---either per IW or in the aggregate. > And, if we don't meet the min then we don't adjust the IW and we > don't clear the counters, but we wait until the first of the > next month to re-consider after gathering more evidence. > > o You could always notice a IW of X is not working well before the > first of the month and reduce the IW. That would be strictly > more conservative and so just fine. > > o This scheme *does not* try to achieve congestion control across > connections. If IW=X fails now because of something systemic > (say talking to some badly connected machine on the other side > of the world) then it will fail in now+5sec, too. And, in fact, > for days or weeks to come. And, if that is only a small > fraction of the activity then it might continue to fail across > all of time. So, we should think of this as empirically > arriving at an initial parameter we can live with over the long > haul and not somehow part of short-term congestion control. > > o This scheme bounds the badness. For some IW=X we can say that: > > - IWs of 1..X-1 worked in over 95% of the cases during the > previous month and so while we cannot say for sure that all > these IWs will work this month we have some direct evidence > in the relevant context that they likely will. > > - IW=X could fail 100% of the time for up to one month. > However, since X is at most one more segment than what > worked in the previous month the imposed loss is likely > minor. And, further, it'd happen in the second RTT anyway > given the usual cwnd increase. (So, this is well within the > bounds of the usual slow start overshoot error.) > > o So, we can use the time period (one month in this sketch) and > the success rate (95% in this sketch) to tune our tolerance of > badness. (I picked these numbers out of thin air, basically. > But, to my eye they look pretty OK.) > > o (Everyone doesn't have to decide on the first of the month. It > was just easier to type that way. It could be "one month since > last considered".) > > o One can always be more conservative. > > E.g., factor out some particular host with a known issue and use > the RFC5681 IW (or lower) with that host and use the > automatically adjusted IW for the remainder of the hosts. > > E.g., not increase IW per the above unless N successive time > periods suggest the current IW is OK. > > E.g., use a threshold more than 95%. > > Etc. > > o And, if one doesn't want to maintain the state then the IW in > RFC5681 stands. > > I am hopeful Joe will write it up as I think that perhaps it addresses > much of what we have been talking about and perhaps we can then > converge. > > allman > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mallman@icir.org Tue Nov 30 09:17:10 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED83328C0F6 for ; Tue, 30 Nov 2010 09:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWLXEXtmaA-h for ; Tue, 30 Nov 2010 09:17:10 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 32D0D28C0E8 for ; Tue, 30 Nov 2010 09:17:10 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAUHILBk025534; Tue, 30 Nov 2010 09:18:22 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id BC82626585D9; Tue, 30 Nov 2010 12:18:21 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CF5307B.9030101@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Dance the Night Away MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma12765-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 30 Nov 2010 12:18:21 -0500 Sender: mallman@icir.org Message-Id: <20101130171821.BC82626585D9@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 17:17:11 -0000 ----------ma12765-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Some additional info. I am in the process of writing this up, but > also trying to participate in a conference today ;-) Excuses, excuses ... > Note - these are simple +1 counters per connection, and deciding if > the IW fails happens ONLY if there is a retransmission. In the > fast-path case, there's only ONE additional opcode required. (There may be a bit more complexity in that you need to figure out the size of the IW to index the right counter. And, you'll need to keep track of the sequence range of the initial window temporarily to correctly classify loss. But, this is all minor implementation detail.) allman ----------ma12765-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz1Md0ACgkQWyrrWs4yIs4EugCeJ9a23R7jeJrunVJ0nAhWhVBD HTUAmQFYr1jVTOgA0lha55kYggPri22p =HS5e -----END PGP SIGNATURE----- ----------ma12765-1-- From jakob.heitz@ericsson.com Tue Nov 30 10:08:58 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669563A6C20 for ; Tue, 30 Nov 2010 10:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFAbsnRRbTnp for ; Tue, 30 Nov 2010 10:08:54 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id AB07E3A6BCC for ; Tue, 30 Nov 2010 10:08:54 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oAUI9avB015307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Nov 2010 12:09:37 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.213]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 30 Nov 2010 13:09:36 -0500 From: Jakob Heitz To: Joe Touch , Yuchung Cheng Date: Tue, 30 Nov 2010 13:09:34 -0500 Thread-Topic: [tcpm] alternate IW proposal Thread-Index: AcuQlxT/aGA+Z8pYRC6WHONfGqnlWAAIdkIw Message-ID: <7309FCBCAE981B43ABBE69B31C8D213909B73BB08B@EUSAACMS0701.eamcs.ericsson.se> References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <4CF26596.7010500@isi.edu> <4CF5037F.4000602@isi.edu> In-Reply-To: <4CF5037F.4000602@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" , "mallman@icir.org" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 18:08:58 -0000 > -----Original Message----- > Behalf Of Joe Touch > Sent: Tuesday, November 30, 2010 6:01 AM > > 2) auto-adjusting IW can still make mistakes >=20 > yes, but over time if it does it will correct. > fixed IW will not More often than not, auto-adjustment makes things worse. If the feedback loop gets relevant feedback, the time constants of the loop are correct and the loop is linear are all conditions for making it better. If any of those are wrong, auto-adjustment will make it worse. Simple example: without limits, it could go to 0 or below. There are many more not-so-simple examples. -- Jakob Heitz. = From touch@isi.edu Tue Nov 30 10:32:02 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A203A6C25 for ; Tue, 30 Nov 2010 10:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.038 X-Spam-Level: X-Spam-Status: No, score=-102.038 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiEdDlw+EiNu for ; Tue, 30 Nov 2010 10:32:02 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 00C743A6C04 for ; Tue, 30 Nov 2010 10:32:01 -0800 (PST) Received: from [144.118.103.248] (n2-103-248.guest.drexel.edu [144.118.103.248]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id oAUIWGlL026467 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 30 Nov 2010 10:32:28 -0800 (PST) Message-ID: <4CF5432F.3010908@isi.edu> Date: Tue, 30 Nov 2010 10:32:15 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jakob Heitz References: <20101118202844.C3C7B2539D2E@lawyers.icir.org> <4CE58F37.7000407@isi.edu> <4CF26596.7010500@isi.edu> <4CF5037F.4000602@isi.edu> <7309FCBCAE981B43ABBE69B31C8D213909B73BB08B@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213909B73BB08B@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: oAUIWGlL026467 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" , "mallman@icir.org" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 18:32:02 -0000 On 11/30/2010 10:09 AM, Jakob Heitz wrote: > >> -----Original Message----- >> Behalf Of Joe Touch >> Sent: Tuesday, November 30, 2010 6:01 AM >> >> 2) auto-adjusting IW can still make mistakes >> >> yes, but over time if it does it will correct. >> fixed IW will not > > More often than not, auto-adjustment makes things worse. > > If the feedback loop gets relevant feedback, the time constants > of the loop are correct and the loop is linear are all > conditions for making it better. > If any of those are wrong, auto-adjustment will make it worse. The time constants we're talking about here are faster than the IETF, but slower than TCP CC, i.e., O(weeks to months). The feedback is based on whether you have loss during the IW. Although your argument about these is true (and somewhat of a platitude about control loops), we've done this many times before in TCP and arguably got it reasonably right. > Simple example: without limits, it could go to 0 or below. > There are many more not-so-simple examples. It would never go below 3, because 3 is what you have now. Joe From mallman@icir.org Tue Nov 30 10:51:50 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53213A6C19 for ; Tue, 30 Nov 2010 10:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.162 X-Spam-Level: X-Spam-Status: No, score=-106.162 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leOd7JqE2sYK for ; Tue, 30 Nov 2010 10:51:48 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id D73BB3A6B9F for ; Tue, 30 Nov 2010 10:51:47 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAUIqaIF004911; Tue, 30 Nov 2010 10:52:36 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2C8D1265B26C; Tue, 30 Nov 2010 13:52:36 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CF5432F.3010908@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Dance the Night Away MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma18417-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 30 Nov 2010 13:52:36 -0500 Sender: mallman@icir.org Message-Id: <20101130185236.2C8D1265B26C@lawyers.icir.org> Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 18:51:51 -0000 ----------ma18417-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > The time constants we're talking about here are faster than the > IETF, but slower than TCP CC, i.e., O(weeks to months). O(weeks to months to years to decades) ----------ma18417-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz1R/MACgkQWyrrWs4yIs6SOgCfbFzKCF+89Cj9ZZPvwnDeJpJp 8mkAni+AVXDSyg3K9n7AXjuXlvImSK1y =bivL -----END PGP SIGNATURE----- ----------ma18417-1-- From ycheng@google.com Tue Nov 30 10:57:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B169D3A6C2E for ; Tue, 30 Nov 2010 10:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.709 X-Spam-Level: X-Spam-Status: No, score=-104.709 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FEG3hEt9q5I for ; Tue, 30 Nov 2010 10:57:56 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B7B3B28C0F0 for ; Tue, 30 Nov 2010 10:57:55 -0800 (PST) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id oAUIx7EV004815 for ; Tue, 30 Nov 2010 10:59:07 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291143547; bh=raU/UsbimaIHIJ33UgiFAo8LDOo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dF53y7DjVuBTuOQGUHI070vU88AzCUJHzg+qosATV+/IW6kdTt+D5qg8O3bqv+aOL ZRy+9ommL7sicy8TnCW8w== Received: from vws14 (vws14.prod.google.com [10.241.21.142]) by kpbe16.cbf.corp.google.com with ESMTP id oAUIwojp025466 for ; Tue, 30 Nov 2010 10:59:06 -0800 Received: by vws14 with SMTP id 14so2122776vws.37 for ; Tue, 30 Nov 2010 10:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=cGTVGrW5/IIEvbHVAAysI5gvGOV8kxzIU4bwShP/Ddk=; b=h/wzxqFcbKnkT9+w6t81pZn9ziKgKBZnxmOxpld5F7pOY2TuIevpHGui4ji+rIY7Bf NI5atI4PvhLKtECTZsZw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=ZsVyWBTUpOm8habsxsoiSi9uln5754k5t36xziE5iT2I47baJkTI7wDziTyVsRaAkn 2b5AV+Z4T5cn62l8Mr2A== Received: by 10.220.179.73 with SMTP id bp9mr752637vcb.216.1291143544954; Tue, 30 Nov 2010 10:59:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.159.66 with HTTP; Tue, 30 Nov 2010 10:58:44 -0800 (PST) In-Reply-To: <20101130170500.ED5732657E7F@lawyers.icir.org> References: <20101130170500.ED5732657E7F@lawyers.icir.org> From: Yuchung Cheng Date: Tue, 30 Nov 2010 10:58:44 -0800 Message-ID: To: mallman@icir.org Content-Type: multipart/alternative; boundary=90e6ba4fc58259e0ac049649c825 X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 18:57:57 -0000 --90e6ba4fc58259e0ac049649c825 Content-Type: text/plain; charset=ISO-8859-1 I am looking forward to see the doc. Are we asking for volunteers to execute this plan? or we already have some? On Tue, Nov 30, 2010 at 9:05 AM, Mark Allman wrote: > > Folks- > > I *think* this might be a reasonable summary of the recent IW > threads. > > o Everyone understands that *within* a TCP connection TCP will > find the "right" cwnd as it always has. So, regardless of IW > setting (1, 3, 10, 1000, ...) mistaken initial assumptions will > be detected and normal congestion control actions taken to > address these problems in the initial parameters within the > given flow. > > o Mistakes (and in particular, systemic mistakes) in the initial > parameter choices across connections from some host are not > mitigated in any fashion with any static IW. (Certainly a stack > *can* cache CC state and leverage it in the future, but it is > not currently *compelled* to do so.) > > o There is not likely a one-size-fits-all set of initial > parameters for TCP. > > o We have traditionally addressed this heterogeneity by picking > initial parameters that are "safe" in the overwhelming majority > of the cases. > > o And, some folks think we have seen enough evidence that IW=10 is > likely to be safe initial parameter choice for general use in > the overwhelming majority of the cases in the Internet. > > o However, choosing initial parameters is difficult because its > hard to understand the implications of such choices both at > scale and across a broad range of situations. > > o And, so, some folks are uneasy because there are for sure > pathologies and even more there is a dynamic that is unknown. > > o So, in some sense this leaves us stuck between two sets of > opinions and without any good way to bring enough data to bear > on the question without deciding to just let IW=10 happen and > then observing things to see if we were right or wrong. > > o In an ideal world we'd not be trying to puzzle through tuning > initial settings every once in a while, but rather there would > be some more automated way to go about setting them. > > o Another thought that seems to have been accepted to some degree > is "go slow". I.e., not jump from 3 to 10, but take smaller > steps (which I tried to codify in a static fashion in my > rockheaded I-D). This lets us learn as we go without as much > possibility of over-shoot. > > Joe and I argued too much. On and off the list (yeah- we spared you > some of it!). But, I think we converged (although I am not sure my > esteemed colleague would frame it as such!). I think the question > comes down to how much error can we tolerate in the IW and for how > long. > > So, off-list I framed this to Joe and Aki. Its basically Joe's > idea, but with a few more details. As such, Joe will no doubt > correct it. :) So, do something like this: > I am looking forward to Joe's writeup. One early question: has anyone sign up to execute this months long measurement plan? > o On Jul/1 set IW=3 [i.e., RFC5681]. Also, start two counters for > each possible IW, 1--3: total number of connections using the > given IW and number of connections using that IW that > experienced loss in the initial window. > > (Remember, just because a connection can use an IW of X doesn't > mean it will have enough data to do so or that the advertised > window will allow, hence, counters for all possible values.) > > This costs IW*2 system-wide counters---which seems like a minor > state burden (e.g., using 8 byte counters would cost 160 whole > bytes of memory for IW=10). Plus, its easy enough to retain across > boots. > > o Update the counters for every connection. > > Tracking the initial window size and any retransmits from that > window is a bit of added complexity, but not onerous and > especially not when compared with the possible benefits of being > able to use a larger initial cwnd. > > o On Aug/1 (one month later) consider the counters. > > If each IW setting shows > 95% success (no loss in the initial > window) then decide we can tolerate the fallout of IW=3 and bump > IW to 4, clear the counters and move on. > > If not all IW settings show > 95% success then set the IW to the > maximum IW that both (1) shows 95% success and (2) all lower > values of IW have 95% success. Again, clear the counters. > > o Perhaps the mechanism can be augmented with some minimum number > of connection attempts---either per IW or in the aggregate. > And, if we don't meet the min then we don't adjust the IW and we > don't clear the counters, but we wait until the first of the > next month to re-consider after gathering more evidence. > > o You could always notice a IW of X is not working well before the > first of the month and reduce the IW. That would be strictly > more conservative and so just fine. > > o This scheme *does not* try to achieve congestion control across > connections. If IW=X fails now because of something systemic > (say talking to some badly connected machine on the other side > of the world) then it will fail in now+5sec, too. And, in fact, > for days or weeks to come. And, if that is only a small > fraction of the activity then it might continue to fail across > all of time. So, we should think of this as empirically > arriving at an initial parameter we can live with over the long > haul and not somehow part of short-term congestion control. > > o This scheme bounds the badness. For some IW=X we can say that: > > - IWs of 1..X-1 worked in over 95% of the cases during the > previous month and so while we cannot say for sure that all > these IWs will work this month we have some direct evidence > in the relevant context that they likely will. > > - IW=X could fail 100% of the time for up to one month. > However, since X is at most one more segment than what > worked in the previous month the imposed loss is likely > minor. And, further, it'd happen in the second RTT anyway > given the usual cwnd increase. (So, this is well within the > bounds of the usual slow start overshoot error.) > > o So, we can use the time period (one month in this sketch) and > the success rate (95% in this sketch) to tune our tolerance of > badness. (I picked these numbers out of thin air, basically. > But, to my eye they look pretty OK.) > > o (Everyone doesn't have to decide on the first of the month. It > was just easier to type that way. It could be "one month since > last considered".) > > o One can always be more conservative. > > E.g., factor out some particular host with a known issue and use > the RFC5681 IW (or lower) with that host and use the > automatically adjusted IW for the remainder of the hosts. > > E.g., not increase IW per the above unless N successive time > periods suggest the current IW is OK. > > E.g., use a threshold more than 95%. > > Etc. > > o And, if one doesn't want to maintain the state then the IW in > RFC5681 stands. > > I am hopeful Joe will write it up as I think that perhaps it addresses > much of what we have been talking about and perhaps we can then > converge. > > allman > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --90e6ba4fc58259e0ac049649c825 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am looking forward to see the doc.

Are we asking for v= olunteers to execute this plan? or we already have some?=A0

On Tue, Nov 30, 2010 at 9:05 AM, Mark Allman <mallman@icir.org>= ; wrote:

Folks-

I *think* this might be a reasonable summary of the recent IW
threads.

=A0o Everyone understands that *within* a TCP connection TCP will
=A0 =A0find the "right" cwnd as it always has. =A0So, regardless= of IW
=A0 =A0setting (1, 3, 10, 1000, ...) mistaken initial assumptions will
=A0 =A0be detected and normal congestion control actions taken to
=A0 =A0address these problems in the initial parameters within the
=A0 =A0given flow.

=A0o Mistakes (and in particular, systemic mistakes) in the initial
=A0 =A0parameter choices across connections from some host are not
=A0 =A0mitigated in any fashion with any static IW. =A0(Certainly a stack<= br> =A0 =A0*can* cache CC state and leverage it in the future, but it is
=A0 =A0not currently *compelled* to do so.)

=A0o There is not likely a one-size-fits-all set of initial
=A0 =A0parameters for TCP.

=A0o We have traditionally addressed this heterogeneity by picking
=A0 =A0initial parameters that are "safe" in the overwhelming ma= jority
=A0 =A0of the cases.

=A0o And, some folks think we have seen enough evidence that IW=3D10 is =A0 =A0likely to be safe initial parameter choice for general use in
=A0 =A0the overwhelming majority of the cases in the Internet.

=A0o However, choosing initial parameters is difficult because its
=A0 =A0hard to understand the implications of such choices both at
=A0 =A0scale and across a broad range of situations.

=A0o And, so, some folks are uneasy because there are for sure
=A0 =A0pathologies and even more there is a dynamic that is unknown.

=A0o So, in some sense this leaves us stuck between two sets of
=A0 =A0opinions and without any good way to bring enough data to bear
=A0 =A0on the question without deciding to just let IW=3D10 happen and
=A0 =A0then observing things to see if we were right or wrong.

=A0o In an ideal world we'd not be trying to puzzle through tuning
=A0 =A0initial settings every once in a while, but rather there would
=A0 =A0be some more automated way to go about setting them.

=A0o Another thought that seems to have been accepted to some degree
=A0 =A0is "go slow". =A0I.e., not jump from 3 to 10, but take sm= aller
=A0 =A0steps (which I tried to codify in a static fashion in my
=A0 =A0rockheaded I-D). =A0This lets us learn as we go without as much
=A0 =A0possibility of over-shoot.

Joe and I argued too much. =A0On and off the list (yeah- we spared you
some of it!). =A0But, I think we converged (although I am not sure my
esteemed colleague would frame it as such!). =A0I think the question
comes down to how much error can we tolerate in the IW and for how
long.

So, off-list I framed this to Joe and Aki. =A0Its basically Joe's
idea, but with a few more details. =A0As such, Joe will no doubt
correct it. :) =A0So, do something like this:
I am loo= king forward to Joe's writeup. One early question: has anyone sign up t= o execute this months long measurement plan?


=A0o On Jul/1 set IW=3D3 [i.e., RFC5681]. =A0Also, start two counters for<= br> =A0 =A0each possible IW, 1--3: total number of connections using the
=A0 =A0given IW and number of connections using that IW that
=A0 =A0experienced loss in the initial window.

=A0 =A0(Remember, just because a connection can use an IW of X doesn't=
=A0 =A0mean it will have enough data to do so or that the advertised
=A0 =A0window will allow, hence, counters for all possible values.)

=A0 =A0This costs IW*2 system-wide counters---which seems like a minor
=A0 =A0state burden (e.g., using 8 byte counters would cost 160 whole
=A0 =A0bytes of memory for IW=3D10). =A0Plus, its easy enough to retain ac= ross
=A0 =A0boots.

=A0o Update the counters for every connection.

=A0 =A0Tracking the initial window size and any retransmits from that
=A0 =A0window is a bit of added complexity, but not onerous and
=A0 =A0especially not when compared with the possible benefits of being =A0 =A0able to use a larger initial cwnd.

=A0o On Aug/1 (one month later) consider the counters.

=A0 =A0If each IW setting shows > 95% success (no loss in the initial =A0 =A0window) then decide we can tolerate the fallout of IW=3D3 and bump<= br> =A0 =A0IW to 4, clear the counters and move on.

=A0 =A0If not all IW settings show > 95% success then set the IW to the=
=A0 =A0maximum IW that both (1) shows 95% success and (2) all lower
=A0 =A0values of IW have 95% success. =A0Again, clear the counters.

=A0o Perhaps the mechanism can be augmented with some minimum number
=A0 =A0of connection attempts---either per IW or in the aggregate.
=A0 =A0And, if we don't meet the min then we don't adjust the IW a= nd we
=A0 =A0don't clear the counters, but we wait until the first of the =A0 =A0next month to re-consider after gathering more evidence.

=A0o You could always notice a IW of X is not working well before the
=A0 =A0first of the month and reduce the IW. =A0That would be strictly
=A0 =A0more conservative and so just fine.

=A0o This scheme *does not* try to achieve congestion control across
=A0 =A0connections. =A0If IW=3DX fails now because of something systemic =A0 =A0(say talking to some badly connected machine on the other side
=A0 =A0of the world) then it will fail in now+5sec, too. =A0And, in fact,<= br> =A0 =A0for days or weeks to come. =A0And, if that is only a small
=A0 =A0fraction of the activity then it might continue to fail across
=A0 =A0all of time. =A0So, we should think of this as empirically
=A0 =A0arriving at an initial parameter we can live with over the long
=A0 =A0haul and not somehow part of short-term congestion control.

=A0o This scheme bounds the badness. =A0For some IW=3DX we can say that:
=A0 =A0 =A0- IWs of 1..X-1 worked in over 95% of the cases during the
=A0 =A0 =A0 =A0previous month and so while we cannot say for sure that all=
=A0 =A0 =A0 =A0these IWs will work this month we have some direct evidence=
=A0 =A0 =A0 =A0in the relevant context that they likely will.

=A0 =A0 =A0- IW=3DX could fail 100% of the time for up to one month.
=A0 =A0 =A0 =A0However, since X is at most one more segment than what
=A0 =A0 =A0 =A0worked in the previous month the imposed loss is likely
=A0 =A0 =A0 =A0minor. =A0And, further, it'd happen in the second RTT a= nyway
=A0 =A0 =A0 =A0given the usual cwnd increase. =A0(So, this is well within = the
=A0 =A0 =A0 =A0bounds of the usual slow start overshoot error.)

=A0o So, we can use the time period (one month in this sketch) and
=A0 =A0the success rate (95% in this sketch) to tune our tolerance of
=A0 =A0badness. =A0(I picked these numbers out of thin air, basically.
=A0 =A0But, to my eye they look pretty OK.)

=A0o (Everyone doesn't have to decide on the first of the month. =A0It=
=A0 =A0was just easier to type that way. =A0It could be "one month si= nce
=A0 =A0last considered".)

=A0o One can always be more conservative.

=A0 =A0E.g., factor out some particular host with a known issue and use =A0 =A0the RFC5681 IW (or lower) with that host and use the
=A0 =A0automatically adjusted IW for the remainder of the hosts.

=A0 =A0E.g., not increase IW per the above unless N successive time
=A0 =A0periods suggest the current IW is OK.

=A0 =A0E.g., use a threshold more than 95%.

=A0 =A0Etc.

=A0o And, if one doesn't want to maintain the state then the IW in
=A0 =A0RFC5681 stands.

I am hopeful Joe will write it up as I think that perhaps it addresses
much of what we have been talking about and perhaps we can then
converge.

allman




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


--90e6ba4fc58259e0ac049649c825-- From mallman@icir.org Tue Nov 30 11:03:55 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 435D83A6C94 for ; Tue, 30 Nov 2010 11:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.759 X-Spam-Level: X-Spam-Status: No, score=-105.759 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyVeeS104VKa for ; Tue, 30 Nov 2010 11:03:54 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 8FABD3A6B9F for ; Tue, 30 Nov 2010 11:03:54 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAUJ54n5006676; Tue, 30 Nov 2010 11:05:04 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 28FC1265B986; Tue, 30 Nov 2010 14:05:04 -0500 (EST) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Dance the Night Away MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma19167-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 30 Nov 2010 14:05:04 -0500 Sender: mallman@icir.org Message-Id: <20101130190504.28FC1265B986@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 19:03:55 -0000 ----------ma19167-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I am looking forward to Joe's writeup. One early question: has anyone > sign up to execute this months long measurement plan? This is not a month's long measurement plan. This is how you run your stack. From now on. I.e., it puzzles through what IW is right for your situation (connectivity, mix of traffic, etc.) on a continual month-by-month basis. (Or, whatever time period we agree on.) The monitoring is the price of using an IW bigger than RFC5681 allows. allman ----------ma19167-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz1SuAACgkQWyrrWs4yIs7L2wCfWlfSN+q6g7ZLFG0xLES3La5G DbkAoJqIV7bctnAgktfRN0lYuPN2sYUA =HJS3 -----END PGP SIGNATURE----- ----------ma19167-1-- From touch@isi.edu Tue Nov 30 11:08:31 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7F928C103 for ; Tue, 30 Nov 2010 11:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.082 X-Spam-Level: X-Spam-Status: No, score=-102.082 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esC2Uut6lxCQ for ; Tue, 30 Nov 2010 11:08:31 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 064723A6C2D for ; Tue, 30 Nov 2010 11:08:31 -0800 (PST) Received: from [144.118.103.248] (n2-103-248.guest.drexel.edu [144.118.103.248]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAUJ8YcZ014347 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 30 Nov 2010 11:08:49 -0800 (PST) Message-ID: <4CF54BB1.9040908@isi.edu> Date: Tue, 30 Nov 2010 11:08:33 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: mallman@icir.org References: <20101130185236.2C8D1265B26C@lawyers.icir.org> In-Reply-To: <20101130185236.2C8D1265B26C@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 19:08:31 -0000 On 11/30/2010 10:52 AM, Mark Allman wrote: > >> The time constants we're talking about here are faster than the >> IETF, but slower than TCP CC, i.e., O(weeks to months). > > O(weeks to months to years to decades) FWIW, I was defining timescale as the period over which the value is re-evaluated and could change, not the period over which it ever does change. But yes, the basic alg we have been discussing off-line has been: backoff if loss during IW is dominant check O(weeks/months) increase the IW by one do this every year or two, maybe Note - the 'increase' part is optional. It is included to incorporate Mark's suggestion that the IW should be ramped up slowly over time, rather than revisited once a decade in larger jumps. Joe From mallman@icir.org Tue Nov 30 11:19:16 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770773A6C27 for ; Tue, 30 Nov 2010 11:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.129 X-Spam-Level: X-Spam-Status: No, score=-106.129 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKqY4ER8Lk1t for ; Tue, 30 Nov 2010 11:19:15 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id BA7883A6C22 for ; Tue, 30 Nov 2010 11:19:15 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id oAUJKEmX008559; Tue, 30 Nov 2010 11:20:14 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 925E7265BFE6; Tue, 30 Nov 2010 14:20:14 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <4CF54BB1.9040908@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Dance the Night Away MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma20078-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 30 Nov 2010 14:20:14 -0500 Sender: mallman@icir.org Message-Id: <20101130192014.925E7265BFE6@lawyers.icir.org> Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] alternate IW proposal X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 19:19:16 -0000 ----------ma20078-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > >> The time constants we're talking about here are faster than the > >> IETF, but slower than TCP CC, i.e., O(weeks to months). > > > > O(weeks to months to years to decades) > > FWIW, I was defining timescale as the period over which the value is > re-evaluated and could change, FWIW, I was increasing the timescale to realistic IETF granularities. allman ----------ma20078-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAkz1Tm4ACgkQWyrrWs4yIs7kmACfcU/6U4Ts56r6idVfxvtUYHsG 5KgAn0Y34ZHum1WwbqzD4zw8vGuron// =rzxu -----END PGP SIGNATURE----- ----------ma20078-1--