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

From: [email-masked]
Date: Tue, 23 Jan 2001 20:53:56 -0500

> > 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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 23 Jan 2001 20:20:46 -0800

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