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

[Black_David@emc.com]

> > 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.

 

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".

 

> 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".

 

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
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------

 

 -----Original Message-----
From: Williams, Jim [mailto:Jim.Williams@emulex.com]
Sent: Wednesday, December 26, 2001 1:15 PM
To: 'Julian Satran'; ips@ece.cmu.edu
Subject: RE: iSCSI - Synch an Steering Appendix - Markers & COWS

 

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, December 23, 2001 2:19 PM
To: ips@ece.cmu.edu
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.

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).  

 

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.

 
Any comments/questions are welcome.

Happy holidays and a peaceful and prosperous 2002,
Julo  

 

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

 - Jim