Re: a vote for asymmetric connections in a session

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

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)