RE: another question (was Re: patent question)

[pat_thaler@agilent.com]

Even when staying within a LAN or VLAN, as the network scales up
in size, congestion control becomes necessary. Neither flow control
nor end-to-end flow control provide effective congestion control in
large networks. For scalability, one needs an adaptive flow control 
that will react to congestion within the network by throttling the
congestion sources with minimal impact on sources that are not causing
congestion. The other alternative is resource reservation over the
whole path rather than just at the end devices. However, given
reasonably bursty traffic, strict resource reservation wastes a lot
of bandwidth and therefore has its own scaling problems. 

For a small network, careful configuration control may work. 
Efficient, reliable operation beyond that requires congestion 
control. Developing effective, stable congestion control 
algorithms has been very challenging (to put it mildly). 

TCP provides an effective congestion control that operates
across a wide variety of network sizes and conditions. 

Pat

-----Original Message-----
From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
Sent: Wednesday, September 20, 2000 3:23 AM
To: bassoon@yogi.ece.cmu.edu; ips@ece.cmu.edu
Subject: Re: another question (was Re: patent question) 


> > i have another quick question. for a local area application, 
> > why hasn't anyone done scsi over ethernet? (ie encapsulating 
> > scsi commands into the ethernet package). why use a higher 
> > level protocol and work with all the latency and overhead problem?
> 
> Check the list archives for info on an Adaptec demo of this, and I'm
> sure Paul von Stamwitz can provide additional information (off the
> list, please).  Encapsulating directly on Ethernet runs into scaling
> problems - the first time one needs to get off the LAN or VLAN that
> the traffic started on, one discovers that an IP header is an immensely
> useful thing to have.

I can add that SCSI on ST (SST) is another implemented form of SCSI on
Ethernet with existing, hardware accelerated implementations.  See
www.genroco.com for more information.

What David says is correct.  You CAN build SANs this way, but you must
careful control the configuration, which is another reason why
scalability is limited.  In some cases, having an Ethernet SAN which
requires this careful configuration control is still better than
needing two network attachment infrastructures (Ethernet & FCP).

Steph