RE: iSCSI Markers and Framing, a recomendation

["Douglas Otis" <dotis@sanlight.net>]

David,

I felt continued discussion on changing a TCP implementation was indication
of dissatisfaction by the WG.  Use of a sanctioned transport should be
preferable over deciding how to alter TCP.  Even minor points such as
increased SACK size is sure to place protocols sensitive to bandwidth in an
inferior status if restricted to just TCP in my view.

Thank you for the clarification and I am sorry for the disruption.

Doug

> With my WG chair hat on, Doug's email  raises a number of
> issues that need to be dealt with:
>
> 	(1) SCTP should be substituted for TCP in iSCSI.
>
> Doug and anyone else is welcome to write a draft on the
> use of SCTP for iSCSI, but the long-standing rough consensus
> of this WG is to use TCP, and hence substitution of SCTP
> for TCP in the main iSCSI draft is not in the cards.
>
> 	(2) The random number approach used in the TCP
> 		ULP framing draft may result in false
> 		detection of a frame boundary.
>
> That topic is covered in the tsvwg draft - see Section 5.2.1
> of draft-ietf-tsvwg-tcp-ulp-frame-01.txt.  It's germane to
> mention here, e.g., in support of:
>
> 	(3) iSCSI should not reference the TCP ULP framing
> 		draft in any fashion.
>
> That's a reasonable input to the discussion.  As I've said
> before, I think specifying use of TCP ULP framing with
> iSCSI in a separate experimental ips draft that can make
> a normative reference to the tsvwg draft would be preferable
> to continuing to describe this in the main iSCSI draft.
>
> 	(4)  iSCSI should not specify any framing technique,
> 		including FIM, and should not use "SHOULD" for
> 		the requirement level.
>
> Also reasonable input to the discussion.  Let me take the
> opportunity to remind folks to look to RFC 2119 for the
> definition of "SHOULD", as that definition differs from
> what one may find in an ordinary dictionary.
>
> 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: Douglas Otis [mailto:dotis@sanlight.net]
> > Sent: Monday, January 14, 2002 10:24 PM
> > To: ips@ece.cmu.edu
> > Subject: RE: iSCSI Markers and Framing, a recomendation
> >
> >
> > John,
> >
> > One other possible consideration would be to use a framing
> > transport that
> > also solves:
> >  - Blind or Flood Attacks
> >  - Single State Fast Recovery Multi-Homing
> >  - Non-Blocking Service Level Resolution
> >  - Improved Data Integrity with Framing and Alignment
> >  - Standardized Path Management
> >  - TLV Bundling for Differential Path MTUs
> >  - Unordered Delivery
> >  - Payload Identification
> >
> > These features are extremely important for any mission
> > critical application.
> >
> > The AAA WG already recommends this new transport for authentication,
> > authorization, and accounting services.
> > IPS should review current RSERPOOL efforts for Association
> > aggregation as
> > well.
> >
> > A transatlantic link with a 50% loss rate is not of any
> > concern with respect
> > to bandwidth or system overhead.  This would represent almost
> > no traffic and
> > would be best handled by a non-modified TCP implementation.
> >
> > One consideration not in this debate would be to exclude
> > modifications to
> > TCP and not incorporate these extensions by means of
> > experimental techniques
> > and instead consider improvements found by a sanctioned
> > transport.  This
> > would go a long way in restoring trust.
> >
> > A random number could be a string of 20 hex bytes or all zeros and the
> > header found by resegmentation may have a high likelihood of
> > presenting that
> > value.  In other words, not all random numbers offer
> > significant protection.
> > Once the wrong header is used, there is no recovery possible
> > even if such an
> > error is later uncovered, as the intent is to de-encapsulate
> > data below the
> > transport and place it directly into user buffers.
> >
> > Techniques specific to iSCSI are not likely to find support
> > in the future as
> > features not possible by these patch methods will force iSCSI
> > to remain
> > inferior to ongoing work.  Should you wish to find a
> > technique that will be
> > used by a broad range of applications, then a search for this
> > technique
> > should not be conducted within this workgroup, as this is
> > clearly not its
> > charter nor its expertise.  Your choice of Should use Fixed
> > Interval Markers
> > is perhaps innocuous, but as this represents changing TCP to
> > make use of
> > this feature; would not this recommendation of Should be a
> > bit too strong?
> >
> > Doug
> >
> >
> > > 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
> > >
> > >
> >
>