Subject: iSCSI - Synch an Steering Appendix - Markers & COWS

From: "Julian Satran" <[email-masked]>
Date: Sun, 23 Dec 2001 21:19:17 +0200

Dear colleagues,

Attached are the two versions of the Synch and Steering appendix that we 
are considering.

During the SLC meeting we tentatively agreed that we will consider the 
markers (ugly but workable) and a new alternative Constant Overhead Word 
stuffing that I had to draft.

We also agreed that we will strive to have only one such option and we 
would like to have it required somewhat stronger (sender should provide it 
if receiver wants it).

Any comments/questions are welcome.

Happy holidays and a peaceful and prosperous 2002,
Julo

---

From: "Mukund, Shridhar" <[email-masked]>
Date: Mon, 24 Dec 2001 13:11:59 -0800

Julo, 

During the SLC meeting we tentatively agreed that we will consider the
markers (ugly but workable) and a new alternative Constant Overhead Word
stuffing that I had to draft. 
[-------->] Isn't this "Consistent Overhead Word(Byte) Stuffing" from
Stanford? 
 
 -Shridhar Mukund

---

From: "Williams, Jim" <[email-masked]>
Date: Wed, 26 Dec 2001 13:15:29 -0500

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Sunday, December 23, 2001 2:19 PM
To: [email-masked]
Subject: iSCSI - Synch an Steering Appendix - Markers & COWS

Dear colleagues, 

Attached are the two versions of the Synch and Steering appendix that we are
considering. 

We also agreed that we will strive to have only one such option and we would
like to have it required somewhat stronger (sender should provide it if
receiver wants it).  

I believe there is also a third alternative under consideration which is a
length/key
encoding which is considerably simpler and easier to implement.  The primary
objection to this mechanism is due to its probabilistic nature, however this
objection seems based more on superstition than on any analysis showing
that the overall reliability of the system is in any way compromised by
the probabilistic nature.
 
In any case, my understanding is that this is also under consideration
in TSV working group, so I would hope that IPS will defer to their
choice and not try to go it alone regarding the decision.
 
However, I would strongly object to the "SHOULD implement".
I believe this should be made a "SHOULD implement" only
after the benefit of this technique has been demonstrated.
I do concede that there are one or two vendors who have
view graphs claiming that "Synch and Steering" layer will allow
them to build a more cost effective product.  However after doing
a considerable amount of study on iSCSI HBA design, I have serious
doubts about the viability of this approach.  I am more than happy to
be proven wrong on this, but the operative word is "proven".
 
I am bothered that a small minority of implementors want everyone
else to de-optimize their designs so that they can optimize their
own, especially when I suspect the approach is technically flawed
to begin with.
 
And, if the "Sync and Steering" approach is successful, it will quickly
become a de-facto standard anyway, so I would urge the IETF
to remain a bit more neutral on this for now.

Thanks for considering my coments, and best to all as well,
 - Jim

---

From: [email-masked]
Date: Wed, 26 Dec 2001 22:05:16 -0500

> > We also agreed that we will strive to have only one such
> > option and we would like to have it required somewhat
> > stronger (sender should provide it if receiver wants it).  
 
length/key
> choice and not try to go it alone regarding the decision.
 
That length/key approach is the TCP ULP framing work in
draft-ietf-tsvwg-tcp-ulp-frame-01.txt.  That draft is currently
planned to become an Experimental RFC, and hence the strongest
requirement that iSCSI can express for implementing it is "MAY".
 
> be proven wrong on this, but the operative word is "proven".
 
That's fair.  I view the level of requirement (MUST/SHOULD/
MAY) as an open issue - to the extent that Julian expressed
a preference for something stronger than MAY, that is not
the rough consensus of the IPS WG.  Further discussion is
encouraged, and I hope to see this issue resolved by/at
the February interim meeting.  FWIW, I have heard from
other hardware implementers that markers are not a make
or break product requirement at 1 Gbit/sec, but they
will have to speak for themselves in the WG.
 
Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------

 -----Original Message-----
From: Williams, Jim [mailto:[email-masked]]
Sent: Wednesday, December 26, 2001 1:15 PM
To: 'Julian Satran'; [email-masked]
Subject: RE: iSCSI - Synch an Steering Appendix - Markers & COWS

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Sunday, December 23, 2001 2:19 PM
To: [email-masked]
Subject: iSCSI - Synch an Steering Appendix - Markers & COWS

Dear colleagues,