2.7.19 Transport Area Working Group (tsvwg)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 09-Mar-00


Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Vern Paxson <vern@aciri.org>

Mailing Lists:

General Discussion:tsvwg@ietf.org
To Subscribe: tsvwg-request@ietf.org
In Body: subscribe email_address
Archive: ftp://ftp.ietf.org/ietf-mail-archive/tsvwg/

Description of Working Group:

The Transport area receives occasional proposals for the development and publication of RFCs dealing with Transport topics, but for which the required work does not rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and a single BOF would not provide the time to ensure a mature proposal. The tsvwg will serve as the forum for developing these types of proposals.

The tsvwg mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion.

The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose.

Goals and Milestones:

Jan 00


Updates to RFC 793 to resolve conflict between diffserv and TCP interpretation of IP Precedence submitted for publication as Proposed Standard

Jan 00


Addition to RFC 2018 to use TCP SACK for detecting unnecessary retransmissions submitted for publication as Proposed Standard

Jan 00


Alternative TCP fast recovery behavior based on rate-halving I-D submitted for publication as Experimental

Mar 00


Submit I-D on TCP Congestion Window Validation to IESG for consideration as a Proposed Standard

Mar 00


Submit I-D on Computing TCP's Retransmission Timer to IESG for consideration as a Proposed Standard.


No Request For Comments

Current Meeting Report

Transport Area Working Group Minutes
Taken by Aaron Falk, some editing by Vern Paxson


Kicking TCP: speeding recovery from subnet outages, Phil Karn

Presentation on performance problems relating to TCP exponential backoff that occurs when subnet links have outages. The timer ratchets up to a large value and when the outage resolves, the sender often still has to wait a long time before finally resuming transmission. Most common cases are found on terrestrial wireless links and dialup links. Proposal is to introduce a new ICMP message, "source encourage", to tell sender to immediately retransmit if a timeout is pending. Sent by stateful routers connected to candidate links. Open issues include being vulnerable to denial of service attacks.

An *implicit* approach (as opposed to the explicit ICMP approach) is to have routers store an IP packet for each connection, which can happen automatically if the router winds up queueing packets because the link layer has announced that it cannot forward at the moment. Per connection storage not possible with IPsec.


Vern (from list): sending a later packet to restart will generate a single ACK because it will be above a sequence hole, not enough to kick TCP.

Phil: if you hold on to the most recent packet, then that will be the retransmission and so will be in sequence when forwarded. Releasing new packets when link is back up will in fact kick TCP.

Comment: could mitigate DOS concerns by having router disregard kicks for outages less than 30 seconds.

Matt Mathis: do you decrement TTL?

Phil: you raise issue of max segment lifetime, which is an outdated concept.

Matt: gets you into PAWs scenarios, recommend rethinking TTL. Some FDDI interfaces save packets forever when cable is removed then reinject them making stacks unstable.

Tim Shepard: always need PAWS, not just for FDDI.

Comment: When kicked does TCP reset timer?

Phil: forces TCP to act as if timer has expired.

Comment: doesn't TCP max timeout do this?

Vern: it's really annoying waiting an entire minute for this to happen. RTO draft caps timer backoff at a minimum of one minute. (Intent was not to change de facto implementations.)

Joe Touch: What about when there are alternate routes to carry traffic that would otherwise get queued up by the broken link?

Phil: may result in additional delayed dupACKs.

Joe: Router will never know that other paths exist.

Mark Handley: prefer explicit mechanism for use with other protocols beside TCP. Receiver should not accept additional messages for some period after getting one.

Tim S.: Old idea allowed end-user to push button to generate message rather than having timer. But this is really no different than the reload button on browsers. Actually a 'go' button would be better because reload restarts the object. Explicit message is a good thing.

Vern: Exposing to user would require building in hysterisis. "Sporadic reward leaves to a belief in supersition."

(Tim: that's what RED is today. :)

Jamshid Mahdavi: Two thoughts. In favor of implicit because can be implemented now. Are there other problems besides PAWS?

Phil: do both and see which ones work.

Jamshid: What about an ICMP message in support of corruptive losses and killing both at one time?

Phil: a better message is 'corruption is now ended.'

Joe: concerned a button will be exploited by end users. Implicit is a lot cleaner.

Ted Tso: don't underestimate people's temptation to hack their stacks to be more agressive.

Steve Deering: In favor of implicit. Buttons are good but should be like elevator or walk buttons.

John Wroclawski: Future devices won't have humans to push buttons. Would be unhappy with a solution that required a human user.

Jamshid: User idea is orthogonal to problem since user doesn't know when link is back up.

Comment: ICMP message is preferable and could be implemented in cellular systems easily.

Vern: what does router hold onto?

Phil: There's explicit flow control between router and subnet and router holds only packets that haven't gone to the subnet.

Comment: All examples are in the class of catastrophic failure. Do you have any examples of failures of only one TCP of many?

Phil: you are assuming this is all in handheld device. When laptops are plugged into a cell phone, the phone is like a router and doesn't have the TCP stack.

Comment: draft needs examples where TCP is not in device with link.

Joe: need to build a system where there is no assumption that the wireless link is the first hop.

Tim: need to document mechanism of what to do when ICMP message shows up regardless of a button or implicit mechanisms.


Link Outage ICMP Notification -- Gabriel Montenegro, Sun

Both link-outage and link-outage-over are useful. Link outage was a valid message at one time, worth revisiting. Easy to send, no state, simple synchronous response using ICMP which stacks and apps already know about: use 'host unreachable' message. RFC1122 says IP must pass these messages to transport. But can't overload existing 'unreachable' codes. Recommend using code #8: 'host isolated.' Introduced for routers (IMPs, actually). Contains enough message to identify originating host. Actions could include local disk caching, activate browser use of caches, freeze timers, etc. Possible issues include whether errors are hard or soft. Could decide based on whether message comes from local host or router.

Steve Deering: some links will send 'destination unreachable' messages when link goes down. What is an example of a hard error?

Gabe: one in which the upper layers won't retransmit forever. Like unhooking ethernet during an NFS transaction.

Steve: would need an AI to guess what the right response is. Give me an example when you'd know what to do?

Geoff Huston: what about the denial of service implications? This would be a great way to take down a network.

(Steve: minumum ICMP format include IP header plus 8 bytes.)

Jamshid: ICMP net down + ICMP kick won't work to manage TCP because you can't be sure you'll get the kick.

Van Jacobson: because one router can't reach a destination doesn't mean the packets won't reach the destination. Most vendors tend to misinterpret this information. Many firewalls filter out these ICMP messages. Suggest you don't do this because you can't know enough about your topology except for very simple networks.

Steve: one use for ICMP message is to print out a diagnostic when application finally quits.


None received.