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

    RE: iSCSI: Framing Steps

    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.
    -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):
     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.


Last updated: Mon Jan 28 23:17:45 2002
8528 messages in chronological order