Re: DefaultTime2Retain Negotiation during Discovery Session

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

> Please see below between <RAM> </RAM>
>
> William Studenmund <[email protected]> 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

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips