RE: profiles - a way to simplify iSCSI

["Somesh Gupta" <someshg@yahoo.com>]

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Matt Wakeley
> Sent: Friday, June 22, 2001 1:57 PM
> To: ips@ece.cmu.edu
> Subject: Re: profiles - a way to simplify iSCSI
>
>
> The whole purpose for creating iSCSI in the first place (by the group that
> started it) was to create a storage interconnect that could take
> advantage of
> the very high performance promised by 10GBE, at low cost.

And share a common infrastructure (including common adapters) with
all other data center apps such as NAS, http etc.

> Mutliple
> connections per session is there to take advantage of the 10GBE
> link with the
> shortcomings of TCP,

How? By skipping around the congestion control algorithms? What
about the other flows in the network?

> and markers are there to eliminate the cost of memory
> subsystems required to buffer out of order TCP frames.

Framing has other benefit but not having a fast memory
system cannot be avoided (especially if the inrastructure
is to be common.) Also markers and CRCs do not mix well
together.

> Eliminate
> these, and
> you've you'll capitulate to Fibre Channel for anything but slow storage
> connects.

I don't think so. The pull of a common infrastructure will
be too strong. And in case you have not looked lately,
memory is getting fast enough and cheap enough. The GigaHz
PCs are driving this.

Somesh

>
> -Matt
>
> John Vrabel wrote:
> >
> > > It's time to start thinking about what we can take out ...
> >
> > I fully agree with the need to limit options, and avoid the need for
> > profiles.
> >
> > FWIW, our list of things to remove:
> >
> >      1) Markers
> >
> >      2) SNACKs
> >
> >      3) Command retries
> >
> >      4) Async Messages
> >
> >      5) Multiple connections per session
> >
> > Things to change:
> >
> >      1) default number of connections from 8 to 1 ( if multiple
> connections
> > remain )
> >
> >  Things I'm less sure about:
> >
> >      1) InitialR2T, ImmediateData.  Do they really need to be
> negotiable?
> >          FirstBurstSize  controls them to a great extent.
> >          Can InitialR2T be removed, and retain ImmediateData for short
> > writes ?
> >
> > John Vrabel


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com