RE: Re: Requirements specification

[somesh_gupta@hp.com]

The primary reason to have multiple connections per session are
cases where the bandwidth requirements for a related set of
commands (ordered) exceeds the capabilities of a single link.
I am sure there is a desire for this in high end apps (tapes,
remote mirroring etc) regardless of the current size of the fat
pipe.

The other arguments do sound a little weak to me.

A reasonable implementation should be able to drive
a single connection at link speed - so to have features of the spec
that accomodate poor implementations is perhaps not the best
thing to do. Coming hardware accelerators will only make this
more prevelent.

Also if the commands are not related, i.e. going to different
LUNs in the same physical device, you could always open
multiple unrelated sessions to that device. How many sessions
to open etc would be an interesting implementation problem.

Also as soon as the spec specifies mechanisms to recover
sessions with a single connection, one does not need multiple
connections for recovery.

We have always seen demand from customers/envrionments where
there is a desire to transfer a single stream (like ftp) faster
than the fastest currently available link i.e. like the case
in the first para. It would be reasonable to accomodate that.

We have to put more work into the spec to show how the multiple
connections per session would work in terms of an architecture/
paper design. I think this would alleviate the fears of complexity
(I think it will not be too complex - or it might show that it is
indeed too complex).

Somesh

-----Original Message-----
From: mark.carlson@sun.com [mailto:mark.carlson@sun.com]
Sent: Friday, August 04, 2000 2:16 AM
To: mark.carlson@sun.com; julian_satran@il.ibm.com
Cc: ips@ece.cmu.edu
Subject: FW: Re: Requirements specification


julian_satran@il.ibm.com wrote:
> 
> David,
> 
> The one additional requirement is availability/fault-tolerance.

Could you elaborate on this and tell us how multiple connections
between the same two NICs enhance availability?

Also, can you state what the availability requirements are?

> 
> Your arguments about performance are valid. However I doubt that there will
> be enough incentives - beyond price - to develop things for high end
> controllers and
> servers.
> 
> Enabling multiple connections brings those applications the performance
> required
> without any serious implications to the rest of the "family" (as I outlined
> in Pittsburgh
> controllers and servers that don't need multiple connections/session don't
> have to implement them).

The serious implications that I think everyone is concerned about is the
complexity that we are introducing into the protocol and the question of
whether this really provides the performance that is asserted.

> 
> Storage traffic requirements will always exceed those of many other
> applications.
> 
> As for the "one-connection-per-LU" we covered this solution in long
> discussions
> and even several full fledged implementation - as it is compelingly simple.
> However the resource consumption is unjustifiably high and the security
> problems are
> even worse (the LUs "viewed" by an initiator depend on who he says he is)
> than
> in the current draft.

Chances are that each LUN could be owned by separate initiators and require
authentication to separate principals anyway. I think that this is the
requirement we need to keep in mind.

-- mark