Re: VI (Was: Avoiding deadlock in iSCSI)

[julian_satran@il.ibm.com]

Randall,

Many in this community are aware of SCTP.

And we will certainly consider it when it will get will get even a
small-percentage
of the world wide support that TCP has or even earlier.

However it is EXTREMELY COUNTERPRODUCTIVE to preach SCTP when we are
looking for a solution WITHIN TCP.

If your experience with SCTP can help us find a better solution WITHIN TCP
please let us
know. If not make a note, mental or otherwise, about another good thing in
SCTP
and keep (or publish) a list of those thinks - we may want it on day - but
don't add
to the noise here.

Thanks,
Julo

"Randall R. Stewart" <randall@stewart.chicago.il.us> on 27/09/2000 14:59:38

Please respond to "Randall R. Stewart" <randall@stewart.chicago.il.us>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: VI (Was: Avoiding deadlock in iSCSI)




Julian:


julian_satran@il.ibm.com wrote:
>
> Charles,
>
> This goes to the hearth of problem.
> To avoid this effect we propose (like FCP) unordered messages to go
always
> through -
> allow the initiator to decide which task management messages he deems
> "urgent".
> But if you have a single connection and the TCP window is closed you are
> left with only
> one think to do - drop the connection (and that is exactly what FCP is
> doing for similar
> reasons!).
>
This is exactly what SCTP's un-ordered message services was
added for. It solves this very issue.

R


> Julo
>
> Charles Monia <cmonia@NishanSystems.com> on 16/09/2000 01:19:37
>
> Please respond to Charles Monia <cmonia@NishanSystems.com>
>
> To:   Stephen Byan <Stephen.Byan@quantum.com>, IPS Reflector
>       <ips@ece.cmu.edu>
> cc:    (bcc: Julian Satran/Haifa/IBM)
> Subject:  RE: VI (Was: Avoiding deadlock in iSCSI)
>
> > -----Original Message-----
> > From: Stephen Byan [mailto:Stephen.Byan@quantum.com]
> > Sent: Wednesday, September 13, 2000 6:22 AM
> > To: IPS Reflector
> > Subject: RE: VI (Was: Avoiding deadlock in iSCSI)
> >
> >
> > Matt Wakeley [mailto:matt_wakeley@agilent.com] wrote:
> >
> > > I don't think VI/TCP helps at all.  The VI is implemented on
> > > top of a TCP
> > > stream.  If the TCP stream delivers the iSCSI command to VI,
> > > and VI has no
> > > place to put it, what is VI going to do?  It has to block the
> > > TCP stream, and
> > > that in turn will block and "RDMA" from occurring.
> >
> > If I understand correctly, VI/TCP has a credit-based flow
> > control mechanism
> > on its message queues (which would be used to implement the
> > iSCSI command
> > reception queue), and so the initiator would never send an
> > iSCSI command
> > without a target buffer in which to store it. So RDMA cannot block on
> > commands in the TCP stream.
> >
>
> In the context of generic ULP "flow control" issues, the following
> observations are offered.
>
> Assuming one VI/TCP message queue handles all SCSI control traffic for a
> target, using flow control on messages to prevent the "queue-full"
> condition
> has undesirable side effects. Specifically, back pressure due to lack of
> command context resources within a logical unit would stop the flow of
> commands and task management requests to all other LUNS (a form of "head
of
> line" blocking).
>
> There's another issue that is perhaps less obvious. Even if multiple
> message
> queues are used, say one per LUN, stopping the flow of messages due to a
> queue full condition would also stop the flow of task management messages
> as
> well.
>
> Charles Monia
> Senior Technology Consultant
> Nishan Systems Corporation
> email: cmonia@nishansystems.com
> voice: (408) 519-3986
> fax:   (408) 435-8385

--
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222 (cell) 815-477-2127 (work)