Subject: iSCSI: MaxRecvPDULength simplification

From: Michael Schoberg <[email-masked]>
Date: Tue, 26 Mar 2002 17:19:03 -0600

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:[email-masked]]
Sent: Tuesday, March 26, 2002 1:50 AM
To: Michael Schoberg
Cc: IPS Reflector (E-mail); [email-masked]
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 <[email-masked]> 
Sent by: [email-masked] 

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

        To:        "IPS Reflector (E-mail)" <[email-masked]> 
        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 ...

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 27 Mar 2002 09:39:47 +0200

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

27-03-02 01:19

        To:     "IPS Reflector (E-mail)" <[email-masked]>
        cc: 
        Subject:        iSCSI: MaxRecvPDULength simplification

 
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:[email-masked]]
Sent: Tuesday, March 26, 2002 1:50 AM
To: Michael Schoberg
Cc: IPS Reflector (E-mail); [email-masked]
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 

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

          retransmission of any number of PDUs (including one).  The 
number