Re: a vote for asymmetric connections in a session

[julian_satran@il.ibm.com]

A note of caution. The most serious dead-lock sitaution we are aware of
steams from a mix of RTT (or should we call it R2T to accommodate Doug
Ottis?) and unsolicited/immediate data.
If channels are full with unsolicited data and the target requests
something else
- that something else will not get through. This dead-lock, as far as I can
tell exists in all
transports. A target should be able to detect it and iSCSI has provided for
the target
to be able to drop data and reclaim them later with R2T.
To minimize the chances for it we are also not providing for switching
between operating modes (R2T mandatory or not).

Julo

"John Hufferd/San Jose/IBM" <hufferd@us.ibm.com> on 08/09/2000 18:42:12

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

To:   "Randall R. Stewart" <randall@stewart.chicago.il.us>
cc:   ips@ece.cmu.edu (bcc: Julian Satran/Haifa/IBM)
Subject:  Re: a vote for asymmetric connections in a session





Randall,
Your head-of-line blockage statement, is of course true, but you say it
like it is a bad thing.  I am not sure it is.

In the Asymmetric configuration, there is a different TCP/IP connections
from each Host to a Storage Controller to handle the Commands from that
Host to the Storage Controller (or at least that Storage Controller's
Port).  Each Host has SCSI commands that are not related to the commands in
other hosts flowing to the same Storage Controller (port) but on separate
TCP/IP connections.  They expect to have their commands handled in some
"fair" allocation method, with respect to, the other Hosts.  Nothing is
blocking its "line" except its own Commands.  So TCP/IP has delivered, or
brought up to be delivered, each Hosts commands independently.  Now it is
up to the Target SCSI layer to chose which port/interface from which to
bring additional commands into its buffers.  I do not see this as an
important problem, and is the way things have worked regardless of the
storage connections, for as long as we have had storage connections.  It
was true on the SCSI buss, and it was even true on the Old IBM 360s (and
continues to this day on the mainframes).  There will always be back
pressure and sooner or later it causes the Initiator to stop sending new
packets, since they are not being acknowledged, this will either occur at
the TCP/IP layer or at the SCSI layer.

I am not sure that this is a bad thing, especially since we are not talking
about dead locks.



.
.
.
John L. Hufferd



"Randall R. Stewart" <randall@stewart.chicago.il.us>@ece.cmu.edu on
09/08/2000 04:58:06 AM

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


To:   Charles Monia <cmonia@NishanSystems.com>
cc:   Matt Wakeley <matt_wakeley@agilent.com>, ips@ece.cmu.edu
Subject:  Re: a vote for asymmetric connections in a session



Charles Monia wrote:
<snip....snip>
> I'm not sure what is meant by "congestion."  If we're talking about
> congestion in the TCP/IP transport, I'm in agreement.  However, I thought
we
> were referring to the sort of congestion that  the application on top of
> iSCSI might see if it received more commands than it had room for.
>
> Unless I misunderstood your point, threfore, I think there might be an
> issue. The only way I can see flow control in the tranport layer being
used
> to avoid dropping commands is if higher layer congestion results in back
> pressure to the iSCSI pipe.  I believe that behavior is undesirable
because
> it introduces "head-of-line" blocking, with the following consequences:
>

Any time you get ANY retransmissions in TCP you will create a
"head-of-line"
blocking scenario. This does not matter if it is from flow control as
you state or network congestion where a packet is dropped by a router.
You will have situations where the TCP is holding data waiting for the
retransmissions of an earlier packet... this is one of the reasons
that sigtran developed SCTP...


> a) It effectively shuts down the flow of commands to all logical units.
>
> b) It blocks the flow of task management commands (Abort Task, Clear task
> set, etc).
>
> <snip...snip>
>
> Charles Monia
> Senior Technology Consultant
> Nishan Systems Corporation
> email: cmonia@nishansystems.com
> voice: (408) 519-3986
> fax:   (408) 435-8385

--
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222 (cell) 815-477-2127 (work)