Re: FC over IP: Requirements

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

Some thoughts and notes:

Murali Rajagopal wrote:
> 
> David:
> 
> The authors of FC Over IP draft see at least 3 distinct options.
> Briefly, this is what we think:
> 
> 1. Make effective use of the Congestion Indicator (CE) bit from a modern
> ECN capable Router but
> without the use of any transport. This indicator will then be used as a
> feedback signal to the
> FC-IP device and will have a bearing on the FC BB credit control between
> this device and the upstream
> FC Switch.
> 

To do ECN you need more than just the two bits provided in the IP
header. You also need a method to communicate to your peer that you
have seen the "congestion notification" at a given point in the
data stream. This notification must be propagated back to the
sender until the sender itself reduces its sending rate and
sends forward an acknowledgement that it has done so. 

The RFC (RFC2481) can be very helpful if you have not read
it. It is short and there are some tricks to implementing it...
these make it most suitable for implemenation in a transport
protocol. I think this is what you would be building to a minor
degree if you choose this option.

How well deployed and available this is, (in the network) is another
question I can't answer. I do like useing ECN though, this is
why the SCTP reference implementation comes ECN enabled...

You may also need to answer the question of what do you do if
ECN is not supported by the routers? Do you kill the iSCSI connection?
How do you proceed... if you need to move forward then you must also
add back in the TCP friendly congestion control...

> 2. Investigate the possible use of a subset of full TCP functionality
> that would suit the requirements
> of this application.

Hmm, you could gut TCP leaving in the congestion control and attempting
to put message boundaries in. Look into getting rid of the head-of-line
blocking issue (if you need to get around this). This is how SCTP got
started and the end result is SCTP... You might possibly not need all
the features in SCTP but the more you dig into a transport protocol
the more you will find it involves more than you think :)

> 
> 3. Similarly, investigate the posible use of a subset of SCTP.

SCTP is fairly sub-settable. You do not have to understand how
to do bundling and some of the other features. You do have to
understand how to decode a bundle of chunks.. just not encode it.

If one wants you can build an implemenation that eliminates the
stream concept, by simply only asking for one stream and setting
a limit of only one stream on all outbound association setups.

I would think you may possibly want the unreliable transport extension
that we are currently working on.. but this does seem a item for
debate... in any event, it is always available if the WG decides it
needs it(the unreliable extension)...

In general I think if you dig in a bit you will find that SCTP is

A) both extensible and
B) can be kept to a minimum subset to some extent.


I don't have a complete picture of all of the iSCSI requirments but
I think IMHO you will find a closer fit in SCTP then you will in any of
the other options... of course you knew I would say that :)

R

> 
> As you can tell, these are mutually exclusive and would be difficult to
> combine them.
> 
> Regards,
> 
> Murali Rajagopal
> 
> muralir@lightSand.com
> 
> 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.
> >
> >         -David
> >

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