RE: iSCSI: multiple connection process

["Y P Cheng" <ycheng@advansys.com>]

I watched this thread with curiosity.  Isn't the WG in defining a multiple
connection process solving a specific implementation problem?

The head-of-queue blocking problem results from placing a bunch of PDUs from
several iSCSI requests into a single queue.  Therefore, the WG suggest
another connection to separate commands from data to avoid deadlock.  This
problem is easily solvable with the creation of an exchange table from which
we can serve the data PDUs without having them waiting in a separate queue.
The WG should not worry about if someone chooses a wrong method of delivery
that results to head-of-queue blocking.  By wrong method, I mean using the
TCP reads and writes to deliver/receive the PDUs.

BTW, multiple connections for different application programs is natural and
should be supported.  This is similar to having multiple VI's in a single
system.  If an iSCSI implementation chooses multiple connections to solve
the head-of-queue problem, it would be fine too.  But, should the WG tell
everyone how to do that?

Am I wrong?  If not, may be we should move forward.

Y.P. Cheng, CTO, ConnectCom Solutions Corp.
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Randall R. Stewart
> Sent: Tuesday, September 26, 2000 5:07 AM
> To: julian_satran@il.ibm.com
> Cc: Black_David@emc.com; matt_wakeley@agilent.com; ips@ece.cmu.edu
> Subject: Re: iSCSI: multiple connection process
>
>
> Julain:
>
> I have not been involved in any of the offline emails
> that I am aware of and I don't see a consenses on the
> list. I think David is just trying to move us
> forward and I support this. I don't see that he is
> saying remove it completly.. just lets get something
> finished and then open this up in another draft...
>
> I think it is a good way to move forward...
>