Re: a vote for asymmetric connections in a session

["David A. Peterson" <dap@storage.network.com>]

I would consider the FCP_XFER_RDY IU a "flow control" mechanism (granted it is
currently only defined for writes). Also, the FCP-2 sequence level recovery has
been developed and is deployed in the field. It does work for class 3 in-order
delivery with no known problems other than the recently discovered ambiguous
command issue for which there is an agreed upon solution.

Matt Wakeley wrote:

> Joshua Tseng wrote:
>
> > John,
> >
> > "A lot of data" is relative.  The fastest TCP implementations available
> > today
> > don't come close to what will be required for iSCSI, since they peak out
> > at about 200Mbps.  And the vast majority of applications are get much worse
> > performance than that out of TCP--I would guess typically about 20Mbps max.
> >
> > iSCSI will use TCP like never before.  I believe FCP has flow control/
> > command recovery mechanisms below SCSI.
>
> Nope. FCP does not have *any* flow control mechanisms (Fibre Channel itself
> does, but *not* the FCP protocol).
> In addition, FCP does *not* have any command recovery mechisms either.  It uses
> the "if the command doesn't complete within x amount of time, blow it away and
> try again" recovery mechanism.
>
> FCP-2 (which is still under developement, and not deployed) is attempting to
> "recover" lost commands and data frames.  And this "recovery" is only meant for
> devices such as tapes, and not discs.
>
> -Matt
>
> > Unlike iSCSI, FCP has the benefit of operating in a low latency environment
> > (<10us).  To think iSCSI can do
> > without it and still be able to function reliably is, well iffy at best from
> > what I can see.
> >
> > Regads,
> >
> > Josh
begin:vcard 
n:Peterson;David A.
tel;cell:612-251-6229
tel;work:763-391-1008
x-mozilla-html:FALSE
org:StorageTek;Minnesota Research and Development Center
adr:;;;;;;
version:2.1
email;internet:dap@network.com
title:Chief Architect - Network Interface Development
fn:David A. Peterson
end:vcard