RE: iSCSI: Session Partial Resolution

["Douglas Otis" <dotis@sanlight.net>]

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Matt Wakeley
> Sent: Wednesday, September 20, 2000 10:38 PM
> To: Reflector, IPS
> Subject: Re: iSCSI: Session Partial Resolution
>
>
> Douglas Otis wrote:
>
> > Matt,
> >
> >
> > > The "iSCSI Requirements" document requires this capability:
> > >
> > > "[R] High bandwidth, bandwidth aggregation.
> >
> > This is a general feature of IP.
>
> No, it's not.  Please go back and read Randy Haagens' memo from August 5,
> available here
>  http://ips.pdl.cs.cmu.edu/mail/msg00412.html
>
> >
> >
> > > [D] The bandwidth (transfer rate, MB/sec) supported by storage
> > > controllers is rapidly increasing, due to several factors: (1)
> > > Increase in disk spindle and controller performance;
> >
> > The linear increase in the performance of the mechanical aspects of the
> > drive have not kept pace with the exponential data density improvements.
> > Unless dealing with a single massive transfer, the overall
> effect of data
> > density improvements is a small reduction in latency lost by the large
> > latency within a MAN network.
>
> We are not talking about drive controllers, we're talking about
> storage array
> (raid) controllers, where there is lots of drives behind it.
>
> I don't think anyone considers attaching individual disk drives
> to the internet
> (we'd very quickly run out of IP addresses).

Matt,

It depends on how you make the connection.  You should review my draft.  You
will not get the performance  expected with an architecture as you propose.
A bad idea.  With SCTP you can drop into 10.xx.xx.xx space.  What do you
mean not enough IPs?  iSCSI is not a good way to aggregate as it requires a
stateful bridge into drives.  Are you really advocating placing a controller
behind 5 ms+ latency?  The impact on drive performance would be far less
noticeable as the controller already hides much of the latency.  But I guess
you have a better idea?

Doug

> (2) Use
> > > of ever-larger caches, and improved caching algorithms;
> >
> > Network latency negates use of remote caching.  Such caching
> must be near
> > the client and not the drive.  If you wish to define a controller
> > specification, this should be done using appropriate
> technologies.  Clearly,
> > if the controller is on site, interface requirements change
> substantially.
> > For redundancy, there may even be one per client system! Now the traffic
> > that needs some work would be to ensure such controllers stay
> synchronized
> > if used in a cluster.  Either way, you will not see a higher performance
> > moving the controller next to the drive.
> >
> > > (3)
> > > Increased scale of storage controllers (number of supported
> > > spindles, speed of interconnects). Not only must the iSCSI
> > > provide for full utilization of available link bandwidth, it
> > > also must exploit parallelism (multiple connections) at the
> > > device interfaces and within the interconnect fabric."
> >
> > Again, this is a general feature of IP.  If access is to the
> drive, as it
> > should be, there is no problem scaling especially if you are using IP.
> >
> > > Unless there is "consensus" that this is not required, I think
> > > the multiple
> > > connections/session must remain.
> >
> > Not one reason for forcing aggregation into a single connection.  If you
> > wish to bind multiple adapters, IP supports this.  I doubt you will ever
> > need to do this however.
>
> I'm not going to try and convince you of the need for iSCSI link
> aggregation,
> and how IP does not support this.  Bottom line is that major
> system and storage
> vendors such as HP think we need it.  Once again, re-read Randy's message.
>
> >
> >
> > Doug
>
> -Matt
>