|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: a vote for asymmetric connections in a sessionJulian, I think I understood what you said in the context of the Symmetric model , but could you please take me through how this would occur in the Asymmetric when you have at least two connections? I had thought, perhaps incorrectly, that the immediate data went with the command, thereby leaving the other connections, in the Asymmetric case, free for solicited data? Or Perhaps I miss understood your statement. . . . John L. Hufferd julian_satran@il.ibm.com@ece.cmu.edu on 09/09/2000 12:33:05 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: a vote for asymmetric connections in a session 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)
Home Last updated: Tue Sep 04 01:07:26 2001 6315 messages in chronological order |