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

[Gabriel Hecht <ghecht@gadzoox.com>]

Doug,

In Orlando, Ralph Weber suggested using time-stamp in FCIP and drop frames
that exceed the R_A_TOV time so that the 20sec waiting period scenario will
not happen.   

Framing can be used to prevent the other scenario.  Framing will allow
looking into particular FC streams that are not affected by a delivery
problem that pauses other streams within a TCP channel.  As discussed
earlier, it may require a special TCP implementation.  This can be done
without using time stamps, although a time-stamp may help. 

Failover, load sharing, and alternate TCP channels are probably
implementation specific.  Time-stamp is not necessary, but if exist it may
benefit these implementations.

Gaby    

-----Original Message-----
From: Douglas Otis [mailto:dotis@sanlight.net]
Sent: Friday, January 26, 2001 11:23 AM
To: Gabriel Hecht; ips@ece.cmu.edu
Subject: RE: FCIP/iFCP : Guarantee In-Order delivery for FC N/NL_ports


Gaby,

> Currently, FCIP doesn't map TCP channels to FC streams.  By
> stream, I mean,
> related FCP commands and data that may require 'in order delivery' by the
> SCSI application.  Mapping TCP channels to FC addresses will
> guarantee that
> a FC-stream is fully contained within a TCP channel.

Should the application be using multiple processors with multiple FC
connections, then what you see as isolated is perhaps not.  An advantage of
using multiple TCP connections is lost if all traffic to a device is
restricted to a connection.  At what point in time would the gateway change
to a different connection if there was a problem.  All this activity is time
related and to sift through the mess, a time-stamp still seems essential.

> FCIP leaves this
> mapping to the Gateway implementation.  For example, assigning a TCP
> connection per remote D_ID address or group of address is relatively easy
> for the H/W to implement.  If we don't want to use time-stamp for
> ordering,
> the only implementation limit will be to not put a FC stream on more than
> one TCP channel, to avoid out of order delivery.

This conclusion assumes no relationship between other sources and no
fail-over will be made and all traffic will be held until a missing frame is
recovered.  A TCP interruption may recover within 20 seconds, but with
respect to FC however, this is forever.  If there are multiple working
connections, and one is briefly lost, how does one allow a fail-over?  TCP
may attempt delivery for a very long period.  Is it safe to assume no timing
relationship between FC sources?  As a TCP interruption may occur for
periods longer than the R_A_TOV, is there a violation of the FC fabric to
then release frames held for say 20 seconds?

Doug