draft TSVWG minutes

[Vern Paxson <[e-mail]>]

If you have comments, please send them soon!

		Vern


Transport Area Working Group
IETF 46 -- Washington DC
November 8, 1999
Chairs: Scott Bradner, Vern Paxson

Reported by: Mark Allman ([e-mail]) (with contributions
from Sally Floyd)


The meeting started with Scott Bradner outlining the charter of the WG.
The group is for various transport topics that come up periodically, but
are not large enough to convene a WG or a BOF, and don't already have a
natural home with an existing WG.  All new topics taken on by the transport
area WG must first be approved by the IESG.  The working group chairs will
be whoever are the transport area directors at the time.

Vern Paxson presented a proposal to redefine TCP's behavior with regards to
the precedence bits (draft-xiao-tcp-prec-00.txt).  RFC 793 states that if
the precedence bits used by the sender are different from the setting used
by the receiver a reset must be sent.  However, with diffserv it is quite
conceivable that the bits will be different.  The suggested fix is to make
TCP ignore the bits.  This is consistent with the intent of RFC 793.  That
is, that a reset should be sent when a packet arrives that clearly does not
belong to the given connection.  Another possible solution would be that
diffserv clouds must set all precedence bits to zero when a packet leaves
the cloud.  A question was raised as to whether the precedence bits are
used for anything.  While there was no direct answer available, a survey by
the diffserv WG had found that it's already existing practice to modify the
bits in transit.  Joe Touch noted that the network mangles these bits quite
a bit anyway and TCPs have been dealing with it, so this is not a
significant change from current practice.  Ran Atkinson pointed out that
DOD wanted to use the precedence bits a decade ago, and first thing they
had to do was modify the TCPs to have the proposed behavior.  A final
observation was that with this change we remove the possibility of
end-to-end type-of-service.  This Internet-Draft will be last-called in the
working group for publication as a proposed standard.

Next, Sally Floyd presented an extension to the TCP selective acknowledgment
(SACK) option (RFC 2018) (draft-floyd-sack-00.txt).  The proposal is for
the receiver to send a "DSACK" block indicating that duplicate data has
arrived.  No new option is needed.  And, a survey of TCP implementers
indicates that the new use for the SACK blocks will not cause any sort of
incompatibility issue with current SACK implementations.  The draft covers
only how to exchange the information about the arrival of duplicate
segments.  Using the information is left to further research.  There were
no objections to proceeding with this option as an experimental RFC.

Matt Mathis presented the rate-halving congestion control scheme
(draft-mathis-tcp-ratehalving-00.txt).  The general idea is that one
segment (new or retransmit) is sent for every second ACK that arrives,
thus halving the sending rate.  The idea can be used with reno-style or
SACK-style loss recovery, as well as with explicit congestion notification.
The algorithm is consistent with those outlined in RFC 2581.  There were
no objections to proceeding with this option as an experimental RFC.

Mark Handley presented a proposal called Congestion Window Validation (CWV)
(draft-handley-tcp-cwv-00.txt).  The idea behind CWV is to ensure that
TCP's congestion window is a true reflection of the probed state of the
network path.  Handley outlined three causes for cwnd to become invalid.
First, some TCP's increase cwnd when the entire window is not being
utilized, providing a cwnd value that is larger than the connection has
actually validated over the network path.  Second, when senders stop
sending data and then start after some amount of time the value of cwnd may
no longer be appropriate.  The final case discussed was when a connection
moves from being cwnd-limited to application limited.  The suggested fixes
are: (1) Don't increase cwnd if the entire window is not being used.
(2) If we become application limited, decrease cwnd appropriately.  And,
(3) every RTO the connection is idle, decrease cwnd by half.  In addition
to changing cwnd, ssthresh is set to keep a history of the cwnd and allow
connections to quickly ramp back up after an idle or application limited
period.  Joe Touch suggested that the cwnd changes should always be made in
increments of an even number of packets rather than blindly picking some
number.  A suggestion was made that we could pick decrease values that are
based on the RTT introducing a time constant.  Another point was raised
that the decay doesn't relate to the amount of traffic inserted.  Handley
noted that CWV is self-balancing.  Sally Floyd noted that this proposal is
not perfect, however it is better than the current situation.  Some
controversy remains over the constants used to decay congestion control
information over time, which will require further discussion on the
mailing list.

Greg Minshall started a digression by asking for a clarification of what an
"experimental" RFC means.  Scott Bradner noted that experimental indicates
that we believe the direction outlined in a document is desirable, however
we don't yet have enough evidence to make the document a proposed standard.
Sally Floyd noted that sometimes such RFCs can be an addendum to PS RFCs
(such as RFC 2582 is a companion to RFC 2581).  Scott Bradner noted that we
believe experimental RFCs are safe to play with in the big-I Internet.
Matt Mathis noted that experimental RFCs are a good way to get feedback and
answer the question "is this a good idea?".

Finally, Mark Allman presented a draft on how to manage TCP's retransmission
timeout (draft-paxson-tcp-rto-00.txt).  The goal is to document TCP timer
principles as they are currently used, as such a document does not exist in
the RFC series.  The intent is to publish the document as a Proposed Standard.
The draft does not discuss congestion control aspects of RTO timers at all
(see RFC 2581).  After Allman outlined the draft, Vern Paxson raised the
issue of whether the minimum RTO of 1 second included in the draft was too
conservative.  Van Jacobson noted that while 1 second is conservative it is
not wildly conservative.  Vern noted that there is room to explore less
conservative alternatives, however this document is attempting to outline
the state of the world today.  Future documents may change the behavior.  A
question was raised as to whether the first RTT sample must come from the
SYN exchange, or is using the first RTT of data transfer OK.  Vern noted
that anything more conservative than outlined in the draft is all right.