Re: FC over IP: Requirements

["Randall R. Stewart" <randall@stewart.chicago.il.us>]

David:

Comments below...

David Robinson wrote:
> 
> Elizabeth,
> It is good to see you making progress on the FC over IP requirements.
> As there is now another draft that is FC over IP (with SCTP as
> the transport) published, is it possible that we can merge the
> two efforts?  I would not like to see as a result one protocol
> to tunnel between two FC clouds and another to direct attach
> FC to IP.
> 
> Possible considerations are if there are mechanisms to adapt
> one or the other draft to allow a merging? Are the transport level
> retry mechanisms you discuss also going to be fundemental problems
> with the SCTP proposal as well? If you do use TCP as a transport
> will your solutions to congestion control etc be sufficient to
> remove the need for SCTP? I would not like to see two groups
> trying to solve the same problem independantly.

SCTP and TCP have essentially the same Congestion Control algorithms.
The differences between them can be summarized as follows:

   - Message oriented on word boundary(SCTP) vs Byte stream
oriented(TCP)
   - Multi-homing support in SCTP and not in TCP, retry's go to
alternates +
   - Unordered delivery service available in SCTP
   - Ability to order messages within different context's (in SCTP) to
     escape the "head-of-line" blocking issue.
   - Extension draft allows for a non-retransmit option in SCTP (so
     you can escape retransmissions if desired).
   - Acknowledgement in SCTP is always done via SACK, SACK is an option
     in some TCP implementations.
   - Interface designed to have more of the parameters tuneable for
     private networks.

I think the bottom line is if you go with TCP you will not need
to put in SCTP and visa-versa. Of course you can also have an
option for either one.. but if you do use TCP (or both) you need
to specify:

 o How under TCP you do message boundaries, Push's et.al. and
   parsing on the receiver side, since a Push does not assure
   the receiver of getting data in any particular unit size.
 o How you intend to support failover between multiple NIC 
   cards (you get this for free with SCTP), if you even want
   this. Note that during a failure one of the nice things
   with SCTP is the first time-out retransmission (if you are
retransmitting
   data) moves the retransmission to an alternate NIC if possible. This
   means on a broken NIC, recovery is 1 retransmit timer away versus
going
   through N retransmissions before failure OR having to run application 
   level timers to send FEC type packets to a second NIC and hope you
are
   not wasting bandwidth on the network..
 o If you have any head of line blocking issues you will need to
out-line
   how you will escape these in TCP i.e. the use of multiple connections
   (and management of these) to provide some parrallel ordering.
 o You will have to live with ordered messages since there is no way
   to completely escape ordering in TCP. This may be of no issue to
you...
 o You may need to pick implemenations that allow some flexibility in
   setting up TCP parameters. Most don't allow this so it may limit
   some of your choices.

Now some of these issues I list may not even bother you.. thats ok.. but
they are considerations that you need to take into account before
you make any decision...


R

-- 
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222