Re: Symmetric vs Asymmetric

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

Pierre,
I am not sure that you factored in Immediate/Unsolicited Data into your
argument.

.
.
.
John L. Hufferd



Pierre Labat <pierre_labat@hp.com>@ece.cmu.edu on 09/11/2000 04:08:29 PM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: Symmetric vs Asymmetric



1) I don't like the asymmetric model because when solving the
synchronization
of the commands by sending the commands on a same TCP connexion,
it just moves the synchronization problem in an other place :
how to synchronize the commands and their data (pb described but Matt
and Somesh).

2)The advantage of the asymmetric model (when two connections at least):

"avoid the problem of commands flow controlled by large transfer of
data"
is not an advantage compared to the symmetric model. Because to do so
the asymmetric model needs at least two connections. In this case,
the symmetric model could avoid this problem too :
   - opening two TCP connections one for the normal command
(read/write,...)
        and a second one for the urgent commands (task management
etc...)

3) As stated it seems that we
  needs a flow control of the commands because if we use the SCSI
  one (TASK SET FULL) the traffic we will instable and composed of
  a sequence of bursts with regularly a full
 RoundTripTime*Throughput/size of a command
  number of commands to retry.
  The command window in the iSCSI draft seems not to be a good
  mechanism to flow control the commands, because if there is a mix
  of slow and fast commands, the result will be a task set half full
  but a window closed, hence the traffic blocked.
   Why not replace in the draft the  "MAXCmdRN" by a credit that is a
number
   of commands in flight allowed (not yet completed) independent of the
"CmdRN"?
   Doing that, the  flow will not be blocked by a slow command but will
   blocked only upon the filling of the task set.


Pierre