Re: [storm] iSER - what to do

[Alexander Nezhinsky <[e-mail]>]

On Tue, Jul 17, 2012 at 4:20 AM,  <[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