RE: new iSCSI draft - 02.txt

["David Peterson" <dap@cisco.com>]

The point is (whether you use an mbuf/mblk/zbuf/socket buffer or whatever)
some type of manipulation will be required. Bottom line is a periodic marker
does not work well for a software based implementation. As I've indicated
before
I do not believe a framing mechanism is required at this point in time. We
should start looking at what it will take to use SCTP (or something
similar).
When the 10G pipes become available in the future we will then be
ready/positioned
and have a solution that should work for all.

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
julian_satran@il.ibm.com
Sent: Saturday, January 06, 2001 3:08 AM
To: ips@ece.cmu.edu
Subject: RE: new iSCSI draft - 02.txt




Dave,

I think that a shim can be inserted between the socket calls and the TCP
copy to mbuf or from mbuf.
On many socket implementations this can be achieved by just changing the
protocol "name" in the socket data structure and then have the shim revert
it to the original.

However we should not be very concerned about stacks that use a
full-fledged mbuf structure and copy the data - their rates will be too low
and they might as well reject the option.

Julo

"David Peterson" <dap@cisco.com> on 05/01/2001 23:40:07

Please respond to "David Peterson" <dap@cisco.com>

To:   "Matt Wakeley" <matt_wakeley@agilent.com>, "IPS Reflector"
      <ips@ece.cmu.edu>
cc:
Subject:  RE: new iSCSI draft - 02.txt




The problem is: at that layer there is simply not a byte stream. The data
is contained in socket buffers which are most likely mbuf clusters for most
implementations. To "simply insert a few extra bytes" requires mbuf
manipulation.
Mbuf manipulation can processing intensive. Depending on how the mbuf data
is
packaged a small DMA operation may occur for these few extra bytes also.
Dave

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Matt Wakeley
Sent: Wednesday, January 03, 2001 7:21 PM
To: IPS Reflector
Subject: Re: new iSCSI draft - 02.txt


David Peterson wrote:
>
> I believe there was agreement to remove the Urgent-Pointer framing
mechanism
> but don't recall any agreement to replace it with an in-stream marker.
For
a
> software implementation it would be hard to support this type of framing
> mechanism. I believe a TCP option indicating the message boundry or a
> fixed-length PDU at a granularity to minimize overhead are much better
> solutions and are workable for both software and hardware
implementations.
I
> have not seen an agenda but I would hope this issue would be discussed at
> the upcoming meeting in Orlando.
> Dave

What is so difficult for software to insert a few extra bytes in the byte
stream?  It's simply a layering problem:

iSCSI layer <-> marker layer <-> TCP

Normally, the marker layer simply transfers the bytes from the iSCSI layer
to
the TCP. Every X number of bytes, the marker layer inserts the marker into
the
byte stream.

Since your software will probably not benefit from the receipt of the
markers,
it would negotiate not to receive the markers.  It would only send markers
*IF* the remote node requested them to be sent.

-Matt Wakeley
Agilent Technologies