Re: iSCSI Markers and Framing

[James Smart <james.smart@trebia.com>]

As you were looking for more votes from those on the reflector...

I would vote for either 5 or 6, where 6 is defined as - FIM optional to 
use, separately enabled/disabled for tx and rx paths, and should 
implement on the tx path.

-- James


John Hufferd wrote:

>Now that I have punished you all with the notes defining what is Framing
>and COWS.  I will lobby for one.
>
>Here again are the choices
>
>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
>6. FIM now, and some kind of Framing Later
>
>Two arguments one for FIM now and one for Bare Framing later:
>
>Let me start with "Framing Later":
>
>The more I have seen of the work going on defining RDMA/iWARP, and the work
>that is going into the Framing Experimental Status, the more I believe, we
>can NOT now know how this will work out.  Let me give you an example.  The
>only significant concern, with Bare Framing,  is the case of a false
>positive indicator only when the network has re-segmented the TCP Segment.
>The Bare Framing protocol has a 48-bit Random number and a 16 bit length
>field to detect this.  I believe this has a lower probability of false
>positives then passing an undetected error through the 16 bit TCP/IP XOR
>Checksum, and possibly even the 32-bit CRC.  So the Experimental work was
>started to prove that this was not an issue.  Now, even though Bare Framing
>is the easiest to implement, and probably statically just fine (at least in
>my opinion), some folks are attempting to come up with a fool proof
>approach, which probably causes more implementation costs. (You can bet
>that will be a major shoot out.)  No one yet has been able to do the needed
>math to prove that Bare Framing is a problem or not a problem (volunteers
>anyone?).  But sooner or later some one will do that.  There is even a
>chance that another word could be added to the Random Number to make it
>even stronger.    In the mean time we have two Different COWS proposals,
>and no one knows if something now unknown will bleed over from the RDMA
>work.
>
>We simply do not know how the Framing will work out.
>
>iSCSI choosing a Marking approach to match one of the perceived Framing
>approaches, will not cause that approach to happen, and it is probably
>going to cause turf wars, and other non productive interactions.
>
>Therefore, I have come to the conclusion that Markers and Framing are
>disjoint issues.  Further, we have no control over the direction of
>framing.
>
>Now my arguments for "FIM now":
>
>FIM is the lowest overhead Marker approach we have been able to come up
>with.  I think we need something that can easily be placed into SW ( In
>this context I am talking about SW that does not  "OWN" the Host TCP/IP
>stack.).  As I have stated before, FIM is simple to implement and can
>greatly help some HW.   It needs to be Sent only if requested, and not
>other wise.   It has been in the spec for some time, is therefore well
>understood  and I think it has been scrubbed my a number of different
>vendors.  Some of which have told me that they have either placed it in
>their product or are working on that.  This is NOT to say that we can not
>change it, but that because of its longevity in the spec, has undergone a
>lot of study.  And we should have important reasons not to do FIM (such as
>if it doesn't work).
>Now, Jonathan Stone, has stated that "transatlantic can regularly show 50%
>drop rate".   I would like the vendors to have some  approach to enable a
>reasonable solution, to this and other long haul requirements, which keeps
>the Adapter cost as low as possible.  Also, that would mean that it can NOT
>wait until 10 Gig.
>
>Now to the issue of MUST or SHOULD implement.
>
>I have been persuaded that "SHOULD implement on Send" but optional to use,
>would be a more acceptable position, since vendors with good and just
>reasons would not have to implement it, yet the customer could find
>solutions if they needed them.
>
>Therefore, based on the above reasoning, I am recommending:
>
>Choice 6, with "SHOULD implement on Send".  That is,
>
>Leave FIM in the Spec, and add an enabling statement about "SHOULD
>implement on Send if requested by the receiving side".
>
>
>.
>.
>.
>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
>