[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI Markers and Framing, a recomendation

    I believe that the reasons you've outlined for FIM 
    now, some kind of framing later, is the right approach.
    So, #6 would be my vote as well.  I also agree that
    the 'SHOULD' language would be appropriate on the send
    side (as per RFC2119).
    -----Original Message-----
    From: John Hufferd []
    Sent: Monday, January 14, 2002 12:37 PM
    Subject: iSCSI Markers and Framing, a recomendation
    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
    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
    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:


Last updated: Mon Jan 28 15:18:04 2002
8521 messages in chronological order