SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Final Pittsburgh Minutes



    IP Storage BOF minutes
    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
    
    NOTE on consensus: There are several places in the minutes in
    	which "consensus in the room" is noted.  These items can
    	be re-opened on the mailing list (preferably by those who
    	were not at the meeting), especially if there are important
    	technical aspects that are not reflected in the minutes.
    	In the absence of list discussion, the WG co-chairs will
    	assume that the "consensus in the room" is the WG consensus.
    
    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, doesn't
    prescribe a specific solution, and is expected to be published as an RFC.
    
    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 in the room:
    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 to implement?
    
    The consensus in the room was that encryption should
    not be mandatory to implement. A lot of people were concerned about the
    overhead that implementation would imply on cheap devices.
    
    Security negotiation is required so that a device that doesn't implement
    encryption can say so in an understandable fashion.  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?"
    
    The AD noted that the WG did not have the option of not making 
    the implementation of authentication non-mandatory.
    
    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 in the room 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
    Fibre Channel 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.  Note that VI is currently not an official work item for
    the ips WG.
    
    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.
    
    


Home

Last updated: Tue Sep 04 01:07:45 2001
6315 messages in chronological order