2.7.16 TCP Maintenance and Minor Extensions (tcpm)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-12

Ted Faber <faber@isi.edu>
Mark Allman <mallman@icir.org>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Mailing Lists:
General Discussion: tcpm@ietf.org
To Subscribe: tcpm-request@ietf.org
In Body: subscribe email_address
Archive: ftp://ftp.ietf.org/ietf-mail-archive/tcpm/
Description of Working Group:
TCP is currently the Internet's predominant transport protocol. To maintain TCP's utility the IETF has regularly updated both the protocol itself and the congestion control algorithms implemented by the protocol that are crucial for the stability of the Internet. These changes reflect our evolving understanding of transport protocols, congestion control and new needs presented by an ever-changing network. The TCPM WG will provide a venue within the IETF to work on these issues. The WG will serve several purposes:

* The WG will mostly focus on maintenance issues (e.g., bug fixes) and modest changes to the protocol and algorithms that maintain TCP's utility. * The WG will be a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts).

* The WG will write a document that outlines "what is TCP". This document will be a roadmap of sorts to the various TCP specifications in the RFC series.

TCPM will take a subset of the work which has been conducted in the Transport Area WG over the past several years. Specifically, some of the WG's initial work will be moved from the Transport Area WG (tsvwg).

TCPM is expected to be the working group within the IETF to handle TCP changes. Proposals for additional TCP work items should be brought up within the working group. While fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) should be brought through TCPM, it is expected that such large changes will ultimately be handled by the Transport Area WG (tsvwg). All additional work items for TCPM will, naturally, require the approval of the Transport Services Area Area Directors and the IESG.

TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP and (in some cases) DCCP). In addition, the IETF has recently worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents in the future will determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles.

Specific Goals:

* A revision of RFC 1323 based on experience and evaluation. Depending on the conclusions of the WG and the nature of the updates this document could be a candidate for Draft Standard. A current Internet-Draft has been submitted to start this process (draft-jacobson-tsvwg-1323bis-00.txt).

* A "roadmap" for TCP. The protocol and associated algorithms have become spread out throughout the RFC series. This WG will issue a document that catalogs all the various TCP specifications and informational documents in the RFC series in a single location. An initial discussion (and strawman start at a list of such RFCs) has been conducted on the end2end interest list.

* While there is no consensus on exactly how to deal with spurious retransmits (caused by bad RTO estimates or packet reordering) there are several proposals that will be fleshed out in this WG and likely issued as experimental documents. The current set of proposals is:

draft-sarolahti-tsvwg-tcp-frto-03.txt draft-blanton-tcp-reordering-00.txt draft-bhandarkar-tcp-dcr-00.txt

Goals and Milestones:
Mar 04  Submit FRTO draft to IESG for publication as an Experimental RFC
Mar 04  Submit Reordering Mitigation draft to IESG for publication as an Experimental RFC
May 04  Submit DCR draft to IESG for publication as an Experimental RFC
May 04  Submit TCP Roadmap document to IESG for publication as a Best Current Practices RFC
May 04  Develop (providing editors are available) milestones for advancement to Draft Standard of identified important TCP specs (e.g. RFC 2018, 2581, 2988...)
Jun 04  Submit a revision of RFC 1323 to the IESG for publication as a Proposed or Draft Standard (depending on the nature of the changes to the document)
No Current Internet-Drafts
No Request For Comments

Current Meeting Report

TCPM Working Group

Draft Minutes as of 8 Mar 2004

The meeting was chaired by Ted Faber.
These minutes were edited by Ted Faber from notes by Matt Zekauskas.

1. Overview of the charter and milestones
   --Ted Faber

Ted addressed some slides going over the charter and group goals.
(See slides.)

Why form a new group?
  * This group was created to focus efforts on TCP tweaks.  Take 
revisions and documents that have been "floating around", and push them 

  * It will also serve as a forum to attract new TCP work where TCP 
expertise can be focused to evaluate the work carefully and move 

Milestone discussion:
FRTO draft (draft-ietf-tsvwg-tcp-frto-01.txt) 
	Discussed and moved fwd, see below.

Roadmap draft (draft-duke-tcp-roadmap-00.txt)
  adopt directly into WG

Ted's impressions:
  draft good in coverage, but needs annotations

  "stuff not used much" the draft calls these "Deprecated TCP 
Extensions".  Ted thinks the discussions of these should include more 
information about why the extensions were deprecated and the lessons one can 
take from them.  Of course editors and group will have the final word.

  Ted mentioned that there's a discussion on e2e about a TCP 
consolidation document.  Ted is not clear on the difference between what 
they're asking for and a roadmap, and Ted would rather see that energy in 
the roadmap.

  We're actively looking for editors and contributors.

