Re: iSCSI: Markers

[Ajit Aryan <digital_aryan@yahoo.com>]

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


John Hufferd wrote:

> 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: hufferd@us.ibm.com
> 
>