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

From: Wayland Jeong <[email-masked]>
Date: Thu, 24 Aug 2000 09:41:53 -0700

[ stuff deleted ]

> Now after reviewing the ipfc-fcoverip draft particularly the
> section that specifies why TCP should not be used, there may
> be objections to the Otis draft...
> 
> One of problems mentioned in ipfc-fcoverip is the retransmission
> by TCP being in conflict to retransmissions that would occur
> at the FC level. I would like to call your attention to a
> draft that I think will solve this problem... 
> 
> http://search.ietf.org/internet-drafts/draft-xie-stewart-usctp-00.txt
> 
> This draft defines a new extension that we have proposed for SCTP
> that allows a particular stream to be specified has "no retransmission".
> This way you can mix both completly reliable and unreliable
> transmissions
> over the same association AND still maintain correct congestion control
> policy's in the network. We still are debating the addition of
> a couple of things to this draft:
>

The problem with this is that you don't want to rely on an I/O level retry
to solve congestion problems in the network. If frames are being dropped due
to congestion issues in the network (i.e. WRED) then having SCSI suffer
a timeout and retry an entire I/O will help exacerbate congestion issues
and bring performance to its knees. Depending on the traffic type, an I/O
level retry may result in a 64K block retransmission after a timeout which
is on the order of seconds. Unless you can absolutely rely on diffserv
and/or RSVP or some other QoS mechanism to guarantee reliable delivery,
the overall SCSI performance will suffer.

I guess you can solve the problem with a well-tuned private network or a
bandwidth matched WAN link, but this can be expensive and takes away
from the business case for this technology.

I think that any protocol which cannot tolerate lost data must have a
reliable
transport underneath it in order to achieve performance over gigabit
networks.
I'm not all that familiar with SCTP, but I thought that one of the features
that would be useful is the capability of using SACK and message numbers
to implement selective retransmission. It seems like, for storage, if we use
SCTP as the transport, we want retransmission.

-Wayland

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 24 Aug 2000 12:16:33 -0500

> the overall SCSI performance will suffer.
The point of the u-sctp draft is that you DO NOT retransmit the
data. You let the upper layer do it (if it so desires). Instead
you drop your cwnd (as normal) and move forward the cumulative
TSN point. There is NO retransmission on a u-sctp stream. Now 
we also did not specify in this draft if the upper layer should
be informed of data not making it to the peer.. this may be
a good thing to add ...

> SCTP as the transport, we want retransmission.

Hmm. thats an option as well.. but if you look at:

http://www.ietf.org/internet-drafts/draft-ietf-ipfc-fcoverip-02.txt

it specifically states that you DO NOT want retransmission...

In either case a SCTP endpoint that supported u-sctp and sctp would
be able to have retransmission turned on OR turned off, on any
particular
stream... and it would be able to have one association doing both at
the same time :-> 

You basically can have it any way you want it :-)

R

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