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

    Re: iSCSI: Framing Steps

    Somesh Gupta wrote:
    > Sridhar,
    >>-----Original Message-----
    >>From: []On Behalf Of
    >>Mukund, Shridhar
    >>Sent: Monday, January 28, 2002 6:43 PM
    >>To: 'Douglas Otis';;
    >>Subject: 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. 
    >      IP networks so far have managed to handle packet drops
    >      (without complete retransmissions) without FIM. Again,
    >      I think the statement below is way overstating the case
    >      and you may want to add the significant number of
    >      qualifiers associated with it.
    Its true that the current day IP networks are capable of handling packet
    drops .... But it is high time to have a mechanism to handle this
    more efficiently, keeping in view the importance of SANs and their
    intended use. I think otion 6 with proper interpretation of *SHOULD* is 
    a good option to opt for.
    >>   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
    >      I think there is substantial disagreement as to whether
    >      any approach meets the objectives that people are
    >      attempting (of course there is probably no agreement
    >      on the requirements either). The debate so far, even
    >      though intelligent, has been at the surface and high
    >      level.
    >      I think to resolve this requires experimentation, or
    >      at least a very detailed hypothetical technical design
    >      and analysis (I would be more than happy to at least
    >      take pot-shots so the design and analysis would be
    >      more thorough).
    >      It will make visible at the compromises and assumptions
    >      being made - people can then decide whether we want
    >      iSCSI to make those assumptions and compromises.
    >      (or perhaps that will require people to share too much?)
    >>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: Tue Jan 29 10:17:56 2002
8538 messages in chronological order