Subject: RE: iSCSI: keys/parameter dependence

From: Robert Snively <[email-masked]>
Date: Tue, 4 Jun 2002 09:07:37 -0700

I stand corrected.  If you want to order batches, you must
not only transmit the keys that you want to batch, but you must
also not transmit another batch of keys until you have received the
replies for the outstanding batch.

You must also do this in a manner consistent with the 
stage of login or post-login operation that is being performed,
as specified in 4.3.  

I haven't studied all aspects of this carefully, but I would
expect that the processing must proceed on a batch by batch
basis, since it is never clear when the Final-Response exchange
will be requested and the target must have completed whatever
negotiation is going on with respect to previous batch exchanges.
I would not expect the target to be allowed to hang around doing nothing
until Final-Response exchanges were requested.  This seems to be
what section 4.4 says, at least for post-login activities.

I was a little surprised to see that post-login negotiations of
a parameter a second time without an intervening reset 
constitute a protocol error.  Some of the values, notably
those duplicating MODE SENSE/SELECT parameters, have traditionally
been renegotiable as desired by the SCSI device without an
intervening reset, and I would expect that capability to have
been mapped into the key=value negotations.

Bob

> 
> Is this true?  When the C bit is not set, there appears to be
> no requirement in the standard that the receiver is forced to
> reply to the keys it has received at that time -- it MUST reply
> to every key eventually, but just having the C bit = 0 does
> not seem to require it to reply then -- it could send an empty
> reply PDU, or could offer new keys of its own at that time
> and delay responding to anything until "everything is on the
> table".  Comments/corrections please.

---

From: Martins Krikis <[email-masked]>
Date: Tue, 4 Jun 2002 12:29:58 -0700 (PDT)

> replies for the outstanding batch.

That's if you don't want to send the next batch
before hearing something back about the previous.
If you are happy with the little you did (or didn't)
receive back), you could just send your next batch
and consider having ordered them. I.e., there was
a moment when the other side was allowed to say
something, so your batches were "ordered"...

> negotiation is going on with respect to previous

There is no such requirement. If the target likes
to respond with nothing (or not with everything
possible) to initiator's first 17 batches and only
send the missing responses in round (exchange)
number 18, that's perfectly legal. It is even
legal to wait for the initiator to set the F-bit
and only then to start negotiating something else,
or respond to keys that can be responded to. (A
correct initiator shouldn't set the F-bit if it
doesn't have the mandated responses, but it could
be that it sends a bunch of boolean keys first
that don't require responses, target answers with
empty, initiator decides to set the F-bit, target
decides to send a bunch of responses, etc.)
Obviously, implementations will likely check
how many rounds (exchanges) have already taken
place and not let the negotiations go on forever.

> what section 4.4 says, at least for post-login

The target is allowed to. 4.4 just says that it is
discouraged to reset the F-bit back to 0 while
sending 0-length data. 

> been mapped into the key=value negotations.

They can be renegotiated, but this has to be after
a negotiation reset (i.e., after sending
TTT=0xffffffff), not necessarily after a device reset,
or in a new negotiation sequence 
(i.e., new ITT, TTT=0xffffffff). But they can
be renegotiated as many times as needed on the
same connection or in the same session.

Martins Krikis, Intel Corp.

Disclaimer: my opinions, not necessarily Intel's.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com