Subject: RE: iSCSI: Framing Steps

From: "Julian Satran" <[email-masked]>
Date: Tue, 29 Jan 2002 23:02:33 +0200

How wonderfull to have among us people that can tell us in one short 
sentence why ATM failed [to reach the desktop because otherwise it is 
still gaining ground].  That adds a lot of clarity and technical argument 
to our discussion.  Julo

Paul Koning <[email-masked]>
Sent by: [email-masked]
29-01-02 22:05

        To:     [email-masked]
        cc:     [email-masked]
        Subject:        RE: iSCSI: Framing Steps

Excerpt of message (sent 29 January 2002) by Somesh Gupta:
> While I support a generic direct data placement model,
> the following are additional points for consideration for
> analysis of memory bandwidths and sizes.
> 
> 1. A 10G link dropping packets will not do TCP at 10Gbps.
> The rate drops as the packet loss increases. I don't recall
> but Franco or Victor from Nortel had posted an equation once.

A very old (40 years?) rule of thumb is that 1% loss costs you 50% in
throughput.  I expect that it gets a lot worse as links get faster.
> ...
> 3. The analysis of 10Gbps, half way round the world
> was initially used in this debate. ALthough interesting, the person
> with the scenario above is not going to blink at the cost of
> 256MBytes of fastest memory considering what they are paying
> for the link.

Exactly.

One reason ATM failed as a LAN is that its design was burdened with
complexity based on that sort of scenario.  (In other words: "it has
to work at umpteen Gig, across the globe, and only use a tiny little
bit of memory because implementations can't handle a megabyte of
buffers".) 

A design optimized for the combination of very high bit rate and very
long latency will inevitably be way overpriced for the predominant
case, which is the LAN case.

      paul

---

From: Paul Koning <[email-masked]>
Date: Tue, 29 Jan 2002 16:55:31 -0500

Excerpt of message (sent 29 January 2002) by Julian Satran:
> to our discussion. 

Actually, my ATM comment was mostly on the ABR service; I don't think
that has gained ground anywhere.  

And, sarcastic comments aside, there's a lot of history of both good
and bad decisions in other protocol designs.  It wouldn't hurt for
people to consider that some of those lessons might even be applicable
to iSCSI.

   paul