RE: iSCSI: Markers and Framing

["Douglas Otis" <dotis@sanlight.net>]

Dave,

The iSCSI draft includes use of Fixed Interval Markers-

"Different schemes can be used to recover synchronization.
 One of these schemes is detailed in Appendix A. - Sync and
 Steering with Fixed Interval Markers -. To make these
 schemes work, iSCSI implementations have to make sure that
 the appropriate protocol layers are provided with enough
 information to implement a synchronization and/or data
 steering mechanism."

As you are suggesting there is a significant consequence in TCP behavior if
not adhering to this iSCSI recommendation that mandates a process below the
transport layer for de-encapsulation of iSCSI related structures, the impact
of this requirement should be reviewed within the appropriate workgroup.
Until then, Fixed Interval Markers should not be included within the iSCSI
documentation as this behavior is a change to TCP as you have indicated.

Doug

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