Subject: RE: iSCSI reqmts and Ethernet adapters

From: [email-masked]
Date: Tue, 24 Apr 2001 15:11:23 -0400

> The only aspect that I was requesting was the iSCSI requirements
> document adds a requirement to seek this common structure for hardware
> support.  You say it is not practical.  I differ with that opinion.

A sentence equivalent in strength to the following sentence
from the IPS WG charter is acceptable:

  The WG will consider whether a layered architecture providing
  common transport, security, and/or other functionality for its
  encapsulations is the best technical approach.

Anything stronger risks linking the protocol encapsulations
in a way that has the potential to cause enormous procedural
headaches.  Common framing work will take place in TSVWG and
can be incorporated by reference to a TSVWG document if
appropriate. 

As for iSCSI on SCTP -- "Send Draft".

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 25 Apr 2001 15:09:42 -0700

iSCSI will not compete with other SCSI transport speeds unless

- significant portions are implemented in hardware

AND
-there is some method of regaining framing in the TCP byte stream to enable
direct iSCSI data placement.

I believe this is sufficiently stated in the iSCSI requirements doc.

Although it is admittedly hard to extract from Doug's long emails, he does
bring up one painful point - even though there are several factual errors
sprinkled throughout that last email.  

The point I chose to extract is that given the first two facts, it is
extremely important to have coordination and attention between the two
efforts (iSCSI definition and framing solution definition).  

Doug states:
> Presently you wish to see this done in a haphazard manner without any
> coordination by the IETF.  This attitude does not reflect the 
> magnitude of this endeavor.

I sympathize with Doug's frustration.  It's a chicken and egg problem that
may cripple iSCSI implementations.  On the one hand, iSCSI definition must
proceed today in order to deliver the specification in a reasonable
timeframe, and a framing solution must proceed in parallel.  On the other
hand, without proper architecture of current iSCSI for a framing solution,
iSCSI may have to be reinvented to perform at 10Gig speeds.  This keeps me
up at night :-)

Another valid point Doug made is that iSCSI, FCIP, and iFCP all have the
same framing needs and should all use the framing solution.  That
recommendation certainly seems sane and within the scope of this WG to
oversee.  Last time I paid attention, FCIP and iFCP were trying to reinvent
this wheel.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked]

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Fri, 27 Apr 2001 15:50:38 -0700

I'm assuming Charles is implying that he doesn't expect to have the memory
and memory bandwidth limitations of an adapter?  FCIP and iFCP are
switch-sized applications, not NIC card-sized?

Marj 

> > The encapsulation proposal is devoid of techniques for 
> > framing.  How do you
> > expect to see this lack of framing resolved?  Do you expect 
> > to use this
> > adapter and not have a means for framing?
> > 
> 
> No, I don't expect to use any adapter.
> 
> Charles

---

From: Charles Monia <[email-masked]>
Date: Fri, 27 Apr 2001 16:01:33 -0700

Hi Marj:

See below.

> -----Original Message-----
> From: KRUEGER,MARJORIE (HP-Roseville,ex1)
> [mailto:[email-masked]]
> Sent: Friday, April 27, 2001 3:51 PM
> To: 'Charles Monia'; 'Douglas Otis'; [email-masked]
> Subject: RE: iSCSI reqmts and Ethernet adapters
> 
> 

Yes, that's true. We also don't plan to use a seperate adapter as the Gbe
interface for our box, so we wouldn't even indirectly benefit from the
adapter's being able to do framing.  I'm pretty sure that's true for the
FCIP folks as well.  I assume that's what Doug was getting at.

Charles

---

From: Charles Monia <[email-masked]>
Date: Fri, 27 Apr 2001 18:43:13 -0700

Hi:

Are you doing any product development?  If so, it might be even more
productive to share your first hand insights instead of lecturing others.

Charles
> From: Douglas Otis [mailto:[email-masked]]
> Sent: Friday, April 27, 2001 5:21 PM
> To: Charles Monia; 'KRUEGER,MARJORIE (HP-Roseville,ex1)';
> [email-masked]
> Charles,
> I suspect that I made too great a generalization with respect 
> to networking
> in describing hardware as adapters.  If you feel you efforts 
> are in such a
> niche market as not to warrant the consideration this effort 
> has on other
> networking, then perhaps your application is not of a 
> significant concern.
> You would make a good politician.  I suspect however we would 
> make better
> progress openly discussing this framing issue as it relates to IPS.
> 
> As this was once a hot issue, I don't think it was solved by not doing
> anything in this area.  As you are running high data rates, 
> you will be
> sensitive to packet loss on longer links as will the next.  
> The need to do
> framing is important.  This need is no less important for 
> your application.
> Having a proprietary solution for a specific application was 
> my concern.  If
> we do not make headway in this area quickly, each solution will be
> proprietary.
> 
> Doug
> 
> > Hi:
> >
> > Please see below.
> >
> >
> > > From: Douglas Otis [mailto:[email-masked]]
> > > Sent: Wednesday, April 25, 2001 5:38 PM
> > > To: Charles Monia; 'KRUEGER,MARJORIE (HP-Roseville,ex1)';
> > > [email-masked]
> > > Charles,

---

From: [email-masked]
Date: Fri, 27 Apr 2001 22:40:19 -0400

I think this thread needs to end here.  As noted earlier,
there are a couple of framing mechanism drafts pending
before TSVWG.  Work on TCP framing applicable to any protocol
using TCP is in TSVWG's domain, *not* IPS's.  I would suggest
that further use of list bandwidth to complain about that
assignment of responsibility is counterproductive - I
would suggest contacting the Area Directors directly.
In practice, if TSVWG progresses a suitable framing draft
in a timely fashion, all the IPS protocols can pick it
up by reference.  I've shown up in TSVWG in the past to
help explain why IPS believe this to be important, and
will continue to do so.

In addition to directing further complaints about the assignment
of responsibility for framing to TSVWG and/or the Area Directors,
I would ask Doug Otis to refrain from commenting on implementations
with which he's not familiar or assuming that his implementation
approach is the only feasible/viable one.  Both of these have
caused unnecessary irritation and problems on the list in the
recent past, and have contributed to the large volume of recent
messages.

Any replies to this message should be sent DIRECTLY to me -
DO NOT REPLY TO THE LIST!

Thanks,
--David