RE: FCIP/iFCP : Guarantee In-Order delivery for FC N/NL_ports

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

David,

The FC frame is placed on FC network within a short time of its arrival or
there is no advantage in allowing out of sequence processing.  With that in
mind, multiple connections can be synchronized with a slight delay by
looking at a single time-stamp field and stale frames dropped if their
arrival is deemed too late by means of a TOV.  In each case, a time-stamp
offers a simple solution to this problem of potential out of sequence
placement.  With a small window looking across multiple connections, frames
can be placed in order.  If a frame arrives with a relative time-stamp in
excess of this time window, bye-bye frame.  At least the fabric assumptions
remain with respect delinquent frames.  The size of the "small" window may
increase in time to allow for 2RTT+ but it would be a sizeable increase in
system latency and require about 1 Mbyte of buffer for a MAN.  One wonders
if such buffering is desired for FC or if one could live with the results of
occasional out of sequence frames where a R_A_TOV limit is used to dismiss
frames.  The aspect of ensuring a restart is enabled by a means to police
old strays.  Without a time windowing scheme, R_A_TOV is not valid and the
size of the buffer required is unknown.  What do you think?

Doug

> > > Beyond this, FCIP may have framing issues (identification and
> placement
> > > of inbound data in the presence of drops) that are similar to iSCSI
> depending
> > > on how the FCIP nodes are implemented.
> > >
> > The issue wrt. to framing in an FCIP device is a bit puzzling to me.
> Framing
> > for an iSCSI HBA for implementing zero-copy DMA semantics I can
> understand.
> > The notification of delivery and the delivery of data is de-coupled, so
> order is
> > preserved in this case.
>
> > But, aggressively forwarding through drops in an FCIP bridge is not only
> > dangerous, it violates TCP layering. Forwarding around dropped PDU's
> > will introduce all sorts of ordering issues. It seems like an
> FCIP device
> > would want to take the conservative approach and allow TCP to recover
> > and deliver the PDU's in the order that they were sent. Hence,
> I don't see
> > a need to specify a framing method for an FCIP-type device.
>
> Depending on the implementation approach to memory management, an
> FCIP device may have issues similar to an iSCSI HBA, and this is still
> the case even though an FCIP device MUST NOT perform the sort of
> aggressive forwarding described in the above paragraph.  YMMV depending
> on the physical configuration and software management of memory in
> the specific implementation.
>
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>
>