Subject: [Ips] Target Behavior Clarifications

From: <[email-masked]>
Date: Mon, 17 Apr 2006 16:48:49 -0500

A couple of quick questions?

1) What should the behavior of a target be if it receives a PDU on a
connection, larger than what it declared with MaxRecvDataSegmentLength:
- If the PDU is part of a SCSI command? 
- If the PDU is part of a login?

2) What should the target behaviour be if the initiator sends it more
data than MaxBurstLength?

3) What should the target behavior be if the initiator sends more data
than FirstBurstLength?

Any clarification would be greatly appreciated. 

Thanks,
Jacob

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

---

From: Julian Satran <[email-masked]>
Date: Tue, 18 Apr 2006 09:12:10 +0300

> - If the PDU is part of a SCSI command? 
protocol error but you will have also to terminate the SCSI command
> - If the PDU is part of a login?
The MaxRecvDataSegmentLength is not "fixed" untill login is finished so 
the target must be ready to accept the default length.
> 2) What should the target behaviour be if the initiator sends it 
> more data than MaxBurstLength?
As above
> 3) What should the target behavior be if the initiator sends more data 
than 
> FirstBurstLength?
that is specially bad as the target may have already issued R2Ts - drop 
the session but terminate the command.

---

From: William Studenmund <[email-masked]>
Date: Tue, 18 Apr 2006 10:32:51 -0700

On Apr 17, 2006, at 2:48 PM, <[email-masked]>  
<[email-masked]> wrote:

> 1) What should the behavior of a target be if it receives a PDU on  
> a connection, larger than what it declared with  
> MaxRecvDataSegmentLength:
>

Drop the connection. Note, the session may still stick around as part  
of recovery processing.

Also, during login (before FFP), the MaxRecvDataSegmentLength in  
force is 8k, regardless of announced values.

> 3) What should the target behavior be if the initiator sends more  
> data than FirstBurstLength?
There are specific sense and ASC/Q values for these errors.

These are treated as SCSI errors 1) because you have to give some  
explanation for why you killed the SCSI task, and 2) because it is  
not obvious which PDU in the burst was "too much." While you might  
want to say it was the last one, that isn't necessarily true.

Note also that to trigger these errors, all the data placement had to  
stay within the TTT bounds and you have to be in DataPDUInOrder=No.  
That's the only way you can really write the same area twice. Most  
other errors involved in sending too much data in a burst would  
trigger an iSCSI protocol error by placing data outside the bounds of  
the TTT.

Take care,

Bill