Date: Thu, 16 Mar 2000 16:35:48 PST To: Sally Floyd From: Zachary Amsden Subject: Re: a question about the deployment of SACK and NewReno TCP Delivery-Date: Thu Mar 16 16:28:05 2000 Sender: zamsden@clock.engr.sgi.com Well I can't give statistics, the following stacks support SACK: Win95/98/NT Linux Solaris IRIX BSDI OpenBSD No idea about FreeBSD, but I would assume yes since OpenBSD follows FreeBSD development, and plenty of *BSD SACK hacking has been done in the academic community. Also no idea about HP-UX, Digital UNIX, or Apple. Some SACK implementations appear to be quite buggy when dealing with multiple SACK options, getting test coverage is a problem (all possible combinations of SACK options, vendor interoperability, interactions with mss on bi-directional connections, ...). My guess is that it will take a couple of years for SACK to be a given, since most high volume server sites are very skeptical of upgrades. -- Zachary Amsden zamsden@engr.sgi.com 3-6919 31-2-510 Core Protocols Date: Thu, 16 Mar 2000 17:52:26 PST To: Sally Floyd From: Kacheong Poon Subject: Re: a question about the deployment of SACK and NewReno TCP Delivery-Date: Thu Mar 16 17:51:25 2000 > If anyone had any data about the relative deployment of Reno, > NewReno, and SACK TCP in the Internet, I would be very interested > to hear. Just a note, starting from Solaris 2.6, NewReno is used. Starting with Solaris 7 (which is the release after Solaris 2.6), SACK is used. I don't have data on how many Sun customers have upgraded to at least 2.6 though. K. Poon. kcpoon@eng.sun.com Date: Fri, 17 Mar 2000 08:32:00 EST To: Sally Floyd cc: end2end-interest@ISI.EDU From: Mark Allman Subject: Re: a question about the deployment of SACK and NewReno TCP Delivery-Date: Fri Mar 17 05:30:55 2000 Song-of-the-Day: Ramble On Sender: mallman@guns.lerc.nasa.gov Sally- I have been crunching across a large collection of traces from one of our web serveres recently. One of the items on my todo list is to look at some of the questions you have raised. I haven't gone down that path very far at this point, but I have a very small script and I just crunched one of the recent traces in my dataset. Trace date: 01/12/2000 -- 02/14/2000 Total packets captured: 3662025 Kernel packet drops: 37 Total TCP connections: 111508 Connections requesting SACK: 19343 (~17%) RFC 1323 extensions: Window scaling: 46082 (~41%) Timestamps: 41376 (~37%) WS + TS: 41323 (~37%) Note that the web server I am watching does not support SACK, so the reported number above is for connections hitting the web server with "SACK permitted" (but, that would turn into the number of connections actually using SACK if the TCP in netbsd would use SACKs). The RFC 1323 numbers are included just for interest. Those numbers reflect actual usage of the extensions, since the web server does support them. I know this isn't as verbose as you were probably hoping for, but hopefully it is at least a starting data point. allman Date: Fri, 17 Mar 2000 19:32:36 +0100 To: floyd@aciri.org cc: end2end-interest@ISI.EDU, anja@research.att.com From: Anja Feldmann Subject: Re: a question about the deployment of SACK and NewReno TCP Delivery-Date: Fri Mar 17 10:31:38 2000 X-Authentication-Warning: sol.cs.uni-sb.de: anja set sender to anja@cs.uni-sb.d ***e using -f Hi Sally, here are a few more numbers regarding the usage of SACK. The trace in question was collected from the AT&T custom-build packet monitor, PacketScope which is deployed next to a dialup modem pool in AT&T WorldNet. This specific PacketScope monitors a FDDI ring carrying traffic to and from a group of roughly 450 modems shared by approximately 18,000 dialup customers. More details on the measurement infrastructure can be found in the paper: "Measurement and analysis of IP network usage and behavior" R. Caceres, N. Duffield, A. Feldmann, J. Friedmann, A. Greenberg, R. Greer, T. Johnson, C. Kalmanek, B. Krishnamurthy, D. Lavelle, P. Mishra, K. Ramakrishnan, J. Rexford, F. True, J. van der Merwe; IEEE Communication Magazine, on Network traffic measurements and experiments, to appear in May 2000, available at: http://www.research.att.com/~anja/feldmann/papers/ieeecom00_measure.ps.gz or http://www.cs.uni-sb.de/~anja/feldmann/papers/ieeecom00_measure.ps.gz Trace start: Mon Dec 13 22:47:46 1999 Trace end: Tue Dec 14 12:21:32 1999 Total number of packets from/to modems: 19,204,640 Number of packets with TCP connections flags: 1,711,939 Number of TCP connections (computed via tcp-conn): 440,669 Number of SYN packets with sack option and without ACK flag: 301,365 Number of SYN packets with sack option and ACK flag: 25,009 This indicates that the SACK option is often set on the TCP connection initiation but not accepted by the other end of the TCP connection. I hope this helps Anja ----------------------------------------------------------------------------- Prof. Anja Feldmann email: anja@cs.uni-sb.de Computer Science Department tel: 01149 681 302 6540 University of Saarbruecken fax: 01149 681 302 6542 Im Stadtwald, Geb. 36.1 http: http://www.cs.uni-sb.de/~anja/ D-66123 Saarbruecken, Germany Date: Tue, 21 Mar 2000 13:02:25 GMT To: Sally Floyd cc: end2end-interest@ISI.EDU From: Richard Wendland Subject: Re: a question about the deployment of SACK and NewReno TCP Delivery-Date: Tue Mar 21 05:01:33 2000 Here are some further SACK numbers. These give a different perspective to Mark Allman's and Anja Feldmann's numbers which are probably from traces largely originating from different Web Browsers and the OSs that run them. These numbers are for connections from a single SACK+RFC1323 capable HTTP client to a random sample of different web server IP addresses. The IP addresses are taken from the large-scale Netcraft Web Server Survey, so this is a plausible first approximation at a representative sample of web servers in general. Because of the predominance of virtual hosting however, this sample largely reflects the choices of virtual hosting companies. Date: Mar 20 2000 Unique IP addresses sampled: 115143 TCP connections responding to: SACK: 17032 14.79% timestamp option: 43913 38.13% window scale option: 46474 40.36% WS + TS: 43742 37.98% WS + TS + SACK: 16854 14.63% Note these measurements aren't of dynamic flows of real traffic, but a measurement of web server TCP option capabilities. Dynamic flows tell us what's happening here and now at the measurement points, but these numbers may offer a useful insight into the capabilities of deployed web server systems. Since the popular client OSs Win98, recent Linux, and in the future Win2000 are SACK capable, SACK usage with HTTP is probably limited by server, proxy cache and server load balancing device support. It's interesting to compare these numbers with Mark Allman's and Anja Feldmann's. These numbers aren't that dissimilar to Mark Allman's, but as I understand it those are connections from many HTTP clients or caches to a few webservers; there's no reason to expect similar results and both give quite different perspectives. Anja Feldmann's dynamic flow numbers show quite a different pattern to these. To try to compare, let's assume all the AT&T traffic is HTTP. Thus all the SACK option without ACK (301,365) SYNs are from SACK capable HTTP clients, and the SACK option with ACK SYNs (25,009) are responses from HTTP servers or caches. This implies only 8.29% of the HTTP server or cache responses are SACK capable, compared to my 14.79% HTTP server static capability measurement. Likely explanations seem to be either that many of these AT&T dial-up customers are using non-SACK capable proxy caches, or the popular web servers they are visiting (and re-visiting) are not represented by my static sample. Richard -- Richard Wendland richard@netcraft.com http://www.netcraft.com/survey/ http://www.netcraft.com/jobs/