Re: iSCSI: draft04 questions

[julian_satran@il.ibm.com]

=== coments in text Julo

"Mallikarjun C." <cbm@rose.hp.com> on 02/03/2001 22:49:49

Please respond to cbm@rose.hp.com

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: draft04 questions




Julian,

Thanks.  I am not clear on some. Comments.

>2. I didn't find a way for an iSCSI target to say that it does not support
>any unsolicited data at all.  SPC-2 specifies that a zero FirstBurstSize
>means unlimited.
>
>+++ UseR2T=yes (default) and ImmediateData=no +++

I am confused.  I thought this combination disallows just the "immediate"
data, and not the unsolicited data as a whole.  The draft hints at this
in section 1.2.5.
     "A target MAY separately enable immediate data without
     enabling the more general (separate data PDUs) form of
     unsolicited data."
=== for this case you have UseR2T=yes and ImmediateData=yes
If I misunderstood, could you please comment how immediate data alone is
disabled, while allowing unsolicited data of FirstBurstSize?
=== UseR2T=no ImmediateData=no
>4. Somehow, "Asynchronous Message" seems at odds with the rest of the
>usage in the draft in regards to PDUs (since a message is introduced as
>PDU in section 1.2).  Should we may be just call it an AEN PDU?  Section
>2.14.3 calls this so.  (I realize that it may not always result in a
>SCSI-level AER.)
>
>+++ Fixed 2.14.3 - vox populi in Orlando not to create confusion -:) +++

As I said in my message to David, since we said a message is a PDU in 1.2,
an "Asynchronous Message PDU" would be a redundant term, unless we call it
as "Asynchronous something PDU".  Do you see what I was getting at?  I
would leave it upto you.

>for an initiator, if any, between iSCSI event codes 2 & 3.  Could you
>please
>comment?
>+++ 2 is for the purists - message,logout,login, 3 indicates that the
>target will disconnectd the named connection +++
>Also, isn't the time in seconds the maximum time than the minimum
>time as currently stated?
>+++ time is minimum - allows the target to do the cleanup before being hit
>with a
>login +++

Do I take it then that the draft currently doesn't specify the maximum time
the targets should keep the session & connection records around hoping
for a restart?  I would strongly recommend adding that as an additional
field in the payload, since that is a resource allocation and scalability
issue.

Thanks.

=== I assume that a traget can figure out by itself after a while that
there is no rendezvous - but I am open to requests
--
Mallikarjun


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668   Hewlett-Packard, Roseville.
cbm@rose.hp.com