SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Framing Steps



    
    Somesh,
    Since the team convinced me to come off my proposal for "Must Implement on
    Send", to "Should Implement on Send", I think it gives you the ability to
    Not do it for all the reasons that are of major importance to you.  The
    others, that can will Implement FIM.  You can then meet in the market
    place.
    
    Option 6 (FIM today and some type of Framing later) along with "Should
    Implement" seem to be the right mix for you and the others.
    
    .
    .
    .
    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
    
    
    "Somesh Gupta" <somesh_gupta@silverbacksystems.com>@ece.cmu.edu on
    01/28/2002 08:10:25 PM
    
    Please respond to <somesh_gupta@silverbacksystems.com>
    
    Sent by:    owner-ips@ece.cmu.edu
    
    
    To:    <ips@ece.cmu.edu>
    cc:
    Subject:    RE: iSCSI: Framing Steps
    
    
    
    Sridhar,
    
    > -----Original Message-----
    > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    > Mukund, Shridhar
    > Sent: Monday, January 28, 2002 6:43 PM
    > To: 'Douglas Otis'; Black_David@emc.com; ips@ece.cmu.edu
    > Cc: tsvwg@ietf.org
    > 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.
    
    >    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
    
         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):
    >
    >          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.
    >
    >
    >
    
    
    
    


Home

Last updated: Thu Jan 31 10:18:06 2002
8572 messages in chronological order