RE: Data in SCSI Response or SCSI Data

[John Matze <john.matze@veritas.com>]

Again I have to agree.  Not everyone writing this protocol is developing a
hardware device.  Every time I (or any hardware vendor) sends one less IP
packet down the wire is one less chance of it getting lost.
 

-----Original Message-----
From: Matthew Jacob [mailto:mjacob@feral.com]
Sent: Thursday, August 24, 2000 5:08 PM
To: csapuntz@cisco.com
Cc: 'ips@ece.cmu.edu'
Subject: Re: Data in SCSI Response or SCSI Data





> 
> If I remember the discussion correctly, I remember some folks who
> were implementing hardware did not like having 3 different
> mechanisms for doing the same thing, as this required more logic
> and verification. 
> 
> From a network performance standpoint, there is minimal difference
> between sending two iSCSI messages back-to-back and one larger
> iSCSI message.
> 
> In fact, both iSCSI messages might even share the same packet.

That's a fair point. In other contexts (FC in this case), I've really liked
being able (in target mode) to send back data && status in packet- it means
I
don't have to manage multiple resources on the send side, and in the case of
sending back canned data for 'trivial' commands (like Mode data), I don't
even
have to do a context or thread switch.

What this might like like in an IPS implementation is not clear to me, but I
believe I do see the point about the h/w implementation issues.

It's not clear to me that you can state as a general rule that two packets
back-to-back is minimally different- not from a performance point of view,
but
from a likelihood of lossage and retransmit. If a high proportion of your
trivial (or not so trivial) read commands come back in one frame, that's a
lot
better than managing lost frames, no? 

-matt