Subject: [Tsvwg] RE: iSCSI: Framing Steps

From: "Douglas Otis" <[email-masked]>
Date: Fri, 25 Jan 2002 15:13:08 -0800

David,

Thank you for the response.  I think a further point should have been
strongly made.  Such changes to TCP are not actions of the IPS workgroup.
These matters should be discussed within the tsvwg.  Even matters of Fixed
Interval Marking brings concerns with respect to the impact even this
seemingly innocuous iSCSI option may have.

Should the interval within the FIM be a power of 2, guessing an initial
sequence value allows injection of packets within existing connections.  A
layer below TCP, as devised for iSCSI, is to place de-encapsulated iSCSI
information from isolated packets that include marker information  despite
prior packet loss.  A general goal of all the framing approaches being
sought by the IPS wg.

This would require extensive modification of TCP to facilitate this
behavior.  In addition, without the specific details of this scheme, largely
due to a desire to claim no changes, it is difficult to evaluate related
security risks.  One risk of this scheme is the requirement for application
specific code to be routinely placed below the transport.  There are no
conventions for instituting the requisite signaling between this below the
transport layer application process and the modified TCP.  Should an attack
successfully inject even null structures, it would not be clear how the
transport would behave.

FIM has been suggested by those within the IPS wg that implementers consider
implementing an otherwise obnoxious scheme requiring the injection of
markers or suffer from discarded data otherwise retained using standard
versions of TCP.  Clearly just sending these markers are not in themselves a
risk to TCP.  It is their intended use that causes concern.  This FIM has
also been indicated by several including the author of iSCSI that FIM is
just an interim measure to be followed by a full framing scheme later.  It
is clear this group wishes extensive modifications to TCP and does not wish
to share these details openly.

One suggestion was to have each iSCSI PDU become framed by a TCP segment.
Just the reduction in the average packet size within a high bandwidth stream
will stress standard versions of TCP as well as the intervening equipment.
SCTP had the foresight to include bundling methods.  This is just one aspect
of these proposals to fail consideration within the IPS wg.  In general, I
think the IETF made a wise choice in proposing SCTP as the means of
incorporating framing within IP protocols and the IPS wg was informed of
SCTP at the outset of their endeavors.  SCTP provides many advantages with
respect to pressing concerns especially the less disruptive nature
incorporation of framing using SCTP would cause over an attempt of framing
within TCP.  It is clear there is consensus within the IPS wg that SCTP is
not to be considered and that TCP framing is despite prohibitions within the
charter and the good judgement of the IETF.  The ongoing tacit approval of
these discussions regarding modification of TCP within the IPS wg is
troubling.

Doug

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, January 23, 2002 11:10 PM
> To: [email-masked]
> Subject: iSCSI: Framing Steps
>
>
> I want to attempt to make some steps towards resolving
> the framing issues.  In reviewing the recent discussions
> on framing, I have a couple of conclusions:
>
> (1) I do not believe that WG consensus (rough or otherwise)
> 	can be obtained for a "MUST implement" requirement
> 	for any form of framing.
> (2) The COWS mechanism has a lot of potential, but
> 	its newness, the multiple versions that
> 	have been mentioned, and the desire for some
> 	sort of alignment with new work on DDP/RDMA
> 	suggest that COWS is premature to specify as
> 	part of iSCSI.
>
> I suggest that these conclusions form the
> basis for further ips WG consideration of framing.
>
> Please think carefully before objecting to these
> conclusions on the list (I'm happy to respond to
> private questions/expressions of concern).  If the
> framing issue cannot be driven to closure in
> the next few weeks, I will be forced to conclude
> that the entire topic is experimental, and hence
> needs to be removed from the iSCSI specification
> and handled in separate drafts intended to become
> experimental RFCs.
>
> Thanks,
> --David
>
> p.s. A desire to build NICs that never behave in
> accordance with an important SHOULD in RFC 1122
> (out-of-order segments SHOULD be queued) does not
> strike me as a good reason for changing the first
> conclusion above.
>
> ---------------------------------------------------
> 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
> ---------------------------------------------------
>

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Mukund, Shridhar" <[email-masked]>
Date: Mon, 28 Jan 2002 18:42:54 -0800

Dear colleagues,

1. Doug : David made the point, "it(FIM) does not modify 
   the TCP protocol", as lucid as it gets. It will be nice 
   to hear some opinions from the TCP gurus out there
   without mixing it up with SCTP and TUF.

2. It will also be nice if other iSCSI folks on the reflector 
   cast their votes per John's request.
   Putting on my politician hat :-), pl. vote for option 6.
   >>>> 6. FIM now, and some kind of Framing later

3. I do agree with David that the implication, "Senders that 
   do not insert markers on send should be willing to accept 
   up to RTT*BW drops" in my email was too strong as it goes 
   against a RFC1122-SHOULD. ( See reference below ). I
   stand corrected.

   The current iSCSI draft addresses my point anyway:
   "In certain environments, a sender not willing to supply 
   markers to a receiver willing to accept markers MAY 
   suffer from a considerable performance degradation."

   In my interpretation, the spirit behind the RFC1122-SHOULD 
   is to save IP networks from having to transport 
   same data all over again in the event of packet drop. 
   In fact, FIM directly addresses this very spirit.

   We may want to add a note in the iSCSI draft that 
   implementations should try to honor the RFC1122-SHOULD
   when the sender is not willing to supply markers.

Thanks.

-Shridhar Mukund

------------------------------------------------------------------------
Reference : David's response dtd 14 Jan. to my email:

>    b. I strongly recommend SHOULD implement FIM on the send side. 
>       Implication -> Senders that do not insert markers should be 
>       willing to accept up to RTT*BW data drops! Headers being 
>       "reasonably" out-of-order is OK. Of course, senders that do not 
>       insert markers but are willing to pay big $$$ to the SSP will 
>       get their buffer/BW allocation as usual and customary :-)

I think the Implication is too strong, as it goes against the following
SHOULD from RFC 1122 (which modifies RFC 793):

         4.2.2.20  Event Processing: RFC-793 Section 3.9
 
            While it is not strictly required, a TCP SHOULD be capable
            of queueing out-of-order TCP segments. 

A drop causes the segments up to the retransmission of the drop to 
be out-of-order.  This does not preclude "SHOULD implement FIM", but
the above Implication is overdone in my view as it appears to condone
drops of all out-of-order segments.