RE: iSCSI: Markers and Framing

[Black_David@emc.com]

A couple of comments on this:

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

>    c. I think that the proponents and beholders of FIM had 
>       good reasons. They still hold and are even more stronger. We
>       have had FIM in the iSCSI spec since version 02. Major changes 
>       to the iSCSI draft, at this late date, should have significant 
>       technical reasons.

I just want to remind everyone that there can be "significant technical
reasons" to change things at this juncture.  One example is the change
made to SCSI Task Management (e.g., Abort Task Set) in Salt Lake City.
The balance in the above text between "changes ... at this late date"
and "significant technical reasons" is a good way to think about this
sort of issue.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------