RE: iSCSI: Framing Steps

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

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.

2. The amount of memory needed is of the order of delay-bandwidth
product and is reasonably independent of the number of connections.
Of course, statistically, worse situations are possible, but that
is not a design point. If lots of packets are being lost, things
are going significantly slower anyway (thus reducing the delay-
bandwidth product).

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.

4. All assumptions are based on existing SCSI API models at
targets. Changes to target APIs/meta-data management would
let some vendors not have to do data copies anyway.

5. A solutions that is iSCSI specific is not likely to give
the savings (especially when it may not work) people expect.

As I mentioned, I think we should take the same approach as
we did for error recovery (if it is not spilling the beans
too much) and come up with a more detailed analysis.

Somesh



> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Stephen Bailey
> Sent: Tuesday, January 29, 2002 6:43 AM
> To: ips@ece.cmu.edu
> Cc: digital_aryan@yahoo.com
> Subject: Re: iSCSI: Framing Steps
>
>
> Sridhar,
>
> > Its true that the current day IP networks are capable of handling packet
> > drops .... But it is high time to have a mechanism to handle this
> > more efficiently, keeping in view the importance of SANs and their
> > intended use.
>
> The combination of IP+transport (TCP/IP) is precisely designed to
> deliver data efficiently and scalably (as a function of network size).
> It is the transport layer's role to maximize `goodput'.  Dropping
> packets in the network as a result of congestion and having the
> transport adjust to this is what results in IP's scalability as
> compared to system area (flow controlled) network technologies.  In
> other words, it's a feature, not a bug.  It's a large part of what
> made IP the dominant networking technology, and it's never going away.
>
> It is not the case that the designers of TCP said `heck, we've got
> these miserable, lossy networks, I guess we'll just suck it up and do
> the best we can, even though it'd work a lot better if we had some
> other characteristics.'
>
> TCP does have some warts in providing the best possible goodput, but
> those are problems for TCP (or other transport) to fix.  Anyway, that
> doesn't seem to be what you're referring to.
>
> The RFC 1122 SHOULD says TCP endpoints should cling tightly to each
> correctly received byte.  If an implementation is discarding portions
> or entire flights of data because a packet is lost that's certainly
> NOT TCP's problem, and not what FIM is intended to fix.  FIM's (or any
> framing technique's) ONLY goal is to reduce the COST (which may equate
> with `tractability' if the cost is otherwise prohibitive) of an
> efficient implementation.  It does not improve the data transport
> efficiency itself at all.
>
> Steph
>
>
>