Re: iSCSI: Framing Steps

[Stephen Bailey <steph@cs.uchicago.edu>]

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