RE: a vote for asymmetric connections in a session

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

Joshua, Charles,

I am not sure how to reply to you, but let me try.

I think we are combining several items (perhaps layers) together in this
discussion.

Again, without going into all the details (and whether they were right or
wrong) the reason for the Sliding Window was as Julian stated.

Now without the need to recover  from the problem of failures in another
connection,  the sliding window is not needed for what it was setup to do.

I could be mistaken here but I think you, and some others have been
addressing issues with the Storage Controller having the right amount of
buffer space in the controllers for the commands, after they are delivered
by iSCSI.  I think this is a SCSI issue and not a iSCSI/TCP flow control
problem.

Originally we were trying to solve a set of problems that were caused by
the Symmetric model which (for this discussion) was independent of memory
problems caused by receiving the commands from iSCSI.  We were concerned
with memory problems that might be caused by either the subset of memory
allocated to iSCSI, or the memory available on the NIC at the Target
(perhaps also the Initiator).

With respect to the Asymmetric approach,  the issues change, and we are no
longer trying to solve the problem of missing commands that occur  because
of a broken connection.  Therefore, I think we can dump the sliding window
and leave the flow control -- and recovery  of lost commands,  --  up to
TCP.  Yes, the SCSI layers on each end need to have their own buffer
management under control, but I do not think this is a transport issue.

.
.
.
John L. Hufferd



Joshua Tseng <jtseng@NishanSystems.com>@ece.cmu.edu on 09/07/2000 11:14:08
PM

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


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



John,

TCP provides congestion management for the network.  The command windowing
mechanism is supposed to provide congestion management for the target's
command
queue, I presume.  Another way to describe it is command flow control.
Well,
TCP will NOT fulfill this role unless iSCSI can actively tell TCP to halt
ACK
responses for TCP segments.  Now, I don't think anybody is advocating this
(right???).

I do not know if a command flow control mechanism is necessary, but I do
believe that the existing sliding window mechanism is a whole lot of work
to
do something that can be accomplished more easily by other means.

Josh

-----Original Message-----
From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
Sent: Thursday, September 07, 2000 4:29 PM
To: ips@ece.cmu.edu
Subject: Re: a vote for asymmetric connections in a session


Folks,
Matt and Julian are correct.  The sliding window was put in for a
completely different reason then is currently being discussed.  I suggest
that we all  look at it only as it was originally intended and then see if
something else needs to be done, or not.  TCP/IP probably handles all the
other issues (well enough).


.
.
.
John L. Hufferd



"Matt Wakeley" <matt_wakeley@agilent.com>@ece.cmu.edu on 09/07/2000
03:46:53 PM

Please respond to Matt Wakeley <matt_wakeley@agilent.com>

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


To:   ips@ece.cmu.edu
cc:
Subject:  Re: a vote for asymmetric connections in a session



As Julian has stated in a different thread, the purpose of the "sliding
windows" in iSCSI is not for congestion management.  It is simply there to
handle the case where if a connection goes down in a multiple connection
session, it prevents the remaining connections from overwhelming the target
with new commands that it can't process due to missing commands that where
on
the broken connection.

Since all of this runs on top of TCP, and TCP performs congestion
management,
why must iSCSI perform congestion management on top of TCP?

-Matt Wakeley
Agilent Technologies

Scott Bradner wrote:

> > Implementing sliding windows is not that hard
>
> note that the issue is not "just" sliding windows - ips also has to deal
> with congestion TCP-friendly way - that can get quite complicated
>
> Scott