Transport Area Working Group IETF 46 -- Washington DC November 8, 1999 Chairs: Scott Bradner, Vern Paxson Reported by: Mark Allman (mallman@grc.nasa.gov) (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.