Subject: iSCSI: Markers

From: "John Hufferd" <[email-masked]>
Date: Thu, 10 Jan 2002 18:19:50 -0800

OK, Folks, I have now talked to Steph, who authored  TUF, which is
currently on the road to Experimental Status,  He has authored another
version of TUF also, which uses a form of COWS.  So that means that we have
two different versions of TUF as well as 2 versions of COWS (which are
independent of Framing), and then there is FIM.  So let me list them and be
sure we name them so that we are not in the middle of more confusion.

1. Fixed Interval Markers (FIM) Currently In the iSCSI Draft
2. Constant Overhead Word Stuffing (COWS) as drafted by Julian and sent in
his note of 12/23/2001 Subject "iSCSI - Synch an Steering Appendix -
Markers & COWS"
3. TCP Upper-layer-protocol Framing (TUF) as drafted by Stephen Bailey in
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-ulp-frame-01.txt
4. COWS Drafted By Stephen Bailey which can be used in both in stream and
with Framing in
http://www.cs.uchicago.edu/~steph/draft-bailey-tsvwg-cows-00.txt

Now lets call Julian's proposal COWS with 2 way pointers (COWS2WP)
Now lets call Steph's COWS with 1 way pointers (COWS1WP)

When the type of COWS does not matter we can just call them COWS.

Both COWS can be used in Framing.  But to keep this discussion somewhat
simpler lets call the Framing without any COWS as "Bare Framing", and Both
of the other as "COWS Framing".  Only when we need to talk about which type
of COWS should we say "COWS2WP Framing" or "COWS1WP Framing".  But for most
conversation it should be just "COWS Framing".

So we have FIM, COWS1WP, COWS2WP, Bare Framing, & COWS Framing (made up of
COWS1WP Framing and COWS2WP Framing).

Now we also need to understand that one of the main reasons expressed to
make Framing go experimental, instead of Standards Track was that folks
were worried that Bare Framing was based on probability, and that there was
a very remote possibility that something could be done incorrectly.

As a result of that Steph was considering, as part of the experimental
work, seeing what the impact of his previous COWS Draft would be on the
experimental work that was going to be done.  He had no intention of
bringing it up now, since he felt work/thought was still needed.

As you know COWS came up anyhow (and in a different form).

So what we have are statements from folks like me that had read Julian's
Draft and the ietf-tsvwg version of Framing (Bare Framing), which did not
see in those drafts the overlap.  Clearly there is an overlap in the minds
of Julian for COWS2WP and Steph for COWS1WP and how they might impact
Framing.

NET of Bare Framing vs COWS Framing:
Bare Framing is based on probability and does not have to inspect each Word
(SW or HW) COW requires Touching each Word,
COWS Framing is guaranteed to always be correct.

So the choices are:
1. FIM now, and Bare Framing later
2. FIM now, and COWS Framing later
3. COWS now, and Bare Framing later
4. COWS now, and COWS Framing Later
5. Nothing now, and some kind of Framing Later

If we chose to do any of the "COWS now" options we would need to hold the
debate on which form, but we should assume that which ever COWS we chose
now is the COWS for later.

Value Statements
1. FIM and Bare Framing: Means we never have the overhead of touching every
word
2. FIM and COWS Framing: Means that touching is postponed until Framing,
and perhaps Faster Desktops/Laptops or support even support in normal NICs.
3.  COWS now and Bare Framing later: Has issues of toughing everything now,
and then not useful later
4. COWS now and COWS Framing Later: Means always touch, but current
approach is extensible into Framing
5.Nothing now, and some kind of Framing later: Means No current help, and
no guarantee of help in the future, but some reasonable probability that
some form of Framing will happen.

So it is 1-5 upon which  we should be taking a position.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

---

From: Ajit Aryan <[email-masked]>
Date: Fri, 11 Jan 2002 10:35:27 +0530

Of the five options mentioned should I say, the option 2 is the right 
kind of thing which provides the necessary flexibility and may be a 
easier way to implement or to adopt whenever needed.
ANY COMMENTS??

Aryan

---

From: Paul Koning <[email-masked]>
Date: Fri, 11 Jan 2002 09:51:43 -0500 (EST)

Apart from taking a position on 1-5, we need to take a position on
mandatory vs. optional to implement.

I don't have strong views right now on which of 1-5 is best for those
who want to cast their iSCSI protocol processing into silicon.  But I
do have views on what these things cost in software, so for any of
options 1..4 I would object to a "mandatory to implement" requirement.

	paul

---

From: "Mark S. Edwards" <[email-masked]>
Date: Fri, 11 Jan 2002 15:34:43 +0000

>options 1..4 I would object to a "mandatory to implement" requirement.
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ditto.

Mark.

---

From: "Amir Shalit" <[email-masked]>
Date: Fri, 11 Jan 2002 09:29:01 -0800

Any option that requires you to touch every byte is not Silicon 
friendly. In other words, only FIM and bare framing (TUF) are 
acceptable.

Amir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Paul Koning
Sent: Friday, January 11, 2002 6:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI: Markers

	paul

---

From: "Matt D. Robinson" <[email-masked]>
Date: Fri, 11 Jan 2002 14:04:41 -0800

> >options 1..4 I would object to a "mandatory to implement" requirement.

I concur.

--Matt