CURRENT MEETING REPORT

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.