RE: Timers and Timeouts in the SSH Transport Protocol

[Dan Davidson <dan.davidson%commatch.com@localhost>]

Also more complicated, I personally tend to prefer the multiple timer
approach. I see this approach more user friendly as the user won't have
to wait for long periods of time when the error occurred at the beginning of

a connection setup.

An intermediate approach may also be considered: dividing the connection
setup into major stages, and timing these parts only (and not per message).

Dan

-----Original Message-----
From: nisse%lysator.liu.se@localhost [mailto:nisse%lysator.liu.se@localhost]
Sent: Wednesday, July 03, 2002 10:30 AM
To: Dan Davidson
Cc: ietf-ssh%netbsd.org@localhost
Subject: Re: Timers and Timeouts in the SSH Transport Protocol


Dan Davidson <dan.davidson%commatch.com@localhost> writes:

> Based on your experience, what do you think the default
> timeout should be.

I don't think you need a specialized timeout for just the version
string exchange. I think it is reasonable to apply a timeout to the
entire initial handshake. E.g. set a timer at 5-15 minutes when you
accept a connection, cancel the timer when userauthentication is
completed, and disconnect if the timer fires.

> Moreover, I do agree with your remark about the
> retransmission and TCP/IP. However, please notice that in 
> numerous telecommunications protocol messages are retransmitted 
> although a reliable transport level is used.
> Example: H.323/H.225.

I've heard that is true also of the IETF SIP protocol, with a
motivation like "messages might have been forwarded over an
un-reliable mechanism like udp somewhere along the path.". Sounds real
ugly.

/Niels