Subject: RE: profiles - a way to simplify iSCSI

From: John Vrabel <[email-masked]>
Date: Fri, 22 Jun 2001 17:43:43 +0200

> 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

---

From: Mark Bakke <[email-masked]>
Date: Fri, 22 Jun 2001 13:02:02 -0500

We've been thinking about how to profile iSCSI implementations
as well, and Paul Congdon, Matthew Burbridge (both of HP) and
I have come up with a spreadsheet that sort of follows the PICS
pro-forma that the IEEE folks use.  Anyway, it appears that this
might be a useful thing to start discussing.  We have attempted
to list the major mandatory and optional features, but have not
had enough review time yet to guarantee that it exactly matches
the spec, so comments are welcome.

Julian has placed it on his web page at:

http://www.haifa.il.ibm.com/satran/ips/iSCSIv6_PICs-5.pdf

I apologize that this is not in internet-draft form, or if this
list is not exactly the right place to do this.  However, I think
that it will help show the sheer number of optional features we
are faced with, and may help us prioritize what must stay in the
protocol, and what we could live without in the interest of
simplicity.

Hopefully, this will help.

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "Matt Wakeley" <[email-masked]>
Date: Fri, 22 Jun 2001 13:56:57 -0700

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.  Mutliple
connections per session is there to take advantage of the 10GBE link with the
shortcomings of TCP, and markers are there to eliminate the cost of memory
subsystems required to buffer out of order TCP frames.  Eliminate these, and
you've you'll capitulate to Fibre Channel for anything but slow storage
connects.

-Matt

---

From: Mark Bakke <[email-masked]>
Date: Fri, 22 Jun 2001 15:59:06 -0500

Just noticed that we did not include descriptions for the
columns in the spreadsheet.  Here they are:

1st column - Section number of an internet-draft version
of this spreadsheet, which we will generate if needed.

2nd column - Category; we divided up the different features
into some categories that made sense to us.  The first set
is common to all iSCSI implementations; the second and third
are for those features that apply just to targets or initiators.

3rd column - Feature; short description of each feature.

4th column - Reference; a reference to the section number of the
iSCSI document that best describes the feature and its status.

5th column - Status.

   M = Mandatory
   O = Optional
   R = Recommended (we have none of these now)
   X = Prohibited (we have none of these, either)

   If numbers appear after the status, e.g. M:4.5, it means that
   the feature is mandatory if the feature numbered 4.5 is
   implemented.  I just noticed that some of our numbers had changed,
   so a few of these might still be typos.

6th column - Value.  This is used if the feature is more than just
a check box; for instance, if an implementation supports "Data Digest - Other",
it is used to indicate some reference to what "other" means.

Hope this helps,

Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Mark Bakke <[email-masked]>
Date: Fri, 22 Jun 2001 15:59:06 -0500

5th column - Status.

   M = Mandatory
   O = Optional

Hope this helps,

Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "Somesh Gupta" <[email-masked]>
Date: Fri, 22 Jun 2001 16:38:59 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Matt Wakeley
> Sent: Friday, June 22, 2001 1:57 PM
> To: [email-masked]
> Subject: Re: profiles - a way to simplify iSCSI
>
>
> 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
> 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

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

> >          Can InitialR2T be removed, and retain ImmediateData for short

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

---

From: "Matt Wakeley" <[email-masked]>
Date: Fri, 22 Jun 2001 19:14:20 -0700

Somesh Gupta wrote:

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

Nobody said anything about skipping around congestion control.
TCP was not designed for the fast links that are available today, so
you'll probably need more than 1 connection to attain link rate.
Whether you have 1 or a thousand connections, congestion control
will still work (or else it's fundamentally broken anyway).

> is to be common.) Also markers and CRCs do not mix well

How do they not mix well?

> memory is getting fast enough and cheap enough. The GigaHz

Until memory becomes "free", iSCSI implementations will always cost more than
FC implementations that do not require memory

-Matt

---

From: "Somesh Gupta" <[email-masked]>
Date: Tue, 26 Jun 2001 14:52:40 -0700

Been busy elsewhere a while.

> Sent: Friday, June 22, 2001 7:14 PM
> To: [email-masked]

  Can you please specify what you mean by TCP not being designed
  for fast links (anything other than the congestion avoidance
  alogorithm)

> FC implementations that do not require memory

The question of economics is much wider in scope than whether
you have additional $10 (or whatever) worth of memory. First you look at
the solution cost, of which hardware probably forms less
than a 1/3rd of the cost. Then you go down to specific
components and below. Then you see the economies of scale etc.
How many chips is your R&D cost spread across etc etc.
So to focus on a specific amount of memory at a particular
point in time is not the right way to look at it.