[ofa-general] iWARP issues

[Steve Wise]

Caitlin Bestler wrote:
> On Nov 2, 2007 4:02 AM, Talpey, Thomas <Thomas.Talpey at netapp.com> wrote:
>> At 05:57 PM 11/1/2007, Sean Hefty wrote:
>>> Does anyone know the details regarding the TCP connection retry algorithm in
>>> Linux?  (time between retries, number of retries, etc.)
>> Sure. The time between retries is variable, it starts out as a few seconds
>> (think, three), and backs off exponentially for a variable number of tries
>> (/proc/sys/net/ipv4/*retries*). It comes out to a pretty large number,
>> a minute or two typically.
>>
>> You really don't want to depend on any of this however. TCP will use all
>> sorts of information from other connections, routing table entries and
>> congestion algorithms, etc to be as adaptive as it feels it needs to be.
>> Constants are NEVER a good idea in networking.
>>
>> Why wouldn't you just leave the timeout to TCP, and make CM's infinite?
>>
> 
> I agree that TCP should handle the timeout on TCP connections. Even if
> there are two TCP stacks I see no reason for two TCP connection timeout
> policies.
> 
> But the CM may want  to timeout the MPA Request/Response exchange
> at least slightly more promptly than TCP would timeout an established
> connection.
> 
> This probably is not urgent until iWARP is sufficiently deployed to attract
> DoS attacks, but it would not be a good idea to lock in an absolute  "all
> timeouts are handled at the transport layer" policy for the iWARP CM.
> The gap between connection setup and connection visibility will eventually
> make an inviting target.

I think the provider drivers handle the MPA timeout now.  But the value 
used should probably be some sort of iwarp-specific connection setup 
attribute...