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

["Y P Cheng" <ycheng@advansys.com>]

> FC switches do not run into this condition by taking special steps. One
> approach is to institute a new route (in response to a link going down)
> after waiting for at least R_A_TOV time. This way, there are no frames
> within that time window whose route may change. It does mean less
> responsiveness to link failures, but it preserves the in-order semantics
> negotiated at FLOGI.
>
> Venkat Rangan

If I read you correctly, even switches do not buffer the frames to ensure
in-order delivery. Instead it relies on R_A_TOV timeout.  So, it always
passes a sequence of in-order incoming frames quickly to an ISL.  If the ISL
fails, it waits until R_A_TOV timeout that forces all unfinished sequences
being thrown away, then, allocates a new link.  Does the switch perform any
checking for out-of-order incoming frames?  Or, is it simply
garbage-in-garbage-out?

Now, if all iFCP, iSCSI, and FCIP must rely on TCP implementation for
ordered delivery, I am the poor guy trying real hard to put TCP in the
microcode of the I/O interface chips in every host, target, and switch port.
If I solve the performance problem of TCP on a 10Gb/100Ms network without
requiring 50 megabytes of reassembly buffer for every single port, I can
corner this market?  This is becomes more interesting every minute.  Thank
God, that should a standard that allows me to write the microcode for this
chip only once.

Other switch experts care to comment?

Y.P. Cheng, ConnectCom Solutions.