RE: StatSN question

Eddy,

The iSCSI initiator that we have confirmed sends updated
ExpStatSN before receiving all of the data is from SourceForge.
The name of the project on SourceForge is "linux-iscsi".
The version that we looked at the source code for is 4.0.2.

I also had a mistake in my detailed example.  The Initiator
negotiated a 128K MaxRecvDataSegmentLength instead of the
256K I mentioned.  That doesn't change anything since the
command that turned up the issue was a 128K Read.

Ken Craig

-----Original Message-----
From: Eddy Quicksall [mailto:[email protected]] 
Sent: Wednesday, May 23, 2007 5:50 AM
To: Ken Craig; Sandars, Ken; [email protected]
Subject: Re: [Ips] StatSN question


It would behoove all of us if the initiator was fixed. We should not be 
adding code to overcome a bug in the initiator especially if it is hard
to 
detect.

Can you tell us the initiator so we can run tests too?

Eddy
----- Original Message ----- 
From: "Ken Craig" <[email protected]>
To: "Sandars, Ken" <[email protected]>; <[email protected]>
Sent: Monday, May 21, 2007 1:16 PM
Subject: RE: [Ips] 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


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