Last Modified: 2004-02-12
* 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
| 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) |
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 forward. * 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 forward. -- 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 draft-bhandarkar-tcp-dcr-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: SACK 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. [Thanks] 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 Experimental. 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 issue. -- Enabling timestamps/PAWS midstream Do most current TCP implementations properly handle unknown options mid-stream? 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 performance? -- 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 notice'. 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 corruption. He goes on to say that he's meaning to write RFC "Fragmentation Considered Really Really Really Harmful" because pathological case horrible. 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 clarifications... 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 chairs. 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.] |