[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00)

On 3 nov 2003, at 13:26, Spencer Dawkins wrote:

Then, you properly mention, for both cases of timeout, the target
value differs application by application that there can be no
meaningful target defined by multi6.


My point here was that humans-in-the-loop give up orders of magnitude
sooner than FTP over TCP (to use one example). Your point, that
"giving up" may involve different strategies for different
applications, is helpful, but seems orthogonal to my point.

Users giving up before applications or protocols is a feature rather than a bug. When Apple first came out with its Safari web browser, it would only wait 30 seconds for a page to load. Now for normal pages 30 seconds is a very long time, so this seemed to make sense. (I'm usually much more impatient than 30 seconds, though.) However, some types of pages, such as very long ones or ones that generate a lot of work for the server (searching for a flight online...) need more than 30 seconds. I that case, the user will wait. Having the application give up when the user knows useful results are still forthcoming is infuriating.

So as long as the user has the option to terminate the session and retry, there shouldn't be any problems.

If by "most of the cases" you believe that end users will sit quietly
while TCP recovers, over a period of minutes, you and I are not
solving the same problem.

So what is it you want to do to avoid this situation?

In the case of a computer using FTP as part
of a cron job, I agree with you, but my experience is that this
portion of Internet traffic is small and declining.

I don't think _any_ type of traffic on the internet is declining in absolute terms. :-)