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.