Re: TCP vs UDP (retransmission algorithms) Author: Van Jacobson Date: 1998/07/08 Forum: comp.protocols.tcp-ip In article <6n8in8$t0r$1@gaia.axis.se>, "Björn Wesén" writes: > The fast retransmit algorithm covers for the case of moderate packet loss; > one packet lost per window. Jacobson has proposed, several times (RFC 1072, > RFC1323 etc), actual TCP options to implement selective retransmission, but > they have been too complex to implement in practise. I quote from RFC 2018 > as of october 1996 (SACK = selective ACK): > > "RFC 1072 [VJ88] describes one possible implementation of SACK options > for TCP. Unfortunately, it has never been deployed in the Internet, > as there was disagreement about how SACK options should be used in > conjunction with the TCP window shift option (initially described > RFC 1072 and revised in [Jacobson92])." > > Then they go on suggesting some improvements on this, but I doubt that this > algorithm (of 1996) is implemented in practice anywhere. Someone might fill > in something here - i crossposted to comp.protocols.tcp-ip. Actually the RFC-2018 tcp selective acknowledgement is fairly widely available. E.g., it's a standard part Win98. A good summary of the current state of things is: http://www.psc.edu/networking/all_sack.html In my recollection of events (which is colored by the frustration I felt at the time) the difficulty in turning RFC-1072 into an Internet standard (which was necessary to get wide vendor adoption) had nothing to do with implementation complexity (the test implementation I had at the time added ~40 lines to the BSD kernel). What I saw happening was that a university professor decided that the addition of three new things to TCP (window scaling, timestamps, sack) was a change large enough to create doubt about the overall viability of TCP. With a relatively small effort on the part of his group to promote & nurture that doubt, he'd might be able suck a lot of money out of DARPA & NSF to increase funding for his existing research into TCP alternatives. [This strategy was eventually quite successful for him.] So he & his minions mounted a *very* active campaign in the IETF TCP-LW working group to derail the adoption of 1072. We had a weath of theoretical, simulation & operational data supporting the window scale & timestamp options so they didn't have much luck on that attack but we weren't as well prepared on sack - there was 2 decades of ARQ research demontrating the effectiveness of selective acknowledgment but they claimed it didn't apply to TCP & at the time we didn't have the simulator technology to show they were just blowing smoke. After 2 years of deadlock in tcp-lw, we decided that some progress was better than none so we removed the SACK stuff from 1072 & created a new RFC with just the window scale & timestamp options (RFC-1323). It became a standard. We also started putting the pieces in place to get the simulation & operational data needed to push SACK forward. Much of the work on test implementations was done a Pittsburg Supercompter Center by Matt Mathis & Jamshid Mahdavi and they, in the course of their testing, made several improvements to the sack algorithm in RFC-1072 and a variation on their improved version eventually became an Internet standard with RFC-2018. So the final result of the process was a better sack than the one we would have had if greed hadn't derailed 1072 but I occasionally wonder if it was worth the 8 year wait & associated confusion & mis-information ("sack is too complicated", etc.). - Van