Editor's note: These minutes have not been edited. I am sending 4 sets of slides in the next 4 mails Los Angeles IETF Proceedings Transport Service Area TCPLW Working Group Minutes of the TCP Large Windows Working Group (TCPLW) Reported by: Dave Borman BSDI and Allyn Romanow, Sun Microsystems Summary Agenda -- Thursday 7 March Session: - Agenda - Overview of Draft-ietf-tcplw-sack-00.txt, Allyn Romanow, Sun - Discussion, questions, issues, vote? - Implementation Discussion + Sender behavior, Sally Floyd, LBL + Net BSD implementation, Jamshid Mahdavi, PSC + BSDI implementation, Hari Balakrishnan, UC Berkeley ** Overview of the SACK draft, Allyn Romanow http://playground.sun.com/pub/allyn/sack_slides_ietf_mar96.ps Why SACK? Simulations of Reno with and without SACK, when more than 2 drops within TCP window, show that SACKS allow quick recovery from drops. Without SACK, the third drop causes TCP timeout and slow-start. For "kind" values, the values in RFC 1072 will be used. There are no known implementations based on RFC 1072, so the redefinition of the SACK option is not a problem. Jon Postel has already said that if there are are no implementations based on RFC 1072, then it is okay to re-use the option number, as long as there is a document forthcoming which defines the new definition. SACK is - Advisory - 3 SACKS can be fit into TCP option field if timestamp option is used 8*n+2 bytes, 40B available, 10B for timestamps Receiver behavior - Send SACKs when ack and have non-contiguous data - First SACK must be the most recently arrived non-contiguous block Issues - Congestion Control - Must follow accepted cc algorithms - Should not be dictated by the SACK RFC, to allow for new research, and for following "current practices" - New cc research is being stimulated by SACK - Efficiency - Unlikely to lose SACK for a segment, since each segment can be included in SACK minimum of 3 times - The frequency of unnecessary retransmissions occurring is less than that of other TCPS - No negative effects on network - TCPs running non-SACK version will not be at a particular disadvantage - See floyd, "Issues of TCP with SACK", ftp://ftp.ee.lbl.gov/papers/issues_sa.ps.Z - Implementations - 4 are being worked on Mahdavi (PSC-BSD), Hari R. (UCB-BSD), Ya Xu (USC-BSD), Romanow (Sun-Solaris) **Discussion, questions, issues, vote Vote - there were no objections to publishing internet draft as a proposed standard ------------------------------------------------------------------------------ **Sender behavior, Sally Floyd ftp://ftp.ee.lbl.gov/talks/sacks.ps Sally Floyd gave a presentation showing the behavior of the sender used in LBL's NS simulator, which is publicly available. SACK has been implemented and studied on a similar simulator for several years. Congestion control algorithms in de facto standard TCP must be followed - accomodates out-of order delivery, congestion window, time-outs On entering Fast Recovery - Retransmit one packet - Cut the congestion window in half ("cwnd") - Estimate the number of packets in the pipe ("_pipe") Behavior in Fast Recovery - When to send data and how much to send are two separable issues _ Send whenever the number of packets in the pipe is less than the congestion window - What to send: Fill "holes", one packet at a time, in sequence number order. If there are not holes, then send new packets. - If a retransmitted packet is itself dropped, then slow-start. Behavior in Fast Recovery: sender receiving ack packets, 3 possibilities - Duplicate ACKs: Decrement "_pipe", call "send" - An ACK that ends Fast Recovery: Call "send" - An ACK that does not end Fast Recovery: Decrement "_pipe" by two packets - once for the retransmitted packet, and once for the original packet (now presumed to have been dropped). Call "send". Behavior in Fast Recovery: details of sending data packets - Send if the number of packets in the pipe is less than the congestion window - Use the SACK scoreboard to determine which packet to send _ Increment "_pipe" Details: "maxburst" new parameter that tells how many packets can be sent for a single incoming ack. Set at 4 in the simulator. Implementors probably won't use "maxburst", or if so, only after consideration. "overhead" a parameter used to inject randomness in the simulator only Ns simulator available from: http://www-nrg.ee.lbl.gov/ns Papers are at: http://www-nrg.ee.lbl.gov ----------------------------------------------------------- **Sack Implementation at PSC, Jamshid Mahdavi http://www.psc.edu/~mahdavi/sack_impl.html - Activities in several areas + Reference implementation for NetBSD 1.1 + Research implementations for NetBSD 1.1 and Digital Unix 3.2c - Changes for SACK are relatively straightforward + tcp.h + tcp_var.h + tcp_input.c + tcp_output.c - SACK_PERMITTED option is trivial - SACK option has 3 main parts + SACK Generation + SACK scoreboard + Sender retransmission and congestion control - SACK research implementations + PSC exploring more precise cc techniques via the FACK algorithm + At USC, work on SACK with Vegas CAM algorithm ----------------------------------------------------------- **Sack Implementation at UCB, Hari Balakrishnan http://www.cs.berkeley.edu/~hari/papers/tcpsack.ps - Daedalus Group, U. C. Berkeley - Interested in SACK because working on wireless technology, limited bandwidth, similar needs to satellite links - Implementation working in the BSD kernel for a few days - No performance measurement yet - Interested in SACK header compression - Receiver behavior + Maintain list of all holes in sorted order + When new ack arrivers, update list of holes - Open issues: + Precise sender behavior and cc mechanisms evaluated in the real world + Applicability in networks with wireless and satellite links + For low bandwidth reverse channels: SACK header compression would be useful. Discussion - with satellite links, loss is not from congestion so TCP congestion control behavior causes poor performance. Need to use different algorithms.