Transport Area Working Group Minutes
Taken by Aaron Falk, some editing by Vern Paxson
Agenda:
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.
Discussion:
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.
