RE: Requirements specification

["Douglas Otis" <dotis@sanlight.net>]

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Stephen Bailey
> Sent: Wednesday, August 09, 2000 2:52 PM
> To: ips@ece.cmu.edu
> Subject: Re: Requirements specification
>
>
> > I don't think network channel speeds are increasing briskly.
> Ethernet was 10
> > Mb/s in 1980, 100 Mb/s in 1990, and 1 Gb/s in 2000. These are slow
> > infrastructural step functions.

You're comparing a times two rate to a times 10 rate.  You should also add
10 Gb/s in 2001, and 40 Gb/s in 2002.

<snip>

> The most immediate hurdle is what iSCSI is addressing---efficient data
> delivery at faster speeds.  There's no point in having a fast channel
> if you can't make use of it.  Once appropriate hardware acceleration
> is available, the demand for faster channels will come as applications
> are developed to use it, and the physical layer technologies are close
> at hand.

iSCSI does not provide any solutions if you consider the bottleneck in this
interface is the memory.  iSCSI requires ordered delivery, multiple memory
copies, split header aggregation, etc.   All these things prevent iSCSI from
being successful even with dedicated hardware.

> > In the 1990's there was a transition from shared bandwidth to switched
> > bandwidth which helped mitigate the problem of the slow
> evolution of link
> > speeds.
>
> The biggest problem this began to solve was how to introduce faster
> channels into the network infrastructure.  If you have a shared
> medium, it is very difficult to support channels of different speeds.
> This is one of the reasons why faster FC is slow in coming, even
> though the physical medium technology has been around.  If the medium
> is not shared, you can upgrade on a link by link basis.
>
> The other hurdle that has to be crossed once you allow channels of
> various speeds is congestion.  Any infrastructure that lacks some form
> of congestion control (adaptive (TCP), or bandwidth reservation (ATM))
> will not be able to support increasing link speeds effectively.  This
> is another reason why faster FC is slow in coming.
>
> What iSCSI brings to the table (assuming it can carry it without
> dropping it :^), is hardware data handling with congestion control and
> media independence, hopefully in a way that other protocols besides
> storage can also use the hardware.  This is the dynamite which will
> blast open the door to memory speed channels.  Once you have a memory
> speed channel, there's no need to stripe.
>
> Steph

Odd, memory is the bottleneck.  A memory effective solution will be found,
but do not expect iSCSI to lead.  If you have a high speed channel, there is
no reason not to aggregate slower devices.  An interim cache will not
improve reliability, scale ability, or availability.  If this network is
feeding a high end server, the server back plane will always offer higher
performance and hence the best location for any additional memory and state
information.

Doug