Re: iSCSI sessions: Let's try again

[Matt Wakeley <matt_wakeley@agilent.com>]

Douglas Otis wrote:

> Matt,
>
> From the little I understand, there is a command window built into this
> scheme which should act as a means to regulate flow of commands.

There is not a window in generic SCSI.  iSCSI proposed one (the command
reference numbers) and everyone hated it.  Thus the idea of using a single tcp
connection only for commands solves the problem in the absense of command
reference numbers.

-Matt

>  You should
> not need an additional connection to perform that function.  I do not think
> stuffing receive buffers is a good technique but it is a good system test.
>
> Doug
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Matt Wakeley
> > Sent: Tuesday, October 03, 2000 12:37 AM
> > To: Douglas Otis; IPS Reflector
> > Subject: Re: iSCSI sessions: Let's try again
> >
> >
> >
> >
> > Douglas Otis wrote:
> >
> > > > 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?
> >
> > Doug, even you know that if you stop reading <in this case the
> > commands> from
> > the TCP stream, TCP will eventually stop the initiator from
> > sending commands.
> > Thus, if the SCSI command queue fills up, the target stops
> > reading from TCP,
> > which eventually shuts down the initiator from sending more commands.
> >
> > -Matt
> >
> >