W3C home > Mailing lists > Public > ietf-discuss@w3.org > September 2000

Re: pilc minutes for IETF 48

From: Mark Allman <mallman@grc.nasa.gov>
Date: Tue, 19 Sep 2000 10:09:26 -0400
Message-Id: <200009191409.KAA28198@lombok-fi.lerc.nasa.gov>
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).


Received on Tuesday, 19 September 2000 10:10:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:00 UTC