RE: iSCSI: Markers and Framing

[Dave Sheehy <dbs@acropora.rose.agilent.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.

It is not overdone. It is the reality of the situation for a one touch NIC.
If an implementation does not want to implement some form of framing
that is the consequence it must be willing to pay for that choice.

Dave Sheehy