2.8.21 TCP Maintenance and Minor Extensions (tcpm)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-11-02

Chair(s):

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: http://www.ietf.org/mail-archive/web/tcpm/index.html

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)

Internet-Drafts:

  • draft-ietf-tcpm-tcp-dcr-01.txt
  • draft-ietf-tcpm-tcpsecure-01.txt
  • draft-ietf-tcpm-frto-01.txt
  • draft-ietf-tcpm-tcp-roadmap-00.txt

    No Request For Comments

    Current Meeting Report

    TCPM Notes

    Taken by Aaron Falk
    Chaired by Ted Faber

    Agenda
    - TCP Roadmap
    - Soft Errors
    - User Timeout
    - PAWS vs. Segment Reordering
    - Timestamp defense vs. off-path spoofing

    Status

    - FRTO Draft in AD review

    - TCP RST summary document, now a wg document, waiting for revision, expect completion before next IETF

    - TCP secure: minor revisions pending, expecting new revision in two weeks. Not many substantive comments. Expecting WGLC soon.

    - Reordering Robustness. Item on charter was DCR and blanton-allman draft. Allman, Blanton will combine collaborate with DCR. Draft renamed to NCR (non-congestion response). Getting fleshed out, some under-specified details. Working to get doc to look like a real specification.

    - revising 2581. Getting bug fixes and other small fixes. Draft expected in a couple weeks. Send input directly to Allman, Paxson, Blanton.

    TCP Roadmap, Wes Eddy

    - Easy to RFC search for 'TCP' but returns many, many hits and understanding relationships is difficult. Goal: help newcomers by categorizing and providing brief commentary.

    - History. Started on e2e-interest mailing list. Originally draft-duke-tcp-roadmap-00.

    - Soliciting feedback. Current version mostly complete listing of TCP-related RFCs. Still some questions about including peripheral; documents. The brief descriptions are tweakable.

    - Goal. Have a good amount of feedback to apply an increment version. People seem mostly happy (?).

    - Open questions (looking for comments):

    - overall structure: Should we reorganize/reclassify? Propose a couple formats on the list and take vote?

    - Take out notions of what's in "modern OSes"?

    - RFC citations: retain or nuke?

    Braden: (erstwhile author of this document). I oppose removing references. At least the names should be there. (why are they there? they take up three pages) I have some other changes. Not enough said about IPv6 TCP. I don't know how the IPv6 describes how the pseudoheader has changed. need to be a more careful definitions of the updates and obsoletes. Looking at the text I found several places where there should be some updated/obsoletes but aren't. Then there's the MIB thicket... In historical documents, there are several that should be promoted (e.g., RFC1718 "silly windows" should be in implementation issues). The Dave Clark Five should be included as they are quite useful. The problems those doc describe still exist. Finally, missing reference to Reno in congestion control section.

    Jon: need to be mindful of replicating information on the RFC Editor pages in obsolete. This is a moving target, e.g., for MIBs.

    Braden: don't think this is a big issue but I see your point about duplication.

    Anantha Ramaiah, Cisco: is there a way to list what RFCs a stack implements

    Ted: this makes me uncomfortable

    Braden: that question reminds me of a short section on conformance in the doc. wonder whether we can get away with saying so much or little.

    Ted: agree. we should be cautious about laying too much law here

    Braden: yes. but perhaps we should be giving a little more advice.


    Pekka presenting for Fernando Gont: Soft Errors and TCP

    - Proposed fix in document could lead TCP to abort connections that would be aborted unnecessarily. Practice indicates this seldom occurs. Except in rare circumstances.

    - Other comment: why not parallel connection attempts? Either try every IP address available, in parallel or wait some time before trying each address. First approach is hard to distinguish a valid connection request from a DoS attack. Second will likely lead to long delays.

    - Next steps. Take as WG document?

    Ted: comments? (none) There were some impassioned statements on this in SD IETF. How many people read the draft? (3-4) How many remember the draft in SD? (none)

    Joe: one issue from before, not addressed today, is changing treating a soft error as a hard error as an optimization which should be done as an application optimization. Haven't heard a good argument to address this. You're trying to fix things by using transport layer signals which the application should be dealing with.

    Pekka: I'd like that every application doesn't need to know how to deal with this kind of error.

    Joe: but what about application which don't want this behavior?

    Pekka: this proposal only applies to all of the end system.

    Joe: this seems like a big problem. it should not do it unless a user asks for it. (default should be off).

    Ted: what about a SOCKOPT?

    Joe: I have no problem as long as the default is OFF. The catch-22 is that, if the app is going to set the SOCKOPT, the app can do the right thing anyways.

    Ted: it's easier to set a SOCKOPT than write a library

    Casner: what is the right application behavior? This mechanism is just more convenient for applications.

    Pekka: trying to fix this in one place instead of two million.

    Allman: can't fix this without involving the app

    Joe: I agree

    Ted: we don't have enough folks to make a decision now, take it to the list

    Lars Eggert, NEC - TCP User Timeout Overview

    - Overview. Want to use per-connection user timeouts negotiated with a TCP option. Longer timeouts = tolerate longer periods of disconnection. Draft describes only the TCP mod, not the policy that you use for picking appropriate user timeouts.

    - next steps: want draft to be a working group item.

    Ted: how many read draft? (few)

    Of those who've read, it how many like it? (all who've read)

    Will take this to list but it looks like there is interest.

    Comments on Experimental vs. Standards? (none)

    A Modification To Make Paws Robust To Segment Reordering, Noritoshi Demizu, NICT

    - Problems: PAWS may discard reordered legitimate segments when retransmission happens. (gives example)

    - Possible solutions.
    - 1. receiver-side modification
    - 2. sender-side modification
    - 3. redo PAWS

    - Current proposal. replacing PAWS. record the following tuple for every 2^30 bytes. (Ed: I don't understand this and he's going too fast.)

    Ted: anyone read this? (1) This is fairly technical draft. See if it technically feasible. Send feedback to list.

    Lars: is this implemented? (no)

    Ted: even doing this in ns would help.

    KC Poon - Use of TCP timestamp option to defend against blind spoofing attack

    - Resolved IPR issue by removing the mechanism which touched IPR. Valid range of TSecr is limited. Issue: current proposal does not protect against wrapped around ACK, will be fixed in next revision. (There are four ways to interpret RFC1323, this causes issues.)

    Touch: spoke about this at BTNS BoF. I feel it is inappropriate to deal with security issues by changing a transport protocol. Deal with Spoofing by fixing spoofing, not by changing timestamps.

    Ted: are you interested in timestamp misrepresentation draft. Joe: yes.

    Tim Shepard: I didn't like this ideas because dialup users may run into problems when two users share one dial up port. This makes it impossible to reset a connection if a system doesn't support resets.

    KC: suggest allowing application to chose whether to use the TCPsecure mechanism so it won't be everywhere.

    Tim: yes but this doesn't address my problem.

    KC: this also applies to anonsec

    Ted: how many have read: (5-10) of those, should this be a wg item (1); Read and don't think should be a wg item (2) "lukewarm, if any support, for a making this a wg item"

    Braden: I've been involved in this and think we should require simulations before making any changes.

    CLOSE.

    Slides

    Chairs Stuff
    TCP Roadmap
    TCP's Reaction To Soft Errors
    TCP User Timeout Option
    Use of TCP timestamp option to defend against blind spoofing attack
    A Modification to Make PAWS Robust to Segment Reordering