RE: Data in SCSI Response or SCSI Data

[Robert Snively <rsnively@Brocade.COM>]

While networks lose packets, TCP/IP connections never do, so you
should not see this as a problem at the iSCSI layer.  If you can
lose packets at the iSCSI layer, then having to guess at whether the
recovery will involve two kinds of information units or one kind of
information unit seems like an unnecessary complexity.  

This should be kept simple, providing one kind of information in 
a packet, thus making it simpler to implement hardware that can
route the information directly to the appropriate memory space.

If the overhead of preparing and sending two packets instead of one
is burdensome, then we have that problem to solve as well.

Bob Snively
Brocade Communications           Phone  408 487 8135
1901 Guadalupe Parkway
San Jose, CA 95131               Email   rsnively@brocade.com


>  -----Original Message-----
>  From: John Matze [mailto:john.matze@veritas.com]
>  Sent: Thursday, August 24, 2000 11:29 PM
>  To: 'ips@ece.cmu.edu'
>  Subject: RE: Data in SCSI Response or SCSI Data
>  
>  
>  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
>  
>