RE: iSCSI: Framing Steps

["Mukund, Shridhar" <Shridhar_Mukund@adaptec.com>]

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.