- From: Mark Allman <mallman@grc.nasa.gov>
- Date: Tue, 19 Sep 2000 10:09:26 -0400
- To: "James P. Salsman" <bovik@best.com>
- cc: pilc@grc.nasa.gov, Reiner.Ludwig@Ericsson.com, discuss@apps.ietf.org, ietf-mmms@imc.org
> As far as robust wireless TCP goes, you are absolutely right that
> good service requires a maximum RTO shorter than the standard 64
> seconds. What is that value in your TCP-Eiffel?
Why should the maximum RTO be less than 64 seconds? If the RTO gets
to that point it was because of exponential backoff. So, one of two
things has happened...
* Extreme congestion. In this case you want your RTO timer to be
backed off to a large time to avoid aggrivating the congestion
even more.
* An outage. In this case, it is potentially painful when the
link is re-established because you have to wait for some (likely
large) amount of time before re-starting transmission. So, for
this case, we'd like to have a lower maximum RTO.
But, how does the end host figure out which situation it is in?
There may be heuristics, but it seems to me that having an explicit
mechanism that "kicks" TCP in the second case is likely the way to
go (i.e., an ICMP or holding on to the last segment(s) to trigger
the restart of the connection).
allman
---
http://roland.grc.nasa.gov/~mallman/
Received on Tuesday, 19 September 2000 10:10:22 UTC