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