2.7.16 TCP Maintenance and Minor Extensions (tcpm)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-17


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

    * 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:


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)


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

    No Request For Comments

    Current Meeting Report

    TCPM notes - Thursday, 10 March 2005 at 1300-1500

    Thanks to Steve Casner for the excellent notes.

    These notes do not include information from the slides, which are in the proceedings.

    - ICMP Soft error draft to informational - strong support
    - Malformed tcpsecure question - inconclusive due to pilot error
    - tcpsecure support "do you think this should ramin a wg item" strong support


    Status - Allman

    RFC2581 revision - Allman

    Revision not done before meeting, but nearly ready.
    Draft expected next week.

    Soft Errors - Pekka Savola

    Joe Touch: is it feasible to go with socket option document, because
    those are not standards?
    Ted Faber - we could document the api, not a socket option.
    Pekka Savola - prefer first option (just informational rfc) instead.
    Matt Mathis - Will informational rfc mention that this could be done with a socket option? Explain the technical issues while avoiding political issues.
    Pekka Savola - could do that.
    Mark Allman - Rephrase: follow option one [document the behavior of treating ICMP soft errors as hard during set up], explaining how it violates 1122 - is this reasonable as a working group item?
    Joe Touch - yes, should be a wg doc - similar to tcp errors document. Maybe we should just glue this onto that doc?
    Mark Holinger - Should we just propose changing the behavior?
    Tim Shepherd - Do we need to say anything about OS behavior (vs protocols)?
    Ted Faber - Issue is this document changes what 1122 says.
    Tim Shepard - does this affect interoperability?
    Joe Touch - TCP has behaviors both ways, up and down, and 1122 covers both.
    Ted Faber - To tell someone to do something different than 1122 requires a standards doc.

    Hum was clearly in favor of making this a wg item for informational.

    ICMP attacks against TCP -- Pekka

    Scott Bradner - Router requirements deprecated Source Quench already, so ignoring them should be fine.
    Joe Touch - Discussion of counter-measures is incorrect because reaction needs to depend on state (initial connection or later). It is wrong to assume that if a packet reaches the dest that any errors associated with it can be ignored. There could be dups, one with error, or router may send icmp later. Document is wrong in its assumption about sequence numbers.

    Matt Mathis - there are tunnel devices that send both icmp and fragments and don't honor df bit. working to improve pmtu discovery as part of getting rid of icmp entirely. So strong link between pmtu discovery and this document. 1191 is only document that requires icmp; if we update that, we could make all icmp to be soft errors.
    Ted Faber - makes security issues of this draft go away.
    Joe Touch - 1122 specifies required app behavior, so this would be affected by making all icmp soft.
    Dave Borman - should it be moved to tsvwg to be more general? icmp does not know about the upper protocol, only ip. but how you handle the icmp is protocol specific, so for tcp behavior this should stay here. implementation should always do as much checking as it can that any received packet is related to something it is doing, including checking sequence numbers. this is just good practice, even if it is more strict than the specs say.
    Ted Faber - want stacks to do the same checks with the same semantics, so this should be standardized.
    Dave Borman - need to make sure that the checks are valid, e.g., can't check both seq and ack in a reset packet.
    Joe Touch - agree except with conclusion. check needs to make sure this belongs to their outstanding packets, not just to the connection. This is 1122 global, so needs to be tsvwg.
    Matt Mathis - 1122 section on icmp needs "freshening". we realize now that things should be different. go to tsvwg. [should that be pmtud?? -- tvf]
    Dave Borman - tsvwg should address general issues of transports reacting to icmp, but not for specifics about what a tcp implementation should do. two docs, linked.
    Ted Faber - seems like you could do one doc that covers all protocols, or separate docs.
    Dave Borman - issue of soft vs hard errors - point of hard errors was to deal with situations where the error would just recur, vs soft errors might work next time. hard error allows keeping at it forever. but it is gray between hard and soft, not binary. so some errors may be hard sometimes and soft other times. need to consider situation.
    Randall Stewart - against making hard errors all soft. Need to pay attention to protocol unreachable to keep yourself from becoming an attacker when you get misdirected toward an innocent victim. prefers separate docs because sctp will already address this in own docs. 1122 is a must only for tcp, does not apply to sctp.
    Mark Holinger - agrees with the need to refresh. Not talking about large machines in computer rooms anymore. During establishment, may need to know more about hard errors. But during connection, don't want to pay attention because path may change with mobile devices.

    Mark Allman - will take discussion of this back to the list. Also need to see what overlap there iswith pmtud.
    Pekka Savola - agrees that revision is appropriate.

    tcp-antispoof -- Joe Touch

    Would prefer to state a prefered solution, but if wg can't agree on
    one, then willing to refrain.
    Looking for references to say window should be related to bw*delay.

    John Hefner - this has been implemented in linux (to automatically set window size)
    Dave Borman - need multiple of bw*d in order to allow for lost packets.
    Joe Touch - if you do sack, don't need as much
    Mitesh Dalal - use of tcpsecure or md5
    Aaron Falk - needs editorial pass to fix structure. proposal, solution, issues.
    Joe Touch - the problems are related, so discussed them together
    Aaron Falk - didn't see the tradeoffs in reading the draft
    Ted Faber - wants to be unbiased, fair expression of all solutions. Wants feedback from other "horses in the race"

    tcpsecure - Mitesh Dalal

    Tim Shepard - 7 vendors who implemented: what kind?
    Mitesh Dalal - 2 routers, 2 end host, 2 firewall...
    Tim Shepard- year's worth of experience may not be meaningful if many applications have not tested it.
    Randall Stewart - an xp service pack does include this?
    Tim Shepard - draft name and title are a problem because it implies too much. but don't have a better suggestion.
    Peter Lay - xp serice pack 2 implements this proposal (in response to Randall)
    Joe Touch - 793 says you should handle things outside the window, and this contradicts that. this should be mentioned.
    Randall Stewart - Joe should send text
    Ted Faber - this is a wg item, put there by fiat. wants to confirm this. this does have IPR.
    Mitesh Dalal - this status [the IPR] has not changed.
    Faber & Touch discuss whether we need to talk about the target (info/experimental/etc) of the draft.
    Jon Peterson (Transport AD) - we do need to say what target the draft will have, but not at the start of process
    Tim Shepard -
    Joe Touch - there are alternatives that are well-spec'd, including tcp md5. not a problem for all hosts, only well-known one.
    Jon Peterson - tcp md5 is not yet standards track, but hums were taken and people were comfortable.
    Ted Faber - hum for comfortable with this -- result was unclear
    Jon Peterson - refine the question
    Ted Faber - hum for individual desire for this to be provisional wg item - result was affirmative.
    Ted Faber - please everyone review, and help decide what status doc should go for.

    non-congestion robustness -- Mark Allman

    Matt Mathis - Jamshid and he worked on rate halving, but problem was that you pull down actual win rather than congestin win. cwin becomes half of actual window. loss is discovered when actual win is at low point. need to revert to sending packet every ack when loss occurs when actual window falls below cwin/2. this is the hard problem that stopped their work.
    Ted Faber - asked for words to the list.
    Sally Floyd - read it and liked it, will do more detailed review. [ this review has subsequently appeared ]

    TCP Roadmap -- Faber for the authors

    Says it is really nice doc, wants everyone to read. [There is a jumbogram issue, but nobody here knew about it.] borman - jumbograms are only for dealing with mtu and interface larger than 64K. code won't ever be used if interface doesn't handle that.

    Ted Faber - good reason not to put it in roadmap?
    Dave Borman - main issue for doc is urgent pointer, but you need to deal with issues even if not jumbograms. and treat all 1's for mss to be unlimited. so, changes to tcp are minimal, so should not be objections to including in doc. can't use jumbogram mechanism if not sending more than 64k.
    Matt Mathis - issue is that people who don't want jumbograms don't want to have to refer to it. another issue is implementeations with sign-extension bugs for mss. detecting all-1's mss.
    Sally Floyd - take question to mailing list
    Tim Shepard - you can't skip reading about jumbograms even if you don't have big interface, so this should stay in the document.
    Dave Borman - two parts:
    1 - support for jg's in 2147
    2 - changes to tcp to properly support jg's
    Ted Faber - happy to receive text
    Sally Floyd - good document, and should be updated every couple of years.

    from jabber, Wes Eddy (an author) says he is inclined to keep it up to date.


    TCP’s Reaction To Soft Errors
    ICMP attacks against TCP
    Non-Congestion Robustness (NCR) for TCP
    TCP Roadmap Status