Re: a vote for asymmetric connections in a session

[Mike Kazar <kazar@spinnakernet.com>]

I don't think that was Costa's point: he was explicitly talking about 
commands coming in out of order, and that the receiver was waiting for a 
command with an earlier sequence number.

My understanding is that handling this type of resequencing is important in 
the symmetric model, where you have N pipes of commands arriving in pretty 
much random order, and limited capacity to buffer requests received out of 
order.  In the assymetric model, since all commands are coming in on one 
channel, with only data using the other connections, this problem does not 
occur, and iSCSI sequence numbers are no longer needed (at least for this 
particular purpose).

         Mike

         (kazar@spinnakernet.com)

At 10:24 PM 9/8/00 -0700, you wrote:
>I think Costa's point is in the asymmetric single connection model:
>
>The target has room for 3 commands.
>The initiator sends 3 commands, followed by data, followed by a 4th command.
>The target could stop reading the TCP connection because the command queue is
>full, because it doesn't know that data is next on the TCP connection.  It has
>to assume that a 4th command is coming, and it doesn't have room for it.
>
>Another case for a "command" tcp connection and a separate "data" connection
>(minimum of two TCP connections per session).
>
>-Matt
>
>Joshua Tseng wrote:
>
> > I don't get it.  Maybe I'm dumb or something, but I thought the whole
> > point of asymmetric was that commands wouldn't arrive out of order.
> >
> > Josh
> >
> > -----Original Message-----
> > From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
> > Sent: Friday, September 08, 2000 4:22 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: a vote for asymmetric connections in a session
> >
> > I do not know how reasonable Costa's configuration is,in the real world,
> > but he has brought up a point that, I think, might be important to address.
> > If his example is reasonable, then it would suggest that we NEED to enforce
> > the requirement of Two connections per Session in the Asymmetric case.
> > What do you all think about this?
> >
> > .
> > .
> > .
> > John L. Hufferd
> >
> > csapuntz@cisco.com@ece.cmu.edu on 09/08/2000 01:01:04 PM
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> > To:   ips@ece.cmu.edu
> > cc:   csapuntz@cisco.com
> > Subject:  Re: a vote for asymmetric connections in a session
> >
> > If I recall correctly, the windowing mechanism was put in to avoid
> > a deadlock condition while using multiple control connections.
> > I believe the logic went as follow:
> >
> > Assumption: You're not allowed to drop commands arriving in on any
> > connection
> >
> > Because the TCP connections work at different rates, commands
> > may not arrive in order. Let's say you have four connections and
> > a command queue depth of 3. Commands #2,#3, and #4 arrive before command
> > #1,
> > filling the queue. However, the queue cannot be drained
> > until command #1 arrives. So, deadlock.
> >
> > Solution: Allow commands to be dropped
> >
> > In the example above, we'd probably drop command #4 and replace it
> > with command #1.
> >
> > Note that using a single TCP connection for control/data is not
> > sufficient to solve the problem.  Imagine the case that the queue is
> > depth 3 and the host issues four WRITES commands in quick order.
> >
> > The device stops reading the TCP connection after three commands.
> > Unfortunately, none of those three writes can complete until
> > data is read from that connection! So, deadlock again.
> >
> > CIFS, NFS, and HTTP don't have this problem because they immediately
> > send data after their WRITE commands.
> >
> > -Costa