Subject: draft minutes for Chicago meeting

From: Vern Paxson <[email-masked]>
Date: Thu, 08 Oct 1998 15:39:28 PDT

Sorry these are so late ...  Please send us comments over the next
few days and then we'll finalize them.

		Vern

TCPIMPL minutes
42nd IETF, Chicago 
August 28, 1998

Reported by Evi Nemeth, with editing by the chairs & Sally Floyd.

Agenda:
	1.  Agenda bashing
	2.  Scott Bradner, intellectual property rights
	3.  Status
	4.  Known problems I-D
	5.  Security problems
	6.  RFC 2001 revision (congestion control)
	7.  WG closing after Orlando

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

1.  Agenda bashing:

No changes to the agenda.

2.  IPR (intellectual property rights) issues:

Scott Bradner reminded the group that if you know of intellectual
property issues in your company on a topic and don't say so, then
you cannot participate in the discussion and decisions regarding
that topic.  This is outlined in RFC 2028.

3.  Status

The testing tools document is done, RFC 2398.  The larger initial
window documents have been approved by IESG, and the 3 drafts will
soon become RFCs.  Regarding the restart of idle connections, see
draft-ietf-tcpimpl-restart, which Joe Touch reports will soon be
revised for publication.

4.  Known problems

7 new ones have been documented since the LA meeting.  Bill Fenner
described a new bug: if during a bi-directional transfer you are
sending and so is the other end, but you're not reading the incoming
data very fast, you can end up deadlocked with a full buffer.  For
example, a multithreaded client-server where one thread is sending a
lot, another is receiving a lot, but using one tcp connection.  The
fix is to change an unsigned to an int and recognize -1 as a valid
value.  Bill will explain it better and submit it.

There are 3 others which are less serious and also not yet
addressed.  The document will be forwarded to the IESG without
outlining these bugs.

5.  Security problems

There is a list of known problems:
	Predictable initial sequence number
	SYN flooding
	Land attack
Phil Karn noted that the latter two are really denial of service
attacks, and questioned the title of the section.

6.  RFC 2001 revision

High-level sketch of the revisions:
	- removed ambiguities
	- fixes for fast retransmit and fast recovery
	- added discussion of SACK
	- added larger initial window pointer

The discussion of the 2001 revision was a little chaotic at this
point and went back and forth between several topics.  The comments
about each topic have been grouped together for the minutes, and
therefore the comments are somewhat out-of-order.

Sally Floyd described two separate modifications to the Fast Retransmit
and Fast Recovery algorithms in RFC 2001.  The first modification is
the NewReno algorithm, introduced in Janey Hoe's SIGCOMM 96 paper,
which improves TCP's response to a "partial ack" received during Fast
Recovery, acknowledging some but not all of the packets sent before
Fast Recovery was initiated.  The preferred TCP algorithms would be
those of Sack TCP.  However, when the SACK option is not available, the
NewReno algorithm was described as a small but important change to make
to Reno TCP, avoiding Reno TCP's well-documented problems with
retransmit timeouts when multiple packets are dropped from a window of
data.

The second modification described was the bugfix algorithm for avoiding
unnecessary multiple fast retransmits.  This problem occurs in Reno
when, after a retransmit timeout, packets are retransmitted that have
already been received at the receiver.  When the TCP sender receives
three duplicate ACKs acknowledging three retransmitted packets, the
sender can incorrectly interpret this as a new instance of congestion.
Simulations showed that the NewReno algorighm and the bugfix for
avoiding-multiple-fast-retransmits are orthogonal - it is possible to
implement one and not the other.  However, while it is possible to
create scenarios with Reno or NewReno TCP where the bugfix for
avoiding-multiple-fast-retransmits would be helpful, it is not 
possible to create the pathological scenarios that can occur with Tahoe
TCP (e.g., TCP with Fast Retransmit but without Fast Recovery).

Sally's slides can be found at:
"ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps" (postscript), and
"ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.pdf" (PDF).

The chairs think that NewReno is a good thing; folks should implement it
(solaris 2.6 might already) and put out an experimental RFC or include it
(all or part) in 2001.

The decision was made to take this discussion to the mailing list and do an
experimental RFC with NewReno, rather than include it in the bugs list 
in RFC 2001.

There was then discussion of whether to include Sally's Reno
modification for avoiding-multiple-fast-retransmits in the RFC 2001
revision - how much experience with it do we need to include it?

Vern suggested that an experimental document with Sally's modification
could come out at the same time, and be referenced by 2001.

Kacheong Poon (Sun) confirmed that some implementations of NewReno can
behave like stop and go during retransmission (like in Janey Hoe's
paper).  This occurs when multiple packets are dropped from a window of
data, and NewReno TCP recovers by retransmitting at most one dropped
packet per roundtrip time.

Sally said it is possible to implement NewReno with "stop and go"
behavior, but that in an alternate implementation, included as an
option in the NS simulator, the retransmit timer is reset on only the
first retransmission.  In this case, instead of slowly recovering by
retransmitting at most one dropped packet per roundtrip time,
eventually the retransmit timer times out and the sender slow-starts.
The first-order fix for problems with multiple packets dropped from a
window of data is to use Sack, but when Sack is not available, NewReno
with this implementation should not perform worse than Reno.

Sally and Kacheong Poon agreed to confer on different possible
implementations of NewReno.

Phil Karn asked if we want to make TCP more aggressive in the face of
multiple packets dropped.  Sally answered: multiple packets dropped in a
window of data is one instance of congestion.  So cut the window in half,
do one retransmit; if retransmitted packets get lost, then it's more serious
and do slow start.

The RFC 2001 discussion continued with a discussion of ACKing every
second full sized segment being a MUST and not a SHOULD.  A wording
tweak is needed: that ACKing is *at least* every second full-sized
packet, since some systems ACK every segment, and that's allowed.

<There was a comment here about satellite environments which the
 note-taker didn't get recorded - anyone recall it?>

Another issue arose concerning ACK every 2nd full sized segment --
there's no way for the receiver to really know if the segments
arriving are full-sized.  Resolution: loosen the language but word
it so that today's TCPs are ok.

A question regarding definition of 3 duplicate ACKs - must they be
consecutive?  Answer: yes, they need to be consecutive, but it's
rare that they're not, so should not cause an implementation to be
labeled non-conformant.

7.  WG closing after Orlando

2001 is almost done if NewReno is not included.  The plan is to
close the working group after the next meeting (in Orlando).
However, in discussion after adjournment, the issue was raised of
documenting PMTU discovery issues, which may merit keeping the WG
active for one more meeting.