IP Storage: Re: DefaultTime2Retain Negotiation during Discovery Session

On Aug 20, 2007, at 11:18 AM, RAMS wrote:

Please see below between <RAM> </RAM>

William Studenmund <wrstuden@xxxxxxx> wrote:

On Aug 18, 2007, at 9:46 AM, RAM SUNEE wrote:

> RAM> Target didn't set 'T' bit when it sent Login response with
> DefaultTime2Retain key.
> What I mean here is that Intiator responded back with a Login
> request with
> an empty PDU(no keys), requesting transition to FFP.
> Because initiator responded back here, there is no question of
> timing out
> the login.What is the correct way the target should handle this?

The target should send back an empty PDU denying the transition to FFP.

There certainly is a question of timing out the login. :-) It is
perfectly reasonable for a target to terminate a login that doesn't
complete after a number of replies. Ken mentioned 100 or 1000 PDUs.
I'd set the limit lower, say at 20. Another option is to keep the
count low, say 10, and reset it when you get a reasonable PDU.

I also recommend that if you kill a login attempt for this reason
(didn't complete, were outstanding Keys), log why you're doingthis and
what keys were outstanding. This will help customers escalate the
issue w/ the initiator vendor.

<RAM> How much is the DefaultTime2Retain key important, when only error recovery level '0' was supported by iSCSI Target? Is it mandatory that there should be a successful negotiation for this specific key, to progress the login into full feature phase? My understanding of RFC3720 is, this key is only meaningful only if error recovery level negotiated is '1' or above(i.e '2')

</RAM>

DefaultTime2Retain has a default value, so if you're happy with that, you don't need to negotiate. Ever.

If the target makes an offer, the initiator has to answer.

In my opinion, ERL 1 doesn't change DefaultTime2Retain's meaning much. ERL 1 is about recovery within a connection, and leaves what happens when a connection fails up in the air. Since DefaultTime2Retain deals with what happens when a connection fails, they deal with orthogonal concepts.

In my experience, the thing that adds lots of complexity isn't directly going to ERL 2, it's supporting MaxConnections > 1. A session with two FFP connections and ERL 0 has a lot of recovery stuff going on. Put another way, most of what people think of for ERL 2 actually comes with ERL 0 && MaxConenctions > 1.

DefaultTime2Retain directly matters for ERL 0 as it sets a timer for the session to fail out. Session failure constitutes an I-T Nexus loss, which can have SCSI consequences.

If all your target supports is READ(10) and WRITE(10) (or READ(16) and WRITE(16)) and one connection, you won't notice DefaultTime2Retain much. But if you support more features, say multiple connections and/or SCSI Reservations (Persistent or otherwise), then it becomes important.

Take care,

Bill