RE: another question (was Re: patent question)

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

Cheng,

TCP/IP was developed outside normal device interfaces but made to
approximate standard file I/O.  This IP interface uses buffers in a clumsy
manner and requires examination for things like checksums.  Unfortunately IP
does not trust hardware, perhaps due to the Telco environment. Letting a few
bits rot on things like DSLAM (Digital Subscriber Line Access Multiplexor)
does not cause excitement.

The concept is with enough hardware, you can make a file (byte stream)
interface look like a SCSI (block) interface to then have the OS transform
that back to a byte stream again.  Why?  SCSI is the storage interface and
yet the traditional means of sending anything in a friendly manner over IP
is by TCP.  On that, there is agreement.

Why a block interface at the storage device?  To abstract storage into
variable length objects requires about 1% ram to hard space to contain a
robust incremental extent, variable name space, and expansive permissions
all involved in high level real-time decisions.  But this cheap ram is still
100 times the expense of hard space so you have doubled cost of storage and
effective use of ram requires close proximity to the CPUs due to nothing
more than the speed of light.  Within the OS there is massive bandwidth
between threads making a final decision if to write/read or hold in cache
all based on these highly dynamic abstractions.  Once past this decision
process, the bandwidth to the block device is tolerable with a simple block
offset and length request.  SCSI over Ethernet is not an innovation, it is
the bigger hammer in hopes to use the now ubiquitous IP.

Some disagree with keeping storage interface a simple block.  See
http://www.nsic.org/nasd/1998-jun/oodreq3.pdf along with clustering.  When a
dominate OS representative was asked how would you recover from a cluster
error, "Reset the system." was not a surprising answer with all this
intelligence getting tangled in chaos.  But how would you be sure of
obtaining the correct object after loss of system coherency?  "Our customers
would rather have bad data than no data."  Again, not a surprise.  Placing
real-time decisions on the net with back and forth open this, close that
does not seem like an innovation to justify a change from something perhaps
a bit more predictable.

Doug


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Dave Nagle
> Sent: Wednesday, September 13, 2000 6:45 PM
> To: ips@ece.cmu.edu
> Subject: another question (was Re: patent question)
>
>
> Really from
>   From: cheng-ann tan <chengann@singnet.com.sg>
>   Reply-To: chengann@singnet.com.sg
>
> thanks a lot for the clarification.
> i have a better idea now about the criteria of
> prior art. but isn't it strange that the patent was granted
> anyhow?
>
> 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?
>
> any insight?
>
> - -cheng
>
> ------- End of Forwarded Message
>