Re: DefaultTime2Retain Negotiation during Discovery Session

Please see below between <RAM> </RAM>

William Studenmund <[email protected]> wrote:    On Aug 18, 2007, at 9:46 AM, RAM SUNEE wrote:

> On Aug 18, 2007, at 8:08 AM, RAM SUNEE wrote:
>
>> Hello,
>>
>> During LoginOperational negotiation phase of Discovery Session,
>> Initiator
>> didn't initiate negogiation for DefaultTime2Retain key.
>> Target tried to negotiate for this key a value of 0,but initiator
>> tried to
>> enter full feature phase without responding to this specific key.
>> In this case what target is supposed to do?
>
> What do you mean "tried to enter full feature phase without
> responding"? It sent back an empty PDU requesting transitioning to
> FFP? Did the target correctly not offer to transition to FFP (did not
> set the 'T' bit in the login response)? The target should not set the
> 'T' bit and it should wait for the initiator to answer, and eventually
> time out the login.
>
> From the RFC:
> 12.16. DefaultTime2Retain
>
> Use: LO Senders: Initiator and Target Scope: SW
>
> DefaultTime2Retain=
>
> Default is 20. Result function is Minimum.
>
> So it's valid to negotiate in a discovery session.
>
> 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>

Take care,

Bill

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