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
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.
