Subject: RE: new iSCSI draft - 02.txt

From: [email-masked]
Date: Thu, 4 Jan 2001 09:25:23 +0200

David,

Several of us thought that we have to have a framing solution in the
current draft and since the TCP option
(flag, length etc>) got a thumbs down at the last IETF and since in-stream
and out-of-stream solution that could be used by others (like the chunking
or my IPV6-like proposal) will take a long time to get through the process
and mature we where left with two options:

   the marker
   having a padding mechanism that will insure that at certain boundaries
   there is always a PDU boundary

I felt that the marker is preferable due to several reasons:

   It can be implemented "underneath" iSCSI - at the boundary with TCP; the
   iSCSI code (its main part) will be unaware of it and it can be replaced
   by another mechanism when such a mechanism becomes available
   it wastes less than the padding
   it is easy to implement in software and even in a plain vanilla TCP/IP
   adapter with hardware assists (and it can be used by many protocols)

We had a "low key" consensus that this is a decent solution and even Doug
Otis does not object!

And yes - we can discuss at any length in Orlando.

Regards,
Julo

"David Peterson" <[email-masked]> on 03/01/2001 16:47:07

Please respond to "David Peterson" <[email-masked]>

To:   "Ips@Ece. Cmu. Edu" <[email-masked]>
cc:
Subject:  RE: new iSCSI draft - 02.txt

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Saturday, December 30, 2000 11:11 AM
To: [email-masked]
Subject: new iSCSI draft - 02.txt

Dear colleagues,

I've just submitted to the Internet-Drafts repository and to our list
archive (at CMU) a new
version of the draft.

Changes (from 2b!):

   framing by Urgent-Pointer replaced by framing through in-stream marker
   editorials and typos (not completed yet)
   simpler digests
   digest recovery and some clarifications on iSCSI specific errors (more
   to come)

I will have version 03 with many more editorial changes before the
intermediate meeting.

You can see the draft at:

http://www.haifa.il.ibm.com/satran/draft-ietf-ips-iSCSI-02.txt

Regards,
Julo

---

From: [email-masked]
Date: Fri, 5 Jan 2001 11:49:37 +0200

Glen,

I can hardly agree with your assumption that CRCs will have to be
recomputed in the end-nodes as the only means for real protection.  Our
design assumptions was that we don't want to mandate that - it is
impractical at high speed.
The end node will get data fit to its quality. If it has a bad DMA it will
get bad data from local disk too!
You are right about the major objection with regard to byte stuffing being
copy - and I don't see how COBS is better than other schemes.  An iSCSI
hardware adapter could do it efficiently while using a plain (even
accelerated) TCP adapter will make it very inefficient.
The marker scheme suggested does not require any TCP internal knowledge -
sequence numbers are not used and markers are relative.  Yes you have to
count every byte but you can do it independent of the TCP count.
Buffer copies become either rare or are eliminated if your DMA mechanism is
sophisticated enough.

Julo

Glen Turner <[email-masked]> on 04/01/2001 07:01:31

Please respond to Glen Turner <[email-masked]>

To:   [email-masked]
cc:   "Ips@Ece. Cmu. Edu" <[email-masked]>
Subject:  Re: new iSCSI draft - 02.txt

Sukha Ghosh wrote:
>
> Also I like the idea of fixed length PDU better than a new TCP
> option indicating message boundary.

A fixed length PDU doesn't solve the fundamental problem.  In a
stream of bytes you still can't tell where the PDU starts
unless you assume PDUs pack nicely into packets and frames
and the iSCSI process has special knowledge of the data
stream (such as TCP options).

Without altering TCP (which this IESG is opposed to) the
options are an adaption layer containing either a flag
byte and escapes (as in SLIP) or a counting scheme (such
as computing a CRC which becomes 0 when the PDU is complete).

Objections that byte stuffing to mark the PDU boundary
discourages host-based implementations are somewhat difficult
to understand.  Firstly, the feature can, and should, be
negotiatable in both directions.  A host processor implementation
can chose not to negotiate the reception of packets with
byte stuffing, at the cost of incurring TCP head-on-line
blocking due to late packets.

Secondly, the decision to include a iSCSI-level checksum (to avoid
surprisingly common corruption by DMA chips and the like, see the
SIGCOMM2000 Proceedings) means that the data has to be scanned
by the CPU anyway.  Any other implementation of the iSCSI-level
checksum gives no protection.

The real objection is that removing the byte-stuffing requires
a buffer copy, not just a scan.  The second objection is that
the overhead from SLIP-style byte stuffing has a pathological case.

The counting schemes do not need a buffer copy (as you can arbitrarily
drop, say, the last 8 octets that were required to drive the CRC
to 0 and retreive the original data).  However, these schemes are
unavoidably computationally expensive, perhaps more so than a buffer
copy (although RISC processors do about 100 instructions per
memory cycle, so this assumption needs testing).

A modification of "Consistent Overhead Byte Stuffing" (IEEE/ACM
Transactions on Networking, Vol 7, No 2, 1999) seems to hold
a neat solution to the pathological case of SLIP.  It offers a
neat way of identifying packet boundaries that has a bound on
the growth in the packet size.  However, like SLIP it also
requires that a buffer copy occur to undo the detection of the
packet boundary.

If the WG find it best to deal with TCP as a stream of octets
with zero knowledge of the underlying packet boundaries, options
and sequence numbers then an adaption layer for TCP with a
COBS-based scheme to identify packet boundaries seems to have the
most promise.

Regards,
Glen

--
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 [email-masked]          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised