notes from the June 29 - phone conference

[julian_satran@il.ibm.com]

Participants (I don't have all the names as it was a rather long call -
5:30 hours! -
and people kept coming and leaving) according to the initial roll call:

Gabi Hecht (GH) and Lani Brauer (spell?) - Gadzoox
Luciano Dalle Ore (LO) - Quantum
Matt Wakeley (MW) - Agilent
Brian Berg (BB) - Berg Software
Dave Nagle (DN) - CMU
Howard Hall (HH) Pirrus Networks
Kalman Meth (KM) IBM
Alain Azagury (AA) IBM
John Hufferd (JH) IBM
Meir Toledano (MT) IBM
Daniel Smith (DS) IBM
Randy Haagens (RH) HP
Costa Sapuntzakis (CS) CISCO
Ed Gardner (EG)  Ophidian
Mark Bakke (MB) NuSpeed (together with two colleagues)
Julian Satran (JS) IBM

The following items where on the agenda:

- review the working draft for iSCSI
- review the requirements document
- a short statement by JS urging all participants to consider Kalman Meth
memo about asymmetric use of connections within a session
- administrivia


Review the working draft:

JS outlined the major areas of change and the rationale behind them as
follows:

   ordering per session as agreed during the meeting in Haifa. The document
   now considers 3 phases in the "life" of a command - emission, execution
   and termination; an initiator task tag is associated with the command
   for the whole life. During emission commands are sequentially numbered
   by the initiator and a complete sliding window mechanism is provided do
   enable a target to use ordered delivery (a target is not required though
   to do so). During execution commands are identified solely by the
   Initiator tag; the initiator can reuse a the reference numbers as soon
   as they are acked. On termination the responses are numbered by the
   target iSCSI and sliding window is used - except that the window size;
   window size for statuses is always the maximum allowed by the sequence
   numbers.
     Concern was expressed by many that the CmdRN current size - 16bit -
     might be two small for the future networks and data rates. After some
     debate a consensus was reached to use 32 bit counts; although that
     might be an overshoot for a long time it is hard to correct if we
     don't reserve the space. Another concern voiced was that if the
     counters are raised to 32 bits then a 32 bit tag is inadequate (JS,
     MW). The majority opinion was that as the 32bit counters will not get
     fully used for a long time 32bit tags will be adequate - and that is
     the current consensus. The counters will be carried by the headers
     (piggybacked); we will consider a new PDU only for the CmdRN window
     (if needed) and the headers will be increased adequately.
     Concern was raised about the need to support multiple connections
     where multiple session will suffice (JH, DS); it was pointed out that
     a target is free to reject any connection but the first.
   connection recovery - is based on the assumption that commands can be
   restarted; the target will request/provide the missing data. For the
   case that command reexecution will have to be communicated to the target
   SCSI layer JS thinks that SAM is vague about it is probably supported
   well by most interesting applications;  interacting with T10 on a better
   specified mechanism could lead to further optimization. Remarkably
   little discussion around the CID - the connection identifier. RH
   expressed concern about the need to close explicitly a connection. That
   is being taken care by a CID login  with a recovery option that can be
   rejected. RH also expressed concern about the fact that there is no
   clear interface for recovery between iSCSI and SCSI and we might have to
   invent the exchange mechanism. It was pointed out (?) that we have
   already the exchange mechanism. A personal note - SAM is vague about who
   does what in this area; one assumes that DMA's are done by the delivery
   mechanism and the rest by some SCSI mechanism. The issue might be more
   academic than practical - whetter the interface between SCSI and iSCSI
   can specify recovery. A consensus was reached to simplify command
   recovery by having the initiator indicate by a flag bit that the command
   is a resent command so that only for those will have the target to look
   in  it's tables for an old match - if any. MB went over the way the
   numbering schemes will be used to achieve recovery both for commands
   that did not make it to the target; if AckCmdRN and MaxCmdRN are the
   lower and upper boundary of the current window then numbers are
   important for commands between AckCmdrN and MaxCmdRN during recovery -
   as the order for those might not have been established by the target.
   For commands outside this range the numbers are irrelevant as the target
   has already established the execution order for them.

   The security text will be sent by LO to JS to include in the draft
   (during weekend?)


Review of the requirements draft:

RH took us over the changes. JS expressed concern about explicitly
excluding classes of devices beyond saying that resources are needed (CP
and memory). It was also agreed to require the protocol to support multiple
connections but simple targets can reject it and initiators do not have to
use it. It was also agreed that since connection allegiance is part of the
solution and not a requirement to remove it from requirements and allow an
open discussion on the issue of allegiance, symmetry etc.


Administrative etc.

EG suggested that whatever presentation we make at IETF we should also take
T10 through it to keep them informed and influence thinking - i.e. give a
talk at their next meeting. He mentioned that T10 has already 2 liaisons to
the not yet formed IETF IPS working group - Charles Monia and Gary Robinson
(spelling?). JS mentioned that this is an issue our WG chairmen would like
to handle.
The only active mailing list is THIS ONE (scsi-tcp is decommissioned).
We will publish working versions of the draft often this week and point you
to them.
We will have a (final) phone conference next Thursday 8AM PDT - 4-5 hours.
RH will host it.

Julo

Julian Satran IBM Research Laboratory in Haifa