iSCSI identity, sessions and recovery: what a second portal does not prove

Identify the node before counting its addresses

iSCSI carries the SCSI command model over TCP. Its node name is independent of network location: one node can have several addresses, and several nodes can share an address. IQN is one naming format, not a synonym for every valid iSCSI name; EUI and NAA formats also exist. [1, sections 4.2.7 and 4.4.1]

The identity definitions follow RFC 7143 sections 2.2, 4.4.1 and 13.9; the last column states Hesela's operational implications. A target portal group tag of zero is valid. Do not confuse this tag with a logical unit number or treat the same tag on different target nodes as a global identifier. [1]

One session can contain several connections

A normal iSCSI session maps to a SCSI initiator-target nexus. Its TCP connections carry iSCSI PDUs and have connection identifiers scoped to that session. Multiple-connection support is subject to the negotiated MaxConnections limit, whose default is one. [1, sections 4.2.1, 11.12.7 and 13.2]

This is not interchangeable with a host multipath stack using separate sessions to reach a logical unit. When reviewing a diagram, ask whether two drawn lines mean two connections in one session, two sessions, or merely two discovered addresses. The drawing alone cannot establish independent switches, controllers, power supplies or data copies.

Discovery is a separate session type. It is restricted to discovery exchanges and logout, uses one connection and requires ErrorRecoveryLevel=0. It does not carry normal SCSI I/O. [1, sections 4.3 and 13.21] In Open-iSCSI's documented manual discovery workflow, discovered targets become database records; they are not yet logged in. [2, section 7.2]

Command order is not completion order

CmdSN orders command delivery across the session; StatSN numbers responses within one connection. Neither counter measures persistence. Immediate commands do not advance CmdSN. [1, sections 4.2.2.1-4.2.2.2]

Illustrative trace, not a capture: connection A carries command 100, while connection B carries command 101. Sorting packets from B alone cannot reconstruct the session's command stream. Likewise, comparing A's status 900 with B's status 20 cannot establish which application operation completed first. Preserve session and connection identity when analysing captures; correlate commands with their task tags.

Command delivery order also does not impose a general order on SCSI responses across connections; special response-fence rules cover specified cases. [1, section 4.2.2.3] Keep this separate from the application's transaction and durability contract.

Recovery level describes capabilities, not a service guarantee

ErrorRecoveryLevel is negotiated for the session using the lower of the offered values, with a default of zero. Supporting level 0 is mandatory; levels 1 and 2 are optional. Higher levels include lower-level capabilities. [1, sections 7.1.5 and 13.20]

Session recovery closes the session's TCP connections and terminates outstanding commands before a new session is established. Also, the RFC's command-PDU retry mechanism fills command-sequence gaps; it is not permission to replay arbitrary failed application operations. [1, sections 7.1.4.4 and 7.2.1]

Hesela's interpretation: report the negotiated level alongside the host driver and target implementation, not as a stand-alone availability score. After an ambiguous completion, use the application's own recovery contract. See timeouts and uncertain write completion and fencing stale writers.

Collect observations from the layer that owns them

The pinned Open-iSCSI README documents these read-only inspection commands. They are examples, not output from a live Hesela test:

iscsiadm -m session -P 2
iscsiadm -m session -P 3

Print level 2 includes iSCSI parameters; level 3 adds SCSI information such as LUNs and device state. A stored node record is not evidence of a running session. [2, section 5]

Open-iSCSI's replacement_timeout controls waiting before affected commands fail upward. Relogin attempts can continue after this timer expires; command retries and multipath queueing have separate effects. Do not read it as a universal application failover duration or prescribe one value for every deployment. [2, section 8.1]

A useful incident record

• Record target identity, portal addresses, TPGT, sessions, connections and logical-unit identity separately.
• Record negotiated parameters, host/driver/target versions and multipath policy, without credentials.
• Time the injected or observed fault, its detection, reconnection, resumed I/O and the application's final outcome separately.
• State what was checked after recovery: readable data, acknowledged writes, ordering, or a full application transaction.

This is a proposed evidence checklist, not a measured result. A successful reconnect alone cannot answer the last question. Continue with flush/FUA persistence boundaries and the distinct NVMe-oF transport architecture.

A historical speedup needs its experimental boundary

Joglekar, Kounavis and Berry's FAST '05 study investigated software CRC and data-copy costs. Its often-quoted 1.4 to 3.6 Gbit/s result is a projected stack throughput from a user-level fast-path sandbox that could not send traffic to real peers. The sandbox used a 1.7 GHz Pentium M; the optimizations combined Slicing-by-8 CRC with interleaved copying. [3, sections 3-5.2, figure 17]

A separate networked test replaced only the CRC algorithm in a UNH iSCSI stack on Linux 2.4.20: a 3 GHz single-processor Xeon initiator, three targets and gigabit NICs. At the paper's 8KB I/O point, the authors reported 15% higher normalized throughput. That is a different experiment, not confirmation of a 2.6-fold live-storage speedup. [3, section 5.2]

Neither result predicts present-day hardware or tests failover. Hesela's practical inference: name the measured layer, baseline, workload and enabled integrity checks before comparing speedups. These are published results, not a benchmark reproduced here.

Method and limitations

Primary-source specification review of RFC 7143 and implementation-documentation review of Open-iSCSI README at commit a65ce4b1858c175d0351c5760015a9ab70212c93. Examples and the incident checklist are explanatory, not collected observations. Historical performance evidence is checked against Joglekar, Kounavis and Berry (FAST 2005), distinguishing its sandbox projection from its networked Linux test.

No target, failure injection, failover-duration or durability experiment was performed. RFC capabilities do not establish support in a particular host driver, target or deployment. The Open-iSCSI reference is pinned to a source revision; deployed distributions and offload drivers may differ. This review does not claim that all iSCSI software supports multiple connections or optional recovery levels.

• iSCSI
• Node name
• Network portal
• Portal group
• Session
• Connection
• Error recovery level
• CmdSN
• StatSN

Primary sources

1. RFC 7143: iSCSI (Consolidated), sections 2.2, 4.2.1-4.2.2.3, 4.2.7, 4.3, 4.4.1, 7.1.4-7.2.1 and 13.2, 13.9, 13.20-13.21
2. Open-iSCSI README, pinned commit a65ce4b: session inspection, discovery and recovery timers (sections 5, 7.2 and 8.1)
3. Abhijeet Joglekar, Michael E. Kounavis and Frank L. Berry: A Scalable and High Performance Software iSCSI Implementation, USENIX FAST 2005, sections 3-5.2

Accessed 17 October 2026. Definitions are paraphrased; explanatory implications and the checklist are Hesela's synthesis.