RE: Re: iSCSI: SCTP Switch and Router support

["Thomas Crowe" <thomas_crowe@yahoo.com>]

I am not suggesting that that iSCSI could not be load balanced, however
there would be significant challenges to doing so.  Firstly most hardware
based loadbalancers are based totally on the TCP session, how would this fit
into the iSCSI model?  In the usual configuration you would have the devices
providing the service *behind* the loadbalancers and the loadbalancer would
route the traffic based on defined rules.  This would have the requirement
that n devices contain the exact same information in the exact same
location.

|----|                      |_____|---|
| A  |______|--|___|--|_____|     |---|
|----|      |--|   |--|     |      D
             B       C      |_____|---|
                            |     |---|
                                   E

A:  Client requesting the data
B:  Virtual address that the client's use to access the service
C:  Physical LoadBalancer (i.e. Foundry ServerIron, Alteon, Cisco
LocalDirector)
D, E:  devices providing iSCSI services

Just to clarify my position again :-)
At this time I can not make an educated stand either for or against using
SCTP or TCP.  I wanted to point out what I perceived as possibly a
misunderstanding of the switch / router support for SCTP.  Layer 2 / 3
devices should have no problem switching or routing SCTP the issue comes in
at Layer 4, for functions such as ACL's, LoadBalancing, Firewall's etc....

Thomas Crowe
Senior Systems Engineer
CTSinc.net
Atlanta, GA

> -----Original Message-----
> From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
> Sent: Friday, August 25, 2000 11:32 AM
> To: Thomas Crowe
> Cc: somesh_gupta@hp.com; Black_David@emc.com; ips@ece.cmu.edu
> Subject: RE: Re: iSCSI: SCTP Switch and Router support
>
>
>
> I know of at least one vendor that wanted to do iSCSI load balancing
> across Multiple Physical Targets, that needed to be looked at as one
> Virtual Target.  Are you suggesting that the Load Balancing Switches could
> not be used by iSCSI even if they used TCP/IP?
>
> .
> .
> .
> John L. Hufferd
>
>
> "Thomas Crowe" <thomas_crowe@yahoo.com> on 08/25/2000 06:01:35 AM
>
> To:   <somesh_gupta@hp.com>, <Black_David@emc.com>, John Hufferd/San
>       Jose/IBM@IBMUS
> cc:   <ips@ece.cmu.edu>
> Subject:  RE: Re: iSCSI: SCTP Switch and Router support
>
>
>
> Switches are aware of protocol from a layer 4 perspective to enhance
> performance, not make switching decisions.  The two company's that you
> mention (Alteon and Foundry) both make layer 4 switches that are designed
> to
> make switching decisions on TCP sessions, one of those devices
> would not be
> used in the transport of iSCSI packets, they are used instead for the
> loadbalancing of webservers and the like.  Foundry also make pure layer 2
> switches as well as layer 2/3 routing switches.  AccessLists would be
> affected but that alone should not be a driving factor in not supporting
> SCTP.
>
> MTU path discovery is NOT a function of TCP, that is done with ICMP.
>
> Just to clarify, I am not supporting / not supporting SCTP I simply wanted
> to clarify some of the network issues.
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > somesh_gupta@hp.com
> > Sent: Thursday, August 24, 2000 1:22 PM
> > To: Black_David@emc.com; hufferd@us.ibm.com
> > Cc: ips@ece.cmu.edu
> > Subject: RE: Re: iSCSI: SCTP Switch and Router support
> >
> >
> > I agree. Look at switches by a lot of vendors (like Alteon,
> > Foundry etc.). In general, the trend towards being aware of
> > TCP connection flows (keeping actual connection states) is
> > increasing with some switches capable of maintaining state
> > information for upto a million connections.
> >
> > In addition to things mentioned by John, it is also going to
> > be used (or already being used) for traffic classification
> > (VLAN and priority). It is an important component of traffic
> > engineering.
> >
> > (on a comment by Doug, most (all??) TCP implementations today
> > avoid fragmentation also (by using path MTU discovery) since
> > fragmentation is so expensive for routers or receivers.
> >
> > Somesh
> >
> > > -----Original Message-----
> > > From: hufferd@us.ibm.com [mailto:hufferd@us.ibm.com]
> > > Sent: Thursday, August 24, 2000 9:19 AM
> > > To: Black_David@emc.com
> > > Cc: ips@ece.cmu.edu
> > > Subject: FW: Re: iSCSI: SCTP Switch and Router support
> > >
> > >
> > > David,
> > > A lot of what you say is true, however, the word "Most" is
> > > the key.  There
> > > are a number of Switches, NATs, Proxies, and Load Balancers
> > > that actually
> > > care about TCP/IP.  I do not believe they will handle the SCTP in a
> > > transparent manor.
> > >
> > > .
> > > .
> > > .
> > > John L. Hufferd
> > > Senior Technical Staff Member (STSM)
> > > IBM/SSD San Jose Ca
> > > (408) 256-0403, Tie: 276-0403
> > > Internet address: hufferd@us.ibm.com
> > > Notes address: John Hufferd/San Jose/IBM @ IBMUS
> > > VM address: hufferd at IBMUSM54
> > >
> > >
> > > Black_David@emc.com on 08/24/2000 08:54:46 AM
> > >
> > > To:   John Hufferd/San Jose/IBM@IBMUS
> > > cc:   ips@ece.cmu.edu
> > > Subject:  iSCSI: SCTP Switch and Router support
> > >
> > >
> > >
> > > John,
> > >
> > > > 3. We will need to get the Switch and Router folks to also
> > > support SCTP
> > > and
> > > > to do it in Hardware so that the speed and throughput can
> > > be maintained.
> > > I
> > > > do not see that happening, at least not right away, when we
> > > need to get
> > > > volumes moving in order to validate the IP storage SAN concept.
> > >
> > > I don't understand this.  Most switches and routers
> > > have no knowledge of whether TCP, UDP, or even IPsec
> > > encapsulated (and hence opaque) traffic is flowing
> > > through them.  What's special about SCTP -- is this
> > > about layer 4 and higher switches/routers?
> > >
> > > --David
> > >
> > > ---------------------------------------------------
> > > David L. Black, Senior Technologist
> > > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
> > > black_david@emc.com  Cellular: +1 (978) 394-7754
> > > ---------------------------------------------------
> > >
> > >
> > >
>
>
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com
>
>
>


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com