|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Flow ControlMatt, Review the present means of control. The SCSI model is as follows: Domain | ----------------------------------------- | | SCSI Device Fabric | | --------------------------------------- | | | | | Target Initiator Service Delivery Port | | --------------- Application | | Task Manager Logical Unit The SCSI concept of device encompasses target, initiator and service delivery port as sub-systems. The service delivery port is the means to extend this model into a client/server environment. In reality, although it is possible to make the many sub-systems beneath the iSCSI target conform to this model as a single target, the proposal pays a high price for this. Flow control defined within the iSCSI proposal is based on this now massive target. There is no resolution of control at the actual sub-systems that compose this virtual target. There have been many to suggest the number of units contained within such an iSCSI server to be in the thousands and this should be possible. Flow control, however, must resolve at the internal medium within the system. It can not if treated in a global fashion as done with the iSCSI proposal. Flow control should not resolve to the connection or even this virtual target. Such a virtual target will not scale as flow control must resolve to the internal medium. (The REAL line above Target, Initiator and Service Delivery Port.) Doug > "GUPTA,SOMESH (HP-Cupertino,ex1)" wrote: > > > I agree. The only difference of opinion I have is whether the > > credit/window should be on a per connection basis or a session > > basis. > > Since the "commands" go across the various TCP connections, but > ultimately > end up in the same single command queue, what does command > credit/window per > TCP connection buy you? > > -Matt >
Home Last updated: Tue Sep 04 01:06:42 2001 6315 messages in chronological order |