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

["Venkat Rangan" <venkat@rhapsodynetworks.com>]

> Out-of-order is therotically possible even with FC Switch fabrics running
a
> dynamic routing protocol such as FSPF, although in practice FC switches
> vendors seldom run into this condition.

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
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Murali Rajagopal
Sent: Monday, January 22, 2001 8:58 PM
To: David Robinson; IPS Reflector
Subject: Re: FCIP/iFCP : Guarantee In-Order delivery for FC N/NL_ports


A point of clarification on FCIP Ordering and multiple TCP connections:

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.

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.

Out-of-order is therotically possible even with FC Switch fabrics running a
dynamic routing protocol such as FSPF, although in practice FC switches
vendors seldom run into this condition.

In summary, multiple TCP connections is not precluded but a solution is
specified in the current FCIP draft. The authors of the FCIP draft will take
an action to clarify this in the next version.

Regards,

Murali Rajagopal
LightSand Communication

----- Original Message -----
From: "David Robinson" <David.Robinson@EBay.Sun.COM>
To: "IPS Reflector" <ips@ece.cmu.edu>
Sent: Friday, January 19, 2001 2:10 PM
Subject: Re: FCIP/iFCP : Guarantee In-Order delivery for FC N/NL_ports


> Y P Cheng wrote:
> > In the world where I live, iSCSI, iFCP, and FCIP will be implemented in
a
> > box or an adapter running RTOS or microcode with fresh new
implementations.
> > While it is essential to intemperate with the world that runs the
existing
> > TCP implementations, nothing prohibits the box and adapter to
interoperate
> > with each other running in "fast mode" in correct TCP packets as long as
> > they obey the Internet fairness rule without creating so called "Super
TCP".
> > In my adapter, I don't have to live with any old TCP implementations.  I
> > asked often how do we streaming data on a 10 Gb/sec network with
roundtrip
> > time over 100 milliseconds?  I would like to hear discussions providing
> > answers to the above question.  The statement "the TCP implementation
> > guarantees in-order delivery and retries lost packets and has the
necessary
> > flow control and congestion avoidance" does not answer the question for
me.
>
> In general I have not seen people in this WG constraining the design
> based
> on TCP implementations, in fact some have been very abstract in their
> comments
> and referring to what has been proven in theory (if not limited test
> implementations)
> that does not reflect current widely deployed implementations.
>
> If I read you correctly, you are asserting that there is a fundemental
> problem
> in the design on the TCP *protocol* which prevents it from taking
> advantage
> of a 10G/100ms network. If so what exactly do you see as a problem?
> Since we
> cannot (ips WG) cannot change TCP how should an IPS protocol work around
> this
> problem while still being friendly with other protocols?
>
> > If everyone agrees that this group can put iSCSI, iFCP, and FCIP
together by
> > assuming the current TCP implementations having all the solutions,
please
> > let me know.
>
> Conversely, if you feel that this group is designing to the TCP
> implementations
> instead of the protocol, please let us know.
>
> -David
>
>
>