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

["Douglas Otis" <dotis@sanlight.net>]

Murali,

To allow detection of stale frames due from a disrupted IP network and to
maintaining ordering on multiple connections, a local time-stamp that
resolves to the packet rate would solve both these issues.  To ensure
ordered delivery, especially with multiple connections, both situations must
be accommodated.  The R_A_TOV fabric time-outs are meaningless unless there
is a means to police stale frames finding their way across IP space.  A
locally generated time-stamp would allow a means to both ensure ordering
over multiple connections as well as a means of rejecting stale frames held
up by some IP disruption otherwise frame ordering is not assured.

Doug

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