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

From: Gabriel Hecht <[email-masked]>
Date: Thu, 25 Jan 2001 18:01:26 -0800

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

Gaby

-----Original Message-----
From: Douglas Otis [mailto:[email-masked]]
Sent: Thursday, January 25, 2001 11:11 AM
To: [email-masked]; [email-masked]
Subject: RE: FCIP/iFCP : Guarantee In-Order delivery for FC N/NL_ports

David,

For what it's worth, I am not making such fine distinctions.  I was
attempting to discuss a reason for including a time-stamp should such
placement be onto FC media.  (Looking to the day when there is a means to
handle out of sequence frames.)

Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 26 Jan 2001 11:22:59 -0800

Gaby,

> 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

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