SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: Draft 04 remarks



    
    
    Comments in text  - Julo
    
    Thanks,
    Julo
    
    "Yaron Klein" <klein@sanrad.com> on 26/02/2001 19:03:19
    
    Please respond to klein@sanrad.com
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Draft 04 remarks
    
    
    
    
    
    
    Julian,
    
    Some remarks (protocol and typos) for version 04:
    
    Section 1.2.3 says: ?Any message except login and text reaching a target on
    a TCP connection before the full feature phase MUST be silently ignored by
    the target.?
    
    However, the reject message state the possibility for ?full feature phase
    before login (15)? in section 2.20.1.
    
    I suggest changing it to:
    
    Any message except login and text reaching a target on a TCP connection
    before the full feature phase MAY be silently ignored by the target, or
    reported to the initiator by a reject message.
    
    
    +++ in fact it MUST be rejected - that is a slip  - it stayed over from
    older versions +++
    
    Section 2.2 says ?Each segment is preceded by a 4 byte Next-Qualifier.?
    Should be: Each Header Segment?. Data segment doesn?t need a qualifier.
    
    +++ OK +++
    
    In section 2.4, the SCSI response scheme states the sense data as part of
    the BHS. It should be part of the AHS or the data segment.
    
    +++ if you are refering to the figure - the digests remove the ambiguity if
    there is one. And BTW today we don't have any AHS on responses +++
    
    Section 2.4.2 says: ?If a SCSI device error is detected while data from the
    initiator are still expected (the command PDU did not contain all the data
    and the target has not received a Data PDU with the final bit Set) the
    target MUST wait until it receives the a Data PDU with the F bit set before
    sending the Response PDU.?
    
    This means that any outstanding R2Ts must be closed before issuing a bad
    response. How can one set a timer for the end of data transfer in such a
    situation? The target might wait forever if it must wait for the data PDU
    before issuing a response. Besides, why wait for redundant data to reach
    the
    target when the target already knows that it is going to fail the command?
    
    +++ the intent is a device error discovered - and the meaning of the phrase
    is to keep the status until all the data have arrived. If in addition to
    the device error you have also a
    channel error then you will have to timeout and take more drastic option.
    
    Again the statement is to mandate sending the status only after the channel
    is clear.
    If that rule is not enforced and tags are reused some bad things may happen
    ++++
    In 2.4.2, a response status code is ?3 - Unsolicited data rejected?.
    However, chapter 1 instructs a target to terminate the session if it
    experiences an initiator violating the agreed upon values for unsolicited
    data.
    ++++ after sending a reject +++
    Section 2.4.5: SR-length states the sense data length. However, if it is a
    data segment, it should be in the data length field in the WN.
    
    +++ correct - this is an overlook - SR-length will be removed+++
    
    Section 2.7.3 says: ?...or by the Target Task Tag and LUN (for data
    solicited through R2T).? Should clarify that the DataSN starts from 0 for
    each R2T.
    
    +++ It says so but I'll rephrase for clarity as follows:
    
    For output (write) data PDUs, the DataSN is the data PDU number (starting
    with 0) within the current output sequence. The current output sequence is
    identified by the Initiator Task Tag (for unsolicited data) or by the
    Target Task Tag and LUN (for data solicited through R2T).
    
    
    
    Section 2.7.5 says: ?b7   P (poll)?, should be F bit - P was removed.
    
    +++ was raised already and corrected +++
    
    Section 2.8.3 says: ?If the Text Response does not contain a key that was
    requested, the initiator must assume that the key was not understood by the
    target?. In previous chapter it was determined that not responding equal
    none. The phrase should combine these.
    
    +++ OK +++
    
    2.10.5 says that ?CIDs MUST NOT be reused during the life of a session
    (every connection ever used in a session MUST have a unique CID)? but a
    Login Command with the retry bit, allows using the same CID.
    +++ will correct +++
    
    Section 2.11.4, redirections, says: ?...All of the 3 status class?. Should
    be: ?all of the Status-Detail responses MUST ??.
    +++ it looks like an inversion - "all of the stauts class 3 responses" will
    do +++
    
    In section 2.11.5, ?A 0 in the returned TSID indicates that either the
    target supports only a single connection or that the ISID has already been
    used as a leading ISID.?
    Since we already have error codes (Status-Class/Status-Detail) it is much
    better to add the error using them instead of encoding it in the TSID
    field.
    Besides, this is an Initiator Error (class = 2) but we do not have a
    matching Status-Detail code.
    +++
       Initiator     | 0206 | 1   | Invalid ISID or single connection
       SID error     |      |     |
                     |      |     |
    
    
    
    ++++ corrected!
    In section 2.12.2, ?The LUN field MUST be set whenever the Target Transfer
    Tag is set?. This is a ping command, there are no LUNs in here.
    
    +++ If the target is using it it can use LUN 0 - the mistake is in NOP in
    where it is missing++
    
    In 2.12.4, ?The NOP-Out MUST have the Target Tag set only if it issued in
    response to a NOP-In or a Data-IN...?. Data In was removed, should only be
    for NOP In.
    
    And then ?When the Target Transfer Tag is set the LUN field must have the
    correct value for the task.? Again, no LUNs required here.
    +++ see above +++
    In section 2.14, ?.On sessions with a single connection, this might imply
    opening a second connection with the sole purpose of cleaning-up the
    first.?
    This means that the logout command is sent on the same connection that is
    to
    be loged out. But the connection is bad (isn?t this the reason for closing
    it) so how can we send a command on a bad connection? Another thing is if
    we
    first logout the connection it means that the session has no connections
    hence it must be terminated. I think that since Login Command with a retry
    has been suggested this should be the only way to replace a connection.
    
    +++ logout can be sent on connection a to logout connection b +++
    
    Section 1.2.3 says: ?The target indicates a successful authentication and
    authorization by sending a login response with "login accept". Otherwise,
    it
    sends a response with a "login reject", indicating a session is not
    established.?
    
    +++1.2.3 explains login in broad terms - details follow later +++
    
    Should be updated to the new statuses.
    
    Section 2.3.4 says?... this field will contain the last input DataSN number
    seen by the initiator?.
    
    If the initiator received packets 1,2 and 5, it should acknowledge just
    number 2 and not 5. Otherwise 3 and 4 will be considered as acked. Should
    be
    ?the last DataSN in a sequence?. Also in 2.4.7.
    +++ will rephrase +++
    In 2.11, login response code should be 0x43 and not 0x83.
    +++ will correct +++
    Also says: ?The Login Response indicates the end of the login phase.? Can
    also be partial response, so it does not necessary indicates the end of the
    phase.
    +++ will rephrase +++
    
    Section 2.4.8 says: ?For responses sent because of retry the StatSN used
    MUST be the same as the first time the PDU was sent unless the connection
    was restarted since then.? This implies that a retry can be send on the
    same
    connection. However, this is what we have SACK now. Therefore, the protocol
    should define SACK for this purpose.
    
    +++ If there is no activity and the command is not acked the initiator may
    try to retry it.
    If the task was completed (no data) this will result in the status being
    resent +++
    
    
    Yaron
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:05:30 2001
6315 messages in chronological order