[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: UNH Plugfest
>>> 1a) (snip) draft v10 addresses these problems. InitialR2T, BidiInitialR2T and ImmediateData are all LO parameters. >>> 1b) However, InitialR2T has a specific restriction (in the description of InitialR2T in Appendix D): In draft 10 it doesn't. BidiInitialR2T does though.. I wonder if it's vestigal text. --buck -----Original Message----- From: Robert D. Russell [mailto:firstname.lastname@example.org] Sent: Monday, February 11, 2002 6:49 PM To: Julian Satran Cc: email@example.com Subject: UNH Plugfest Julian: Attached are some of the issues that arose during the first day of the iSCSI plugfest at UNH on Monday 11-February-2001. Bob Russell InterOperability Lab University of New Hampshire firstname.lastname@example.org 603-862-3774 -------------------------------------------------------------------------- 1a)The following operational keys are labeled with "Use: ALL" and have session-wide applicability: InitialR2T BidiInitialR2T ImmediateData This means that they can be negotiated during the login phase for any connection in a session, as well as during full feature phase on any connection in a session, but at the successful conclusion of that negotiation, the results apply immediately to all connections in the session. The question is: "What is the rationale for making these 3 keys session-wide instead of connection-specific?" Phrased another way, the question is: "Would it not be better if these keys were connection-specific instead of session-wide?" In particular, it appears that dynamic changes to these values on one connection can have an effect on outstanding commands on other connections that requires considerable complication in implementations to handle correctly, yet the benefit is not obvious from the standard. Could someone please supply a rationale for keeping these keys session-wide? 1b)A related issue is that the values negotiated for InitialR2T and ImmediateData are intimately intertwined, as evidenced by the table accompanying the description of ImmediateData in Appendix D. However, InitialR2T has a specific restriction (in the description of InitialR2T in Appendix D): "Once InitialR2T has been set to 'no', it cannot be set back to 'yes'. BidiInitalR2T has the same restriction. But ImmediateData does not have this restriction. The question is: "Why doesn't ImmediateData have a similar restriction?" In particular, this restriction on (Bidi)InitialR2T limits the possibilities for (re)negotiation at any time on any connection mentioned in 1a above, because once unsolicited data PDUs have been negotiated off, they can never be negotiated on again, effectively eliminating InitialR2T from all further negotiations. Could someone please supply a rationale for allowing ImmediateData to be negotiated on/off at any time on any connection but not InitialR2T? 2. Section 3.11.3 discusses the use of the Target Transfer Tag in the Text Response pdu. It says that when the target has more work to do, it MUST set the Target Transfer Tag to some value other than 0xffffffff. When the target does not have more work to do, the standard does not say what value the Target Transfer Tag should have. There are 2 possibilities: a. If the target must set the Target Transfer Tag to 0xffffffff, then the standard should state this explicitly. b. If the target can set the Target Transfer Tag to any value (or leave it undefined) then it appears that there is no need to reserve 0xffffffff for the Target Transfer Tag at all, and there is no need to require a value other than 0xffffffff when F = 0 (any value will work fine). 3. Section 3.8.3 limits the value of the Desired Data Transfer Length in an R2T to at most MaxBurstSize. What is the rationale for this? An R2T is sent by the target to the initiator, so why can't the target specify any size it wants in the R2T? The target already uses R2Ts to control the flow of Data-Out PDUs from the initiator, so why impose this restriction on the R2Ts? Could someone please explain the benefit to this limitation on R2Ts? 4. Section 3.7.1 says that the Data-In pdus sent by the target to satisfy a SCSI read command can be split into sequences each terminated by a pdu having F=1. The standard does not seem to require that this be done. However, if it is done, then the description of MaxBurstSize in Appendix D limits these sequences to at most MaxBurstSize bytes. 4a.The first question is: "What is the benefit for allowing the Data-In pdus to be split into sequences?" It appears that doing so forces a dual role on the F-bit -- as end of sequence and as end of all input -- and complicates the interpretation of this bit in the initiator. This feature seems to be necessary to change direction in bidirectional transfers, but are there other uses for this? 4b.The second question is: "Is the target required to split Data-In pdus into sequences?" If so, this should be made explicit in the standard, and the rationale for this should also be given.
Last updated: Fri Feb 15 09:18:02 2002
8756 messages in chronological order