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

From: Santosh Rao <[email-masked]>
Date: Tue, 16 Jan 2001 23:14:26 -0800 (PST)

I have a question for the FCIP and iFCP folks. Do these 2 protocols still 
assure in-order delivery of frames to the FC end nodes (N/NL_Ports) 
when requested through the "Sequential Delivery" bit in FLOGI ?

Can this assurance be made even while using multiple TCP connections b/n 
edge switch/routers ? 

- Santosh

-- 
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################

---

From: "Y P Cheng" <[email-masked]>
Date: Wed, 17 Jan 2001 08:03:28 -0800

> Can this assurance be made even while using multiple TCP connections b/n

If I may add that most FC devices out in the market will NOT receive
out-of-order delivery because it does not go over the scatter/gather list
from beginning on every incoming frame!  So, if FCIP and iFCP wish to work
with legacy FC devices, they must learn from Brocade switches, i.e. assure
in-order delivery.

Y.P. Cheng, ConnectCom Solutions

---

From: "Y P Cheng" <[email-masked]>
Date: Wed, 17 Jan 2001 11:20:07 -0800

> It is not only the desire to inter-operate with legacy FC devices
> that drives this requirement.
> This is a mandatory requirement, since FC-FLA Table 3 mandates
> that N/NL_Ports originating FLOGI SHALL request in-order delivery in
> the FLOGI.  (by setting the "Sequential Delivery" bit in their class
> specific parameters for class 2 & 3 to 1.).
> - Santosh

If in-order-delivery is a MUST, the next question is "How many open
sequences?"  On a 10 Gb/sec network with long latency, we need many open
sequences to fill the pipeline.  This is the same problem as TCP window size
of iSCSI.  To keep all open sequences in order, in the worst case, there
will be a huge holding buffer in an iFCP and FCIP device.  We have just
moved the TCP window problem from an end-point into a bridge or gateway
device.  Hence, by just changing the protocol, the problem does not go away.

---

From: Santosh Rao <[email-masked]>
Date: Wed, 17 Jan 2001 10:56:22 -0800

It is not only the desire to inter-operate with legacy FC devices that drives
this requirement.

This is a mandatory requirement, since FC-FLA Table 3 mandates that N/NL_Ports
originating FLOGI SHALL request in-order delivery in the FLOGI. (by setting
the "Sequential Delivery" bit in their class specific parameters for class 2 &
3 to 1.).

- Santosh

---

From: "Y P Cheng" <[email-masked]>
Date: Wed, 17 Jan 2001 12:23:20 -0800

> > Hence, by just changing the protocol, the problem does not go away.
>
> Not sure what you mean here. Changing which protocols ?

By reading this reflector, you must know my opinion about the overlapping
functionality of iFCP and iSCSI.  I consider them as two different protocols
solving the same set of problems, i.e. long Internet latency, congestion,
lossy connections, duplicated or missing frames, R_A_TOV values, target
device naming and discovery, etc., etc.  Hence, why two protocols solving
the same set of problems?  (I must qualify that iFCP and FCIP do not have to
solve the message framing issue.  Each FCP IU is a separate frame/sequence.
But, if iFCP and FCIP use TCP encapsulation, then, we back to square zero.)

---

From: Santosh Rao <[email-masked]>
Date: Wed, 17 Jan 2001 11:39:55 -0800

Y P Cheng wrote:

> sequences?"

In-order is a requirement that spans across exchanges. (not just within an
exchange).

> On a 10 Gb/sec network with long latency, we need many open
> device.

Agreed. The alternative is to use 1 TCP connection per FC (S_ID, D_ID) pair.
Which is why I raised the question in the context of multiple TCP connections
between the edge switch/routers per (S_ID, D_ID) pair.

Regards,
Santosh

---

From: Matt Wakeley <[email-masked]>
Date: Thu, 18 Jan 2001 13:46:22 -0800

Please explain why/how you think iFCP and FCIP do not require the use of TCP?

-Matt Wakeley

---

From: "Y P Cheng" <[email-masked]>
Date: Thu, 18 Jan 2001 16:06:53 -0800

> Please explain why/how you think iFCP and FCIP do not require the

Matt,

Certainly, both drafts have proposed TCP.

However, when two iFCP or two FCIP devices talk to another of its own kind,
they have the freedom to use any protocol they wish, even SCTP, as long as
the protocol provides reliable delivery.  This is because the frames are
only received by another device of same implementation.  There is no
interoperability issue with any legacy implementations.  Now, does the other
protocol obeys the fairness rule of Internet?  I assume it would.

Y.P.

---

From: Matt Wakeley <[email-masked]>
Date: Thu, 18 Jan 2001 16:36:54 -0800

Your reply seems to indicate that UDP or some other protocol could be used. 
Only TCP and SCTP implement the congestion control REQUIRED by the internet.

-Matt

---

From: "Y P Cheng" <[email-masked]>
Date: Thu, 18 Jan 2001 18:48:01 -0800

> Your reply seems to indicate that UDP or some other protocol
> could be used. Only TCP and SCTP implement the congestion
> control REQUIRED by the internet.
>
> -Matt

I said "they have the freedom to use any protocol they wish, even SCTP, as
long as
the protocol provides reliable delivery."  I also said "does the other
protocol obeys the fairness rule of Internet?  I assume it would."  I don't
believe UDP fits these two statements. However, talking to a device of its
own kind does give it the freedom in choosing a protocol.  I did not say
that it has a blank check to do everything.

Y.P.