SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI: Session Partial Resolution



    > Perhaps I am wrong but it seems we are drifting and not focusing on the
    > search for concurrence regarding Symmetric vs Asymmetric.  What is your
    > view?
    
    John's acquiring the prescient talent of causing the
    co-chair to appear and take action ... as long as he
    doesn't start calling himself a "wizard" based on these
    summoning powers, I won't object :-).  In any case ...
    
    In the past week, I have seen at most one objection
    to each of the following two proposed points of consensus:
    
    (1) An iSCSI session containing a single TCP connection
    	should not be required to use the currently specified
    	iSCSI command reference numbers and sliding window
    	mechanism because TCP will deliver commands in order.
    (2) Use of more than one TCP connection per iSCSI session
    	is OPTIONAL.
    
    Therefore I declare these to be the WG rough consensus on
    these issues, and the next version of the iSCSI draft
    should remove the command reference numbers and sliding
    window mechanism from the iSCSI header.  Somesh Gupta's
    objection to (1) and Matt Wakeley's continued objection to
    (2) are noted as part of declaring these to be the WG rough
    consensus.  Anyone else who objects to this declaration
    of rough consensus should email me directly with the
    reasons for the objection.
    
    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.
    
    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
    ---------------------------------------------------
    
    


Home

Last updated: Tue Sep 04 01:07:11 2001
6315 messages in chronological order