RE: StatSN question

Ken,

My iSCSI Target has been working for the last
couple of years with all of the Initiators I
have been able to get a hold of.  I guess I
should have been more explicit in my example.
The Initiator negotiated a 256K
MaxRecvDataSegmentLength of 256K then sent a
128K Read command which allowed me to send all
of the data in one PDU.  The DATA IN PDU had
the Status and Final bits set with Command
Status of Good.  It wasn't until I had a
situation where a few of the Ethernet Frames
with the rest of the data for this particular
DATA IN PDU were stalled for ~.5 second (due
to what I think was the Initiator not opening
up its window size) that the problem was seen.  

Ken Craig

-----Original Message-----
From: Sandars, Ken [mailto:[email protected]] 
Sent: Sunday, May 20, 2007 7:34 PM
To: Ken Craig; Eddy Quicksall; [email protected]
Subject: RE: [Ips] StatSN question


Hi Ken,

Interesting initiator. If it is truly issuing an ExpStatSN which
acknowledges a response which has not been sent by the target, the
implementers should be directed to section 3.2.2.2 of RFC3720.

Is it possible that the target is not initialising its StatSN counter
correctly? Your example refers to a StatSN of 0 for the Data-In PDU
(which I am assuming also has the S bit set). Have a read of section
10.13.4 and ensure the target is incrementing StatSN correctly.

HTH,
Ken

-----Original Message-----
From: Ken Craig [mailto:[email protected]] 
Sent: Saturday, 19 May 2007 02:47
To: Eddy Quicksall; [email protected]
Subject: RE: [Ips] StatSN question

Eddy,

Thanks for the response.  I've got an Initiator that is updating
ExpStatSn before receiving all of the data.  I consider that Initiator
to be broken but since the RFC doesn't specifically state what you said
I've got no choice but to find a way to deal with it.

Ken Craig

-----Original Message-----
From: Eddy Quicksall [mailto:[email protected]]
Sent: Thursday, May 17, 2007 10:03 PM
To: Ken Craig; [email protected]
Subject: Re: [Ips] StatSN question


It would mean the header and data has been received. The reason is
because 
the target can use ExpStatSN to free the resources used to send the
Data-in. 
At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there
was 
argument given once that the TCP ACK may not really indicate that the
data 
was received and hence the ExpStatSN would be used for that purpose (I
don't 
really remember that well though).

Eddy

----- Original Message ----- 
From: "Ken Craig" <[email protected]>
To: <[email protected]>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=0, send a
DATA IN PDU with FINAL=1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


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


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


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