Re: [storm] iSER - what to do

[Michael Ko <[e-mail]>]

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]>wrote:

> 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
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm
>