DRAFT Pittsburgh ips Minutes

[Black_David@emc.com]

Here are the draft minutes from the ips meeting in
Pittsburgh.  Many thanks to Costa and Howard for
taking the notes, and especially to Costa for doing
most of the editing that resulted in these minutes.
Send corrections and clarifications directly to me
or to the list.

Also, would everyone who presented in Pittsburgh
send me their slides for inclusion in the proceedings,
unless they've already been sent me or posted to
the list?  I need PowerPoint or Postscript.  Netiquette
is generally to put large documents (like slides) on
a web site and send a URL to the list rather than
sending directly to the list.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
black_david@emc.com  Cellular: +1 (978) 394-7754
---------------------------------------------------

IP Storage BOF minutes - DRAFT
Summer IETF 2000
Pittsburgh, PA
Wednesday, August 2, 2000
---------------------------

Co-chairs: Steve Bellovin (smb@research.att.com) and
	David Black (black_david@emc.com)

Area directors: Allison Mankin (mankin@isi.edu) and
	Scott Bradner (sob@harvard.edu)

Attendance: ~100 people

Agenda bashing - David Black, co-chair
--------------

There were no comments on the agenda.


Area director - Scott Bradner, Transport AD
-------------

Intellectual property rights:

If there is intellectual property in anything discussed in the WG, the
person discussing it is responsible for saying that there is intellectual
property involved.  If what someone says is going to be constrained by
intellectual property rights, they shouldn't say it, especially if
they're not prepared to describe the resulting restrictions.

A lot of work on iSCSI has been done in a very focused and very
dedicated design team. From now on, this is a WG effort.  Most of the
work should be done on the WG's mailing list in order to:
	- minimize interim meetings
	- minimize phone calls	
	- discuss issues on a common mailing list accessible to all


Charter status and bashing - David Black, co-chair
--------------------------

Concerns were raised about emphasis of TCP as the protocol.  The
charter should not and currently does not limit itself to TCP.
Instead, it states a requirement for congestion control.  Congestion
control without TCP is possible, the ECM working group and SCTP are
examples.

Scott Bradner reminded the group that the charter comes from the
IESG and IAB. This group is only suggesting a charter to the IESG/IAB.
It was agreed that all specific references to Gigabit Ethernet should
be removed from the charter (editor's note: there weren't any).

The question was raised about why FC/IP may be worked on by ips.
The answers were: similar application domains, same people interested
in both technologies, maybe even similar network traffic patterns.

The question was raised of how a charter and a requirements document
differ.  Scott Bradner answered that a charter is commands from the
IESG to the working group, i.e., it's the general structure of what the
working group is going to do and what it won't do.  A requirements
document lays out requirements for the area of investigations.  It is
expected to be longer, it is expected to go into detail, and it doesn't
prescribe a specific solution.

iSCSI requirements - Randy Haagens, Hewlett-Packard
------------------

iSCSI is a native SCSI transport on IP, not FCP on top of IP.

TCP may be deficient for iSCSI use in a couple of areas. The TCP reassembly
buffer is inefficient at higher speeds. The 16-bit checksum seems
insufficient. These problems need to be addressed.

A concern was raised that using multiple TCP connections adds a lot
of complexity to the protocol that is not present in other IETF protocols,
and that this is premature optimization.  Randy responded that storage
bandwidth needs (esp. at high end) will always outrun speeds on a single
link, thus the need to use multiple links through the fabric (which
multiple TCP connection enables).  There was also a brief discussion of
whether to use a TCP connection per LUN - the primary reason not to is
scalability concerns for large storage controllers with lots of LUNs.

Suggestions were made by a number of people that the requirements document
should focus on the required functionality, not the required implementation.

The requirements presentation spent time talking about the SMU concept from
the SCSI Architecture Manual-2. Ralph Weber, secretary of T10, and technical
editor of SAM-2, pointed out that SAM-2 is changing significantly in that
area.  T10 is also working on lifting the 64-bit limit on the size
of target names.

The need for multiple connections to a single LUN was questioned, 
since a LUN will not be able to use more than one network link (a
gigabit link).  Several people pointed out that this is not true,
since many LUNs are backed by RAM, which can source data at full
link rates.
 
An issue was raised about whether gigabit performance should be required.
It was agreed that the requirements should allow a gigabit or more, but
not require it, and it was noted that the charter explicitly mentions small
devices.

------------------

Question for consensus:
All we have available is the 16-bit checksum. looking for direction
on whether 16-bit checksum is adequate, or should be requirements
that there will be strong checksum?

Consensus:
Need to investigate checksums stronger than 16-bits.

SCTP was noted as having a 32-bit checksum.

iSCSI spec - Julian Satran, IBM Research - Haifa
----------

General overview and summary of iSCSI.  See the document for details.

The issue of using multiple connections came up again.  After some
discussion,
it was agreed to take this issue to the list for discussion and resolution.

An issue was raised about whether iSCSI's error recovery on dropped
TCP connections is necessary, as some other have no such error recovery
scheme.  FCP (the Fibre Channel encapsulation of SCSI) has discovered
the hard way that it needs error recovery for dropped frames, which
is now part of the FCP-2 effort.  On the other hand, a parallel SCSI
bus makes no attempt to recover from breaking the physical connection.
It was pointed out that since iSCSI uses TCP, it has fewer cases to
deal with than FCP, since it must only deal with connection drops,
not packet loss.  More discussion on the list is needed on error recovery,
including scenarios that may require the target to drop data that TCP
has successfully delivered (e.g., where the TCP connection breaks before
the ACK or response is delivered and hence the initiator retries the
operation via some other connection).

