Subject: RE: [Ips] resending Data-in with S bit set

From: "Dean Scoville" <[email-masked]>
Date: Tue, 5 Oct 2004 14:54:31 -0700

Julian,
 
Section 10.16 states the following about PDUs transmitted as a result of a SNACK:
 
   "The numbered-response(s) or R2T(s), requested by a SNACK, MUST be
    delivered as exact replicas of the ones that the target transmitted originally
    except for the fields ExpCmdSN, MaxCmdSN, and ExpDataSN, which MUST
    carry the current values. R2T(s) requested by SNACK MUST  also carry the
    current values and except for resegmentation (see Section 10.16.3 Resegmentation)."
 
Section 10.16.1 describes Status and Data/R2T SNACK types as:
 
    0-Data/R2T SNACK - requesting retransmission of one or more Data-In or R2T PDUs.
    1-Status SNACK - requesting retransmission of one or more numbered responses.
 
It seems to me that if the target receives a Status SNACK for status sent on a Data-In 
PDU due to phase collapse, the target should send an exact replica of the Data-In PDU.
Similarly, if the target receives a Data SNACK, it should retransmit the Data-In PDU with
the S bit set, since it is a retransmission.
 
I may have misunderstood your recent posting, but I thought it said the target should 
generate a totally new SCSI Response PDU in response to the Status SNACK rather
than retransmitting the original Data-In PDU. And that it should send a Data-In PDU
without the S-bit set in the case of a Data SNACK. Both of these behaviors seem to 
violate what is stated in Sections 10.16 and 10.16.1 of the iSCSI RFC, as quoted above.
 
I would appreciate clarification on the target's expected response in these situations.
 
thanks,
 
Dean Scoville

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Julian Satran
Sent: Monday, October 04, 2004 7:43 AM
To: Eddy Quicksall
Cc: [email-masked]
Subject: Re: [Ips] resending Data-in with S bit set

Eddy, 

This is correct. 
The data-in PDUs don't have to be sent. 
The initiator has to request the data-in PDUs explicitly and MUST do so before it acks the status (that implicitly acks all the data and deletes any record of the command at target). 

Julo 

[email-masked] wrote on 04/10/2004 15:20:56:

> Can you confirm that the intent of 10.16.6. is as follows? 
>   
> If the Initiator has requested for a Status SNACK with BegRun=0 and 
> RunLength=0 (i.e, all unacknowledged status pdus) and the target has
> some Data-In PDUs carrying *status* that have not been acknowledged,
> the target will *not* resend those Data-In PDUs carrying the status. 
>   
> The unacknowledged queue looks like 
>   
>    response(statSN=5) ---> response(statSN=6) -----> Data-In w/S 
> bit(statSN=7) ----> response(statSN=8) 
>   
> The target will resend pdus with statSN 5, 6 and 8. The Data-In with
> statSN 7 will not be resent even though it sends status. 
>   
> Eddy 
>  _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Eddy Quicksall" <[email-masked]>
Date: Tue, 5 Oct 2004 18:08:33 -0400

Maybe my question was misunderstood. To say it another way:

Is it true that a Status SNACK only solicits Status PDUs and that it does not solicit Data-In PDUs which have the S bit set?

I interpret Julian's answer to this as "yes, that is true". 

Eddy
  ----- Original Message ----- 
  From: Dean Scoville 
  To: Julian Satran ; Eddy Quicksall 
  Cc: [email-masked] 
  Sent: Tuesday, October 05, 2004 5:54 PM
  Subject: RE: [Ips] resending Data-in with S bit set

  Julian,

  thanks,

  Dean Scoville
    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]]On Behalf Of Julian Satran
    Sent: Monday, October 04, 2004 7:43 AM
    To: Eddy Quicksall
    Cc: [email-masked]
    Subject: Re: [Ips] resending Data-in with S bit set

    Eddy, 

    This is correct. 

    Julo