Subject: [Ips] DefaultTime2Retain Negotiation during Discovery Session

From: "RAM SUNEE" <[email-masked]>
Date: Sat, 18 Aug 2007 08:08:22 -0700

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?

Also, if the same situation happens during Normal Session,what the target is
supposed to do?

Thanks,
Ram.

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

---

From: William Studenmund <[email-masked]>
Date: Sat, 18 Aug 2007 08:28:48 -0700

> 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=<numerical-value-0-to-3600>

    Default is 20.  Result function is Minimum.

So it's valid to negotiate in a discovery session.

> Also, if the same situation happens during Normal Session,what the  

Same thing.

Take care,

Bill

---

From: "RAM SUNEE" <[email-masked]>
Date: Sat, 18 Aug 2007 09:46:12 -0700

-----Original Message-----
From: William Studenmund [mailto:[email-masked]]
Sent: Saturday, August 18, 2007 8:29 AM
To: RAM SUNEE
Cc: Ips
Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery
Session
Importance: High

 From the RFC:

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?

Same thing.

Take care,

Bill

---

From: "Sandars, Ken" <[email-masked]>
Date: Sun, 19 Aug 2007 20:45:00 -0700

Hi Ram,

So you're probably in a delightful loop where the initiator sends an
empty Login request PDU which requests a transition to FFP, and the
target responds with an empty Login response refusing to transit. This
goes on forever, and probably quite quickly.

Two valid target implementations to break out of this are:

1. Limit the number of Login responses the target will send before it
gives up. Let this be a gross number - say over a hundred, a thousand,
whatever you prefer.

2. Limit the duration from the start of the TCP connection to reaching
FFP. If the login phase goes over your arbitrary limit, terminate the
sequence.

Cheers
Ken

-----Original Message-----
From: RAM SUNEE [mailto:[email-masked]] 
Sent: Sunday, 19 August 2007 02:46
To: Ips; William Studenmund
Subject: RE: [Ips] DefaultTime2Retain Negotiation during Discovery
Session
Importance: High

-----Original Message-----
From: William Studenmund [mailto:[email-masked]]
Sent: Saturday, August 18, 2007 8:29 AM
To: RAM SUNEE
Cc: Ips
Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery
Session
Importance: High

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.

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:

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?

> Also, if the same situation happens during Normal Session,what the 
> target is supposed to do?

Same thing.

Take care,

Bill

---

From: William Studenmund <[email-masked]>
Date: Sun, 19 Aug 2007 22:12:16 -0700

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

>> Initiator
>> tried to

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.

Take care,

Bill

---

From: "Ken Craig" <[email-masked]>
Date: Mon, 20 Aug 2007 08:10:58 -0700

William,

Wouldn't it also be legal for the Target to
terminate the Login with a response code of
Initiator Error after the receipt of the first
empty PDU since the value was offered by the
Target but not returned by the Initiator?

Thanks,
Ken Craig

-----Original Message-----
From: William Studenmund [mailto:[email-masked]] 
Sent: Sunday, August 19, 2007 10:12 PM
To: RAM SUNEE
Cc: Ips
Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery
Session
Importance: High

Take care,

Bill

---

From: RAMS <[email-masked]>
Date: Mon, 20 Aug 2007 11:18:20 -0700 (PDT)

Please see below between <RAM> </RAM>

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

> DefaultTime2Retain=

   
  <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

---

From: William Studenmund <[email-masked]>
Date: Mon, 20 Aug 2007 11:40:28 -0700

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

> William Studenmund <[email-masked]> wrote:
> <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

---

From: "Paul Hughes" <[email-masked]>
Date: Mon, 20 Aug 2007 13:11:11 -0600

I think it's legal to terminate a login if a proposed key is not answered in the next login request/response (with exceptions for Boolean negotiations having optional responses).  I don't think RFC3720 states this explicitly, but this seems to indicate that initiators and targets should not delay answering a proposed key:

5.2.  Text Mode Negotiation

   A target or initiator SHOULD NOT use a Text or Login Response or Text
   or Login Request with no data segment (DataSegmentLength 0) unless
   explicitly required by a general or a key-specific negotiation rule.

My interpretation is that DefaultTime2Retain requires an answer and does not require an empty PDU request/response, therefore the acceptor must answer in the next login request/response.

Thanks,
Paul

-----Original Message-----
From: Ken Craig [mailto:[email-masked]]
Sent: Monday, August 20, 2007 9:11 AM
To: William Studenmund; RAM SUNEE
Cc: Ips
Subject: RE: [Ips] DefaultTime2Retain Negotiation during Discovery
Session

William,

Thanks,
Ken Craig

-----Original Message-----
From: William Studenmund [mailto:[email-masked]] 
Sent: Sunday, August 19, 2007 10:12 PM
To: RAM SUNEE
Cc: Ips
Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery
Session
Importance: High

Take care,