There was some confusion on SCSI's ordering requirements.
SCSI requires commands to be delivered to the target in the
same order as the initiator issued them. However, the order
in which the target executes the commands is also controlled
by the queuing attributes on the device and command.

There is an inconsistent use of words like should, may, and can in the
document.  For example, the ping response appears to be optional as
currently
worded.  This is wrong and needs to be corrected.  In general, the
authors of the document should review RFC-2119 for definitions of terms
like MUST, SHOULD, and MAY and use them appropriately to clarify the
requirements on implementations.


Security Discussion - led by Steve Bellovin, co-chair
-------------------

The discussion started by asking about the need for encryption:

It was generally stated by the audience that authentication and
integrity seem most important. Speed is also a requirement, 
as initial link speeds of a gigabit are envisioned.

Steve Bellovin noted that encryption generally runs faster than
authentication algorithms and that there were encryption 
algorithms doing a gigabit in hardware already.

It was noted that it is difficult to turn on IPSec in the middle of a
connection.


Consensus call
--------------
There was a consensus call eventually. Should encryption be mandatory?

The consensus in the room is that encryption of the stream should
not be mandatory. A lot of people were concerned about the overhead
it would imply on cheap devices.

There was some discussion that secure negotiation was highly desirable,
to prevent a man-in-the-middle from causing the security negotiation to
result in no security.

It was noted that most application of iSCSI expect a secure interconnect.
Also, secure interconnects are least likely to be available at the low
end, where people have the least ability to pay for a secure network.

-------

Steve Bellovin asked the group about authentication. "Whom are you
authenticating? Is it bi-directional or uni-directional? How many
parties does the SCSI device have to authenticate.  How do you
administer this?"

It was suggested that the host OS be authenticated and that the
authentication should be bi-directional. Web servers could be
used for administration.  It was pointed out that the web server
doesn't scale to large installations and that LDAP could be used
to configure a group of machines.  It was also pointed out that
disks may not have room for a large number of keys and ACLs, which
may necessitate the use of an authentication server.

At the other end of the spectrum, it was observed that storage
arrays are in many cases more powerful than the servers they connect
to.

It was decided that it is feasible have good random numbers from disks.

Steve Bellovin asked if we can do public key calculations
at login time?

The general consensus is that even most disks have enough CPU power to
do this at login time. A hard disk has about as much CPU as a cell phone,
which is capable of doing public key calculations.

The issue of providing customer support for badly configured security
mechanism came up.  How do you deal with a user that has lost his keys?
Add back-door passwords?  There were no good answers in the meeting.

Consensus call
--------------
Should public keys be mandatory for login authentication?

(About half of the people voted for and half against)

Scott Bradner suggested that this issue be remitted to the mailing list.

Steve Bellovin pointed out that it's much harder to do something for
security for UDP than TCP.  TCP is easier because there's a steady,
in-order context. For UDP, one have to do something like IPSec.

Other parting words:
There's no confidentiality without integrity checking.

A separate session key is probably needed for each TCP connection.

For some choices of crypto algorithms (e.g. RC4), it is important to
make sure that you NEVER reuse the same key, as key reuse enables some
relatively easy attacks on the crypto.

----------------

There was no iSCSI MIB discussion due to insufficient time.


FC-over-IP - Elizabeth Rodriguez, Lucent
------------------

It has not been decided where FC-over-IP will be worked on in the IETF.  The
ipfc
WG's time slot will be used to discuss FC-over-IP, but it is not an official
work
item of the ipfc WG.

FC-over-IP is a gateway-to-gateway protocol.  Multiple gateways can talk
amongst
themselves.  This was described as complementary to iSCSI.
See the draft for current technical details.

Scott Bradner asked for input over about where the FC-over-IP work should be
done.
Send Scott mail privately (sob@harvard.edu) or on the ips mailing list.

There was some discussion of a 10km limit in FibreChannel. Standard
FibreChannel
has a 10km limit on a single link based on emitter and detector
characteristics.
The actual protocol timeouts are several seconds which should go allow the
protocol to go much further.

One important timeout is R_A_TOV (resource allocation time-out value),
maximum packet lifetime in a Fibre Channel fabric, which is in the
seconds. Default time-out values in fibre-channel fabrics are between
1-10 seconds.  Should be good for fairly long hauls.

SEP - Paul von Stamwitz, Adaptec
----------------

SEP work is progressing. The one LUN per connection limitation has been
removed
and the packet format is being changed to resemble packetized SCSI.

iSCSI/VI - Constantine Sapuntzakis, Cisco
---------------------

This was a quick presentation to set up a bar/dinner BOF for further
discussion.

Protocol stack overhead is too high for IP-based protocols.
To reduce the number of copies/page flips, the NIC must place data
in the correct place in memory the first time.

One way for the NIC to do this is to parse the upper-layer protocol.
Another way is to add a generic RDMA protocol which works
with multiple upper-layer protocols. 

VI is one good way of doing an RDMA abstraction. By running
iSCSI over VI, we can leverage this generic infrastructure.