Ramon,
Your 3-dupacks scheme indeed appears to be an interesting
solution that is compatible with the existing TCP standards.
However, it seems to me that in the case of a sufficiently long
outage, this scheme would not prevent cwnd from shrinking down
to 1 segment, ssthresh from halving, etc. (correct me if I am
mistaken!). In other words, I see two separate problems to be
solved in the case of intermittent connectivity: (1) notifying
the sender to start transmitting as soon as connectivity is
reestablished, and (2) having the sender utilize the available
bandwidth fully (especially since it may not be long before
the link goes down again).
I guess your scheme solves problem #1 cleanly but doesn't
address #2. Problem #2 may be important only for high-bandwidth
wireless networks. As I mentioned in an earlier posting, one
could view it as simply an extension of the restart-after-idle
problem. In such a scenario, the ICMP message that you propose
could also notify the sender of the (just-concluded) period of
disconnection, and have it undo any timeouts and the like that
may have occurred during that period.
-Venkat
Venkat Padmanabhan
Microsoft Research
padmanab@microsoft.com
http://www.research.microsoft.com/~padmanab
> -----Original Message-----
> From: Ramon Caceres [mailto:ramon@research.att.com]
> Sent: Sunday, February 14, 1999 1:47 PM
> To: pilc@lerc.nasa.gov
> Cc: karn@qualcomm.com; rludwig@huginn.cs.berkeley.edu;
> sanjoy@nortelnetworks.com; adfalk@mail.hac.com; Venkat Padmanabhan;
> rludwig@cs.berkeley.edu
> Subject: Re: LL ARQ on LD links [was: PILC: prioritization]
>
>
> (I just joined this list so my apologies if this has been
> said before.)
>
> Regarding how to improve TCP performance in the face of link
> outages, I agree with Phil (see below) that long retransmission
> backoffs are the main problem to attack. I also think that an
> explicit signal to restart TCP is the best way to address
> this problem. I didn't know that Phil had done something like
> this for packet radio until I read his message to this list.
>
> In the work described in
>
> R. Caceres and L. Iftode, Improving the Performance of
> Reliable Transport Protocols in Mobile Computing Environments,
> IEEE JSAC, Vol. 13, No. 5, June 1995.
> http://www.research.att.com/~ramon/papers/jsac95.ps.gz
>
> we implemented such explicit signals to trigger TCP fast
> retransmissions after an abrupt handoff between wireless cells
> (e.g., in an infrared LAN). When the handoff completed,
> the mobility management code on the mobile (which knew that
> connectivity had been restored) sent an internal signal
> to the TCP code on the mobile, which then went into fast
> retransmission.
>
> The TCP code on the mobile also sent a signal to the remote
> TCP. We tried this two ways. In one, the signal was carried
> in an ICMP packet. In the other, the mobile sent three
> duplicate TCP acknowledgements. The remote TCP also went
> into fast retransmission when it received this signal.
>
> For the handoff situation, these signals worked pretty well
> in the end-to-end fashion I just described. For the general
> link outage situation, the ICMP message could be sent in both
> directions of communication from any network node that knows
> the link is back up.
>
> --Ramon
>
> > From: Phil Karn <karn@homer.ka9q.ampr.org>
> >
> > Yes, but. Yes, it's unreasonable to expect TCP to continue
> working if
> > you pull out the network plug. But I would like TCP to recover more
> > quickly when the plug is put back in. Right now, if the
> plug has been
> > out for a while TCP won't discover that the link has returned until
> > the next retransmission timeout. And with the exponential backoff in
> > effect, this can get pretty long.
> >
> > I suggest something along the lines of a "ICMP Reachable"
> message sent
> > by routers to recent senders of packets it had to discard due to a
> > broken link that has since returned. Receipt of this packet would
> > cause TCP to force an immediate retransmission, or to transmit an
> > empty ACK if no send data is pending.
> >
> > I did something like this 10 years ago in my TCP/IP package for
> > amateur packet radio. I called it a "remote kick" command packet and
> > carried it in UDP. While it had to be manually invoked, it
> worked very
> > well.
>
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST