Re: [storm] iSER - problem with unsolicited NOP-IN right after final Login Response

Mallikarjun Chadalapaka <> Sat, 26 May 2012 01:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F37F21F86D4 for <>; Fri, 25 May 2012 18:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FuNapTCGDUf2 for <>; Fri, 25 May 2012 18:01:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 625FF21F86EE for <>; Fri, 25 May 2012 18:01:56 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Sat, 26 May 2012 01:01:43 +0000
Received: from mail161-tx2 (localhost []) by (Postfix) with ESMTP id 13C65E0206; Sat, 26 May 2012 01:01:43 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -25
X-BigFish: PS-25(zz9371Ic85fh98dK4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah)
Received-SPF: pass (mail161-tx2: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail161-tx2 (localhost.localdomain []) by mail161-tx2 (MessageSwitch) id 1337994099778995_22651; Sat, 26 May 2012 01:01:39 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id B0D7AC0046; Sat, 26 May 2012 01:01:39 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Sat, 26 May 2012 01:01:39 +0000
Received: from ([]) by ([]) with mapi id 14.16.0152.000; Sat, 26 May 2012 01:01:51 +0000
From: Mallikarjun Chadalapaka <>
To: "" <>, "" <>, "" <>
Thread-Topic: [storm] iSER - problem with unsolicited NOP-IN right after final Login Response
Thread-Index: AQHNOXtOIIaCinNGykWqG66+HjtgdZbbOw+g
Date: Sat, 26 May 2012 01:01:50 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E160851FCED17643AE5F53B5D4D0783A092D0294BL2PRD0610MB361_"
MIME-Version: 1.0
Cc: "" <>, "" <>, "" <>
Subject: Re: [storm] iSER - problem with unsolicited NOP-IN right after final Login Response
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 26 May 2012 01:02:01 -0000

I am curious to understand a bit more on why this is a protocol issue per se.

Seems like one way to address this problem is via an implementation approach with the initiator posting in advance the negotiated number of unsolicited PDU buffers, at the same time it makes the (final) negotiation offer. As the in-bound unsolicited PDUs can technically arrive any time after the offer, due to standard network latency mechanics that Alexander summarized. Has that approach been considered?


From: [] On Behalf Of
Sent: Thursday, May 24, 2012 12:03 AM
Subject: Re: [storm] iSER - problem with unsolicited NOP-IN right after final Login Response
Importance: High

Mike (Ko) and Alexander,

Mike is of course correct that iSER Hello usage can be forced by negotiating iSERHelloRequired to "Yes".  However, existing implementations are likely to reply with iSERHelloRequired=NotUnderstood, so we do need to specify what should be done in order to interoperate with an implementation that refuses to deal with the iSER Hello exchange.

I think the situation that Alexander described should be documented in a new section 5.1.4 of the iSER draft.  My general rule of thumb on this sort of surprise found by implementers in the "running code" is that it indicates that something is missing in the spec.  I believe that Alexander has described the solution - more below.

The new section 5.1.4 (suggested section title: Omission of the iSER Hello Exchange) should describe default omission of the exchange, use of iSERHelloRequired key to omit the iSER Hello exchange, and the consequences of target use of unsolicited PDUs after login when the exchange is omitted, including IB's use of NOP-IN (as a keep-alive measure, right?)

The crucial requirements points that I take away from Alexander's description are that if the iSER Hello exchange is omitted, then:

1) The target MAY send *one* unsolicited PDU immediately after sending the Login Response.

2) The target MUST wait at least 200ms (use some other number if 200ms isn't a good choice)
or until it receives a full feature mode PDU from the initiator before sending a
second unsolicited PDU in order to ensure that initiator has sufficient
      time to allocate the full feature buffer resources for the connection.
3) The initiator SHOULD allocate at least one additional buffer for use during login (so that
at least two buffers are in use during login) in order to receive an unsolicited PDU
that may follow login completion.  Failure to allocate this second buffer may
cause connection termination if no buffer is available when an unsolicited PDU arrives.

Both Mike and I are on vacation, so it may be a few weeks until we can agree on the new text and get a -12 version of the draft with that new text submitted.  In the interim, I've asked our AD (Martin Stiemerling) to hold off on further processing of the iSER draft until a -12 version with this new text is submitted.  I'd prefer to work this text out now rather than deal with it as an IETF Last Call comment - as the problem turned up in actual implementations, I think it's worth the extra month that it's likely to take to get correct text on how to avoid the problem into the draft.

I'd suggest that Mike Ko post an initial draft of the text for the new section 5.1.4 to the list when he resurfaces ...


From: Michael Ko []<mailto:[]>
Sent: Monday, May 21, 2012 10:23 AM
To: Alexander Nezhinsky
Cc:<>; Black, David; Or Gerlitz; Mike Christie
Subject: Re: iSER - problem with unsolicited NOP-IN right after final Login Response


The iSER Hello support has never been removed in the latest spec.  Only its use is made optional.  So during login negotiation, just negotiate iSERHelloRequired to Yes.

On Mon, May 21, 2012 at 6:15 AM, Alexander Nezhinsky <<>> wrote:

I understand that it is a bad timing for sending this kind of mail, now that iSER draft was submitted,
but actually we still have a small problem.
It is related to the final Login Response handling and the transition to Full-Featured phase on the initiator side in
Infiniband setups.

When the target receives the final Login Request it send the final Login Response and from its perspective
the connection is now in Full Featured Phase (assuming that it agreed to transition in the Login Response being sent).

This means that the target is ready to accept SCSI commands, Text Requests etc. sent by the initiator.
It also means that the target is eligible to send some unsolicited PDUs, notably unsolicited NOP-INs.

With IB sending NOP-IN periodically is the easiest (an almost only feasible) way to determine closed connections
reliably, because this kind of error is delivered to user only in response to a previously initiated TX operation.

This leaves the initiator in a dubious position. It posts its RX buffers for that connection only when the final
Login Response arrives. But during that time (after the target had sent the Last Login Response but before
the Full Featured phase related RX-buffers are posted on the initiator side) the target may send
the first NOP-IN as it considers the connection in Full Featured phase already and NumOfUnsolicited PDUs
accounting for NOP-INs has been negotiated to a non-zero value.

If the initiator works with a single RX-buffer posted during the entire login phase (which is a logical thing to do
judging by the login exchange protocol) then an error occurs, as no buffers are posted when the NOP-IN arrives
and the connection is shut down.

Posting a single extra buffer before sending the last Login Request only alleviates the problem. Although this
often solves it in practical terms (as the target most probably sends the next NOP-IN only after some timeout
period measuring seconds or hundreds of milliseconds), it does not solves it in terms of protocol completeness,
as the target MAY theoretically send more than one NOP-IN until FF buffers are posted.

This issue was encountered recently in linux iscsi/iser initiator and the above solution has been applied to solve
it against the existing target implementation (STGT), but the initiator remains exposed to this kind of errors.

The solution is actually quite simple (theoretically) - if we bring back the requirement for iSER Hello exchange
then the iSER assisted Full Featured phase does not commence until HelloReply PDU arrives at the target
and the initiator has a definitive point in time when it can safely post its RX buffers - after the final LoginResponse
returns but before it sends iSER Hello PDU.

In practical terms it means that iSER Hello support requirement should be brought back to spec, which is a hassle.

Should we decide on this now?


P.S. : Thanx to Mike Christie and Or Gerlitz, the maintainers of linux iSCSI and iSER initiator for raising the issue.