RE: Draft Pgh. Agenda and charter

[julian_satran@il.ibm.com]

Doug,

We had different assumptions for Reads and Writes.
For Reads we assumed that the initiator manages the DMA the target the
exchange.
For writes we have again two options:

- low latency pairs with enough resources would like to expedite writes by
giving-up the RTT trip (large penalty for  small writes) and use either
immediate data
or unsolicited writes. The host DMA is managed by the initiator again and
the target should have the buffers ready.
-higher latency pairs (bandwidth can be the same) and more cost conscious
targets
will operate only in solicited mode and the they could also use the Target
Tag as
a fast "buffer binder" (or cache DMA) while the initiator manages the host
DMA.

In all case we are not mandating any descriptors that can be fetched from
memory although some adaptor vendors may choose to do so; we are limiting
ourselves to the wire protocol
and make only minimal assumptions about the APIs (even the age-old sockets
can do!).
And we would like to remain so unless there are compelling reasons not to.
But as I said we still have some issues open.


Julo




"Douglas Otis" <dotis@sanlight.net> on 25/07/2000 20:18:17

Please respond to "Douglas Otis" <dotis@sanlight.net>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  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.