Re: iSCSI: Session Partial Resolution

["Matt Wakeley" <matt_wakeley@agilent.com>]

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.

[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; (2) Use
of ever-larger caches, and improved caching algorithms; (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."


Unless there is "consensus" that this is not required, I think the multiple
connections/session must remain. 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
> ---------------------------------------------------