From detlef.bosau at web.de Mon Jan 1 04:48:19 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 01 Jan 2007 13:48:19 +0100 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> Message-ID: <45990313.1050003@web.de> Fred Baker wrote: > > > I wonder where you got the notion that a typical session had a 10 ms > RTT. In a LAN environment where the servers are in the same It?s just a number. However, it?s the magnitude. Not the exact number. In your example below you have about 20 ms, 100 ms, 200 ms RTT. If we again consider one outstanding segment with 12000 bit we have the following rates (approximately) 600 kbps 120 kbps 60 kbps It?s not the question whether this is optimal. It?s the question: Does this happen in a relevant number of cases? Particularly in downloads from mobile devices which quite often do not offer larger bandwidth. So to your question why TCP should tune itself to only one outstanding segment: The reason could be the limited bandwidth the node, e.g. a mobile node, can handle. Detlef From detlef.bosau at web.de Mon Jan 1 04:49:41 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 01 Jan 2007 13:49:41 +0100 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <032EC4F75A527A4FA58C5B1B5DECFBB301F249E6@KC-MSX1.kc.umkc.edu> References: <032EC4F75A527A4FA58C5B1B5DECFBB301F249E6@KC-MSX1.kc.umkc.edu> Message-ID: <45990365.4080708@web.de> Medhi, Deep wrote: > See > > John Heidemann, Katia Obraczka, and Joe Touch. "Modeling the Performance of HTTP Over Several Transport Protocols." ACM/IEEE Transactions on Networking, vol. 5, pp. 616-630, October, 1997. > > This covers maximum usable window size for different transmission media. > > -- Deep > Unfortunately, I don?t have an ACM account. Is it possible to send me a copy? Perhaps Joe? Thanks a lot! From detlef.bosau at web.de Mon Jan 1 08:36:27 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 01 Jan 2007 17:36:27 +0100 Subject: [e2e] Thanks a lot for the copies! Re: Are we doing sliding window in the Internet? In-Reply-To: <45990365.4080708@web.de> References: <032EC4F75A527A4FA58C5B1B5DECFBB301F249E6@KC-MSX1.kc.umkc.edu> <45990365.4080708@web.de> Message-ID: <4599388B.2050904@web.de> I just received two copies of the paper. Many thanks to all! Detlef Detlef Bosau wrote: > Medhi, Deep wrote: >> See >> John Heidemann, Katia Obraczka, and Joe Touch. "Modeling the >> Performance of HTTP Over Several Transport Protocols." ACM/IEEE >> Transactions on Networking, vol. 5, pp. 616-630, October, 1997. >> This covers maximum usable window size for different transmission media. >> >> -- Deep >> > Unfortunately, I don?t have an ACM account. Is it possible to send me > a copy? Perhaps Joe? > > Thanks a lot! > > From pingali at ISI.EDU Tue Jan 2 10:31:29 2007 From: pingali at ISI.EDU (Venkata Pingali) Date: Tue, 02 Jan 2007 10:31:29 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> Message-ID: <459AA501.8050901@isi.edu> A few months back we collected some per-connection data in both client and server modes. We thought you might be interested in the preliminary results. We collected data in two modes/configurations. In the client mode we configured Apache to be a web proxy and in the server mode we configured Apache to serve an actual website. The basic results, which must be only considered as being indicative/hints of the reality, are as follows: Server end (i.e, end that has large amount of data to transfer): - Most connections are short (90% < 1sec) - MaxCwnd is < 5KB in > 80% of cases - MaxRTT is distributed almost uniformly in the 0-400ms range. Client end (i.e., the end receiving data): - ~ 90% of connections see MaxCwnd < 5KB - < 1% connections see MaxCwnd > 10KB - 90% of connections have MaxRTT < 100ms There are some problems with the data: - limited scenarios (web based) - small sample sizes (21K for server, 150K for client) - the website has non-standard distribution of file types and sizes You can find the various graphs here: http://www.isi.edu/aln/e2e.ppt Venkata Pingali http://www.isi.edu/aln Fred Baker wrote: > yes and no. > > A large percentage of sessions are very short - count the bytes in this > email and consider how many TCP segments are required to carry it, for > example, or look through your web cache to see the sizes of objects it > stores. We are doing the sliding window algorithm, but it cuts very > short when the TCP session abruptly closes. > > For longer exchanges - p2p and many others - yes, we indeed do sliding > window. > > I don't see any reason to believe that TCPs tune themselves to have > exactly RTT/MSS segments outstanding. That would be the optimal number > to have ourstanding, but generally they will have the smallest of { the > offered window, the sender's maximum window, and the used window at > which they start dropping traffic }. If they never see loss, they can > keep an incredibly large amount of data outstanding regardless of the > values of RTT and MSS. > > I wonder where you got the notion that a typical session had a 10 ms > RTT. In a LAN environment where the servers are in the same building, > that is probably the case. But consider these rather more typical > examples: across my VPN to a machine at work, across the US to MIT, and > across the Atlantic to you: > > [stealth-10-32-244-218:~] fred% traceroute irp-view7 > traceroute to irp-view7.cisco.com (171.70.65.144), 64 hops max, 40 byte > packets > 1 fred-vpn (10.32.244.217) 1.486 ms 1.047 ms 1.034 ms > 2 n003-000-000-000.static.ge.com (3.7.12.1) 22.360 ms 20.962 ms > 22.194 ms > 3 10.34.251.137 (10.34.251.137) 23.559 ms 22.586 ms 22.236 ms > 4 sjc20-a5-gw2 (10.34.250.78) 21.465 ms 22.544 ms 20.748 ms > 5 sjc20-sbb5-gw1 (128.107.180.105) 22.294 ms 22.351 ms 22.803 ms > 6 sjc20-rbb-gw5 (128.107.180.22) 21.583 ms 22.517 ms 24.190 ms > 7 sjc12-rbb-gw4 (128.107.180.2) 22.115 ms 23.143 ms 21.478 ms > 8 sjc5-sbb4-gw1 (171.71.241.253) 26.550 ms 23.122 ms 21.569 ms > 9 sjc12-dc5-gw2 (171.71.241.66) 22.115 ms 22.435 ms 22.185 ms > 10 sjc5-dc3-gw2 (171.71.243.46) 22.031 ms 21.846 ms 22.185 ms > 11 irp-view7 (171.70.65.144) 22.760 ms 22.912 ms 21.941 ms > > [stealth-10-32-244-218:~] fred% traceroute www.mit.edu > traceroute to www.mit.edu (18.7.22.83), 64 hops max, 40 byte packets > 1 fred-vpn (10.32.244.217) 1.468 ms 1.108 ms 1.083 ms > 2 172.16.16.1 (172.16.16.1) 11.994 ms 10.351 ms 10.858 ms > 3 cbshost-68-111-47-251.sbcox.net (68.111.47.251) 9.238 ms 19.517 ms > 9.857 ms > 4 12.125.98.101 (12.125.98.101) 11.849 ms 11.913 ms 12.086 ms > 5 gbr1-p100.la2ca.ip.att.net (12.123.28.130) 12.348 ms 11.736 ms > 12.891 ms > 6 tbr2-p013502.la2ca.ip.att.net (12.122.11.145) 15.071 ms 13.462 ms > 13.453 ms > 7 12.127.3.221 (12.127.3.221) 12.643 ms 13.761 ms 14.345 ms > 8 br1-a3110s9.attga.ip.att.net (192.205.33.230) 13.842 ms 12.414 ms > 12.647 ms > 9 ae-32-54.ebr2.losangeles1.level3.net (4.68.102.126) 16.651 ms > ae-32-56.ebr2.losangeles1.level3.net (4.68.102.190) 20.154 ms * > 10 * * * > 11 ae-2.ebr1.sanjose1.level3.net (4.69.132.9) 28.222 ms 24.319 ms > ae-1-100.ebr2.sanjose1.level3.net (4.69.132.2) 35.417 ms > 12 ae-1-100.ebr2.sanjose1.level3.net (4.69.132.2) 25.640 ms 22.567 ms * > 13 ae-3.ebr1.denver1.level3.net (4.69.132.58) 52.275 ms 60.821 ms > 54.384 ms > 14 ae-3.ebr1.chicago1.level3.net (4.69.132.62) 68.285 ms > ae-1-100.ebr2.denver1.level3.net (4.69.132.38) 59.113 ms 68.779 ms > 15 * * * > 16 * ae-7-7.car1.boston1.level3.net (4.69.132.241) 94.977 ms * > 17 ae-7-7.car1.boston1.level3.net (4.69.132.241) 95.821 ms > ae-11-11.car2.boston1.level3.net (4.69.132.246) 93.856 ms > ae-7-7.car1.boston1.level3.net (4.69.132.241) 96.735 ms > 18 ae-11-11.car2.boston1.level3.net (4.69.132.246) 91.093 ms 92.125 > ms 4.79.2.2 (4.79.2.2) 95.802 ms > 19 4.79.2.2 (4.79.2.2) 93.945 ms 95.336 ms 97.301 ms > 20 w92-rtr-1-backbone.mit.edu (18.168.0.25) 98.246 ms www.mit.edu > (18.7.22.83) 93.657 ms w92-rtr-1-backbone.mit.edu (18.168.0.25) 92.610 ms > > [stealth-10-32-244-218:~] fred% traceroute web.de > traceroute to web.de (217.72.195.42), 64 hops max, 40 byte packets > 1 fred-vpn (10.32.244.217) 1.482 ms 1.078 ms 1.093 ms > 2 172.16.16.1 (172.16.16.1) 12.131 ms 9.318 ms 8.140 ms > 3 cbshost-68-111-47-251.sbcox.net (68.111.47.251) 10.790 ms 9.051 ms > 10.564 ms > 4 12.125.98.101 (12.125.98.101) 13.580 ms 21.643 ms 12.206 ms > 5 gbr2-p100.la2ca.ip.att.net (12.123.28.134) 12.446 ms 12.914 ms > 12.006 ms > 6 tbr2-p013602.la2ca.ip.att.net (12.122.11.149) 13.463 ms 12.711 ms > 12.187 ms > 7 12.127.3.213 (12.127.3.213) 185.324 ms 11.845 ms 12.189 ms > 8 192.205.33.226 (192.205.33.226) 12.008 ms 11.665 ms 25.390 ms > 9 ae-1-53.bbr1.losangeles1.level3.net (4.68.102.65) 13.695 ms > ae-1-51.bbr1.losangeles1.level3.net (4.68.102.1) 11.645 ms > ae-1-53.bbr1.losangeles1.level3.net (4.68.102.65) 12.517 ms > 10 ae-1-0.bbr1.frankfurt1.level3.net (212.187.128.30) 171.886 ms > as-2-0.bbr2.frankfurt1.level3.net (4.68.128.169) 167.640 ms 168.895 ms > 11 ge-10-0.ipcolo1.frankfurt1.level3.net (4.68.118.9) 170.336 ms > ge-11-1.ipcolo1.frankfurt1.level3.net (4.68.118.105) 174.211 ms > ge-10-1.ipcolo1.frankfurt1.level3.net (4.68.118.73) 169.730 ms > 12 gw-megaspace.frankfurt.eu.level3.net (212.162.44.158) 169.276 ms > 170.110 ms 168.099 ms > 13 te-2-3.gw-backbone-d.bs.ka.schlund.net (212.227.120.17) 171.412 ms > 171.820 ms 170.265 ms > 14 a0kac2.gw-distwe-a.bs.ka.schlund.net (212.227.121.218) 175.416 ms > 173.653 ms 174.007 ms > 15 ha-42.web.de (217.72.195.42) 174.908 ms 174.921 ms 175.821 ms > > > On Dec 31, 2006, at 11:15 AM, Detlef Bosau wrote: > >> Happy New Year, Miss Sophy My Dear! >> >> (Although this sketch is in Englisch, it is hardly known outside >> Germay to my knowledge.) >> >> I wonder whether we?re really doing sliding window in TCP connections >> all the time or whether a number of connections have congestion >> windows of only one segment, i.e. behave like stop?n wait in reality. >> >> When I assume an Ethernet like MTU, i.e. 1500 byte = 12000 bit, and >> 10 ms RTT the throughput is roughly 12000 bit / 10 ms = 1.2 Mbps. >> >> From this I would expect that in quite a few cases a TCP connection >> will have a congestion window of 1 MSS or even less. >> >> In addition, some weeks ago I read a paper, I don?t remember were, >> that we should reconsider and perhaps resize our MTUs to larger values >> for networks with large bandwidth. The rationale was simply as >> follows: The MTU size is always a tradeoff between overhead and >> jitter. From Ethernet we know that we can accept a maximum packet >> duration of 12000 bit / (10 Mbps) = 1.2 ms and the resultig jitter. >> For Gigabit Ethernet >> a maximum packet duration of 1.2 ms would result in a MTU size of 1500 >> kbyte = 1.5 Mbyte. >> >> If so, we would see "stop?n wait like" connections much more >> frequently than today. >> >> Is this view correct? >> From detlef.bosau at web.de Tue Jan 2 11:52:03 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 02 Jan 2007 20:52:03 +0100 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459AA501.8050901@isi.edu> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> Message-ID: <459AB7E3.7010705@web.de> Venkata Pingali wrote: > > > Server end (i.e, end that has large > amount of data to transfer): > > - Most connections are short (90% < 1sec) Do you have any knowledge of the number of "rounds" the TCP connection has seen? A couple of years ago I saw some similar result (don?t no the source at the moment) where 90 % of connections consist of not more than 20 packets. Now, consider the initial slowstart, IIRC we start with 2 MSS (?) then we have: Round CWND 1 2 2 4 3 8 total of 14 packets up to now 4 16 total of 24 packets up to now, thus many flows will finisch before the end of the fourth round which would correspond to a CWND of about 6 kByte, 1500 byte MSS assumed. In short words: Quite a few connections are finished before the end of the fist slow start period. Does this match your observations? > - MaxCwnd is < 5KB in > 80% of cases > - MaxRTT is distributed almost uniformly > in the 0-400ms range. > > Client end (i.e., the end receiving data): > > - ~ 90% of connections see MaxCwnd < 5KB > - < 1% connections see MaxCwnd > 10KB > - 90% of connections have MaxRTT < 100ms > Oh, I love it :-) Last year I had a long argument with someone who told me about the benefits of window scaling :-) He talked about extremely large CWNDs by several dozens or hundreds of MByte :-) O.k., that?s a different story because we are talking about greedy sources than. However, if that colleague was the only one to activate window scaling while surfing from the US and A to good ol? Europe and Cisco et al. had buried hundreds of megabytes of useless queue memory in their hardware *blush* this guy perhaps filled the queues the first time ever, following the good old paradigm: "Keep the queue full" and that way of course outperformed his competitors hopelessly ;-) > There are some problems with the data: > > - limited scenarios (web based) > - small sample sizes (21K for server, 150K > for client) > - the website has non-standard distribution > of file types and sizes > At least it exists. And reality is often more convincing than standards. Particularly in cases were both disagree. > You can find the various graphs here: > http://www.isi.edu/aln/e2e.ppt Just a question: Is it possible to export those slides to a common readable format like PDF? I don?t have any M$ products in use here and when I opten PowerPoint slides with OpenOffice the results are sometimes interesting, sometimes surprising, sometimes hopeless, but nearly always quite different from what you wrote :-) Regards Detlef From pingali at ISI.EDU Tue Jan 2 12:29:55 2007 From: pingali at ISI.EDU (Venkata Pingali) Date: Tue, 02 Jan 2007 12:29:55 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459AB7E3.7010705@web.de> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> Message-ID: <459AC0C3.30103@isi.edu> Detlef Bosau wrote: > Venkata Pingali wrote: >> >> >> Server end (i.e, end that has large >> amount of data to transfer): >> >> - Most connections are short (90% < 1sec) > > Do you have any knowledge of the number of "rounds" the TCP connection > has seen? A couple of years ago I saw some similar result (don?t no the > source at the moment) where 90 % of connections consist of not more than > 20 packets. Our sample shows that 94% of connections have < 20 packets - when observed from the server end. Number of Packets Percentile of Connections 3 4% 4 55% 5 69% 10 87% 20 94% I have included the new graph and generated pdfs. http://www.isi.edu/aln/e2e.pdf http://www.isi.edu/aln/e2e.ppt > > Now, consider the initial slowstart, IIRC we start with 2 MSS (?) then > we have: > > Round CWND > 1 2 > 2 4 > 3 8 > total of 14 packets up to now > 4 16 > total of 24 packets up to now, > > thus many flows will finisch before the end of the fourth round which > would correspond to a CWND of about 6 kByte, 1500 byte MSS assumed. > > In short words: Quite a few connections are finished before the end of > the fist slow start period. > > Does this match your observations? Yes. About 90-95% finished before slow start completed - often within the first two round trips. About 3-4% of connections lasted for a long time (several secs - minutes). But there is an interesting category of connections that last beyond the slow start but not for very long. These connections, it turns, carry a large chunk of the data (40+%) and most of the time in these connections is spent in slow start. > >> - MaxCwnd is < 5KB in > 80% of cases >> - MaxRTT is distributed almost uniformly >> in the 0-400ms range. >> >> Client end (i.e., the end receiving data): >> >> - ~ 90% of connections see MaxCwnd < 5KB >> - < 1% connections see MaxCwnd > 10KB >> - 90% of connections have MaxRTT < 100ms >> > > Oh, I love it :-) > > Last year I had a long argument with someone who told me about the > benefits of window scaling :-) He talked about extremely large CWNDs by > several dozens or hundreds of MByte :-) Dont know if it is correct to extrapolate from the same that we have but the MaxCwnd graph seems to plateau as the connection length increases (bytes or packets). > > O.k., that?s a different story because we are talking about greedy > sources than. However, if that colleague was the only one to activate > window scaling while surfing from the US and A to good ol? Europe and > Cisco et al. had buried hundreds of megabytes of useless queue memory in > their hardware *blush* this guy perhaps filled the queues the first time > ever, following the good old paradigm: "Keep the queue full" and that > way of course outperformed his competitors hopelessly ;-) > >> There are some problems with the data: >> >> - limited scenarios (web based) >> - small sample sizes (21K for server, 150K >> for client) >> - the website has non-standard distribution >> of file types and sizes >> > > At least it exists. And reality is often more convincing than standards. > Particularly in cases were both disagree. > > >> You can find the various graphs here: >> http://www.isi.edu/aln/e2e.ppt > > Just a question: Is it possible to export those slides to a common > readable format like PDF? I don?t have any M$ products in use here and > when I opten PowerPoint slides with OpenOffice the results are sometimes > interesting, sometimes surprising, sometimes hopeless, but nearly always > quite different from what you wrote :-) > > Regards > > Detlef > From touch at ISI.EDU Tue Jan 2 16:14:50 2007 From: touch at ISI.EDU (Joe Touch) Date: Tue, 02 Jan 2007 16:14:50 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459AB7E3.7010705@web.de> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> Message-ID: <459AF57A.5080304@isi.edu> Detlef Bosau wrote: > Venkata Pingali wrote: >> >> >> Server end (i.e, end that has large >> amount of data to transfer): >> >> - Most connections are short (90% < 1sec) > > Do you have any knowledge of the number of "rounds" the TCP connection > has seen? A couple of years ago I saw some similar result (don?t no the > source at the moment) where 90 % of connections consist of not more than > 20 packets. > > Now, consider the initial slowstart, IIRC we start with 2 MSS (?) then > we have: I don't know if the current code starts with 2 MSS; it could start with 4. > Round CWND > 1 2 > 2 4 > 3 8 > total of 14 packets up to now > 4 16 > total of 24 packets up to now, It doesn't double each RTT; it goes up by 50%. Remember, the window grows by one MSS each ACK during the initial phase, but there is one ACK for each two MSS's. I.e., the sequence should be: round CWND 1 2 (assuming it starts with 2) 2 3 3 4 4 6 5 9 6 13 This assumes that the congestion window hasn't kicked in, at which point the growth would be 1 MSS per round (RTT). FYI,Internet MSS's are usually in the 500-byte range in general. A 5KB file would take 10 packets and be over by the 4th round. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070102/73b105f8/signature.bin From touch at ISI.EDU Tue Jan 2 18:55:05 2007 From: touch at ISI.EDU (Joe Touch) Date: Tue, 02 Jan 2007 18:55:05 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> Message-ID: <459B1B09.40301@isi.edu> Lachlan Andrew wrote: > Greetings, > > On 02/01/07, Joe Touch wrote: >> >> Detlef Bosau wrote: >> > Round CWND >> > 1 2 >> > 2 4 >> > 3 8 >> >> It doesn't double each RTT; it goes up by 50%. Remember, the window >> grows by one MSS each ACK during the initial phase, but there is one ACK >> for each two MSS's. > > If you have ABC (as recent Linux senders do by default), or don't use ABC is EXPERIMENTAL. > delayed ACKs (as Linux receivers don't when the window is small), Delayed ACKs are strongly encouraged. Both good reasons to fix these bugs in Linux. > Detlef was right that it doubles each RTT. Right - noncompliant or nonstandard implementations can do various other things. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070102/db75defd/signature.bin From ian.mcdonald at jandi.co.nz Tue Jan 2 19:58:09 2007 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Wed, 3 Jan 2007 16:58:09 +1300 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459B1B09.40301@isi.edu> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> Message-ID: <5640c7e00701021958w60fdd86cg8c94055dd495671f@mail.gmail.com> > > If you have ABC (as recent Linux senders do by default), or don't use > > ABC is EXPERIMENTAL. > And ABC is now off by default on even later kernels as basically the congestion window didn't grow with how the whole code base interacted. Can't comment on the delayed acks as don't know that part of the code so well. Ian -- Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group From touch at ISI.EDU Tue Jan 2 20:11:05 2007 From: touch at ISI.EDU (Joe Touch) Date: Tue, 02 Jan 2007 20:11:05 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <5640c7e00701021958w60fdd86cg8c94055dd495671f@mail.gmail.com> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <5640c7e00701021958w60fdd86cg8c94055dd495671f@mail.gmail.com> Message-ID: <459B2CD9.3030509@isi.edu> Ian McDonald wrote: >> > If you have ABC (as recent Linux senders do by default), or don't use >> >> ABC is EXPERIMENTAL. >> > And ABC is now off by default on even later kernels as basically the > congestion window didn't grow with how the whole code base interacted. That's not how "experimental" is intended by the IETF, i.e., it's not a patch to other bugs. -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070102/0c91a4a9/signature.bin From ian.mcdonald at jandi.co.nz Tue Jan 2 20:25:38 2007 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Wed, 3 Jan 2007 17:25:38 +1300 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459B2CD9.3030509@isi.edu> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <5640c7e00701021958w60fdd86cg8c94055dd495671f@mail.gmail.com> <459B2CD9.3030509@isi.edu> Message-ID: <5640c7e00701022025i1bf18875p2a6d77c374c0c12f@mail.gmail.com> On 1/3/07, Joe Touch wrote: > Ian McDonald wrote: > >> > If you have ABC (as recent Linux senders do by default), or don't use > >> > >> ABC is EXPERIMENTAL. > >> > > And ABC is now off by default on even later kernels as basically the > > congestion window didn't grow with how the whole code base interacted. > > That's not how "experimental" is intended by the IETF, i.e., it's not a > patch to other bugs. > I understand that since I'm working on an experimental protocol myself. I'm only the messenger here. As I understand it (and I could be wrong) Linux deals with the cases fairly well that ABC is trying to solve. To get ABC into the kernel by default some of the other code would have to be changed and nobody has done that yet. If someone does that and can convince others it can go back in.. -- Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group From touch at ISI.EDU Tue Jan 2 20:38:05 2007 From: touch at ISI.EDU (Joe Touch) Date: Tue, 02 Jan 2007 20:38:05 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <5640c7e00701022025i1bf18875p2a6d77c374c0c12f@mail.gmail.com> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <5640c7e00701021958w60fdd86cg8c94055dd495671f@mail.gmail.com> <459B2CD9.3030509@isi.edu> <5640c7e00701022025i1bf18875p2a6d77c374c0c12f@mail.gmail.com> Message-ID: <459B332D.4040302@isi.edu> Ian McDonald wrote: > On 1/3/07, Joe Touch wrote: >> Ian McDonald wrote: >> >> > If you have ABC (as recent Linux senders do by default), or don't >> use >> >> >> >> ABC is EXPERIMENTAL. >> >> >> > And ABC is now off by default on even later kernels as basically the >> > congestion window didn't grow with how the whole code base interacted. >> >> That's not how "experimental" is intended by the IETF, i.e., it's not a >> patch to other bugs. >> > I understand that since I'm working on an experimental protocol myself. > > I'm only the messenger here. As I understand it (and I could be wrong) > Linux deals with the cases fairly well that ABC is trying to solve. To > get ABC into the kernel by default some of the other code would have > to be changed and nobody has done that yet. If someone does that and > can convince others it can go back in.. ABC should NOT be "ON" by default. As to whether it should be in the kernel at all, or how it interacts with the code base, that's an implementation issue. I appreciate the complexities, but the decision of whether to use it or not should be made solely on whether it is recommended for widescale deployment or not. Thanks for the update; it's worrisome that Linux's defaults are that ephemeral, though. ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070102/9a3b7181/signature.bin From touch at ISI.EDU Tue Jan 2 22:07:48 2007 From: touch at ISI.EDU (Joe Touch) Date: Tue, 02 Jan 2007 22:07:48 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> Message-ID: <459B4834.1050304@isi.edu> Lachlan Andrew wrote: > Greetings, > > This is probably not related to the original thread (on what happens > in real networks, as distinct from what *should* happen), but the word > "bug" bugged me... > > On 02/01/07, Joe Touch wrote: ... >> > delayed ACKs (as Linux receivers don't when the window is small), >> >> Delayed ACKs are strongly encouraged. >> Both good reasons to fix these bugs in Linux. > > I don't follow the logic of that at all. Please review RFC2581. > Linux deliberatly suppresses > delayed ACKs when it guesses that the sender is in slow start, which > sems generally correct, judging by the earlier posts in this thread. Whether it's interpreted as correct by this email list, it is NOT what the IETF currently recommends. > In that phase, they harm performance, by making slow-start even slower > than it was intended to be. Increasing the initial speed of slow > starts helps short flows at no long term cost to ongoing long flows. > When the window is large, Linux does use delayed ACKs, for the reasons > given in the RFCs. Since this is fully standards compliant, I don't > see how it can be called a bug. > > The fact that something is "encouraged" doesn't *of itself* seem a > good reason to do it, if there are clear reasons not to. That isn't > to say that there may not indeed be good reasons to change Linux's > behaviour; I'd be interested to hear them. I'd be more interested to know that there had been *controlled* experiments to validate that this behavior was safe and did not impact the current behavior of TCP congestion control as per RFC2581. At that point, I'd be interested to have that information taken to the IETF with a proposal to change the recommended behavior, and have it vetted by that community. The idea that this should be tried in the large "until there are good reasons not to" is NOT how such experiments should be performed. > (On a related note, this year's PFLDnet > has a panel session on the > implications of network stack implementors Linux and Microsoft setting > new de-facto flow control standards. This seems analogous to what the > BSD Reno release did, implementing improvements well before Reno made > it into the RFCs. The difference is that now a global infrastructure > rides on it...) The improvements in Reno were MORE conservative than TCP as specified, not less. Being more conservative is always compliant. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070102/d6846059/signature-0001.bin From detlef.bosau at web.de Wed Jan 3 03:13:10 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 03 Jan 2007 12:13:10 +0100 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> Message-ID: <459B8FC6.1040208@web.de> Lachlan Andrew wrote: > Greetings, > > On 02/01/07, Joe Touch wrote: >> >> Detlef Bosau wrote: >> > Round CWND >> > 1 2 >> > 2 4 >> > 3 8 >> >> It doesn't double each RTT; it goes up by 50%. Remember, the window >> grows by one MSS each ACK during the initial phase, but there is one ACK >> for each two MSS's. > > If you have ABC (as recent Linux senders do by default), or don't use > delayed ACKs (as Linux receivers don't when the window is small), > Detlef was right that it doubles each RTT. > > $0.02 > Lachlan > Just before I?m to end my life on "Yellow Mama" ....... ;-) I admit that I often forget to mention all my assumptions. And even more, I don?t have all the RFCs in mind, particularly not rfc 3390, which Joe has in mind when he talks of an initial window of 4 MSS. When I do NS2 simulations, I mostly turn off delayed ACKs for my purposes at the moment. From the congavoid paper, I understand that the intention was to double CWND each round if the sender is in slow start state and to increase it by 1 MSS each round when the sender is in congestion avoidance state. From my understanding it is not necessary for the AIMD scheme to work that this doubling/increasing happens every or every other round. Of course, it affects the convergence time. I?m talking too much. Please forgive me, if I miss to mention all my assumptions ... Detlef From touch at ISI.EDU Wed Jan 3 08:20:27 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Jan 2007 08:20:27 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459B8FC6.1040208@web.de> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B8FC6.1040208@web.de> Message-ID: <459BD7CB.3080300@isi.edu> Detlef Bosau wrote: ... > Just before I?m to end my life on "Yellow Mama" ....... ;-) > > I admit that I often forget to mention all my assumptions. And even > more, I don?t have all the RFCs in mind, particularly not rfc 3390, > which Joe has in mind when he talks of an initial window of 4 MSS. > > When I do NS2 simulations, I mostly turn off delayed ACKs for my > purposes at the moment. > > From the congavoid paper, I understand that the intention was to double > CWND each round if the sender is in slow start state and to increase it > by 1 MSS each round when the sender is in congestion avoidance state. The original intention was to double it, but since delayed ACKs that hasn't been the case. The current AI is 1.5x in slowstart, and has been for quite a long time. > From my understanding it is not necessary for the AIMD scheme to work > that this doubling/increasing happens every or every other round. > Of course, it affects the convergence time. It also affects fairness when different connections use different factors, either for AI or MD. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/bd68a531/signature.bin From lachlan.andrew at gmail.com Tue Jan 2 17:49:53 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Tue, 2 Jan 2007 17:49:53 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459AF57A.5080304@isi.edu> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> Message-ID: Greetings, On 02/01/07, Joe Touch wrote: > > Detlef Bosau wrote: > > Round CWND > > 1 2 > > 2 4 > > 3 8 > > It doesn't double each RTT; it goes up by 50%. Remember, the window > grows by one MSS each ACK during the initial phase, but there is one ACK > for each two MSS's. If you have ABC (as recent Linux senders do by default), or don't use delayed ACKs (as Linux receivers don't when the window is small), Detlef was right that it doubles each RTT. $0.02 Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 From lachlan.andrew at gmail.com Tue Jan 2 21:15:27 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Tue, 2 Jan 2007 21:15:27 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459B1B09.40301@isi.edu> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> Message-ID: Greetings, This is probably not related to the original thread (on what happens in real networks, as distinct from what *should* happen), but the word "bug" bugged me... On 02/01/07, Joe Touch wrote: > > ABC is EXPERIMENTAL. Fair enough. I've just noticed that the default in 2.6.18 has been changed to "off", possibly as a result of their experiments :) > > delayed ACKs (as Linux receivers don't when the window is small), > > Delayed ACKs are strongly encouraged. > Both good reasons to fix these bugs in Linux. I don't follow the logic of that at all. Linux deliberatly suppresses delayed ACKs when it guesses that the sender is in slow start, which sems generally correct, judging by the earlier posts in this thread. In that phase, they harm performance, by making slow-start even slower than it was intended to be. Increasing the initial speed of slow starts helps short flows at no long term cost to ongoing long flows. When the window is large, Linux does use delayed ACKs, for the reasons given in the RFCs. Since this is fully standards compliant, I don't see how it can be called a bug. The fact that something is "encouraged" doesn't *of itself* seem a good reason to do it, if there are clear reasons not to. That isn't to say that there may not indeed be good reasons to change Linux's behaviour; I'd be interested to hear them. (On a related note, this year's PFLDnet has a panel session on the implications of network stack implementors Linux and Microsoft setting new de-facto flow control standards. This seems analogous to what the BSD Reno release did, implementing improvements well before Reno made it into the RFCs. The difference is that now a global infrastructure rides on it...) Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 From touch at ISI.EDU Wed Jan 3 11:04:51 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Jan 2007 11:04:51 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> Message-ID: <459BFE53.5070605@isi.edu> Lachlan Andrew wrote: > Greetings Joe, > > On 02/01/07, Joe Touch wrote: >> The improvements in Reno were MORE conservative than TCP as specified, >> not less. Being more conservative is always compliant. > > Correct me if I'm wrong again, but I thought that RFC 1122 mandated > following Jacobson'88, which specifies that specifies that packet > loss, as indicated by timeout, should result in setting the CWND to > its initial small value. I also thought that Reno retransmits before > timeout (less conservative) and consequently only halves the window > (less conservative). > > If the changes made transmission slower, why were they adopted? If > they made it faster, perhaps I'm misinterpreting "conservative". Reno came out roughly about the same time as RFC1122; when I say "as specified", I mean as _specified_ at the time, which was just RFC793 (in this regard, not including Nagle). It's worth considering that the Internet of 1990 wasn't what it is today either. Such experiments had much more limited impact on the international, commercial, and public community at that time. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/fdd74f4d/signature.bin From Anil.Agarwal at viasat.com Wed Jan 3 13:14:20 2007 From: Anil.Agarwal at viasat.com (Agarwal, Anil) Date: Wed, 3 Jan 2007 16:14:20 -0500 Subject: [e2e] Are we doing sliding window in the Internet? References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B0650A3564@VGAEXCH01.hq.corp.viasat.com> Joe at al, To add to this discussion, I just did a few quick tests with a Linux 2.6.18 TCP stack over an (emulated) satellite link. Here are my observations, based on analyzing the packet trace - 1. The sender starts with an initial cwnd of 3 segments, 1448 bytes each (1448 = 1500 - 40 bytes TCP/IPv4 hdr - 12 bytes TCP timestamp option). 2. The receiver acks every segment for the first 32 kbytes of received data; subsequently, it acks every other segment (delayed ack). 3. The sender increases cwnd by 1 segment for every ack (ABC is not used). The cwnd values are as follows - Round cwnd 1 3 segments 2 6 3 10 - for some reason, the sender does not increase cwnd by 6 in this round 4 16 - the 32 kbyte threshold is crossed in this round, so the cwnd increase rate halves These are close to the values described by Detlef. A 50 kbyte transfer finishes in 5 RTTs (including one for the SYN exchange). A quick test on a Sun Solaris 5.8 machine shows the 50 kbyte transfer take 7 RTTs, which is consistent with an implementation that always uses delayed acks. Questions: 1. Is this what the Linux TCP stack implementors intended? Is this documented somewhere? 2. Does this violate any IETF TCP principle, in letter or spirit? It seems to have an (unfair) advantage over TCP implementations that always perform delayed ack. Anil ------------ Anil Agarwal ViaSat Inc. Germantown, MD ________________________________ From: end2end-interest-bounces at postel.org on behalf of Joe Touch Sent: Wed 1/3/2007 1:07 AM To: l.andrew at ieee.org Cc: end2end-interest at postel.org Subject: Re: [e2e] Are we doing sliding window in the Internet? Lachlan Andrew wrote: > Greetings, > > This is probably not related to the original thread (on what happens > in real networks, as distinct from what *should* happen), but the word > "bug" bugged me... > > On 02/01/07, Joe Touch wrote: ... >> > delayed ACKs (as Linux receivers don't when the window is small), >> >> Delayed ACKs are strongly encouraged. >> Both good reasons to fix these bugs in Linux. > > I don't follow the logic of that at all. Please review RFC2581. > Linux deliberatly suppresses > delayed ACKs when it guesses that the sender is in slow start, which > sems generally correct, judging by the earlier posts in this thread. Whether it's interpreted as correct by this email list, it is NOT what the IETF currently recommends. > In that phase, they harm performance, by making slow-start even slower > than it was intended to be. Increasing the initial speed of slow > starts helps short flows at no long term cost to ongoing long flows. > When the window is large, Linux does use delayed ACKs, for the reasons > given in the RFCs. Since this is fully standards compliant, I don't > see how it can be called a bug. > > The fact that something is "encouraged" doesn't *of itself* seem a > good reason to do it, if there are clear reasons not to. That isn't > to say that there may not indeed be good reasons to change Linux's > behaviour; I'd be interested to hear them. I'd be more interested to know that there had been *controlled* experiments to validate that this behavior was safe and did not impact the current behavior of TCP congestion control as per RFC2581. At that point, I'd be interested to have that information taken to the IETF with a proposal to change the recommended behavior, and have it vetted by that community. The idea that this should be tried in the large "until there are good reasons not to" is NOT how such experiments should be performed. > (On a related note, this year's PFLDnet > has a panel session on the > implications of network stack implementors Linux and Microsoft setting > new de-facto flow control standards. This seems analogous to what the > BSD Reno release did, implementing improvements well before Reno made > it into the RFCs. The difference is that now a global infrastructure > rides on it...) The improvements in Reno were MORE conservative than TCP as specified, not less. Being more conservative is always compliant. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/4ae13093/attachment.html From ian.mcdonald at jandi.co.nz Wed Jan 3 13:15:43 2007 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Thu, 4 Jan 2007 10:15:43 +1300 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> Message-ID: <5640c7e00701031315u70a8d89ckabf726487ca3e5f7@mail.gmail.com> On 1/3/07, Lachlan Andrew wrote: > Greetings, > > This is probably not related to the original thread (on what happens > in real networks, as distinct from what *should* happen), but the word > "bug" bugged me... > > On 02/01/07, Joe Touch wrote: > > > > ABC is EXPERIMENTAL. > > Fair enough. I've just noticed that the default in 2.6.18 has been > changed to "off", possibly as a result of their experiments :) > Yes - see http://www.google.com/custom?domains=www.spinics.net&q=%22high+latency+with+tcp+connections%22&sa=Search&sitesearch=www.spinics.net&client=pub-3422782820843221&forid=1&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23003324%3BGL%3A1%3BDIV%3A%2373B59C%3BVLC%3AFF6600%3BAH%3Acenter%3BBGC%3AC5DBCF%3BLBGC%3A66CC99%3BALC%3A330033%3BLC%3A330033%3BT%3A000000%3BGFNT%3A333300%3BGIMP%3A333300%3BFORID%3A1%3B&hl=en-- The thread is messy though so here is probably the most relevant part: Main message is from Dave Miller replying to Stephen Hemminger > On Fri, 1 Sep 2006 01:46:35 +0400 > Alexey Kuznetsov wrote: > > > > Expecting any performance with one byte write's is silly. > > > > I am not sure why you are so confident about status of ABC. > > I missed the discussions, when it was implemented. Apparently, > > it was noticed that ABC in its pure form does not make sense > > with snd_cwnd counted in packets and there were some reasons, > > why it still was not adapted. > > I implemented it but don't think ABC is the correct thing to be doing > in all cases. > > If you read the RFC3465, the problem it is trying to address is that of > small packets causing growth of congestion window beyond the capacity > of the link. > > It makes a number of assumptions that may not be true for Linux: > * ABC doesn't take into account congestion window validation RFC2861 > already prevents most of the problem of inflated growth. > * ABC assumes that the "true" capacity of the link is limited by > byte count not packet count. It seems to me that the thing gained by ABC are twofold: 1) protection against ACK division 2) a way to take delayed ACKs into account for cwnd growth Both of which can be obtained by simply validating the ACK against the retransmit queue, returning number of true packets ACK'd. I would even go so far as to suggest that we should drop ACKs which do not fall on packetization boundaries. Perhaps only when not in LOSS state, but I doubt that this matters in practice. Cases where mid-packet ACK is valid are truly marginal ones involving repacketization wrt. MSS/MTU changes, and these would self-correct eventually. I agree that ABC has some problems. Solution is good, implementation is just horrible :-) From ian.mcdonald at jandi.co.nz Wed Jan 3 13:46:18 2007 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Thu, 4 Jan 2007 10:46:18 +1300 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <5640c7e00701031315u70a8d89ckabf726487ca3e5f7@mail.gmail.com> Message-ID: <5640c7e00701031346r14fa0d88u1b370cc08631a799@mail.gmail.com> > > I would even go so far as to suggest that we should drop ACKs which do > > not fall on packetization boundaries. > > Interesting suggstion. Would TSO be a problem? You'd have to make > sure that the card never got "creative" and put the boundaries where > we don't expect. > I don't know as I'm not an expert here - just cross posting the discussions. You can always email Dave Miller who made the suggestion. Ian -- Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group From weddy at grc.nasa.gov Wed Jan 3 13:48:11 2007 From: weddy at grc.nasa.gov (Wesley Eddy) Date: Wed, 3 Jan 2007 16:48:11 -0500 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459B4834.1050304@isi.edu> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> Message-ID: <20070103214811.GA27322@grc.nasa.gov> On Tue, Jan 02, 2007 at 10:07:48PM -0800, Joe Touch wrote: > > > Lachlan Andrew wrote: > > Greetings, > > > > This is probably not related to the original thread (on what happens > > in real networks, as distinct from what *should* happen), but the word > > "bug" bugged me... > > > > On 02/01/07, Joe Touch wrote: > ... > >> > delayed ACKs (as Linux receivers don't when the window is small), > >> > >> Delayed ACKs are strongly encouraged. > >> Both good reasons to fix these bugs in Linux. > > > > I don't follow the logic of that at all. > > Please review RFC2581. > The exact wording in RFC 2581 says that ACKs should be sent "at least" for every 2 packets, which allows for an ACK to be sent for every packet, as Linux does when it assumes the other side is in slow start. I believe the Linux behavior is perfectly allowable under the letter of RFC 2581. I do not consider this behavior buggy whatsoever. One separate thing to note with regards to ABC is that the RFC2581bis document in TCPM right now RECOMMENDS to increase CWND by the number of bytes ACKed during slow-start - i.e. ABC is RECOMMENDED by that document intended as an update to RFC 2581. -- Wesley M. Eddy Verizon Federal Network Systems -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/7b7001c9/attachment.bin From touch at ISI.EDU Wed Jan 3 14:08:32 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Jan 2007 14:08:32 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <20070103214811.GA27322@grc.nasa.gov> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> Message-ID: <459C2960.7030407@isi.edu> Wesley Eddy wrote: > On Tue, Jan 02, 2007 at 10:07:48PM -0800, Joe Touch wrote: >> >> Lachlan Andrew wrote: >>> Greetings, >>> >>> This is probably not related to the original thread (on what happens >>> in real networks, as distinct from what *should* happen), but the word >>> "bug" bugged me... >>> >>> On 02/01/07, Joe Touch wrote: >> ... >>>>> delayed ACKs (as Linux receivers don't when the window is small), >>>> Delayed ACKs are strongly encouraged. >>>> Both good reasons to fix these bugs in Linux. >>> I don't follow the logic of that at all. >> Please review RFC2581. > > The exact wording in RFC 2581 says that ACKs should be sent "at least" for > every 2 packets, which allows for an ACK to be sent for every packet, as > Linux does when it assumes the other side is in slow start. I believe the > Linux behavior is perfectly allowable under the letter of RFC 2581. I do > not consider this behavior buggy whatsoever. The exact wording from 2581: The delayed ACK algorithm specified in [Bra89] SHOULD be used by a TCP receiver. When used, a TCP receiver MUST NOT excessively delay acknowledgments. Specifically, an ACK SHOULD be generated for at least every second full-sized segment, and MUST be generated within 500 ms of the arrival of the first unacknowledged packet. The first sentence regards the use of delayed ACKs, which Bra89 defines as: A host that is receiving a stream of TCP data segments can increase efficiency in both the Internet and the hosts by sending fewer than one ACK (acknowledgment) segment per data segment received; this is known as a "delayed ACK" [TCP:5]. I.e., "delayed ACK" *means* sending fewer than one ACK per received segment. The second sentence from 2581 says not to excessively delay ACKs just do do delays; the subsequent sentences refer situations that arise due to holding back on ACKs. The paragraph in its entirety means that - when there are no losses or substantial delays, TCP SHOULD ACK *exactly* every other packet - when there are losses or delays, more ACKs can be sent to avoid withholding feedback Granted, 'every two' is a SHOULD not a MUST, but that's the only place for Linux's behavior to be considered compliant. I don't see sufficient reason in "well, it makes *us* go faster" to warrant overriding SHOULD. > One separate thing to note with regards to ABC is that the RFC2581bis > document in TCPM right now RECOMMENDS to increase CWND by the number of > bytes ACKed during slow-start - i.e. ABC is RECOMMENDED by that document > intended as an update to RFC 2581. *When* that doc comes out, then the status of ABC may need to be updated. Until then, widespread default use of ABC is not appropriate. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/2a55e617/signature-0001.bin From touch at ISI.EDU Wed Jan 3 14:37:24 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Jan 2007 14:37:24 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3564@VGAEXCH01.hq.corp.viasat.com> Message-ID: <459C3024.5000903@isi.edu> Lachlan Andrew wrote: ... > As an aside, I thought of a nice hack which I think is within the > letter of the standards, but well outside the spirit. > 1. First packet, send a MSS > 2. After the first ACK, send 2MSS worth of 1-byte packets > 3. 1 RTT later, receive 1MSS worth of ACKs (ack'ing every second packet) > 4. Without ABC, we now have a CWND of 500-1500 packets. > > Could someone tell me if this is within the letter of the standards? RFC1122, Sec 4.2.2.2: An application program is logically required to set the PUSH flag in a SEND call whenever it needs to force delivery of the data to avoid a communication deadlock. However, a TCP SHOULD send a maximum-sized segment whenever possible, to improve performance (see Section 4.2.3.4). Given the penchant for trampling SHOULDs, however, I wouldn't be surprised to see someone implement the above and claim it to be compliant. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/1c7b6c22/signature.bin From touch at ISI.EDU Wed Jan 3 14:46:15 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Jan 2007 14:46:15 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <45980C60.9020405@web.de> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> Message-ID: <459C3237.4000709@isi.edu> Lachlan Andrew wrote: > Greetings, > > On 03/01/07, Joe Touch wrote: >> I.e., "delayed ACK" *means* sending fewer than one ACK per received >> segment. > > It obviously doesn't mean that *every* packet should be ACK'd less > than once (i.e., zero times). It means that *some* packets should not > be ACK'd, just as Linux does once the transmission is underway. > >> I don't see sufficient >> reason in "well, it makes *us* go faster" to warrant overriding SHOULD. > > Agreed!! Selfishness should be discouraged. > > The point is that if *everyone* used QuickACKs, short transfers would > be faster, with almost no harm done to long flows. If you believe that's true, please present some verification. An implementation based on an assertion is insufficient. > (It is a better > approximation to "shortest job first", which is well known to minimise > the average delay for a given utilisation.) It is well known that > slow start is too slow for modern bandwidth-delay products (althought > it was fine when it was proposed). Agreed. > To me, that *is* a good reason to > override a SHOULD. Thought experiments are *lousy* reasons to override SHOULDs. The desire for something better than what we currently have is an equally lousy reason by itself. If you have evidence, please make the case and get the community to agree and deploy this everywhere. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/2045a7f6/signature.bin From faber at ISI.EDU Wed Jan 3 14:59:36 2007 From: faber at ISI.EDU (Ted Faber) Date: Wed, 3 Jan 2007 14:59:36 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459C2960.7030407@isi.edu> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> Message-ID: <20070103225935.GA11407@hut.isi.edu> On Wed, Jan 03, 2007 at 02:08:32PM -0800, Joe Touch wrote: > Granted, 'every two' is a SHOULD not a MUST, but that's the only place > for Linux's behavior to be considered compliant. I don't see sufficient > reason in "well, it makes *us* go faster" to warrant overriding SHOULD. A TCP implementation that acknowledges every packet (and otherwise implements all MUSTs in the relevant RFCs) is a (conditionally) compliant implementation as defined by RFC1122. I really don't see any ambiguity there. (OK, RFC1122 could say that all conditionally and unconditionally compliant implementations are compliant, which it doesn't, so strictly speaking I should remove the parens around "conditionally" above: "anal-retentive" is hyphenated.) "Buggy," unlike "(un)?conditionally compliant," is not well defined, but I don't think that the majority of implementors would agree that a conditionally compliant TCP implementation is per se a buggy one. It's a good way to argue about text rather than the design decision, though. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/7a4129bf/attachment.bin From touch at ISI.EDU Wed Jan 3 15:51:07 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Jan 2007 15:51:07 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <20070103225935.GA11407@hut.isi.edu> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> Message-ID: <459C416B.7040702@isi.edu> Ted Faber wrote: > On Wed, Jan 03, 2007 at 02:08:32PM -0800, Joe Touch wrote: >> Granted, 'every two' is a SHOULD not a MUST, but that's the only place >> for Linux's behavior to be considered compliant. I don't see sufficient >> reason in "well, it makes *us* go faster" to warrant overriding SHOULD. > > A TCP implementation that acknowledges every packet (and otherwise > implements all MUSTs in the relevant RFCs) is a (conditionally) > compliant implementation as defined by RFC1122. I really don't see any > ambiguity there. (OK, RFC1122 could say that all conditionally and > unconditionally compliant implementations are compliant, which it > doesn't, so strictly speaking I should remove the parens around > "conditionally" above: "anal-retentive" is hyphenated.) Conditional compliance should come with a statement of the conditions. Absent that, it's just buggy. Reasonable conditions do not include "it makes *us* go faster"; the include things like "this implementation is to be deployed in a limited environment that is overwhelmingly satellite-oriented" - e.g., if DirectPC were to use a variant for proxy traffic to its home routers that overrode SHOULDs for those reasons, that'd be non-buggy. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/8d345fa3/signature.bin From L.Wood at surrey.ac.uk Wed Jan 3 16:26:34 2007 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Thu, 04 Jan 2007 00:26:34 +0000 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459C416B.7040702@isi.edu> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> Message-ID: <200701040027.AAA13758@cisco.com> At Wednesday 03/01/2007 15:51 -0800, Joe Touch wrote: >Ted Faber wrote: >> On Wed, Jan 03, 2007 at 02:08:32PM -0800, Joe Touch wrote: >>> Granted, 'every two' is a SHOULD not a MUST, but that's the only place >>> for Linux's behavior to be considered compliant. I don't see sufficient >>> reason in "well, it makes *us* go faster" to warrant overriding SHOULD. >> >> A TCP implementation that acknowledges every packet (and otherwise >> implements all MUSTs in the relevant RFCs) is a (conditionally) >> compliant implementation as defined by RFC1122. I really don't see any >> ambiguity there. (OK, RFC1122 could say that all conditionally and >> unconditionally compliant implementations are compliant, which it >> doesn't, so strictly speaking I should remove the parens around >> "conditionally" above: "anal-retentive" is hyphenated.) > >Conditional compliance should come with a statement of the conditions. >Absent that, it's just buggy. > >Reasonable conditions do not include "it makes *us* go faster"; the >include things like "this implementation is to be deployed in a limited >environment that is overwhelmingly satellite-oriented" - e.g., if >DirectPC were to use a variant for proxy traffic to its home routers >that overrode SHOULDs for those reasons, that'd be non-buggy. So, if we're DirecPC, overriding SHOULDs can make us go faster. Do these semantic wranglings actually have a point? L. From L.Wood at surrey.ac.uk Wed Jan 3 16:28:12 2007 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Thu, 04 Jan 2007 00:28:12 +0000 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459C3237.4000709@isi.edu> References: <45980C60.9020405@web.de> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <459C3237.4000709@isi.edu> Message-ID: <200701040028.AAA13798@cisco.com> At Wednesday 03/01/2007 14:46 -0800, Joe Touch wrote: >> >> The point is that if *everyone* used QuickACKs, short transfers would >> be faster, with almost no harm done to long flows. > >If you believe that's true, please present some verification. An >implementation based on an assertion is insufficient. And yet everyone is expected to implement based on the simple MUST and SHOULD assertions in RFCs, given without explanation. Which is, as you say, insufficient. L. From touch at ISI.EDU Wed Jan 3 16:36:01 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Jan 2007 16:36:01 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <200701040028.AAA13798@cisco.com> References: <45980C60.9020405@web.de> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <459C3237.4000709@isi.edu> <200701040028.AAA13798@cisco.com> Message-ID: <459C4BF1.6060004@isi.edu> Lloyd Wood wrote: > At Wednesday 03/01/2007 14:46 -0800, Joe Touch wrote: >>> The point is that if *everyone* used QuickACKs, short transfers would >>> be faster, with almost no harm done to long flows. >> If you believe that's true, please present some verification. An >> implementation based on an assertion is insufficient. > > And yet everyone is expected to implement based on the simple MUST > and SHOULD assertions in RFCs, given without explanation. > > Which is, as you say, insufficient. It should be insufficient to get those words into an RFC without evidence that they are appropriate. RFCs are neither the sole nor necessarily the appropriate place for that information; they can and should cite published work that validates their claims. Whether we should trust the IETF to do that is independent of whether we should ignore them solely for the benefit of individual performance. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/11df03ab/signature.bin From touch at ISI.EDU Wed Jan 3 16:44:03 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Jan 2007 16:44:03 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <200701040027.AAA13758@cisco.com> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> Message-ID: <459C4DD3.3010106@isi.edu> Lloyd Wood wrote: > At Wednesday 03/01/2007 15:51 -0800, Joe Touch wrote: ... >> Reasonable conditions do not include "it makes *us* go faster"; the >> include things like "this implementation is to be deployed in a limited >> environment that is overwhelmingly satellite-oriented" - e.g., if >> DirectPC were to use a variant for proxy traffic to its home routers >> that overrode SHOULDs for those reasons, that'd be non-buggy. > > So, if we're DirecPC, overriding SHOULDs can make us go faster. Yes, but they would not impact others, i.e., their impact would be local to DirectPC's infrastructure. > Do these semantic wranglings actually have a point? The question is "under what conditions is it permissible to override a SHOULD". I would hope that would be clarified in an update to 2119, but don't know what the state of that doc is... Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/e8acd584/signature-0001.bin From L.Wood at surrey.ac.uk Wed Jan 3 17:57:05 2007 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Thu, 04 Jan 2007 01:57:05 +0000 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459C4BF1.6060004@isi.edu> References: <45980C60.9020405@web.de> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <459C3237.4000709@isi.edu> <200701040028.AAA13798@cisco.com> <459C4BF1.6060004@isi.edu> Message-ID: <200701040157.BAA18111@cisco.com> At Wednesday 03/01/2007 16:36 -0800, Joe Touch wrote: >*** PGP SIGNATURE VERIFICATION *** >*** Status: Good Signature from Invalid Key >*** Alert: Please verify signer's key before trusting signature. >*** Signer: Joe Touch (0x89A766BB) >*** Signed: 04/01/2007 00:36:02 >*** Verified: 04/01/2007 01:24:20 >*** BEGIN PGP VERIFIED MESSAGE *** > > > >Lloyd Wood wrote: >> At Wednesday 03/01/2007 14:46 -0800, Joe Touch wrote: >>>> The point is that if *everyone* used QuickACKs, short transfers would >>>> be faster, with almost no harm done to long flows. >>> If you believe that's true, please present some verification. An >>> implementation based on an assertion is insufficient. >> >> And yet everyone is expected to implement based on the simple MUST >> and SHOULD assertions in RFCs, given without explanation. >> >> Which is, as you say, insufficient. > >It should be insufficient to get those words into an RFC without >evidence that they are appropriate. RFCs are neither the sole nor >necessarily the appropriate place for that information; they can and >should cite published work that validates their claims. Such citations would be informational rather than normative, and therefore optional. Informational references tend to get left out of RFCs. >Whether we >should trust the IETF to do that is independent of whether we should >ignore them solely for the benefit of individual performance. > >Joe > >-- >---------------------------------------- >Joe Touch >Sr. Network Engineer, USAF TSAT Space Segment > > > >*** END PGP VERIFIED MESSAGE *** From Anil.Agarwal at viasat.com Wed Jan 3 19:59:35 2007 From: Anil.Agarwal at viasat.com (Agarwal, Anil) Date: Wed, 3 Jan 2007 22:59:35 -0500 Subject: [e2e] Are we doing sliding window in the Internet? References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com><459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de><459AF57A.5080304@isi.edu><459B1B09.40301@isi.edu><459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov><459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu><459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> <459C4DD3.3010106@isi.edu> Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> Joe Touch wrote : >> Do these semantic wranglings actually have a point? > The question is "under what conditions is it permissible to override a > SHOULD". I would hope that would be clarified in an update to 2119, but > don't know what the state of that doc is... 1. The technical issue in question is QuickAck, where delayed acks are not used for the first R / 2 bytes of received data, where R seems to be the receive socket buffer size 2. QuickAck is enabled in Linux, by default. There is no procedure to disable it, except temporarily, for an application via a system call. 3. Linux supports many other "non-standard" TCP features, but most/all of them seem to be disabled by default. 4. There does not seem to be a whole lot of technical documentation on the feature, except for the Linux man page. It is not clear how this feature gets turned on and off during the life of a connection. There is no RFC on the subject. 5. It seems to violate a "SHOULD" statement in the RFCs. 6. It's objective is certainly not nefarious. It improves performance for individual short data transfers. Perhaps the SHOULD needs to be changed with some qualifications. But that requires an open discussion. It is perhaps understandable that SHOULDs and even MUSTs can be violated in controlled experimental environments (e.g., simulations). It is perhaps understandable that SHOULDs may be violated in controlled , isolated environments (e.g., satellite networks). It may be unavoidable that a SHOULD or MUST is violated by a "hacker" and used over over the Internet. But under what circumstances should a SHOULD be violated and let loose over the Internet as part of a widely used OS? One would like to think that the last category should require some care and a rigorous process. Is this process not documented or well understood? Surely, it cannot be - implement, deploy, publish paper and write RFC :). What role should the IETF play in this process? Advisory only? Anil ----- Anil Agarwal ViaSat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/9be39f79/attachment.html From L.Wood at surrey.ac.uk Wed Jan 3 20:29:19 2007 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Thu, 04 Jan 2007 04:29:19 +0000 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.v iasat.com> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> <459C4DD3.3010106@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> Message-ID: <200701040429.EAA24974@cisco.com> This issue is minor compared to the widespread changes to their TCP stack Microsoft made with adopting Compound TCP in Vista. http://www.microsoft.com/technet/community/columns/cableguy/cg1105.mspx and the IETF didn't have any say in that either. Standards bodies don't ship code. At Wednesday 03/01/2007 22:59 -0500, Agarwal, Anil wrote: > >Joe Touch wrote : > >>> Do these semantic wranglings actually have a point? > >> The question is "under what conditions is it permissible to override a >> SHOULD". I would hope that would be clarified in an update to 2119, but >> don't know what the state of that doc is... > >1. The technical issue in question is QuickAck, where delayed acks are not used for the first R / 2 bytes of received data, where R seems to be the receive socket buffer size >2. QuickAck is enabled in Linux, by default. There is no procedure to disable it, except temporarily, for an application via a system call. >3. Linux supports many other "non-standard" TCP features, but most/all of them seem to be disabled by default. >4. There does not seem to be a whole lot of technical documentation on the feature, except for the Linux man page. It is not clear how this feature gets turned on and off during the life of a connection. There is no RFC on the subject. >5. It seems to violate a "SHOULD" statement in the RFCs. >6. It's objective is certainly not nefarious. It improves performance for individual short data transfers. Perhaps the SHOULD needs to be changed with some qualifications. But that requires an open discussion. > >It is perhaps understandable that SHOULDs and even MUSTs can be violated in controlled experimental environments (e.g., simulations). >It is perhaps understandable that SHOULDs may be violated in controlled , isolated environments (e.g., satellite networks). >It may be unavoidable that a SHOULD or MUST is violated by a "hacker" and used over over the Internet. >But under what circumstances should a SHOULD be violated and let loose over the Internet as part of a widely used OS? > >One would like to think that the last category should require some care and a rigorous process. Is this process not documented or well understood? Surely, it cannot be - implement, deploy, publish paper and write RFC :). What role should the IETF play in this process? Advisory only? > >Anil >----- >Anil Agarwal >ViaSat Inc. > From touch at ISI.EDU Wed Jan 3 21:14:06 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Jan 2007 21:14:06 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <200701040157.BAA18111@cisco.com> References: <45980C60.9020405@web.de> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <459C3237.4000709@isi.edu> <200701040028.AAA13798@cisco.com> <459C4BF1.6060004@isi.edu> <200701040157.BAA18111@cisco.com> Message-ID: <459C8D1E.5080404@isi.edu> Lloyd Wood wrote: > At Wednesday 03/01/2007 16:36 -0800, Joe Touch wrote: ... >> It should be insufficient to get those words into an RFC without >> evidence that they are appropriate. RFCs are neither the sole nor >> necessarily the appropriate place for that information; they can and >> should cite published work that validates their claims. > > Such citations would be informational rather than normative, and therefore optional. Although there is a distinction between required citations of protocols (normative) and other references, I don't agree that it's appropriate to consider all informative references optional. They're informative only in the sense that they don't cite protocol standards; they're required if they are needed to understand motivation. > Informational references tend to get left out of RFCs. I hope we all avoid making that mistake, or allowing others to do so. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/88153b30/signature.bin From touch at ISI.EDU Wed Jan 3 21:15:52 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Jan 2007 21:15:52 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <200701040429.EAA24974@cisco.com> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> <459C4DD3.3010106@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> <200701040429.EAA24974@cisco.com> Message-ID: <459C8D88.5020603@isi.edu> Lloyd Wood wrote: > This issue is minor compared to the widespread changes to their TCP stack Microsoft made with adopting Compound TCP in Vista. > http://www.microsoft.com/technet/community/columns/cableguy/cg1105.mspx > > and the IETF didn't have any say in that either. Standards bodies don't ship code. And two bugs don't make a right ;-) Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/79c7a38b/signature.bin From touch at ISI.EDU Wed Jan 3 21:21:04 2007 From: touch at ISI.EDU (Joe Touch) Date: Wed, 03 Jan 2007 21:21:04 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com><459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de><459AF57A.5080304@isi.edu><459B1B09.40301@isi.edu><459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov><459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu><459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> <459C4DD3.3010106@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> Message-ID: <459C8EC0.3050708@isi.edu> Agarwal, Anil wrote: ... > 1. The technical issue in question is QuickAck, where delayed acks are > not used for the first R / 2 bytes of received data, where R seems to be > the receive socket buffer size > 2. QuickAck is enabled in Linux, by default. There is no procedure to > disable it, except temporarily, for an application via a system call. > 3. Linux supports many other "non-standard" TCP features, but most/all > of them seem to be disabled by default. > 4. There does not seem to be a whole lot of technical documentation on > the feature, except for the Linux man page. It is not clear how this > feature gets turned on and off during the life of a connection. There > is no RFC on the subject. > 5. It seems to violate a "SHOULD" statement in the RFCs. > 6. It's objective is certainly not nefarious. It improves performance > for individual short data transfers. Perhaps the SHOULD needs to be > changed with some qualifications. But that requires an open discussion. Nefarious motives are not the issue. The SHOULD currently stands, and it is Linux's default that should be changed first. ... > But under what circumstances should a SHOULD be violated and let loose > over the Internet as part of a widely used OS? > > One would like to think that the last category should require some care > and a rigorous process. Is this process not documented or well > understood? Surely, it cannot be - implement, deploy, publish paper and > write RFC :). How about "implement, *test*, publish a paper or bring the results to the IETF, and publish an RFC"? (i.e., basically, "of course it can be") And don't call me Shirley ;-) (with apologies in advance to those not familiar with the movie "Airplane") > What role should the IETF play in this process? Advisory only? The IETF plays the role of standards body. Linux (and Microsoft) *should* play the role of test first, deploy later. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070103/d677beb1/signature-0001.bin From ian.mcdonald at jandi.co.nz Wed Jan 3 23:54:14 2007 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Thu, 4 Jan 2007 20:54:14 +1300 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> <459C4DD3.3010106@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> Message-ID: <5640c7e00701032354l1ba3feccn8bdda21e9df37cd4@mail.gmail.com> > One would like to think that the last category should require some care and > a rigorous process. Is this process not documented or well understood? > Surely, it cannot be - implement, deploy, publish paper and write RFC :). > What role should the IETF play in this process? Advisory only? > You'll find that Linux is probably the most RFC compliant implementation of TCP. However Linux isn't perfect and the developers do as they want. I think the bigger issue is that there are academics in one corner and implementors in another and usually they are not the same people and often don't even talk to each other. Linux is a meritocracy so if people from this list were to go over to the netdev mailing list and make a reasonable argument then it will get listened to. Ian -- Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group From ian.mcdonald at jandi.co.nz Wed Jan 3 23:55:23 2007 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Thu, 4 Jan 2007 20:55:23 +1300 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459C8EC0.3050708@isi.edu> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> <459C4DD3.3010106@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> <459C8EC0.3050708@isi.edu> Message-ID: <5640c7e00701032355g3332edb5ma4897ed996618239@mail.gmail.com> On 1/4/07, Joe Touch wrote: > Nefarious motives are not the issue. The SHOULD currently stands, and it > is Linux's default that should be changed first. If you think Linux has a problem here post it to netdev at vger.kernel.org and say what is wrong and why. Even better if it comes with patches. Ian -- Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group From detlef.bosau at web.de Thu Jan 4 06:24:07 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 04 Jan 2007 15:24:07 +0100 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <5640c7e00701032354l1ba3feccn8bdda21e9df37cd4@mail.gmail.com> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> <459C4DD3.3010106@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> <5640c7e00701032354l1ba3feccn8bdda21e9df37cd4@mail.gmail.com> Message-ID: <459D0E07.7040004@web.de> Ian McDonald wrote: >> > You'll find that Linux is probably the most RFC compliant > implementation of TCP. However Linux isn't perfect and the developers > do as they want. > > I think the bigger issue is that there are academics in one corner and > implementors in another and usually they are not the same people and > often don't even talk to each other. No. I basically disagree. Sounds similar to a paper last year which I criticized and the answer was: "You can publisch results yourself!" Correctness is not proven by acclamation. And if some implementation is buggy or not standard compliant this is not healed by a large number of implementors who do something wrong. Last year, I had some look at some networking code in the BSD kernel and much of it reminded me of code, I?ve seen in the NS2. And there have been comments with names. With authors. And from that I guess, that many of the "academics" have done a great deal of implementation work, particularly in the field of TCP. In addition, computer science is an engineering discipline. And in engineering, you _first_ do research, _then_ you test your protocols, _then_ you write the standards if the tests yield convincing results and further implmentations are to follow the standards. Period. The other way round is some kind of trial and error. I think, we all remember the well known fortune cookie "If builders built buildings like programmers write programs, any woodpecker that came along would destroy human civilization." That directly applies here. I pesonally find it difficult to have always the "state of the art" i.e. the actual standards of TCP in mind, but this my problem and I have to deal with it. However, TCP is not a meritocratic or implmentocratic or commerciocratic election and the winner is M$ for today and Linux for tommorrow and afterwards it?s Novell, and then I once again see one of these funny "TCP probing" papers where some guys propose a sophisticated test suite which standards they follow, if any. I strongly believe in sound scientific work and standards which are based on that. And from that, implementations are simply to follow the standards - no ifs and buts. We have learned this in any other field of enginieriung but computer science. However, it?s necessary for computer science to achieve maturity to catch up with other disciplines here. And I say this from my own experience in professional life, because other engineers often ridicule about CS or even take it not seriously - for exactly this reason. Detlef > Linux is a meritocracy so if > people from this list were to go over to the netdev mailing list and > make a reasonable argument then it will get listened to. > > Ian From touch at ISI.EDU Thu Jan 4 06:39:11 2007 From: touch at ISI.EDU (Joe Touch) Date: Thu, 04 Jan 2007 06:39:11 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <5640c7e00701032355g3332edb5ma4897ed996618239@mail.gmail.com> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> <459C4DD3.3010106@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> <459C8EC0.3050708@isi.edu> <5640c7e00701032355g3332edb5ma4897ed996618239@mail.gmail.com> Message-ID: <459D118F.8070309@isi.edu> Ian McDonald wrote: > On 1/4/07, Joe Touch wrote: >> Nefarious motives are not the issue. The SHOULD currently stands, and it >> is Linux's default that should be changed first. > > If you think Linux has a problem here post it to > netdev at vger.kernel.org and say what is wrong and why. Even better if > it comes with patches. That's a convenient way to ensure that the problem doesn't get fixed. Participating in the IETF is not a full-time job, and going around to every OS's specific discussion venue to make the case to fix a bug - or demanding that we fix it - confuses this body with a free, evangelical repair service, which it is not. I've made the case that this is a problem here, on this list. We can take that discussion to the TSVWG mailing list if desired. Yhe next step in the IETF process - given others agree this is a bug and it does not get fixed by the *Linux community* (no, we're not all part of that) - would be to add this to an update to RFC 2525. If others decide that this should be a change to all TCPs, then the next step would be to propose it as a change in an I-D. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070104/7e79abbf/signature.bin From touch at ISI.EDU Thu Jan 4 07:09:01 2007 From: touch at ISI.EDU (Joe Touch) Date: Thu, 04 Jan 2007 07:09:01 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <5640c7e00701032354l1ba3feccn8bdda21e9df37cd4@mail.gmail.com> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> <459C4DD3.3010106@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> <5640c7e00701032354l1ba3feccn8bdda21e9df37cd4@mail.gmail.com> Message-ID: <459D188D.8060204@isi.edu> Ian McDonald wrote: >> One would like to think that the last category should require some >> care and >> a rigorous process. Is this process not documented or well understood? >> Surely, it cannot be - implement, deploy, publish paper and write RFC :). >> What role should the IETF play in this process? Advisory only? >> > You'll find that Linux is probably the most RFC compliant > implementation of TCP. Should we include the time when Linux defaulted T/TCP to "on" in that? Or the default-ON of ABC? I.e., there are certainly points when versions of Linux were clearly not RFC-compliant in more significant ways; which version are you referring to? And *WE* won't find that. If you want to look for evidence of that fact, then please do. But unfounded assertions do not make it so, nor does throwing the gauntlet at the rest of the world saying, "if you think this is wrong, PROVE it". > However Linux isn't perfect and the developers > do as they want. That's clearly true. The good news is that Linux ends up with some of the earliest versions of new protocols. The bad news is that Linux sometimes enables things as default that were never intended as such. > I think the bigger issue is that there are academics in one corner and > implementors in another and usually they are not the same people and > often don't even talk to each other. If I'm the academic in this discussion, note that I have a number of patches that fixed bugs in FreeBSD. Just because I don't work on Linux doesn't render me an academic. However, you're right - we're not all in the same corner. I'm in the IETF corner, as are developers from other OS's, and right now it seems like you're representing the Linux community in their corner demanding that we all come over there for a chat (see below). > Linux is a meritocracy so if > people from this list were to go over to the netdev mailing list and > make a reasonable argument then it will get listened to. That's the disconnect here. *THE* place for this sort of discussion is the IETF, which this list is a peripheral (IRTF) party to. Perhaps the discussion should occur on TSVWG, or even TCPM. But expecting us to take this to the Linux community is a disconnect on how standards bodies work. Again, we don't all work on Linux. Linux cannot demand that of the world. The Linux community needs to participate in the bodies of standards it uses, and expect that of its developers. I know of no standards body that sends emissaries to developer communities (at best, they send emissaries to other standards bodies). The converse is the way things work; Linux is implementing IETF protocols, and has an *obligation* to participate in the IETF, where other communities participate. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070104/38a0cbdd/signature.bin From perfgeek at mac.com Thu Jan 4 07:13:26 2007 From: perfgeek at mac.com (rick jones) Date: Thu, 4 Jan 2007 07:13:26 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <5640c7e00701031346r14fa0d88u1b370cc08631a799@mail.gmail.com> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <5640c7e00701031315u70a8d89ckabf726487ca3e5f7@mail.gmail.com> <5640c7e00701031346r14fa0d88u1b370cc08631a799@mail.gmail.com> Message-ID: <4e17c6bbe1c216e4f25ced41852dab5f@mac.com> > I don't know as I'm not an expert here - just cross posting the > discussions. You can always email Dave Miller who made the suggestion. Direct email to David Miller generally (well, if my experience can be generalized, perhaps I'm just too far back in the peanut gallery) results in a "send it to the list" response. In this case that would be netdev at vger.kernel.org. rick jones From Anil.Agarwal at viasat.com Thu Jan 4 07:20:18 2007 From: Anil.Agarwal at viasat.com (Agarwal, Anil) Date: Thu, 4 Jan 2007 10:20:18 -0500 Subject: [e2e] Are we doing sliding window in the Internet? References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> <459C4DD3.3010106@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> <200701040429.EAA24974@cisco.com> Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B0650A356B@VGAEXCH01.hq.corp.viasat.com> Lloyd Wood wrote: > This issue is minor compared to the widespread changes to their TCP stack > Microsoft made with adopting Compound TCP in Vista. > http://www.microsoft.com/technet/community/columns/cableguy/cg1105.mspx > > and the IETF didn't have any say in that either. Standards bodies don't ship > code. Yikes !! >From the above URL - "CTCP is enabled by default in computers running Windows Server "Longhorn" ..." Whatever happened to the idea of vendors and IETF conducting trial tests over the Internet for a period of time and writing RFCs before widespread deployment of a new protocol feature? Anil ----- Anil Agarwal ViaSat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070104/babb6f99/attachment.html From lachlan.andrew at gmail.com Wed Jan 3 10:38:58 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 3 Jan 2007 10:38:58 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459B4834.1050304@isi.edu> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> Message-ID: Greetings Joe, On 02/01/07, Joe Touch wrote: > The improvements in Reno were MORE conservative than TCP as specified, > not less. Being more conservative is always compliant. Correct me if I'm wrong again, but I thought that RFC 1122 mandated following Jacobson'88, which specifies that specifies that packet loss, as indicated by timeout, should result in setting the CWND to its initial small value. I also thought that Reno retransmits before timeout (less conservative) and consequently only halves the window (less conservative). If the changes made transmission slower, why were they adopted? If they made it faster, perhaps I'm misinterpreting "conservative". Cheers, Lachaln -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 From lachlan.andrew at gmail.com Wed Jan 3 13:40:46 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 3 Jan 2007 13:40:46 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <5640c7e00701031315u70a8d89ckabf726487ca3e5f7@mail.gmail.com> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <5640c7e00701031315u70a8d89ckabf726487ca3e5f7@mail.gmail.com> Message-ID: Greetings Ian, On 03/01/07, Ian McDonald wrote: > On 1/3/07, Lachlan Andrew wrote: > > the default in 2.6.18 has been > > changed to "off", possibly as a result of their experiments :) > > > Yes - see http://www.google.com/custom?domains=www.spinics.net&q=%22high+latency+with+tcp+connections%22&sa=Search&sitesearch=www.spinics.net&client=pub-3422782820843221&forid=1&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23003324%3BGL%3A1%3BDIV%3A%2373B59C%3BVLC%3AFF6600%3BAH%3Acenter%3BBGC%3AC5DBCF%3BLBGC%3A66CC99%3BALC%3A330033%3BLC%3A330033%3BT%3A000000%3BGFNT%3A333300%3BGIMP%3A333300%3BFORID%3A1%3B&hl=en-- Thanks for that explanation. > I would even go so far as to suggest that we should drop ACKs which do > not fall on packetization boundaries. Interesting suggstion. Would TSO be a problem? You'd have to make sure that the card never got "creative" and put the boundaries where we don't expect. Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 From lachlan.andrew at gmail.com Wed Jan 3 14:24:54 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 3 Jan 2007 14:24:54 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <0B0A20D0B3ECD742AA2514C8DDA3B0650A3564@VGAEXCH01.hq.corp.viasat.com> References: <45980C60.9020405@web.de> <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3564@VGAEXCH01.hq.corp.viasat.com> Message-ID: Greetigns Anil, On 03/01/07, Agarwal, Anil wrote: > I just did a few quick tests with a Linux 2.6.18 > TCP stack over an (emulated) satellite link. > > A 50 kbyte transfer finishes in 5 RTTs (including one for the SYN exchange). > a Sun Solaris 5.8 machine shows the 50 kbyte transfer take 7 RTTs. > > 1. Is this what the Linux TCP stack implementors intended? Is this > documented somewhere? I can't speak for them, but I would think that speeding up slow start was their aim, yes. Google "quickack", or look at man 7 tcp on a Linux system. > 2. Does this violate any IETF TCP principle, in letter or spirit? It seems > to have an (unfair) advantage over TCP implementations that always perform > delayed ack. I personally think it is within the spirit of TCP. TCP is already internally unfair (look at "RTT unfairness", or "jumbo-frame unfairness", which can give speed disparities much greater than 7:5). The original aim of TCP was a roughly-fair mechanism to achieve good effective data rates while avoiding congestion collapse. Speeding up slow start is an important part of improving the effective data rate. If absolute equality of rates had been the aim, wouldn't the algorithms have been specified independently of the MSS, and wouldn't steps have been taken to avoid RTT-unfairness when it was discovered? As an aside, I thought of a nice hack which I think is within the letter of the standards, but well outside the spirit. 1. First packet, send a MSS 2. After the first ACK, send 2MSS worth of 1-byte packets 3. 1 RTT later, receive 1MSS worth of ACKs (ack'ing every second packet) 4. Without ABC, we now have a CWND of 500-1500 packets. Could someone tell me if this is within the letter of the standards? Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 From lachlan.andrew at gmail.com Wed Jan 3 14:37:46 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 3 Jan 2007 14:37:46 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459C2960.7030407@isi.edu> References: <45980C60.9020405@web.de> <459AA501.8050901@isi.edu> <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> Message-ID: Greetings, On 03/01/07, Joe Touch wrote: > I.e., "delayed ACK" *means* sending fewer than one ACK per received > segment. It obviously doesn't mean that *every* packet should be ACK'd less than once (i.e., zero times). It means that *some* packets should not be ACK'd, just as Linux does once the transmission is underway. > I don't see sufficient > reason in "well, it makes *us* go faster" to warrant overriding SHOULD. Agreed!! Selfishness should be discouraged. The point is that if *everyone* used QuickACKs, short transfers would be faster, with almost no harm done to long flows. (It is a better approximation to "shortest job first", which is well known to minimise the average delay for a given utilisation.) It is well known that slow start is too slow for modern bandwidth-delay products (althought it was fine when it was proposed). To me, that *is* a good reason to override a SHOULD. Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 From L.Wood at surrey.ac.uk Thu Jan 4 08:24:34 2007 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Thu, 04 Jan 2007 16:24:34 +0000 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459D118F.8070309@isi.edu> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> <459C4DD3.3010106@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> <459C8EC0.3050708@isi.edu> <5640c7e00701032355g3332edb5ma4897ed996618239@mail.gmail.com> <459D118F.8070309@isi.edu> Message-ID: <200701041625.QAA20711@cisco.com> At Thursday 04/01/2007 06:39 -0800, Joe Touch wrote: >Yhe next step in the IETF process - given others agree this is a bug and >it does not get fixed by the *Linux community* (no, we're not all part >of that) obviously, since ABC and other TCP specifications in RFCs are quite specific to BSD stacks. L. From faber at ISI.EDU Thu Jan 4 08:26:04 2007 From: faber at ISI.EDU (Ted Faber) Date: Thu, 4 Jan 2007 08:26:04 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459C416B.7040702@isi.edu> References: <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> Message-ID: <20070104162604.GA85755@hut.isi.edu> On Wed, Jan 03, 2007 at 03:51:07PM -0800, Joe Touch wrote: > > > Ted Faber wrote: > > On Wed, Jan 03, 2007 at 02:08:32PM -0800, Joe Touch wrote: > >> Granted, 'every two' is a SHOULD not a MUST, but that's the only place > >> for Linux's behavior to be considered compliant. I don't see sufficient > >> reason in "well, it makes *us* go faster" to warrant overriding SHOULD. > > > > A TCP implementation that acknowledges every packet (and otherwise > > implements all MUSTs in the relevant RFCs) is a (conditionally) > > compliant implementation as defined by RFC1122. I really don't see any > > ambiguity there. (OK, RFC1122 could say that all conditionally and > > unconditionally compliant implementations are compliant, which it > > doesn't, so strictly speaking I should remove the parens around > > "conditionally" above: "anal-retentive" is hyphenated.) > > Conditional compliance should come with a statement of the conditions. > Absent that, it's just buggy. Now who's not reading 1122? The terms are defined there and there's no indication of a "signing statement" requirement for conditionally compliant implementations. It's just a phrase that means "did all the MUSTs and omitted one or more of the SHOULDs." It's precise, unlike the "buggy" word we can't agree on. You may disagree with omitting delayed ACKs, but the RFCs allow it. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070104/21c5ea18/attachment.bin From touch at ISI.EDU Thu Jan 4 08:57:45 2007 From: touch at ISI.EDU (Joe Touch) Date: Thu, 04 Jan 2007 08:57:45 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <20070104162604.GA85755@hut.isi.edu> References: <459AB7E3.7010705@web.de> <459AF57A.5080304@isi.edu> <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <20070104162604.GA85755@hut.isi.edu> Message-ID: <459D3209.5090602@isi.edu> Ted Faber wrote: > On Wed, Jan 03, 2007 at 03:51:07PM -0800, Joe Touch wrote: ... >> Conditional compliance should come with a statement of the conditions. >> Absent that, it's just buggy. > > Now who's not reading 1122? The terms are defined there and there's > no indication of a "signing statement" requirement for conditionally > compliant implementations. It's just a phrase that means "did all the > MUSTs and omitted one or more of the SHOULDs." It's precise, unlike the > "buggy" word we can't agree on. See below... > You may disagree with omitting delayed ACKs, but the RFCs allow it. RFC1122 also states: * "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. I.e., if you negate a SHOULD you ought to demonstrate you understand the implications and have weighed the case. That's clearly stated in RFC1122. It may not be reiterated where "conditionally compliant" is defined, but it comes along when a SHOULD is negated. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070104/916925b4/signature.bin From faber at ISI.EDU Thu Jan 4 10:16:33 2007 From: faber at ISI.EDU (Ted Faber) Date: Thu, 4 Jan 2007 10:16:33 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459D3209.5090602@isi.edu> References: <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <20070104162604.GA85755@hut.isi.edu> <459D3209.5090602@isi.edu> Message-ID: <20070104181633.GC85755@hut.isi.edu> On Thu, Jan 04, 2007 at 08:57:45AM -0800, Joe Touch wrote: > > > Ted Faber wrote: > > On Wed, Jan 03, 2007 at 03:51:07PM -0800, Joe Touch wrote: > ... > >> Conditional compliance should come with a statement of the conditions. > >> Absent that, it's just buggy. > > > > Now who's not reading 1122? The terms are defined there and there's > > no indication of a "signing statement" requirement for conditionally > > compliant implementations. It's just a phrase that means "did all the > > MUSTs and omitted one or more of the SHOULDs." It's precise, unlike the > > "buggy" word we can't agree on. > > See below... > > > You may disagree with omitting delayed ACKs, but the RFCs allow it. > > RFC1122 also states: > > * "SHOULD" > > This word or the adjective "RECOMMENDED" means that there > may exist valid reasons in particular circumstances to > ignore this item, but the full implications should be > understood and the case carefully weighed before choosing > a different course. > > I.e., if you negate a SHOULD you ought to demonstrate you understand the > implications and have weighed the case. That's clearly stated in > RFC1122. If we're going to be picky (and why stop now?) no *demonstration* is required. It says that implementors *should* to think seriously about their choice when they violate a SHOULD, not that they have to explain their thinking to you (or me, or anyone else). I understand that there's no objective way to make sure that thinking has been done, but there's no requirement to present it either. To whom would you require such a presentation, anyway? And, of course, there's a "should" in the definition of SHOULD. Regardless of whether any thinking at all has happened, one can ignore a SHOULD and be within the letter of the RFC "law." FWIW, I don't think SHOULDs should be thrown aside lightly, either. But they're spots where the IETF consensus admits that designers and implementors can make a different decision without catastrophic interoperability problems. For my money "bug" is much more derisive than even "wrong design" because it implies (to me) a level of obliviousness that doesn't seem present here. Bugs are accidents; this seems like a conscious choice. I understand it's a choice you disagree with, but IMHO it's a choice that violates no RFC. I think you're much better off debating the content of the design decision than wether it violates some unenforcable boundary. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070104/7942ae30/attachment.bin From touch at ISI.EDU Thu Jan 4 10:40:16 2007 From: touch at ISI.EDU (Joe Touch) Date: Thu, 04 Jan 2007 10:40:16 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <20070104181633.GC85755@hut.isi.edu> References: <459B1B09.40301@isi.edu> <459B4834.1050304@isi.edu> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <20070104162604.GA85755@hut.isi.edu> <459D3209.5090602@isi.edu> <20070104181633.GC85755@hut.isi.edu> Message-ID: <459D4A10.30200@isi.edu> Ted Faber wrote: > On Thu, Jan 04, 2007 at 08:57:45AM -0800, Joe Touch wrote: >> RFC1122 also states: >> >> * "SHOULD" >> >> This word or the adjective "RECOMMENDED" means that there >> may exist valid reasons in particular circumstances to >> ignore this item, but the full implications should be >> understood and the case carefully weighed before choosing >> a different course. ... > FWIW, I don't think SHOULDs should be thrown aside lightly, either. But > they're spots where the IETF consensus admits that designers and > implementors can make a different decision without catastrophic > interoperability problems. That's not what's implied above, IMO, e.g., by using the terms "full" and "carefully". Let's consider ma few of the SHOULDs in 1122 and consider whether we can negate them without catastrophe: - ARP would discard the first packet sent to each unresolved IP address (Nagle saw this problem in 1986: http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8604.mm.www/0126.html) - ICMPs redirects could be used for arbitrary off-path diversion (3.2.2.2) - packets could be forwarded to a gateway indefinitely in the absence of positive information it is available > For my money "bug" is much more derisive than even "wrong design" > because it implies (to me) a level of obliviousness that doesn't seem > present here. Bugs are accidents; this seems like a conscious choice. Bugs can be conscious choices too; they are just incorrect ones. > I understand it's a choice you disagree with, but IMHO it's a choice > that violates no RFC. If 'violates' means obeys only MUSTs, then we agree. If 'violates' means obeys all MUSTs and negates SHOULDs only in particular circumstances, then we disagree. > I think you're much better off debating the content of the design > decision than wether it violates some unenforcable boundary. I've already pointed out that it is likely to be unfair w.r.t. TCPs that ACK every second packet all the time (excepting timeouts). Others seem intent on finding ways to make their preferred OS behave better so long as it's within the 'letter of the RFCs'; it is in that spirit that we need to be clear on the conditions where SHOULDs are OK to skip. Joe -- ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070104/04461b0b/signature-0001.bin From ian.mcdonald at jandi.co.nz Thu Jan 4 11:25:18 2007 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Fri, 5 Jan 2007 08:25:18 +1300 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <459D188D.8060204@isi.edu> References: <2C63D9E0-9738-44A9-8A7F-C59D36276EF4@cisco.com> <20070103214811.GA27322@grc.nasa.gov> <459C2960.7030407@isi.edu> <20070103225935.GA11407@hut.isi.edu> <459C416B.7040702@isi.edu> <200701040027.AAA13758@cisco.com> <459C4DD3.3010106@isi.edu> <0B0A20D0B3ECD742AA2514C8DDA3B0650A3568@VGAEXCH01.hq.corp.viasat.com> <5640c7e00701032354l1ba3feccn8bdda21e9df37cd4@mail.gmail.com> <459D188D.8060204@isi.edu> Message-ID: <5640c7e00701041125t594c62a3xd4a0f01aac60146d@mail.gmail.com> On 1/5/07, Joe Touch wrote: > I'm sorry for the way I said things. I wasn't trying to start a mini-flame war but I have a habit of saying things in a way that causes misunderstanding at times. > > Ian McDonald wrote: > >> One would like to think that the last category should require some > >> care and > >> a rigorous process. Is this process not documented or well understood? > >> Surely, it cannot be - implement, deploy, publish paper and write RFC :). > >> What role should the IETF play in this process? Advisory only? > >> > > You'll find that Linux is probably the most RFC compliant > > implementation of TCP. > > Should we include the time when Linux defaulted T/TCP to "on" in that? > Or the default-ON of ABC? I.e., there are certainly points when versions > of Linux were clearly not RFC-compliant in more significant ways; which > version are you referring to? > What I was meaning is that Linux at present seems to be attracting people to check code against RFCs and implement experimental RFCs. This is probably because Linux is "fashionable" at the moment. I can certainly add to the list of problems as well - e.g. broken BIC the default, DCCP implementation is broken against RFCs. > And *WE* won't find that. If you want to look for evidence of that fact, > then please do. But unfounded assertions do not make it so, nor does > throwing the gauntlet at the rest of the world saying, "if you think > this is wrong, PROVE it". > > > However Linux isn't perfect and the developers > > do as they want. > > That's clearly true. The good news is that Linux ends up with some of > the earliest versions of new protocols. The bad news is that Linux > sometimes enables things as default that were never intended as such. > I think the development community for Linux is significantly different in make up to how the BSD community was. This has its positives as well as some negatives. Linux developers are very much in the mold of "lets try this out and see what happens". > > I think the bigger issue is that there are academics in one corner and > > implementors in another and usually they are not the same people and > > often don't even talk to each other. > > If I'm the academic in this discussion, note that I have a number of > patches that fixed bugs in FreeBSD. Just because I don't work on Linux > doesn't render me an academic. > > However, you're right - we're not all in the same corner. I'm in the > IETF corner, as are developers from other OS's, and right now it seems > like you're representing the Linux community in their corner demanding > that we all come over there for a chat (see below). > I'm not saying you need to chat. I'm saying notify bugs to the relevant place (see also below) > > Linux is a meritocracy so if > > people from this list were to go over to the netdev mailing list and > > make a reasonable argument then it will get listened to. > > That's the disconnect here. *THE* place for this sort of discussion is > the IETF, which this list is a peripheral (IRTF) party to. Perhaps the > discussion should occur on TSVWG, or even TCPM. But expecting us to take > this to the Linux community is a disconnect on how standards bodies work. > But surely if you say Linux is broken and then you don't inform the relevant developers then how will it get fixed? Its nice to moan about a broken TCP implementation but if you talk about th