2.7.17 TCP Maintenance and Minor Extensions (tcpm)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-01


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-04.txt
  • draft-ietf-tcpm-tcpsecure-03.txt
  • draft-ietf-tcpm-frto-02.txt
  • draft-ietf-tcpm-tcp-roadmap-04.txt
  • draft-ietf-tcpm-tcp-antispoof-01.txt
  • draft-ietf-tcpm-tcp-uto-01.txt

    No Request For Comments

    Current Meeting Report

    Tuesday, 2 August 2005 at 1815-1945 CEST

    Notes by Andrew McGregor, Ted's clarifications in []. Spelling corrections (only a few) unnoted.

    Chair's comments - state of the world (Ted):
    • rohc-tcp: TCP header compression
    • Looking for input and document reviewers
      rohc wants committed reviewers, so be sure to contact them if you want credit as one.
    • F-RTO:
    • should be published shortly
    • NCR:
    • approaching WG last call; new draft more understandable; technical input sought.
    • ICMP soft errors:
    • being revised
    • ICMP attacks:
    • will be discussed in Vancouver; revision in progress
    • TCP antispoof
    • revision in progress; perhaps WGLC before Vancouver

    Lars on UTO [see slides for content]

    Bob Braden: UTO is exactly? There's no idle timeout in RFC 793
    Lars: Unacknowledged data time out.

    Abolade Gbadegesin: How does this relate to SO_MAXRT?
    Lars: That's an API for setting this locally. (later: maxrt is apparently defined in posix as a socket option) [After the meeting, Ted: I haven't been able to find it, but under FreeBSD and Linux, I believe the the sockopts to set UTO are SO_SNDTIMEO and SO_SNDTIMEO. Linux has sysctls to set the defaults tcp_retries{1,2}. XXX: Have I run these down correctly, or is there a POSIX sockopt I've missed?]

    Bob: count retransmissions instead of waiting for X time to pass as per 1122 [in UTO negotiations].

    Joe Touch: Conflict between description in document and consequences of actual defined semantics. Description says 'negotiate' etc, but setting is unilateral.

    Bob: It might be in the spirit of TCP to coordinate in the apps, i.e. provide an API, and allow apps to do their own policy.
    Ted: Hooks to do this [coordinate in the applications] are already there [in published RFCs], we intend to allow the stack to do it itself.

    Abolade Gbadegesin: Makes sense to allow app to specify in real time units, have TCP figure it out in RTTs. Also, app doesn't know when this timer started, so it's hard to make use of this.

    Tim Shepard: Sympathetic to the problem, but don't see that carrying an option to the other end is the answer. Why not allow maximum system-wide, allow apps to turn it down, and have policy on purging.

    AG: How does knowing the other end's timeout help me cope with events? All that matters is my own timer.

    Knowing the other end's timeout is of no use if I don't know that the other end has begun trying to send something to me. Typically, the only way to know the other end has begun trying to send something is if there's an upper layer protocol which gives me that information. But if I'm relying on an upper layer protocol to tell me when I should be expecting something from the other end, I may as well rely on that upper layer protocol to tell me the timeout as well. And in that case, I don't need UTO in the TCP layer.

    Ted: Let's take these offline.

    Jabber summary: jishac:
    So I think a way of summarizing Tim's comment and resulting discussion on UTO is that there are a couple of ways of looking at this:
    1. Current is that you have (in example on all of these numbers) a server that uses 5 sec but may be able to support a day dur. for some connections. UTO gives an app a way of requesting some of those resources

    2. Server grants a higher dur. (and thus resources) to all connections but has a smart way of purging connections. and one may argue that the purging will be required with 1 anyways

    F-RTO field testing, Kazunori Yamamoto

    Presenting test results showing reduction in spurious retransmissions due to use of Eifel and F-RTO.

    Bob B: is this intended to be published?
    KY: yes, that is the intention. [See slides for papers, Ted encouraged them to post to lists]

    Greg Daley: asking about number of runs when measuring spurious TOs.
    KY: don't have that number, "a lot"

    Markku, Helsinki U: (co-author of F-RTO draft) interesting findings, similar to our results in an emulated network, we could make delay spikes quite frequent, which makes this much easier to see. It can be the case than when window is open, the RTT is longer and that is why we see more retransmissions due to a delay spike.

    TCP Extensions for immediate retransmission, Lars Eggert

    Summarizes draft looking at mechanisms for forcing probes for connections with outages longer than an RTT. [See slides]

    Draft does not define specific connectivity indicators (as in, triggers for this behavior). Idea is that they be local, not deep in the network.

    Basic idea, send away if you have a connectivity indicator.

    Implicitly, signal with triple-duplicate ACKs
    Explicitly, with a new option.

    LMDR and Retransmit-Now play in the same space.

    LMDR is a proposal to prevent over-aggressive behavior when switching to a slower link (f.e.) [ XXX: Lars/Andrew - what's f.e. short for here? ]

    Bob B: How does this relate to DTN? D=delay or disruption
    Lars: if delay is too long, this doesn't apply, but it might in cars or trains.
    Bob: is it of general application, or specialized?

    Tim: Phil Karn's NOS had mechanism for this sort of thing, 'tcp kick', which WAS useful. But should this be 'below' TCP in some sense... HIP or shim6 might activate this.
    Lars: We actually tested with HIP. But the security issues do remain.

    Greg Daley: It's about path change indication, locators have changed. Maybe want to talk to internet area about carrying this information up and down the stack, and maybe even end-to-end... but only once per endpoint, not per TCP therefore mitigating the security issues.

    AG: draft says that this doesn't change congestion control, it at least seems to violate packet conservation... it introduces extra packets unless endpoints know that the earlier packets have certainly gone. Do CIs announce time of disruption? Must be careful not to introduce unnecessary packets.
    Ted: should be thought about

    Gorry: where do link indications come from? Are we looking at remote links?
    Lars: no, that is not my idea.

    Markku: this could be very useful, but might like to see broader indication than simply reconnect; maybe 'link characteristics have now changed'
    Lars: didn't want it to be too complex

    Wes Eddy [via Jabber]: that's the point of LMDR, and integrating rexmit-now with LMDR.
    [ Wes says: The LMDR signalling specifically indicates that the physical path has changed to some extent (at least at the "final hop"), i.e. it is a "link characteristics have now changed" notification, as the speaker at the mic was suggesting would be useful.]

    Bill S[XXX:??]: million connections likely to be lots of places, so one packet per endpoint pair may not be that much of a win

    Aaron Falk: (at mic) The IAB has been working on documenting some of the many efforts on bringing link change indications into the stack in draft-iab-link-indications. When these mechanisms get deployed, people will start making stack "optimizations" to do this kind of stuff. The IETF should document how to do it right, if that is possible, or why not to do it, if not.

    Ted: Hum if you think that looking at TCP link indication is WG material.
    [A hum was taken indicating approval for the question, but not overwhelming support. After Joe's clarification below no additional hums were taken. Ted's position is that there is interest in the area, but by no means is the topic or the draft a WG priority at this time. The issue is not closed by any means however and more list discussion is actively solicited.]

    Joe Touch: Question had too many negatives. Maybe WG should indicate where it breaks.

    Ted: Lets pursue this on list, there is interest in the field if not the specific document (on its own)

    IPR issues, Eifel response, RFC 4015
    Jon P: IPR situation is uncertain. There are initial indications on ancestors of the current document, but not on it itself. However, have been anecdotal reports of IPR action taking place.

    Scott Bradner (via jabber): the point is that the IPR holder has asked for a NDA discussion to get a license to implement 4015 so its not so theoretical as Jon suggests

    Christian Huitema: encumbered to the point where many in the room cannot implement

    Ted: Scott says cannot directly address IPR in a document, but can say RFC is moved in status based on discussion of IPR

    Christian: try to implement, then can change status

    Scott B: cannot bless IPR claim by specifically referring to it.

    (many 'aah's)

    Ted: hear 'move to experimental with a note'

    Gorry: The roadmap authors and WG moved another standards-track document (jumbograms, RFC2675) to the "extensions" section, on the basis that it was not yet widely implemented. Could a similar case be made for Eifel?

    Ted: that would be another reason

    Markku: there is another complication, proposed standard status was accidental.

    Scott B: Christian is correct about 2026 in theory but we actually have no running code on that part of 2026
    Scott B: I think it has been implemented which is how the question of the license came up

    Ted: Hums showed strong support for moving RFC 4015 to the experimental section of the roadmap - mostly due to IPR concerns, but please post other arguments. Hums on other two options, "move to separate section" and "no change," received basically no support.

    Joe T: note the other reason for moving 4015 to experimental section, i.e., dependence on experimental RFCs, and asked to include that in the comment in the roadmap

    Jon: this leaves the roadmap without any standards-track recommendations for this issue, do we really want that?

    Joe T: Is there another solution we want in the roadmap?
    Ted: F-RTO is a possibility
    Mark Allman: Not F-RTO. F-RTO is a detection algorithm and RFC 4015 is a response algorithm.
    Bob B: don't hold up the roadmap for that
    Ted: should we hold for that?

    Hum was to not delay the roadmap for a new spurious RTO response algorithm and the response was strong to proceed with that issue unaddressed in the roadmap - i.e., no response algorithm in the "Recommended" section.


    TCP User Timeout Option
    Field Test Results of F-RTO
    TCP Extensions for Immediate Retransmissions