RE: iSCSI: Framing Steps

["John Hufferd" <hufferd@us.ibm.com>]

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