RE: iSCSI sessions: Let's try again

["Douglas Otis" <dotis@sanlight.net>]

Matt,

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Matt Wakeley
> Sent: Monday, October 02, 2000 5:23 PM
> To: Black_David@emc.com; ips@ece.cmu.edu
> Subject: Re: iSCSI sessions: Let's try again
>
>
> Black_David@emc.com wrote:
>
> <snip>
>
> > Summarizing the above discussion:
> >
> > [Consensus Attempt 1]  I don't see anything that REQUIRES
> > two TCP connections in all iSCSI sessions, because I haven't
> > seen any TCP window closure scenarios [3] that aren't avoidable
> > by reasonable design/engineering of the target.  I therefore
> > propose to re-establish the WG consensus that multiple TCP
> > connections per iSCSI session is OPTIONAL.
>
> Reasons requiring 2 tcp connections per iSCSI session (one for
> commands the
> other for data):
>
> 1- It allows a target to temporarily flow control commands from
> the initiator
> while still allowing data to continue on the "data" connection (allowing
> commands to complete so that the flow control can be opened again).

How do you go about managing the buffers of these connections using TCP?

> 2- It allows commands to be received without being stuck behind a
> large data
> transfer, allowing the target to begin command execution sooner.

You could also break all data transfers into smaller lengths to prevent
queue blockage.

Doug

> 3- if "Consensus Attempt 2" is allowed, it provides a single
> "model" of iSCSI
> while allowing more than one data connection.  It also simplifies
> the "command
> ordering" issues of the symetric model (sending commands on any
> connection).
> -Matt Wakeley
> Agilent Technologies
>