iSCSI: need for new data SNACK code?

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

I am still unclear about the need to add the new data SNACK 
code.  IMHO, this can only be confusing to both initiator and target 
implementers - to have two codes that have identical semantics
on the wire.

The only remaining reason that I see from David (attached below)
is that the new code makes the initiator aware that it must request
status retransmission.  IOW, you're expecting the initiator to be careful 
enough to use the new code, but somehow you don't expect it to be 
attentive enough to discard the status PDU unless it had used this new 
code in an *outbound* SNACK.  I completely miss this rationale.

I'd buy the new code if it's meant to convey something different to 
*targets* because they need to process these SNACK PDUs.  I see
nothing that the targets need to different in satisfying either SNACK.
Both parties are aware of the fact of PDU size change, it it had happened.

The only two changes from the rev14 text that I propose are that we add:

    a) The first status PDU must always be dropped after a MaxRecvDataSegmentLength
        change, if ever a data SNACK is employed for the task.  Initiator MUST issue a
        status SNACK to recover the status PDU (i.e. move the onus of retransmitting
        status from the target to the initiator).
    b) A SNACK requesting an R2T, Data or Status PDU for a task MUST be 
        issued before the status for the task is acknowledged.

I'll be glad to see any technical reasons that I am overlooking, that require two codes.
I'd assume Elizabeth would be the process co-chair, if need be.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com




T.30 (Resegmenting may come as a surprize - suggested a different request)
Ouch - the new SNACK type code was inserted in the middle of the
sequence making this change not backwards compatible with earlier
versions. Please use 3 for the new R-Data SNACK and leave 0, 1
and 2 unchanged from -14.

I am ok with the Initiator deciding whether it needs a new
Response and using the existing Status SNACK mechanism to get it -
that's definitely cleaner than my proposed abuse of the service
response code.  The current working draft uses a MAY for the
initiator requesting a status retransmit - I prefer Mallikarjun's
proposal on the list that the initiator MUST discard the first
Response PDU and MUST use a Status SNACK to get one that is certain

to reflect any resegmentation.  I still disagree with Mallikarjun
about the new R-Data SNACK type code - I would prefer to see this
code used so that the initiator is clearly aware that it is in a
situation where it MUST request status retransmission.  Getting
this wrong risks returning incomplete data on a READ.