RE: a vote for asymmetric connections in a session

[julian_satran@il.ibm.com]

That is correct. The window was put to limit the size of the command set
waiting for de-skewing. At thew same time - aware of the possible large
amounts of unsolicited data
accompanying them we added the "RTT should be always be supported"
statement to allow a target to drop data and reclaim it later through RTT.

Julo

"John Hufferd/San Jose/IBM" <hufferd@us.ibm.com> on 09/09/2000 09:36:43

Please respond to "John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>

To:   Joshua Tseng <jtseng@NishanSystems.com>
cc:   ips@ece.cmu.edu (bcc: Julian Satran/Haifa/IBM)
Subject:  RE: a vote for asymmetric connections in a session




They are not out of order, you need to reread his note.

.
.
.
John L. Hufferd


Joshua Tseng <jtseng@NishanSystems.com> on 09/08/2000 08:53:41 PM

To:   John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  RE: a vote for asymmetric connections in a session



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