SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: MaxRecvPDULength simplification


    • To: "IPS Reflector (E-mail)" <ips@ece.cmu.edu>
    • Subject: RE: iSCSI: MaxRecvPDULength simplification
    • From: Michael Schoberg <michael_schoberg@cnt.com>
    • Date: Wed, 27 Mar 2002 10:36:42 -0600
    • Content-Type: multipart/alternative;boundary="----_=_NextPart_001_01C1D5AD.93B20320"
    • Sender: owner-ips@ece.cmu.edu

    SNACK with RL=0 is only one requirement.  Another is task allegiance reassignment (6.1.2) which does not use SNACK (correct?)  Here the initiator sends a Task-Management request with a Task-Reassign message to the target.  The target must reorganize it's T->I messages to match the MaxRecvPDULength of the new connection.  Plus, the Task Reassign message includes the ExpDataSN field which, if I'm reading right, on reassignment the target must remember the sequencing of the old connection in order to track the ExpDataSN field then re-sequence for the new connection (9.5.4).  So now target implementations will have to keep track of sequence indexes for Data-In PDUs for conversion over to the new allegiance.
     
    On-the-fly modification of MaxRecvPDULength also means that some compliance standard must be set for in-flight messages.  An outstanding read request may have T->I PDUs that comply with multiple MaxRecvPDULength values.  In a sense, there will be times where multiple MaxRecvPDULength values are valid.  At what point MUST the target comply with the new value?
     
    So I guess I'm not convinced that the benefit of simplification is illusionary.  Is there a discussion thread that expressly states MaxRecvPDULength must have the flexibility allowed for in the draft?  The discussions I've seen mainly centered around whether it should be duplex valued (I->T, T->I).
     
    Thanks.
    -----Original Message-----
    From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent: Wednesday, March 27, 2002 1:40 AM
    To: Michael Schoberg
    Cc: IPS Reflector (E-mail); owner-ips@ece.cmu.edu
    Subject: Re: iSCSI: MaxRecvPDULength simplification


    The simplification you are talking about is illusory. Currently this requires SNACK to require all data(RL = 0).
    The restriction you propose instead is far more severe (and unwarranted).

    Julo


    Michael Schoberg <michael_schoberg@cnt.com>
    Sent by: owner-ips@ece.cmu.edu

    27-03-02 01:19
    Please respond to Michael Schoberg

           
            To:        "IPS Reflector (E-mail)" <ips@ece.cmu.edu>
            cc:        
            Subject:        iSCSI: MaxRecvPDULength simplification

           


    I've looked over some of the reflector messages regarding MaxRecvPDULength negotiation (back to Oct 2001).  I can't find the discussion of why this value must be available for negotiation outside of login.  It really complicates SNACK and Task Reassignment if the initiator can change this value on-the-fly.  Would it be too restrictive to propose the following rules?
     
    1) MaxRecvPDULength is negotiated only at login before FFP.
     
    2) For message-level recovery, a connection must be prepared to accept the MaxRecvPDULength of the connection it's providing fail over capability for.  It doesn't seem unreasonable to expect fault tolerant configurations to comply with this.  It would simply be stating that RecoveryLevel 2 devices should be somewhat matched in this capability.
     
     
     
     -----Original Message-----
    From:
    Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent:
    Tuesday, March 26, 2002 1:50 AM
    To:
    Michael Schoberg
    Cc:
    IPS Reflector (E-mail); owner-ips@ece.cmu.edu
    Subject:
    Re: iSCSI: SNACK RunLength


    Michael,


    The paragraph says that if you issue a SNACK after the MaxPDURecvLength has decreased you should use RunLength 0 (meaning all) instead of a specific runlength which might not be accurate anymore.


    Julo


    Michael Schoberg <michael_schoberg@cnt.com>
    Sent by: owner-ips@ece.cmu.edu

    25-03-02 19:43
    Please respond to Michael Schoberg

           
           To:        "IPS Reflector (E-mail)" <ips@ece.cmu.edu>

           cc:        

           Subject:        iSCSI: SNACK RunLength


         



    Am I just not reading this or can this paragraph use some help?  Can someone
    give an interpretation?

     9.16.3  RunLength
                                    ...

             The first data SNACK, issued after initiator's MaxRecvPDULength
             decreased, for a command issued on the same connection before the

             change in MaxRecvPDULength, MUST use RunLength "0" to request
             retransmission of any number of PDUs (including one).  The number
    of
             retransmitted PDUs in this case, may or may not be the same as
    the
             original transmission, depending on whether loss was before or
    after
             the MaxRecvPDULength was changed at the target.


    Does this refer to something like:

    For connections with unacknowledged PDUs that undergo MaxRecvPDULength
    negotiation ...






Home

Last updated: Wed Mar 27 23:18:13 2002
9359 messages in chronological order