RE: iSCSI: Session Partial Resolution

["Douglas Otis" <dotis@sanlight.net>]

Matt,

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Matt Wakeley
> Sent: Wednesday, September 20, 2000 2:05 AM
> To: Black_David@emc.com
> Cc: hufferd@us.ibm.com; ips@ece.cmu.edu
> Subject: Re: iSCSI: Session Partial Resolution
>
> Black_David@emc.com wrote:
>
> <snip>
>
> > OTOH, I do not see consensus on the session model for
> > multiple connection sessions among the Asymmetric model,
> > the Symmetric model, and Pierre Labat's proposal.  In
> > order to make progress on iSCSI, I see no alternative to
> > separating multi-connection sessions from the main iSCSI
> > spec.  Significant effort and email traffic has been
> > invested in this topic for at least 6 weeks and the issue
> > is not settled -- I don't think holding up the iSCSI spec
> > for another 6+ weeks in hopes of settling this issue on
> > the list is an effective way to make progress, but I'm
> > prepared to listen to dissenting opinions (e.g., if
> > someone thinks there is rough consensus, and I've missed
> > it); please send such opinions directly to me rather than
> > using the list.  I've already had one offline comment from
> > an outside observer expressing amazement at the willingness
> > of this community to discuss multi-connection sessions
> > "ad nauseum".
> >
> > Therefore, I would ask that the authors of the next
> > version of the iSCSI draft delete all specification
> > of multiple connection sessions from the next version
> > of the except for a note that they will be handled in
> > a separate document.
>
> The "iSCSI Requirements" document requires this capability:
>
> "[R] High bandwidth, bandwidth aggregation.

This is a general feature of IP.

> [D] The bandwidth (transfer rate, MB/sec) supported by storage
> controllers is rapidly increasing, due to several factors: (1)
> Increase in disk spindle and controller performance;

The linear increase in the performance of the mechanical aspects of the
drive have not kept pace with the exponential data density improvements.
Unless dealing with a single massive transfer, the overall effect of data
density improvements is a small reduction in latency lost by the large
latency within a MAN network.

> (2) Use
> of ever-larger caches, and improved caching algorithms;

Network latency negates use of remote caching.  Such caching must be near
the client and not the drive.  If you wish to define a controller
specification, this should be done using appropriate technologies.  Clearly,
if the controller is on site, interface requirements change substantially.
For redundancy, there may even be one per client system! Now the traffic
that needs some work would be to ensure such controllers stay synchronized
if used in a cluster.  Either way, you will not see a higher performance
moving the controller next to the drive.

> (3)
> Increased scale of storage controllers (number of supported
> spindles, speed of interconnects). Not only must the iSCSI
> provide for full utilization of available link bandwidth, it
> also must exploit parallelism (multiple connections) at the
> device interfaces and within the interconnect fabric."

Again, this is a general feature of IP.  If access is to the drive, as it
should be, there is no problem scaling especially if you are using IP.

> Unless there is "consensus" that this is not required, I think
> the multiple
> connections/session must remain.

Not one reason for forcing aggregation into a single connection.  If you
wish to bind multiple adapters, IP supports this.  I doubt you will ever
need to do this however.

Doug

> If nothing else, at least the
> "hooks" should
> remain in the document (such as for login, etc) so as to minimize
> incompatibilities with future versions of the specification.  The
> mechanisms
> to "bundle" tcp connections into a session are the same
> regardless of whether
> they're used "synchronously" or "asynchronously".  Also, it's
> much easier to
> ignore unimplemented fields in a header than to add fields after the fact.
>
> -Matt Wakeley
> Agilent Technologies
>
> > Producing that separate document is going to require
> > an offline design team.  The design team can either be
> > chartered to write a compromise session specification
> > or to evaluate competing specifications and choose one.
> > My current inclination is to do the latter, which would
> > involve having the design team produce a set of requirements
> > and guidelines for session specifications in consultation
> > with the co-chairs, evaluate Internet-Drafts documenting
> > the specifications, and recommend an approach to the WG.
> > Comments on this process are solicited - either on the
> > list or to me directly.  Further discussion of multi-connection
> > sessions on the list is probably not a good use of list
> > bandwidth.
> >
> > --David
> >
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------