SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Draft Pgh. Agenda and charter



    Julo,
    
    Architecturally, there is a significant difference between serial ATA,
    FireWire with ORBs as a container for direct DMA which could be your meld of
    VIA, or perhaps that of Fibre-Channel or SSA.  I do not have a clear sense
    as to which architecture you advocate nor have your statements shed much
    light in this area.  What happens if there is a 10 milli-second response
    delay within a network?  What delay is tolerable?  From looking at your
    spec, it would appear architecturally to be that of Fibre-channel on a
    different transport, but to even suggest this seems to create heated
    comments.  Perhaps you could indicate your short and long term goals with
    respect to architecture in neutral terms.
    
    1) Target manages exchanges; Initiator manages DMA.
    2) Target manages exchanges and DMA.
    3) Initiator manages exchanges and DMA.
    
    Where intelligence is placed has great effect on security and scalability.
    Which end do you want to see secure and which end do you want to see scale?
    
    Doug
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    julian_satran@il.ibm.com
    Sent: Monday, July 24, 2000 10:02 PM
    To: ips@ece.cmu.edu
    Subject: RE: Draft Pgh. Agenda and charter
    
    
    
    
    Doug,
    
    It is true that RDMA - in a form or other - would be valuable in any fast
    context.
    As it stands the current proposal relies on information already in the
    headers to perform
    the association between packets and buffers. In this sense it is different
    from more direct approaches - like in VIA - in which the context is
    specifically handed over to the remote site.
    However the team that put the draft together feels that we probably have
    some more things to do until we can call it good enough and I hope we have
    a chance to discuss it in
    Pittsburgh.
    
    Regards,
    Julo
    
    "Douglas Otis" <dotis@sanlight.net> on 25/07/2000 06:19:08
    
    Please respond to "Douglas Otis" <dotis@sanlight.net>
    
    To:   Julian Satran/Haifa/IBM@IBMIL, Black_David@emc.com
    cc:   ips@ece.cmu.edu
    Subject:  RE: Draft Pgh. Agenda and charter
    
    
    
    
    Julian,
    
    Are you suggesting iSCSI should distribute the DMA context from the
    initiator adapter to the target device?
    
    Doug
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    julian_satran@il.ibm.com
    Sent: Monday, July 24, 2000 2:38 PM
    To: Black_David@emc.com
    Cc: ips@ece.cmu.edu
    Subject: Re: Draft Pgh. Agenda and charter
    
    David,
    
    It looks good. I still don't understand the FC stuff and I assume that for
    the world at large
    a good encapsulation of serial ATA would be more important, and SSA - a
    very widely deployed ANSI standard protocol - has in this time frame the at
    least same merit as FC but I'll let it be!
    
    As for the agenda:
    
    I assume that Randy will need at least 15 minutes for the requirements
    (Randy ?) and that
    storage "consumers" (SSPs, large users like National Labs) will join the
    discussion (or you will invite them).
    
    I have a already prepared some of the summaries for overview/design
    considerations/ multiple channels. Can we have those in one block (i was
    thinking about 25-30 min)?
    
    Security and some of the open things will certainly fill the remaining
    time.
    
    Thanks,
    Julo
    
    
    
    Black_David@emc.com on 24/07/2000 21:14:17
    
    Please respond to Black_David@emc.com
    
    To:   ips@ece.cmu.edu
    cc:    (bcc: Julian Satran/Haifa/IBM)
    Subject:  Draft Pgh. Agenda and charter
    
    
    
    
    Draft agenda for Pittsburgh along with latest rev.
    to proposed charter follow (both should appear on the
    agenda area of the IETF web site).
    
    Important Agenda notes:
    
    The purpose of the Overview and Rationale talks is
    review of major design decisions.  The 15 minutes
    available for FC-over-IP limits discussion to major
    issues; detailed review of FC-over-IP will not be
    done during the ips meeting.  The 15 minute slots should
    be no more than 10 min of presentation; iSCSI Multiple
    Channels and Error Recovery should be no more than 5
    min of presentation.  Presenters should assume that
    the audience has read the drafts, and hence only cover
    material necessary to get to design decisions, questions,
    issues, etc.  The  5 min time slots are for updates only;
    clarification questions will be entertained if time permits,
    but discussion will need to take place on the mailing list.
    Expect time slots to be enforced in some fashion.
    
    Could those who are going to be presenting each of the
    iSCSI items on the agenda please contact me and let me
    know who's doing what.  I believe I know who the presenters
    are for the other segments.
    
    Thanks, --David
    
    IP Storage (ips) BOF DRAFT Agenda - subject to change
    
    -- Organizational Matters (20 min)
    
    5 min   Agenda Bashing
    5 min   A few words from the AD
    10 min  Charter Bashing
    
         Draft charter for bashing is appended to this
         agenda.  Please bash the charter on the
         mailing list in preference to in the meeting,
         as the charter bashing time can be productively
         used for other purposes.
    
    -- Internet SCSI (iSCSI) (80 min)
    
         draft-haagens-ips-iscsireqs-00.txt
         draft-satran-iscsi-01.txt
         draft-bakke-iscsimib-00.txt
    
    15 min  iSCSI Overview and Rationale
    30 min  iSCSI Security, may include draft-klein-iscsi-security-01.txt
    15 min  iSCSI Multiple Channels
    15 min  iSCSI Error Recovery
    5 min   iSCSI MIB
    
    -- Related Matters (20 min)
    
    15 min  FC-over-IP Overview and Rationale
         draft-ietf-ipfc-fcoverip-02.txt
    5 min   SEP and Parallel SCSI update
         draft-wilson-sep-00.txt
    
    IP Storage (ips) Working Group Proposed Charter - DRAFT 5
    
    There is significant interest in using IP-based networks to transport
    block storage traffic.  This group will pursue the pragmatic approach of
    encapsulating existing block storage protocols, such as SCSI and certain
    Fibre Channel protocols, in an IP-based transport or transports.  The group
    will focus on the transport or transports and related issues (e.g.,
    security,
    naming, discovery, and configuration), as opposed to modifying existing
    block
    storage protocols.  Standards for those protocols are controlled by other
    standards organizations (e.g., T10 [SCSI] and T11 [Fibre Channel]).  The WG
    cannot assume that any changes it desires will be made in these standards,
    and hence will pursue approaches that do not depend on such changes unless
    they are unavoidable and in that case will create a document to be
    forwarded
    to the standards group responsible for the technology explaining the
    issue and requesting the desired changes be considered.  The WG will
    endeavor to ensure high quality communications with these standards
    organizations.
    
    The storage protocols to be encapsulated expect a reliable transport,
    in that failure to deliver data is considered to be a rare event for
    which time-consuming recovery is acceptable.  This has implications
    for both the choice of transport protocols and design of the
    encapsulation(s).  Encapsulations of the storage protocols may require
    quality of service assurances (e.g., predictable latency) to operate
    successfully; the WG will consider what assurances are appropriate and
    how to provide such assurances in shared traffic environments
    based on existing IETF QoS mechanisms such as Differentiated Services.
    
    Use of an IP-based transport raises issues that do not occur in existing
    storage transports.  The WG will address at least the following issues:
    - Congestion control suitable for shared traffic network environments, such
    as
         the Internet.
    - Security measures, including authentication and privacy, sufficient
         to defend against threats up to and including those that can be
         expected on a public network.
    - Storage naming and discovery mechanisms for block storage services
         on IP-based networks, including both discovery of storage for
         access by the discovering entity, and discovery for management.
    - Management, including appropriate MIB definition.
    The WG will address security and congestion control as an integral part
    of its protocol(s); naming, discovery, and management are important related
    issues, but may be addressed in companion documents.
    
    The WG will consider issues raised by bridges and gateways to existing
    implementations of block storage protocols in order to support effective
    interoperability of the protocols developed in the working group with other
    implementations and/or encapsulations of the same block storage
    protocol(s).
    The WG will strive to support the approaches to discovery, multi-pathing,
    and booting taken by the existing block storage protocols it encapsulates
    at the levels of those protocols.
    
    It may be necessary for block storage traffic to pass through Network
    Address Translators (NATs) and/or firewalls in some circumstances; the
    WG will endeavor to design NAT- and firewall-friendly protocols that do
    not dynamically select target ports or require Application Level Gateways.
    
    Effective implementations of some IP transports for block storage traffic
    are likely to require hardware acceleration; the WG will consider issues
    concerning the effective implementation of its protocols in hardware.
    
    The standard internet checksum is weaker than the checksums used by
    existing
    block storage implementations.  The WG will consider what levels of data
    integrity assurance are required for block storage traffic over IP networks
    and how they should be achieved.
    
    The WG will produce a framework document describing the encapsulation or
    encapsulations it intends to pursue, and requirements, applicability
    and protocol specification documents for each encapsulation.  The framework
    document will consider whether both end-system and gateway node (including
    gateways to Fibre Channel) requirements can be accommodated in a single
    protocol
    family (e.g., as has been done by the IP Security Protocol).  The
    applicability
    and requirements documents will consider both disk and tape devices and
    take
    note of the variation in scale from single drives to large disk arrays and
    tape libraries; the protocols need not be applicable to all such devices.
    
    The WG will not work on:
    - Extensions to existing block storage protocols beyond those strictly
         necessary for the use of IP-based transports.
    - Modifications to internet transport protocols or approaches requiring
         transport protocol options that are not widely supported, although
         the WG may recommend use of such options for block storage traffic.
    - Support for environments in which significant data loss or data
         corruption is acceptable.
    - File system protocols.
    
    Milestones
    
    Aug 00 Initial meeting in Pittsburgh.  Discuss selection of encapsulation
         approach or approaches.
    Sep 00 Submit initial version of framework draft on encapsulation
         approaches.
    Dec 00 Discuss framework draft, as well as requirements, applicability
         and protocol specification drafts for at least one protocol
         encapsulation at IETF meeting in San Diego.
    Feb 01 Submit requirements, applicability, and protocol specification
         drafts for at least one protocol encapsulation to the IESG for
         consideration as a Proposed Standard.
    Mar 01 Discuss related drafts (e.g., MIBs, discovery) for at least the
         first protocol encapsulation at IETF meeting in Minneapolis.
    Jun 01 Submit MIB and discovery draft to the IESG.  Begin revision
         of WG charter as appropriate in consultation with ADs.
    Aug 01 Meet at IETF meeting to close any open issues and finish any
    outstanding
         work items.
    
    
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:08:05 2001
6315 messages in chronological order