Re: [storm] iSER - what to do

[<[e-mail]>]

Mike,

In particular, we need to say that a new target MUST respond to iSERHello with iSERHello when the iSERHelloRequired key was omitted from the negotiation.  OTOH, if iSERHelloRequired was negotiated to No, target receipt of iSERHello indicates a protocol error by the initiator - the target MAY choose to treat that as an error (e.g., and close the RCaP connection) or the target MAY choose to continue by responding with an iSERHello.

We need to state a recommended timeout value, at least as a default.  1 second seems like a reasonable default, and it could be adjusted via other means (e.g., system configuration).  There's no need to state a single value that MUST be used in all implementations.

I believe the quoted text has to be changed to align with this discussion.

Thanks,
--David

From: Michael Ko [mailto:[e-mail]]
Sent: Tuesday, July 17, 2012 3:07 PM
To: Alexander Nezhinsky
Cc: Black, David; [e-mail]
Subject: Re: [storm] iSER - what to do

An ""old" home-grown initiator implementation which will not send iSERHelloRequired=Yes but will send iSERHello" should not cause any problems.  An old target which does not support iSERHello will fail.  A new target will assume it is dealing with an old initiator which does not use iSERHello and will act according to the new spec for dealing with old initiators.  So when iSERHello shows up, it will follows the new spec for dealing with new initiators.

There are two other issues which need to be resolved.

1. Should the spec say anything about the timeout value?  I agree with Alex that there is no practical value that will work in all cases.  So how about simply stating that the timeout values is outside the scope of the document?

2. In the current iSER spec, section 5.1.1 states that:

"If the outcome of the iSCSI negotiation is to enable iSER-assisted mode, then on the initiator side, prior to sending the Login Request with the T (Transit) bit set to 1 and the NSG (Next Stage) field set to FullFeaturePhase, the iSCSI Layer MUST request the iSER Layer to allocate the connection resources necessary to support RCaP by
invoking the Allocate_Connection_Resources Operational Primitive."

Should the MUST requirement be weakened to a SHOULD as MaxOutstandingUnexpectedPDUs will not be allocated beofre Login Request is sent?

Mike
On Tue, Jul 17, 2012 at 11:45 AM, Alexander Nezhinsky <[e-mail]<mailto:[e-mail]>> wrote:
On Tue, Jul 17, 2012 at 4:20 AM,  <[e-mail]<mailto:[e-mail]>> wrote:
> We can update the spec now - what do you think a reasonable timeframe
> is to push out that code?

I can estimate that the target part can be ready within a month.
It's harder for me to make a correct estimation about the initiator.
But I would bet on a similar time frame.

>From there it should be taken up by the distributions. Each one has
its own pace.
At least RHEL 6.3 was released a couple of weeks ago, so if all goes
well we can
be pretty sure that the changes are included in RH 6.4.

>>    As we are trying to neutralize the shortcomings of the existing
>>    targets, the initiator can bet that the target won't send split
>>    login responses, as it regularly does not do so today.
>
> Ok, this does need to be stated as something that existing targets
> do not do.

Hmm, my second thought is that this may be incorrect in general.
They don't do it in a "normal" setup, where the initiator sends a
small number of keys,
so the target answers with the response of a comparable size.
I need to check how well split responses are generated and tolerated right now.
Probably we should not bet on their absence anyway.

>> 4. "New" target will recognize an "old" initiator by having received
>>    iSERHelloRequired=No either implicitly or explicitly.
>
> "implicitly or explicitly" means either iSERHelloRequired was not
> received or iSERHelloRequired=No was received.  Both cases MUST be
> treated in the same fashion.
>
>>    Then it must
>>    ignore the iSERHello absence
>
> Those aren't the right words.  The target knows that iSERHello will
> not be used - it can choose to terminate the negotiation without setting
> up iSER.

At least in theory, there could be an "old" home-grown initiator implementation
which will not send  iSERHelloRequired=Yes but will send iSERHello.
Should not we allow this ?

> ... then the target SHOULD do one of the following:
>
>>    * delaying sending any "unexpected" PDUs until the first PDU is
>>      received from the initiator after the final login response
>>      has been sent
>>    * taking a reasonable timeout, say a second (the exact value
>>      does not matter as the initiator can't count on it anyway and
>>      no value will solve the problem in full, theoretically).
>>    * doing both, that is waiting for the first incoming PDU and
>>      taking a timer to start sending NOP-INs in case no PDUs arrived
>>      during the timeout period, to be able to detect silent connection
>>      failures.
>
> I believe the second and third bullets ought to be combined, in that
> receipt of a PDU is sufficient reason to end the timeout period before
> it would otherwise expire.

I agree

>
>> 5. "New" target and "new" initiator will count on iSERHello as the
>>    guarantee of proper buffer posting
>>
>> 6. "Old" target and "old" initiator will work as they do now, in their
>>    double bliss of ignorance.
>
> We also need to issue a warning about the latter combination risking
> RCaP session termination if unsolicited PDUs show up from the target
> before the initiator is ready.

Ok

> If the above looks close to correct, we can start working on text for
> the draft ...

I'm ok with this

Alexander
_______________________________________________
storm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/storm