Bill

---

From: William Studenmund <[email-masked]>
Date: Mon, 20 Aug 2007 12:28:58 -0700

On Aug 20, 2007, at 12:11 PM, Paul Hughes wrote:

> I think it's legal to terminate a login if a proposed key is not  
> answered in the next login request/response (with exceptions for  
> Boolean negotiations having optional responses).  I don't think  
> RFC3720 states this explicitly, but this seems to indicate that  
> initiators and targets should not delay answering a proposed key:
>
> My interpretation is that DefaultTime2Retain requires an answer and  
> does not require an empty PDU request/response, therefore the  
> acceptor must answer in the next login request/response.

In the example we're talking about, I think terminating negotiation  
would be fine.

The thing though is that the text above is a SHOULD NOT, not MUST NOT.  
So there _could_ be a good reason for delaying. I can think of one,  
but I admit it's a corner case.

Say the initiator has made key offers to the target which the target  
hasn't responded to. Say the target then offers a key, but in order to  
answer, the initiator needs to know the answer to the offers it made.   
In this case, it seems appropriate for the initiator to send an empty  
PDU, so that the target can answer the offers the initiator made (and  
the target didn't answer last pass).

I admit that's a corner case. And we could have a real problem if both  
sides want the answer from the other to respond. I also can't see why  
we'd run into this with the current set of keys. The only explicit  
tiering we have is with the marker keys, and the initiator can offer  
both "do markers" and "markers are at X" in one offer, then the target  
can answer yes or no on markers and "Irrelevant" for the interval if  
it says no.

So I think an immediate terminate is OK, and waiting for a few round  
trips is OK too.

As an aside I wonder if the initiator implementation is getting  
confused by the offer of 0 (which is PERFECTLY VALID) and internally  
overloading 0 with "nothing to do." Ram, can you tell is which  
initiator is doing this? It's OK if you can't.

Take care,

Bill

---

From: Paul Koning <[email-masked]>
Date: Mon, 20 Aug 2007 15:35:21 -0400

>>>>> "William" == William Studenmund <[email-masked]> writes:

 William> On Aug 20, 2007, at 12:11 PM, Paul Hughes wrote:
 >> A target or initiator SHOULD NOT use a Text or Login Response or
 >> Text or Login Request with no data segment (DataSegmentLength 0)
 >> unless explicitly required by a general or a key-specific
 >> negotiation rule.
 >> 
 >> My interpretation is that DefaultTime2Retain requires an answer
 >> and does not require an empty PDU request/response, therefore the

 William> In the example we're talking about, I think terminating
 William> negotiation would be fine.

 William> The thing though is that the text above is a SHOULD NOT, not
 William> MUST NOT.  So there _could_ be a good reason for delaying. I
 William> can think of one, but I admit it's a corner case.

If the spec says a sender SHOULD NOT do X, then the receiving end is
NOT allowed to insist that the sender do X.  So that means that
terminating the negotiation would be a protocol violation, because it
produces a failure to interoperate with a conforming sender.

	 paul

---

From: "Ken Craig" <[email-masked]>
Date: Mon, 20 Aug 2007 12:38:34 -0700

William,

To me the fact that the Initiator attempted to
transition to FFP without answering the key is
reason enough to terminate the login with an
error.

Thanks,
Ken Craig

-----Original Message-----
From: William Studenmund [mailto:[email-masked]] 
Sent: Monday, August 20, 2007 12:29 PM
To: Paul Hughes
Cc: Ips
Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery
Session

On Aug 20, 2007, at 12:11 PM, Paul Hughes wrote:

> Text

Take care,

Bill

---

From: William Studenmund <[email-masked]>
Date: Mon, 20 Aug 2007 13:00:32 -0700

> reason enough to terminate the login with an

True. I agree.

It depends on why we want to kill the login attempt. :-)

I think that an empty PDU alone isn't enough, especially given Paul  
Konig's comment about interoperation.

Trying to skip answering a key, however is. Good call.

Take care,

Bill

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 21 Aug 2007 11:48:06 -0700 (PDT)

Given the default ErrorRecoveryLevel=0 and
MaxConnections=1 for the Discovery session, the only
thing an initiator would get by a non-zero
DefaultTime2Retain is session continuation (jump
straight from FAILED to LOGGED_IN) when the only
connection in the session fails.  Typical motivation
for a session continuation then is avoiding SCSI side
effects related to I_T nexus loss, and there wouldn't
be any obviously for a Discovery session anyway.

Given all that, it's unlikely that an initiator would
attempt a session continuation for a Discovery session
at all.  On its part OTOH, it's not an undue burden
for a target to support it if a continuation were
attempted - minimal state, primarily around TSIH &
Initiator Port, I'd imagine.

None of this justifies what appears a negotiation
protocol violation identified on this thread.

Mallikarjun

> Trying to skip answering a key, however is. Good

____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC