Subject: RE: draft-otis-fc-sctp-ip-00.txt

From: Wayland Jeong <[email-masked]>
Date: Thu, 24 Aug 2000 19:37:28 -0700

> It seems like people are missing the intended application of FCoverIP -
namely, a
> switching device, NOT an endpoint.  Switching devices are not aware of the
> protocol running over FC and must treat every FC packet similarly.  SCSI
is only
> one application that runs over FC.  An FCoverIP device can't selectively
decide to
> retransmit a packet without implementing some pretty complicated policies,
and
> looking into the headers of each packet, which would degrade performance
so much
> that it's questionable whether this would be a feasable application at
all.  This
> has been discussed somewhat on the IPS reflector.
> 
Layer 4 through layer 7 LAN switches exist today (Foundry, Alteon, Extreme,
etc.) that
inspect deep into each packet and make wire-speed decisions about how to
service the
data. There are routers and firewalls which terminate TCP and thus run
entire stacks in
the box. I'm not saying that it is trivial to design a port that can keep-up
with the wire and
run a session protocol in hardware, but it is not out of the question. If it
was, iSCSI would
be doomed as a high-performance gigabit solution (and that is an entirely
different argument).

I guess, what I'm trying to say is that someone should clearly state the
requirements for
FCoverIP. If the requirements are that it simply run on a private tuned
network which can
virtually guarantee a loss-less medium, then I would argue that we don't
need congestion
control and hence a retry mechanism. I would also argue that FCoverIP is a
niche, proprietary
solution which probably does not belong in IETF since it is not intended for
the internet. 

If the requirement is that FCoverIP must co-exist with other LAN/WAN
traffic, then I would
argue that at a minimum we need a congestion management scheme since the
networks
depend on it. If we have a need for congestion management that implies that
things are
getting dropped (unless QoS ensures that does not happen.). And if things
are getting
dropped, then retries at the SCSI I/O level could severely limit
performance. 

That was the convoluted reason for my comments about needing to have a retry
mechanism.
I believe that you need a reliable medium for transporting any SCSI-based
protocol.

> Marjorie Krueger
> Vixel Corporation

-Wayland

---

From: "Randall R. Stewart" <[email-masked]>
Date: Fri, 25 Aug 2000 03:44:54 -0500

Wayland:

My sole reason for pointing out the unreliable/non-retransmit
option of SCTP is because of a working group document.
In the document it is very very specific and states that
the WG does not like TCP because of the retransmit storms
that can occur if TCP and the FC layer both retransmit.

I simply offered a solution, and since SCTP could offer
both non-retransmit and retransmit it takes this argument
off the table...

Other comments in-line below:

> solution which probably does not belong in IETF since it is not intended for

If you ARE on a private net, even if Congestion Control is in place it
SHOULD never be engaged. Here a SCTP with non-retransmit will help
you. You never have the danger of a retransmit storm, and the fact
that your network IS so reliable means you never get the CC algorithms
working against you . Also if someone makes a mistake, and puts a 
private configuration across the big I-Internet it provides a
protection..

> dropped, then retries at the SCSI I/O level could severely limit

And here, no matter what the performance level, one could turn on
the reliable side transport of SCTP since it IS on a WAN and the
retransmit on the SCTP level would save you from hitting SCSI I/O
retransmits..

> I believe that you need a reliable medium for transporting any SCSI-based

R
-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222