|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Flow Control
Matt,
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 |