DCR & reordering. (blanton-tcp-reordering-00.txt 

  Need to get with authors and gauge interest.  Ted suspects authors will 
need to drive.

1323 revamp: 
  Dave Borman presented, see below.

  Goal is depending on how big a revamp happens either push to Draft 
Standard, or "revalidate" at Proposed Standard.
End of Milestone discussion
Presentation of other documents that might be of interest to TCPM:

  From the slide:
	2018 update?  Merge with 2883 (DSACK)?

  Congestion Control 
	Update 2581  (back to PS?)
		merge 3390 (initial cwnd)
		merge 3042 (limited transmit)
		merge 2582 (Reno bugfix/NewReno)
		merge 3465 (App. Byte Count security)
	2861 to PS (cwnd validation)
	2988 to DS (RTO timer comp)
	3517 to PS? into 2018 update? (DSACK loss rec) 
	[NB: after the meeting Kevin Fall pointed out to me that Ted had 
mischaracterized RFC 3517, which is already a Proposed Standard, and 
probably doesn't need to move forward any time soon.]

  Again, these will be come work items based on group interest, though no 
one leapt up to take one on.

Closed with a "Drivers Wanted" plea.

Allison Mankin encouraged people to volunteer to take things on.  

Sally Floyd: "I wouldn't go so far as to say that I was interested, but I 
agree that it is necessary to do."  
 [Sally's Restatement: I am *willing* to do my share of the work, just not 
necessarily *excited* about having to do it.]

2. FRTO presentation 
   --Pasi Sarolahti.
   draft: draft-ietf-tsvwg-tcp-frto-01.txt

The draft has been around for a while.  Started in June 2002 as 
individual submission, to TSV last october.

detecting spurious RTOs.
  (where a lost or delayed ack causes an RTO time out)

  Send a little new data during retransmit and looks for immediate acks of 
that new data.

  Can be combined with SACK
List of editorial changes from last version
They have been working for a while... want to submit for pub as 

Ted called for comments:

Sally Floyd: I have not been paying attention to the discussion on the 
mailing list.  Has the discussion converged to consensus?  Are there 
outstanding technical points of contention? [Not verbatim]

Pasi: There has been no real discussion since June.  Comments have mostly 
editorial, not technical.  There have been some individual nits. nothing 
related to algorithm.  I believe that the draft is stable.

Ted says what we're going to do is make another pass for NITs, on tcpm, and 
then on ML go to WGLC.  Ted doesn't know whether to ask for a hum or some 
other consensus indication in a mixed meeting.

Allison Mankin:  I talked to Jon in the back, who's the responsible AD nits 
review is just nits, no humming to do.

Action is to do a nits pass and got to WGLC on the list.


3. RFC 1323 update 
   --David Borman

  Large windows & timestamps RFC that has been proposed for way too long. at 
last IETF, gave presentation... this is what's happened since.

Nothing has really changed... no new draft, no discussion. But we are now 
part of tcpm wg.  This is a good thing.

Outstanding issues...
RTO adjustments
  When using timestamps and calculating RTTs frequently, need to adjust 
weighting factor on estimates.  There seems to be general consensus on this 
Enabling timestamps/PAWS midstream
     Do most current TCP implementations properly handle unknown options 

     Originally, implementations crash when unknown options appear in the 
middle of a  tcp connection.

     We would have to think about reliability in that context - i.e. would 
allowing timestamp/PAWS renegotiation cause more crashed than improved 
PAWS & DF bit
  Without DF bit set, PAWS would protect 1st fragment not the rest. Only the 
16-bit IP ID would protect them.

  The pathological case is that the 1st frag arrives, another packet fills in 
hole. then perpetually all assembled incorrectly. 'TCP cksum should 

  Matt Mathis points out that this is a general ugly problem with IP 
reassembly and points out similar problems with UDP transport.

  Vern Paxson mentions a related problem: every 65000 of those 
collisions will be missed by the TCP checksum.  That's even worse!

  Matt Mathis points out that the real pathological condition is the one 
that Dave mentioned where each contains the data Vern alluded to - every 
packet is misassembled in such a way that the checksum misses the 

  He goes on to say that he's meaning to write RFC "Fragmentation 
Considered Really Really Really Harmful" because pathological case 

  Someone says that because of probs with MTU discovery, people 
ignoring DF bits -- really bad.

  Ted says that this is all good discussion and I'd like to see it get into 
the new document.

RTTM estimate from dup ack.
  discussed on ML (different mailing lists). If a connection is idle for 
long period of time, and 1st ack is lost, when get a dupack, it could have 
good information for RTT, but that means changing what's in document.  
Concern: even if get everything right and correctly id dupack 
(potential for random window update coming in) how interoperate with 
existing implementations?  (How do we know that the other side giving is 
good information in a dupack timestamp.  Even though the idea is good, you 
can't do anything with it.

  "not a real big problem out there" -- not clear who said this

  Dave points out that TCP doesn't define what dupack is.  all know one 
when see one, but...  we need a precise definition.

non-technical issues:
  Connections with other work:
    HSTCP and others depend on window scaling
    Eifel wants ts option
  Should the revision disucss SACK?
    Originally SACK was part of 1323.  Split originally because SACK 
needed baking)   He thinks SACK is further ahead for stds progress.

  We need to revisit the MUST/SHOULD language.

  what about last 10 yrs of experience?  include 

draft-jacobson-tsvwg-1323bis-00.txt will expire RSN

This has been discussed on e2e mailing list, but David will attempt to 
steer traffic to tcpm.

Ted ask Dave to please summarize to TCPM.

Dave and Ted talk about generating a numbered list of items, so that we can 
check items off as we go.

Jon Peterson says the IESG is making issue trackers available to WG 
  Check with Rob Austein... there is one on the psg.com site.

David is mainly looking for things to move along.  He has tried to bring up 
the topic of a revised document a couple of times, but it hasn't 
advanced in part because we do not having a precise way of saying when an 
issue is closed.

Sunay from sun microsystems made an appeal for interest in outboard 
protocol processing. [This has since surfaced on the ML and e2e.]


F-RTO Update
RFC 1323 update