Re: iSCSI: Connection status summary corrections

[julian_satran@il.ibm.com]

David,

Regarding Pierre Labat's proposal - although certainly interesting - it is
another
form of numbering (as Matt Wakeley has already pointed out). It will be
hard to accept
as any ordering scheme needs a limit to the number of yet unordered items
you
are going to keep.  As such I would put it as another version of S.

Regarding the requirement to have multiple connections or not I would not
say that it
precludes ONE connection for control and ONE for data as many other
transport mechanisms (some buses, some protocols like FTP) use.

Again I am somewhat biased for the PA but I also think that S is viable if
PA is flawed.

Julo


Black_David@emc.com on 26/09/2000 21:19:07

Please respond to Black_David@emc.com

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  iSCSI: Connection status summary corrections




A couple of important corrections to Julian's summary:

- There is long standing WG consensus that multiple TCP
     connections per session are optional.
     Therefore the Pure Asymmetric model must also
     support sending both commands and data over
     the same connection when only one TCP connection
     is in the session, and this needs to be added
     to the list of PA drawbacks.
- The discussion of Asymmetric models overlooked
     Pierre Labat's proposal for spreading commands
     across multiple connections, but using a single
     command sequence in which the initiator tells
     the target which connection to expect the
     next command on.  Since this provides the
     initiator with some ability to do load balancing,
     Balanced Asymmetric (BA) might be a good name.

--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
---------------------------------------------------


> -----Original Message-----
> From:   julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com]
> Sent:   Tuesday, September 26, 2000 12:48 PM
> To:     ips@ece.cmu.edu
> Subject:     Status summary on multiple connections
>
>
>
> Dear colleagues,
>
> I am attempting to summarize where we stand with regard to the multiple
> connection issue
> and to the two possible models - Symmetric (S) and Asymmetric (A).
>
> Many of us feel strongly that the multiple connection issue is central to
> the whole design
> and cannot be added as an afterthought.  Moreover designing the hooks to
> allow it later
> will certainly already force us to make a decision. And both the hardware
> and the software designers will be ill-served if we hand them a
> half-backed solution.
>
> However this is not an invitation to reiterate positions that where
> already stated.
> If you feel that I have grossly misstated anything in this note please
> write me and use
> the mailing list only if my answer is not satisfying.
>
> And yes - like the chairman - I would like to make progress but I don't
> see any way to
> do it without satisfactorily closing this issue.
>
> The reasons for multiple connections where discussed at some length and
> where very nicely summarized in a series of notes by Michael Krause
> (beginning of August).
>
> The core reasons for having multiple connections where the need for more
> bandwidth and availability than a single link can supply with a level of
> complexity affordable for simple
> installations and with a traffic engineering and management clearly
> separated from the transport users (SCSI).
>
> The session is embodying this requirement.
>
> The only major objections I have heard against this where those requiring
> to go all
> the way in having one TCP connection/LU - and after a short debate this
> objection
> was practically removed.
>
> The other objections we heard where that this is basically a transport
> issue and it should be solved at transport level.
> That might be true - but since many, if not most, of TCP applications do
> not have this
> requirement it is highly unlikely that TCP is going to do connection
> trunking in the foreseeable
> future.
>
> iSCSI can be designed to use multiple TCP connections in one of two ways:
>
> -Asymmetric - one TCP flow only carries commands the others carry only
> data
>
> -Symmetric - every flow carries both commands and their associated data
>
> The S version is designed in the I-D version 01
> The S version requires an command ordering scheme and that is provided by
> a
> command counter and a sliding window scheme. It was argued that ordering
> needs might be more prevalent than usually thought and a good
conservative
> design should preserve ordering.
> Ordering-per-LU (as it is designed in FCP-2 version 4)  was considered
> impractical as it
> required initiators to maintain state for each LU - while the rest of the
> design required initiators only to maintain state for outstanding
> commands.
> Several comments on this list suggested that this windowing mechanism
> could
> also be used as a command-flow-control mechanism and that is a "bonus" of
> the scheme.
>
> The A version - comes in two flawors:
>
> - pure A (PA) in which ONLY commands  flow on one TCP connection while
> data flow
>    on DIFFERENT connections (with only one data connection being selected
> for a
>    command);   this scheme requires a minimum of 2 TCP connections
> although not
>    necessarily on  different physical links.
>
> - collapsed A (CA) in which commands flow one a single TCP connection
> while data
>    flow on ANY connection; this scheme requires as a minimum 1 TCP
> connection.
>
> Here is first attempt to list the benefits and drawbacks of all of them:
>
>
> - S - benefits
>         - well understood
>         - simple hardware setup and/or TCP API activation
>         - window mechanism can be also used for flow control
>         - the minimum required is a single TCP connection
>
>      - drawbacks
>        - need to maintain a window mechanism
>        - a multiplexing mechanism has to be carefully crafted to avoid
>           closing TCP windows to severely affect command flow and
> performance
>
>
>    - PA - benefits
>           - TCP will both order the commands and provide for flow control
>              through the TCP window mechanism
>           - the multiplexing mechanism is simpler as closing TCP windows
> will
>              never affect command flow
>           - data flow can use a streamlined header (and processing)
>
>         - drawbacks
>            - more complex hardware and/or software API activation
>            - need for a minimum of two TCP connections (not links)
>
>     - CA - benefits
>             - TCP will order the commands
>             - needs a single TCP connection as a minimum
>
>        - drawbacks
>            - more complex hardware and/or software API activation
>            - need for a minimum of two TCP connections (not links)
>            - if command flow control is required counters and the sliding
> window mechanism
>               are required
>            - a multiplexing mechanism has to be carefully crafted to
avoid
>               closing TCP windows to severely affect command flow and
> performance
>
>
> From the above it should be apparent - as was already pointed out by Matt
> Wakeley -
> that the CA inherits the drawbacks of S and PA and as such the choice is
> really
> between S and PA.
>
> Julo
>