Subject: iSCSI: unsolicited Vs immediate; restart delay

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 06 Mar 2001 12:19:17 PST

Julian,

>To:   [email-masked]
>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

But that puts the target in unsolicited data mode not requiring R2Ts at all!

Sorry if I seem too slow.  Let me try again.  There are three variables -

	1. solicited data mode after FirstBurstSize    UseR2T=yes
	   unsolicited data mode only                  UseR2T=no

	2. Immediate data allowed                      ImmediateData=yes
	   Immediate data disallowed                   ImmediateData=no

        3. Unsolicited burst (immediate & separate) allowed     ??
           Unsolicited burst not allowed                        ??

FirstBurstSize can be used for (3), but a zero FirstBurstSize means
"unlimited" than "not allowed".  My original question was how one can
distinguish the two.

I would be glad to be corrected, if I am misinterpreting the usage of
UseR2T. 

>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.
>
>=== I assume that a traget can figure out by itself after a while that
>there is no rendezvous - but I am open to requests

There's no architected mechanism to figure out on its own!  Either it 
has to keep the (session, connection, task) states around for a long time, 
OR it can clean up the these states and trigger an unnecessary ULP 
recovery on the initiator which is surprised at an unexpected restart failure 
(keep in mind that initiator may not be able to restart a login precisely 
after the "minimum time" specified, typically there's an aggregation 
of multiple O/S timer requests into one master handler).  Providing an 
upper limit is a cleaner, safer design for both initiator and target.

Thanks.
--
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
[email-masked]

---

From: Stephen Bailey <[email-masked]>
Date: Fri, 09 Mar 2001 10:44:30 -0500

> upper limit is a cleaner, safer design for both initiator and target.

I agree with Mallikarjun.

This is a big problem already faced by increasingly general FCP
configurations.  The idea that RR_TOV (the resource recovery timer,
which is equivalent to the timer being discussed here) could be
fixedly specified (as opposed to communicated in the protocol) only
really works with a narrow set of assumptions about the application
configurations.

With many order of magnitude range in delays, as happens with
`internet' protocols, we really can't specify a fixed delay.
Furthermore, in this particular case, we can't really punt it to the
target to select.  The target has no idea.  The sad fact is that the
initiator may not have much of an idea either, but if we don't
provide the knob, a target choice is guaranteed to be wrong in some
cases.

Of course, you probably remember that I'm not a fan of recovery in any
case, so my solution would be to punt recovery altogether.  Clearly
that's not going to happen, so the next choice is to make it work :^)

Steph