summary of iSCSI meeting 22 June 2000

[meth@il.ibm.com]

iSCSI design team meeting
Thursday, 22 June 2000
Haifa, Israel

Attendees:
SDG  Steve De Grate (NuSpeed)
JD   John Dowdy (IBM)
RH   Randy Haagens (HP)
GH   Gabi Hecht (Gadzoox)
JH   John Hufferd (IBM)
NN   Nelson Nachum (Storage)
JM   John Matze (Veritas)
KM   Kalman Meth (IBM)
LDO  Luciano Dalle Ore (Quantumm)
JS   Julian Satran (IBM)
MS   Mark Shrandt (NuSpeed)
PvS  Paul von Stamwitz (Adaptec)
MT   Meir Toledano (IBM)
MW   Matt Wakeley (Agilent)


Overview of last night's brainstorming session.

Problem of spreading the same set of sequence numbers across multiple iSCSI
 NICs.
Only commands need seq numbers.
If assign the seq in the host, then have multiple interrupts on the host
and contesting of some
semaphore by multiple iSCSI NICs.
If even data packets and RTT etc are numbered, this helps in recovery at
the iSCSI level.
Have thin layer of iSCSI in host and the rest in the NIC.
The part on the host gives seq numbering and perhaps some PDU formatting.
The SCSI layer must be well enough behaved to not saturate the iSCSI level.

perhaps via max MTU size or max number of commands pending, etc.
i.e. have some level of flow control imposed to the SCSI level above iSCSI
level
(by limiting the number of pending SCSI commands).
This then obviates need of communication between host iSCSI levels on each
command,
since almost all can be done in the iSCSI NICs.

The communication between the software iSCSI layers can be so low that it
doesn't affect the overall flow.
When needed, (for task management emergencies) the software iSCSI layers
can communicate via regular tcp/ip,
not using the high bandwidth iSCSI NICs.
This obviates the need to use flow control on the other high bandwidth
lines.
They can all saturate, while the auxiliary line is always kept open for
urgent messages.
Only SCSI command PDUs need be numbered

The connections between initiator and target with the iSCSI NICs on both
ends can do much of their
work independently. (RTT and send data).

Discussion.


JS has a scheme to allow seq numbering per LUN all without using excessive
resoures on initiator side.
JS will send out a page describing his ideas.


Discussion of LDO's method from yesterday to use TCP back pressure to avoid
 need for separate iSCSI flow control.

KM put a proposal on the table to go back to the model with one control
channel and multiple data channels,
with several additional features to overcome objections raised earlier.

JS asked KM to put the idea in writing.

LDO suggested we come up with several implementations to see which of the
suggested models works best.

Further discussion of what happens when TCP packets get lost, especially if
 they contain an iSCSI header.
How well can iSCSI compete with FC if we are so dependent on TCP, with its
dropped packets.

In the LAN, TCP packets are not generally lost and we should be comparable
to FC.
Over WAN, can have packet loss and resulting complications, but that is no
longer competing with FC
(which doesn't exist at all in the WAN).


Security:

Open Issues:
need text to go into the internet-draft.

We still have question of SSL vs IPSec.
In the meantime we proposed to describe how to use both, with a
recommendation to use IPSec.
This may have to be left to the WG to decide.
In the meantime, we have to write something concrete.

We have to write the security details according the guidelines on how to
write them up and include it the draft.
See http://www.ietf.org/internet-drafts/draft-rescorla-sec-cons-01.txt.

Suggestion: Start with the description on how to use iSCSI with IPSec.

But IPSec is still (after 3 years) only an Internet-Draft; not an internet
standard.
And it may never become an internet standard, which may delay the
acceptance of iSCSI as a standard.

We can start with  IPSec, and if that prevents us from becoming a standard,
then we can change that section of the draft to no longer depend on IPSec.

The problem with IPSec was going past a NAT (Network Address Translation).
Suggestion to place IPSec at the gateway to the internet, whereas on the
local LANs (SANs) we can go in the clear.
The NATs would be behind the gateways to the LANs.
In this case, have an IPSec tunnel (when use NATs).
Alternatively, use IPSec end-to-end (with no NATs).

Check out SASL to see if we can leverage it.


Naming:

What have most of us agreed to in the meantime?
We do not presently attempt to name LUNs.
We name targets with URL syntax
scsi://host_name[/virtual_target_name]

Multiple views can also be achieved by using different host_names for the
same target.

Further rehashing and discussion about virtual_target_name (= view, = VSDP
== Virtual Service Delivery Port).

Each of these virtual_targets (views) will have a virtual LUN 0 that can
report what is visibile on that virtual_target (view).

There will be an administrative view with name: iSCSI
This view has no LUNs and is only to establish iSCSI sessions that perform
text dialogs to discover what is available on that machine.

How to specify the Access ID?



Lunch


What do we want to accomplish at the upcoming IETF meeting?

Assuming that we have a Working Group formally estalished ......

Do we want to make iSCSI into an RFC proposed standard, implying that we
commit to having 2 different implementations within 6 months?
Are we stable enough to have compatible implementations?

We are also dependent on the opinions of the WG Chairmen and Area Directors
 if this can progress.

RH: We are still at a preliminary stage and we haven't nailed down all the
issues. We will still have to make some changes.
JS: There will also be other bright people who can give us some ideas.

So we aren't really ready to go straight to a proposed standard.
We still need some input.

JS: It is important that as many of us show up at the IETF.
We need to counter the dissenters who may show up.

We need to clean up the 2 documents: Requirements and Protocol.


What presentations do we want to prepare for the IETF meeting?

RH will take a number of the pictures we had on the board and prepare
slides.

We should have a presentations on:
     High level goals and requirements
     Security issues
     Design principles
     Protocol details?
     Implementation implications

We also need time for feedback from others.

Can we ask for 2 sessions? One for high level stuff and one for details and
 feedback?
JS will ask Scott Bradner if we can have 2 sessions.


Action Items:

Place updated Requirements and Protocol documents on the mailing list by
next Wednesday.

LDO and PvS will provide their stuff on security: login process and
discussion of using IPSec.




Schedule:

28 June 2000 - updated Requirements and Protocol documents
29 June 2000 - iSCSI design team phone conference call 8:00-13:00 Pacific
time
5 July 2000 - updated documents ready for IETF
30 July 2000 - IETF meeting