Re: iSCSI: draft 7: remove S bit and Status field from the Data-i

["Julian Satran" <Julian_Satran@il.ibm.com>]

I am sure we don't want to enter this. The sequencing rules are there to
asure:

   that there is no deadlock (order of data must follow the order of
   commands)
   that the target command buffer does not overflow (MaxCmdSN) - this will
   eliminate an "unlimited number of immediate"

Any additional rules will interfere with performance, multiplexing policy
etc. and I see no great
value in enforcing them (and enforcing means checking and that means
expense).

Julo

Sandeep Joshi <sandeepj@research.bell-labs.com>@ece.cmu.edu on 26-08-2001
00:11:39

Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>

Sent by:  owner-ips@ece.cmu.edu


To:   Dave Sheehy <dbs@acropora.rose.agilent.com>
cc:   IETF IP SAN Reflector <ips@ece.cmu.edu>
Subject:  Re: iSCSI: draft 7: remove S bit and Status field from the Data-i




Julian,

I wonder if Dave's last paragraph in this email has been considered.
Here it is again..

> This does help some. It eliminates the situation where a target can
receive
> an essentially unlimited number of immediate data commands prior to
receiving
> *any* data PDUs.

in reference to Section 1.2.5
> Unsolicited data MUST be sent on
> every connection in the same order in which commands were sent.

The draft currently allows
   c-1,c-2,c-3, (SEP-1-1),(SEP-1-2),(SEP-2-1,SEP-2-2),..
where c-N = command {N}
and   SEP-N-M = unsolicited (non-immediate) PDU number {M} for command
{N}

It would be simplify target login (ITT lookup) if we only permitted
this sequence.
   c-1, SEP-1-1, SEP-1-2, c-2, SEP-2-1, SEP-2-2,..

-Sandeep


Dave Sheehy wrote:
>
> David,
>
> > I think you've taken a wrong turn.
>
> I think John hit the nail on the head.
>
> > > Second, thoughts of removing the immediate data seem not to be
> > > simplification, since all the information to tie the data to the
command
> > is
> > > right there with the command.  That has got to be easier than
matching up
> > > separate PDUs of data with the appropriate commands.
> >
> > Actually, that was the point, since the logic for "matching up separate
> > PDUs of data with the appropriate commands" has to exist for inbound
> > Data PDUs already.
>
> Except that there is a target context present in the solicited case to
route
> the data. That doesn't exist in the unsolicited case.
>
> > The slide I presented in London was about replacing
> > immediate data with an unsolicited data PDU immediately following the
> > command, thus removing the immediate data case in favor of reusing the
> > logic for dealing with separate Data PDUs.  Remember that this was
presented
> > as a simplification possibility.
>
> This does help some. It eliminates the situation where a target can
receive
> an essentially unlimited number of immediate data commands prior to
receiving
> *any* data PDUs.
>
> But, do you mean to say that *one* unsolicited data PDU would follow the
> command? Wouldn't that be unnecessarily restrictive if the PDU size is
small?
> Simply guaranteeing that the data PDUs will immediately follow the
command
> seems like an adequate improvement.
>
> Dave Sheehy