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

From: [email-masked]
Date: Tue, 23 Jan 2001 18:19:59 -0500

> > The FCIP draft does not preclude multiple TCP connections.
> > Somesh is right in pointing that we could result in out-of-order if we
> > have more than one TCP connections between same two FCIP Gateways.
> 
> Even with just one TCP connection, when frames travel through the "IP
> cloud", don't we risk out-of-order and duplicated frames at the other end?
> For multiple connections, it is a sure thing.

Not a problem - TCP sits above IP and takes care of both of these.  FWIW,
TCP tends not to be good at dealing with out-of-order packets (e.g., it asks
for retransmits) resulting in a significant incentive to the IP cloud to not
deliver
out of order very often.

> > However, an FCIP gateway (say FCIP-A) can carry on simultaneous TCP
> > connections say with FCIP-B and FCIP-C gateways without the
> > danger of the out-of-order issue.
> 
> FCIP-A can take responsibility for in-order delivery of outgoing frames.
> But, there is no guarantee for in-order and non-duplicated reception on
> either FCIP-B or FCIP-C.

TCP on FCIP-B and FCIP-C will ensure in-order and non-duplicated reception
on the FCIP to FCIP links.  The FC fabric is responsible for in-order
delivery
across the FC fabric based on this link property.

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.

--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: Wayland Jeong <[email-masked]>
Date: Tue, 23 Jan 2001 17:39:54 -0800

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

> --David
-Wayland