Re: iSCSI: Framing Steps

[Ajit Aryan <digital_aryan@yahoo.com>]

Somesh Gupta wrote:

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


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