Subject: Re: Kicking TCP

From: Vernon Schryver <[email-masked]>
Date: Tue, 7 Mar 2000 16:26:05 -0700 (MST)

> From: Dan Grossman <[email-masked]>
>
> Seems to me that resuming without changing cwnd assumes that the congestion 
>state hasn't changed during the outage.   That seems unlikely.  Wouldn't it be 
> better to reduce cwnd to ssthresh?

There is a draft that will soon advance (if it has not already) on the
standards track concerning what to do when the congestion window gets
stale for any of many reasons, including some that cover this situation.

Kicking TCP with a repeated TCP segment to trigger a delayed ACK when a
link comes back sounds plausible.  I bet I could name that tune in 30
lines in a couple of PPP implementations.  I'm not sure why it's useful,
since I would have hoped that reasonable implementations would queue
TCP packets on the far side of the link when it went down, and since the
wireless people seem so interested in monitoring the link state.

Isn't this repeating of TCP segments a very limited form of ARQ? 
Are you sure it wouldn't be better to admit as much and then ask if
partial ARQ wouldn't be just as simple and more generally effective?

Generating an ICMP packet would also be straightforward, if I could
figure out where to send it.  Would you record the last IP address
seen in the router and just send to there in the hope that all TCP
connections are to that host?

Using an ICMP Redirect to kick TCP sounds unlikely to work.  There
is too much deployed code that either sends ICMP Redirects in
completely unrelated situations or that expects to have to deal
with them in unrelated situations.  Then there are the many firewalls
and other filters that discard all ICMP Redirects on (mostly bogus)
security grounds before they could get to the TCP peer.

What with firewall, filters, and NAT boxes, I don't see how you can hope
to get anything to the TCP remote peer often enough to do much good, except
an IP packet that looks very much like other recent IP (i.e. TCP) packets.

Vernon Schryver    [email-masked]

---

From: Phil Karn <[email-masked]>
Date: Tue, 7 Mar 2000 23:43:49 -0800

>partial ARQ wouldn't be just as simple and more generally effective?

It's not quite the same as partial ARQ. I'm assuming that the node
with an interface on the downed link would have an out-of-band
indication from the link level driver whether the link is up or down.
And when it's down, it wouldn't even try to pass a queued packet to
the link driver. It would just hold onto the most recent queued packet
on each flow (e.g., TCP connection), overwriting it with any
subsequent retransmission and wait for the link to come back up. When
it does, it would forward the packet normally. Whether the packet is
just a TCP ack or it also contains data, it should stimulate the
sending TCP into resuming normal operation.

Phil

---

From: [email-masked] (Keith Scott)
Date: Wed, 08 Mar 2000 08:29:24 -0500

At 04:26 PM 03/07/2000 -0700, Vernon Schryver wrote:

[snip]
>connections are to that host?
[snip]

Our notion was to keep an LRU queue of flows that use that link, and to 
send "Link Outage" messages to each of the sources.

                 --keith